2007/477: Drivers registering devids

[Peter Dennis - Solaris Sustaining Engineering]

Jerry Gilliam wrote:
> I am submitting this fast-track on behalf of myself, with
> timeout set to 08/28/2007.  Patch/update binding requesed.
> 
> 
> -jg
> 
> 
> ------------
> 
> 
> Identification of Drivers Registering Devids
> 
> Summary
> 
>    This case proposes a new property, 'ddi-devid-registrant'. This
>    property will be specified in the driver.conf(4) files of target
>    drivers that call ddi_devid_register(9F) [8].  Instead of using
>    compiled-in tables, the IO framework will use this new information
>    to identify drivers of interest when there is a devid cache [3]
>    miss.  NOTE: This property is similar in purpose to the
>    'ddi-vhci-class' property approved by [1].
> 
>    Immediate consumers (sd, ssd, cmdk, and dad target drivers) are all
>    in ON.  There are no contracts needed at this time. I am seeking
>    patch binding.

There are two other drivers that use ddi_devid_register:
sata and vdc (ldom's virtual disk client) - should they be listed here ?

What happens if a driver uses ddi_devid_register but the corresponding
driver.conf is not updated to have this flag ?

Thanks
pete


> 
> Proposal
> 
>    The IO framework maintains a private cache that maps devids to
>    /devices paths [3]. If the cache is corrupted, deleted, or the
>    requested mapping is not in the cache the IO framework must still
>    perform a best-effort search to resolve a devid to a /devices path.
>    For this best-effort search the IO framework attaches all instances
>    of all drivers that register devids. To do this, the IO framework
>    currently has a compiled-in table containing the names of drivers
>    known to register a devid.
> 
>    The compiled-in list of driver names is a maintenance overhead since
>    the list needs to be updated whenever a new driver that a registers
>    devid is added to the system (or an existing one is removed). To
>    eliminate this overhead, the proposal is to remove this compiled-in
>    list and replace it with a mechanism based on the
>    'ddi-devid-registrant' property.
> 
>    The proposed 'ddi-devid-registrant' property will be specified in
>    the driver.conf file of each target driver that calls
>    ddi_devid_register(9F).  The IO framework will be modified to use
>    this information instead of compiled-in tables.
> 
> 
> Interface Summary
> 
> Interface		Level		Comments
> -------------------------------------------------------------------------
> ddi-devid-registrant    Committed 	Property to indicate a driver may
> 					register a devid for a device
> 
> 
> Man page update
> 
> 
> 
> Kernel Functions for Drivers                ddi_devid_compare(9F)
> 
> NAME
>      ddi_devid_register, <...>
> 
> SYNOPSIS
> 
>      <...>
> 
>      int ddi_devid_register(dev_info_t *dip, ddi_devid_t devid );
> 
>      <...>
> 
> DESCRIPTION
> 
>      <...>
> 
> 
>      ddi_devid_register() registers the device ID address (devid)
>      with  the  DDI  framework,  associating it with the dev_info
>      passed in (dip). The drivers must  register  device  IDs  at
>      attach time. See attach(9E).
> +
> +    A driver which calls ddi_devid_register() should place the
> +    following line in its driver.conf(4) file.  The presence of
> +    this property informs the system that this driver may
> +    register a devid for a device when device discovery is
> +    necessary.
> +
> +       ddi-devid-registrant=1;
> +
> 
> 
> References
> 
>     [1]	PSARC/2006/285 MPxIO Driver Properties
> 	http://sac.sfbay/arc/PSARC/2006/285/
> 
>     [2]	PSARC/2004/504 Common Devid/GUID Encode Interfaces for SCSI Devices
> 	http://sac.sfbay/PSARC/2004/504/
> 
>     [3]	PSARC/2004/064 Devid Cache
> 	http://sac.sfbay/PSARC/2004/064/
> 
>     [4]	PSARC/2003/123 Devids for disksets
> 	http://sac.sfbay/PSARC/2003/123/
> 
>     [5]	PSARC/2001/559 New Devid Type for ATA Drives
> 	http://sac.sfbay/PSARC/2001/559/
> 
>     [6]	PSARC/2000/480 Devid Enhancements
> 	http://sac.sfbay/PSARC/2000/480/
> 
>     [7]	PSARC/1999/357 Devid Issues
> 	http://sac.sfbay/PSARC/1999/357/
> 
>     [8]	PSARC/1995/352 Disk Id
> 	http://sac.sfbay/PSARC/1995/352/
> 
>