I still don't understand why they don't use (or extend, if necessary) TIPC, which is already a distributed IPC protocol that is already in the kernel. Why build a library around an existing feature that has already had a lot of testing when you can say NIH and design something new with an entirely new set of bugs?
https://www.gnu.org/software/libc/manual/html_node/Scatter_0...
That's a red herring though. A new syscall implementation can also provide the same guarantees.
> What, bothers me is what the fuck is an iovec!
Pretty sure they're referring to Berkeley-style UIO. Any discussion about those will soon devolve in other types of IPC, in my experience..
> What cringes me too is it is a distributed system (and I played quite a lot with them) and they say they have tackled the problem of global ordering of the messages. Well, be it on the network, be it on silicium, I never saw anyone achieve this feature.
They are claiming there's no global synchronization and a global order. That is textbook impossible, and leads me to believe what's written on the site is either waaay misunderstood or waaay manipulative.
Need to update your textbook ;) http://research.microsoft.com/en-us/um/people/lamport/pubs/t...
In particular, what we did is described here: https://github.com/bus1/documentation/wiki/Message-ordering
If anything is unclear or misleading, please let me know and I'll try to clarify.
I admit I haven't read the implementation to see what kind of bounds you derive, and I couldn't find them in the wiki either. So, I think I'll go with "accidentally exaggerated" instead of "manipulative".
Could you explain what bounds you are interested in and in what way you think anything is exaggerated? I would like to update the docs if necessary.
Quoting Steven Doyle
ioctl can be guaranteed by the kernel to be atomic. If a driver grabs a spinlock during the ioctl processing then the driver will enter atomic context and will remain in atomic context until it releases the spinlock. http://lwn.net/Articles/274695/
cooperative multitasking in critical functioning requires thread safety and atomicity.
What, bothers me is what the fuck is an iovec! That is the most important part of the norm and yet it is not defined. My fear is that to accommodate «industry grade level of developers» they will use dynamically allocated structures vs fixed size structure. And we all know that malloc in user space is already the door to hell, but in kernel space, it is a direct nightmare.
What cringes me too is it is a distributed system (and I played quite a lot with them) and they say they have tackled the problem of global ordering of the messages. Well, be it on the network, be it on silicium, I never saw anyone achieve this feature.
I fear they are over promising and they will under-deliver