On (08/22/07 17:27), Peter Memishian wrote: > > > 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?
they are a special case of public: as I mentioned in the design doc, the system calls for these are written as discrete ioctls to the net80211 module, so they don't follow the same DLDIOCSETPROP path as the "True" public properties. > ... and if a public property with the same name is subsequently added, it > becomes impossible to access the private property? correct. But Private properties are not designed to linger for extended periods of time. There's a danger of them being abused (much like ndd was), and I'm not sure it's a good idea to build too much infra-structure around these. > > 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 If we are going to use a prefix (and I am not sure at all that we should), let's at least come up with something more obscure than "link_". Maybe some variation/abbreviation of the words "external" and "layer2"? Say "l2ext_", or even just "x_" or some such to be prefixed to private properties? > 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. here's another example: link_clock is used for gigabit drivers. And most drivers that implement this will probably choose the name "link_clock" or some variation (via "-", say) thereof. If we choose a generic prefix like "link_", we'd have to artificially modify the name to fit the implicit stability level. --Sowmini
