Weniger Kexte durch DSDT !?

Wo ist denn dein Problem, die liegen doch alle in der EFI und damit ist dein System absolut vanilla, näher am echten Mac geht es doch gar nicht.
Clover injected die Kext beim Start ganz vereinfacht ausgedrückt in den Kernel und startet dein macOS und übergiebt die Kontrolle an das OS quasi zurück, nichts davon ist auf Dauer sondern nur temporär.

DSDT Patches sparen keine Extensions ein, das war nie so und wird nie so sein. Man kann zwar damit eventuell vielleicht den einen oder anderen macOS eigenen Treiber dazu bewegen zu laden (meist im Bereich LAN) oder eben eventuell auch einen PropertyInjector einsparen (AHCI) aber letztlich tun die Dinger nicht Weh und oftmals sind die angebotenen Lösungen den macOS eigenen überlegen (gerade im Bereich LAN). Es macht eben schon einen Unterschied ob man zum Beispiel den NIC mit einem Treiber ausstattet der zu ihm passt oder ob man über einen "Compatible" Eintrag in der DSDT einen Treiber erzwingt der nur theoretisch passt.

DSDT Patches wo sie sinnvoll sind gerne aber bitte nicht um Extensions zu sparen denn das ist nicht der Sinn davon besonders nicht bei moderner Hardware. Bei alten Lauben sieht das möglicherweise anders aus denn hier ist vieles seitens Apple final entwickelt und man ggf. mit gezielten Patches die eine oder andere fremde Extension vermeiden wobei sich auch hier immer die Frage stellt was besser ist...

Es gibt einige Dinge die sich nicht über Extensions regeln lassen und daher in die DSDT gehören ein gutes Beispiel dafür sind Device Namen hier hat Apple ein ziemlich eigenes Verständnis dafür wie die zu heißen haben. Ein gutes Beispiel ist USB Apple hätte hier gerne das die Devices im ACPI den Namen EH01, EH01 und XHC (eventuell noch XH01 und XH02 uzw. zu heißen haben) und auch beim Audio ist Apple eigen denn es hätte gerne das das Audio Gerät (onboard Audio) HDEF heißt und die HDMI Audio Geräte den Namen HDAU tragen. Dazu kommen einige Devices die es so in einer non Apple DSDT gar nicht gibt oder aber schon gibt aber eben nicht so wie Apple sich das vorstellt (LPC Device, MCHC Device, SMBUS Device) auch hier machen Patches Sinn denn damit ermöglicht man macOS die dazu gehörenden Treiber zu laden. Ein weiterer Punkt der sich nicht über einen Kext regeln lässt ist das Thema IMEI Device was wichtig für QuickSync werden kann denn auch dieses Device gibt es vermutlich es heißt dann aber gerne anders...

Du siehst das DSDT Gefummel hat seine Berechtigung aber nicht unbedingt dafür Extensions zu sparen sondern mehr dafür Funktionen zu ermöglichen die sonst nicht möglich wären.

Kurz und Knapp wenn Deine Möhre so läuft wie sie soll dann nicht sonst ggf. doch...

Jop, wenn deine Möhre läuft brauchst du keine

Ich habe hier noch eine nette Geschichte zum Thema Skylake DSDT.
Hier liegen drei Mainboard ...
1. ASRock B150M Pro4
2. ASRock Z170X Extreme 4
3. Gigabyte Z170X Gaming 7
und alle drei lassen sich mit einer gepatchten DSDT booten und haben unter PCI die entsprechenden Einträge.
Nicht mal bei den Kexten musste ich was ändern, es ist wie aus einem Guss als wenn alle Hersteller das gleiche machen.

Das heisst alle drei Boards arbeiten mit der ein und der selben DSDT?

Ganz genau so ist es.
Ich bin ja auch ein wenig bequem und habe nur die SSD umgesteckt, aber keine Veränderungen an Clover vorgenommen, weder in der config.plist noch an der bereits gepatchten DSDT.

