Hi, Oliver Tappe <openbeos@xxxxxxxxxxxxxxx> wrote: > BTW: I wonder if we should implement our new stack in C++ instead of > C (to > gain type-safety, inheritance and stack-based locking for instance)? Yes, that sounds nice, even though we're bound to C for the module interfaces, the internals can be written in C++ (I'll do that, in any case). > > Since we are a bit under time pressure to not waste Andrew's work > > force, I think the best way to start is probably to begin with a > > very > > BONE like architecture. That is, I think should start with a > > replacement for bone_data and start working on the interface level > > and > > the stuff that brings it all together (previously called "core"). > Yes, so what exactly do we want to live in the core? As you mentioned > that > you would volunteer to work on a net_buffer *module*, the core should > contain only the layering code that dispatches net_buffers to the > protocols > and the code that loads all the modules, right? I wouldn't mind if the stack module itself would also contain the net_buffer/data module as well as the socket and maybe even the datalink layer. At least that are the basics that are always needed, so it makes sense to put them together in a single add-on (they can still export multiple modules if we prefer to keep them separated that way). > [ 8< ] > > Anyway, there are a couple of things I don't like about BONE, and > > that > > is the following: > > - the headers are just badly organized, there is no distinction > > between > > public and private, between userland and kernel headers, it's all > > just > > thrown together. That example shouldn't set a standard, and we > > shouldn't follow it from the start > Agreed, can't we just keep/update our current public (FreeBSD) > headers and > throw away the private ones? That's more or less what I did for the branch, although I don't like what's in our public headers, either- they don't seem to be 1:1 FreeBSD, and even if they were, I don't think we should put that much stuff in there. They expose too much of the internals, and go way beyond of what is needed (for example, have a look at sys/socket.h). I would also like to get rid of sys/ioccom.h, sys/filio.h, etc. Also, sys/ioctl.h is broken. > > - I would like to get rid of acronyms like "if" and "dl" and use > > their > > full names for structure names and fields; I would also like to > > remove > > the "if_" or similar prefixes in the structure fields names > I personally have nothing to complain about names like net_dl_proto, > but > net_datalink_proto would be ok, too. I'd be thankful for that, even though I'd even call it net_datalink_protocol ;-) But if it comes down, I'd prefer net_dl_protocol over net_datalink_proto. But anyway, I somewhat dislike abbreviations, and only use them rarely. > > I'll open a new branch for the stack by simply renaming the FreeBSD > > branch, okay? > Fine with me. Done. I've also added a script to switch the networking stacks. BTW I've investigated BONE a bit yesterday, and while I said something like "I can't see any reason why we should create packets faster than the card can send" before, I would think it might be actually better to decouple this with a dedicated thread. The reason is simply to reduce the latency between outgoing packets - it still doesn't make much sense to prepare 10 packets for sending, but it makes sense to try to always have one in the queue, so that as soon as the card is ready, the next one can be send - this could be especially useful for Gigabit ethernet cards. Anyway, the current bone_data concept doesn't seem to be too useful for this, at least, before switching to another thread, we must make sure there is no user space buffer left in the bone_data object. But I don't know if there are any cards out there that could work with a couple of iovecs instead of a single buffer, so there is possibly no reason to be too smart about this, anyway. I would move that decision to the interface level, so that we can still find a good way to do this later. Another problem is that lock_memory() is not really implemented yet, and I am not sure how expensive it will be yet. So it might make sense to get rid of the userland buffer early on, which somewhat compensates the strength of bone_data. Ah well, I think we should ignore this for now, too. Bye, Axel.