Messages in this thread | | | From | "Khimenko Victor" <> | Date | Wed, 1 Mar 2000 00:11:43 +0300 (MSK) | Subject | Re: Linux's future: //posix/ipc, //root and so on ? |
| |
In <E12PsxN-0004LZ-00@the-village.bc.nu> Alan Cox (alan@lxorguk.ukuu.org.uk) wrote: >> mount anything at all, easy change of root: just umount //root and mount >> other thing there. And POSIX agrees that //root or //proc CAN be special >> so all is correct. So just kernel changes are needed. Right ? Not quite:
AC> Millions of apps rely on // working.
Are you sure ? Why ? Till there no warning we can not check it.
>> it's better to add kernel warning NOW. Perhaps configurable so it can be >> disabled (not in compile time, but in run-time). This way at least EACH AND >> EVERY Linux vendor will be aware about problem. What do you think ?
AC> If Linus made // special in the kernel we'd have to make it unspecial again AC> in glibc 8(.
You can not :-)) It'll be slow, error-prone and will have security iplications (why ? think about symlinks :-)
AC> It also breaks the flexibility of mounting we have now. Why is it AC> //ipc - what does //ipc have to do with ipc in other languages, why AC> can't I mount it where I want it ?
POSIX IPC implementation needed finename, visible from userspace. If you have no knowleadge about where "IPC filesystem" is mounted you can not construct such name. With //ipc //ipc/bla-bla-bla will be ALWAYS //ipc/bla-bla-bla -- no matter what and when. The same goes for //proc and so on. Of course we can always say: if you are mounting procfs not in /proc and ipcfs not in /ipc then blame yourself. But then why it should be done from userspace if there are no choice ?
AC> We have a nice unix VFS abstraction. Not using it is just ugly. Things like AC> mounting /ipc can be handled in startup space quite easily.
Then we'll end up with kludges like devpts handling in glibc :-((
- 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/
| |