Линус Торвальдс обдумывает новую схему нумерации версий ядра Linux

>>Но для x86 имхо бесполезно.

>Аргументируй!

один из главных аргументов, то что управлять прерываиями на X86 можно только из ядра (возможно полноценный MSI это изменит), это означает, что драйвер любого устройства с прерываниями должен иметь часть в ядре и часть в юзерспейсе, что противоречит самой идее микроядра.

>Про hurd помню что проект вроде умер...

>>Не верно. Он просто медленно развивается.

Ленин тоже не умер, просто медленно руководит Партией...

Интересно, теперь при комплияции программ будет требование: поддерживаются версии 2008.4.5 или 2007.4.1 или 2006.1.2 но не новее 2009.0.2, но с версией 2009.1.4 проблем не обнаружено.

Кто тестировал программу с другой версией ядра, отпишитесь. И будет флейм. "У меня ядро 2000.3.4 У меня все Ок. Что я делаю не так?" И так далее, ему скажут, обновись, он скажет у друга на 2000.3.5 не работает и т.п. и т.д.

Да здравствуйте множество флеймов по совместимости с дядрами?

А будет написан спец. драйвер подбора хэша. Задача сводится к решению уравнения

предлагаю версию ядер оставить также ( для совместимости )

2.6.х - где х это будет название ( словами ) текущего ядра
ну как в убунту "жирный гусь"

И Линусу с 150 разработчиками будет чем заняться от выхода до выхода
ядра - будут в форумах с пеной у рта обсуждать новое название !

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

Проблема высосана из пальца (или из чего?). Поотрубай ненужное. Пересобери ядро. Лехко можно будет грузиться с дискетки.

>Между прочим, MS тоже меняло "нумерацию":
>1) windows 2.x
>потом здОрово поменялся код:
>2) windows 3.x
>потом решили "привязаться" к датам:
>3) windows 9.x
>Потом перешли на "именованые":
>4) windows millenium

Тут гомноветка умирает. И остается только:

1.0) OS/2
1.1) NT.xx
1.2) windows XP
1.3) windows vista
И снова "нумерация", причем, похоже, как "продолжение серии":
1.4) windows 7

> Хорошо. Покажи нам написанную тобой микроядерную ОС,занимающую более 1% рынка ОС общего назначения, в которой функционал ОС разнесен по нескольки серверам.

Чтобы понять, что молоко скисло, необязательно быть коровой

>Цифры 2.6 в версии ядра давно не несут никакой информации. И не надо тут вспоминать про 2.4, 2.2, 2.1, 1.0.

Вот только не надо! 2.2 еще используется где-то, 2.4 - используется на слабых компьютерах (старые или встроенные). А 2.6 - исторически сложившияся версия.

ps. Не понимаю, чего может быть не понятно в текущей нумерации версий ядра.))

> А причем сразу покажи? А что ты написал для монолита?

Ну писал драйверы для Win и для Linux. Так, совсем небольшие - но писал. И могу сказать, что "монолит" не так плох как его рисует ваше воображение - если, конечно, не допускать грубых ошибок реализации и не лазить грязными руками во все доступные структуры.

Есть например такое поделие, как CDFS для монтирования audio-cd. Представляет дорожки как wav файлы. Но при этом иногда благополучно глючит, и не завершает сис. вызов. И программа, обращающаяся к этой ФС, благополучно повисает и ни на что не реагирует, ибо ждет окончания вызова.

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

Linux 3 грядёт! Wheee!

>Устав от постоянных вопросов, касающихся выпуска нестабильной ветки 2.7, Линус Торвальдс планирует на ближайшем саммите разработчиков ядра Linux обсудить новую схему нумерации версий ядра.

Если он устал, то, может, лучше пусть обсудит свою пенсию на ближайшем саммите разработчиков ядра.

Эмм... поворачивание яиц в профиль?

>один из главных аргументов, то что управлять прерываиями на X86 можно только из ядра (возможно полноценный MSI это изменит), это означает, что драйвер любого устройства с прерываниями должен иметь часть в ядре и часть в юзерспейсе, что противоречит самой идее микроядра.

чем? прерываиями ? это что за зверь? а таки если вы про interrupt - а именно про хэндлинг IDT, то что тебе мешает захендлить нужную ф-цию, которая будет дергать нужный модуль, - самый простой принцип. То есть пишется просто DDI для всех модулей железяк и все. x86 не сахар конечно со своими PAE и прочими "прелестями", но тем не менее это не дает вам право свое скодоумие скидывать на архитектуру. Опереждающе про скорость - в новых cpu - в частности amd64 есть такая вещь как hyper transport - что позволит минимизировать потери на контекст свитчинге. Да и в вашем жирном и глючном монолите многое уже пошло в юспейс - тот же контекст свитчинг если что. Самое веселое будет когда разжиреете, хотя веселье есть уже и сейчас, в духе - такой то процесс сковырнул там то - ой а мы на этом cpu упали, часть процессов отвалилась, ой - а что такое - почему не засвитчится - ой kernel panic на втором cpu.

