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.