> #ident "@(#)issues 1.5 07/09/12 SAC" > > kb-01 'props' vs 'capabs'. Are both needed? what's the difference? what are > the criteria for a device driver developer to express a certain > feature as a property or as a capab (via the mac_capab_*() interface)? > AI: update document to clearly note difference between property and capability, providing guidelines. Section 2.1 of design doc [2] has been updated. > kb-02 3.2.4, use of ddi_strtoul(). Why not offer the type as an attribute of > a property that the framework queries (at the same time it asks about > whether the prop is supported or not), then read/parse/convert the > userland input as needed, and pass a properly typed prop value through > the (*mc_setprop)() Response: the ddi_strtoul is only needed for Private properties, where we are currently providing the same usage as is available for ndd and driver.conf. As an RFE it would be possible to expand this so that the drivers can register private properties (including their type) with the mac and dladm layers, allowing the framework to read/parse/convert user input. > kb-03 5.1 > driver.conf can carry per driver and per instance properties. > What's the equivalent of per-driver in this proposal? Response: Although they are not supported now, nothing in Brussels prevents the creation of driver-wide parameters in the future. Also, as a side-effect of the methods proposed in Section 5.1, driver.conf input will be returned via the Brussels property retrieval interfaces. Section 2.1 of the design doc [2] also points out that the design proposed does not constrain extensions to support driver-wide parameters in future extensions. > > kb-99 (implementation nit) an enum type seems more suitable for pr_num (the > scalar encoding of a prop type). Accept; will be addressed in the implementation. > kb-98 Attempt to set a property on a device that cannot support it should > fail with EINVAL or ENOTSUP, not ENXIO (No such Device or Address). Accept; Section 3.2.3 of [2] has been updated. > > seb-01 brussels-umbrella.txt 3.5 > This is a subset of the ON GLDv3 drivers (and one that is under > development and not yet in ON.) Is the idea to convert all ON > drivers? If so, I'd state that instead of listing them here, as > the list seems to be growing weekly. > Accept; Section 3.4 of [3] has been updated. > seb-02 brussels-umbrella.txt 4.1.3 > I'm not sure I understand the semantics of this function. > mac_register_t contains fields that are clearly immutable and > only meant to be initial settings, and the structure does not > contain the values of the properties that may be supported by > the driver. It would be cleaner (IMO) to add specific > mac_update_*() functions for specific properties well-known to > the framework (such as mac_update_sdu() for example). Accept; we will be importing the mac_maxsdu_update() interface from Project Clearview (iptunnel component; PSARC case TBD). > ged-01 brussels-umbrella.txt 3.4 > I don't think drivers should use NDD *at all*. If Brussels is going > to achieve simplification for drivers, it should really provide a > common way for drivers to support "private" properties, without asking > them to resort to the very clunky NDD ioctls. My hope is one day to > eradicate all the different NDD implementations in drivers out there. > > But then I see in brussels pdf 5.2 you plan to use nd_param_t? > This still seems a bit clumsy and insufficiently specified. I'd > like a lot more detail here before final commitment. Clarification: Section 5.2 is talking about legacy support for existing ndd usage which will be addressed in the ndd compatibility component of the Umbrella case. Drivers will not be required to support ndd (or any related structures) after Brussels. Section 5.2 of [2] has been updated to clarify this explicitly. > ged-02 general > A lot of drivers have tweaking for loopback via IOCTLs. I'd still > like this to be "on the plan". Loopback ioctls are important for > SunVTS, but very clumsy to implement directly. I think they might > fit well to Brussels properties. The SunVTS ioctls are not really "properties" that control the behavior of the interface, like other examples considered, but are part of loopback testing interfaces that are documented in netlb.h as "may be supported". We've filed an RFE: 6613193 loopback ioctls should be implemented as Brussels properties. to track this (currently under brussels:software/driver but will be converted to solaris with putback) > > ged-03 For the record, I'm willing to update eri, dmfe, hme, afe, mxfe > rtls, and iprb which are the drivers I've touched. Ok. > > ged-04 Why no WLAN drivers? I'd really like to see some of > the WIFI tunables handled here. Accept; Section 3.2.1 of [2] and Section 3.4 of [3] have been updated. Other AI's: ---------- - The umbrella doc [3] has been updated to collapse framework deliver, dladm and libdladm components into one deliverable for PSARC 2007/429. - An example for private property usage, with sample code, has been provided in Appendix B of [2] References: ----------- [1] one-pager (http://sac.sfbay/arc/PSARC/2007/429/20070725_sowmini.varadhan) [2] "Brussels- NIC configuration Design Specification" http://opensolaris.org/os/project/brussels/files/brussels.pdf [3] "Brussels Umbrella Document" http://opensolaris.org/os/project/brussels/files/brussels-umbrella.txt [4] "PSARC 2007/429 Brussels Framework Interfaces Specificaiton" [5] Revised ieee802.11 manpage: manpages/ieee802.3.5[.orig, .diff] [in materials] [6] Revised dladm manpage: manpages/dladm.1m[.orig, .diff] [in materials] [7] Revised bge manpage: manpages/bge.7d[.orig, .diff] [in materials]