FreeLists / openbeosnetteam / [openbeosnetteam] Re: Status

[Philippe Houdoin <philippe.houdoin@xxxxxxx>]

Quoting Marcus Overhagen <marcusoverhagen@xxxxxxxx>:

> Axel Dörfler  <axeld@xxxxxxxxxxxxxxxx> wrote:
> > In the longer term, I would prefer a BONE like architecture with a
> > useful separation of code and functionality into modules. That's why I
> > would like to do this transition module per module.
> This is what I also would like to have.
>
> Including a module that provides a socket api for use inside the kernel,
> and a module that provides native access to mbufs so that drivers can
> bypass the read/write driver hooks.

Oh, yes, this kernel module to provide the socket api to any kernelland code
(drivers, network file systems, other kernel modules) was planned and is an
open task, btw. Dunno if it should include DNS client API (gethostby*() and
like) too or not...

Allowing network devices drivers to directly connect to our stack is already
supported: just (re)write the driver as a network interface module. Basically,
it means to add to the drivers a module_info and move their read/write hook to
the corresponding net_module interface hooks.

> I planned to work on a mbuf like structure to handle all packet data inside
> the stack,
> extending it to better support memory alignment constrains, jumbo frames, and
> optaining of physical addresses during initalization of the buffer queue,
> instead
> of each time a buffer is used. However, I have postponed that now, to not
> interfere
> with Andrews work.

I've made in the past a lame attempt to work on a bone_data like structure which
was supporting attributes to packets, and David Reid wrote also something to
replace mbufs for his (dead?) Marrow project.

I can't personnaly stand mbufs because, as much as BSD stack code, it's macros
ridden, many of them having a cryptic name. But as any network stack aim is
being able to pass as fast as possible huge amount of packets, it's a central
object to implement right.

> > What parts of the stack do we want to adopt? I guess net/netinet are
> > the minimum of what's required (possibly netgraph, too, dunno about the
> > references yet).

netgraph is an whole alternative "graph oriented" modular network stack.

- Philippe