LINUX.ORG.RU

linux unified kernel

 , ,


0

0

18 февраля вышел Linux Unified Kernel 0.2.1. Это попытка перенести некоторые системные вызовы Windows NT из userspace (wine) в kernelspace. Вот что говорит Dan из команды wine по этому поводу:

"It looks like they added hooks to the linux kernel to accept windows nt syscalls. Maybe they even allow using the system's normal shared library loader instead of Wine's special one. This is something I've often wanted to do, but it was way lower priority than getting wine working. I haven't looked at their project at all, no idea if it was done well."
............

"We would, I think, like to move wineserver into the kernel sometime. It's been discussed before. Linus is not opposed to having native support for win32 system calls. A fellow at Redhat wrote a kernel module for wine a number of years ago, but it just wasn't time yet."

источник: winehq.org

В двух словах на русском: 1. Возможно, этот проект позволяет использовать стандартный загрузчик динамических библиотек вместо загрузчика wine. 2. Возможно, это будет добавлено в mainstream ядро.

>>> Подробности

★★☆☆☆

Проверено: JB ()
Ответ на: комментарий от geek

>причем тут линукс, когда этой херней занимаются девелоперы проекта ReactOS?

девелоперы ReactOS вплотную работают с девелоперами wine. И на winehq написано:

"We would, I think, like to move wineserver into the kernel sometime. It's been discussed before. Linus is not opposed to having native support for win32 system calls. A fellow at Redhat wrote a kernel module for wine a number of years ago, but it just wasn't time yet."

Это все, кончено, вилами по воде. Но так или иначе - просто информация к размышлению

dikiy ★★☆☆☆
() автор топика
Ответ на: комментарий от no-dashi

> Набор системных вызовов скотины и линукса семантически очень схож с
> точностью до параметров и их значений, с отличие от...

... чего собственно ? Вы в курсе что wineserver делает ? Если нет - почитайте доки: максимум десяток вызовов для всяких изврщенных мутексов и прочей подобной хрени.

Поддежки формата win32 сиколлов боитесь ? Так ibcs это не только SCo это дофига ныне мертвых юниксов. Это поддержка в ядре именно формата чужих сисколлов, в основе своей. Для реализации этих сисколов есть wine - запихать в ядро реализацию помимо разомно необходимого минимума никто не даст, да это и не нужно.

kernel ★★☆
()
Ответ на: комментарий от kernel

> Но сискол в ядре с 2.0.28

Ну его еще юзает и само ядро, и X-сервер в некоторых ситуациях, то есть говорить, что это "поддержка dosemu", на самом деле немного некорретно :-)

no-dashi ★★★★★
()
Ответ на: комментарий от kernel

> максимум десяток вызовов для всяких изврщенных мутексов и прочей подобной хрени.

Место подобной хрени в юзерспейсе.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

> "поддержка dosemu", на самом деле немного некорретно :-)

Чиста все вапросы к Линусу :) Он считает что это именно поддержка dosemu - сам сказал в процитированном на winehq емейле. :) Скажите ему что он неправ ;)

Да и Х с ядром .... а не для вызовали ли реалмоде bios они этот сисколл используют, так к слову ? :) :) :)

Ничего не мешает эти вызовы в будущем использовать в ядре или каком прикладном софте. Зачем ? Так и тут когда добавляли про это особо не думали. :) Однако понадобилось - использовали.

kernel ★★☆
()
Ответ на: комментарий от sneer

>вместо того что бы давить на писателей что бы нативное всё лабали.

Еще раз повторяю, в использовании МЕГАТОННЫ софта УЖЕ. Купленного, п^Wкраденого, любого. И точно так же как с х86, никто и не думает что-то менять в среднесрочной перспективе даже если рядом мегао^Wклассное нечто. Никому в конторах не нужна новая опупенная программа, нужно работать с учетным комплексом купленым в 95 году, нужно работать в "программе" на VBA в екселевском файле образца 97 года, нужно печатать чеки из программы под 98-ю винду на кассовый аппарат купленый в 2000-м. Здесь огромная инерция, инерция которая ДАЕТ ШАНС сегодня ударить по M$!!! Потому что новое сегодня не нужно и от M$! Сейчас золотой междутехнологичный период. Очень зря что сообщество этого не видит! А вообще новое под линукс массово будут писать только тогда, когда линукс массово будет использоватся, а этого можно реально добится поддержкой запуска уже существующего ПО. И только тогда, когда "сверху" УЖЕ существующее ПО в приличном объеме будет относительно одинаково работать "сегодня", в "середине" и "снизу" преимущества линукса как ОС станут конкурентными преимуществами "на завтра". И даже тогда интероперабельность и переносимоть будет далеко не лишней - это реально может разбить монополию M$ и не дать образоватся другой, тому же Google. Я за переносимость ПО, поэтому такие шаги приветствую.

