nulldriver [PSARC/2008/674 Self Review]
Garrett D'Amore
gdamore at sun.com
Sun Nov 2 21:29:34 PST 2008
+1
It turns out that I have used this approach for another use case, which
is development of device drivers. Having a driver like nulldriver in
place (but suitably renamed) allows me to have enough stuff present to
meet add_drv requirements, but doesn't require me to put stuff of
questionable quality (e.g. early debug bits) on the filesystem itself.
This can prevent a situation where a crash in the driver results in
requiring external media (or fail-safe boot) ... because the "real"
driver is loaded only from NFS after doing modunload of the null driver.
The details are probably beyond the scope of what we want to discuss in
detail, but just thought it might provide an interesting data point.
-- Garrett
Christopher Horne wrote:
> 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