[openbeosnetteam] About Kernel API userland emulation issues
- From: "Philippe Houdoin" <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sat, 10 Jan 2004 15:47:25 GMT
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: