From: Bill Davidsen <davidsen@tmr.com>
To: Seewer Philippe <philippe.seewer@bfh.ch>
Cc: Jeff Garzik <jeff@garzik.org>, Gabor Gombas <gombasg@sztaki.hu>,
Adrian Bunk <bunk@stusta.de>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: /dev/sd*
Date: Fri, 18 Aug 2006 08:45:38 -0400 [thread overview]
Message-ID: <44E5B672.1010407@tmr.com> (raw)
In-Reply-To: <44E56804.1080906@bfh.ch>
Seewer Philippe wrote:
> Jan Engelhardt wrote:
>>>> In the process, we can rename the then-"generic disk" (scsi ide whatever)
>>>> back to "hd*" since that actually expands to Hard Disk.
>>>> (If I would have known a lot earlier about Linux I would have proposed
>>>> "id*" for the IDE disks.)
>>>>
>>> Actually that does make more sense then using disk. So I guess we're
>>> back to square one. Personally I don't think its that big of a deal, all
>>> you have to do is change fstab and grub or lilo. My main concern is for
>>> the less advanced Linux users.
>> Less advanced users should use the upgrade tools their distribution
>> provides.
>
> And personally I think less advanced users will be very happy with
> /dev/disk (or /dev/hd). No more confusion wether to user /dev/hdx or
> /dev/sdx or whatever!
>
But less clarity about which name goes with which device. I think it's
desirable to have a way for the user, the non-guru user, to find out
what meaningless name goes with which actual device. Currently finding
out what's on a system involves /proc/ide/hd*/model and /proc/scsi/scsi
to see what's attached and what names are being used.
For discussion I suggest /proc/ata/devices, a single flat file matching
a name meaningful to open() with a vendor string and whatever other info
is handy, like serial number and the like. If people are going to use
ATA that allows them to generate their own tools using familiar methods
like awk, sed, grep, perl, python or whatever. Having that information
in an inobvious format will really slow adoption by triggering the "it's
hard to use" or "I need to use all these new tools" responses.
And those responses are not limited to newbies, experienced users are
aware of the ratio of learning curve to functionality as well.
--
Bill Davidsen <davidsen@tmr.com>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
next prev parent reply other threads:[~2006-08-18 12:43 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 17:29 Merging libata PATA support into the base kernel Alan Cox
2006-08-09 20:16 ` Mark Lord
2006-08-10 6:13 ` Jeff Garzik
2006-08-10 6:20 ` Jan Engelhardt
2006-08-10 6:25 ` Olaf Hering
2006-08-11 15:47 ` Mark Lord
2006-08-15 13:31 ` Matthieu CASTET
2006-08-15 13:35 ` Tejun Heo
2006-08-15 14:01 ` Jeff Garzik
2006-08-09 21:21 ` /dev/sd* Adrian Bunk
2006-08-09 21:40 ` /dev/sd* Mark Lord
2006-08-09 22:01 ` /dev/sd* Alan Cox
2006-08-09 22:18 ` /dev/sd* Adrian Bunk
2006-08-10 1:44 ` /dev/sd* Alan Cox
2006-08-10 6:19 ` /dev/sd* Jan Engelhardt
2006-08-10 4:46 ` /dev/sd* Greg KH
2006-08-10 12:36 ` /dev/sd* Gabor Gombas
2006-08-10 12:37 ` /dev/sd* Jeff Garzik
2006-08-17 3:17 ` /dev/sd* Lee Trager
2006-08-17 7:58 ` /dev/sd* Michael Tokarev
2006-08-17 8:10 ` /dev/sd* Jan Engelhardt
2006-08-17 8:42 ` /dev/sd* Alan Cox
2006-08-17 8:01 ` /dev/sd* Jan Engelhardt
2006-08-17 8:29 ` /dev/sd* Lee Trager
2006-08-17 9:21 ` /dev/sd* Jan Engelhardt
2006-08-18 7:11 ` /dev/sd* Seewer Philippe
2006-08-18 8:52 ` /dev/sd* Jan Engelhardt
2006-08-18 9:19 ` /dev/sd* Tejun Heo
2006-08-18 14:57 ` /dev/sd* Alan Cox
2006-08-18 15:51 ` /dev/sd* Jan Engelhardt
2006-08-18 16:47 ` /dev/sd* Lee Revell
2006-08-18 17:02 ` /dev/sd* Alan Cox
2006-08-21 6:04 ` /dev/sd* Lee Trager
2006-08-21 6:17 ` /dev/sd* Jan Engelhardt
2006-08-18 12:45 ` Bill Davidsen [this message]
2006-08-18 15:48 ` /dev/sd* Jan Engelhardt
2006-08-19 0:15 ` /dev/sd* Gabor Gombas
2006-08-17 8:45 ` /dev/sd* Alan Cox
2006-08-10 6:24 ` Merging libata PATA support into the base kernel Andi Kleen
2006-08-10 12:37 ` Alan Cox
2006-08-10 12:20 ` Jens Axboe
2006-08-10 14:14 ` Alan Cox
2006-08-10 13:59 ` Jens Axboe
2006-08-10 15:54 ` Alan Cox
2006-08-10 19:02 ` Jason Lunz
2006-08-10 19:40 ` Rafael J. Wysocki
2006-08-17 3:26 ` Lee Trager
2006-08-17 9:18 ` Pavel Machek
2006-08-17 9:52 ` Alan Cox
2006-08-17 9:45 ` Pavel Machek
2006-08-17 11:51 ` Alan Cox
2006-08-18 3:38 ` Lee Trager
2006-08-18 3:57 ` Lee Trager
2006-08-18 16:01 ` Alan Cox
2006-08-18 19:22 ` Lee Trager
2006-08-18 20:50 ` Alan Cox
2006-08-19 8:17 ` Lee Trager
2006-08-21 0:44 ` Lee Trager
2006-08-10 19:47 ` Jens Axboe
2006-08-10 19:54 ` Rafael J. Wysocki
2006-08-11 15:48 ` Mark Lord
2006-08-10 22:27 ` Krzysztof Halasa
2006-08-24 3:31 ` Albert Lee
2006-08-24 3:38 ` Jeff Garzik
2006-08-24 4:13 ` Doug Maxey
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=44E5B672.1010407@tmr.com \
--to=davidsen@tmr.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bunk@stusta.de \
--cc=gombasg@sztaki.hu \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=philippe.seewer@bfh.ch \
/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;
as well as URLs for NNTP newsgroup(s).