LinuxLists.cc - [PATCH] move eject code from zd1211rw to usb-storage

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Stefan Seyfried schrieb:

> The USB ID claimed by zd1211rw for the fake storage device is
> also in use by other, non-zd1211rw devices (Sphairon Homelink
> 1202). Move the eject of these devices to where it belongs and
> where all the needed infrastructure already exists: usb-storage.

We can do the eject (as other mode switches) in userspace. Previous
discussions pointed into that direction.

And there is always the question of being able to access the "fake
CD-ROM" without hacking the kernel.

I'd like to see these devices removed from unusual_devs.h.

Josua Dietze

2009-12-15 14:01:47

by Stefan Seyfried

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Hi,

On Tue, 15 Dec 2009 13:31:13 +0100
Josua Dietze <[email protected]> wrote:

> Stefan Seyfried schrieb:
>
> > The USB ID claimed by zd1211rw for the fake storage device is
> > also in use by other, non-zd1211rw devices (Sphairon Homelink
> > 1202). Move the eject of these devices to where it belongs and
> > where all the needed infrastructure already exists: usb-storage.
>
> We can do the eject (as other mode switches) in userspace. Previous
> discussions pointed into that direction.

Well, the zd1211rw already did that, I wanted to fix that up and was
told to do it in usb-storage instead (which, looking at the diffstat,
seems like a good idea).

> And there is always the question of being able to access the "fake
> CD-ROM" without hacking the kernel.

I was thinking that I would be able to achieve that by echoing an
appropriate quirk into /sys/module/usb-storage/parameters/quirks,
however, I could not get it to *not* eject the device.
But given that there is already an "option_zero_cd" parameter in
usb-storage, it should be easy to massage this into a general "do not
eject virtual installer media" flag so that people are still able to
get the windows driver files off their devices should they need to do
so.

> I'd like to see these devices removed from unusual_devs.h.

I'd like them to work with one driver, not two (one in kernel and one
in userspace).

That's a fundamental difference in opinions, and I fear I'm not the one
who is going to decice how this will be handled ;)

Have fun,

Stefan
--
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

2009-12-15 14:59:26

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Stefan Seyfried schrieb:
> But given that there is already an "option_zero_cd" parameter in

> usb-storage, it should be easy to massage this into a general "do not
> eject virtual installer media" flag so that people are still able to
> get the windows driver files off their devices should they need to do
> so.
>
>> I'd like to see these devices removed from unusual_devs.h.
>
> I'd like them to work with one driver, not two (one in kernel and one
> in userspace).

The more basic arguments that prevailed at the last time such an
"eject" command was being considered for inclusion into usb-storage
were:

1. Userspace can obviously react a lot quicker than kernel space to
new or changed devices popping up.

2. Userspace works with older kernels immediately.

> That's a fundamental difference in opinions, and I fear I'm not the one
> who is going to decice how this will be handled ;)

Neither am I. But the number of known mode-switching USB devices is
now at around 50. New ones are arriving by the month or even week.

A decision to handle *all of them* in usb-storage would lead to the
disadvantages pointed out.

A decision to handle just *some of them* can hardly be made
plausible if there are no immediate technical reasons.

Oh, and in most cases (including your suggestion) there *are*
already two drivers necessary to make these devices work,
independent of where the switching is happening ...

> Have fun,

You too!

Josh
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot

2009-12-15 15:10:58

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Am Dienstag, 15. Dezember 2009 13:31:13 schrieb Josua Dietze:
> Stefan Seyfried schrieb:
>
> > The USB ID claimed by zd1211rw for the fake storage device is
> > also in use by other, non-zd1211rw devices (Sphairon Homelink
> > 1202). Move the eject of these devices to where it belongs and
> > where all the needed infrastructure already exists: usb-storage.
>
>
> We can do the eject (as other mode switches) in userspace. Previous
> discussions pointed into that direction.
>
> And there is always the question of being able to access the "fake
> CD-ROM" without hacking the kernel.
>
> I'd like to see these devices removed from unusual_devs.h.

