Re: [GIT PULL] kdbus for 4.1-rc1

[Rik van Riel]

On 04/15/2015 01:59 PM, Austin S Hemmelgarn wrote:
> On 2015-04-14 15:43, Greg Kroah-Hartman wrote:
>> On Tue, Apr 14, 2015 at 08:35:33PM +0100, Al Viro wrote:
>>> On Tue, Apr 14, 2015 at 09:23:57PM +0200, Greg Kroah-Hartman wrote:
>>>
>>>>> I agree.  You've sent a pull request for an unfortunate design.  I
>>>>> don't think that unfortunate design belongs in the kernel.  If it says
>>>>> in userspace, then user programmers could potentially fix it some day.
>>>>
>>>> You might not like the design, but it is a valid design.  Again, we
>>>> don't refuse to support hardware that is designed badly.  Or support
>>>> protocols we don't necessarily like, that's not the job of a kernel or
>>>> operating system.
>>>
>>> And no, "the sole consumer of that API knows better, so bend over" is
>>> not
>>> a good idea.  We have shitloads of examples when single-consumer APIs
>>> turned into screaming horrors; taking that in over the objections to API
>>> design, merely on "they do it that way, who the hell we are to say they
>>> are wrong?" is insane.
>>
>> Again, in this domain, the design is sound.  So much so that everyone
>> who works in that area moved toward it (KDE, Qt, Go, etc.)  We might not
>> think it makes sense, and it did take me a while to wrap my head around
>> it, but to call it "crap" is unfair, sorry.
>>
> 
> The reason that 'everyone who works in this area' adopted is not as much
> that the design is sound (I'm not arguing whether it is or isn't in this
> case) as it is that none of them could come up with anything better.

They are smart people, and I would not underestimate
the usefulness of the user space API (above the
dbus library) that they came up with.

That does not mean the actual in-kernel implementation
needs to follow the same design criteria. It may make
sense to have part of the implementation in kernel space,
part in user space, and allow the userspace part to be
switched out to accommodate other protocols over the same
in-kernel bus...

Moving some of the policy bits into a user space daemon
may make sense. Storing messages that cannot be delivered
right now in user space could make sense, too.
--
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/