From: Brandon S. Allbery (bsa@kf8nh.wariat.org)
Date: 06/06/93


From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Thread Package for Linux
Date: Mon, 7 Jun 1993 03:28:38 GMT

In article <C875Lp.2wt@madhouse.demon.co.uk> andy@madhouse.demon.co.uk (Andrew Bray) writes:
>In article <1993Jun4.214413.3288@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>>---Maybe I'll design an IPC mapper that allows hierarchical named access to
>>IPC, and assign these semaphores a namespace to be mapped. If I did it right,
>>someone who *really* wanted IPC objects to be mapped into the filesystem could
>>mount the IPC map as a filesystem and possibly use symlinks to put things
>>where they want them; but then I'd need to solve the filesystem semantics
>>problem....
>
>As I understand the BSD thinking behind UNIX domain sockets, the idea was
>that the mounted file tree constituted a single hierachical namespace, and
>is conceptually 'the UNIX name space'. The idea was that it is cleaner
>for UNIX to have just one namespace and that all kernel objects are
>addressable via this name space.

Which is what the above would give you. Read and write operations would then
be mapped to the correct operation and you could ignore the other
implementation. The mapping would produce a slight speed penalty, but VFS
has so many layers already that even if I copied the IPC code instead it would
be slower.

>The downside for the single name-space is that the it is eventually
>stored on disk on a number of different partition formats. There needs
>to be a consistant way of representing these non-file objects on a partition
>that is in the end designed to store files.

...if it is stored on disk. The minus of the Xenix approach is that it must
be, even though semaphores aren't persistent; a better way would be to have a
mountable semaphore namespace, which is to say, a pseudo-filesystem a la
procfs.

>All of this is of course waffle, based on a gut feeling of what I find
>aesthetically pleasing in an OS. It is of course totally irrelevant,
>as SYSV IPC has escaped from the brain-dead laboratory where it was
>dreamt up, and so we must support it. We should also resist providing
>different interfaces to similar functionality to the rest of the UNIX
>world, unless they are endorsed by POSIX.

I honestly believe, albeit with little evidence, that System V IPC was
originally implemented as it was as a first step toward the Plan 9 namespace,
e.g. the "real" name of anything would be the ?node and it could be mapped
anywhere in a per-process(-group) hierarchical namespace. (Think of the ID as
an inode number.) Unfortunately, the rest of the semantics were omitted,
possibly because the mechanisms "weren't ready to be released" or just plain
weren't understood very well by the commercial folks. If I were to produce a
filesystem "map" it would work in basically that way, except that you would
need to use symlinks to produce the hierarchical map because Unix (Linux)
isn't Plan 9.

++Brandon

-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org

It's not too late to turn back from the "Gates" of Hell... Linux: the free 32-bit operating system, available NOW. Why waaaaaait for NT?