linux-kernel - Re: Problem with restricted I2C algorithms in kernel 2.6.26!

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-next>] [day] [month] [year] [list]

Message-ID: <489B6A66.40605@linuxtv.org>
Date:	Thu, 7 Aug 2008 17:34:30 -0400 
From:	mkrufky@...uxtv.org
To:	khali@...ux-fr.org
Cc:	sam@...nborg.org, user.kernel@...il.com,
	linux-kernel@...r.kernel.org, i2c@...sensors.org
Subject: Re: Problem with restricted I2C algorithms in kernel 2.6.26!

Jean Delvare wrote:
> Hi Michael,
>
> On Thu, 7 Aug 2008 15:03:36 -0400, Michael Krufky wrote:
>   
>> I agree with Trent and D.Kelly
>>
>> These options should be made available to the user -- We should go
>> with the patch that Jean posted, "Subject: i2c: Let users select
>> algorithm drivers manually again" -- this is a fair compromise for
>> both sides -- users that dont know should leave the automatic
>> selection enabled.  Users that know better can disable the automatic
>> selection and enable what they need.
>>
>> The statement, "just have the external driver merged into the kernel"
>> is not a solution.
>>     
>
> Why not, please? A vast majority of drivers work fine that way today. I
> am still waiting for someone to give me a good reason why some other
> drivers supposedly can't be merged upstream (something better than
> "believe me, it's impossible".)
>
>   

Nobody said that a driver "...can't be merged upstream" ...  but 
REQUIRING a driver to be merged upstream to allow development and / or 
testing is a problem, IMHO.

If you required that all of my development happens within a git 
development repository, preventing me from working against distro-kernel 
xyz, then I would simply spend more time on Windows driver development 
and my Linux contributions would cease.

External subsystem development repositories allow us to work against 
stable kernels at our own pace.  When driver X is ready to be merged, it 
gets merged.

With the model that you propose, "use linux-next for development" ... 
well then what about testing?  Who is going to test my driver if it 
requires a full kernel compile?

Khali, you know me, and you know that I am always in favor of merging 
drivers into the kernel.  The ability to choose a kernel's features is 
an option that should not be removed.

>> Removing the option to build those additional algos is a regression, IMHO
>>     
>
> Will be addressed soon, do not worry.
Regards,

Mike
--
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/