[Novalug] Old Vs New was: Re: Kernel configuration for opticaldrive.

[Bryan J. Smith]

First off, I work on my Blackberry and remotely quite a bit.  I wanted to
confirm all the different subsystems that are typical in nearly _all_ systems.
When I'm actually on my main notebook, it's much easier to put everything
together.  Understand I'm pulling 100% from memory in most posts.

[ Despite the insistence of many people to assume I'm using Google. ]


Second, I'd glad you "know better" than the kernel developers.  I mean,
are you _really_ serious?  Why should kernel developers duplicate things
when the code is common, and the devices act the same?  It's kinda self-
defeating, all for an arbitrary approach that _so_few_ actually want.

It's legacy.

Third, the assignment of storage devices at boot have a major dependency
on the firmware of the PC.  So that's an issue _regardless_ of what device
assignment Linux makes.  Yes, I wish the PC has all of the firmware inter-
assignment goodies of non-PC, RISC/UNIX platforms.  But it doesn't, and
that's a PITA in general.

If you want to name it _anything_ you want, take the 5 minutes to learn udev.
There has been enough links posted to this information in this thread alone
to fill several volumes now.  Honestly.  Drop the "old dog" views and learn.

If not, then don't open the hood and pull the wires.  ;)

Lastly, your assumptions on position assignment, UUIDs and what not are
 _dead_wrong_.  Sorry. USB allows 127 dynamically assigned devices
(in reality, it's usually only 1 without devices conflicting -- at least for the
software block drivers), AHCI allows 31, SAS is a multi-level assignment
approach (long story), etc...

SATA is _not_ and has _never_ been master/slave, or even traditional ATA
based.  Early SATA designs used ATA ASICs and a legacy mode for
transition.  But there is this gross assumption that SATA is like ATA when it
comes to assignment, and it has _never_ been other than legacy modes.
AHCI allows up to 31 devices.  AT Attachment itself is not ESDI either, even
if the legacy assumptions were made (and DMA modes were _never_
designed for master/slave -- that was PIO emulation, largely Western
Digital's Enhanced IDE -- yes, it's their trademark, not generic/universal ;).

And SCSI-2 protocols run over countless mediums of different assignments,
Fibre-Channel and Serial Attached.  The narrow/wide assumptions on only
7 and 15 assignments are so '90s.  It's the 21st century, let alone 2010.

Again, drop the "old dog" views and learn -- or don't open the hood and
pull wires.  ;)

Man that dead horse is flying again!  I think I've more than proved my point.



----- Original Message ----
From: Alan Grimes <agrimes at speakeasy.net>

Bryan J Smith wrote:
> Again, today's storage includes:  
> - [S]ATA -- Dumb, Serial or Parallel Hardware Block AT Attachment (ATA)
> - SCSI -- Queued, Block Small Computer Systems Interface (SCSI)
> - AHCI -- Queued, Block Serial AT Attachment ("modern" SATA)  
<<<<< NEW INFORMATION  -- YAY!!! =P

> I think the dead horse has been steadily moving from all the beatings it
> has been taking.  ;)  This is PC-level stuff.  Linux is just trying to
> cope.  Between the 2TiB (2.2TB) limitations of legacy BIOS/DOS disk
> labels (aka "Partition Table") and the on-going, "ATA is ATA, SCSI is
> SCSI," people here are just proving why they don't learn.

That just means that the kernel should have these sections in it's
device configuration;

ATA (ide etc...)
AHCI
SCSI
Device Protocols (CD-ROM, tape, etc...)

How the code is cross-linked internally is irrelevant.

And, naturally, in /dev there should be separate namespaces for each of
the connectors you listed such that the first device connected to the
first port of any such connector will *ALWAYS*, without fail or
exception, receive the first designation.

In my case, if I own exactly 1 PATA drive, and I connect it to the first
port of the first IDE controller, under no circumstances will it receive
the designation sdb.

Furthermore I am concerned about the designation sdb again because my
SATA controller has two ports, 1 internal and 1 external. I think
hardware-wise, the first port is the internal, and the second is the
internal. Therefore I would expect sda to be not-connected and my SATA
data drive to be sdb. This is not the case. I don't know what the kernel
would do if I actually installed a drive to that external port. Would I
have to rewrite my /etc/fstab again? Obviously the new setup is
profoundly problematic in ways that Bryan refuses to admit.

As to the suggestion that I use uuids, My point on that front is that
uuids (on desktop systems), are a solution to a problem that is entirely
artificial created wholly by the unreliable naming scheme (or rather
lack of a naming scheme) for the block devices.

My point on the dynamically added device front is that only USB lacks
(AFAIK) positional device addressing. -- Ie no port is the "first"
"second", "third" etc... So for namespaces of ATA, AHCI, and SCSI
devices, a naming scheme that numbers devices by the port they are
attached to is entirely practical and unambiguously desirable because it
prevents the user from having to resort to mounting partitions by uuid
which can't be predicted ahead of time and are extremely cumbersome (and
error prone!) to work with from the command line which doesn't have
cut-and-paste. (Naturally, the drives must be set up before x-'doze can
be installed).