[openbeosnetteam] Re: One small step for net team, but... but one small step forward?

  • From: Philippe Houdoin <philippe.houdoin@xxxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Wed, 13 Nov 2002 18:19:34 +0100 (MET)

Quoting Axel Dörfler:

> Philippe Houdoin <philippe.houdoin@xxxxxxx> wrote:
> > Small changes on the net team front.
> > a) kernel and userland driver conflicting on /dev/net/stack entry
> > b) libnet.so
> > c) libnetapi.so
> 
> Very nice, I think that's a good solution (though it probably should be
> disabled in production code ;-))

Agreed.
Hence the use of "stack debug platform" here and there ;-)

> BONE obviously uses howmany(), but recent BSDs are using _howmany() - 
> which I would be in favor for (to not reserve the name howmany), that's
> why I've done the select.h header in that way :-)
> I would just rename the macro in the applications.

Okay, here what I add in both ping.c and traceroute.c, right after 
including sys/select.h:

#define howmany(x, y) _howmany(x, y)

Maybe I should directly use _howmany() instead.
BTW, it make me think that my R5 select() for socket support is buggy 
if the caller use a differently sized fd_set than the one used at libnet.so 
build time. I should fix that some day. I guess I can *steal* some 
stuff from your kernel select() implementation 
(storing the max set size, etc) no?

> >   I start to remove as much as possible of userland-specific code 
> >   as the userland net_server provide all modules API support from 
> >   userland too, modules no need anymore to load by themselves 
> >   sub-modules.
> 
> How is that done?

Well, the so-called "stack debug platform", aka net_server export 
the modules API (get_module(), put_module(), open_module_list() & co).

Give a look at userland_modules.cpp, part of net_server, in:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/open-beos/current/src/tests/servers/net/net_server/

Network modules link against kernel find this modules API in _KERNEL_, 
and will find same in net_server as soon I manage to build them
as userland add-ons.
 
> >   Unfortunnatly, currently:
> >   - I couldn't manage to (re)create the symlink at build time 
> >   *before* running the "Addon" rule on them. 
> >   Please, Jamfile guru(s), help me! :-)
> >   - network modules code are not yet buildable as userland add-ons.
> 
> What exactly are you trying to do? I mean why do you need the symbolic
> links?
> What's the plan?

I really don't want to duplicate code of each network module 
in another place in the CVS tree simply to be able to build it 
as userland add-on instead of kernel add-on.

But, as most of Jam rules use the Jamfile relative location to 
create both objects/... and distro/... trees, I can't put 
the userland build in the same Jamfile than kernelland build.
More specificly, I did try to change the 
/current/src/add-ons/kernel/network/core/Jamfile (for example) to build as 
userland add-on 
instead of kernel add-ons like today that way :

if $(NET_SERVER) {
  Addon core :
     core.c
     ...
   : root ;

} else {
  R5KernelAddon core : ...
}

But, as the SubDir directive at top is the same, the *.o files where 
generated in the same place, which is bad!

So, the plan is:
- create a specific directory for each userland network add-ons under 
  src/tests/add-ons/net_server/core, etc
- write a Jamfile to build the module as userland add-on
- NO DUPLICATED code, but instead symlink to the source code files 
  in the corresponding src/add-ons/kernel/network/core/ & co.
  Obvioulsy, I can symlink manually (and locally), but CVS being what 
  he's, I want to do this a build time.

That way:
- garuanted shared code
- different build settings

I've at home something starting to works that way, except that I failed 
to (re)generate symlinks to shared source code *before* building each 
network modules as userland add-on. The symlinks are created 
*after* all rules applied. Okay, build them running jam two times is NOT 
an option here!
:-) 

> Shame on David for the mess he created in this regard :/

Created or imported from BSD, it's not easy to know.
Whatever. 
Seems that *messness* is required for a network stack these 
days... ;-)
 
-Philippe

Other related posts:

  1. Home
  2. openbeosnetteam
  3. Archive
  4. 11-2002