Thus spake Greg A. Woods ("GAW> ") sometime Today...

GAW> I'm only blurring the boundary between kernel and user-land because when
GAW> you get down to these kinds of things the boundary _should_ be blurry.
GAW>
GAW> Just as the unix filesystem has namei(), SysV IPC has ftok().

The difference, though, is that ftok() is implemented in userspace, forcing
whatever uses IPC to do its own groveling, while namei() is never seen from
userland -- the kernel always ALWAYS handles namei().

You might like to blur the line between kernel and userspace, and as much
as the line should be blurred on occasion, this is not one of those
occasions, except, it seems, to suit your own point of view.  Using IPC
shouldn't require kernel-like knowledge to address any more than one is
required to know kernel-like things in order to call, e.g. open(2) or
chdir(2).

With open/chdir, you pass a pathname which is easily determined and can
even be proscribed by the program in question, at which point error
detection and handling and probably several fallbacks come into play.

With the IPC stuff, you have to jump through quite a few hoops to locate
the identifier.  You must ALWAYS do this.  You cannot hope to even generate
the identifier on the fly.  At this point, error detection and handling
come into play, and there's really no fallback -- if what the system
gives you doesn't work for some strange reason, you're hosed (of course,
so's the system, most likely).

Comparing the filesystem to IPC/shm/sem/msg is like comparing apples
to astrology.  There is little commonality between the two; given that they
serve somewhat different needs (unless you count the open/fork/unlink
trick which preceded anything resembling current IPC), this is expected.

Nonetheless, that the implementation as it stands deals with nonhuman(oid)-
readable identifiers which must be obtained through secondary means is just
ridiculous.  The least that could be done is that a shm/sem/msg could
be requested by a particular name; the system could then perform whatever
magic it deems necessary to keep track of it.

At least, to narrow the comparison gap momentarily (and conveniently for
my POV (at least I admit it!)), the programmer has some choice over what
s/he wants their files to be named for easy access.  IPC does not afford
such luxury, and while it's not necessary to do so for anything currently
running, once the process terminates or one wants to pass something manually
(i.e. typed in), it would be nice to be able to pass a reliable name in.

Unless you're going to argue that computers, and not people, should be
in charge of programming computers (and people!)...

				--*greywolf;
--
NetBSD: SIMMs Like Good Code.