Re: [9fans] nvram

[erik quanstrom <quanstro@quanstro.net>]

> 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