FreeLists / openbeosnetteam / [openbeosnetteam] Re: Networking Next Steps

[Oliver Tappe <openbeos@xxxxxxxxxxxxxxx>]

Hi,

On 2006-06-17 at 13:44:19 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
> 
> 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.

Good idea, that.

BTW: I wonder if we should implement our new stack in C++ instead of C (to 
gain type-safety, inheritance and stack-based locking for instance)?

> 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").

Yes, so what exactly do we want to live in the core? As you mentioned that 
you would volunteer to work on a net_buffer *module*, the core should 
contain only the layering code that dispatches net_buffers to the protocols 
and the code that loads all the modules, right? 

[ 8< ]

> 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

Agreed, can't we just keep/update our current public (FreeBSD) headers and 
throw away the private ones?

> - 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

I personally have nothing to complain about names like net_dl_proto, but 
net_datalink_proto would be ok, too.

> - 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.

Yes, I'd prefer the protocols to live separately, too.

> 
> 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?

Fine with me.

chees,
        Oliver