> -----Original Message----- > From: Borislav Petkov [mailto:b...@amd64.org] > Sent: Monday, August 20, 2012 1:20 PM > To: H. Peter Anvin > Cc: Yu, Fenghua; Henrique de Moraes Holschuh; Ingo Molnar; Thomas > Gleixner; Mallick, Asit K; Tigran Aivazian; Andreas Herrmann; Borislav > Petkov; linux-kernel; x86 > Subject: Re: [PATCH 04/11] x86/microcode_core_early.c: Define > interfaces for early load ucode > > On Mon, Aug 20, 2012 at 01:08:49PM -0700, H. Peter Anvin wrote: > > On 08/20/2012 07:06 AM, Borislav Petkov wrote: > > > > > > Or, > > > > > > in case we want to supply more vendor-specific stuff early at boot, > we > > > could do: > > > > > > kernel/x86/<vendor>/microcode... > > > |-> bios_overrides > > > |-> ... > > > > > > and have this layout extensible from the beginning... > > > > > Does that make sense, though? > > Only time will tell. I was simply saying that we should leave ourselves > the door opened, should we need functionality like that in the future. > > > I'm a bit concerned about having multiple files named microcode.bin > by > > default; the pathname isn't as sticky as the filename when people > move > > things around... > > Ok, I see. > > How about the following scheme then: > > kernel/x86/<vendor>-microcode.bin > kernel/x86/<vendor>-bios-overrides.blob > ... > > ? > > All I'm saying is maybe we should impose some sanity rules now before > people go crazy with this and things get out of hands...
We might name the cpio directory as: kernel/x86/microcode/GenuineIntel.bin kernel/x86/microcode/AuthenticAMD.bin kernel/x86/acpi/... etc. This is expendable for the future usage. Plus I will add a doc on the cpio directory, supported directory names and how to add new stuffs in the directory. Thanks. -Fenghua Thanks. -Fenghua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/