>> why does AF_LOCAL still have anything to do with the filesystem?

>> Whether there is reason enough to preserve the filesystem semantics
>> is debatable.
> having it in the filesystem is not that much of a problem,

Big problem for some things, though we tend not to notice because
things that need filesystem-free sockets don't get done because there
aren't filesystem-free sockets.  (Except 127.0.0.1 AF_INET sockets,
which lose compared to AF_LOCAL in various ways.)

The ability to put them in the filesystem and leverage the filesystem
access-control mechanisms, that's good.  Having no option but putting
them in the filesystem, that's a lose.

Unfortunately I'm not sure there's much that can be done about it.  I
don't for a moment think we're going to actually trash compatability
with historical AF_UNIX behavior.  If this mistake had been caught
before AF_LOCAL were made a synonym for AF_UNIX, it could have been
corrected by adding a "flavor" field of some sort to the AF_LOCAL
sockaddr, thereby allowing multiple paradigms (eg, filesystem and
non-filesystem) for addressing.  Now, the only alternative is to use a
new AF number.

Or ignore the issue and continue telling anyone who wants local sockets
freed of filesystem restrictions to use AF_INET 127.0.0.1, thereby
preventing them from passing access rights, requiring INET-capable
kernels, etc.  Perhaps that'll be considered acceptable.

/~\ 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