lkml.org 
[lkml]   [1997]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NEW unified parallel port IDE subsystem
On Sun, 14 Dec 1997, Grant R. Guenther wrote:
> > Like I said a couple of days ago
>
> Did you ask me this question ? I wasn't aware that this was being
> debated.

Umm... no, I just put it in a mail with a bunch of other stuff I saw in the
2.1.71 (?) pach; nobody replied to it.

> > why aren't these handled like other IDE devices,
> > that is to say, mixing all ATAPI/IDE devices in one set of device-files?
> > This makes much more sense to me then segregating different types of
> > devices, as (I assume) you can plug any IDE/ATAPI device into any one
> > of these adapters.
> > [...]
>
> It's not self evident to me that one naming convention is better than
> another. Why does it make more sense to you to call something a
> hard-disk, even if it isn't ?

It dosn't particually. It just makes more sense to name the devices in a
self-consistent, deterministic, wetware-grokable manner. I think that
saying "the slave on the third parallel-port IDE controller" (it would be
even better if we could say "parallel-ports/2/IDE/slave") makes more sense
then "the third cd-rom attached to a parallel-port IDE controller".

It would be better if we would have a procish system wherein everything is
defined both by the n-th within a collection (the 3rd IDE controller in the
system), and in terms of connection (the device connected to the 2nd
parallel port), and in terms of name (for those devices that know their own
name (hard drives do, partitions don't, for example)). (Or, of cource, any
combonation, using symlinked directories (not hardlinked (nor two device
files with the same major/minor), not having a cannonical way of refering to
a device seems very sticky)). However, I don't expect that to happen till
we redesign everything to work with a wider dev_t.

Note that I listed those three ways of refering to devices in order of
preferince. Saying the 3rd parallel-port IDE CD-ROM seems even worse then
the device on the primary channel of the 5th parallel-port IDE controller.
Even better would be the 8th IDE controller's primary channel (and better
for purposes of code-reuse, I should suspect).

> The standard IDE drivers use the naming
> conventions that they do because there are a small number of physical
> slots in which a device can be located (primary/secondary, master/slave).
Not really - you should be able to have any number of IDE interfaces in a
system and expect Linux to be able to use all of them (there is currently a
limit of three (each with two channels)).

> The parallel port IDE drivers support chains of adapters on
> the same port, up to six different ports, master or slave on each
> _adapter_, as well as LUNs - all of which adds up to something much
> more like the SCSI subsystem, on which the PARIDE design is loosely
> based.
Cool. But I still think that "the eighth IDE controller's secondary
device's third LUN" is far better then "the third CD-ROM connected to a
parallel-port IDE controller". There is a simple rule here: the same peice
of hardware should have the same major no matter where you put it. The
device files reference IDE-devices, not IDE-controllers.


> --------------------------------------------------------------------------
> Grant R. Guenther grant@torque.net
> --------------------------------------------------------------------------

-=- James Mastros

--
When the annals of distributed computing are written, and the name 'Bovine'
appears in there, I can say "Hey, I was a part of that, I checked .0012% of
the keyspace".
-=- Brian Wilson <wilsonb@mindspring.net>
Go to www.distributed.net before I come make you!


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.028 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site