[openbeosnetteam] Re: Dynamic Modules!
- From: "David Reid" <dreid@xxxxxxxxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Mon, 11 Feb 2002 12:03:40 -0000
> > 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.
Well, I agree but to be honest I couldn't think of another way :(
Basically we want to be able to add modules at will, the ordering shouldn't
be important, so the 10th module loaded may be the one that a packet wants
to use first, so we need some way of linking them.
> 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.
True.
> 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).
That's in the comments :)
>
> 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.
I thought about that but it gets very messy! For instance, the ipv4 module,
it can be addressed from below (link level) and above (tcp/udp) and in fact
the same layer (icmp)! Given this I decided a single large protocol table
was the sensible way to handle it. If this can be fixed I'll be very happy!
> 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... :-)
Oh, didn't realise they don't need the .so - but that can/will be changed!
>
> 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.
Hmm, well how else would we do it? If we adopt the approach that we only
open the ones the user has asked for in preferences, then we're back in the
problem that when we add a device we don't see it until we go to the
preferences panel and actively select it on. that's very windoze/unix and
I'd rather that if we can actually use a card then we do. BTW, what does the
last line mean?
> 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.
I agree about the moving to kernel, but didn't follow the comment that
followed!?
david
Other related posts:
