Re: Reviving userland LWKT

[Eric Jacobs <eric@xxxxxxxxxxx>]

On Wed, 12 Jul 2006 13:46:45 -0700 (PDT)
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:

> 
> :
> :Hi all,
> :
> :I'm interested in bringing back to life the port of LWKT to userland
> :(the old "libcaps") - I know a lot of this stuff hasn't been a high
> :priority for quite some time, but it was a cool unique Dragonfly feature
> :and I'd hate to have it go to bit-rot as the rest of the system
> :continues to mature.
> :
> :So, anyone have any ideas, suggestions or requests going out? I realize
> :the sysport/sendsys stuff has been removed and I am prepared to deal
> :with that (I'm not sure it ever worked anyway, did it?) My plan of
> :attack focuses on usermode<->usermode intraprocess and interprocess
> :messaging first, leaving the whole issue of what to do with the kernel
> :interfaces for last.
> :
> :Thanks,
> :-Eric
> 
>     Instead of doing that, perhaps you would be interested in something
>     even MORE interesting, but very similar -- userland VFS!
> 
>     We need a stream based command/response mechanism that basically
>     works similarly to the current filesystem journaling protocol but
>     allows bi-directional command initiation, parallel commands, etc etc.
>     Initially I just want the protocol to operate over a pipe or socket,
>     and not via shared memory, but the protocol also has to eventually
>     be extensible to a shared memory FIFO implementation which creates
>     certain limitations.

In actuality that is very similar to ideas I've been throwing around
regarding the messaging implementation. I'm a big fan of TLV-based
protocols, and idea just recently occurred to me also to have the
lower-layered protocols interpret the leftmost X bits of the type field
to decide how to translate the message for transmission while the
detailed format of the message remains opaque. Fantastic!

>     --
> 
>     Ok, that may be somewhat confusing, but hopefully you can see what I
>     am getting at.  This is a big ticket need for DragonFly... we need 
>     it for a userland VFS implementation, and we need it for inter-machine
>     links in a cluster.

It makes a lot of sense actually -- I will take a closer look at the
details. I did not have VFS as a particular application in mind; I
wanted the protocol to be general, but VFS is certainly applicable.

My big question for you is why do you mention this idea as alternative
to the idea of implementing LWKT? It seems like LWKT would be a
necessary platform to build this kind of service on. What would the
userland VFS drivers use for m:n threading and asynchronous requests?

 -Eric