Kevin Stallard(deleted)
|
Re: Path name enumeration and SIM_HBA
|
Kevin Stallard(deleted)
07/24/2009 2:41 PM
post34551
|
Re: Path name enumeration and SIM_HBA
If I do things such that all the device entries appear, then it won't automount. If I do it such that only the valid
one appears, then it will automount the one, but it's numbered incorrectly...
|
|
|
John Garvey
|
Re: Path name enumeration and SIM_HBA
|
John Garvey
07/24/2009 3:56 PM
post34560
|
Re: Path name enumeration and SIM_HBA
Kevin Stallard wrote:
> Is there a way to force io-blk to use a particular number when enumerating devices?
> i.e. I have two SD card slots. One on the left and one on the right. I'd like to have the left be '0' and the right
be '1'.
Unfortunately, not really. A number of factors involved:
* the name prefix is provided by cam-disk, and not your driver, so you
can't dynamically change it on a per-attach basis;
* the rsrcdbmgr_devno_attach() changed its behaviour mid-life to fail
an attempt to use a specific minor number (it used to advance);
* resmgr_attach() will awlays succeed, possibly unioning mounts (thus
a unique naming scheme involving it must poll, which introduces
race windows plus has stack requirement);
* driver might have multiple devices; might have multiple drivers
(so some name conflict is known, some unknown, but thus likely
involved some form of external coordination).
These all conspire to mean that the original scheme doesn't work too
well at anything other than random/sequential naming. I'd like to
improve it, but not quite sure how at this point, since it will likely
involve changes outside of just io-blk.
Potential workarounds might be:
* attach your devices just once, and leave them alone (so they stay
named 0 and 1 in order); indicate media changes via SK_UNIT_ATN sense
codes (as the ATAPI CD-ROM driver does); media insert/relearns driven
by user access only; paths always up but will ENXIO when ejected
* run two drivers, one "disk name=sd@0" the other "disk name=sd@1"
(the old-style mechanism for doing this), and whatever option you
need to access only one (provided the h/w is separate controllers),
and you can attach/detach these dynamically and they should stick
to the forced name
* use procmgr_symlink to dynamically also create/remove a symlink
(left or right) that points to the appropriate sd0 or sd1; I have
seen this done in the driver itself, which is pretty ugly; it could
also be done by an external monitor/enumerator
Medium term we might be able to add something to libcam that allows
specification of device names for each P/T/L (on same bus); so you
could force 0/0/0=sd0 and 0/1/0=sd1, rather than just a single
prefix (sd) coming up. The io-blk attempts at numbering are still
potentially problematic in general (multiple drivers trying to
force conflicting names), but would be non-applicable in this case.
I think this is a more relevant fix (to provide explicit names from
the driver rather than trying to reverse-engineer them higher up!)
Longer term I suspect the correct approach is the integration of
phsyical device location and raw device names with a symlink-style
management scheme. So names at the device level are purely
physical-based (bus, P/T/L, etc) and thus implicitly unique already.
Then a higher-level management layer would be responsible for
linking more friendly names onto those, if required. This would
be an excellent opportunity to possibly rationalise enumerators
and media detectors and auto-mounters etc all into one place?
|
|
|