Inception: Brussels - enhanced network driver config a dladm (2007/429) Exposure: open Submitter: Sowmini Varadhan Owner: James Carlson Intern: garrett.damore@sun.com SUMMARY ======= Project Brussels aims to fix these problem for GLDv3 drivers by providing a dladm based standardized interface. Specifically, this project will provides a cleaner solution by using the dld layer as the intermediary. GLDv3 drivers will be able to register callback functions to be invoked for setting/getting property values. Dladm/libdladm will be modified to issue system calls to set/get property values via the dld layer. Invocations to the new property management interfaces will be integrated into smf(5) to provide persistent network-driver settings across interface restart and driver unload/reload. ISSUES ====== 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)? =====>Document the definition of capability and property. 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)() =====>Private properties are instructions to the driver. They will be added in future. kb-03 5.0.1 driver.conf can carry per driver and per instance properties. What's the equivalent of per-driver in this proposal? =====>Per-driver is per link. IT will be replacement for driver.conf per link. kb-99 (implementation nit) an enum type seems more suitable for pr_num (the scalar encoding of a prop type). 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). 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. =====>The intent is to convert all the ON drivers. 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). =====>Agree with proposal to clean up above. 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.0.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. ANSWER: The goal is to lose 2: driver.conf and NDD. SOLUTION: Provide examples in documentation . 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. 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. ged-04 Why no WLAN drivers? I'd really like to see some of the WIFI tunables handled here. THE NEXT STEP ============= Schedule commitment.