DragonFly kernel List (threaded) for 2008-07
DragonFly BSD
DragonFly kernel List (threaded) for 2008-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Adding new syscall

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Jul 2008 21:14:32 -0700 (PDT)

:      I added few system calls for the scheduler and they are working fine. I had to use syscall(); function to execute the system call. I want to know how do i invoke the system call from the command line, because the when i enter the command on the prompt it says 'the command is not recognised'.  

    If you add the system call to /usr/src/sys/kern/syscalls.master,
    and rebuild the sysents with 'make sysent', then you should be
    able to do a 'make buildworld' and 'make installworld' in /usr/src
    and libc should automatically end up with the entry points for the
    new system call.

    All you would need to do then is supply the prototypes.  For example,
    the userland prototype for usched_set() is in sys/usched.h.

:     Secondly, In the scheduling algorithm there is one invariant which requires a floating point operation. Currently i have approximated it, but i want to know how do you get around such a situation in kernel. What is the best way i can approximate this floating point operation.

    Basically the answer is: You don't use floating point in the kernel.
    It's a real mess.  DragonFly does use floating point in the bcopy
    code but it requires a mess of save/restore code because the FP state
    and registers are not saved on entry to the kernel and still reflect
    state that userland will need on return.

    So you need to come up with a solution which does not require floating
    point.  Depending on what you are doing, an approximation will probably
    work just fine.

    I haven't seen your new system calls.  I'm assuming you are familiar
    with with usched_set() and setpriority() system calls.  If you need
    a more fine-grained control you can add another syscall, but it needs
    to operate within the usched infrastructure (get dispatched through
    the usched, etc etc), even if the other schedulers just return EOPNOTSUPP
    for that patricular request.  Try to make the syscall API as flexible
    and general as possible.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]