[openbeosnetteam] Re: Dynamic Modules!
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Mon, 11 Feb 2002 12:43:12 CET (+0100)
> Well, we now have dynamic modules!
That's nice :-)
> global=5Fmodules[protocol=5Ftable[proto]].mod->(input/output)(...)
>
> Not perfect, but it seems to work and is what Dmitri and I discussed
> this
> afternoon in IRC.
I am not *so* happy with the protocol=5Ftable structure, although I am
not sure how to fix it properly. The disadvantage is that you have to
know everything that comes after you - and using the NS=5FETHER/...
stuff, that makes a very static architecture, that doesn't really have
to be add-on oriented.
And you should really test if net=5Fmodule[].mod->input is not NULL
before calling it, or maybe initialize it in the server to a function
that discards the buffer.
And the module=5Finput() function really should have a pointer to the
interface structure, and if it's for stats only (but there are more,
like some flags).
Perhaps it would be better to have a priority sorted linked list (or
dynamic array) in every layer. But I don't know as much as I should to
know what to do.
And, don't kill me for that, but do we have to change the "standard"
module names and add that '.so' suffix=3F Not that this is really
important... :-)
Finally, I don't think it makes any sense to open every device in the
net=5Fserver (BTW they don't have to be called e.g. /dev/net/tulip/0; /1,
or tulip0 are also valid, so every "file" should be opened regardless
of its name) - if BONE or the net=5Fserver would do this, we couldn't
write a networking stack at all, because you would have to kill them
before.
BTW AFAICT, we'd just have to move our modules to kernel modules to
compile and let run this thing completely in the kernel (of course
something would have to start the server, then). I guess this won't
change if we're keeping that coding style.
Adios...
Axel.
Other related posts:
