nulldriver [PSARC/2008/674 Self Review]
Christopher Horne
cth at sac.sfbay.sun.com
Sun Nov 2 18:23:12 PST 2008
I am sponsoring the following fasttrack for myself. Micro/patch
binding is requested. I believe the case qualifies for self review,
and have filed it as Closed Approved Automatic. If there is a request,
I'd be happy to convert it to a fasttrack and set the timer to enable
further discussion.
-Chris
1. Introduction
1.1. Project/Component Working Name:
nulldriver
1.2. Name of Document Author/Supplier:
Author: Chris Horne
1.3. Date of This Document:
Thu Oct 23 2008
4. Technical Description
4.1 Description
A new 'nulldriver' driver is introduced. This driver succeeds
probe(9E), attach(9E), and detach(9E) but provides no
functionality.
Only consolidation private use of this driver is proposed. Since no
public use is proposed, this case is not providing a nulldriver(7D)
manpage. Any future promotion of nulldriver will be responsible for
documenting public use in nulldriver(7D).
The nulldriver can be used in an number of private ways:
A] To simplify nexus driver child discovery code: With nulldriver,
a nexus driver's bus_config implementation [1] can implement
dynamic child discovery by creating a child 'probe' devinfo
node, bound to nulldriver, at the specific @unit-addresses
associated with discovery. By promoting [2] this
nulldriver-bound 'probe' node, nexus discovery code can reuse
normal operation transport services for discovery. While
nulldriver prevents external device access, a nexus driver can
still internally use the transport services. Reuse of transport
services for discovery results in significant simplification.
In the case of SCSA, nulldriver enables nexus code to issue a
REPORT_LUN command to lun 0 to discover luns. It also allows
the discovery code to issue various forms of identity related
INQUIRY commands (standard, page 0x80, and page 0x83) to
determine the scsi(4) 'compatible' property forms [3] that
apply to each reported lun, and lun devid/GUID information [4].
B] Exclusions: Aliases that specify nulldriver can be used to
represent exclusions. An example use would be to configure a
system so a specific SCSI target driver remains unused on a
given binding-set [3]: the ses(7D) driver should not be used on
ATAPI.
nulldriver "scsiclass,0d.batapi"
The nulldriver allows exclusions to be implemented without
incorporating that knowledge into target drivers.
C] Hardware Disable: Access to a specific device can be disabled
by establishing a path-oriented alias [5] to nulldriver.
# update_drv -a -i '"/pci at 8,600000/SUNW,qlc at 4"' nulldriver
The above example would disable a specific Qlogic HBA.
D] Accommodate Hardware Design Flaw: In this specific use, see [6]
for details, a multi-function card was produced in a
depopulated form, but the fact that the board was depopulated
was not properly reflected in pci config space. While you could
argue that this represents a hardware design flaw, such
hardware was shipped before the flaw was noticed. The
nulldriver could be used to siliently accommodate this type of
errata.
E] Aid: For some devices, the nulldriver can be used in
conjunction with the lowest precedence 'compatible' form to
ensure that devices lacking a driver binding still promote [2]
above DS_LINKED. Promotion causes the unit-address to be
available in its more convenient string form: the @unit-address
form used in /devices path components. In this way,
associating the lowest precedence alias with nulldriver can aid
in establishing a more meaningful driver binding.
The imminent intended private use of nulldriver is A]. The other
use cases above are just informatinal at this point.
Support for automatically changing driver binding as a result of
alias additions (update_drv -a -i) and deletions (update_drv -d -i)
without additional action (cfgadm(1M), modunload(1M), or reboot) is
dependent on correct framework support. There have been issues in
this area for a long time. While some progress has been made [5]
(unbind_children), some issues still remain [8]. Ensuring complete
correctness is beyond the scope of this proposal, but the remaining
issues are being worked on.
The nulldriver was previously proposed as part of [3], but there
was some disagreement around its utility. I think that some of this
resistance may have been related to framework deficiencies at the
time related to dynamic alias modification support. In the interest
of delivering on [3], and because nulldriver was not an integral
part of that case, it was dropped from that proposal.
4.2 Proposed Interfaces
------------------------------------------------------------------
Interface Name Comm.Level Comments
------------------------------------------------------------------
nulldriver Private Driver that provides a
'null' implementation.
nulldriver_major Private major_t of nulldriver(7D).
Used to suppress path_to_inst
entries for nulldriver(7D)
paths.
4.3 Release Binding
Micro/patch binding is requested.
4.4 References
[1] PSARC/2002/168 Bus Config
http://sac.sfbay/PSARC/2002/168
http://www.opensolaris.org/os/community/arc/caselog/2002/168
[2] PSARC/2000/532 Devinfo State Model
http://sac.sfbay/PSARC/2000/532
http://www.opensolaris.org/os/community/arc/caselog/2000/532
[3] PSARC/2004/116 SCSI target compatible property
http://sac.sfbay/PSARC/2004/116
http://www.opensolaris.org/os/community/arc/caselog/2004/116
[4] PSARC/2004/504 Common Devid/GUID Encode Interfaces for SCSI Devices
http://sac.sfbay/PSARC/2004/504
http://www.opensolaris.org/os/community/arc/caselog/2004/504
[5] PSARC/2007/176 path-oriented driver alias
http://sac.sfbay/PSARC/2007/176
http://www.opensolaris.org/os/community/arc/caselog/2007/176
[6] Bugs related to hardware that should not be used.
5094257 No driver binding for X1033A during PCI hotplug
http://monaco.sfbay.sun.com/detail.jsf?cr=5094257
[7] Prtconf display of 'compatible'
6502202 prtconf should display 'compatible'
http://monaco.sfbay.sun.com/detail.jsf?cr=6502202
[8] Bugs related to update_drv operation.
4854243 update_drv -d requires reboot
6464765 update_drv -d can remove other etnries than one specified
6198348 update_drv: needs -n option
http://monaco.sfbay.sun.com/detail.jsf?cr=4854243,6464765,6198348
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: Automatic
6.6. ARC Exposure: open
More information about the opensolaris-arc
mailing list