> 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 > > > > >