"H. Peter Anvin" <hpa@transmeta.com> writes:
> > I'm not following you. What you talk about is the kernel
> > implementation. I've written the interface the user will see at
> > everything I said is true for it. There is no one-to-one
> > correcpondence between names given to shm_open() and files in the
> > filesystem tree, there are no slashes allowed in the names.
> >
>
> Interesting. I thought that was the whole purpose of shmfs?
Yes and the glibc implementation wraps the open (2) call into the shm
fs with the function shm_open which does not allow slashes in the
path. Thus the application does not have to know the path to the shm
fs.
We could also supply sys_shm_open and sys_shm_unlink in the kernel. In
this case we would not need to mount the fs at all. But this would
make a bigger kernel API with loosing the ability to use the common
tools like ls and rm for manipulating the POSIX shm namespace.
Greetings
Christoph
BTW. in my last shm patch I changed the recommended path for the shm
fs to /dev/shm (But please, no flames.)
-
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 : Wed Jun 07 2000 - 21:00:16 EST