Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)

Boie, Andrew P

There has not been any public talk in mailing list about
userspace/kernel separation and how it affects IP stack etc. so it is
a bit difficult to say anything about this.
That's true, but we can/should think how it may be affected, or we'll be caught
in the cold water with them, and may come up with random on-spot designs to
address such future requirements, instead of something well thought out.
The userspace work has progressed to the point where we have enough confidence in the API design to open up the design discussion to a larger audience; until now enough things have been in flux (or uncertain) such that we've kept the discussion to the working group we established for it.

What we are trying to do is get something feature-complete into the tree for the upcoming 1.10 release, with partial test case coverage and initial documentation, on an 'experimental' basis; i.e. APIs and policies are subject to change. Then polish everything up for the 1.11 release, which would be the official debut of this feature.

I have to admit my knowledge of the network stack is quite poor, but broadly speaking here are a set of slides recently drafted which goes into some detail about what sort of kernel objects are accessible from user threads and the sort of restrictions they have. We expect to expose a subset of existing kernel APIs to user threads, and all driver APIs which don't involve registration of callbacks. Please feel free to leave comments in the document, or on this list.

I suspect the biggest implication for the network stack is that it uses registration of callbacks heavily, and it's forbidden to allow user threads to directly register callbacks that run in supervisor mode. But you can get around this (for example) by having the callback do minimal processing of the incoming data and signal a semaphore to have a user mode worker thread do the rest of the work. We are also looking into supporting user-mode workqueues. We also don't (yet) have a clear picture on what support for k_poll APIs we will have for userspace.

There's also the question of memory buffers, there would need to be some care taken that any buffers used by the stack that are exposed to the application contain purely data and no internal data structures private to the kernel. This constraint is why we don't provide system call interfaces to k_queue APIs.

Ideally in the fullness of time, we could migrate some parts of the network protocol stack to run in user mode, which I think would enhance the security of the system.

At the moment, current implementation effort is centered around getting our test cases running in user mode, and getting started on the formal documentation.


Join to automatically receive all group messages.