Re: /dev/sd*

[Greg KH]

On Thu, Aug 10, 2006 at 12:18:57AM +0200, Adrian Bunk wrote:
> On Wed, Aug 09, 2006 at 11:01:43PM +0100, Alan Cox wrote:
> > Ar Mer, 2006-08-09 am 23:21 +0200, ysgrifennodd Adrian Bunk:
> > > It might be a bit out of the scope of this thread, but why do some many 
> > > subsystems use the /dev/sd* namespace?
> > > 
> > > Real SCSI devices use it.
> > > The USB mass storage driver uses it.
> > 
> > USB storage is real SCSI.
> 
> Real SCSI for a developer, for a user it's USB.

So?  Users of Linux know to look for their USB storage devices in
/dev/sd* because of this.

> And things become even more confusing considering that the drive might 
> show up as /dev/sda or /dev/uba depending on the driver used.

And udev causes this to be moot, as people use the /dev/disk/by-*
symlinks, which are the same if they use the usb-storage or ub driver.

Same thing will happen for the changes that Alan is going to do (which I
think is the right thing to have happen.)

> > > libata uses it.
> > > 
> > > I'd expext SATA or PATA devices at /dev/hd* or perhaps at /dev/ata* - 
> > > but why are they at /dev/sd*?
> > 
> > ATA uses the top half of the scsi stack so ends up using the top layer
> > scsi drivers. Its probably more efficient than writing new driver
> > clones, especially as non disk ATA is also real SCSI (or very close).
> 
> You are talking about kernel<->kernel and kernel<->hardware interfaces.
> 
> I'm more concerned about the kernel<->userspace interface.
> 
> > You can use /dev/ata if you want - its just a udev problem ;)
> 
> Or by adding some manual links if using a static /dev.

Sure, but most distros don't have a static /dev anymore.

> But I'm still not getting the point why the /dev/sd* namespace has to be 
> used.

Because it has for USB storage devices since the 2.2 kernel.

Ok, 2.3, but then quickly backported to 2.2...  You want to break that
userspace interface?  :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/