Eric W. Biederman wrote: > Patrick McHardy <[EMAIL PROTECTED]> writes: > >>You don't really need to patch it, installing a new iplink_XXX.so >>file is enough. Generalizing driver specific options more than >>what we currently have doesn't look very promising. I think your >>driver was simple enough to get along with the generic device >>attributes though (IFLA_LINK or IFLA_MASTER). > > > I need to know the other device in the pair of devices I am creating. > If ifindex was selectable IFLA_LINK or IFLA_MASTER might be > interesting however they are currently are not, and I'm not quite > certain about letting a user select the ifindex. Although there may > come a point when dealing with migration when it makes sense.
It shouldn't be very hard to implement, so far I just didn't see any use for it. > Hmm. I guess if I had a reasonable default I could find out the > pair device by looking at the returned NEW_LINK message. > > Looking more close. IFLA_MASTER does not work because I don't > have a master/slave relationship. > > IFLA_LINK looks like it will work. I don't precisely match the > semantics though which makes me nervous. In particular my other > device is not something I am sending through but what I am sending > to. The way the IPv6 code uses iflink to get the link local address > starting with the hardware address of the iflink would be completely > the wrong thing to do in my case. Now my device won't have the magic > IPv6 tunnel arp type so that code won't trigger. Still it is > a challenge. > > I still think adding a IFLA_PARTNER or a custom attribute is cleaner > in this case. Slight semantic mismatches are the worst design bugs > to correct. Indeed, IFLA_PARTNER sounds like a better idea. I just suggested to Pavel to create only a single device per newlink operation and binding them later, what do you think about that? >>>I do think we should specify the IFLA_KIND (was: IFLA_NAME) values in >>>a header file. So it is easy to get a list of all of the different >>>kinds and so we don't conflict. >> >> >>I don't think conflicts are going to be a problem (it would be >>nice if modpost would warn about duplicate aliases though). >>How is listing IFLA_KIND types in a header file going to help >>get a list? Presuming the user knows what kind of device he >>wants to set up and is not just looking for things to play >>around with I also don't see any real value in this. > > > This isn't about the user this is about maintaining the ABI. > > We have to control set of strings for IFLA_KIND. Having them all > in a single header file means that we can easily look when we add > support for a new kind to see if some other driver has already > used that kind. > > The same reason we stick the rest of the enumerations into a header > file. > > Strings don't conflict as easily as small integers do, but it is still > possible to have a conflict, so having something like an ifla_kind.h to > hold them would be useful. Mhh .. we have multiple string based APIs that do just fine. I'd prefer having someone adding a new driver do a quick grep for MODULE_ALIAS_RTNL_LINK to adding unused definitions. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html