> >Ah, but this is less driver implementation and more *framework* related. >I mind less that drivers register a property in attach(), than that we >rely on the actual driver.conf to be read by the framework and used >before driver attach. > > -- Garrett
Attach however is per-device and the ddi-devid-registrant property would be per-driver. We don't want open-by-devid of the root device to return to the old days of attach-everything. Even inspecting the cb_ops for a flag, searching for elf information or asking the driver to provide a property at _init(9E) time would require at minimum loading all drivers. Persistently recording that information however would allow us to harvest it once. And to not have to repeat that process unless that data were lost. There would be a dynamic aspect to this, in that the process would have to be performed on each driver add and update of a driver.conf file. (Yes, update_drv(1M) does inform the system dynamically of driver.conf updates) I have considered that in the past and suppose I never pursued it because it hardly seemed worth the trouble. When I submitted this case, believe it or not I was half expecting to be chastised for wasting PSARC's time with such an obvious proposal that should have been submitted approved/self-reviewed. Silly me. ;-) If we were to cache the data, I can't think of any reason not to include it in the devid cache itself. The format of that file is typed & versioned nvlist data and easily extensible. The one serious constraint is that the list of drivers would need to be available before root is mounted to avoid mountroot requiring discovery. -jg
