[lkml]   [1999]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Devfs, was Re: Migrating to larger numbers
> > > > /dev/parport/cd
> > > > /dev/pcmcia/cd
> > > > /dev/usb/cd
> > > >
> > > > Doesn't look like the right way to me.
> >
> > <serious replies only, I don't want flames for asking a question>
> > Why bother seperating it out by interface? I'm just asking. It
> > seems it would be better to go by controller/bus/id/lun[/partition]
> > for all devices that connect to scsi, ide, usb, pcmcia, parport,
> > etc. It could get ugly having all of them in the same machine, or
> > we could do it with the device name beginning with h for ide (like
> > it is now actually), p for parport, (pcmcia is just another bus like
> > isa/pci to me so I feel it's irrelevent), s for scsi, u for usb.
> > say: u0b0i0l0 is id 0 on first bus on first usb controller..
> > Obviously, I don't know if usb has more than 1 bus per controller, I
> > know scsi does (used to have a dual channel adaptec eisa at one
> > time)
> There are good reasons for separating out the interface types. The
> first is that it allows an interface driver (ide-cd, sr_mod and so on)
> to manage a subdirectory. This makes the CD-ROM searching scheme I
> outlined trivial to implement.

I thought about that a little more... I was thinking that devfs or the
driver could have a link to the above or something...

> If you want to unify all controller numbers (at least IDE and SCSI),
> then that requires a higher level of abstraction than we currently
> have. Right now the IDE and SCSI code don't talk to a common base
> (genhd is *not* a common base for *all* IDE and SCSI devices, before
> anyone asks).
> BTW: the scheme you outline is ugly, because you end up with a very
> deep directory structure, with very few entries per directory. To find
> all your SCSI discs (for example) becomes much harder. It's the other
> extreme to the current mess of everything in /dev. I've gone for a
> balance between these two extremes that is practical and is easy to
> follow.

No it wasn't directories, they were files. Ie: s0i0l0p0 would be first scsi
controller (I feel first found scsi controller is better than first found
drive) scsi id0 lun0 partition0. s0i0l0 would be whole disk. Something
like h0i0p0 would be for ide, but after thinking about it, hd[x] might be
better... I dunno... I'm just throughing ideas around. I surely wouldn't
want something like
/devices/pcibus/slot1/scsi0/id0,lun0:a or something like that.... (I'm
thinking in sparc terms if you didn't know).

I really like the idea of solaris having this for scsi0 id0 lun0 partition0:
/dev/dsk/c0t0d0s0 I just don't like the letters they used.

Above where I said bus[0-9], forget it, it would be too hard to do that and
it would be easier to have c0 and c1 being controller 0 bus 0 and controller
0 bus 1. Whoever thought of /dev/sdb being 2nd found scsi hard drive should
be shot (IMO) I thought about running that user space thing, but I don't
like the idea of it since the rootfs is mounted via /dev/sdx by the kernel.
This is the exact reason I put my hard drives as close to id0 as possible
and all my other drives as close to id6 as possible. if my cd changer goes
out, my burner goes from scd5 to scd0.. ouch! I only have 1 tape drive in
this machine so that I'm not TOO worried about. But I thought about this,
if I ever get a wide card, there's no way I'm putting a wide hdd on an id
less than 8. This leaves enough room for all my narrow drives

Anyway, I don't feel it would be right to yank the /dev/sda out of the way
for people who like it, but it would be a nice config option... Atleast
that would suit the people who love /dev/s{cd,da,t} and for those who can't
stand it.. Me I can live with it, but I don't like it... Where's my choise

(I'm kidding)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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