[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux's future: //posix/ipc, //root and so on ?
Followup to:  <>
By author: "Khimenko Victor" <>
In newsgroup:
> 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 ?

Because the // and /.. namespaces are huge, nasty, terrible kluges.

> Then we'll end up with kludges like devpts handling in glibc :-((

That's WRONG. If /ipc isn't mounted, you can't use this API.
Period. End of story.

<> at work, <> in private!
"Unix gives you enough rope to shoot yourself in the foot."

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.098 / U:1.576 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site