Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bus1 – Kernel Message Bus

bus1.org

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Bus1 – Kernel Message Bus

#41

Post by tomegun »

mfukar wrote: post #28
ktRolster wrote: post #6

The API seems bad to me, the ioctl() is ridiculously overloaded (disconnect, connect, read, and write all go through ioctl(), for example). As an API, this doesn't pass Linus' "good taste" test. As a solution, it's more complicated than necessary. On messaging in general: this is yet another IPC api from RedHat. They really want to get an IPC api into the kernel over there. However, their proposals seem 'ignorant,' i…

If only Red Hat actually tried to accommodate others' use cases, Linux systems would be so much better.

What makes you think we are not? What use case would you like to be taken into account in bus1 that is not? Open to suggestions (that is the point of an RFC after all ;) ).

Re: Bus1 – Kernel Message Bus

#42

Post by gribbly »

ktRolster wrote: post #6

The API seems bad to me, the ioctl() is ridiculously overloaded (disconnect, connect, read, and write all go through ioctl(), for example). As an API, this doesn't pass Linus' "good taste" test. As a solution, it's more complicated than necessary. On messaging in general: this is yet another IPC api from RedHat. They really want to get an IPC api into the kernel over there. However, their proposals seem 'ignorant,' i…

>On why Linus doesn't want to integrate it:

Where have you read that Linus doesn't want to integrate it ?

From the LKML response it sounded as if he wanted more explanation of how it solves certain things.

Re: Bus1 – Kernel Message Bus

#43

Post by tomegun »

SFJulie wrote: post #24
ktRolster wrote: post #6

The API seems bad to me, the ioctl() is ridiculously overloaded (disconnect, connect, read, and write all go through ioctl(), for example). As an API, this doesn't pass Linus' "good taste" test. As a solution, it's more complicated than necessary. On messaging in general: this is yet another IPC api from RedHat. They really want to get an IPC api into the kernel over there. However, their proposals seem 'ignorant,' i…

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/ cooperative multitasking in critical…

> What, bothers me is what the fuck is an iovec!

https://www.gnu.org/software/libc/manual/html_node/Scatter_0...

Re: Bus1 – Kernel Message Bus

#44

Post by tomegun »

mfukar wrote: post #30
SFJulie wrote: post #24

Earlier quoted context omitted.

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/ cooperative multitasking in critical…

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

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

Re: Bus1 – Kernel Message Bus

#45

Post by mfukar »

tomegun wrote: post #44
mfukar wrote: post #30

Earlier quoted context omitted.

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

> 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/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'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], 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".

Re: Bus1 – Kernel Message Bus

#46

Post by tomegun »

mfukar wrote: post #32
solidsnack9000 wrote: post #3

> Also in the case where there can be no causal relationship, we are guaranteed > a global order. In case two events happend concurrently, there can never be > any inconsistency in which occurred before the other. By way of example, > consider two peers sending one message each to two different peers, we are > guaranteed that both the recipient peers receive the two messages in the same > order, even though the order…

With their "synchronize-local-clocks" approach, it doesn't. They are using Lamport's algorithm to synchronize the clocks. However, Lamport's approach creates a _partial_ ordering, and to make that a _total_ ordering you need some mechanism to break "ties". For instance, the PID, or whatever. The catch is that the relationship derived from this arbitrary tie-breaking mechanism has nothing to do with causality, and the…

Indeed that is how we break ties (not exactly the PID, but you get the idea).

The reason this works is that the only time we can have a tie is if there can be no causality between the events. I.e., the two sending events happen concurrently: the two ioctl calls overlap in time, so there would be no way for one to have caused the other.

What problem do you see with this?

Re: Bus1 – Kernel Message Bus

#47

Post by gribbly »

X86BSD wrote: post #18
ktRolster wrote: post #6

The API seems bad to me, the ioctl() is ridiculously overloaded (disconnect, connect, read, and write all go through ioctl(), for example). As an API, this doesn't pass Linus' "good taste" test. As a solution, it's more complicated than necessary. On messaging in general: this is yet another IPC api from RedHat. They really want to get an IPC api into the kernel over there. However, their proposals seem 'ignorant,' i…

That's a very good suggestion. But the reality is that will never, ever happen. Linus and the Linux community as a whole exist in an echo chamber. They never resort to looking outside their little bubble world to see how others solved problems they are trying to fix. They simply are not capable of that. They constantly reinvent the wheel and reinvent it poorly. They should have simply adopted kqueue, ZFS, dtrace, jai…

>ZFS, dtrace

These are both using a incompatible license (CDDL), they can't be merged into mainline.

Re: Bus1 – Kernel Message Bus

#48

Post by mfukar »

tomegun wrote: post #46
mfukar wrote: post #32

Earlier quoted context omitted.

With their "synchronize-local-clocks" approach, it doesn't. They are using Lamport's algorithm to synchronize the clocks. However, Lamport's approach creates a _partial_ ordering, and to make that a _total_ ordering you need some mechanism to break "ties". For instance, the PID, or whatever. The catch is that the relationship derived from this arbitrary tie-breaking mechanism has nothing to do with causality, and the…

Indeed that is how we break ties (not exactly the PID, but you get the idea). The reason this works is that the only time we can have a tie is if there can be no causality between the events. I.e., the two sending events happen concurrently: the two ioctl calls overlap in time, so there would be no way for one to have caused the other. What problem do you see with this?

I foresee a problem where people confuse the wording of "total order on all messages" in the wiki to mean there is a "global total order" - in other words, that bus1 solves distributed systems and we can all go home - and building buggy systems on this assumption. I'm not saying the concept is flawed or the implementation buggy, or anything like that.

PS. Neil Brown in the LWN article already conflates "global" and "total" order.

Re: Bus1 – Kernel Message Bus

#49

Post by tomegun »

mfukar wrote: post #45
tomegun wrote: post #44

Earlier quoted context omitted.

> 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/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'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 ], 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".

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

Re: Bus1 – Kernel Message Bus

#50

Post by mfukar »

tomegun wrote: post #49
mfukar wrote: post #45

Earlier quoted context omitted.

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 ], 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".

"[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 anythi…

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.
Post reply on HN