DragonFly kernel List (threaded) for 2003-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: userapi: message versioning
:Matthew Dillon wrote:
:> My current thinking is to make the emulation layer responsible for
:> all version matching.
:
:> Here's the idea... all binaries in the system will generally be tagged
:> with a build version using a non-debug symbol in the binary and/or
:> tagged in the ELF binary or as a file attribute.
:
:Will this work for statically compiled applications?
The emulation layer runs in userland but is managed by the kernel. Static
vs Dynamic binaries are irrelevant. From the userland's point of view
(for programs that are compiled natively) the emulation layer is simply
a more convenient way of doing a system call.
:> For the kernel messaging side of things I propose that all system calls
:> which transfer complex structures, such as stat*(), getdirentries(),
:> etc... take and return data as a resource list rather then as a static
:> structure.
:
:The userapi would be responsible for translation to and from the
:resource list?
:That would be pretty slick, the resource list would automatically be the
:template I was thinking about earlier, and marshalling the message for
:transition to MachLand or passing it over the network would be almost
:trivial.
Correct. The emulation layer provides standard unix calls to the userland,
like stat(), and will be responsible for taking the list results from the
kernel's stat() and loading up the stat structure with them.
Very trivial, and both forwards AND backwards compatible. We would be
able to add arbitrary elements to what the kernel stat returns and the
emulation layer will simply ignore what it doesn't understand.
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]