Prev: kexec boot regression
Next: add Honeywell hmc5843 3-Axis Magnetometer (digital compass) driver.
From: Oliver Neukum on 16 Dec 2009 05:30
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
--
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 16 Dec 2009 05:50
On Tue, 15 Dec 2009 10:03:00 -0800
Matthew Dharm <mdharm-kernel(a)one-eyed-alien.net> 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."
--
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 16 Dec 2009 06:30
Stefan Seyfried schrieb:

> On Tue, 15 Dec 2009 10:03:00 -0800
> Matthew Dharm <mdharm-kernel(a)one-eyed-alien.net> 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
--
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 16 Dec 2009 06:30
Am Mittwoch, 16. Dezember 2009 11:49:32 schrieb Stefan Seyfried:
> On Tue, 15 Dec 2009 10:03:00 -0800
> Matthew Dharm <mdharm-kernel(a)one-eyed-alien.net> 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
--
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 16 Dec 2009 06:50
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
--
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/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: kexec boot regression
Next: add Honeywell hmc5843 3-Axis Magnetometer (digital compass) driver.