
|
[openbeosnetteam]
||
[Date Prev]
[11-2002 Date Index]
[Date Next]
||
[Thread Prev]
[11-2002 Thread Index]
[Thread Next]
[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.
|

|