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

Message-ID: <37219a840808071203y36775d8fx5cccd653da04e1fc@mail.gmail.com>
Date:	Thu, 7 Aug 2008 15:03:36 -0400
From:	"Michael Krufky" <mkrufky@...uxtv.org>
To:	"Jean Delvare" <khali@...ux-fr.org>
Cc:	"Sam Ravnborg" <sam@...nborg.org>,
	"D. Kelly" <user.kernel@...il.com>,
	"mailing list: linux-kernel" <linux-kernel@...r.kernel.org>,
	"Linux I2C" <i2c@...sensors.org>
Subject: Re: Problem with restricted I2C algorithms in kernel 2.6.26!

On Thu, Aug 7, 2008 at 2:49 PM, Jean Delvare <khali@...ux-fr.org> wrote:
> On Thu, 7 Aug 2008 20:39:44 +0200, Sam Ravnborg wrote:
>> >
>> > Alternatively, I am curious if our build system couldn't allow 3rd
>> > party drivers to select in-tree modules. Obviously this would require
>> > the complete kernel source tree to be available, instead of just the
>> > header and config files as is usually the case. Sam, is this possible
>> > to do that at this time? If not, is this something that could be
>> > implemented, or is this too much work for the thin benefit?
>>
>> In general I recommnd to have the full kernel source available
>> simply because we have no in-kernel solution to create the required
>> set of files to build external modules.
>>
>> And today there is no way to hook into the kernel configuration
>> for an external module. First of we cannot allow changes in
>> the build kernel module as this would destroy module versioning
>> for instance.
>>
>> And in this case you ask because you would change the kernel
>> configuration.
>>
>> And I fail to see why this stuff cannot be done inside the
>> kernel source tree. Merging new kernel updates should be absolutely
>> trivial and then the drivers are better prepared for upstream anyway.
>
> OK, thanks for the clarification.
>
> Maybe one way would be for the external module build system to copy (or
> link to) the missing driver source from the kernel tree and build it
> locally with the rest of the external drivers, if it wasn't enabled in
> the original kernel configuration and they need it. That's probably
> just a couple lines of shell script, should be pretty easy. Obviously
> this only works for kernel options which only select a given driver and
> have no side effect on the rest of the kernel. And this is more
> user-friendly than having the user check its kernel configuration and
> rebuild his/her kernel.
>
> Just a thought anyway...
>
> --
> Jean Delvare

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.

Removing the option to build those additional algos is a regression, IMHO

Regards,

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