Yes, you can delete what you don't need. In fact I was doing that
before I wrote devfs. But then when you buy a shiny new disc, you have
to go and create inodes again.
Using scsidev helps, but then there are still problems with inserting
new devices on-the-fly and cute tricks like that. And you don't need
exotic hardware to do this: think PCMCIA. Without devfs the problems
just go on and on.
> 2. I don' t know very well the fs code but I don' t think the problem
> is the number of inodes, but instead the number of file entry in the
> directory /dev/. So dividing /dev/ in /dev/block /dev/char for example
> would speed up things I think.
Yes, it helps a bit. But the problem just gets shifted to a
subdirectory. If you have a fully populated directory of inodes for
discs, that is still a big directory. Hence having *only* inodes for
the devices you have currently plugged in is the way to go.
> I don' t know if devfs is so malleable/configurable.
I'm not sure what you mean here. Do you mean having subdirectories?
Sure: devfs supports subdirectories. In fact a fair bit of stuff has
the new name entries in subdirectories to reduce /dev clutter.
Regards,
Richard....
-
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