Subject: Re: getaddrinfo() and PF_LOCAL
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 08/02/2001 02:24:51
>> 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
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
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 email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B