Prev: kexec boot regression
Next: add Honeywell hmc5843 3-Axis Magnetometer (digital compass) driver.
From: Matthew Dharm on 16 Dec 2009 15:00
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: mdharm-usb(a)one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver

What, are you one of those Microsoft-bashing Linux freaks?
-- Customer to Greg
User Friendly, 2/10/1999
From: Dan Williams on 16 Dec 2009 15:00
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
>

--
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 17 Dec 2009 08:10
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
--
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 17 Dec 2009 08:40
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
--
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 17 Dec 2009 09:40
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
--
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.