Re: PROPOSAL: /proc/dev

James Mastros (root@jennifer-unix.dyn.ml.org)
Thu, 1 Jan 1998 16:17:14 -0500 (EST)


On Thu, 1 Jan 1998, Richard Gooch wrote:
> James Mastros writes:
> > On Thu, 1 Jan 1998, Richard Gooch wrote:
> > [...]
> > Huha? OUCH! I had forgot about that... we don't just want entries for
> > every divice existant... you need one for every divice possible, so the
> > device files exist before the driver is loaded to create the dynamic entries
> > in the devfs... sombody please tell me that I havn't been using a circular
> > path for devices that we need to access before we know how to access them...
> >
> > Shit.
>
> Sorry. That was my braino. What you do is have devfs pass to kerneld
> the name of the /dev entry that was open()ed. Let kerneld do the
> conversion between "ttyS{0,1,2,3}" to "serial". Probably kerneld will
> use a configuration file.
Mine too... we were both independently stupid. I came up with the same thing.

> > I don't like the idea of creating a file for every possible device; it takes
> > away the whole point of a dynamic devfs.
> >
> > Shit.
>
> In the worst case with all modules loaded or all drivers built into
> the kernel, the number of /dev entries is determined by the number of
> *available* devices. So, on my system with no IDE drives, there will
> be no /dev/hd* entries. Ever. I just did a rough estimate of the
> number of available devices on my system (I have 4 SCSI discs and a
> SCSI CD-ROM). Assuming each disc has the maximum number of partitions,
> that's still only around 150 device entries for the lot. In reality
> it's likely to be 100 or less. We're talking about a few pages in
> kernel space.
Exactly; I was counting on the stupid way of getting to module
autoloading... but the smart way dosn't have this limitation.

[...]
> > > A simple implementation of this will require one kernel-memory inode
> > > per available device. Given that there are usually not many available
> > > devices, this overhead should be minimal. If this were ever to become
> > > a problem, we could look at ways of avoiding creating VFS inodes for
> > > each device.
> > Yes; I think we are in agreement with how to store the fs: have un-reapable
> > i&dcache entries.
>
> I've had a closer look and I think we can avoid creating an inode for
> each /dev entry.
Ahh, good. I'm currently writing a memfs (IE automaticly growing and
shrinking fs in ram only (nonpersistant without userlevel help)); I'm going
to finish it and then extend it to a devfs. I hope you share your inodeless
plan with me... (hint, hint...)

[...]
> > The icache (inode cache) can handle device files by itself, the
> > dcache can handle directories; contents would require a new in-memory
> > structure.
> But then you would need an inode for each available /dev entry, right?
> And that's 244 bytes per inode for 2.1.76 (x86). I'm hoping for a
> per-device entry structure of under 64 bytes.

I want to see your plan... I'm trying to keep this simple for the first
implementation. Probably we can fit in a inodeless system later without too
much work if it's posible in the first place (which I'm not to shure of).

-=- James Mastros

-- 
Information as a base of power is coming to an end.  In the way the world
works tomorrow, the power to *do* *something* *with* *information* is what
will matter. 

-=- James Mastros, rephrasing Nugget (David McNett, distributed.net Big Man)