linux-kernel - Re: [patch 1/4] Configure out AIO support

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:	Fri, 1 Aug 2008 00:42:22 +0200
From:	Bernhard Fischer <rep.dot.nop@...il.com>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	michael@...e-electrons.com, Matt Mackall <mpm@...enic.com>,
	bcrl@...ck.org, linux-aio@...ck.org, akpm@...ux-foundation.org
Subject: Re: [patch 1/4] Configure out AIO support

On Thu, Jul 31, 2008 at 01:12:19PM +0300, Adrian Bunk wrote:
>On Thu, Jul 31, 2008 at 12:09:29PM +0200, Bernhard Fischer wrote:
>> On Thu, Jul 31, 2008 at 11:27:04AM +0200, Thomas Petazzoni wrote:
>> >This patchs adds the CONFIG_AIO option which allows to remove support
>> >for asynchronous I/O operations, that are not necessarly used by
>> >applications, particularly on embedded devices. As this is a
>> >size-reduction option, it depends on CONFIG_EMBEDDED. It allows to
>> >save ~7 kilobytes of kernel code/data:
>> 
>> Shouldn't this also make sure not to install aio_abi.h or at least an
>> empty aio_abi.h?
>
>The userspace headers are independent of any kernel configuration
>(except for the architecture).

I beg to disagree:
internals as exposed by e.g. aio_abi.h are impl dependent. Noone except
the impl and it's users are interrested in it.

If a per package feature, independent of arch, is off, all respective
features stuff should be off for that particular installation.

I.e. if I, for subsequent installations, choose to turn on feature, the
requested feature-stuff will be installed properly. If I, OTOH, choose
to (keep to) turn off feature, then all feature-related stuff should --
and has to be and stay -- turned off.

In the particular case of the kernel exposing unwanted API extensions
that are off, all such API reminiscences should be off, thus not
installed to my staging dir at all since i explicitely asked for doing
away with all of the API.

>From a libc POV i'd agree, but from an inherently broken userspace POV
installing willingly broken stuff is just wrong and misleading, imo.
--
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/