FreeLists / openbeosnetteam / [openbeosnetteam] Networking Next Steps

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Hi there,

since we're several people wanting to work on the networking stack now, 
we should lay out a plan on how we proceed, so that everyone can start 
to contribute in a useful way.

Since we are a bit under time pressure to not waste Andrew's work 
force, I think the best way to start is probably to begin with a very 
BONE like architecture. That is, I think should start with a 
replacement for bone_data and start working on the interface level and 
the stuff that brings it all together (previously called "core").

Following the route set by David's Marrow, I would also like to name 
the structures net_data, etc. (or in this case, net_buffer would do as 
well). His docs and design overviews are worth a look: 
http://www.david-reid.com/projects/marrow/design.html 
- even though I don't agree with many things of that design, he also 
discusses some BONE issues.

Anyway, there are a couple of things I don't like about BONE, and that 
is the following:
- the headers are just badly organized, there is no distinction between 
public and private, between userland and kernel headers, it's all just 
thrown together. That example shouldn't set a standard, and we 
shouldn't follow it from the start
- I would like to get rid of acronyms like "if" and "dl" and use their 
full names for structure names and fields; I would also like to remove 
the "if_" or similar prefixes in the structure fields names
- BONE relies on the bone.conf file to build the module "paths" - since 
I can hardly see a reason to ever change this (only if new modules and 
their functionality is added), I would like to hard code this 
information in the respective modules. Having said that, I think we 
should ignore this matter for now, and have the information hardcoded 
into the "core".
- I would also don't mind if protocol modules would end up in a 
different directory than the rest; the BONE directory hierarchy is 
rather flat - but that's also something we don't need to bang our head 
against now.

If no one else does, I would volunteer to start with implementing a 
naive net_data module. If Philippe wants to send me his start, I'd 
prefer to have a look at that, too (maybe we have a similar idea of 
"naive" :-)).

I'll open a new branch for the stack by simply renaming the FreeBSD 
branch, okay?
Does anyone feel like writing a script that lets you switch between the 
branch and the current version of the stack (so that a "jam haiku-
image" will build either one)? If not, I would do that as well, and 
place it in the main branch directory.

Complaints and suggestions are welcome, as always.

Bye,
   Axel.