girla
()
Ответ на: комментарий от gods-little-toy

>следующий шаг будет поддержка бинарных драйверов от винды

Оно уже есть - см. ndiswrapper

sS ★★★★★
()
Ответ на: комментарий от Virun

>С каких это пор можно отключить _системные вызовы_?

с тех пор как линус выложил самую первую версию ядра ;)

sS ★★★★★
()
Ответ на: комментарий от INFOMAN

Гента вообще показательный дистр, огромная свалка всего подряд, которую день и ночь компилят тысячи красноглазых задротов, бррр...

anonymous
()
Ответ на: комментарий от no-dashi

> Место подобной хрени в юзерспейсе.

Это всему остальному место в юзерспейсе. А вот именно этой хрени место в ядре, и пихать ее в юзерспейс уже извращение.

Даже не вдаваясь в детали - люди пишут wine уже десяток лет, результат очень даже ничего. После долгих лет стараний они нашли что некоторые примитивы для работы с данными принадлежащими нескольким процессам разумнее реализовать в ядре.
Ну и в чем вопрос ? Ядро они не сакральная корова - оно специально для этого. Для реализации тех вещей которые либо кроме ядра никак либо (типа тех же символических ссылок) гораздо удобнее в ядре.

kernel ★★☆
()

Коль включат в ядро - перейду на Nexenta GNU/OpenSolaris X_x

GFORGX ★★★
()
Ответ на: комментарий от kernel

> а не для вызовали ли реалмоде bios они этот сисколл используют, так к слову?

Ну типа realtime APM BIOS call, и вызов int10h из Xorg/XFree86, как минимум :-)

no-dashi ★★★★★
()
Ответ на: комментарий от kernel

> Ядро они не сакральная корова - оно специально для этого

Оно давно уже стало таким монстром, что "мам не горюй". Если есть реальная возможность его не утяжелять - то ее следует использовать, IMHO.

no-dashi ★★★★★
()
Ответ на: комментарий от girla

Самое время. По слухам, в следующей версии винды Win32 API будет не нативным (как в ХП и Виста), а эмулироваться. Как раз к этому времени в виндах не будет винды, а в линуксе она появится. "Так и до мышей дотрахаемся" (С). Уйду на bsd.

anonymous
()

Так и представляю себе будущее, когда Windows 95, Windows 98 и Windows XP будут лишь возможными параметрами запуска программ. И, конечно, работать лучше оригиналов :).

anonymous
()

Прочтя новость увидел лишь что есть возможность включения в маинстрим ядро ЗАГРУЗЧИКА, а не всех вызовов winapi.

Эти вызовы реализованы в китайском форке ядра (и то я думаю кое как, хотя хз) , и ваниле вряд ли вообще когда нибудь появятся

Но аналитикам лора лишь бы поднять панику.

Dudraug ★★★★★
()
Ответ на: комментарий от anonymous

>Cамое время. По слухам, в следующей версии винды Win32 API будет не >нативным (как в ХП и Виста), а эмулироваться. Как раз к этому >времени в виндах не будет винды, а в линуксе она появится. "Так и до >мышей дотрахаемся" (С). Уйду на bsd.

Win32 API и так работает поверх ntdll.dll - интерфейса уровня ядра. Так что оно уже "эмулируется".

halyavin
()

А может ли предъявить M$ патентные претензии вайну, если куски его будут в ядре? Почему они вайну не предъявляют? У вайновцев нет проблем с M$?

anonymous
()
Ответ на: комментарий от samy_volosaty

>ага. даёшь 100% совместимость со всеми вирусами!

Они и так работают - могут даже похерить все в каталоге юзера и не которые распознают ключи wine.

gaux ★★
()
Ответ на: комментарий от fdn

>В биореактор!!! Wine - это зло. Пусть пишут нативный софт.

Студентам и учиться надо, подожди.

anonymous
()
Ответ на: комментарий от gods-little-toy

>- Винда останется доминирующей платформой

Гы, так оно и так будет. Линуксу остался пяток жить от силы. Я бы уже начинал копить на нормальную ос на вашем месте.

anonymous
()
Ответ на: комментарий от anonymous

>Фильмы, музончик с торрентов? Что, глазки-то забегали, а?

Мы - линаксоиды, такими вещами не занимаемся! Мы качаем модули ядра!

anonymous
()

Академическая среда ??? Да она никогда ничего путного не делала. Это тот навоз на котором вырастают (точнее - могут вырасти) некие полезные злаки. Как навоз она нужна, но не стоит переоценивать ее гастрономических свойств 8)

V0ID ★★★
()
Ответ на: комментарий от V0ID

Мля, а то даже не костыль, а целая инвалидная коляска

anonymous
()

Да уж. Не в ту сторону развивают ядро.

alman ★★★
()
Ответ на: комментарий от sS

>с тех пор как линус выложил самую первую версию ядра ;)

Отключи любой вызов и наслаждайся жизнью.

anonymous
()
Ответ на: комментарий от girla

> И это не мелочь пузатая, а крупные компании покрывающие своим ПО значительное количество государственных и корпоративных клиентов. Купленное у них СЕГОДНЯ ПО, скрученное с технологий времен 98-2000 винды будет еще жить лет 15 как пить дать. А вы Java и .NET, ага.

Даже в РФ не все интеграторы такие, вменяемые давно на .NET/Java. А то что госконторы очень любят закупать - давно известно.

sv75 ★★★★★
()

1. Нужно писать нативный софт 2. В майнстрим-ядре этого никогда не будет.. Ибо это идиотизм

ceeqwer
()
Ответ на: комментарий от anonymous

>Отключи любой вызов и наслаждайся жизнью.

Тут некоторое время назад уже отключали vmsplice на лету на работающем ядре ;)

sS ★★★★★
()
Ответ на: комментарий от anonymous

>Мы - линаксоиды, такими вещами не занимаемся! Мы качаем модули ядра!

s/линаксоиды/унылые тролли/
s/ами не/ествами/

;)

sS ★★★★★
()
Ответ на: комментарий от ceeqwer

>1. Нужно писать нативный софт

Пиши, я тебе не запрещаю. И вайновцы тоже.

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от sS

> Тут некоторое время назад уже отключали vmsplice на лету на работающем ядре ;)

А ведь интересная идея - модуль в роли двоичного патча :)

tailgunner ★★★★★
()
Ответ на: комментарий от jackill

>Пусть сначала что-нибудь сопоставимое напишут.

Они пишут. Только оно быстро утекает в коммерцию и становится проприетарным ...

sS ★★★★★
()
Ответ на: комментарий от tailgunner

>А ведь интересная идея - модуль в роли двоичного патча :)

Мы так лет 7 назад ядро NT/2k патчили ;)

sS ★★★★★
()
Ответ на: комментарий от sS

>Тут некоторое время назад уже отключали vmsplice на лету на работающем ядре ;)

Интересно. Хочу ссылку.

Капча: raiting

anonymous
()
Ответ на: комментарий от tailgunner

>От чего? Как назывался вендовый vmsplice?

От всего подряд ;)

PS: виндовый vmsplice назывался debploit если мне склероз не изменяет ;)

sS ★★★★★
()
Ответ на: комментарий от halyavin

> Win32 API и так работает поверх ntdll.dll - интерфейса уровня ядра. Так что оно уже "эмулируется".

Вы меня неправильно поняли. Win32 API работает поверх ntdll.dll нативно. Как я понимаю, в следующей версии винды файлы формата PE, использующие вызовы Win32, будут исполняться с помощью бинарного транслятора типа valgrind. То есть вызов Win32 будет дергать код .NET, который, в свою очередь, будет исполняться виртуальной машиной, нативно работающей с новым ОС API.

Поэтому если уж делать в линуксе "поддержку винды", то лучше уж добавлять системные вызовы, облегчающие и ускоряющие работу .NET.

