linux-kernel - Re: [PATCH 00/11] SFI: Simple Firmware Interface

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: <20090817100628.GA21498@elte.hu>
Date:	Mon, 17 Aug 2009 12:06:28 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Len Brown <lenb@...nel.org>
Cc:	x86@...nel.org, sfi-devel@...plefirmware.org,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 00/11] SFI: Simple Firmware Interface - v3

* Len Brown <lenb@...nel.org> wrote:

> Changes since v2:
> 
>  re-based to v2.6.31-rc6
> 
>  included here some patches from the ACPI tree
>    that prepare for SFI
> 
>  deleted MMAP table parsing code
>    It isn't needed in the kernel, since on all known SFI boxes today,
>    the booter parses this table for us.
> 
>  fixed some build issues, generally related to CONFIG_ACPI=n
> 
>  various cosmetic changes in response to v2 code review
> 
> What is left to do:
> 
>  x86_32 can set CONFIG_PCI_MMCONFIG=y when
>  SFI=y and ACPI=n, but x86_64 can not, yet.
> 
>  A number of drivers will use SFI and will provide
>  their own table parsers, but those will come later.

Ok, this iteration is even nicer.

  Reviewed-by: Ingo Molnar <mingo@...e.hu>

A patch technical request/suggestion. I guess you'd like to keep 
these bits in the ACPI tree, so that you can test it and merge it 
with ongoing ACPI changes, right?

That would be fine to me for all the arch/x86/ touching patches, 
except for this one:

 [PATCH 05/11] ACPI, x86: expose some IO-APIC routines when CONFIG_ACPI=n

I'd like to pick this one up into tip:x86/apic, because there's 
ongoing work in this area. (also, by the looks of it, i'd not be 
surprised if this patch needed some testing. This is fragile code 
with quirky Kconfig dependencies.)

I can create a standalone topic for this (based on .31-rc6), 
containing this single commit, which you could pull into the ACPI 
tree? That way we both can have this commit and nobody is held up, 
and both trees can be pushed to Linus in the .32 merge window, 
independently of each other.

	Ingo
--
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/