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: <20080731224222.GB9208@mx.loc>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