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.0702141130340.20368@woody.linux-foundation.org>
Date:	Wed, 14 Feb 2007 11:32:34 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jean Delvare <khali@...ux-fr.org>
cc:	Dax Kelson <dax@...ulabs.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Linus' laptop and Num lock status



On Wed, 14 Feb 2007, Jean Delvare wrote:
> 
> On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> RAM (offset 0x497). This is how Suse's hwinfo does.

Heh. Shows just how much I ever used DOS and BIOS.

> But maybe the first question to ask is: why is the BIOS setting lost in
> the first place? Why is the kernel resetting the led state?

Ehh. Silly question. "Those flags, they do nothing."

The kernel needs to know what they are in order to react correctly to 
them. And since you can't read them from hardware, the only way to know 
what they are (if you don't know about BIOS magic areas) is to SET THEM.

Which is what the kernel has traditionally always done.

		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