lkml.org 
[lkml]   [1999]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: USB device allocation
On Tue, Oct 05, 1999, Brian Swetland <swetland@be.com> wrote:
> [Jeff Noxon <jeff@planetfall.com>]
> > On Tue, Oct 05, 1999 at 01:54:24PM -0700, Dan Hollis wrote:
> > > My /dev takes 107kbyte on disk (2,245 entries!), this is even just a small
> > > fraction of devices.
> >
> > This may sound like flamebait or ignorance, but here goes: Why can't
> > USB devices just show up dynamically under /proc/usb/dev/ or something
> > like that? Are traditional device nodes really necessary?
>
> Wait! Why couldn't all devices just show up dynamically? You'd only
> see the devices that were actually on the system (at that moment). Wait,
> somebody already made this work! Ye gods, the anarchy.
>
> Why should a usb zip drive, parallel zip drive, or scsi zip drive be
> different to access? They all speak the same protocol. You don't have
> a different driver for a scsi disk on a buslogic controller and a scsi
> disk on an adaptec controller, do you?

Neither do you with USB. It uses the same SCSI disk driver. Perhaps I'm
missing your reference?

For all of the "standard devices" (this is vaguley defined) it uses one
of the standard device nodes. In the case of USB zip drives, etc it
shows up as the next sd* device.

This is good (consistent) but bad since the device naming is dependant
on order of plugging the device in.

This will not work for USB. devfs (as it stands right now) won't work
for USB either. However, making the appropriate changes to devfs CAN
make it work.

To use standard device nodes would require something similar but with a
mess of kernel code (no one likes that) or creative moving around of
device nodes on the disk.

Since the in kernel solution will probably never be accepted into the
kernel, a daemon is most likely solution.

I'd like to see devfs in the role since it exists already and does much
of the work that is needed already.

I guess it's time to grab devfs and seriously look at what can be done
to do this.

JE


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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