Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

Albert D. Cahalan (acahalan@cs.uml.edu)
Fri, 7 Aug 1998 17:29:49 -0400 (EDT)


H. Peter Anvin writes:

>> Many programs need to search through /dev. That includes lilo, the
>> whole procps package, stuff related to the talk daemon, etc.
>>
>> That's not even the worst of it. Every time you open a pty, you need
>> access /dev. Every time you want /dev/null or /dev/zero, you access /dev.
>>
>> The result: general system slowdown. You can't point a finger at
>> the problem ("we lost 23 seconds RIGHT THERE because /dev was slow")
>> but you suffer anyway.
>>
>> Hey, Linus! It looks like a latency problem.
>
> This is what the dcache is for.

Yes and no. The size of the dcache is finite, and the system will
slow down if you fill the dcache with crap.

It's not good to rely on the dcache to hide problems. The dcache may
already be stressed by a news spool. The dcache will make your /dev
benchmarks look good on a machine with enough RAM. Who cares?

People keep proposing bandaid solutions that only treat the symptoms.
Device files are a namespace used to access kernel drivers, not just
an ordinary collection of files. There is a fundamental difference here.
It is critical that /dev be perfectly synchronized with the kernel.
Preferably, /dev is also synchronized with the hardware.

How would an anti-devfs person support USB? Remember, the whole system
is dynamic. You can add and remove devices on a live system. You can
have several devices of the same type, there is no adjustable ID like
SCSI has... It will put you through hell.

-
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.altern.org/andrebalsa/doc/lkml-faq.html