Messages in this thread | | | Date | Thu, 1 Jan 1998 16:17:14 -0500 (EST) | From | James Mastros <> | Subject | Re: PROPOSAL: /proc/dev |
| |
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)
| |