[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.021 / U:1.448 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site