Messages in this thread | | | Date | Wed, 22 Apr 2015 10:05:50 -0400 | From | Austin S Hemmelgarn <> | Subject | Re: 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 <luto@amacapital.net> 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] | |