Re: USB device allocation
Nathan Hand (nathanh@chirp.com.au)
Sun, 10 Oct 1999 00:48:20 +1000
On Fri, Oct 08, 1999 at 06:08:02PM +0400, Khimenko Victor wrote:
> In <19991008093800.A25741@wookie.chirp.com.au> Nathan Hand (nathanh@chirp.com.au) wrote:
> > On Thu, Oct 07, 1999 at 11:15:08AM -0700, david parsons wrote:
> >> In article <linux.kernel.19991007104127.C15982@wookie.chirp.com.au>,
> >> Nathan Hand <nathanh@chirp.com.au> wrote:
> >>
> >> >This is why I suggested losing the devfs FILESYSTEM but retaining what
> >> >is devfs's INTENTION. Use the existing devfsd to maintain nodes on the
> >> >disk. Most of the benefits are kept. Some problems are addressed.
> >>
> >> Removing the filesystem makes devfs completely useless.
>
> > The /dev directory can still be "dynamic", the difference is that it's an
> > ext2 filesystem being updated from userspace, rather than a virtual devfs
> > filesystem being updated from kernelspace.
>
> > Realistically it only loses two features that people might covet (special
> > behaviour on open() of non-existent nodes, ability to use a non-UNIX like
> > filesystem for your /). The majority of people lose nothing.
>
> Main ability of devfs (to me) is ultimate solution for dev_t size: there are
> no need to allocate major and minor number for devices in some center.
Devfs is an overkill solution for dev_t size. You can increase the number
of bits for dev_t far more easily.
> > Notice that what I'm proposing here is exactly like the cardmgr daemon in
> > the PCMCIA package. With the introduction of PCMCIA into the kernel, it's
> > sensible to make ALL devices contact a cardmgr-alike daemmon.
The real benefit of devfs for the average punter is a dynamic /dev. You'd
get this exact same benefit with the scheme I proposed above.
--
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871 Fax: +61 2 6230 1515 E-mail: nathanh@chirp.com.au
-
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/