Re: API noodling

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:>     The union is really just a space allocation.  We can add some padding,
:>     and anyway the emulation layer *will* be aware of the user program's
:>     release since it's syscall entry points (e.g. 'read()') have to be
:>     compatible.
:
:Yeh, but I thought that the emulation would be providing the glue
:between the application version and the kernel version by passing
:a structured message to the kernel. I must have misunderstood
:something somewhere in that message where you had something like
:READ, ARG_HANDLE, fd, ARG_BUFPOINTER, address, ARG_SIZE, length...

    No, resource lists would be used for (complex) structural contents,
    e.g. things like the contents of a struct stat structure,
    or all the info related to a process when doing a ps, etc.

    It would be an incredible burden to use a resource list for simple
    syscall arguments.  Better to generate a new system call message
    if the arguments change drastically, and then have the emulation code
    fall-back to the old version of the system call message format if 
    the kernel returns ENOSYS for the new one.

:>     We don't have to use the pre-cache approach for all of our message types,
:>     just for the ones in the critical path to streamline the interface.
:>     Signals aren't really in the critical path so those could be allocated.
:
:I'm looking at the case where a signal makes a system call: you don't 
:want it re-using the buffer that the system call it interrupted used,
:so the wrapper would need to do something like:
:
:	if(in_a_signal_handler) {
:		msgp = ...->td_sigmsg;
:	} else {
:		msgp = ...->td_sysmsg;
:	}

    That would work, but I would prefer to keep the main stream system
    call code clean, so a better way would be:

    struct lwkt_thread {
	...
	union lwkt_sysmsg	*td_sysmsg;
	union lwkt_sysmsg	td_staticmsg;
    }

    initthread() {
	...
	td->td_sysmsg = &td->td_staticmsg;
    }

    Then the signal handler would replace the message structure for the
    purposes of the signal function, and restore it when the signal
    function returns (disregarding longjump for the moment):

    master_signal_handler()
    {
	union lwkt_sysmsg *save = td->td_sysmsg;
	union lwkt_sysmsg stacked_msg;

	td->td_sysmsg = &stacked_msg;
	initmsg(&stacked_msg); ...

	call_user_signal_handler();

	td->td_sysmsg = save;
    }

    Then the system call code doesn't have to check.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>