Re: Userapi, Reflection

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:All,
:
:   I have been contemplating how the useapi portion of the project will work
:(for those not farmiliar please see
:http://www.dragonflybsd.org/Goals/userapi.cgi).  What I think would be quite
:impressive would be a process that uses reflection (java and c#).  Reflection
:is an api that allows for the creation of types, functions, and classes at run
:time.  Please see http://java.sun.com/docs/books/tutorial/reflect/index.html
:for information how java does this.
:   The idea for userapi would be to use reflection to create callable
:prototypes for systemcalls at run time.  Say we have our special user level
:process that handles system calls.  It is invoked by the kernel like init.  It
:will have a configuration file, containing prototypes for every system call it
:knows how to handle.  If linux changes a prototype for one of their system
:calls, the configuration file could be modified accordingly.  On a SIGHUP the
:process would re-read the configuration file, and modify the prototypes
:accordingly.   The idea is that you could modify, add, and delete system calls
:at runtime, without ever rebooting the os or modifying any code at all.
:   This is just a thought I had.  It is possible that it is infeasible, but I
:thought I would throw the idea out there and see what other might think of it.
:
:Regards,
:Galen Sampson

    Well, I guess the question is:  What type of run-time entity would
    use these prototypes?   I can see adding and removing support for
    particular system calls in libc.so dynamically, but the programs that
    link into libc would have no visibility into the changes after the
    fact.  That is, you would still have to either restart an application 
    or start an application dependant on a new system call after having
    loaded the configuration for the system call.  This doesn't seem much
    different then reinstalling libc on a live system.  Applications are
    still going to hardwire their understanding of a particular syscall's
    API.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>