This would break existing systems and thus introduce a regression.
We'd need to go through a feature removal process. For the time being
I see no alternative to Seife's patch, as we cannot introduce ejection
code to another wireless driver and need to support these devices.

Regards
Oliver

2009-12-15 17:58:37

[permalink] [raw]

Subject: Re: [usb-storage] [PATCH] move eject code from zd1211rw to usb-storage

On Tue, Dec 15, 2009 at 03:59:15PM +0100, Josua Dietze wrote:
> The more basic arguments that prevailed at the last time such an
> "eject" command was being considered for inclusion into usb-storage
> were:
>
> 1. Userspace can obviously react a lot quicker than kernel space to
> new or changed devices popping up.
>
> 2. Userspace works with older kernels immediately.
>
> > That's a fundamental difference in opinions, and I fear I'm not the one
> > who is going to decice how this will be handled ;)

I hate to say this, but I really consider this discussion to be closed.
Nobody has introduced a new argument in quite some time. This material,
where possible, belongs in userspace.

The primary reason userspace may *not* be apropriate is if the device needs
a non-standard eject command. Some devices need something very *close* to
an eject, but not quite an eject. Or, they have some goofy timing
restriction which makes the startup time for udev too long, or somesuch.

> Neither am I. But the number of known mode-switching USB devices is
> now at around 50. New ones are arriving by the month or even week.
>
> A decision to handle *all of them* in usb-storage would lead to the
> disadvantages pointed out.

The rate at which these devices are arriving makes this more than a
"disadvantage", it makes it practically impossible for management at the
kernel level.

> A decision to handle just *some of them* can hardly be made
> plausible if there are no immediate technical reasons.

The current decision is that all new devices, whenever possible, are to be
handled in userspace. Old devices currently handled by the kernel will be
removed on an "as we get around to it" schedule.

> Oh, and in most cases (including your suggestion) there *are*
> already two drivers necessary to make these devices work,
> independent of where the switching is happening ...

This is true. However, drivers such as usb-serial support dynamic addition
of IDs, so no kernel change is necessary.

Matt

--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver

You were using cheat codes too. You guys suck.
-- Greg to General Studebaker
User Friendly, 12/16/1997

Attachments:

(No filename) (2.20 kB)
(No filename) (189.00 B)
Download all attachments

2009-12-15 18:03:52

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Tue, Dec 15, 2009 at 04:11:08PM +0100, Oliver Neukum wrote:
> Am Dienstag, 15. Dezember 2009 13:31:13 schrieb Josua Dietze:
> > Stefan Seyfried schrieb:
> >
> > > The USB ID claimed by zd1211rw for the fake storage device is
> > > also in use by other, non-zd1211rw devices (Sphairon Homelink
> > > 1202). Move the eject of these devices to where it belongs and
> > > where all the needed infrastructure already exists: usb-storage.
> >
> >
> > We can do the eject (as other mode switches) in userspace. Previous
> > discussions pointed into that direction.
> >
> > And there is always the question of being able to access the "fake
> > CD-ROM" without hacking the kernel.
> >
> > I'd like to see these devices removed from unusual_devs.h.
>
> This would break existing systems and thus introduce a regression.
> We'd need to go through a feature removal process. For the time being
> I see no alternative to Seife's patch, as we cannot introduce ejection
> code to another wireless driver and need to support these devices.

The right answer here is neither to move the eject code nor to introduce
more of it. New devices should be supported via userspace.

Matt

--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver

A: The most ironic oxymoron wins ...
DP: "Microsoft Works"
A: Uh, okay, you win.
-- A.J. & Dust Puppy
User Friendly, 1/18/1998

Attachments:

(No filename) (1.40 kB)
(No filename) (189.00 B)
Download all attachments

