[openbeosnetteam] Re: mbuf.h
- From: Philippe Houdoin <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Tue, 23 Sep 2003 10:36:14 +0200
Waldemar Kornewald take time to read my reply:
> > Oh, once again, here come globals variables *definitions* instead of *
> > declarations* in a header file.... Pfff.
>
> Is this not the first time?
Alas no, we (Marcus and I) have already find other same situation.
> Okay, but all modules that include mbuf.h will want to link against something
> that *defines* those variables, but as they do not link against the core
> (where they are defined (mbuf.c belongs to the core, does it not?)) these
> variables are never defined.
> Where is my mistake?
Nowhere. I'm wrong.
Damn, these globals are worst ever!
Last times, they were only used by core functions, like protosw and domain
linked lists, so nobody outside core module care to know them.
Solution to fix that issue need more consideration.
I don't like the idea of a public variable exported by kernel module api.
Beside that issue, that's global variables aiming to be used *per* module.
max_xxxx variables won't have same value for each network modules using
mbuffers...
Did I say I don't like *mbuf*, by the way!?
BSD/Linux stack is monolithic, where public/non public symbols isn't an issue.
With our modular design, we can't do that, we need a public way to set and get
these maximum headers sizes. Per module using mbuf.o services, in bonus, as not
every network module will share the same maximum headers sizes...
:-(
> > From mbuf.c::mbinit().
>
> I think I do not understand. :)
> I thought that mbinit() lives in the core. There is no copy of this
> initialization living in _each_ network module like tcp, etc.
> Could you please explain to me why this will work?
You perfectly understood, I'am the one replying too fast on this topic with
enough consideration. Sorry.
> Should not the declarations go into a private header in the core's
> directory?
These variables are, currently ( :-( ), required by mbuf.o and non-core network
modules tcp and ipv4. I guess that why they ends there in the first place.
But it's a bug, clearly:
the core module
> > > Can tcp and ipv4 use them? Does this not result in undefined values
> > > for max_xxx?
> >
> > No.
>
> No to the first question? :))
Hum... I need to look at this issue better before being able to keep a position
on this question ;-)
But whatever it will, these maxumim values should be handled better than thru
this mess.
-Philippe
Other related posts:
