> 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
Aren't the WiFi properties public? > 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). ... and if a public property with the same name is subsequently added, it becomes impossible to access the private property? > 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. We don't need to use that prefix. A prefix just seemed simpler to me than adding a formal namespace abstraction -- and I don't know how you can address the issue I raised above without some sort of namespace isolation. > 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. But are we really likely to promote things as-is? I think it's more likely that N different drivers will all add their own version of link_foo, with slightly different names and semantics, and we'll need to add a public version, unified version with a name and semantics that accommodate all of those N private properties. -- meem
