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: <20060907114358.GA26551@flint.arm.linux.org.uk>
Date:	Thu, 7 Sep 2006 12:43:58 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Andi Kleen <ak@...e.de>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org, Roman Zippel <zippel@...ux-m68k.org>,
	linux-arch@...r.kernel.org
Subject: Re: [2.6 patch] re-add -ffreestanding

On Thu, Sep 07, 2006 at 12:27:40PM +0200, Adrian Bunk wrote:
> And I'm getting bashed for sendind a patch to revert it "only" to 
> linux-kernel...

You're not getting bashed - you're getting directed to the correct place
to discuss this issue.  There are some architecture maintainers who might
have some input who aren't subscribed to linux-kernel.

Incidentally, the addition of -ffreestanding was only sent to linux-kernel
in the first place back in 2004, so this actually gives those architecture
maintainers a chance to actually comment on it.  At the time, no one
commented on it - maybe it got missed?  I certainly did.

 http://marc.theaimsgroup.com/?l=linux-kernel&m=110194462121275&w=2

As far as your argument that the kernel is not a hosted environment, that's
debatable (as you're finding out).

If we decide that we want the compiler to treat our source as if it were a
hosted environment, and we provide sufficient implementation of a conforming
nature of a hosted environment then that is our perogative to do so.  That
is a decision that we are entirely free to make.  By doing so, we take on
the responsibility to provide whatever is required for a hosted environment
as opposed to the more limited functionality of a freestanding environment.

We _have_ taken on that responsibility.  We have even taken on the
responsibility to provide the compiler's internal library functions in
some cases.

The question really comes down to two points:

1. do the C standard defined library services we use in the kernel have
   the behaviour required by the C standard
2. do we provide everything that the compiler would want to use in the
   environment mode we have chosen.

The answer to both is generally yes, except when something is omitted for
a reason.  (eg, float support.)

And two final points:

- according to what I read in the gcc manual, free standing environments
  are required to provide float support.  We don't, so it could be possible
  to argue that we provide neither a freestanding nor a hosted environment,
  and, therefore, we shouldn't be using gcc at all.

- architecture maintainers should be left to decide what implementation
  option they require the kernel to be built in, since it's the architecture
  support code which provides most of the runtime environment.

> Adrian
> (who has just deleted all his cross compilers for getting rid of all 
>  these troubles)

If that's how you feel and what you've done, you seem to have disqualified
yourself from handling generic kernel changes.

I notice that you didn't respond to anything else in my message, so I can
only assume that you've accepted my reasoning and are no longer going to
push this patch.  So treat the above as the finer detailed reasoning.

I'm not anti--ffreestanding per se, but if we _are_ going to switch (back)
to that compiler mode, I want to ensure that we aren't walking backwards
from the point I _thought_ we were at.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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