From: andy@madhouse.demon.co.uk (Andrew Bray) Subject: Re: Thread Package for Linux Date: Wed, 9 Jun 1993 09:50:20 +0000
In article <1993Jun7.032838.2212@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>>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.
Once opened via an open call, I am a lot less worried about how its accessed,
for example UNIX domain sockets can be read and written, but there is also
the getmsg and putmsg interface. So if the IPC handles are compatibly
numbered with file handles (ie they are made mutually exclusive) then
either interface can be used to access the object once opened. So
a Linux specific program could take advantage of the UNIX namespace to
open the object, then use IPC calls (or maybe the socket calls) to
get a better performance on actual use. Most programs should be able
to afford the time of a slow open, followed by normal speed operations.
>...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.
By this argument, UNIX domain sockets should also be non persistent. The
proc filesystem seems to be growing into a kernel filesystem. For
consistency's sake I would put the SYSV IPC objects into the proc filesystem,
and rename it the kernel filesystem.
>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.
This is interesting, but I don't think I know enough about the Plan 9
namespace to really comment.
Regards,
Andy