2009-12-16 10:29:18

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Am Dienstag, 15. Dezember 2009 19:03:00 schrieb Matthew Dharm:
> > This would break existing systems and thus introduce a regression.
> > We'd need to go through a feature removal process. For the time being
> > I see no alternative to Seife's patch, as we cannot introduce ejection
> > code to another wireless driver and need to support these devices.
>
> The right answer here is neither to move the eject code nor to introduce
> more of it. New devices should be supported via userspace.

Usually I would agree, but in this case the vendor reused IDs.
The legacy kernel space switcher and user space would race.

Regards
Oliver

2009-12-16 10:49:42

by Stefan Seyfried

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Tue, 15 Dec 2009 10:03:00 -0800
Matthew Dharm <[email protected]> wrote:
> The right answer here is neither to move the eject code nor to introduce
> more of it. New devices should be supported via userspace.

Can somebody point me to the "userspace" that is meant here?
Preferably some code that can be built actually?
--
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

2009-12-16 11:22:49

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Stefan Seyfried schrieb:

> On Tue, 15 Dec 2009 10:03:00 -0800
> Matthew Dharm <[email protected]> wrote:
>> The right answer here is neither to move the eject code nor to introduce
>> more of it. New devices should be supported via userspace.
>
> Can somebody point me to the "userspace" that is meant here?
> Preferably some code that can be built actually?

If the "eject" from SCSI tools does not work, "usb_modeswitch" can
send customized bulk messages to devices.

http://www.draisberghof.de/usb_modeswitch/

Josh
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot

2009-12-16 11:23:12

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Am Mittwoch, 16. Dezember 2009 11:49:32 schrieb Stefan Seyfried:
> On Tue, 15 Dec 2009 10:03:00 -0800
> Matthew Dharm <[email protected]> wrote:
> > The right answer here is neither to move the eject code nor to introduce
> > more of it. New devices should be supported via userspace.
>
> Can somebody point me to the "userspace" that is meant here?
> Preferably some code that can be built actually?

Sure:
http://www.draisberghof.de/usb_modeswitch/

HTH
Oliver

2009-12-16 11:42:33

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Oliver Neukum schrieb:

> Am Dienstag, 15. Dezember 2009 19:03:00 schrieb Matthew Dharm:
>>> This would break existing systems and thus introduce a regression.
>>> We'd need to go through a feature removal process. For the time being
>>> I see no alternative to Seife's patch, as we cannot introduce ejection
>>> code to another wireless driver and need to support these devices.
>> The right answer here is neither to move the eject code nor to introduce
>> more of it. New devices should be supported via userspace.
>
> Usually I would agree, but in this case the vendor reused IDs.
> The legacy kernel space switcher and user space would race.

User space can test for device/interface class (which will
supposedly change even if the IDs do not) and base it's actions on
that. It was done before.

Apart from that issue, I can see that there is a problem with a
device that has worked without "external" handling up to now.
Unfortunately, I can't think about a clean solution.

Josua
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot

2009-12-16 12:15:00

by Stefan Seyfried

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Wed, 16 Dec 2009 12:22:31 +0100
Josua Dietze <[email protected]> wrote:

> Stefan Seyfried schrieb:
> > Preferably some code that can be built actually?
>
> If the "eject" from SCSI tools does not work, "usb_modeswitch" can
> send customized bulk messages to devices.

for my device, eject seems to be enough, so I'll be trying to get
this into udev.

> http://www.draisberghof.de/usb_modeswitch/

Unfortunately it cannot be built with current libusb and once you
compile it without warnings turned off (which is the default!), you
probably don't want to run it anymore ;)

Having code in kernel has one major advantage: it gets reviewed much
more thoroughly.
--
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

2009-12-16 14:15:31

