[openbeosnetteam] Next milestones?
- From: Philippe Houdoin <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 30 Oct 2002 17:21:15 +0100 (MET)
Here some milestones I think we should aim now.
A) Complete the build
- libnetapi.so
Due to wrong/outdated BNet* classes headers files in /current/headers/os/net,
this library don't build fine yet.
Scott should send us his BNet* classes implementation, headers included, by
this week end.
- command lines apps (ifconfig, ping, etc)
There is no action in these's command line apps respective Jamfiles.
But I guess it will involve some code change. Based on what I saw about
Marcus recent changes, I bet some #include "..." will have to be
turn into #include <...>. But what else?
B) Make the stack running again
- core module can't find & load any modules currently at startup:
The prefixes used to iterate the interfaces & protocols modules are wrong:
"network/protocol" and "network/interface" when it
should be "network/protocols" and "network/interfaces", respectivly.
- Check that all required modules are there. I fear having forgot to move
the "route" module, but it looks like it was obsolete. Maybe it was not,
dunno.
- name resolution (getaddrbyname() & co in libnet.so) was reported as
broken/unfinished IIRC. Who want to fix that?
C) Make coexist friendly kernelland vs userland stack
- /dev/net/stack entry conflict between the two *stack* driver
As graphics speak 10x better than words:
kernel stack current design
http://philippe.houdoin.free.fr/phil/beos/openbeos/obos_net_stack_design_1.gif
userland stack net_server/debug platform design
http://philippe.houdoin.free.fr/phil/beos/openbeos/obos_net_server_design_1.gif
The green parts *are* where the real stack job is done.
In both designs the code of these parts (modules) is identical, except few
kernelland or userland limitations that should be/are inclosed by
#ifdef _KERNEL_MODE ... #endif.
In both design, the libnet.so talk to a *stack* driver, which can be seen as
the stack upper interface for libnet.so. This interface is defined in
headers/private/net/net_stack_driver.h.
We've two stack drivers, first one for the kernelland stack design,
the second for the userland/net_server like design.
Both of them publish the /dev/net/stack entry required by libnet.so.
Only one could be active at a time, or we've a conflict in devfs, which is
never a good thing to see!
I suggest to change the userland stack driver to publish a different
entry, /dev/net/server for example. Some may have notice that, in fact, I've
already renamed net_userstack_driver.c into net_server_driver.c in CVS today
(but forget to update the entry name!!! 'will fix that tonight).
- "/dev/net/stack" is currently hardcoded in libnet.so
Obviously, we can't use anymore a hardcoded "/dev/net/stack" dependant
libnet.so if we want to have two stack drivers up & running.
In libnet.so code, there is a very few places (socket(), accept(), r5_select())
where we need to know the stack driver path, why not write a simple
get_stack_driver_path() like this:
char * get_stack_driver_path() {
char * net_server_driver_path;
// user-defined stack driver path?
path = getenv("NET_STACK_DRIVER_PATH");
if (path)
return path;
// use the default stack driver path
return NET_STACK_DRIVER_PATH;
}
And on the few places we need the path, do:
socket = open(get_stack_driver_path(), O_RDWR);
It will give us one single libnet.so and the ability to have both stacks
running (at least, their loopback interface, because without two net cards, the
first one started will acquire the card driver...) at the same time, and tell
libnet.so to use the userland design simply by a:
$ export NET_STACK_DRIVER_PATH=/dev/net/server
What do you think? Do I totally lost my mind?
D) Code cleanup
- All stack modules, starting by "core", use cryptic functions & variables
names. It doesn't help newcomers, and even veterans don't always what the
meaning of one name he may encounter walking the code.
Nobody want to (have to) read it, and I totally understand that! ;-)
I suggest that we rename the module exported functions (the one in his
module_info structure), from top to bottom of the stack.
Let's start with "core", and then dive more deeper.
Marcus, Axel and I agreed to rename a socket_create() in place of socreate(),
and more generally to rename into <c module name>_<verb>(); and variable names
SHOULD means SOMETHING. sb_q0 don't. It doesn't help understand the code.
E) DHCP support
I'm not sure how it could be integrate, but most of us agree that we should
reuse some BSD code. Could someone (Valentin?) look deeper
on how BSD DHCP is designed (userland, kernelland, client/server, etc) ?
F) DialUp support
Well, David added a first PPP support. It's not moved under /current in the CVS
yet, but I'll import it soon. AFAIK, he wrote a serial_ppp interface module, a
ppp protocol module and some CHAP & co PPP module-specific sub-modules.
G) GUI Preflet
It's not in the CVS, as the one currently there is a full clone of vanilla R5
one, which can't be reused. Evan sent me his skeleton some months ago, I could
import them into CVS, but where? Should we create another src/prefs/network2
folder?!?
We've already two Translator preflets build, I guess we don't want another
duplicate...
H) Update the team tasks web page
I'll do it tonight.
Should be enough to busy all of you for last 10 years.
Not all these share the same priority, thought.
Feedback welcome, as always.
-Philippe
Other related posts:
