История изменений

либы надо портировать, пистоны/руби/луы/кутэ/майпэйнты и пр. и пр...

Ты упоролся? Гораздо проще портануть свежее ядро, на котором взлетит весь свежий юзерспейс, чем разводить некрофилию и обеспечивать обратную поддержку для тонны юзерспейсовых апликух и мейнтейнить адову тонну патчей. А платформа на который не взлетает сразу хотя бы 90% имеющихся на рынке USB-затычек никому нахрен не вперлась. Это раз.
Два, с точки зрения девелопера, который поддерживает некоторую не-мейнлайн платформу в ядре, гораздо проще шагать в ногу с апстримом, делая ребейз каждую мажорную версию ядра, и допиливая небольшие изменения, чем через 3 года внезапно огрести геморроя на несколько месяцев работы, когда не собирается ничего.

SDM надо просить (как под их архитектуру писать/как поддержку всяческих «защищенных режимов» в ПО обеспечивать), а то как пить дать окажется, что они «не все» пока готовы/могут опубликовать - ну и выложат линуксовы ошметки, кому оно тогда надо? пусть лучше на доки сил побольше бросят

Эта часть в ядре не меняется каждую вторую версию, если меняется вообще. Потому архитектурно-специфичный код, если он написан, достаточно просто вмержить и использовать как есть. Точка. А не читать до полного просветления документацию на то, что давно уже реализовано и работает.

как под их архитектуру писать/как поддержку всяческих «защищенных режимов» в ПО обеспечивать

Об этом девелоперу _юзерспейсного_ приложения знать не надо. Исключения - код для DSP/ассемблерные вставки с матаном.

либы надо портировать, пистоны/руби/луы/кутэ/майпэйнты и пр. и пр...

Ты упоролся? Гораздо проще портануть свежее ядро, на котором взлетит весь свежий юзерспейс, чем разводить некрофилию и обеспечивать обратную поддержку для тонны юзерспейсовых апликух и мейнтейнить адову тонну патчей. Это раз.
Два, с точки зрения девелопера, который поддерживает некоторую не-мейнлайн платформу в ядре, гораздо проще шагать в ногу с апстримом, делая ребейз каждую мажорную версию ядра, и допиливая небольшие изменения, чем через 3 года внезапно огрести геморроя на несколько месяцев работы, когда не собирается ничего.

SDM надо просить (как под их архитектуру писать/как поддержку всяческих «защищенных режимов» в ПО обеспечивать), а то как пить дать окажется, что они «не все» пока готовы/могут опубликовать - ну и выложат линуксовы ошметки, кому оно тогда надо? пусть лучше на доки сил побольше бросят

Эта часть в ядре не меняется каждую вторую версию, если меняется вообще. Потому архитектурно-специфичный код, если он написан, достаточно просто вмержить и использовать как есть. Точка. А не читать до полного просветления документацию на то, что давно уже реализовано и работает.

как под их архитектуру писать/как поддержку всяческих «защищенных режимов» в ПО обеспечивать

Об этом девелоперу _юзерспейсного_ приложения знать не надо. Исключения - код для DSP/ассемблерные вставки с матаном.

либы надо портировать, пистоны/руби/луы/кутэ/майпэйнты и пр. и пр...

Ты упоролся? Гораздо проще портануть свежее ядро, на котором взлетит весь свежий юзерспейс, чем разводить некрофилию и обеспечивать обратную поддержку для тонны юзерспейсовых апликух. Это раз.
Два, с точки зрения девелопера, который поддерживает некоторую не-мейнлайн платформу в ядре, гораздо проще шагать в ногу с апстримом, делая ребейз каждую мажорную версию ядра, и допиливая небольшие изменения, чем через 3 года внезапно огрести геморроя на несколько месяцев работы, когда не собирается ничего.

SDM надо просить (как под их архитектуру писать/как поддержку всяческих «защищенных режимов» в ПО обеспечивать), а то как пить дать окажется, что они «не все» пока готовы/могут опубликовать - ну и выложат линуксовы ошметки, кому оно тогда надо? пусть лучше на доки сил побольше бросят

Эта часть в ядре не меняется каждую вторую версию, если меняется вообще. Потому архитектурно-специфичный код, если он написан, достаточно просто вмержить и использовать как есть. Точка. А не читать до полного просветления документацию на то, что давно уже реализовано и работает.

как под их архитектуру писать/как поддержку всяческих «защищенных режимов» в ПО обеспечивать

Об этом девелоперу _юзерспейсного_ приложения знать не надо. Исключения - код для DSP/ассемблерные вставки с матаном.

либы надо портировать, пистоны/руби/луы/кутэ/майпэйнты и пр. и пр...

Ты упоролся? Гораздо проще портануть свежее ядро, на котором взлетит весь свежий юзерспейс, чем разводить некрофилию и обеспечивать обратную поддержку для тонны юзерспейсовых апликух. Это раз.
Два, с точки зрения девелопера, который поддерживает некоторую не-мейнлайн платформу в ядре, гораздо проще шагать в ногу с апстримом, делая ребейз каждую мажорную версию ядра, и допиливая небольшие изменения, чем через 3 года внезапно огрести геморроя на несколько месяцев работы, когда не собирается ничего.

SDM надо просить (как под их архитектуру писать/как поддержку всяческих «защищенных режимов» в ПО обеспечивать), а то как пить дать окажется, что они «не все» пока готовы/могут опубликовать - ну и выложат линуксовы ошметки, кому оно тогда надо? пусть лучше на доки сил побольше бросят

Эта часть в ядре не меняется каждую вторую версию, если меняется вообще. Потому архитектурно-специфичный код, если он написан, достаточно просто вмержить и использовать как есть. А не читать до полного просветления документацию на то, что давно уже реализовано и работает.