Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - Path name enumeration and SIM_HBA: (5 Items)
   
Path name enumeration and SIM_HBA  
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'.

When a card is not in one of them, the device is removed from /dev. 

If I only put a card in the right one and the xpt_async() dance is done, all goes well, expect that instead of /dev/sd1,
 its /dev/sd0.

Is there a way to tell io-blk how to number them, or do I need to go ahead and allow the device name for the left one to
 show up as /dev/sd0 (even if a card isn't in the slot) so the right one beceoms /dev/sd1?

Thanks
Kevin
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...
Re: Path name enumeration and SIM_HBA  
I think I'm going to have to run multiple instances of this driver to make this work.  I would like to run only one and 
be able to dictate the enumeration numbers for the devices if possible....

Thanks
Kevin
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?
Re: Path name enumeration and SIM_HBA  
Wow.  This is really great information, thanks John.

Yeah..for now I'm running multiple instances..I'll probably look at this more in depth later.  It's been an interesting 
journey understanding it all.  And I have to say, I really think this IO-BLK/SCSI/CAM subsystem in QNX is a jewel.  I 
was able to use the ANSI specs to figure out the behavior, you guys have done a great with it.

Kevin