[openbeosnetteam] About Kernel API userland emulation issues

Waldemar said:

> the reason why jam did not print out the error message 
> when going into the PPP directory is that there is a second 
> place where the whole stuff is built in 
> src/tests/add-ons/kernel/network. This is the userland 
> version and I forgot to add the #ifdef _KERNEL... block to the 
> beginning of the file.

Plus his CVS commit comment:
> I like it better this way. dprintf is not available in userland. ;)

dprintf() *is* available in userland, provided by net_stack_tester app. 
This function is part of userland kernel API emulation support I've 
written.

Precisely, these kernel functions are available too in net_stack_tester 
app:

dprintf
kprintf
load_driver_symbols
spawn_kernel_thread
send_signal_etc
get_module
put_module
get_next_loaded_module_name
open_module_list
read_next_module_name
close_module_list

Those are not yet:

disable_interrupts
restore_interrupts
acquire_spinlock
release_spinlock
install_io_interrupt_handler
remove_io_interrupt_handler
add_timer
cancel_timer
has_signals_pending
snooze_etc
lock_memory
unlock_memory
get_memory_map
map_physical_memory
platform
set_dprintf_enabled
panic
add_debugger_command
remove_debugger_command
spin
register_kernel_daemon
unregister_kernel_daemon
call_all_cpus

Emulatating from userland the hardware-related will be both hard and 
useless for us, as our network stack modules are not hardware oriented 
code. And network card drivers run in kernelland in both real stack and 
net_stack_tester based, so no issue there.

However, some of these currently unsupported functions would make sense 
in the near future, like 
add|remove_debugger_command or un|register_kernel_daemon, and I may add 
them to net_stack_tester to support them too, and keep modules code 
from being to much #ifdef _KERNEL_MODE bloated...

To sum up, let me put some general principle here:
- kernel hosted stack is our goal
- which means network modules are hosted by kernel
- which means network modules code should be kernel-aware, written 
using kernel API, not the reverse way
- however, the less kernel-only API we use the better
- which means use kernel API only when required

Currently, it means you should write "spawn_kernel_thread", "dprintf", 
etc in module code. It's the userland debug platform task to provide 
this API from userland too, not your job to take care of redefining 
these API to match their userland counterparts. Clean code is always 
better. 

The only exception I know is semaphores ownership: sem create in 
kernelland are own by the caller team, which mean when she dies the sem 
is destroyed too! We can't allow this, so we must change each network 
stack-wide semaphores ownership to B_SYSTEM_TEAM. 
Alas, it doesn't make sense in userland version and, worst, will be 
buggy!

It's why we needs to have this after every stack-wide semaphore 
creation code:
#ifdef _KERNEL_MODE
  set_sem_owner(sem, B_SYSTEM_TEAM);
#endif

Otherwise, modules code could/should be runtime space agnostic as much 
as possible.  
I hope I make these issues a little clearer...

- Philippe

--
Fortune Cookie Says:

A sense of humor keen enough to show a man his own absurdities will
keep him from the commission of all sins, or nearly all, save those
that are worth committing.
                -- Samuel Butler

Other related posts: