Re: [ANNOUNCE] hotplug-ng 001 release

Re: [ANNOUNCE] hotplug-ng 001 release

[Patrick Mansfield]

[added linux-scsi]

On Wed, Feb 16, 2005 at 11:32:51PM +0000, Willem Riede wrote:
> On 02/16/2005 06:17:41 PM, Roman Kagan wrote:

I tried out Roman's patch, well at least simple loading of st via
"modprobe scsi-type-1", works nicely as expected. (modprobe -r sd is
hanging on down() in device_unregister with 2.6.11-rc4 ... must be a ref
count problem, have not figured anything out, and took me a while before
trying st and sg instead.)

> > On Wed, Feb 16, 2005 at 11:02:41PM +0000, Willem Riede wrote:
> > > On 02/16/2005 06:07:52 AM, Roman Kagan wrote:
> > > > It handles only st, sd_mod and sr_mod cases (as
> > > > hotplug-ng-001/module_scsi.c did).  Are there any other?
> > > 
> > > Not all tapes are supported by st - OnStream drives need osst instead.
> > 
> > As an excuse I can say that I reproduced what was in
> > hotplug-ng-001/module_scsi.c, no more, no less :)
> > 
> > > How do you suggest that is to be handled?
> > 
> > AFAICS they coexist nicely, so, if you add the same thing to osst.c:
> > 
> > MODULE_ALIAS("scsi-type-1");	/*	TYPE_TAPE	*/
> > 
> > both osst and st will be loaded (provided Greg convinces Rusty to make
> > modprobe load _all_ matching modules as he suggested the other day).
> > Then the one whose .probe succeeds will handle the device.
> > 
> > Will that work?
> 
> Yes. If we can get that load-all behaviour implemented, everything will be fine.

You could also append the sdev->vendor and sdev->model, and use alias wild
cards.

So OSST would not be loaded for all tape devices found (not a big deal).
st would still load for all tapes (likely the same as we have today, and
not easy to *not* load it for osst devices).

That is, add aliases to osst.c like:

MODULE_ALIAS("scsi-type-1-onStream-SC-*");
MODULE_ALIAS("scsi-type-1-onStream-DI-*");

etc.

The vendor (8 bytes) and model (16 bytes) can have spaces, and the values
are not '\0' terminated. modprobe does not seem to handle spaces in an
alias.

And for st.c:

MODULE_ALIAS("scsi-type-1-*");

sd.c:

MODULE_ALIAS("scsi-type-4-*");
MODULE_ALIAS("scsi-type-5-*");

Also, sg loading would want (along with modprobe load all feature):

MODULE_ALIAS("scsi-type-*");

-- Patrick Mansfield


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 18, 2005 at 09:17:37AM -0800, Patrick Mansfield wrote:
> You could also append the sdev->vendor and sdev->model, and use alias wild
> cards.

String values haven't been used in the aliases so far, and I think for a
reason: with all the unpredictable weird characters and string lengths
they would make maintainance harder, not easier.

> That is, add aliases to osst.c like:
> 
> MODULE_ALIAS("scsi-type-1-onStream-SC-*");
> MODULE_ALIAS("scsi-type-1-onStream-DI-*");

I used dashes for the only reason of these aliases being static.  If
they are supposed to grow it may make sense to stick to the convention
used everywhere else, i.e. bus:devspec.

> Also, sg loading would want (along with modprobe load all feature):
> 
> MODULE_ALIAS("scsi-type-*");

Is it certain that it can live together with s[dtr]?  I thought these
guys now handled all the ioctls sg was supposed to themselves...

Roman.

Re: [ANNOUNCE] hotplug-ng 001 release

[Patrick Mansfield]

On Fri, Feb 18, 2005 at 09:11:06PM +0300, Roman Kagan wrote:
> On Fri, Feb 18, 2005 at 09:17:37AM -0800, Patrick Mansfield wrote:
> > You could also append the sdev->vendor and sdev->model, and use alias wild
> > cards.
> 
> String values haven't been used in the aliases so far, and I think for a
> reason: with all the unpredictable weird characters and string lengths
> they would make maintainance harder, not easier.

Yes, but modprobe should just work with them, even if scripts or other
usage has problems. I haven't seen any really odd strings for vendor or
model, ususally just spaces and alphanumeric, I don't remember (or even
remember where to look) for the allowed characters; there are always
devices that behave badly.

> > Also, sg loading would want (along with modprobe load all feature):
> > 
> > MODULE_ALIAS("scsi-type-*");
> 
> Is it certain that it can live together with s[dtr]?  I thought these
> guys now handled all the ioctls sg was supposed to themselves...

Yes.

The block SG_IO handles the ioctls, but not devices without a SCSI upper
level driver (i.e. not tape, disk or cdrom).

For example, media changers (though a driver has just been submitted),
scanners, enclosure devices, or printers (I've never seen any scsi
printers).

In my experience, there are always applications that want to use the
standard device driver (/dev/sda etc.) and others that want to use a
generic driver.

-- Patrick Mansfield

Re: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 18, 2005 at 10:33:50AM -0800, Patrick Mansfield wrote:
> The block SG_IO handles the ioctls, but not devices without a SCSI upper
> level driver (i.e. not tape, disk or cdrom).

Then it might make sense to explicitly list in sg.c the TYPE_* not
matched by s[dtr].

> In my experience, there are always applications that want to use the
> standard device driver (/dev/sda etc.) and others that want to use a
> generic driver.

So these drivers can compete for the same device?  Are there
deterministic rules on which one is supposed to win?  And is there a
userspace interface to unbind one driver and bind another?  Otherwise it
may mean that automatic module loading is inappropriate here at all...

Roman.

Re: [ANNOUNCE] hotplug-ng 001 release

[Patrick Mansfield]

On Fri, Feb 18, 2005 at 10:41:35PM +0300, Roman Kagan wrote:
> On Fri, Feb 18, 2005 at 10:33:50AM -0800, Patrick Mansfield wrote:
> > The block SG_IO handles the ioctls, but not devices without a SCSI upper
> > level driver (i.e. not tape, disk or cdrom).
> 
> Then it might make sense to explicitly list in sg.c the TYPE_* not
> matched by s[dtr].

sg can be used even if another scsi upper level driver is loaded.

fedora core tried something like that for a while, I'm not sure what
happened (besides it being really hard to do), and haven't noticed
anything different in recent (2.6.x) fc kernels.

> So these drivers can compete for the same device?  Are there
> deterministic rules on which one is supposed to win?  And is there a
> userspace interface to unbind one driver and bind another?  Otherwise it
> may mean that automatic module loading is inappropriate here at all...

No to all.

It is OK to autoload sg, it has special handling. Even though greg
probably hates it, it is much better than a /proc/bus/scsi ;-)

-- Patrick Mansfield


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click