by John W. Linville

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Wed, Dec 16, 2009 at 01:14:52PM +0100, Stefan Seyfried wrote:
> On Wed, 16 Dec 2009 12:22:31 +0100
> Josua Dietze <[email protected]> wrote:
>
> > Stefan Seyfried schrieb:
> > > Preferably some code that can be built actually?
> >
> > If the "eject" from SCSI tools does not work, "usb_modeswitch" can
> > send customized bulk messages to devices.
>
> for my device, eject seems to be enough, so I'll be trying to get
> this into udev.

When you do that any chance you could account for zd1211rw too? :-)

--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.

2009-12-16 16:48:24

by Dan Williams

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Wed, 2009-12-16 at 13:14 +0100, Stefan Seyfried wrote:
> On Wed, 16 Dec 2009 12:22:31 +0100
> Josua Dietze <[email protected]> wrote:
>
> > Stefan Seyfried schrieb:
> > > Preferably some code that can be built actually?
> >
> > If the "eject" from SCSI tools does not work, "usb_modeswitch" can
> > send customized bulk messages to devices.
>
> for my device, eject seems to be enough, so I'll be trying to get
> this into udev.
>
> > http://www.draisberghof.de/usb_modeswitch/
>
> Unfortunately it cannot be built with current libusb and once you
> compile it without warnings turned off (which is the default!), you
> probably don't want to run it anymore ;)

At this point, however, usb_modeswitch is the correct place to put eject
code for all devices. I wouldn't put this code into udev; I'd put it
into usb_modeswitch instead, since usb_modeswitch is (a) the de-facto
standard, (b) has the most users, and (c) has the most devices. Yes, it
has problems, but at this point we should fix those problems instead of
creating 5 different eject tools.

Dan

2009-12-16 18:05:35

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Wed, Dec 16, 2009 at 11:29:27AM +0100, Oliver Neukum wrote:
> Am Dienstag, 15. Dezember 2009 19:03:00 schrieb Matthew Dharm:
> > > This would break existing systems and thus introduce a regression.
> > > We'd need to go through a feature removal process. For the time being
> > > I see no alternative to Seife's patch, as we cannot introduce ejection
> > > code to another wireless driver and need to support these devices.
> >
> > The right answer here is neither to move the eject code nor to introduce
> > more of it. New devices should be supported via userspace.
>
> Usually I would agree, but in this case the vendor reused IDs.
> The legacy kernel space switcher and user space would race.

So, let me see if I understand this... we have two devices that use the
same IDs, and get mode-switched the same way, but need different
post-switch drivers?

If this is the case, then the only reasonable answer to is to push the
modeswitch code for both into udev and out of the kernel. It will take
longer to support the new device that way (since we need to wait until udev
is updated and then remove kernel support), but that's what a vendor gets
for re-using IDs.

Matt

--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver

What, are you one of those Microsoft-bashing Linux freaks?
-- Customer to Greg
User Friendly, 2/10/1999

Attachments:

(No filename) (1.38 kB)
(No filename) (189.00 B)
Download all attachments

2009-12-16 19:13:25

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Wed, Dec 16, 2009 at 08:47:17AM -0800, Dan Williams wrote:
> On Wed, 2009-12-16 at 13:14 +0100, Stefan Seyfried wrote:
> > On Wed, 16 Dec 2009 12:22:31 +0100
> > Josua Dietze <[email protected]> wrote:
> >
> > > Stefan Seyfried schrieb:
> > > > Preferably some code that can be built actually?
> > >
> > > If the "eject" from SCSI tools does not work, "usb_modeswitch" can
> > > send customized bulk messages to devices.
> >
> > for my device, eject seems to be enough, so I'll be trying to get
> > this into udev.
> >
> > > http://www.draisberghof.de/usb_modeswitch/
> >
> > Unfortunately it cannot be built with current libusb and once you
> > compile it without warnings turned off (which is the default!), you
> > probably don't want to run it anymore ;)
>
> At this point, however, usb_modeswitch is the correct place to put eject
> code for all devices. I wouldn't put this code into udev; I'd put it
> into usb_modeswitch instead, since usb_modeswitch is (a) the de-facto
> standard, (b) has the most users, and (c) has the most devices. Yes, it
> has problems, but at this point we should fix those problems instead of
> creating 5 different eject tools.

