lkml.org 
[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux's future: //posix/ipc, //root and so on ?
Date
Followup to:  <AFFO3lui6S@khim.sch57.msk.ru>
By author: "Khimenko Victor" <khim@sch57.msk.ru>
In newsgroup: linux.dev.kernel
>
> 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.

-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> 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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site