On (08/22/07 16:37), Peter Memishian wrote: > > So what keeps the driver's private property names from colliding > non-private names that are later added?
It doesn't. As Section 3.2.1 of the Brussels design doc says, the property names are prioritized as: 1. first search public props 2. if not found, try the wifi props 3. if not found, try private props. The idea is to treat Private props as experimental, second-class citizens. A driver that wants to venture in this area should first make sure there's no name-space collision with public props (which will be fully documented in the dladm(1m) man page). > (That's one of the intents of the > the link_ prefix. The other is making the division between private and > public property names an explicit part of the administrative experience, > so the admin's expectations remain appropriately set.) I'm not averse to it, but adding the link_ prefix for Private props (or vice-versa) places an artificial burden on Public props - for example many MII props are already prefixed with "link_". If we choose to make these Public ethernet props (as Brussels has done) we'd now have to strip off the "link_" prefix. In the general case, if a driver comes up with some prop like "link_foo" that ends up being a good candidate for a public prop, we'd have to go through the exercise of stripping off the link_ to promote it. --Sowmini
