linux-kernel - Re: tighten ATA kconfig dependancies

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

Message-ID: <20060716061706.GB29733@mars.ravnborg.org>
Date:	Sun, 16 Jul 2006 08:17:06 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	7eggert@....de, Dave Jones <davej@...hat.com>,
	linux-ide@...r.kernel.org,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: tighten ATA kconfig dependancies

On Sun, Jul 16, 2006 at 08:04:47AM +0200, Arjan van de Ven wrote:
> 
> > A cross compile toolchain is the only real soluion. Otherwise we would
> > soon end up with far to many drivers selectable for x84-64.
> 
> if the *driver* is not platform specific, what is the problem with that?
and
> The only difference between x86 and x86-64 is isa-bus
> cards and things that were put on a motherboard but never on a PCI card.
and
> That's maybe a dozen or two total for the entire kernel, and a set that
> is not growing.
By that definition there are still a lot of candidates out-side the IDE
world. The x86 versus x86-64 is irrelevant here. The point is that
kconfig is used to select only relevant options for any given
architecture and with the above definition we could simply boil it down
to "make only what cannot compile for an arch non-selectable".

We have a nice kconfig system that is extensively used to secure we have
a valid kernel configuration all the time and we go long to secure this.
Should we now start to breake that apart to start to give drivers more
compile coverage just becasue that's a tad easier. That brakes the
fundamental of the kconfig in the first place namely to secure valid
configurations.

It is nto the IDE patch as such that is the topic here. It is the
general issue if kconfig at all shall allow one to select drivers that
is not suitable for your HW. Tomorrow it will be a bunch of ARM
drivers..

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