rtnetlink
rtnetlink copied to clipboard
jsimonetti
rtnetlink: add enumerations/constants for link types, route types, etc.
The current implementation of the rtnetlink API does not appear to contain any constants to refer to link types when creating/referencing a link. I was wondering if those constants could be added to round out the API implementation. Is there any reference (either in linux source or elsewhere) as to the standard values for link types, and if so, could they be added to make creating links a bit easier? (It doesn't look like the standard values are within the unix library anywhere either) I am willing to root around if there is a standard list, I have not found anything in iproute2 source or kernel source, but I guess it exists. I was wondering if this would be a worthwhile feature I should invest more time in and create a PR for.
Thanks
Hi, I am sorry for my late response. I have quickly looked into this and couldn't find the constants in x/sys/unix. I have a hard time believing that there are no constants somewhere in the kernel for link types, sp this might just be a case of missing header parsing on that end. So I think the best course of action would be to add the appropriate constants to x/sys/unix. I will have a look what I can do from my end for this. Perhaps @mdlayher has some spare time? He has done that a lot more often then I have :)
I am no expert, I need to look into this further, but it looks like a lot of link types (if not all) are registered by kernel modules at runtime, and thus I don't think there is a specific set of network devices that are registered by kernel sources. I think they are registered in at runtime, similar to other char/block devices whenever the kernel module is loaded at bootup. That at least applies to pure software devices/link types, I know on my PI for example GRE and VTI links are implemented by a kernel object. I don't know about physical NICs yet. I need to learn more about the driver layer first.
This actually makes sense. It makes for a much cleaner API between kernel and driver. As such, I don't think adding constants to this package would be the way to go. Now, an additional (sub?) package with just driver constants sounds fine to me, but I think I would prefer them to not be directly in the rtnetlink package. What do you think?
I can work on that, I have been busy with work this week, but I'll look into getting all of the values from runtime/do some more research into this whole thing when I can.