lkml.org 
[lkml]   [1998]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PROPOSAL: /proc/dev
James Mastros writes:
> On Thu, 1 Jan 1998, Richard Gooch wrote:
> [...]
> > So, my current thinking is:
> >
> > Device driver startup code registers the device entry, giving the name
> > of the /dev entry, the permissions, ownership and so on as well as
> > major&minor numbers for legacy disc-based /dev systems.
> OK, you are with me here (mine just gives the name, but close enough).
>
> > Another
> > parameter would be the name of the module to pass to kerneld when
> > someone open()s /dev/someentry. The ctime of these entries would be 0
> > (or perhaps system boot time).
> 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.

> 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.

> How about this redisign:
> <devfs' root>/
> possible/ (note - for backwards compatablity, mount devfs on /devfs, and
> make /dev be a symlink to /devfs/possible/)
> <a divice for everything in Documentation/devices.txt>
> loaded/
> <various shit> (Including lots of trees (for chained devices, devices of
> the same type, etc...))
>
> But we still need to have nodes for stuff that isn't neccessarly
> there. Shit.

Nope, just the stuff that is available. For a system where not all
modules are loaded (i.e. kerneld), there will be even less /dev
entries.

> > 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.

> > The question of symlinks: either the devfs supports creation of
> > symlinks (stored in RAM) or you require symlinks from an external
> > filesystem (not very nice).
> Don't do symlinks; make hardlinks. All data for the hardlink is in the
> inode, so we don't have to handle file contents. But a symlink has its data
> as contents, so we would have to put it somewhere, which would involve real
> work. 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.

Regards,

Richard....

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