>> I'm going to be mildly heretical here...why does AF_LOCAL still have
>> anything to do with the filesystem?  [...]
>> Am I being stupid somehow, or is there really no reason beyond
>> backward compatability?

> I don't think I'd call it stupid, I can see your point.

Actually, since I wrote that, one thing came to mind: permissions.  I'm
not sure whether the permission bits on a socket have any semantics,
but those on the directories leading up to it definitely do.

Whether there is reason enough to preserve the filesystem semantics is
debatable.  (Vide infra, too.)

> I'm interested to know what you had in mind for replacing it.  Would
> the kernel just keep the "paths" in a table or some similar
> mechanism?

Basically, yes.  Conceptually, AF_LOCAL addresses would be arbitrary
strings, which the kernel could store any way convenient: linear list,
hash table, trie, 2-3 tree, whatever.

> This would seem to eliminate the need to check for stale files and
> whatnot.

Exactly.  Of course, it would also divorce AF_LOCAL socket names from
filesystem paths in ways that existing code won't handle well (for
example, any code that expects a chdir() to have anything to do with
socket paths), which is basically the backward-compatability argument.

> Would this port easily?

To other OSes, probably not.  Across NetBSD ports, yes, unless someone
does something really boneheaded in the implementation (but that
possibility exists for just about everything).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B