linux-kernel - Re: x86 BIOS interface for partitioning and system serial number on SGI UV

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:	Tue, 5 Aug 2008 01:21:46 -0400
From:	"Kyle Moffett" <kyle@...fetthome.net>
To:	"Russ Anderson" <rja@....com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, mingo@...e.hu,
	tglx@...utronix.de, linux-kernel@...r.kernel.org,
	"Jack Steiner" <steiner@....com>
Subject: Re: x86 BIOS interface for partitioning and system serial number on SGI UV

On Mon, Aug 4, 2008 at 6:19 PM, Russ Anderson <rja@....com> wrote:
> On Fri, Aug 01, 2008 at 10:34:30AM -0700, H. Peter Anvin wrote:
>>Russ Anderson wrote:
>>>+# define BIOS_CALL(result, a0, a1, a2, a3, a4, a5, a6, a7)          \
>>>+    do {                                                            \
>>>+            /* XXX - the real call goes here */                     \
>>>+            result.status = BIOS_STATUS_UNIMPLEMENTED;              \
>>>+            result.v0 = 0;                                          \
>>>+            result.v1 = 0;                                          \
>>>+    } while (0)
>>
>> I have more than a little problem with submitting patches like this.  We
>> have no way to judge the suitability of the coding or the interface with
>> the "meat" of the driver stubbed out!
>
> This is also code for hardware that does not exist.  In order for the
> code to be in distro releases in time for the hardware to ship, we
> must push it _before_ we have hardware.  The main concern is getting in
> interfaces now, because the interfaces cannot change in a minor release.
> Providing more "meat" is on the ToDo list.

These kinds of statements are not the way to get things done on LKML.
Quite a number of people have gotten flamed/ignored/etc lately by
making statements "We need this (unfinished code) in the kernel by
2.6.27 because RHEL6 is going to use 2.6.27 and otherwise we won't be
supported in RHEL6".

Cheers,
Kyle Moffett
--
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/