udev just calls either usb_modeswitch or eject at the hotplug event. So,
you always need an update to the udev database, regardless.

The choice between using usb_modeswitch or eject is really one of "does the
standard eject work properly" or not. If not, add the code to
usb_modeswitch. Tho, if the usb_modeswitch maintainers want to carry
around a duplicate set of 'eject' code, that's really up to them.

Matt

--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver

Would you mind not using our Web server? We're trying to have a game of
Quake here.
-- Greg
User Friendly, 5/11/1998

Attachments:

(No filename) (1.81 kB)
(No filename) (189.00 B)
Download all attachments

2009-12-16 19:51:53

by Dan Williams

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Wed, 2009-12-16 at 10:03 -0800, Matthew Dharm wrote:
> On Wed, Dec 16, 2009 at 11:29:27AM +0100, Oliver Neukum wrote:
> > Am Dienstag, 15. Dezember 2009 19:03:00 schrieb Matthew Dharm:
> > > > This would break existing systems and thus introduce a regression.
> > > > We'd need to go through a feature removal process. For the time being
> > > > I see no alternative to Seife's patch, as we cannot introduce ejection
> > > > code to another wireless driver and need to support these devices.
> > >
> > > The right answer here is neither to move the eject code nor to introduce
> > > more of it. New devices should be supported via userspace.
> >
> > Usually I would agree, but in this case the vendor reused IDs.
> > The legacy kernel space switcher and user space would race.
>
> So, let me see if I understand this... we have two devices that use the
> same IDs, and get mode-switched the same way, but need different
> post-switch drivers?
>
> If this is the case, then the only reasonable answer to is to push the
> modeswitch code for both into udev and out of the kernel. It will take

you mean usb_modeswitch, not udev actually.

> longer to support the new device that way (since we need to wait until udev
> is updated and then remove kernel support), but that's what a vendor gets
> for re-using IDs.
>
> Matt
>

2009-12-16 19:53:36

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

On Wed, Dec 16, 2009 at 11:50:48AM -0800, Dan Williams wrote:
> On Wed, 2009-12-16 at 10:03 -0800, Matthew Dharm wrote:
> > On Wed, Dec 16, 2009 at 11:29:27AM +0100, Oliver Neukum wrote:
> > > Am Dienstag, 15. Dezember 2009 19:03:00 schrieb Matthew Dharm:
> > > > > This would break existing systems and thus introduce a regression.
> > > > > We'd need to go through a feature removal process. For the time being
> > > > > I see no alternative to Seife's patch, as we cannot introduce ejection
> > > > > code to another wireless driver and need to support these devices.
> > > >
> > > > The right answer here is neither to move the eject code nor to introduce
> > > > more of it. New devices should be supported via userspace.
> > >
> > > Usually I would agree, but in this case the vendor reused IDs.
> > > The legacy kernel space switcher and user space would race.
> >
> > So, let me see if I understand this... we have two devices that use the
> > same IDs, and get mode-switched the same way, but need different
> > post-switch drivers?
> >
> > If this is the case, then the only reasonable answer to is to push the
> > modeswitch code for both into udev and out of the kernel. It will take
>
> you mean usb_modeswitch, not udev actually.

That is correct; I had mis-typed. Tho, the actual implementation is udev
calling usb_modeswitch and/or eject.

Matt

--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver

What, are you one of those Microsoft-bashing Linux freaks?
-- Customer to Greg
User Friendly, 2/10/1999

Attachments:

(No filename) (1.57 kB)
(No filename) (189.00 B)
Download all attachments

2009-12-17 10:56:14

by Daniel Drake

[permalink] [raw]

Subject: Re: [usb-storage] [PATCH] move eject code from zd1211rw to usb-storage

