Prev: kexec boot regression
Next: add Honeywell hmc5843 3-Axis Magnetometer (digital compass) driver.
From: Josua Dietze on 15 Dec 2009 08:00
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Seyfried on 15 Dec 2009 09:10
Hi,

On Tue, 15 Dec 2009 13:31:13 +0100
Josua Dietze <digidietze(a)draisberghof.de> 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."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Josua Dietze on 15 Dec 2009 10:00
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 15 Dec 2009 10:20
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Dharm on 15 Dec 2009 13:10
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: mdharm-usb(a)one-eyed-alien.net
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
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: kexec boot regression
Next: add Honeywell hmc5843 3-Axis Magnetometer (digital compass) driver.