lkml.org 
[lkml]   [1999]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: My $0.02 on devd and devfs
On Mon, Oct 11, 1999, H. Peter Anvin <hpa@transmeta.com> wrote:
> Followup to: <19991010011136.C30460@wookie.chirp.com.au>
> By author: Nathan Hand <nathanh@chirp.com.au>
> In newsgroup: linux.dev.kernel
> >
> > > One of the things I do with Linux is to write my own distribution.
> > > As part of this, I'm trying to build an installer that autodetects
> > > as much of the system as it can. Currently I need to jump through a
> > > lot of poorly-documented hoops to do this; for example, with a
> > > devfs numerating the number of partitions on a system is a simple
> > > case of trawling through /dev for the appropriate files, but if I
> > > don't have devfs, I get chore of running ``fdisk -l'' and picking
> > > the output apart.
> >
> > HPA, would you be open to the idea of /proc/devices. This won't be
> > a terrific loss of functionality from the existing devfs.
>
> I have thought a lot about this, and I have been trying to avoid
> sounding like I flame. I *do* believe that devfs is a very inelegant
> solution, but it is a solution to a real problem. It is not, in my
> opinion however, the *right* solution.
>
> I don't think a /proc/dev/ is the right solution either; although it
> is less severe (since all entries in /proc/dev/ can have 600
> root,root) it isn't a *solution*, really.
>
> The right solution -- which the devfs people have correctly identified
> -- is a user-space daemon. However, once you have the user-space
> daemon, "devd", I believe you neither need nor want the virtual
> filesystem, in the general case. However, I can understand that in
> some configurations (like embedded systems) it may be desirable.
>
> This is what I would like to see:
>
> * A device daemon, devd, which can add devices on demand. I was
> thinking of one which would receive data packets like the following:
>
> <stub_name, type, major, first_minor, count, naming_scheme>
>
> e.g.
>
> <"ttyS", char, 4, 64, 192, "serial">
>
> ... where "serial" would mean the daemon should find the iterator
> for this particular class in "/usr/lib/devd/serial.so".
>
> * devd should not *delete* devices in normal operation, unless they
> have been superceded. Deleting device nodes is generally a
> destructive operation.
>
> * On modules, additional ELF sections as needed to include necessary
> detection- and hopefully device information. This will be part of
> the "supermodule" proposal I'm working on for the Genesis boot
> loader ("supermodules" will be able to be either linked into the
> kernel or runtime loaded, using the same binary -- the idea is that
> Genesis will link a kernel with the necessary/desired drivers on the
> fly.)
>
> Notice that this interface would *also* be usable for devfs (which
> would have to include all the various iterators etc in kernel space,
> but it would have to anyway), which makes devfs an optional, isolated
> feature. This is a Good Thing: I don't have anything against devfs as
> an *isolated* feature for the people who want to use it (lazy/careless
> admins, embedded systems...) I *do* have a problem with it becoming
> ubiquitous, and I do have a problem with it being a requirement for
> each device driver. However, with this configuration devd would
> effectively be the "standard" mode of operation, and devfs would be an
> "alternate", using the same interfaces.

Thanks for putting forth your input into the matter.

I'd like to here your thoughts on major/minor allocation for PnP
devices. The hypothetical example being used is connecting 1000+ modems
to a machine. (Apparentely someone has done this on an Irix machine
further solidifying the fact this can and will happen).

Right now, it's impossible to do with the current 8/8 split of
major/minor. Some people are proposing increasing it a 16/16 split which
will significantly improve the situation, but as we've fallen into in
the past, any arbitrary limit will be broken.

Do you think simply increasing the major/minor will solve the problem?
It seems like when you increase the major/minor space you also increase
computational complexity in determining which driver owns that
major/minor.

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.148 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site