[okl4-developer] new Wombat syscall and others

[Jorge Torres]

Hi Ben,

I can see your point, and it is true, it turned out to a little more than
one might think at first.
But I thought it to be a good idea since I could provide a much more general
solution  for Wombat's user threads to use the L4-API,  due to I could
simply "clone" L4 syscalls onto wombat syscalls, and at the same time make
wombat kernel aware of such things, ie:

syscall womabt-l4Call(from, to,msg)=>
    wombatScheduler->send_to_block_queue(from)
    create_new_thread.....
    ===on newthread==>
           loadmessage
           tag=l4_call(to)
           wombatSched->trytowakeup(from)
           return tag

Or something like that, any how, that was the intention, and it could be
something close to the Native Mode linux process you explain in your wombat
paper I mentioned before, and also forwarding syscalls may not require much
code, and once such new syscall is proved to be correctly implemented, it
will avoid VERY UGLY CODERS like me getting their hands on kernel space,
still it could be done by adding a module for it, but I don't see syscalls
idea too bad is it?, anyhow I'll go the way Ben suggested and see how I like
it.

Cheers,

Jorge


On 6/19/07, Ben Leslie <benno at ok-labs.com> wrote:
>
> On Tue Jun 19, 2007 at 11:00:30 -0400, Jorge Torres wrote:
> >Hi okl4.org,
> >
> >About adding syscalls to the base ABI:
> >On 6/12/07, Carl van Schaik <carl at ok-labs.com> wrote:
> >
> >>Alternatively, you can add extra syscalls to the base ABI. The base ABI
> >>depends on the architecture, eg ARM L4 uses ARM compatible syscalls.
> >
> >I decided to add a new syscall to the base ABI, to test a proxy by
> syscall,
> >not by module. I compiled and it all went OK, but when I try to call it
> from
> >a Wombat's user application  I get:
> >----------------
>
> >/home/jetorres/cool/okl4_release_1.4.1.1/linux/apps/busybox/coreutils/yes.c:57:
> >error: `__NR_testcall_register' undeclared (first use in this function)
>
> >/home/jetorres/cool/okl4_release_1.4.1.1/linux/apps/busybox/coreutils/yes.c:57:
> >error: (Each undeclared identifier is reported only once
>
> >/home/jetorres/cool/okl4_release_1.4.1.1/linux/apps/busybox/coreutils/yes.c:57:
> >error: for each function it appears in.)
> >make[1]: ***
> >-----------------
> >Im trying to call it with:
> >syscall(__NR_testcall_register,0,0,0);
> >and headers #include <unistd.h>, #include <sys/syscall.h>
> >I've also tried with syscall(SYS_testcall_register,0,0,0); or
> >syscall(testcall_register,0,0,0); or
> >_syscall3(int,testcall_register,int,0,int,0,int,0);
> >
> >But I get the same error,  Does somebody knows why is that?
>
> Hi Jorge,
>
> The problem is that these symbols do not exist within the headers
> that are part of the Linux compiler toolchain. The changes you made
> are only going to affect the compilation of the kernel itself, and
> won't be reflect in the user applications.
>
> The reason for this is that the toolchain is compiled in such a way
> that it bound for a particular set of kernel headers. To change this
> you need to change the headers that are used by the compiler itself,
> as well as the headers made visible to the compiler. For a cross
> compiler this means editing the headers that are found under the
> cross compiler directory, if you are using a native compiler, then you
> will need to edit the files in /usr/include (which is probably not
> such a good thing to do.)
>
> I would recommend against using a new system call (for the difficulties
> presented above), and instead recommend presenting a character device
> interface, which is usually quite simple to provide. The O'Reilly Linux
> device drivers book gives quite a good treatment to this, including how
> to hook up ioctl()s.
>
> Cheers,
>
> Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20070619/752cd87b/attachment.htm