Message-ID: <53AD2F99.1010004@ahsoftware.de>
Date:	Fri, 27 Jun 2014 10:47:21 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	John Stultz <john.stultz@...aro.org>
CC:	John Whitmore <arigead@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: rtc/hctosys.c Problem during kernel boot

Am 23.06.2014 23:36, schrieb John Stultz:
> On Sat, Jun 21, 2014 at 6:08 AM, Alexander Holler <holler@...oftware.de> wrote:
>> Am 12.06.2014 01:53, schrieb John Stultz:
>>
>>> You can read some of the previous discussion here:
>>> https://lkml.org/lkml/2013/6/17/533
>>>
>>> I'd be very interested in patches to resolve this!
>>
>>
>> And the silence as response to my repost of my already working patches just
>> proved that isn't true.
>
> You put in your patches the following:
> "Besides discussing possible *real* bugs, I don't care what any person
>   (including maintainers) will request. I'm fine with these patches (I'm
>   using them since a year) and I don't play remote keyboard or
>   patch ping-pong. If someone want changes I suggest he gets responsible
>   for them himself and just puts a patch on top of my patches. And in any
>   case, feel free to completely ignore these patches."
>
> I've pointed out problems with your patchset earlier, and you refuse
> to address them. That's totally your prerogative, and that's fine, but
> I don't know how I should respond here.

I've written that because I will not add a totally unnecessary lock in a 
code path which does set the system time. If multiple RTCs do race to 
set the system time, the system was configured wrong and is already 
untrustworthy and a lock inside the kernel won't help. Especially 
because it will not remove the race, and just solve it somehow. And 
that's happen without a lock (which might block or even dead lock if 
done wrong) too.

So if you want a lock there, please add such a patch yourself and be 
responsible for it. I will not do such.

> I agree that there is an issue here that your patches try to address,
> which needs to be fixed, but I'm hoping John Whitmore might be able to
> read the discussion and either rework your patches or write his own to
> address the issue without the problems in your patch I pointed out.
>
> I've removed the rest of your anti-maintainer rant here, but I will
> say that I do very much understand that the upstream kernel community
> process can be frustrating at times. I have myself had to start over
> many many times on patches when maintainers request, and sometimes my
> patches don't ever make it past the bar for acceptance. So I very much
> do see this from both sides, and despite my frustration, I appreciate
> that folks are looking over my patches carefully for design and
> maintenance issues, because without the high standards, the kernel
> code would be in much worse shape.

Unfortunately I really think you believe what you are writing.

But my experience is that even totally silly and very small bugfixes 
like oneliners are discussed to death and do need years to end up in a 
mainline kernel, if they end up there at all.

And it doesn't help if maintainers do request silly things. My 
experience here is that they always will request a change, even for 
perfect patches, just to request something. If a patch contains a 
variable named red, they would request to change it to green and if it 
would have a name green, they would request to change it to red.

So I'm sorry, but in my humble opinion that isn't how a high standard 
does look like. Many request from maintainer are just capriciousness or 
despotism and often maintainers are totally wrong. And discussing with 
them just leads to ignored patches/bugfixes.

Regards,

Alexander Holler

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

Powered by blists - more mailing lists