Linux 2.6.14.1

Официально:

http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.14.1
http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.14.1.bz2

Линус, бросай своего монолитного монстра, мирись с Танненбаумом и пишите вместе микроядро! ;) Не стоит бороться за крохи производительности на современных процах! Гибкость и надежность микроядра важнее!

Ура. Наконец то новое ядро. :) А то как то непривычно-за неделю ни одного не было. Обновляемся!!!

Опять кто то в ядреной рассылке завел разговор о стабильности ядерного апи (http://marc.theaimsgroup.com/?t=113118393000002&r=2&w=2). Ответы как всегда в стиле - "а оно нам нах ненадо!". Позабавила фраза одного из отвечающих:

The 2.6 is a stable kernel series in the sense that it doesn't crash very often. 2.6.14 is not API-compatible with 2.6.15.

Такое вот определение стабильности...

>You could open the /proc/sys/net/ipv4/conf/<if>/<whatever> file, then wait for interface to go away, try to grab as much memory as possible in hope to hit the (kfreed) ctl_table. Then fill it with pointers to your function. Then do read from file you've opened and if you are lucky, you'll get it called as ->proc_handler() in kernel mode.

Ну прям очень просто это сделать :).

Офигеть! Новое ядро! Обновляемся!!!

Ждём, блин, -archck

> Опять кто то в ядреной рассылке завел разговор о стабильности ядерного апи

На самом деле - народ забывает главный принцип делания чего либо. Не получается сразу - делай по частям. Я в том смысле, что народ распинается про необходимость переделывать usb и т.д. Но ведь есть уже отлаженные и неизменные вещи, типа всяких ide/scsi, сетевые карты там... Вполне могли бы стабилизировать хотя бы их. Ну, не навсегда, а на вторую цифрку...

"Несмотря на то, что интерфейсы ядра изменяются чуть ли не ежеминутно, тем не менее когда вопрос касается пространства пользователя, Linux превращается в очень консервативную операционную систему, которая позволяет использование программ в течение длительного времени без необходимости их перекомпиляции." (C) Tigran Aivazian ("Внутреннее устройство Ядра Linux 2.4", Перевод: Андрей Киселев)

>Линус, бросай своего монолитного монстра, мирись с Танненбаумом и пишите вместе микроядро! ;) Не стоит бороться за крохи производительности на современных процах! Гибкость и надежность микроядра важнее!

Это типа Windows XP(и NT вообще), что ли? Насколько я знаю, уже мало кто спорит с тем, что ядро Linux надежнее виндового. Кто-то может спорить о вопросах практичности и удобства(хотя это снобизм со стороны виндузятников, так как то, что Linux - технология для только для профи - это миф), но преимущество Linux в надежности даже Microsoft оспаривает очень вяло. ЗЫ: Что в вашем понимании есть гибкость?

>Линус, бросай своего монолитного монстра, мирись с Танненбаумом и пишите вместе микроядро! ;) Не стоит бороться за крохи производительности на современных процах! Гибкость и надежность микроядра важнее!

И кстати говоря, когда какое-то скандально известное агенство вякнуло, что Линус не написал ядро сам, а стырил его у Танненбаума и прочих *nix, то именно Танненбаум полез защищать Торвальдса. А так ничего.

>Офигеть! Новое ядро! Обновляемся!!!

Это скорее не ядро, а патч!

2.6.14.1 это патч? :))) Помоему это ядро. ;)

В целом это ядро, но в данном случае -- патч. Патч к ядру вышел, а не ядро %)

Гибкость - это unix-way. То есть когда каждая программа делает только что-то одно, но делает это отлично. ЧТо касается ядра linux, то там юниксвеем и не пахнет! Типичный "шампунь и кондиционер в одном флаконе". Линукс предоставляет отличное пользовательское api на основе POSIX, но отвратительные интерфейсы ядра... ни с чем не совместимые, даже между соседними подверсиями. Микроядро не имеет этого недостатка по определению - оно всего лишь следит за памятью и процессами.. Тем более, что в i386 архитектуре есть возможность 4 колец защиты - логично было бы разделить. Само микроядро на 0, драйвера системы на 1, драйвера пользовательских устройств(usb, принтеры, сканеры) на 2, а пользовательские программы на 3. Стабильность была бы супер, с сохранением гибкости. А выгадывать 4% производительности за счет монолитного ядра - а это надо на современных процах?

То Annymous (*) (10.11.2005 8:33:15)
Думаю ты не первый так думаешь, почитай в интернете, такая система слишком много(подробностей уже не помню, но точно не 4% ) ресурсов займет, за счет переходов между уровнями. И к тому же это приведет к глобальной переработке непосредственно ядра (слишком много взаимосвязей сейчас упрощено, поскольку все на 1 уровне(не считая UserSpace)).
Вы лично поддержите? Сможете чтото из вами описаного соорудить, ведь исходники то есть?
P.S. Если создадите, то многие придут посмотреть, особенно LOR :)

>Линукс предоставляет отличное пользовательское api на основе POSIX, но отвратительные интерфейсы ядра... ни с чем не совместимые, даже между соседними подверсиями. Микроядро не имеет этого недостатка по определению - оно всего лишь следит за памятью и процессами..

Ну хорошо, микроядро не будет иметь этого недостатка. Но почему этого недостатка _по_ _определению_ не будет в драйверах? Теже яйца только с боку.

