[lkml]   [2015]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Issues with capability bits and meta-data in kdbus
On 2015-04-22 09:07, Greg Kroah-Hartman wrote:
> On Wed, Apr 22, 2015 at 07:40:25AM -0400, Austin S Hemmelgarn wrote:
>> On 2015-04-21 22:32, Linus Torvalds wrote:
>>> On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski <> wrote:
>>>> If kdbus were a general purpose IPC tool
>>> .. but it's not ..
>> Except, IIRC, that was one of the stated design goals in the original patch
>> set. I'm pretty sure that i remember a rather verbose exposition that
>> pretty much could be summarized as "Linux has no general purpose IPC in the
>> kernel, this fixes that"
> Did I say that somewhere? Here's what the patchset has always started
> with every time I have posted it for review, starting back last year in
> October:
> kdbus is a kernel-level IPC implementation that aims for
> resemblance to the the protocol layer with the existing
> userspace D-Bus daemon while enabling some features that
> couldn't be implemented before in userspace.
> 2+ years ago, I had the dream that maybe we could make kdbus into the
> "general purpose IPC layer for the kernel", but in working through all
> of the issues, and the requirements of the userspace users and
> protocols, it just really didn't work out that way, sorry.
I think it may have been someone else elaborating on this ideal that I
was remembering. Personally, I could care less whether it is considered
'general purpose', as far as I'm concerned, POSIX semaphores, shm, and
UDS fit all the IPC I ever need. On that note, I have considered trying
to implement SOCK_SEQPACKET support for AF_LOCAL, although I've gotten
by just fine using SCTP over the loop-back interface.

[unhandled content-type:application/pkcs7-signature]
 \ /
  Last update: 2015-04-22 16:21    [W:0.216 / U:1.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site