Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!WORLD.STD.COM!bzs
From: bzs@WORLD.STD.COM (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: OS network interfaces (was: sockets vs. streams)
Message-ID: <9009031808.AA02023@world.std.com>
Date: 3 Sep 90 18:08:59 GMT
References: <652304954.af@SPICE.CS.CMU.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 52


The issue of name server resolution and similar problems was raised by
Robert Elz. This is a real problem and well worth grappling with.

What has been done in various special-case forms but has never really
been standardized into unix kernels is a clean interface which allows
the kernel to call back out to a user process for information.

For example, one simplistic approach would be a daemon which registers
a service with the kernel (similar to bind() in philosophy) and then
waits for requests.

This could be cobbled up as a socket thing, call it the UNIX_KERNEL
protocol. That would, for example, allow the current name service to
do this via just adding another fd to its select() call:

daemon:

	struct sockaddr_kern sockk;

	sockk.port = NAME_SERVICE;

	skern = socket(KERNEL,SOCK_DGRAM,0);

	bind(skern,&sockk,sizeof(sockk));

	...etc...(select/accept loop)

PDP-10 types will of course recognize this as a generalization of the
ACJ idea. And it could very well be used for authorization etc.,
anything where it would be nice to manage various data at user level
and let the kernel just query these user processes for things like
"can this uid do remote TCP connects?", "what does this string
translate to?", "user foo's job just ran out of memory, please log to
a file".

Current facilities, such as kernel error logging, could be completely
replaced by this sort of facility.

I'm sure people will now tell me that XYZ is just this, I'm
interested, but I suspect what we'll find is a lot of little special
facilities that never quite got generalized, or have some other
strange limitations.

Of course, generalizing this so the query relays to another server
over the net is almost trivial (the user level daemon can do that, and
in the case of a name service almost certainly would.)

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD