> i guess i need to update this man page. i didn't recall the > search algorithm was documented. thanks for pointing that out.
sorry for the obtuse reference. now that i've made it on the list, i'll just explain myself. i made a local change to how nvram is found because i kept needing to update the search to add new drives. sata has made it more difficult to just enumerate the possibilities. a vanilla machine can have 2 ahci controllers and up to 32 drives per controller. devsd supports up to 16 drives per controller, which covers existing hardware. that becomes annoying to enumerate. my test machine has 1 ahci, 2 ide, 1 mv50xx, 2 marvell orion and 1 loopback controller. since the current approach requires 2 entries per drive, i changed to this algorithm: 1. read #S/sdctl. gather a list of device ids. example /dev/sdC, /dev/sdE. 2. for each device, probe drives 0-f. example /dev/sdE[0-f]. both a partition named "nvram" and 9fat/plan9.nvr are probed. note: a. probes on other devices are unchanged. b. i modified sd so that each sd device produces exactly 1 line in #S/sdctl. the parallel scsi drivers had previously been missing. bugs: a. non-sd disks like usb still can't be used with this scheme. b. probe order depends on the order of sd devices in your kernel config. one could argue that you should just plug your nvram drive into a low-numbered port, but i kept running situations where i couldn't use the ports i wanted due to chassis constraints. ahci also provides a mechanism for disabling ports, so it's anyone's guess what ports are actually available. this change as worked well on my personal system and at coraid for the past 6 months. it just works. even on hitherto unknown controllers like the orion. - erik
