Messages in this thread | | | Subject | Re: [PATCH] shm fs v2 against 2.3.41 | From | Christoph Rohland <> | Date | 01 Feb 2000 14:52:31 +0100 |
| |
Richard Guenther <richard.guenther@student.uni-tuebingen.de> writes:
> On 1 Feb 2000, Christoph Rohland wrote: > > > GOTO Masanori <gotom@debian.or.jp> writes: > > > > > And now I have a question: > > > I guess almost all users have no shmpath (default: /var/shm), > > > and they maybe make a dir and have to mount it. > > > IMHO, it is better to change that sysv shared memory works > > > samely, whenever shmfs is not mounted. Is it feasible, > > > or only my mistaken ? > > > > This was my first attempt, but all the gurus opposed to that since > > this needed some hacks to the VFS layer. > > > > Since shmat, etc rely on the VFS functions, we have to mount the fs to > > use these functions. > > Why not use //shm for the path, or //proc/shm so that if the kernel will > ever honour the extra // namespace even no hacks are required to have > the shmfs mounted in every chroot environment? Btw, proc should be > mounted as //proc, too. Using /var/shm is too much educating the user > IMHO. If you have to mount the shmfs by using mount anyway would it not > be possible to extract the directory used by using the information from > the remount_fs() superblock operation?
O.K. I will add the additional / to all shm pathes internally.
I do not like the path //shm since it clutters the root dircetory further.
I tried to extract he path in my first version, but did not like the hack needed for this. Since the information is not known to read_super, you always need a hack to extract the name. Thus I fell back to the old principle 'keep it small an stupid^H^H^H^H^Himple'
Greetings Christoph
--
- 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/
| |