Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: 2.3.51-52.pre1, shm and mounting somewhere else than /var/shm... | Date | Tue, 14 Mar 2000 13:29:01 -0500 (EST) |
| |
Christoph Rohland writes: > "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
>> Documentation doesn't a feature make. It seems odd that the kernel >> would not know where a filesystem is mounted. The kernel, more than >> anything else, ought to be aware of filesystem mount points. > > My first version had this feature, but it was an ugly hack and I did > not find a way to reliably export this to user space without further > hacks.
Going to user space you have /proc/mounts and /etc/mtab.
> Unfortunately the fs does not get the mount point from anywhere. The > only function called by the VFS ist read_super, which does not get the > information. If you want to autodetect, you have to play tricks with > dcache and the path to your root inode.
a. play tricks b. change read_super
>> BTW, /var/shm is a bad default. Stuff like this should be right on >> the root because /var may be a separate filesystem that gets mounted >> after the system already needs shared memory. > > I am very open to proposals for other mount point defaults. But > personally I really do not like any further root directory cluttering.
Stuff that belongs on the root: historical requirements, mount points for special filesystems, and locally desired junk. Instead of "clutter", think "short and fast paths".
> Another idea would be /dev/shm like /dev/pts but I wanted to avoid > clashes with devfs.
There isn't a clash, but this adds a mount order dependency. It would mean the shm filesystem can not be mounted until after devfs (or /var in the current code) has successfully been mounted. Going the other direction, a hung shm filesystem would prevent /dev or /var from being unmounted.
- 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/
| |