On Sat, 2013-01-26 at 12:12 -0800, Jordan Justen wrote: > > Is this still an issue? If so, why not use EBDA?
Kevin seemed very reluctant when this was suggested. We *have* RAM at 0xE0000-0xF0000 that is perfectly usable if we handle things correctly. > I think it is extremely unlikely that EFI_COMPATIBILITY16_TABLE will > be modified. I hope that's not the case; there's no reason we couldn't extend it in a backwards-compatible manner. If we can't get it fixed properly, I suspect people will end up carrying a patch to fix it. Or we'll find some platform-specific hack like putting the extra data in the Oem16Segment/Oem16Offset. But that would just be crap. We *need* to fix the lack of high persistent (runtime) memory, and the lack of a LUN field in the BBS_TABLE is also a fairly serious problem. I think we probably ought to be able to do a 0.98 version of the CSM spec... -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
