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: <Pine.LNX.4.64.0607242246530.29649@g5.osdl.org>
Date:	Mon, 24 Jul 2006 23:00:05 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Andrew Morton <akpm@...l.org>
cc:	Edgar Hucek <hostmaster@...soft.at>, ebiederm@...ssion.com,
	hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]



On Mon, 24 Jul 2006, Linus Torvalds wrote:
> 
> Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so we now 
> have x86 machines with EFI as the native boot protocol.

Btw, that's not totally new. I think some people played around with EFI on 
x86 even before Apple came around. And don't get me wrong - the problem 
with EFI is that it actually superficially looks much better than the 
BIOS, but in practice it ends up being one of those things where it has 
few real advantages, and often just a lot of extra complexity because of 
the "new and improved" interfaces that were largely defined by a 
committee.

I think a lot of the "new standards" tend to be that way. Trying to solve 
a lot of problems and allow everybody to add their own features, instead 
of just saying that it's better to just standardize the hardware.

For example, instead of ACPI, we could just have had standardized hardware 
(and a few tables to define things like numbers of CPU's etc). It would 
have been simpler for everybody. But no, people seem to think that it's 
somehow "better" to have wild and crazy hardware, and then have a really 
complicated way of describing it - and driving it - dynamically.

So EFI has this cool shell, a loadable driver framework, and other nice 
features. Where "nice" obviously means "much more complex than the simple 
things they designed in the late seventies back when people were stupid 
and just wanted things to work".

Of course, it's somewhat questionable whether people have actually gotten 
smarter or stupider in the last 30 years. It's not enough time for 
evolution to have increased our brain capacity, but it certainly _is_ 
enough time for most people to no longer understand how hardware works any 
more.

Not a good combination, in other words.

Not that I'd ever claim that the BIOS is wonderful either, but at least 
everybody knows that the BIOS is just a bootloader, and doesn't try to 
make it anything else. 

The absolutely biggest advantage of a BIOS is that it's _so_ inconvenient 
and obviously oldfashioned, that you have to be crazy to want to do 
anything serious in it. Real mode, 16-bit code is actually an _advantage_ 
in that sense. People know how to treat it, and don't get any ideas about 
it being some grandiose framework for anything else than "just load the OS 
and get the hell out of there".

			Linus
-
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