Axel wrote: > You must have been very bored :-) Three words: Windows Software Engineer. Well, only first one matter here... >> a) libnet.so export to userland clients the net_kit API: > > Do you think it makes sense to have them all in one library? > For thestandard Desktop machine, I would say yes, because all APIs will be > needed by the applications running. Yep, I do too. One *kit*, one library. Clean, simple, easy to understand for newbies developers. All kind of things I love in BeOS development environment. > OTOH there should be the possibility to easily split it into several > smaller ones for building special packages. It's open source heaven, people make what that they want or need with the code. ;-) >> - stack configuration/querying api (for preference app, etc). Think >> about ifconfig tool, etc... > > I am not sure about this - this should be done via ioctls() and > friends. Agreed. This kind of API is not priority, but I hope we could offer a thin wrapper over most common configuration ioctls: enumerate interfaces, route table user-land access, to say some. It would be usefull for Network preference app... >> The libnet.so use this mechanism to create a valid, file >> descriptorized >> socket. And to do the real job behind connect(), etc... > > This should be done by the stack itself, not the library - it doesn't > know anything about the implementation, only how to talk to the server. Absolutly! It's what I've in mind too, but my words put it wrong. For me, lib/socket.c is *done*. Let's move to driver <-> net_server interface. > The driver doesn't need to do much, e.g. it's the same communication > for the driver as it is for the library. Mostly, yes. There's, in fact, some extra needs: - each fd the driver returns should have a *cookie* attached to it so that he can link to a net_server managed endpoint. - the driver would need to store somewhere the selectsync/select ref infos Kernel pass him via [de]select() hook to be able to send select notification when needed/requested by the net_server. include/net_endpoint.h/net_endpoint struct is only this *cookie* today, nothing more. - maybe cache some *static* datas in the driver may help decrease the driver <-> net_server communication needs. - for accept() support, as the returned socket should be a valid fd too, the driver would need to be able to *bind* a specific *cookie* to the net_server endpoint created in the "listen" endpoint queue. See lib/socket.c/accept() code to understand why... Nothing to worry, really. > I have thought about having a command queue in a shared area per > socket. And communication via semaphores and/or ports. Yep. Time to think about this communication design. I'll see if I can put something here... new ASCII diagrams! :-) :-| :-( -Philippe.