anonymous
()
Ответ на: комментарий от anonymous

>Поэтому если уж делать в линуксе "поддержку винды", то лучше уж добавлять системные вызовы, облегчающие и ускоряющие работу .NET.

Мда, сколько ни говори про важность поддержки уже существующего софта, одни двойки. Я с вами еще не одну спинку кресла разломаю от откидывания ближайшие десять лет...

girla
()
Ответ на: комментарий от INFOMAN

>Даёшь Gentoo OpenSolaris!!!

лучше Gentoo QNX! :)

anonymous
()
Ответ на: комментарий от anonymous

> Мы - линаксоиды, такими вещами не занимаемся! Мы качаем модули ядра!

по торренту, iso-шки с модулями ядра? O_o

anonymous
()
Ответ на: комментарий от girla

> Мда, сколько ни говори про важность поддержки уже существующего софта, одни двойки. Я с вами еще не одну спинку кресла разломаю от откидывания ближайшие десять лет...

Как вы думаете, сколько стоил бы плейер, который не только СD/DVD/HD-DVD/BluRay играет/пишет, но и виниловые пластинки, магнитофонные кассеты, а также цилиндры с первых эдисоновских фонографов ?

Обратная совместимость (в том числе совместимость бинарная) хороша в разумных пределах. На эту тему см. Documentation/stable_api_nonsense.txt самизнаетегде.

anonymous
()
Ответ на: комментарий от anonymous

>Как вы думаете, сколько стоил бы плейер, который не только СD/DVD/HD-DVD/BluRay играет/пишет, но и виниловые пластинки, магнитофонные кассеты, а также цилиндры с первых эдисоновских фонографов ?

>Обратная совместимость (в том числе совместимость бинарная) хороша в разумных пределах. На эту тему см. Documentation/stable_api_nonsense.txt самизнаетегде.

Мы говорим про разные вещи. Я о корпоративном и государственном секторах, крупнейших по использованию ПО и обладающих огромной инерцией, а не потребительском. То чего уже не застать на компьютере дома, используется сегодня и сейчас в полный рост в них, и будет еще висеть там значительное время, я думаю лет 10 точно. И висит оно в громадных объемах. Это просящаяся в руки возможность отвоевать плацдарм в использовании ОС и вспомагательного ПО, организации ИТ-инфраструктуры у Винды. А вы дейсвительно о уже не актуальных вещах. У большинства этих контор сейчас назревают проблемы с лицензированием. Это если не брать в расчет пузатую мелочь которой в сумме наберется итого больше, правда у последних не такая ацкая инерция. Я не призываю курочить ванильное ядро, но ИМХО, форк в этих целях имел бы успех и способствовал продвижению Линукса, так как создал бы для последнего хороший фундамент на будущее и репутацию в обозначеных мною средах. А от них и дальше. Я думаю тут проблема в другом - это рутинная работа, копание в устаревающих технологиях и запутанной дуратской реализации ака "инновациях" прошлых лет одной большой конторы, какой уж тут джастфофан. И, конечно, религиозная нетерпимость канонического православия.

girla
()

а давайте вообще всё пихнём в ядро - будет такой большой бинарник на ~1-4Гб и файловая система для юзерских данных

откровенно говоря в ядре и так слишком много чего сейчас находится и переносить тудыть ещё чего-то - идея безумная, бредовая; наоборот из ядра много всего надо выносить(в userspace), например, драйвера переферийных устройств, большинство неосновных файловых систем вот это хорошая идея - большое ядро- это плохо в плане безопасности(многие ошибки в ядре как правило являются по-совместительсву и критическими, а то и уязвимостями) и возможности развития самого ядра, развитие гигантского проекта как правило происходит медленно из-за медленного процесса синхронизации разработок разных групп разработчиков с мэйнлайн веткой кода и друг с другом

Eleksir
()
Ответ на: комментарий от girla

>А вообще новое под линукс массово будут писать только тогда, когда линукс массово будет использоватся, а этого можно реально добится поддержкой запуска уже существующего ПО.

Просто многие бояться что Linux опопосеет. Что придут тупые юзеры которые будут скажем пользоваться только KDE и KDE станет мейнстримом и все будет писаться только под KDE. Перекоса боятся.

xtron
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.