Re: [GIT PULL] kdbus for 4.1-rc1

[Andy Lutomirski]

On Wed, Apr 15, 2015 at 2:56 PM, One Thousand Gnomes
<gnomes@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 15 Apr 2015 19:31:45 +0200
>> Don't make idle comments, the tty layer is far more complex and larger
>> than the kdbus code, with much nastier issues and problems.  And we
>> handle that just fine :)
>
> The tty layer is the way it is because of design decisions dating back 20
> years that were (with hindsight) wrong coupled with the fact that POSIX
> took a lot of the behavioural guarantees from an armwaving claim about
> what Unix(tm) implemented without thinking about how to implement them
> (as far as I can tell - given many of the guarantees are broken in Unix!)
>
>> I'll again refer to ALSA here, no one writes a "raw" ALSA program, they
>> all use the library to interact with the kernel.  Do that here, there
>> are wonderful dbus libraries out there, for all languages.  Use them
>> instead.
>
> Agreed entirely - I don't disagree that we need a fast messaging layer.
> The question is what bits belong in kernel. Go wants one, JMS wants one,
> porting from stuff like QNX wants one (although they use the POSIX API
> on QNX), MPI wants one (but with some useful and subtly different
> semantics), various embedded things from tiny uKernels want one.
>
> The question is what the kernel bit should actually look like, and how
> many we need.
>
> My guess is that we actually have three of the big use cases covered
>
> - futexes and shared memory cover the tiny uKernel emulation bits (and on
>   a lawnmower engine sized ARM thats probably the only way to get the
>   speed approaching that of a tiny rtos)
> - posix queues cover things like QNX porting
> - publish/subscribe - via tmpfs
>
> but we don't cover
>
> - multicasting
> - some types of credential and authority passing
> - scatter/gather without excessive userspace wakes

I would really like to see a very lightweight capability-based
messaging system.  By "capability-based" I don't mean Linux
capabilities.  I mean that a user program could give some very
lightweight token to a peer authorizing that peer to use some service
(by reference to the same token), and the peer could pass it on to
other peers as an introduction mechanism.  (Search for
"capability-based security".)

This is functionally identical to passing AF_UNIX socket fds over
SCM_RIGHTS, but I want something much lighter weight.

Also, getting the really high performance stuff right would be nice.
Binder has one thing going for it (IIRC -- I've talked about it to
some of the authors, but I've never so much as glanced at the code):
it has a primitive to send and wait for a reply.  This reduces the
load on scheduler.

I wish kdbus were blazingly fast, but I don't think it is :(  I think
the bar should be either similar performance to (peer-to-peer) AF_UNIX
or something possibly more complex but considerably faster.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/