On Tue, Oct 23, 2012 at 10:05:01AM -0600, Randy Wright wrote: > On the first: one way to be compliant with such a requirement would be > to design systems that implement softfail in this particular region. > What about a system that hardfails, but on which the resulting machine > check can be handled by the kernel machine check handler? Would > appropriate re-ordering of the kernel initialization code to support > such systems be acceptable?
Good question. I don't maintain that code, so I can't really answer it... > Also, let me mention a possible amendment to your first idea: what if > the mandate that probing be supported were qualified by some attribute > that could be indicated in the UEFI environment? For example: instead > of just a hole in the UEFI memory map, what if this range was > specifically present and typed as EfiUnusableMemory? Another idea for > UEFI systems - but one requiring a UEFI specification change - might be > adding a UEFI variable that if present, indicates any area not > explicitly included and typed in the UEFI memory map (including the > legacy adapter region) must be explicitly avoided by an OS. Yeah, I think if it were marked unusable we could probably justify staying away from it. > > 2) Don't call probe_roms() by default, but leave it up to the graphics > > drivers. If they can get the rom by any other means then don't call it. > > One the second idea: there are a quite a lot of video drivers in the kernel > source tree. Do you have a suggestion for how to evaluate which ones > rely on the setup performed by probe_roms? Realistically - intel, radeon and nouveau. Basically, anything that calls pci_map_rom() and is under drivers/gpu/drm. I'll look into a patch that does that. -- Matthew Garrett | mj...@srcf.ucam.org -- 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/
