From: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
To: Josua Dietze <digidietze@draisberghof.de>
Cc: Stefan Seyfried <stefan.seyfried@googlemail.com>,
usb-storage@lists.one-eyed-alien.net, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Stefan Seyfried <seife@sphairon.com>
Subject: Re: [usb-storage] [PATCH] move eject code from zd1211rw to usb-storage
Date: Tue, 15 Dec 2009 09:58:15 -0800 [thread overview]
Message-ID: <20091215175815.GE16426@one-eyed-alien.net> (raw)
In-Reply-To: <4B27A443.6040908@draisberghof.de>
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
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: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
You were using cheat codes too. You guys suck.
-- Greg to General Studebaker
User Friendly, 12/16/1997
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2009-12-15 17:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-15 12:06 Stefan Seyfried
2009-12-15 12:31 ` Josua Dietze
2009-12-15 14:01 ` Stefan Seyfried
2009-12-15 14:59 ` Josua Dietze
2009-12-15 17:58 ` Matthew Dharm [this message]
2009-12-15 15:11 ` Oliver Neukum
2009-12-15 18:03 ` Matthew Dharm
2009-12-16 10:29 ` Oliver Neukum
2009-12-16 11:42 ` Josua Dietze
2009-12-16 18:03 ` Matthew Dharm
2009-12-16 19:50 ` Dan Williams
2009-12-16 19:52 ` Matthew Dharm
2009-12-17 13:02 ` Oliver Neukum
2009-12-17 13:33 ` Josua Dietze
2009-12-17 14:36 ` Oliver Neukum
2009-12-17 15:22 ` Josua Dietze
2009-12-17 18:21 ` Matthew Dharm
2009-12-16 10:49 ` Stefan Seyfried
2009-12-16 11:22 ` Josua Dietze
2009-12-16 12:14 ` Stefan Seyfried
2009-12-16 14:05 ` John W. Linville
2009-12-16 16:47 ` Dan Williams
2009-12-16 19:12 ` Matthew Dharm
2009-12-16 11:23 ` Oliver Neukum
2009-12-17 10:41 ` [usb-storage] " Daniel Drake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091215175815.GE16426@one-eyed-alien.net \
--to=mdharm-kernel@one-eyed-alien.net \
--cc=digidietze@draisberghof.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=seife@sphairon.com \
--cc=stefan.seyfried@googlemail.com \
--cc=usb-storage@lists.one-eyed-alien.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®