При этом дико возрастает сложность коммуникаций между драйверами.
Хотя впрочем это прописные истины :)

по ссылке:

The message you requested cannot be found.

The message you requested cannot be found. The message with the url http://lkml.org/lkml/2005/11/8/360 does not exist in the database. 

>При этом дико возрастает сложность коммуникаций между драйверами. Хотя впрочем это прописные истины :)

Собственно именно так аргументировал Торвальдс свой выбор монолита. Мол, микроядро предполоагает деление на почти элементарные функциональные части, но не стоит забывать, что при этом взаимодействие между этими подчастями очень сложно.

> выгадывать 4% производительности
если бы не несколько ошибок в архитектуре x86 то так и было-бы.

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

1) i386 - не единственная архитектура, так что далеко не везде "4 кольца". 2) AMD64 в 64-битном режиме - только 0 и 3 кольца, 1 и 2 нет.

У них мускуль отвалился:

Warning: mysql_pconnect(): Too many connections in /home/sites/lkml.org/scripts/getmail.php on line 55

Warning: mysql_select_db(): Access denied for user: 'www-data@localhost' (Using password: NO) in /home/sites/lkml.org/scripts/getmail.php on line 56

Warning: mysql_select_db(): A link to the server could not be established in /home/sites/lkml.org/scripts/getmail.php on line 56

Warning: mysql_query(): Access denied for user: 'www-data@localhost' (Using password: NO) in /home/sites/lkml.org/scripts/maillib.php on line 182

Warning: mysql_query(): A link to the server could not be established in /home/sites/lkml.org/scripts/maillib.php on line 182

"AMD64 в 64-битном режиме - только 0 и 3 кольца, 1 и 2 нет" - Офигеть.. зачем они так сделали?

а кто использует 1 и 2?:) Имеетсу в виду: какая из 64-битных ОС на IA испльзует 1 и 2? В 32-битном режиме у AMD64 AFAIK все 4 кольца присутствуют.

Вот так вот упростили:)

>Офигеть.. зачем они так сделали?

кто amd?

Мда..тенденция.. с такими упрощениями скоро вообще от поддержки защиты памяти откажутся. Будет flat с 64-битными указателями )) А потом лет через 5 опять введут кольца привилегий как совершенно новую фичу нового поколения процессоров. По кругу ходим, ИМХО! :-)

>Мда..тенденция..

причем здесь тендеция, просто ни одна популярная ОС (linux, *bsd, windows) и т.д.,
не использовали кольца защиты 1,2, зачем же их поддерживать?

>просто ни одна популярная ОС (linux, *bsd, windows) и т.д., не использовали кольца защиты 1,2

Заметьте: не поддерживается только в 64-битном режиме, в 32-битном - поддерживается!

А какие ещё есть ОС (хотя бы непопулярные) для 64-битного режима AMD64?

>Заметьте: не поддерживается только в 64-битном режиме, в 32-битном - >поддерживается!

и что? очевидно что это сделанно для совместимости.

>А какие ещё есть ОС (хотя бы непопулярные) для 64-битного режима AMD64?

ИМХО вообще-то и в 32 битные ОС тоже не используют 1 и 2 кольца защиты.

>ИМХО вообще-то и в 32 битные ОС тоже не используют 1 и 2 кольца защиты.

Вроде что-то такое про BeOS говорили...

>и что? очевидно что это сделанно для совместимости.

Это я к тому, что архитектура AMD64 изначально только с 0 и 3 кольцами, так что никакой несовместимости в 64-битном режиме быть не может:) По большому счёту, ИМХО AMD64 - это ia32 + ещё один дополнительный режим (64-битный, с двумя "кольцами")

больше двух колец защиты может понадобиться для микроядерных ОС,
ядро в 0, процессы по рабоате с памятью, диском и т.д. на 1 остальное на 2 или 3,
но это в теории.

Это понятно... Потому и говорю, что вроде что такое про BeOS говорили - я точно не знаю. Может и Minix использует 1 и 2?

Я понял! AMD64 это продукт тайного заговора монолитчиков против микроядерщиков! :))

>Я понял! AMD64 это продукт тайного заговора монолитчиков против микроядерщиков! :))

Для микроядерщиков 32-битный режим в нём оставили, им больше и не нужно:)

Хотелось бы верить, что это шаг к выбрасыванию старого ненужного "хвоста" ia8/ia16/ia32: как только большая часть ОС/софта станет нативно 64-битной, из процессора выбросят всё, кроме 64-битного режима:)

>И кстати говоря, когда какое-то скандально известное агенство вякнуло, что Линус не написал ядро сам, а стырил его у Танненбаума и прочих *nix, то именно Танненбаум полез защищать Торвальдса. А так ничего.

Между прочем, сам Танненбаум открыто называет Линух клоном minix'а ;)

>Хотелось бы верить, что это шаг к выбрасыванию старого ненужного "хвоста" ia8/ia16/ia32: как только большая часть ОС/софта станет нативно 64-битной, из процессора выбросят всё, кроме 64-битного режима:)

Фик! До сих пор 16-битный не выкинули...

test for my only

Патч к ядру вышел под номером 2.6.14.1?

Кстати, народ, а у кого еще есть 386 ор 286? Хочу в Ф19 погеймить или крусайдера....

>Кстати, народ, а у кого еще есть 386 ор 286? Хочу в Ф19 погеймить или крусайдера.... DosBox спасёт отца русской демократии. Крусадера обе части не так давно ходил...