From: Rob Landley <rob@landley.net>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
Jens Axboe <axboe@suse.de>,
Suparna Bhattacharya <suparna@in.ibm.com>,
Nick Piggin <piggin@cyberone.com.au>
Subject: Re: What still uses the block layer?
Date: Sun, 14 Oct 2007 18:45:44 -0500 [thread overview]
Message-ID: <200710141845.44750.rob@landley.net> (raw)
In-Reply-To: <1192400672.3351.56.camel@localhost.localdomain>
On Sunday 14 October 2007 5:24:32 pm James Bottomley wrote:
> On Sat, 2007-10-13 at 16:05 -0600, Matthew Wilcox wrote:
> > On Thu, Oct 11, 2007 at 08:11:21PM -0500, Rob Landley wrote:
> > > My impression from asking questions on the linux-scsi mailing list is
> > > that the scsi upper/middle/lower layers doesn't use the block layer
> > > described in Documentation/block/*.
> >
> > Entirely incorrect.
>
> OK, right ... could we please get a sense of decorum back on this list.
Did I reply to the insult?
> Rob, if you didn't ask your alleged questions in such a pejorative
> manner, we'd get a lot further
I'm not attempting to be pejorative.
I admit a certain amount of personal annoyance that once the SCSI layer
consumes a category of device (USB, SATA, PATA), they can often _only_ be
used by going through the SCSI midlayer. (This strikes me as analogous to
TCP/IP claiming ethernet and PPP devices so thoroughly that you can no longer
address them as eth1 or /dev/ttyS0.)
This has the annoying effect of bundling together different types of devices
and making device enumeration unnecessarily difficult: my laptop only has one
SATA hard drive and can't gain another without a soldering iron, but that
drive could move from /dev/sda to /dev/sdb if I reboot the system with a USB
key plugged in. This seems like a regrettable loss of orthogonality to me.
I remember back when /dev/usb0 and /dev/hda were separate devices that showed
up in /dev, but these days "it's SCSI" seems to trump "it's USB", "it's ATA",
or "it's SATA". (Even though none of those are actually SCSI hardware, they
just send a similar packet protocol across the wire.)
The fact that udev can theoretically unwind this hairball is not an excuse for
conflating different categories of devices in the first place. Avoiding an
unnecessary problem seems superior to trying to get udev to solve it. Note
that Ubuntu 7.04 solves it by sticking a UUID on every _partition_, and then
spinning up my external USB hard drive trying to find the root partition on a
reboot. Tell me how this can be considered progress:
> # /etc/fstab: static file system information.
> #
> # <file system> <mount point> <type> <options> <dump> <pass>
> proc /proc proc defaults 0 0
> # /dev/sda1
> UUID=04d1b984-bd65-46f1-9a77-c158cf4bed1b / ext3
defaults,errors=remount-ro,noatime 0 1
> # /dev/sda5
> UUID=cdf0936d-9f19-42c6-b131-9fefcf1321ef none swap sw
0 0
> /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
> UUID=86bbb512-ab7e-4a12-8618-1190f032c082 /boot ext3 defaults 0 0
Conflating categories of hardware that cannot easily be enumerated (USB) with
categories that can (the SATA hard drive in my laptop, of which there can be
only one) strikes me as a bad thing. Putting them in a common "scsi device
pool" within which they do not enumerate consistently is not something I
enjoy dealing with.
However, the response to my attempts to express this dissatisfaction on the
SCSI list a few months ago came too close to a flamewar for me to consider
continuing it productive. I'd still love to update the "2.4 scsi howto" and
corresponding sg howto, but lack the expertise. The SCSI layer really isn't
my area, and I was much happier back when I could avoid using it at all.
The question I was trying to ask _here_ was about the block layer. I seem not
to have asked it very well. Sorry 'bout that.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
next prev parent reply other threads:[~2007-10-14 23:46 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-12 1:11 What still uses the block layer? Rob Landley
2007-10-13 22:05 ` Matthew Wilcox
2007-10-14 5:54 ` David Newall
2007-10-14 17:46 ` Stefan Richter
2007-10-14 22:35 ` Tilman Schmidt
2007-10-14 23:36 ` Rob Landley
2007-10-15 1:23 ` Neil Brown
2007-10-15 5:44 ` Stefan Richter
2007-10-15 9:26 ` Rob Landley
2007-10-15 16:08 ` Matthew Wilcox
2007-10-15 17:10 ` Stefan Richter
2007-10-16 3:06 ` david
2007-10-16 5:56 ` Stefan Richter
2007-10-16 10:19 ` Alan Cox
2007-10-16 19:54 ` david
2007-10-16 19:54 ` Matthew Wilcox
2007-10-16 20:18 ` Stefan Richter
2007-10-16 20:34 ` Theodore Tso
2007-10-16 20:56 ` Stefan Richter
2007-10-16 20:55 ` david
2007-10-16 21:49 ` Alan Cox
2007-10-17 9:48 ` Gabor Gombas
2007-10-17 17:23 ` Stefan Richter
2007-10-17 21:04 ` david
2007-10-15 20:29 ` Wilfried Klaebe
2007-10-14 22:24 ` James Bottomley
2007-10-14 23:45 ` Rob Landley [this message]
2007-10-15 1:45 ` Theodore Tso
2007-10-15 8:04 ` Rob Landley
2007-10-15 9:06 ` Julian Calaby
2007-10-15 10:08 ` Rob Landley
2007-10-15 17:33 ` Greg KH
2007-10-16 2:54 ` david
2007-10-16 4:04 ` Matthew Wilcox
2007-10-16 4:11 ` Arjan van de Ven
2007-10-16 4:15 ` david
2007-10-16 4:21 ` Greg KH
2007-10-16 5:00 ` david
[not found] ` <646765f40710150327i78519a0fvaea7a83d5975b180@mail.gmail.com>
[not found] ` <200710151511.29748.rob@landley.net>
2007-10-15 23:49 ` Julian Calaby
2007-10-15 10:32 ` Loïc Grenié
2007-10-15 21:09 ` Rob Landley
2007-10-15 11:19 ` Neil Brown
2007-10-15 21:34 ` Rob Landley
2007-10-15 21:46 ` Jeff Garzik
2007-10-15 22:01 ` Alan Cox
2007-10-15 23:41 ` Neil Brown
2007-10-16 2:12 ` david
2007-10-15 13:21 ` Theodore Tso
2007-10-15 13:29 ` Alan Cox
2007-10-15 13:35 ` Theodore Tso
2007-10-15 17:44 ` Jeff Garzik
2007-10-15 14:46 ` Douglas Gilbert
2007-10-16 2:51 ` david
2007-10-15 13:37 ` OOM killer gripe (was Re: What still uses the block layer?) Nick Piggin
2007-10-15 9:52 ` Rob Landley
2007-10-15 15:08 ` Nick Piggin
2007-10-16 6:22 ` David Newall
2007-10-20 9:48 ` Pavel Machek
2007-10-15 11:40 ` Theodore Tso
2007-10-20 9:50 ` Pavel Machek
2007-10-16 3:55 ` Eric W. Biederman
2007-10-16 4:10 ` david
2007-10-16 4:45 ` Eric W. Biederman
2007-10-16 6:59 ` Nick Piggin
2007-10-16 4:38 ` Eric W. Biederman
2007-10-16 6:38 ` Rob Landley
2007-10-16 9:31 ` Eric W. Biederman
2007-10-16 10:28 ` Alan Cox
2007-10-16 23:59 ` Rob Landley
2007-10-16 7:34 ` Nick Piggin
2007-10-18 13:00 ` Rogier Wolff
2007-10-19 6:49 ` Rob Landley
2007-10-19 7:21 ` Rogier Wolff
2007-10-16 20:37 ` Andrew Morton
2007-10-17 5:34 ` What still uses the block layer? Valdis.Kletnieks
2007-10-17 6:07 ` david
2007-10-15 6:00 ` Greg KH
2007-10-15 8:36 ` Rob Landley
2007-10-15 13:08 ` Alan Cox
2007-10-15 14:00 ` Arjan van de Ven
2007-10-15 18:56 ` Matthew Garrett
2007-10-15 17:25 ` Greg KH
2007-10-15 18:00 ` Matthew Wilcox
2007-10-15 18:46 ` Jeff Garzik
2007-10-16 6:33 ` Stefan Richter
2007-10-17 23:43 ` Bill Davidsen
2007-10-15 22:54 ` Rob Landley
2007-10-15 8:52 ` Christoph Hellwig
2007-10-15 13:10 ` James Bottomley
2007-10-15 21:51 ` Rob Landley
2007-10-15 0:45 ` Luben Tuikov
2007-10-15 6:51 ` Rob Landley
2007-10-15 8:37 ` Luben Tuikov
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=200710141845.44750.rob@landley.net \
--to=rob@landley.net \
--cc=James.Bottomley@steeleye.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=piggin@cyberone.com.au \
--cc=suparna@in.ibm.com \
/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