Device naming.

Device naming.

[Alan Grimes]

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.

Re: Device naming.

[Karl O. Pinc]

On 03/11/2010 09:37:13 AM, Alan Grimes wrote:

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

It's not clear to me that that's really what the administrator is
interested in.  The truly essential fact, at least when it comes
to storage devices which is what you seem to be talking about, is what
data is on the device.

> 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. =\

Hence you use a uuid or a fs disk label, which has nothing
to do with what kind of device it is but identifies what's
on the device.   You can even "move the data" (TM)
to a completely different device and not have to 
adjust anything.

If you find there to be "lack of documentation" on the subject
you are looking in the wrong places.  Some might even assume
that you are not trying very hard.  At the very least
it would be politic to ask about where to find documentation
before complaining that there isn't any.  A lot of folks
may decide to simply ignore you, which is not a good way
to get help or try to influence design decisions.

I am in no way an official spokesperson.  I am simply
trying to relate to you what I've found to be true.
Uninformed complaining will be ignored so please decide
what you want to get by emailing and be more focused
in the future.

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: Device naming.

[Greg KH]

On Thu, Mar 11, 2010 at 10:37:13AM -0500, Alan Grimes wrote:
> 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!!!

You must have never done this in the past.  USB flash disks have been
named /dev/sda since the 2.2 kernel days (back in 1999).  They have
never changed naming schemes here, because USB storage devices are
really scsi devices at the protocol level.

As others have pointed out, use /dev/disk/by-label/ and all will be
fine.  That is what it was created for, and is what the distros use it
for.

If you are using a distro that does not allow you to easily manage these
disk names in a way you find acceptable, then I suggest you change your
distro as there are many that handle this quite well.

good luck,

greg k-h

device naming

[Andrew Kohlsmith (Mailing List Account)]

Is there a definitive guide to device naming with ALSA? I'm trying to use a 
single device for simultaneous capture and playback but opening different 
device names gives different results and I'm trying to determine which is the 
best to use.

aplay -L output gives front, surround40, surround41, surround50, surround51, 
null and pulse.

Trying to register a playback callback using "pulse" gives a "function not 
implemented" error, although I can open and set all the parameters I need 
(8kHz, 2 channels, 20ms buffers).

I get the same result with "default".  If I use "plughw:0,0" I can capture and 
play audio, but the driver (intel HDA) seems to be very prone to either not 
calling either the playback or capture callback, or throwing an xrun and not 
being able to recover.  This is an otherwise idle core2 machine running Ubuntu 
9.10. Playing with nice or ionice does not seem to affect this "brittleness."

I do not have an ~/.asoundrc, nor do I have anything related to asound in 
/etc.  Moving pulseaudio out of the way doesn't seem to do anything either.

Is there a definitive list of devices and their device filenames so I can stop 
guessing?  /proc/asound/cards just shows card 0 as an Intel HDA, and 
/proc/asound/devices shows the following:

$ cat /proc/asound/devices
  2:        : timer
  3:        : sequencer
  4: [ 0- 2]: digital audio capture
  5: [ 0- 0]: digital audio playback
  6: [ 0- 0]: digital audio capture
  7: [ 0- 1]: hardware dependent
  8: [ 0- 0]: hardware dependent
  9: [ 0]   : control

(0-0 is the only device showing both playback and capture, which is why I'm 
using it, but how do I know that plughw is the correct device filename? I just 
guessed at it due to previous experience trying to get bt audio working with 
ALSA.)

I'm sure I'm doing something incredibly stupid, but I can't seem to find out 
what it is.

-A.