Re: PROPOSAL: /proc/dev

James Mastros (root@jennifer-unix.dyn.ml.org)
Mon, 5 Jan 1998 19:00:42 -0500 (EST)


On Mon, 5 Jan 1998, Andrea Arcangeli wrote:
> On Sun, 4 Jan 1998, James Mastros wrote:
> >On Sun, 4 Jan 1998, Andrea Arcangeli wrote:
> >> On Sat, 3 Jan 1998, Richard Gooch wrote:
> >> >The reason my scheme doesn't depend on kerneld is that if a driver is
> >> >built-in/loaded by a boot script, the /dev entries for that driver are
> >> >registered in the startup code. So, on a system like mine where all
> >> >drivers are either built-in or automatically installed by a boot
> >> >script, /dev would be fully populated. An attempt to open(2) an entry
> >> >in /dev which did not exist would cause devfs to return -ENODEV
> >> >because kerneld isn't running.
>
> ...and if kerneld is running kerneld will "mknod" the device in /devfs.
>
> This is what I don' t agree and I take as wrong.
No, kerneld will load the module, the module will ask devfs to create the
file. Under my idea, I'm going to make it simple to implement devfs asking
userspace to do it (IE implementable without changes to devfs), but I won't
have it do that. Some people seem to want that feature.

> >> - You could implement that more easily without use kerneld.
> >Yes, but then we don't have module autoloading.
>
> I am not talking about modules. The open(2) implementation that Richard
> proposed in the paragraph above is whole related to static device and not
> only module.
Yes, but the way I interpreted what you were saying is like this: It is
simpler to implement the open(2) call without using kerneld. I'm saying
that if open(2) dosn't use kerneld _if_ _avaible_, then if sombody attempts
to open a device, for which the driver is an unloaded module, then that
module won't get autoloaded, but the open attempt would fail instead. You
can't load modules from kernelspace directly at present, and I think that
any system where you can is fundementaly broken, as the kernel shouldn't
have to know the locations of things (and I think Linus has stated many
times the same opinion).

> >> - I think this is totally wrong for programs or people that check in /dev
> >> for a device before try to open it, or at least is a mess.
> >WHAT!!! The whole point of a virtual devfs is that you can do a "ls /dev"
> >to see what devices are currently accessable. And most actions on a divice
> >start with a call to open() (or mount()).
>
> Richard in the paragraph I quoted, proposed a devfs implementation that
> don' t show what devices are currently accessible, but only the ones
> opened(2).
No, he didn't (unless he sent a privite mail to you, and I am going crazy
and blind). He proposed a devfs that only shows devices that are currently
avaible (as in have a driver currently in kernelspace (wether there since
boottime or loaded as a module)).

> >> - If you want to make something useful, your devfs must be populated from
> >> _all_ kernel devices at boot with 600 permission and it must not remove
>
> Obviously I want to mean _all_ and __only__ kernel devices linked or
> insmodded with the kernel.

Right. Thats what Richard & I have been proposing (except possibly the
default to 600).

OK, that is totaly not how I interpreted your mail... I'm very sory for
biting at you.

> >> device entry for some reason. It can add/remove devices from the
> >> filesystem only when you load/unload a kernel module.
> >NO! We want only divices that are acatually on the system to show up in
> >/dev. That is the main selling point of a devfs.
>
> You should read the quoted mail before reply.
>
> >> - Since devfs should be a virtual device that forget permission and
> >> ownership at reboot (or after module unload) it will make the life hard
> >> and less efficient in the rcS.d scripts. I' d like to chown directly
> >> /dev/devname on ext2, instead of change a bootup script or adding the
> >> line "option modname chmod 644 /dev/modname; chown ..." in /etc/conf.modules.
> >> I don' t like something of only virtual.
> >OK, so write a little c proggie that stat()s each file in /dev and restores
> >them apon boot. Problem solved.
>
> I know but I am a bit conservative when all just works perfect and
> efficient...

But it dosn't work perfect and efficient:
# ls -l /dev | wc
1285 12843 78638 dev.list

# (edit to only show what I really have (+ all pty files, since I don't know
how to check how many I have in use (all 512 of 'em), + ones that I'm not
shure what they are, +cua2, though I don't have one, the serial driver
has one anyway (Uart=unknown), and all the floppy formats (of the proper
3.5/5.25age), +foo (42,42), +symlinks for all the devices that I have,
+msr (I have msr, of course, but my current kernel dosn't have the
driver))
# wc dev.list
633 6351 38927 dev.list

That is why the current dev system is bad (1285-633=652. And, 512 of them
are ptys, so there are only 140 "real" divices). That, and arbitrary limits
on the number of a certian divice you can have (7 IDE/ATAPI devices, 63 VTs,
256 loopback mounts, n scsi devices). (That last is the most importatnt:
If you want to have host/chain/lun/slice addressing, then making a unique
device number for every possible combo and a /dev node to match is quite a
daunting task. Having a device number for each one that exists (and not
needing to make nodes) is much better.) And the lack of an easy way
to see what hardware you have. And...

-=- James Mastros

> Andrea[s] Arcangeli

-- 
  Agent K: Humans for the most part don't have a clue.  They don't need one
    or want one either.  They're happy.  They think they have a good read on
    things.
  Will Smith (not yet Agent J): But why the big secret?  People are smart;
    they can handle it.
  K: A person is smart; people are dumb, panicky animals and you know it.
     Fifteen hundred years ago, everybody knew that the Earth was the center
     of the Universe.  Five hundred years ago, everybody knew that the Earth
     was flat.  Fifteen minutes ago, you knew that humans were alone in the
     Universe.  Just think what you'll know tomorrow.

-=- Men In Black (1997, Paramount)