Если учесть человеческий фактор - а его надо учитывать, то чем жирнее тем глючнее будет линукс. Производительность микроядра давно уже не проблема (см L4), можно гонять все через регистры - будет достаточно быстро, плюс секурно. Не говоря уже о том что можно имплементить vm для scheme/haskell в микроядре - и уже на уровне языка все имплементить - и где надо там кидатся через регистры.

Но нет - жирный монолит это круто, сколько кода - это круто - каунтинг LOC офигительно, и опять же на x86 свет клином не сошелся, проблемы фитч архитектуры должны решатся на нижнем уровне.

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

Если интерестно то читаем тут - http://fare.tunes.org/tmp/emergent/secureos.htm

Сейчас как раз подобным занимается.

ах ну да - в ответ на идиотские замечания поповоду ошибок грамматических и тупой троллинг и тупинг - каждому персонально - "ты идиот".

это уже из серии кризис жанра, давно пора разкоцать линупс на либы и пускать все уже в микроядре.

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

Я ожидал что они таки с 2.5 начнут идти в сторону микроядерности, потом думал что может потом допрут - ан нет - упорно продолжают.

проблема в том, что "не допускать" себе не позволяют даже заведомо аГхиопытные дроваписатели. а зачем ? кто там что увидит в этом (одном толсто-большом) бревне-ядре ?

ктонибуть, запретите Линусу посещать эти странные Голландские бары...

>http://www.ethiopic.com/ethiopic/numerals.htm

Что-то третий фокс это не выдерживает и падает.

>Есть например такое поделие, как CDFS для монтирования audio-cd. Представляет дорожки как wav файлы. Но при этом иногда благополучно глючит, и не завершает сис. вызов. И программа, обращающаяся к этой ФС, благополучно повисает и ни на что не реагирует, ибо ждет окончания вызова.

Может, не использовать "поделия"?

Делаются альтернативные варианты - и хорошо. Окажется, что нужно-таки микроядро - будет куда переходить. Пока такой надобности нет. О чем флеймить - непонятно. Кто что считает правильным, тот то и делает. а кто не делает ничего - пусть помалкивает. Ни Линус, ни кто-либо другой из разработчиков опен-сорса не обязан делать так как кому-то нравится. Только об этом забывают регулярно.

Предлагаю петицию:

Дядя Линус, мы, вид юзерус латентус привыкли к существующей нумерации и просим Вас продлить обдумывание нововведений до 3000 года.

%) :-)

>чем? прерываиями ? это что за зверь? а таки если вы про interrupt - а именно про хэндлинг IDT, то что тебе мешает захендлить нужную ф-цию, которая будет дергать нужный модуль, - самый простой принцип. То есть пишется просто DDI для всех модулей железяк и все. x86 не сахар конечно со своими PAE и прочими "прелестями", но тем не менее это не дает вам право свое скодоумие скидывать на архитектуру. Опереждающе про скорость - в новых cpu - в частности amd64 есть такая вещь как hyper transport - что позволит минимизировать потери на контекст свитчинге. Да и в вашем жирном и глючном монолите многое уже пошло в юспейс - тот же контекст свитчинг если что. Самое веселое будет когда разжиреете, хотя веселье есть уже и сейчас, в духе - такой то процесс сковырнул там то - ой а мы на этом cpu упали, часть процессов отвалилась, ой - а что такое - почему не засвитчится - ой kernel panic на втором cpu.

Для начала, прочитайте Фроловых "Защищенный режим процессоров i80286/386/486", и Вы увидите, что не все так просто. На вскидку такая концепция сработает только для устройств с открытым интерфейсом обработки прерываний, что не всегда доступно.

А фраза "hyper transport - что позволит минимизировать потери на контекст свитчинге" вообще бред, ht не имеет отношение к контекст свитчингу

>Что-то третий фокс это не выдерживает и падает.

брехня Mozilla/5.0 (X11; U; Linux x86_64; ru; rv:1.9.0.1) Gecko/2008071717 Firefox/3.0.1

"На вскидку такая концепция сработает только для устройств с открытым интерфейсом обработки прерываний, что не всегда доступно." обьясните про открытость/закрытость интерфейсов обработки прерываний в 2х словах, если не трудно

>ht не имеет отношение к контекст свитчингу

зато имеет прямое отношение к сокращению времени доступа к памяти - дальше сами догадаетесь как это взаимосвязано ?

>Для начала, прочитайте Фроловых "Защищенный режим процессоров i80286/386/486", и Вы увидите, что не все так просто. На вскидку такая концепция сработает только для устройств с открытым интерфейсом обработки прерываний, что не всегда доступно.

для начала выкиньте ваших фроловых, и займитесь реализацией, и Вы увидите что все достаточно тривиально, но не всегда всем понятно. Или Вы отрицаете существование real-microkernel on x86 ? Так погуглите - полно прототипов и экспериментальных ядер - и все таки работает. Да - у 80286 не было защищенного режима ;)

ну и читайте оф доки от производителя - там много нового и интерестного прочтете. Мне тут особо нет времени распинатся.

