linux-kernel - Re: rtc/hctosys.c Problem during kernel boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Jun 2014 14:36:15 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Alexander Holler <holler@...oftware.de>
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

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 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.

Similarly I appreciate your continued participation here, even if its
just to resend your patches and provide more context to others wanting
to solve the issue properly. But it might be better not get into
personal tangents, and instead focus on the technical merits and
issues with the potential approaches.

thanks
-john
--
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/