Brussels framework putback to snv_83!
By sowmini on Jan 24, 2008
PSARC 2007/429 was putback Jan 24 2008! This putback provides a configuration framework for administering network drivers through the GLDv3 framework in Solaris Nevada. This feature should be available on bfu archives built on/after Jan 25 2008, and in snv_83.
This feature has a few ramifications for Network device-driver developers:Project teams that propose new network drivers should no longer need to provide ndd(1m) entry points for administering their driver. Instead, such drivers should provide setprop and getprop entry points as defned in PSARC 2007/429.
The putback of PSARC 2007/429 also converts the bge driver to the Brussels framework, so that the recommended method for administering properties of the bge driver is using the dladm(1m) command.
Information about the Brussels framework, including documentation of the driver interfaces for Brussels can be found at http://opensolaris.org/os/project/brussels
A preview of the draft dladm(1M) man page is also available for those wishing to use the new features introduced by the Brussels/Clearview projects at http://www.opensolaris.org/os/project/clearview/dladm-uv-brussels.1m.txt
- convert more drivers to plug into the Brussels framework- e1000g and igb drivers are next on the pipeline with more to come soon,
- implement the Peristence feature by leveraging on the dlmgmtd provided by Project Clearview. This will allow dladm(1m) to be used for persistently setting tunable values, and the setting will automatically be incorporated at the next restart of the driver (or reboot)
- For legacy drivers, we will clean up the ioctl code path so that the ndd ioctl goes through the Brussels framework (though we will continue to provide legacy support for existing ndd usage in datalink drivers). Details coming soon!
- Phase 0 cleanup of ndd abuse/deficiencies in the TCP/IP layer: e.g., inappropriately use of ndd(1m) in debugging kernel data-structures, when better tools like dtrace and mdb are available, we have a profusion of ndd commands (e.g., for /dev/rts) that are poorly documented and understood. Shrinking this abuse to the bare essentials will place us in a better situation to evaluate alternatives/enhancements to ndd(1m)