linux-kernel - Re: [usb-storage] [PATCH] move eject code from zd1211rw to usb-storage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Dec 2009 09:58:15 -0800
From:	Matthew Dharm <mdharm-kernel@...-eyed-alien.net>
To:	Josua Dietze <digidietze@...isberghof.de>
Cc:	Stefan Seyfried <stefan.seyfried@...glemail.com>,
	usb-storage@...ts.one-eyed-alien.net, linux-usb@...r.kernel.org,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	Stefan Seyfried <seife@...airon.com>
Subject: Re: [usb-storage] [PATCH] move eject code from zd1211rw to usb-storage

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@...-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

Content of type "application/pgp-signature" skipped