>"На вскидку такая концепция сработает только для устройств с открытым интерфейсом обработки прерываний, что не всегда доступно." обьясните про открытость/закрытость интерфейсов обработки прерываний в 2х словах, если не трудно

Функция, которая вызывается через IDT должна знать хотя бы как проверить, что именно это устройство вызвало прерывание, а не другое, которое тоже шарит этот вектор.

>Да - у 80286 не было защищенного режима ;)

LOL, RTFM.

У него не было режима трансляции страничного адреса в физический. А все остальное было только с 16-бит.

>для начала выкиньте ваших фроловых, и займитесь реализацией, и Вы увидите что все достаточно тривиально, но не всегда всем понятно. Или Вы отрицаете существование real-microkernel on x86 ? Так погуглите - полно прототипов и экспериментальных ядер - и все таки работает.

Проблема, что в экспериментах и прототипах все есть, нет ничего рабочего.

>Функция, которая вызывается через IDT должна знать хотя бы как проверить, что именно это устройство вызвало прерывание, а не другое, которое тоже шарит этот вектор.

Вы идиот, включите мозк.

>У него не было режима трансляции страничного адреса в физический. А все остальное было только с 16-бит.

я там выше написал. и еще - страничный адрес - это так фроловы отжигают да ? )

>Проблема, что в экспериментах и прототипах все есть, нет ничего рабочего.

как раз работает, просто никто дальше не идет - но это уже другой вопрос.

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

нет я вижу это Вы жгете "не подеццки": "В процессорах i80286 не было защищенного режима", и не знаете систему трансляции сегмент смещение в физический адрес не только в 286, но и в 386 судя по вашему изумлению словосочетанием "страничный адрес"

>нет я вижу это Вы жгете "не подеццки": "В процессорах i80286 не было защищенного режима", и не знаете систему трансляции сегмент смещение в физический адрес не только в 286, но и в 386 судя по вашему изумлению словосочетанием "страничный адрес"

Вы идиот - впрочем это может быть изза того что Вы напросто выключили мозк - или его у Вас нет. Внимательно думаем - зачем нам такой защищенный режим где нет - пейджинга, виртуального адрессного пространства, остальное ладно опустим. то что он так назывался еще не значит что он идентичен принципиально тому что используется сейчас - именно поэтому я и написал что его не было в 286 - для просветления советую a) выкинуть фроловых b) почитать вот тут вот - http://en.wikipedia.org/wiki/Protected_Mode

Больше не несите ересь и включайте мозк.

>также можно в драйвере определить функцию определения "своего" прерывания и тогда всё будет обрабатываться своим драйвером а чужое пропускаться, что мешает?

надо контекст переключать на обработку для каждого драйвера по цепочке это долго.

Что я Вам все пишу, LKML почитайте там много аргументов почему это очень сложно, а, главное, перезагружаемые драйверы устройств - это миф на x86.

+-1

>Вы идиот - впрочем это может быть изза того что Вы напросто выключили мозк - или его у Вас нет. Внимательно думаем - зачем нам такой защищенный режим где нет - пейджинга, виртуального адрессного пространства, остальное ладно опустим. то что он так назывался еще не значит что он идентичен принципиально тому что используется сейчас - именно поэтому я и написал что его не было в 286 - для просветления советую a) выкинуть фроловых b) почитать вот тут вот - http://en.wikipedia.org/wiki/Protected_Mode

из вики:

The initial protected mode, released with the 286, was not widely used.

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

Вы идиот.

P.S. а схема эта не пошла, потому что нигде кроме x86 она не работает, и она оказалась не портабельной хотя одно из ее главных преимучеств - не возможность использования переполнения стека для подстановки своего кода в принципе.

>Вы идиот.

Таки я настоятельно советую Вам включить мозк.

не хочу больше с Вами дисктутировать - время жалко, да и Вы по ходу упираетесь и не гуглите в показанную Вам сторону для просветления. Есть принцип - все ошибаются, ваши кумиры с lklm тоже - если б все строили для себя кумиров и гуру и не искали подвохов - мы б жили в каменном веке до сих пор. Последний раз - и так - посмотрите в сторону functional languages для системной разработки и в сторону микроядер и перспективных разработок - ну и L4 гляньте как один из примеров (хотя оно тоже не сладкое, но тем не менее порушит Ваши представления о якобы тормознутости микроядер)

Удач.

> >Проблема, что в экспериментах и прототипах все есть, нет ничего рабочего.

> как раз работает, просто никто дальше не идет - но это уже другой вопрос.

думаю, что принципиальной разницы микроядро/монолит не существует. Что там что там можно нормально модульно структурировать код и т.п. От глюков в железе не спасет никакая микроядерность :-) какая разница, зависит все ядро, или модуль, микроядра без которого ничго работать не будет? :-)

/зависит/зависнет/

>думаю, что принципиальной разницы микроядро/монолит не существует. Что там что там можно нормально модульно структурировать код и т.п. От глюков в железе не спасет никакая микроядерность :-) какая разница, зависит все ядро, или модуль, микроядра без которого ничго работать не будет? :-)

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