El 15/12/09 12:31, Josua Dietze escribi?:
> Stefan Seyfried schrieb:
>
>> The USB ID claimed by zd1211rw for the fake storage device is
>> also in use by other, non-zd1211rw devices (Sphairon Homelink
>> 1202). Move the eject of these devices to where it belongs and
>> where all the needed infrastructure already exists: usb-storage.
>
>
> We can do the eject (as other mode switches) in userspace. Previous
> discussions pointed into that direction.

When I originally wrote this code this wasn't as easy as you might think
- the virtual CD device seems to be very quirky, and utterly confused
Linux to the point where it didn't even create a device node. Maybe
linux is more flexible these days though.

Daniel

2009-12-17 13:02:31

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Am Mittwoch, 16. Dezember 2009 20:52:58 schrieb Matthew Dharm:
> > > If this is the case, then the only reasonable answer to is to push the
> > > modeswitch code for both into udev and out of the kernel. It will take
> >
> > you mean usb_modeswitch, not udev actually.
>
> That is correct; I had mis-typed. Tho, the actual implementation is udev
> calling usb_modeswitch and/or eject.

Can storage tell the devices apart so that it knows which ones to leave
to the kernel solution and which devices to accept so that udev can
issue an eject command?

Regards
Oliver

2009-12-17 13:33:19

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Oliver Neukum schrieb:

> Am Mittwoch, 16. Dezember 2009 20:52:58 schrieb Matthew Dharm:
>>>> If this is the case, then the only reasonable answer to is to push the
>>>> modeswitch code for both into udev and out of the kernel. It will take
>>> you mean usb_modeswitch, not udev actually.
>> That is correct; I had mis-typed. Tho, the actual implementation is udev
>> calling usb_modeswitch and/or eject.
>
> Can storage tell the devices apart so that it knows which ones to leave
> to the kernel solution and which devices to accept so that udev can
> issue an eject command?

If you are thinking about the two specific devices at hand there is
no need to tell them apart. Same IDs on plugin, same switching
procedure, different IDs on return, different drivers take care.

If you are thinking generally, there is already a case when:
same IDs on plugin, different switching procedures.
See "option_ms.c"; the solution was to check for SCSI ID strings and
only act if there's a match. I filed this patch to enable userspace
handling for a different device with the same IDs.

This is also the way usb_modeswitch (via wrapping script) is
handling ambiguities right now.
(BTW, the next version has no more compiler warnings. No big deal.)

Cheers,
Josua

2009-12-17 14:36:38

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Am Donnerstag, 17. Dezember 2009 14:33:06 schrieb Josua Dietze:
> > Can storage tell the devices apart so that it knows which ones to leave
> > to the kernel solution and which devices to accept so that udev can
> > issue an eject command?
>
> If you are thinking about the two specific devices at hand there is
> no need to tell them apart. Same IDs on plugin, same switching
> procedure, different IDs on return, different drivers take care.

How do you issue an eject command without a /dev/sgX node?

Regards
Oliver

2009-12-17 15:23:14

[permalink] [raw]

Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage

Oliver Neukum schrieb:

> Am Donnerstag, 17. Dezember 2009 14:33:06 schrieb Josua Dietze:
>> If you are thinking about the two specific devices at hand
>> there is no need to tell them apart. Same IDs on plugin, same
>> switching procedure, different IDs on return, different drivers
>> take care.
>
> How do you issue an eject command without a /dev/sgX node?

You're thinking of handling one device in the kernel and the other
one (same ID, same switching procedure) on the outside?

Well, as I said, you'd have to "filter" additional data (USB
model/manufacturer etc., SCSI_INQUIRY strings). But obviously you
would need to have the data of the two devices to note the differences.

BTW, usb_modeswitch does not need SCSI device nodes, because it
talks to the USB device directly via the bulk message layer once the
endpoints are up. Slight advantage over "eject".

Cheers,
Josua

2009-12-17 18:22:31