[openbeosnetteam] Re: Change of heart...

  • From: "David Reid" <dreid@xxxxxxxxxxxx>
  • To: <openbeosnetteam@xxxxxxxxxxxxx>
  • Date: Tue, 5 Feb 2002 16:19:32 -0000

> I agree :-)

Good.

> This is what I think it is the better for the moment, getting experience
and
> continue to make the BeOS 5 keep "alive" with a network stack replacement:

Hmm, well let's try to be more objective and focused on what needs doing!

This is a first hash at some milestones/ordering of what needs doing.  NB
this is a discussion item!

1. basic infrastructure.
By this I mean network buffers (mbuf/skbuf type implementation), interface
details to/from existing network drivers, how modules interact, etc etc
This should get us to a point where we can actually get data from/send data
via a nic, and have some sort of basic module loaded instead of the existing
net_server (even though it won't do anything but test)

2. link level layer
So, now we can get packets we start actually trying to do something with
them. This involves determing the type of packet and what it contains, then
routing accordingly.
modules: ethernet,

3. network layer
We got a packet, but what is it? Again, look at packet and decide what to do
next. This includes routing.
modules: ip, arp, icmp

NB I'd also like to build in a dhcp client service so that we don't have to
run a seperate application to fulfil dhcp client services.  I think it
belongs in this layer.

4. transport layer
How do we get the contents of the packet to where it's required?
modules: tcp, udp

5. application layer
Move the data to/from the user.
modules: sockets, libnet C++ wrapper

Now, I've used ip as meaning ipv4 as the intent is to replicate what was
offered by the net_server.  If we decide to expand on that, then great, but
for R1 this is really what we're talking about (IMHO).

I have some ideas about how this should work, which I'll try to outline
here.  Be aware I haven't actually got a total working blueprint in my head!

- each network card driver is a module
- each network component is a module (as far as practicable)

o When we start, the system loads and adds the network drivers as requird.
o When the net stack starts it goes through all the devices and modules and
allows every device driver the chance to init every module. This would mean
that the ethernet module would be offered to every device, even if it's a
ppp link. During the init such things as addresses are setup and
configuration takes place.
o The entire net stack can be stopped. Once restarted the entire collection
of modules, including the network drivers, should be reloaded and the entire
init process done again.  Don't know if this is possible.
o Every module should be as self contained as possible and will live in it's
ownd irectory with all private headers and so on in that directory. Public
headers live somewhere else (not sure where??).
o No module can make assumptions about subsequent or previous modules.

I'm sure there's loads more that I should add, but that should be enough to
kick off a discussion.

We should probably try to get together in IRC to discuss this more.  I'm
around (UK time) Friday afternoon thru Tuesday morning.

david
>
> - Preference Pannel;
> - API for UDP/TCP/RAW endpoints;
> - IP/ARP/ICMP+UDP/TCP+DHCP+PPP and PPPoE;
> - Multiple device driver interfacing and management.
>
>      Emmanuel
>
> ----- Original Message -----
> From: "David Reid" <dreid@xxxxxxxxxxxx>
> To: "OpenBeOS Network Team" <openbeosnetteam@xxxxxxxxxxxxx>
> Sent: Tuesday, February 05, 2002 12:46 PM
> Subject: [openbeosnetteam] Change of heart...
>
>
> >
> > Folks,
> >
> > I've had some email from people recently about the approach we're taking
> and
> > combined with some other things I'm afraid to say I've changed my mind
> about
> > things.
> >
> > Don't get me wrong, I still think an kernel land stack will be the way
to
> > go, but I think it's a long way off and for obos we really should be
> > considering the nearer future. Considering the nearer future basically
> means
> > that we look at creating a userland network stack that's compatible with
> > beos 5.
> >
> > While this is a change of course, as we've not really done much so far
it
> > isn't a big change is it? :)
> >
> > The change will also lower the entry requirements for everyone and
> hopefully
> > start to provide soem code that people can work on in a familiar
> environment
> > rather than having to jump into a totally new environment at the same
time
> > as trying to wrestle with the complexities of a network stack.
> >
> > When we get towards an R2 release (if we ever get there) and we're using
> the
> > newos kernel then we can look at moving over to a kernel based stack,
> which
> > should be much easier having already done the userland code and having a
> > bunch of people used to working with network protocols.
> >
> > I realise this is a change, but think it's one we should make.
> >
> > david
> >
>
>
>


Other related posts: