> Hi all, > > Yesterday, I was bored at work. :-) > So I start to write some code to add light on last week ML thread > about > sockets file descriptor support, client-side library and stack-side > interface. You must have been very bored :-) > 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 the standard Desktop machine, I would say yes, because all APIs will be needed by the applications running. OTOH there should be the possibility to easily split it into several smaller ones for building special packages. > - 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. > BTW bis, for kernel network needs, like network fs (nfs, cifs, etc), > the socket API should be > exported too by a kernel *module*, as drivers/modules can't link > against libraries... Right, that would be nice. > 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. > "Voila". > Any thoughs about this design? It's basically what we've planned :-) > Should we put aside this fd socket support until R2, > as it's not the top priority? Technical design choice > may have some impact on net_server design, I think. > Any hint(s) on the IPC design I should try to connect this > driver with the net_server in CVS? The driver doesn't need to do much, e.g. it's the same communication for the driver as it is for the library. I have thought about having a command queue in a shared area per socket. And communication via semaphores and/or ports. Adios... Axel.