linux-kernel - Re: [PATCH] drivers/tty: Folding Android's keyreset driver in sysRQ

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:	Sat, 20 Oct 2012 10:38:57 -0600
From:	Mathieu Poirier <mathieu.poirier@...aro.org>
To:	Arve Hjønnevåg <arve@...roid.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	rdunlap@...otime.net, kernel-team@...roid.com,
	john.stultz@...aro.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH] drivers/tty: Folding Android's keyreset driver in sysRQ

On 12-10-16 09:35 PM, Arve Hjønnevåg wrote:
> On Fri, Oct 5, 2012 at 12:48 PM, Mathieu Poirier
> <mathieu.poirier@...aro.org> wrote:
>> On 12-10-05 12:16 PM, Dmitry Torokhov wrote:
>>> On Fri, Oct 05, 2012 at 11:59:29AM -0600, mathieu.poirier@...aro.org wrote:
>>>> From: "Mathieu J. Poirier" <mathieu.poirier@...aro.org>
>>>>
>>>> Andrew,
>>>>
>>>> After requesting a number of changes that, to my understanding
>>>> have been implemented, I have not been able to get the attention
>>>> of the subsystem maintainer on this patch.
>>>>
>>>> If there are still issues, I'm open to making changes but I want
>>>> to make sure it doesn't get forgotten.  If there no objections,
>>>> would you consider queuint it ?
>>>
>>> Mathieu,
>>>
>>> I have the same objection as before: using platform device solely for
>>> the purpose of passing some data from board code to the driver. Surely
>>> there are other ways of passing this bit of data... What about, for
>>> example, making it an empty weak symbol so that board code could
>>> override it with strong one?
>>
>> Thanks for the comments - I will implement a weak function in the
>> keyreset driver.
>>
> 
> A weak symbol does not work. A single kernel can support multiple
> devices that have unique reset key combinations.
> 

I'm afraid Arve has a point here...  His comment about supporting
multiple combinations got me thinking and forced me to dive back in the
code.

The original keyreset driver can indeed be instantiated multiple times
while the sysrq driver is a one instance model.  In its current
implementation the keyreset extension can only support one reset sequence.

But does a system realistically need to support more than one reset
sequence ?

If so then I can enhance the keyreset extension of the sysrq driver but
that will also mean, as stated by Arve, that we will need to keep the
platform data.  On the flip side it is deemed sufficient to support a
single reset sequence then I'll implement the weak symbol method.

The subject is up for debate, please chime in with your opinion.

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