Beim patchen gehe ich nach dem "Standard DSDT-Patch Verlauf für Desktops Skylake-Chipsätze" aus dem Wiki vor, darüber hole ich mir die Intel SATA 10, die Intel XHC 10, den Intel LAN mit dem GLAN.txt sowie die restlichen Fixe (RTC, QS, IRQ, etc.), HDMI Sound läuft über eine SSDT und der PropertyInjektor.kext übernimmt Audio (Layout ID, Builtin, etc.) und Intel Graphics HD 630 und WLAN Airport (Builtin, etc.), also eine Mischung die recht vielseitig einsetzbar ist.

Hätte ich noch ein weiteres Mainboard hier, ich könnte wetten dass auch das auf Anhieb damit starten würde und mir den Schreibtisch von macOS präsentiert.

Lass uns mal probieren ob dein Z270 Gaming 4 die DSDT vom Z170 Extreme4 auch nimmt, findest du im Skylake Sammelthread alls letzten Eintrag, zusätzlich kannst du noch mit F4 in Clover eine rohe DSDT erzeugen.

Edit: Im Grunde kannst du auch gleich die SSDT für HDMI Sound von der HD 630 und den PropertyInjektor.kext mit rüber ziehen, Versuch macht klug.

Im Skylake Sammelthread geht auch der Ordner von dem GA Z170X Gaming 7 oder dem ASRock B150M Pro4, jedes der drei Bretter lässt sich damit booten.
Denk bitte daran dass du nur testen sollst für die eigentliche DSDT solltest du trotzdem deine rohe DSDT mit F4 ziehen.

@rubenszy Danke für die wunderbaren Dumps, die sind sehr hilfreich!

Ich will jetzt hier nicht den Besserwisser oder sonstwas spielen, ich habe nur beim Thema ACPI ein etwas andere Meinung als die hier beschriebene und will nur diese Möglichkeit aufzeigen.

Ich finde das eine gute ACPI Struktur eindeutig sinnvoll und eine gute Alternative zu ein paar Kexts ist. Auch bei Intel Skylake Boards.

Zitat von griven

Es macht eben schon einen Unterschied ob man zum Beispiel den NIC mit einem Treiber ausstattet der zu ihm passt oder ob man über einen "Compatible" Eintrag in der DSDT einen Treiber erzwingt der nur theoretisch passt.

Kexts wie SATA-200-series-unsupported.kext oder XHCI-200-series-injector.kext machen ja auch nichts anderes als einen falschen Treiber zu laden (wie das bei NIC ist weiß ich jetzt nicht). Es ist ja nicht so, dass sich dahinter ein kompletter Treiber für die jeweilige Hardware verbirgt – das ist bei den wenigsten Kexts der Fall, die meisten bauen auf Apples Lösungen.
Im Vergleich finde ich einen "Compatible" Eintrag sinnvoller als eine SATA-200-series-unsupported.kext und solche Kexts lassen sich hier eindeutig komplett ersetzen.

Zitat von rubenszy

In Kurzfassung SirusX ab Intel-Skylake macht es keinen Sinn mehr DSDT anzufertigen und zu patchen, benutze die Clover DSDT Patche und die Fixes, das reicht locker aus.

Finde ich auch nicht zwingend, denn die Clover Patches mögen zwar flexibel sein, decken aber wirklich nicht alles ab. Es gibt immer wieder Konfigurationen und Systeme bei denen die Clover ACPI Optionen nicht anschlagen. Man denkt: Der Haken ist gesetzt, alles passt, aber es ist mir schon häufiger aufgefallen, dass letztendlich die aktivierten Änderungen garnicht in zB IOReg zu erkennen waren. Der Fix wurde dann nicht angewandt und hat dementsprechend auch keine Auswirkungen. Zudem lässt sich in der ACPI Sektion auch nicht alles finden und machen, bei manchem muss man einfach händisch vorgehen. Eine Kombination aus Clover Hotpatch und eigenen ACPI Tabellen finde ich hingegen sehr gut und sauber.

Zitat von griven

Ein gutes Beispiel ist USB Apple hätte hier gerne das die Devices im ACPI den Namen EH01, EH01 und XHC [...] tragen.

Ist wahrscheinlich nur ein kleiner Tippfehler, aber EH01, EH02 und XHC werden verwendet um das Eingreifen der Apple-eigenen Methoden gezielt zu verhindern. Apple hätte hier gerne EHC1/2 und XHC1/2