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

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Wed, 13 Nov 2002 17:27:25 +0100 CET

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

> d) command line apps all build (again)
>   Jamfiles appear, then they build. That's magic.
>   However, for both ping and traceroute, I've to hack a howmany() 
> macro 
>   over the _howmany() one defined insys/select.h. Who is right here, 
>   howmany() or _howmany()?

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.

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

>   My main focus. So that we could see internal code running/crashing, 
>   learn how it (expect to) works, understand it, and then make 
>   it really works as expected. Or dump it and rewrite it.
>   Hopefully, only partially.

True enough :-)

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

>   - Continue to rename cryptic function names here and there.
>   s/function/macro/ on previous line.
>   - Locking where it's lacking. Or the reverse!?! :-)
>   - Make inter-module shared variables really..., well, shared!

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

>   - Reduce usage of global variables when possible, serialize access 
> to them 
>   otherwise

If needed.

> And that pretty much all for today.

Nice work!

Adios...
   Axel.

Other related posts:

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