Was looking over the 2.3.99 differences (versus 2.3.40) and came across a few
people having to create a /var/shm in order to do anything shared-memory. Why
do we need a increasing number of virtual filesystems these days to please the
kernel? Whatever happened to just having good old /proc and kernel-level
routines with syscalls to take care of everything? If programs generally use
syscalls to do shared memory anyways, and they never touch a filesystem
(unlike how programs use /proc), then why isn't shmem just an internel kernel
structure instead?
While I'm at it, here are my comments on /devfs. I feel it's actually
something we should have because of the inode management problems (too many
of them in that /dev directory, slow seek time, etc.), but I don't feel the
way it was implemented was a very good idea--
The current /devfs method forces all user-level programs to be rewritten to
use the new format, i.e. changing say /dev/tty10 to /devfs/tty/10. This also
causes the potential problem that new programs will be written only for /devfs
and not maintain compatibility with the old /dev structure.
If anything, I would love to see a virtual device filesystem get implemented
that mounts on /dev and has its links simulated completely by the kernel,
ensuring full compatibility with old programs. This means that while there
aren't 1,000 directories hanging out in /dev, instead there would only be the
ones currently available and active by the kernel. As modules [un]register new
major IDs, their entries would appear/disappear from the /dev list on the fly
without any mknod managing. Of course this requires keeping a list of devices
associated with major nodes like /dev/tty{0-63} and such in kernel memory
somewhere, but isn't that already done with /devfs anyways? Only it's called
/devfs/tty/{0-63}.
I just feel this way is more productive because it eliminates the need for
changing /dev nodes as new kernels come out, it provides full compatibility
with older programs (nothing's changed from earlier user-end behavior), it
would keep seek time low because only those devices available from the kernel
would show up in /dev, and modules could be inserted and removed with their
/dev entries automatically generated.
If you think about it, this also gives an added benefit. The kernel could keep
track of which Major node numbers are being used and assign unused ones out as
modules get inserted. While this shouldn't be done for common devices that
have static major nodes (/dev/tty being 4, etc), what the kernel Can do is
reserve a subset of nodes such as 240-254 for proprietary software. Then such
software modules can request any next available Major Node ID for their
/dev entry, and user-level programs using those /dev entries wouldn't notice
a single difference.
Thoughts, suggestions?
-- Byron Stanoszek <gandalf@winds.org>- 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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:11 EST