I have a feeling that will be useful later on, thanks for that tip.
You're welcome, Pooky!
The PureDarwin issue: PureDarwin, though it does use a Darwin kernel, is more like Linux than Mac OS. The troubles I believe that AMD (and legacy Intel) people have are related to non-Darwin (a.k.a. OS X-specific) components. Although the changes needed for AMD/legacy Intel are in the kernel, the original problems occur (in my knowledge) because of interactions between the Mac OS components (kexts, system daemons etc.) and the kernel.
Yeah, it's that why we have to be careful with what we change. If there's some crucial kernel task requiring ssse3, for an example (and in Lion it seems that's the case for 64-bit support, according to David Elliot's page), simply erasing or bypassing ssse3 calls and checks won't solve anything: we'll have to substitute them for sets of supported instructions that do the same thing. Could be even worse: for example, suppose there's no crucial task that uses those much discussed ssse3 instructions in the kernel itself, but important kernel extensions were written taking those instructions for granted? This is an awful prospect. In this case, we'll need a runtime ssse3 emulator, precisely the thing that we're trying to avoid at all costs.
Also, something I'd like to know is whether or not getting legacy Intel to work would require the same work as AMD or more/less, or if it must be a totally different approach...I know that the main topic is AMD, but me and many others also have legacy Intel boxes.
I think that's the same principle, the same idea. The ideal scenario (and meklort expressly advised me to seek it) is not to simply add AMD patches, but to hinder the CPU ID checks and replace the modern-Intel-only CPU instructions calls, if needed, with ones that permit the kernel and extensions to run on the largest array possible of x86 CPU models.
Another thing I'm thinking is...let's stick with Lion XNU for now. ML has, from what I can see, a lot more architectural differences than Lion, so probably fixing Lion's issues first is the best idea.
I'm not sure if i agree here. Mountain Lion drops support to more hardware than Lion, that's a certainty, but that doesn't mean that solving its issues with unsupported hardware, as far as the kernel is concerned, would be more problematic than with Lion already was. Besides this, Lion issues, in a certain way, are solved: we can alread run it on a vast collection of otherwise unsupported hardware, either by simply patching it (Atom CPUs) or add the boot flag -legacy to the patches so it runs 32-bit, yet badly (older AMD and Intel CPUs). Mountain Lion, by its turn, runs only on natively supported hardware until now, except for Atom CPUs (thanks to meklort expertise), which by their own turn were once supported by Apple. And it's a newer, better, way cooler OS than Lion is. So i think the benefits are bigger, the prize, better. Of course it's just my opinion here.
Legality of forking XNU: totally legal. That's why we have patched kernels; an example of an actual code repository would be the old Voodoo kernel, produced back when dinosaurs of OSx86 roamed the earth (10.5)
Good to know i was right.
Thank you for answering.