FreeLists / openbeosnetteam / [openbeosnetteam] Roadmap...

["David Reid" <dreid@xxxxxxxxxxxx>]

Given the things have been going on recently thought I'd just try to outline
my thoughts on where we're going and how we should get there...

One word of caution - nothing here is cast in stone!

Select

Using the native select on R5 looks like a dead duck as it's giving big
problems with memory corruption. Philippe is going to try and roll his own
that will get us something that works for R5. However, once we have the new
openbeos kernel I'm hoping that it will have a solid enough implementation
that we can simply export it from the kernel via libroot and use it from
there, saving us a lot of bother. Having said that I'm interested to see
what Philippe produces :)

Documentation

I've been aware for a while that we're not really documenting anything at
present. This is very bad, but given the rate of development we've had it's
understandable. However, I do think that now is the time for us to fix this
and start doing some work on documentation. The doc team isn't as far along
as I'd like so I think for the time being we should simply stick with doing
html conversions of man pages. I've made a start but to be honest I'd like
someone else to take on the task. Volunteers?

libnet

Our present focus has been to get libnet working, and we've been successful
in that it now works quite well. We have a lot of the functions we need and
a lot more besides, which is very cool. Someone needs to go through and
check to see that we have all the functions that libnet.so provided and add
missing ones. Again, a volunteer would be really appreciated.

New kernel

The new kernel will hopefully be upon us before too long. What does this
mean?

1. initially nothing! Nope, we should be able to simply do exactly as we're
doing on R5 and it'll all just work! If we can't then something has gone
wrong and the kernel will need to be adapted. We'll be able to help a fair
bit with this as we do exercise a reasonable amount of the kernel. That said
the initial kernel is likely to be just console so we'll need all of our
great command line apps. the R5 command line apps should also work.
2. The next step (as I see it) is to integrate the headers we need with the
main build tree and move code as required. This will get us building in the
main tree, but I don't think at this point we'll change anything else.
3. Next we start to move into the kernel proper. This will only affect the
core (net_server directory) as the individual modules will still be separate
and loaded at run time. It's at this point that some functions will
hopefully move from libnet to libroot. Now, I don't think this will cause
any binary compat issues as libroot and libnet are both loaded by apps under
R5, but will start to provide a better platform to move forward with.
However, I may be wrong about this :)

Starting/Stopping

One element that has yet to be resolved is how we start/stop the stack once
in kernel. I've got some changes in mind for the way we currently do things
that I'll try to get to soon that should make this easier. Basically once
we're in kernel, even as a module, we can't really be unloaded. The
interface and protocol modules are however another thing altogether. I think
we should aim for loading the core at start-up and then have it sit dormant
until we actually configure something. At that point we load the protocols
and the threads start. If we decide to stop the stack then we simply stop
and then unload all the protocol and interface modules. This will leave the
core still loaded, but that's not a big issue. Of course we also have memory
management issues to manage and those will need some thought (draining the
pools to start levels once we've stopped all modules is an example that
jumps to mind). I think this is the way to go and means we can use
B_KEEP_LOADED in the core and not in the modules. The change I have in mind
will actually bring this is in anyway, so it won't be a huge change.

PPP

We can't put this off forever and so sooner or later we're going to have to
start looking at adding this :) Suggestions are welcome as to the
"architecture" to use and documents to refer to. I'd like to think we'd aim
for ppp, pppoe and pppoa. For the latter we'd need an atm module, which
might also be used by network cards, and that may affect the thoughts on
architecture?

Anyway, enough spouting from me. Please let's discuss the contents, but try
to reply with a subject line more appropriate and don't just reply to the
entire mail in one go as it covers too much ground for that. Be interesting
to see who read this bit won't it?

david