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    [W:0.040 / U:0.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site