[openbeosnetteam] Progress report
- From: "David Reid" <dreid@xxxxxxxxxxxx>
- To: "OpenBeOS Network Team" <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Wed, 13 Mar 2002 11:55:49 -0000
So, here's the progress report before I head off to Philly for a couple of
days...
We can now build ourselves as a kernel driver. This is temporary but the
code is in CVS and so people interested are invited to look at it and
comment. This is the start of allowing ourselves to be very cool and do all
sorts of stuff, as well as simplifying our i/o with regard to running as a
process. developing our own IPC so we could be running the net stack in one
team while other teams used the services was looking like a PITA and would
have been a performance drag in the extreme. So, the solution?
Basically we'll build the stack in a series of pieces that live in the
kernel.
- socket driver - this will be built mainly from code that is already in
place in net-server/net_server.c, albeit it'll be removed from there and
added to a separate file that will build a simple socket driver. This is
responsible for creating a /dev/net/socket entry and handling requests
to/from that socket. When started for the first time it will load the
net-server kernel module.
- kernel modules - these will be everything else. All the existing modules
need to be rewritten to allow them to be kernel modules and then we need to
decide where they should be installed. Once we know we can start making more
changes. there will be a central "core" server that will be what we have in
net_srv at the moment (net_server/net_server.c without the test stuff) and
this will be responsiblke for opening the other modules and handling
communication between the socket driver and these modules.
The modules will all have the flags set so they stay in memory, but of
course we should be abel to unload them as required. Don't think this is an
issue.
Issues
- What functions do we need in the core module? Basically what do we want to
export and how does the socket driver talk to the core module? We need ioctl
for sure as that's how most of the functions work, and we'll need an
init/uninit (or do we want to call it start/stop) but can anyone think of
other things we need?
- locking will need to be reviewed and probably implemented in a slightly
different way in a lot of places due to being in kernel. Also we need to
make sure we're thread and MP safe throughtout the code we have (I know
we're not in places at the moment).
- domains. We need to review how we actually register modules and then keep
track of them in light of the move and the need to be able to create sockets
using their domains and so on. This isn't important and I suggest we do it
once we've done the above. I have some ideas on this.
- we need to add a make install once we decide where to put the modules
Todo
Well, the above really! First things to be done I think are as follows...
1. create the new socket driver and get it working.
2. get the core code we have working as a kernel module
3. start getting the other modules working as kernel modules and figure out
where to install them
Notes
We need to remove exit() from the code as this isn't allowed in kernel. Look
at better ways of logging what's going on. get ready for some nasty
debugging experience and dig out the old serial dbeugging cable as this is a
truly useful tool to use.
http://bedriven.be-in.org is a useful resource for kernel stuff.
We should add a defines to hide the complexities of what we're doing such as
#ifdef _KERNEL_MODE
#define START_THREAD kernel_spawn_thread
#else
#define START_THREAD spawn_thread
#endif
and look at adding more such defines so that we can carry on in our hybrid
userland/kernel way of working for a little longer. It'll be useful if we
can come up with a way of allowing us to build both. maybe we should have
make / make kernel / make installkernel as options available?
I don't underestimate how hard this will be, but this is starting to look
like it'll give us what we want. the logic fits well with the BSD model
we've been using and in fact the code we have should allow rapid development
in places.
david
Other related posts:
