Re: centralized auth and nsswitch.conf

[Peter da Silva <peter-dragonfly@xxxxxxxxxxx>]

Matthew Dillon wrote:
>     What the LWKT messaging gives us in this case is an abstraction that
>     fits well with the userland threading infrastructure, allowing things
>     like asynchronous queries when most existing APIs (like gethostbyname())
>     are synchronous-only.  But this capability should not be confused
>     with the basic transport mechanism used to communicate the messages 
>     between processes.  I would far prefer that a normal, portable IPC
>     mechanism be used for the transport because it allows us to create
>     a portable standard that other UNIXes can use whether or not they
>     implement the end points as LWKT messages.

I'm not sure I see the point of doing it that way in Dragonfly
itself.

LWKT doesn't care about the abstraction. Implementing the
messages efficiently in Dragonfly shouldn't have anything to
do with the implementation on another platform.

This does open up the question of how messages are to be
marshalled for transport through sockets (or Mach message
ports, as already discussed, or any other heavyweight message
scheme), but that issue is opened up as soon as you talk
about passing LWKT messages through sockets. For example,
how would you marshall a message containing:

	int fd;
	char *buffer;
	int length;

This is where I thought you were going to have templates inline
in the message itself:

	TYPE_HANDLE, sizeof fd, fd,
	TYPE_VM_OBJECT, sizeof buffer, buffer,
	TYPE_SIZE_T, sizeof length, length,
	NULL

I was thinking more along the lines of having those templates
out of line and passed with Send() so it can use them if necessary
to marshal the message itself.

Either way, the native dragonfly code for the Send() function
in gethostbyname() shouldn't need to be the same as the code
in a non-native implementation. And maybe I'm being particularly
thick but it seems like it would make a lot of things quite hard
to implement efficiently if you did things this way (for example,
passing pointers and handles).