> Philippe, why? Please give me reasons that make sense... > > The functions that move into the kernel will never require a change > of > kernel to support a new protocol, so the argument that we'd have to > rerelease the kernel isn't valid and I can't understand why you'd > want to > have to mess with ioctl's and such like when we could simply have a > syscall > that keeps things much simpler. > > Given that much of the networking code will be in a seperate module > anyway I > don't see the problem, but the advantages that I see are enormous. As long as the networking code is in a separate module that hasn't to be there, and that's only loaded asynchronously on demand (which would be always for a standard user system), I don't see any problems with putting them in the kernel directly. The kernel-side functions would be pretty much stubs to call those of the networking module - very comparable to functions like fs_open_query() which is in the kernel (and should be there, right?), but the work is done in the file system if it supports it. Adios... Axel.