5 ms·

In term of linux design ioctl are natural candidates as an underlying mechanism for multi-process communication. Quoting Steven Doyle ioctl can be guaranteed

by SFJulie 10y ago

In term of linux design ioctl are natural candidates as an underlying mechanism for multi-process communication. 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/ 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

pdkl95 10y ago
> What cringes me too is it is a distributed system 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? http://www.spinics.net/lists/netdev/msg190623.html http://www.spinics.net/lists/netdev/msg190623.html
mfukar 10y ago
> 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. 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.
- tomegun 10y ago
  > They are claiming there's no global synchronization and a global order. Need to update your textbook ;) http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf 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 https://github.com/bus1/documentation/wiki/Message-ordering If anything is unclear or misleading, please let me know and I'll try to clarify.
  - mfukar 10y ago
    I've read both, thanks. I clearly remember the fact the total ordering is "somewhat arbitrary" in Lamport's own words, which is what I pointed out here [https://news.ycombinator.com/item?id=12803907 https://news.ycombinator.com/item?id=12803907], too. 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".
    - tomegun 10y ago
      "[S]omewhat arbitrary" is a correct description. We take something that is fundamentally partially ordered (real-world events that may happen exactly at the same time), respect the partial order and extend it to a total order. The extension is arbitrary, but I fail to see the problem with that, or how it contradict anything we wrote? 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.
      - mfukar 10y ago
        I could. I would rather put it in an email or PR. I'll try to put it together as soon as I have some time.
        tomegun 10y ago
        Thanks.
tomegun 10y ago
> What, bothers me is what the fuck is an iovec! https://www.gnu.org/software/libc/manual/html_node/Scatter_002dGather.html https://www.gnu.org/software/libc/manual/html_node/Scatter_0...

by SFJulie 10y ago

pdkl95 10y ago

> What cringes me too is it is a distributed system 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? http://www.spinics.net/lists/netdev/msg190623.html http://www.spinics.net/lists/netdev/msg190623.html

mfukar 10y ago

> 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. 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.

tomegun 10y ago
> They are claiming there's no global synchronization and a global order. Need to update your textbook ;) http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf 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 https://github.com/bus1/documentation/wiki/Message-ordering If anything is unclear or misleading, please let me know and I'll try to clarify.
- mfukar 10y ago
  I've read both, thanks. I clearly remember the fact the total ordering is "somewhat arbitrary" in Lamport's own words, which is what I pointed out here [https://news.ycombinator.com/item?id=12803907 https://news.ycombinator.com/item?id=12803907], too. 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".
  - tomegun 10y ago
    "[S]omewhat arbitrary" is a correct description. We take something that is fundamentally partially ordered (real-world events that may happen exactly at the same time), respect the partial order and extend it to a total order. The extension is arbitrary, but I fail to see the problem with that, or how it contradict anything we wrote? 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.
    - mfukar 10y ago
      I could. I would rather put it in an email or PR. I'll try to put it together as soon as I have some time.
      - tomegun 10y ago
        Thanks.

tomegun 10y ago

> What, bothers me is what the fuck is an iovec! https://www.gnu.org/software/libc/manual/html_node/Scatter_002dGather.html https://www.gnu.org/software/libc/manual/html_node/Scatter_0...