Nathan wrote: > > > I've been busy lately, so I haven't had to time to look at it. > > > However, > > > as my response has been requested, I feel obliged to at least say > > > something. Perhaps I can remedy the situation by dumping lots of > > > code > > > at you guys: http://members.verizon.net/~vze236yf/ > > > net_server_stuff.zip > > > This code was written in another context, and (for a variety of > > > reasons) is probably slow as hell, but it does illustrate some of > > > the > > > ideas I've mentioned. It also (as far as it goes -- which is a > > > generic > > > ethernet driver and a PPPoE stack) actually works, and does so > > > quite > > > well. I have omitted all of the support libraries, however. If > > > you > > > want > > > them, e-mail me. Maybe that will delay you long enough for me to > > > be > > > able to take a look at yours. > > > > I like the idea, really. I like the idea of "layer names", but failed to understand from code how do you connect each layers between them. Could you expand there? BTW, you try to get the /dev/net/* device max frame size using the wrong ioctl() opcode: int framesize = 0; if (ioctl(fd,ETHER_GETADDR,&framesize,0) <= 0) // <- should be ETHER_GETFRAMESIZE framesize = 1514; Next, having attributs attached to a net packet make sense. Your NetPacket class, seem to follow a bone_data, aka iovec'zised buffers, design. But I'm wondering how we could reuse these ideas without: 1) going full C++ into kernelland :-| 2) importing all your IO::* framework... Currently, if we want to use C++ in kernelland, I think it's better to keep any C++ code invisible from outside, otherwise we'll have the classes heritage issue pointed by Axel. That means having plain C public API. It apply to stack utilities features used by network modules, too. NetPackets falls in this utilities case, don't they? Maybe it could be made simpler for R1? -Philippe -- Fortune Cookie Says: Smoking is one of the leading causes of statistics. -- Fletcher Knebel