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/ > >
