Prev: kexec boot regression
Next: add Honeywell hmc5843 3-Axis Magnetometer (digital compass) driver.
From: Stefan Seyfried on 16 Dec 2009 07:20
On Wed, 16 Dec 2009 12:22:31 +0100
Josua Dietze <digidietze(a)draisberghof.de> 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."
--
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: John W. Linville on 16 Dec 2009 09:20
On Wed, Dec 16, 2009 at 01:14:52PM +0100, Stefan Seyfried wrote:
> On Wed, 16 Dec 2009 12:22:31 +0100
> Josua Dietze <digidietze(a)draisberghof.de> 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
linville(a)tuxdriver.com might be all we have. Be ready.
--
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: Dan Williams on 16 Dec 2009 11:50
On Wed, 2009-12-16 at 13:14 +0100, Stefan Seyfried wrote:
> On Wed, 16 Dec 2009 12:22:31 +0100
> Josua Dietze <digidietze(a)draisberghof.de> 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


--
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 16 Dec 2009 13:10
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: 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: Matthew Dharm on 16 Dec 2009 14:20
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 <digidietze(a)draisberghof.de> 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: mdharm-usb(a)one-eyed-alien.net
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: kexec boot regression
Next: add Honeywell hmc5843 3-Axis Magnetometer (digital compass) driver.