linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Grimes <agrimes@speakeasy.net>
To: linux-hotplug@vger.kernel.org
Subject: Device naming.
Date: Thu, 11 Mar 2010 15:37:13 +0000	[thread overview]
Message-ID: <4B990E29.5080206@speakeasy.net> (raw)

Due to the lack of documentation on the subject, I have been forced to
do my own investigation and make my own conclusions regarding recent
changes to the naming of devices on linux.

My verdict is that it's the latest example in a chain of spectacularly
bad design decisions made by linux developers (Penguins) in the past
year or two.

Here's why.

The purpose of the /dev path is to allow administrators to access
devices attached to their systems. Therefore it is sensible for each
device handle to expose to the administrator essential facts such as
what type of device it is, which controller it is attached to, the
position number on that controller and, finally, the identifier of any
virtual devices which might benefit from being treated separately.

Furthermore the administrator doesn't have the slightest interest in
what driver is behind the device, that is irrelevant information that
should be hidden.

Minix, IIRC did this correctly. Each name has a very easy to understand
encoding.

The old scheme on Linux did an adequate job of this too. The first two
letters indicated what technology it was, the third letter was a mix of
controller and position information, and the number indicated the
virtual device being referenced.

I did an experiment the other day which involved plugging a USB thumb
drive into the server. To my horror, the operating system assigned it
/dev/sda. The Penguins had gone and *intentionally* designed a namespace
collision between all possible storage solutions that might be attached
to the computer!!!

This is insane. How do I know what drives are which when I go to write
an /etc/fstab? If I make any changes to the controllers in the system,
designations of existing drives are sure to change. =\

I am aware of /dev/disk so don't flame me about THAT, I have examined it
closely and have not found any way to make use of it because it is not
possible to reliably predict how a new drive would appear there.

On my existing system that is still running an old linux kernel, the
device ID of my boot drive is:

ata-ST380013A_5JVA01L2

Which is correct...

But the device id of my data drive is:

scsi-SATA_WDC_WD3200AAKS-_WD-WCAT11129455

Which is wrong because I don't own any SCSI hardware. It should be:

SATA-WDC_WD3200AAKS-_WD-WCAT11129455

WTF??? My data drive has two entries in there, the other is:

ata-WDC_WD3200AAKS-00B3A0_WD-WCAT11129455

Which is not that inaccurate because SATA is a form of ATA, however it
is useful to be able to distinguish the two so you know where your new
drive will appear.


-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.


             reply	other threads:[~2010-03-11 15:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-11 15:37 Alan Grimes [this message]
2010-03-11 16:19 ` Device naming Karl O. Pinc
2010-03-11 18:23 ` Greg KH

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=4B990E29.5080206@speakeasy.net \
    --to=agrimes@speakeasy.net \
    --cc=linux-hotplug@vger.kernel.org \
    /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).