Hi all,
after reading on the removal of kdbus from Rawhide[1] I've searched
the mailinglist archives for more details but didn't find anything.
So, what are your plans?
[1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
--
Thanks,
//richard
On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
> Hi all,
>
> after reading on the removal of kdbus from Rawhide[1] I've searched
> the mailinglist archives for more details but didn't find anything.
> So, what are your plans?
>
> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
As that link said, based on the result of the code being in Rawhide, it
is now being reworked / redesigned. The result will be posted for
review "when it's ready".
thanks,
greg k-h
On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
> On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>> Hi all,
>>
>> after reading on the removal of kdbus from Rawhide[1] I've searched
>> the mailinglist archives for more details but didn't find anything.
>> So, what are your plans?
>>
>> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>
> As that link said, based on the result of the code being in Rawhide, it
> is now being reworked / redesigned. The result will be posted for
> review "when it's ready".
If you rework/redesign something you have to know what you want to change.
That's why I was asking for the plan...
--
Thanks,
//richard
On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
> >> Hi all,
> >>
> >> after reading on the removal of kdbus from Rawhide[1] I've searched
> >> the mailinglist archives for more details but didn't find anything.
> >> So, what are your plans?
> >>
> >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
> >
> > As that link said, based on the result of the code being in Rawhide, it
> > is now being reworked / redesigned. The result will be posted for
> > review "when it's ready".
>
> If you rework/redesign something you have to know what you want to change.
> That's why I was asking for the plan...
Since when do people post "plans" or "design documents" on lkml without
real code? Again, code will be posted when it's ready, like any other
kernel submission.
thanks,
greg k-h
On Sun, Nov 08, 2015 at 03:30:18PM -0800, Greg KH wrote:
> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
> > On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
> > > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
> > >> Hi all,
> > >>
> > >> after reading on the removal of kdbus from Rawhide[1] I've searched
> > >> the mailinglist archives for more details but didn't find anything.
> > >> So, what are your plans?
> > >>
> > >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
> > >
> > > As that link said, based on the result of the code being in Rawhide, it
> > > is now being reworked / redesigned. The result will be posted for
> > > review "when it's ready".
> >
> > If you rework/redesign something you have to know what you want to change.
> > That's why I was asking for the plan...
>
> Since when do people post "plans" or "design documents" on lkml without
> real code?
Quoting Documentation/development-process/1.Intro:
> Section 3 covers early-stage project planning, with an emphasis on
> involving the development community as soon as possible.
Quoting Documentation/development-process/3.Early-stage:
> When planning a kernel development project, it makes great sense to hold
> discussions with the community before launching into implementation.
[...]
> - It's entirely possible that other developers have thought about the
> problem; they may have ideas for a better solution, and may be willing
> to help in the creation of that solution.
>
> Years of experience with the kernel development community have taught a
> clear lesson: kernel code which is designed and developed behind closed
> doors invariably has problems which are only revealed when the code is
> released into the community. Sometimes these problems are severe,
> requiring months or years of effort before the code can be brought up to
> the kernel community's standards.
[...]
> If possible, posting your plans during the early stages can only be
> helpful. Describe the problem being solved and any plans that have been
> made on how the implementation will be done. Any information you can
> provide can help the development community provide useful input on the
> project.
And I've seen you specifically recommend having such conversations early
and often.
That same document also warns about the discouraging possibility of
receiving "little or no reaction" for a variety of reasons, but somehow
I don't think kdbus will encounter that problem. :)
- Josh Triplett
On Mon, Nov 9, 2015 at 12:30 AM, Greg KH <[email protected]> wrote:
> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>> >> Hi all,
>> >>
>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
>> >> the mailinglist archives for more details but didn't find anything.
>> >> So, what are your plans?
>> >>
>> >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>> >
>> > As that link said, based on the result of the code being in Rawhide, it
>> > is now being reworked / redesigned. The result will be posted for
>> > review "when it's ready".
>>
>> If you rework/redesign something you have to know what you want to change.
>> That's why I was asking for the plan...
>
> Since when do people post "plans" or "design documents" on lkml without
> real code? Again, code will be posted when it's ready, like any other
> kernel submission.
Nobody asked for a design document.
And yes, people often say what they do or want to do.
Anyway, heise.de has details from the systemd.conf:
http://www.heise.de/open/meldung/Linux-Kdbus-soll-universeller-werden-Videos-von-Systemd-Konferenz-2910910.html
According to them the plan is making kdbus more universal and less
dbus specific.
Which sounds great.
--
Thanks,
//richard
Hi
On Mon, Nov 9, 2015 at 1:53 AM, Josh Triplett <[email protected]> wrote:
> Quoting Documentation/development-process/1.Intro:
[...]
>> Years of experience with the kernel development community have taught a
>> clear lesson: kernel code which is designed and developed behind closed
>> doors invariably has problems which are only revealed when the code is
>> released into the community. Sometimes these problems are severe,
>> requiring months or years of effort before the code can be brought up to
>> the kernel community's standards.
[...]
> And I've seen you specifically recommend having such conversations early
> and often.
I think comparing kdbus to "behind closed doors" development models is
unfair. We chose to center our development around DBus, not the
kernel. Anybody who is interested in kdbus discussions could have
easily joined the DBus and systemd communication channels (and *many*
people did). I see little reason in cross-posting everything to LKML,
especially given that our communication is rarely mail-based.
Thanks
David
Am 09.11.2015 um 09:34 schrieb David Herrmann:
> Hi
>
> On Mon, Nov 9, 2015 at 1:53 AM, Josh Triplett <[email protected]> wrote:
>> Quoting Documentation/development-process/1.Intro:
> [...]
>>> Years of experience with the kernel development community have taught a
>>> clear lesson: kernel code which is designed and developed behind closed
>>> doors invariably has problems which are only revealed when the code is
>>> released into the community. Sometimes these problems are severe,
>>> requiring months or years of effort before the code can be brought up to
>>> the kernel community's standards.
> [...]
>> And I've seen you specifically recommend having such conversations early
>> and often.
>
> I think comparing kdbus to "behind closed doors" development models is
> unfair. We chose to center our development around DBus, not the
> kernel. Anybody who is interested in kdbus discussions could have
> easily joined the DBus and systemd communication channels (and *many*
> people did). I see little reason in cross-posting everything to LKML,
> especially given that our communication is rarely mail-based.
I agree, "behind the doors" is not true. But a mailinglist with achieves
would be nice.
IIRC last time I've asked you said that all discussion happened privately
or on IRC. Which is okay but not that transparent.
Thanks,
//richard
On Mon, Nov 09, 2015 at 09:34:37AM +0100, David Herrmann wrote:
> Hi
>
> On Mon, Nov 9, 2015 at 1:53 AM, Josh Triplett <[email protected]> wrote:
> > Quoting Documentation/development-process/1.Intro:
> [...]
> >> Years of experience with the kernel development community have taught a
> >> clear lesson: kernel code which is designed and developed behind closed
> >> doors invariably has problems which are only revealed when the code is
> >> released into the community. Sometimes these problems are severe,
> >> requiring months or years of effort before the code can be brought up to
> >> the kernel community's standards.
> [...]
> > And I've seen you specifically recommend having such conversations early
> > and often.
>
> I think comparing kdbus to "behind closed doors" development models is
> unfair. We chose to center our development around DBus, not the
> kernel.
And yet it will be the kernel people you ask to take your code. You
don't see something funny with that?
> Anybody who is interested in kdbus discussions could have
> easily joined the DBus and systemd communication channels (and *many*
> people did). I see little reason in cross-posting everything to LKML,
> especially given that our communication is rarely mail-based.
So you want to develop kernel code, but can't be arsed to do it the
kernel way? Gheez, no wonder this all is going so well..
Hi
On Mon, Nov 9, 2015 at 9:48 AM, Peter Zijlstra <[email protected]> wrote:
> On Mon, Nov 09, 2015 at 09:34:37AM +0100, David Herrmann wrote:
>> Hi
>>
>> On Mon, Nov 9, 2015 at 1:53 AM, Josh Triplett <[email protected]> wrote:
>> > Quoting Documentation/development-process/1.Intro:
>> [...]
>> >> Years of experience with the kernel development community have taught a
>> >> clear lesson: kernel code which is designed and developed behind closed
>> >> doors invariably has problems which are only revealed when the code is
>> >> released into the community. Sometimes these problems are severe,
>> >> requiring months or years of effort before the code can be brought up to
>> >> the kernel community's standards.
>> [...]
>> > And I've seen you specifically recommend having such conversations early
>> > and often.
>>
>> I think comparing kdbus to "behind closed doors" development models is
>> unfair. We chose to center our development around DBus, not the
>> kernel.
>
> And yet it will be the kernel people you ask to take your code. You
> don't see something funny with that?
No.
>> Anybody who is interested in kdbus discussions could have
>> easily joined the DBus and systemd communication channels (and *many*
>> people did). I see little reason in cross-posting everything to LKML,
>> especially given that our communication is rarely mail-based.
>
> So you want to develop kernel code, but can't be arsed to do it the
> kernel way? Gheez, no wonder this all is going so well..
The submission and following year of development followed the 'kernel
way'. I don't see why the design phase needs to follow your style,
though.
Thanks
David
On Mon, Nov 09, 2015 at 09:56:04AM +0100, David Herrmann wrote:
> The submission and following year of development followed the 'kernel
> way'. I don't see why the design phase needs to follow your style,
> though.
And you wonder why there was such a backlash...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
On Mon, Nov 09, 2015 at 09:56:04AM +0100, David Herrmann wrote:
> The submission and following year of development followed the 'kernel
> way'.
This is not true; the last complete posting I could find was:
Date: Mon, 9 Mar 2015 14:09:06 +0100
Subject: [PATCH v4 00/14] Add kdbus implementation
I've seen many random kdbus patches, but not a single comprehensive
posting one could attempt to review after that.
The normal way is to regularly post a complete set of patches for
review -- which very much includes folding patches you get back into the
series, not post a 100+ patch series.
Hi
On Mon, Nov 9, 2015 at 10:14 AM, Peter Zijlstra <[email protected]> wrote:
> On Mon, Nov 09, 2015 at 09:56:04AM +0100, David Herrmann wrote:
>
>> The submission and following year of development followed the 'kernel
>> way'.
>
> This is not true; the last complete posting I could find was:
>
> Date: Mon, 9 Mar 2015 14:09:06 +0100
> Subject: [PATCH v4 00/14] Add kdbus implementation
..which was the last time we proposed it for inclusion.
Thanks
David
Am 09.11.2015 um 10:19 schrieb David Herrmann:
> On Mon, Nov 9, 2015 at 10:14 AM, Peter Zijlstra <[email protected]> wrote:
>> On Mon, Nov 09, 2015 at 09:56:04AM +0100, David Herrmann wrote:
>>
>>> The submission and following year of development followed the 'kernel
>>> way'.
>>
>> This is not true; the last complete posting I could find was:
>>
>> Date: Mon, 9 Mar 2015 14:09:06 +0100
>> Subject: [PATCH v4 00/14] Add kdbus implementation
>
> ..which was the last time we proposed it for inclusion.
Guys, let's cool down. :-)
What Peter is complaining about is that since the last proposal a lot
of iterative patches and even pull requests were sent instead of
complete patch series.
The expectation was that you send patch series with fixes folded in
as long the review takes.
Thanks,
//richard
On Mon, Nov 09, 2015 at 10:28:42AM +0100, Richard Weinberger wrote:
> Am 09.11.2015 um 10:19 schrieb David Herrmann:
> > On Mon, Nov 9, 2015 at 10:14 AM, Peter Zijlstra <[email protected]> wrote:
> >> On Mon, Nov 09, 2015 at 09:56:04AM +0100, David Herrmann wrote:
> >>
> >>> The submission and following year of development followed the 'kernel
> >>> way'.
> >>
> >> This is not true; the last complete posting I could find was:
> >>
> >> Date: Mon, 9 Mar 2015 14:09:06 +0100
> >> Subject: [PATCH v4 00/14] Add kdbus implementation
> >
> > ..which was the last time we proposed it for inclusion.
>
> Guys, let's cool down. :-)
>
> What Peter is complaining about is that since the last proposal a lot
> of iterative patches and even pull requests were sent instead of
> complete patch series.
> The expectation was that you send patch series with fixes folded in
> as long the review takes.
And that will happen, when the code is ready, nothing different is
happening here from any other code submission. I don't know why people
somehow think we don't know how to do this whole thing, it's as if they
don't trust us, which is sad.
greg k-h
Am 09.11.2015 um 16:02 schrieb Greg KH:
> On Mon, Nov 09, 2015 at 10:28:42AM +0100, Richard Weinberger wrote:
>> Am 09.11.2015 um 10:19 schrieb David Herrmann:
>>> On Mon, Nov 9, 2015 at 10:14 AM, Peter Zijlstra <[email protected]> wrote:
>>>> On Mon, Nov 09, 2015 at 09:56:04AM +0100, David Herrmann wrote:
>>>>
>>>>> The submission and following year of development followed the 'kernel
>>>>> way'.
>>>>
>>>> This is not true; the last complete posting I could find was:
>>>>
>>>> Date: Mon, 9 Mar 2015 14:09:06 +0100
>>>> Subject: [PATCH v4 00/14] Add kdbus implementation
>>>
>>> ..which was the last time we proposed it for inclusion.
>>
>> Guys, let's cool down. :-)
>>
>> What Peter is complaining about is that since the last proposal a lot
>> of iterative patches and even pull requests were sent instead of
>> complete patch series.
>> The expectation was that you send patch series with fixes folded in
>> as long the review takes.
>
> And that will happen, when the code is ready, nothing different is
> happening here from any other code submission. I don't know why people
> somehow think we don't know how to do this whole thing, it's as if they
> don't trust us, which is sad.
Well, what me makes sad is that my little question ended up in a flame.
If someone asks me how I plan to solve something I'm become proud and tell my ideas.
All I got was rejection and platitudes.
Thanks,
//richard
On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <[email protected]> wrote:
> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>> >> Hi all,
>> >>
>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
>> >> the mailinglist archives for more details but didn't find anything.
>> >> So, what are your plans?
>> >>
>> >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>> >
>> > As that link said, based on the result of the code being in Rawhide, it
>> > is now being reworked / redesigned. The result will be posted for
>> > review "when it's ready".
>>
>> If you rework/redesign something you have to know what you want to change.
>> That's why I was asking for the plan...
>
> Since when do people post "plans" or "design documents" on lkml without
> real code? Again, code will be posted when it's ready, like any other
> kernel submission.
I ask for feedback on ideas and designs on a fairly regular basis. I
even frequently get valuable feedback :)
I would like to think that the kernel community would have something
of value to add to the process of designing and implementing a major
new IPC mechanism.
--Andy
Andy Lutomirski <[email protected]> writes:
> On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <[email protected]> wrote:
>> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
>>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>>> >> Hi all,
>>> >>
>>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
>>> >> the mailinglist archives for more details but didn't find anything.
>>> >> So, what are your plans?
>>> >>
>>> >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>>> >
>>> > As that link said, based on the result of the code being in Rawhide, it
>>> > is now being reworked / redesigned. The result will be posted for
>>> > review "when it's ready".
>>>
>>> If you rework/redesign something you have to know what you want to change.
>>> That's why I was asking for the plan...
>>
>> Since when do people post "plans" or "design documents" on lkml without
>> real code? Again, code will be posted when it's ready, like any other
>> kernel submission.
>
> I ask for feedback on ideas and designs on a fairly regular basis. I
> even frequently get valuable feedback :)
>
> I would like to think that the kernel community would have something
> of value to add to the process of designing and implementing a major
> new IPC mechanism.
The "trust us, we'll show it when it's ready" attitude reminds me of the
controversial TPP and TTIP negotiations.
--
M?ns Rullg?rd
[email protected]
On Mon, Nov 09, 2015 at 05:02:45PM +0000, M?ns Rullg?rd wrote:
> Andy Lutomirski <[email protected]> writes:
>
> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <[email protected]> wrote:
> >> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
> >>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
> >>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
> >>> >> Hi all,
> >>> >>
> >>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
> >>> >> the mailinglist archives for more details but didn't find anything.
> >>> >> So, what are your plans?
> >>> >>
> >>> >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
> >>> >
> >>> > As that link said, based on the result of the code being in Rawhide, it
> >>> > is now being reworked / redesigned. The result will be posted for
> >>> > review "when it's ready".
> >>>
> >>> If you rework/redesign something you have to know what you want to change.
> >>> That's why I was asking for the plan...
> >>
> >> Since when do people post "plans" or "design documents" on lkml without
> >> real code? Again, code will be posted when it's ready, like any other
> >> kernel submission.
> >
> > I ask for feedback on ideas and designs on a fairly regular basis. I
> > even frequently get valuable feedback :)
> >
> > I would like to think that the kernel community would have something
> > of value to add to the process of designing and implementing a major
> > new IPC mechanism.
>
> The "trust us, we'll show it when it's ready" attitude reminds me of the
> controversial TPP and TTIP negotiations.
Ok, that's just trolling, cut it out.
When something is even in the "hey look, it works, here's the big
changes from last time", we will of course post it, but right now,
things are being totally revisited based on the feedback we have
received so far. Give people a chance to recover from conferences and
then get back to work...
thanks,
greg k-h
Greg KH <[email protected]> writes:
> On Mon, Nov 09, 2015 at 05:02:45PM +0000, M?ns Rullg?rd wrote:
>> Andy Lutomirski <[email protected]> writes:
>>
>> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <[email protected]> wrote:
>> >> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>> >>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
>> >>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>> >>> >> Hi all,
>> >>> >>
>> >>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
>> >>> >> the mailinglist archives for more details but didn't find anything.
>> >>> >> So, what are your plans?
>> >>> >>
>> >>> >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>> >>> >
>> >>> > As that link said, based on the result of the code being in Rawhide, it
>> >>> > is now being reworked / redesigned. The result will be posted for
>> >>> > review "when it's ready".
>> >>>
>> >>> If you rework/redesign something you have to know what you want to change.
>> >>> That's why I was asking for the plan...
>> >>
>> >> Since when do people post "plans" or "design documents" on lkml without
>> >> real code? Again, code will be posted when it's ready, like any other
>> >> kernel submission.
>> >
>> > I ask for feedback on ideas and designs on a fairly regular basis. I
>> > even frequently get valuable feedback :)
>> >
>> > I would like to think that the kernel community would have something
>> > of value to add to the process of designing and implementing a major
>> > new IPC mechanism.
>>
>> The "trust us, we'll show it when it's ready" attitude reminds me of the
>> controversial TPP and TTIP negotiations.
>
> Ok, that's just trolling, cut it out.
>
> When something is even in the "hey look, it works, here's the big
> changes from last time", we will of course post it, but right now,
> things are being totally revisited based on the feedback we have
> received so far. Give people a chance to recover from conferences and
> then get back to work...
If there are public discussions about it elsewhere, you could have
simply pointed at those instead being condescending.
--
M?ns Rullg?rd
[email protected]
On Mon, Nov 9, 2015 at 9:07 AM, Greg KH <[email protected]> wrote:
> On Mon, Nov 09, 2015 at 05:02:45PM +0000, Måns Rullgård wrote:
>> Andy Lutomirski <[email protected]> writes:
>>
>> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <[email protected]> wrote:
>> >> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>> >>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <[email protected]> wrote:
>> >>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:
>> >>> >> Hi all,
>> >>> >>
>> >>> >> after reading on the removal of kdbus from Rawhide[1] I've searched
>> >>> >> the mailinglist archives for more details but didn't find anything.
>> >>> >> So, what are your plans?
>> >>> >>
>> >>> >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html
>> >>> >
>> >>> > As that link said, based on the result of the code being in Rawhide, it
>> >>> > is now being reworked / redesigned. The result will be posted for
>> >>> > review "when it's ready".
>> >>>
>> >>> If you rework/redesign something you have to know what you want to change.
>> >>> That's why I was asking for the plan...
>> >>
>> >> Since when do people post "plans" or "design documents" on lkml without
>> >> real code? Again, code will be posted when it's ready, like any other
>> >> kernel submission.
>> >
>> > I ask for feedback on ideas and designs on a fairly regular basis. I
>> > even frequently get valuable feedback :)
>> >
>> > I would like to think that the kernel community would have something
>> > of value to add to the process of designing and implementing a major
>> > new IPC mechanism.
>>
>> The "trust us, we'll show it when it's ready" attitude reminds me of the
>> controversial TPP and TTIP negotiations.
>
> Ok, that's just trolling, cut it out.
>
> When something is even in the "hey look, it works, here's the big
> changes from last time", we will of course post it, but right now,
> things are being totally revisited based on the feedback we have
> received so far. Give people a chance to recover from conferences and
> then get back to work...
>
I hate to say this, but this approach to receiving feedback makes me
really dislike the process.
I read a fairly large fraction of the kdbus code. I found what I
perceived to be issues, and I spoke up. I was told for quite a while
that the authors disagreed that the issues I found were issues and
that my assessment of the security aspects of the code was correct.
Now the submission has been withdrawn (because of feedback received so
far? from me?) and there will apparently be a new submission out of
the blue, allegedly based on feedback.
As a developer, I'm willing to ask for feedback on ideas and to ask
for feedback on code. In many cases, I've gotten (correct!) feedback
telling me that my design is wrong or needs major changes. I *always*
try to answer such feedback respectfully and, if the reviewers are
right (which they usually are), I won't keep shoving code they don't
like in their face. In fact, IIRC I got my start as a serious x86
developer when I wrote some code and tglx told me that the way I
designed it was unacceptable for upstream. In response, I thought
about what the issues were, asked some questions, and rewrite the
majority of the code. I think I learned a lot from the process, and
the code was vastly improved as a result. If I'd sent substantially
the same patch series three or four more times and then declared that
I was withdrawing it without commenting directly on what I'd changed,
I really doubt that anyone would have taken my next submission
seriously.
Please understand that kdbus' approach to receiving feedback is very
off-putting. Fortunately the vast majority of kernel developers
receive feedback for graciously and transparently, because otherwise
I'd probably just never review anything. Frankly, if I were in the
chain of people through whom the kdbus code would flow to an eventual
home in Linus' tree, I would just say that the developers have used up
my patience as a reviewer and the onus would be on the developers to
demonstrate that it's worth my time to continue thinking about the
code.
--Andy
[unrelated quotes trimmed, attribution preserved.]
> >> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <[email protected]> wrote:
> >> >> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
> >> >>>
> >> >>> If you rework/redesign something you have to know what you want to change.
> >> >>> That's why I was asking for the plan...
> >> >>
> >> >> Since when do people post "plans" or "design documents" on lkml without
> >> >> real code? Again, code will be posted when it's ready, like any other
> >> >> kernel submission.
> >> >
tl;dr: perhaps they should start doing that.
In the case of kdbus' 4.1 iteration, several of its defects could've been
spotted from its design alone. For examples: the expected userspace
behaviour when clients and servers notice that a message wasn't delivered
(which was underspecified to say the least); difficulty in guaranteeing
forward progress in the face of e.g. surprising scheduling behaviour and the
dropped_msgs field; the O(n) nature of the broadcast filtering bitmap
construct wrt # of connections on the bus[0]; and the feature that permits
opaque falsification of sender credentials by the bus owner[1].
Each of these has a significant real-world impact on designs built atop
kdbus, regardless of whether such things are closer to a layman's
approximation of formal engineering or green-field hack-job proofs of
concept. Literally each must be accounted for in userspace applications that
even as much as breathe in kdbus' direction. I'd have hated to run into the
credential-faking feature if I'd already been sack-deep into a derivative
that relied on the integrity of kdbus' metadata; and as of the most recent
version, the effects of a broadcast storm during high scheduling latency
(load, memory pressure, block device lag, w/e) were still very difficult to
parlay into a predictable design that left no dangling wires.
I don't mean to suggest that the defects cited were due to an incomplete
understanding of kdbus (or indeed IPC) on the part of its authorship.
However there's a very strong argument that these aspects weren't considered
when kdbus was submitted for inclusion, and then given a hard shove.
Moreover, even a semi-formal requirements document would've made reviewing
kdbus much easier without compromising quality of review. As it stood, the
things that would be reasoned about during review had to be sussed out from
kdbus' API documentation, the comments of its developers elsewhere, various
forms of PR surrounding the topic, header files, and from existing knowledge
of things that really must be in there somewhere (e.g. locking).
Similarly knowing the (implicit, patchwork, _anything_ really) arguments why
kdbus' design meets those requirements, how its implementation corresponds
to the design, and how its test suite verifies that the design's properties
are present in the implementation, would've permitted review besides the
"off-road" style which would therefore have been available sooner. That's to
say: there'd have been less of the cranium-oriented demolitions on both
sides of the fence, if any kind or quality of design document had been
available.
Considering that a req spec would've led to a design spec, in turn leading
to impl and test plans, each subject to review, the utility that could've
been had _at 0 SLOC_ would've definitely been significant. Also, their
existence would help manage long-term rot of the implementation and its test
suite by making both unambiguously remediable where rot's effects were
discovered[2]. Further progress could be built on that foundation instead of
hacks upon hacks, ever-mounting technical debt, and eventual CADT.
For instance: who's had a poke at Linux mm in the past two years? Or the
scheduler? Who even could, and where would they start? Both appear as
interlocking mishmashes of subtle oft-historical concerns ranging from the
humdrum to "must have been employed at SGI in the early aughties to
understand" grade NUMA, making each alteration unverifiable outside of test
environments the hacker has access to -- i.e. VMs and maybe a handful of
off-the-shelf microcomputers. IIRC the last major scheduling change was a
nigh-complete rewrite that had CFS emerge from failings indicated by Con
Kolivas' interactivity work.
I'm sure there's people who're well savvy to mm, sched, and maybe even both
at once. To the rest of us it might as well be opaque as far as
non-regressive modification is concerned. kdbus is certainly big enough to
suffer a similar fate, given time.
On Mon, Nov 09, 2015 at 09:23:34AM -0800, Andy Lutomirski wrote:
> On Mon, Nov 9, 2015 at 9:07 AM, Greg KH <[email protected]> wrote:
> > On Mon, Nov 09, 2015 at 05:02:45PM +0000, M?ns Rullg?rd wrote:
> >> Andy Lutomirski <[email protected]> writes:
> >>
[quote moved up top]
> >> > I ask for feedback on ideas and designs on a fairly regular basis. I
> >> > even frequently get valuable feedback :)
> >> >
> >> > I would like to think that the kernel community would have something
> >> > of value to add to the process of designing and implementing a major
> >> > new IPC mechanism.
> >>
> >> The "trust us, we'll show it when it's ready" attitude reminds me of the
> >> controversial TPP and TTIP negotiations.
> >
> > Ok, that's just trolling, cut it out.
> >
> > When something is even in the "hey look, it works, here's the big
> > changes from last time", we will of course post it, but right now,
> > things are being totally revisited based on the feedback we have
> > received so far. Give people a chance to recover from conferences and
> > then get back to work...
> >
>
> I hate to say this, but this approach to receiving feedback makes me
> really dislike the process.
>
> I read a fairly large fraction of the kdbus code. I found what I
> perceived to be issues, and I spoke up. I was told for quite a while
> that the authors disagreed that the issues I found were issues and
> that my assessment of the security aspects of the code was correct.
>
> Now the submission has been withdrawn (because of feedback received so
> far? from me?) and there will apparently be a new submission out of
> the blue, allegedly based on feedback.
>
This serves to discourage my review as well. What do we have to go on
besides diffs? The submitter (and his/her organization) is privy to all the
knowledge on what changed, and we are not. There's not even clarity on what
parts of review so far is being accounted for.
It's like the KHTML guys and A###e's source code dumps: sync up all over
again or flippity-flapping fudge off.
[rest of Andy's post snipped. hopefully I got the CC's right this time
around.]
-KS
[0] an alternative design would associate every bus-connection with a number
of arbitrary 32-bit identifiers and filter broadcast messages according to a
disjunction of conjunctions of their presence, giving exact filtering and
time complexity linear to # of connections that genuinely need to receive a
given message. With a bit of storage cleverness, the required merge/uniq
algorithms could be implemented in a branch-free fashion, yielding extreme
micro performance and a predictable upper bound for space during
filter-clause evaluation.
[1] IPC mechanisms exist that permit sender-faking ("propagation")
transparently. Some allow fake receivers ("redirection") as well. Whether
either is necessary under monolithic Unix is anybody's guess.
[2] as for documentation rot, no comment.