Re: 2.6.16-rc4: known regressions

From: Al Viro <viro@ftp.linux.org.uk>
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Zeuthen <david@fubar.dk>, Kay Sievers <kay.sievers@suse.de>,
	Pekka J Enberg <penberg@cs.Helsinki.FI>, Greg KH <gregkh@suse.de>,
	Adrian Bunk <bunk@stusta.de>, Robert Love <rml@novell.com>,
	Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	John Stultz <johnstul@us.ibm.com>
Subject: Re: 2.6.16-rc4: known regressions
Date: Wed, 22 Feb 2006 18:04:23 +0000	[thread overview]
Message-ID: <20060222180423.GD27946@ftp.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.64.0602220915500.30245@g5.osdl.org>

On Wed, Feb 22, 2006 at 09:31:59AM -0800, Linus Torvalds wrote:
> Why the hell anybody would care about what the command transport type is, 
> when all that matters is that it's a block device, I don't understand. The 
> exact details of what kind of block device it is are totally secondary, 
> and shouldn't affect basic desktop behaviour.

Actually, it's not about transport, it's about command _set_.  So there
is legitimate userland code that would want to know that (especially since
a lot of external enclosures have incredibly brittle and crappy firmware
and go tits-up when they see anything they don't recognize), but
	a) the last thing that code wants is to have TYPE_RBC mislabeled
as TYPE_DISK and
	b) hal has nothing to do with that.

The only place where _transport_ enters the picture is that RBC is very common
in e.g. firewire-to-IDE bridges, so sbp2 had to deal with it somehow.  And
instead of teaching sd.c to deal with those (it's very easy) it went ahead
and just marked those as type 0 (disk).  Almost worked...