LINUX.ORG.RU

Обзор ядер UNIX вообще и HP-UX в частности


0

0

Неплохая статья, рассказывающая о внутреннем устройстве ядер UNIX вообще, об основных концепциях построения и приводящая ядро HP-UX как пример. Весьма полезно для расширения кругозора. Статья на английском.

>>> Статья, одной страницей

★★★★★

Проверено: Demetrio ()

Линус Торвальдс ещё не дал ни одного разъяснения по поводу строения и особенностей ядра Linux. И не кивайте на исходники - без понимания абстрактных идей, заложенных в исходный код, открытые исходники равнозначны закрытию ПО.

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

Почему бред - вполне здравая мысль. Давно пора потребовать от Тервальдса объяснительную записку (в трех экземплярах). И справку из ЖЭКа.

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

Читай книжку RObert Love, "Linux kernel development - design and implementation of linux kernel"

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

просто Линус сейчас занят - портирует записку в зюмель!

o1o
()

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

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

А почитать статьи Инго Молнара не судьба там описывается как ядро работает и nptl в частности.

anonymous
()

Да блин! Почему к ядру до сих пор нет красивых доков в .чм формате с красивой диаграммкой про то что же хотел выразить Торвальдс написанием ядра? И рассмотрение исходников в свете влияний позднего Тургенева, Пушкина и трудного детства в котором ему ни одна девка во дворе так и не дала.

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

>>Статья, безусловно, хорошая. надеюсь ты её прочитал?

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

В этой заметке рассматриваются общие принципы организации UNIX ядра и схемка нарисована как в любом классическом учебнике,так что неудивительно,что для линукса оно то же самое.Конкретно про HP-UX я там что-то не сильно много нашёл...

>>но вот качество кода ядра оставляет желать лучшего. По сравнению с чем? Если бы кто-нибудь видел исходники того же HP-UX`а то можно было бы говорить о чём-то,а так...Напомню было давно какое-то исследование,где измеряли количество ошибок на число строк кода - так там помнится линукс показал неплохие результаты.

и по поводу качества HP-UX: работал я с этой тварью - патчей к ней выходит просто немеряно - и на ядро в том числе; Почитаешь описания - страшно становится - везде segfault`ы,зависания...ошибки кстати пишут в описаниях те же: не проверили входные значения,неверные указатели...

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

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

> и по поводу качества HP-UX: работал я с этой тварью - патчей к ней
> выходит просто немеряно - и на ядро в том числе; Почитаешь описания -
> страшно становится - везде segfault`ы,зависания...ошибки кстати пишут
> в описаниях те же: не проверили входные значения,неверные указатели...

совсем йобнулись пингвиноводы - на чпупикс наезжать! :E
да, сложная система
да, не собирается на ней фришный софт без напильника
но про сегфолты чистый гон - аптайм билинговой системы в одной крупной московской телекоммуникационной компании на hp-ux - 8 лет без перегрузов, нарушили только когда ethernet 10 на 10/100 поменять понадобилось
да и жаба на ней бегает шустрей чем на солярке, ко всеобщему удивлению сановцев ;)

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

> Линус Торвальдс ещё не дал ни одного разъяснения по поводу строения и особенностей ядра Linux

а откуда ему нахрен знать, что ему там коммитеры напатчили?

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

>> Линус Торвальдс ещё не дал ни одного разъяснения по поводу строения и особенностей ядра Linux

>а откуда ему нахрен знать, что ему там коммитеры напатчили? А он типа уже не координирует нифига в создании? Ему походу все из каких-то странных побуждений все патчи шлют... :S

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

2anonymous (*) (10.07.2004 11:50:51)

Гы-Гы, там поди Ultrix на Alpha стоит :))

Ну Sun-ch, ну ты то хоть как старый мазохист от юникса че-нть пёрнул бы ...

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

2ananymous (*) (10.07.2004 14:03:59)
>давайте все соберемся и напишем крутое ЯДРО!!!!!!!!
От имени всех анонимусов пишу: "КРУТОЕ ЯДРО" :-)
А ты, ananymous (*) (10.07.2004 14:03:59) к нам не примазывайся :-)

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

alman:
> но вот качество кода ядра оставляет желать лучшего.

Торвальдс и компания очень охотно принимают патчи.
если не знаете куда посылать, то я напомню:
linux-kernel@vger.kernel.org.

а вообще, было бы очень интересно, если бы лично вы
привели пример плохого кода, и обьяснили, в чем он
плох. только не из драйвера какого-нибудь, и не из
reiserfs, а поближе к kernel/, или mm/.

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

на стабильность наезжать не буду, оракл на пашет хорошо, но HPUX самый сраный юникс из всех (aix,solaris,linux).

1. В нем куча дырок, нет не так ОГРОМНАЯ КУЧА ДЫРОК ОЧЕНЬ ОГРОМНАЯ. и их не фиксят со времен десятой версии.
2. Убогий lvm (своим миррором), FS и все что с этим связано. Без vxfs hpux использовать низя.
3. sam ничего, но со smit'ом не сравнится.
4. для гнутого софта нужен ОТ ТАКОЙ напильник, при этом современные версии софта обычно не собираются ваще, лучше брать 2-х летней давности.
5. На сайтах подобных этому одно старье http://hpux.cs.utah.edu.
6. Инсталяция пакетов полная срань, должно быть как в linux'е aix'е.
7. Кучи ошибок в инклудах.
8. Нету очень многих ф-ций (сишный), которые стандарт де-факто.
9. Даже shadow нет!!
10. aCC это просто пиздец в отношении C++.


Мне жаль всех (и себя тоже), кто програмит\админит эту срань, когда это говно сдохнет наш мир станет лучше. Молюсь на то, чтобы еще и Sun поскорее двинул кони виесте со своими тормозными гробами и солярой.

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

>Линус Торвальдс ещё не дал ни одного разъяснения по поводу строения и особенностей ядра Linux. И не кивайте на исходники - без понимания абстрактных идей, заложенных в исходный код, открытые исходники равнозначны закрытию ПО.

перестань дышать через анус - кислород до мозга не доходит

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

Ламеров всетаки сюда не надо пускать если человек не знает С не знает как работает компьютер и вообще тормозит и говорит а скажите что хотем сделать Торвальдс то этому человеку срочно надо выхвать медиком обязательно оставь адрес на ранних стадиях это еще лечится позже начнеш писать в штаны ;-)

hanprog
()

Даже смешно, как вы друг перед другом умничая раздуваетесь, как жабы.

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

Да тут вообще сложно найти людей, которые читали/пытались_читать эту статью, максимум 3-4.

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

>аптайм билинговой системы в одной крупной московской телекоммуникационной компании на hp-ux - 8 лет без перегрузов

Скоко-скоко? :-))))) Т.е. дыры в ядре принципиально открытыми держуть? :-)

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

>2. Убогий lvm

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

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

> Т.е. дыры в ядре принципиально открытыми держуть?

да, заодно honeypot сделали на той же машине

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

> а вообще, было бы очень интересно, если бы лично вы
> привели пример плохого кода, и обьяснили, в чем он
> плох. только не из драйвера какого-нибудь, и не из
> reiserfs, а поближе к kernel/, или mm/.

Ну хоть я не alman, но вот пример: lseek. Черт ногу сломит. А если
мне надо быстренько проконсультироваться на предмет его работы? Там
разбора часа на два/три/четыре... в завис. от квалификации.

А вот сдесь нужно в три/четыре раза меньше времени:
http://www.openbsd.org/cgi-bin/cvsweb.cgi/sys/kern/vfs_syscalls.c?rev=1.113

Linux kernel плюс glibc это пример code bloat'а. К сожалению.

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

> Linux kernel плюс glibc это пример code bloat'а. К сожалению.

Бля, как же я забыл про Bourne Again Shell. Еще один GPL'ный монстр.

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

> Ну хоть я не alman, но вот пример: lseek. Черт ногу сломит.

это в функции, длина которой 22 строки? какие-то уж очень
изнеженные черти у вас.

> А вот сдесь нужно в три/четыре раза меньше времени:

чтобы убедиться, что написано хуже. достаточно посмотреть
на сравнения v_type с VFIFO, VCHR. или вы полагаете, что
постоянные проверки !special делают код более читабельным?
а что делать драйверу, если он хочет перехватить lseek() ?

все таки, хотелось бы услышать более конструктивную критику,
чем: "мне это не нравится, с трудом понимаю".

я не утверждаю, что в linux kernel идеальный код. но я ни
разу не смог добиться предметного разговора от людей, кричащих
sucks! плохо! bsd/windows rulez!

кстати, глядя на этот lseek() от OpenBSD сразу видно, что
SMP не поддерживается. я думал, они уже сделали?

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

> HPUX самый сраный юникс из всех (aix,solaris,linux).

ты не видел OpenServer? ;) счастливый человек. ;)

> 1. В нем куча дырок, нет не так ОГРОМНАЯ КУЧА ДЫРОК ОЧЕНЬ ОГРОМНАЯ. и их не фиксят со времен десятой версии.

десятка уже неподдерживаема сто лет в обед. но вообще барахла там и впрямь немало. но они иногда патчат. медленнее соляриса но быстрее sgi. впрочем, hp-ux никто в здравом уме в инетку не выставит.

> 2. Убогий lvm (своим миррором), FS и все что с этим связано. Без vxfs hpux использовать низя.

так без vxfs или без vxvm? vxfs таки hp лицензировала и оно там внутри теперь

> 3. sam ничего, но со smit'ом не сравнится.

необходимость smit - только от того, что в AIX все через одно место сделано. вон в солярке отлично все без SunMC админится

> 9. Даже shadow нет!!

есть специальный security pack - там оно есть

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

и на чем жить? на linux все крутить? ;)

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

> Ну хоть я не alman, но вот пример: lseek. Черт ногу сломит.

это в функции, длина которой 22 строки? какие-то уж очень
изнеженные черти у вас.

Нет к разнообразию:

generic_file_llseek
no_llseek
dcache_dir_lseek
default_llseek
seq_lseek

и файлу fs/read_write.c.

> чтобы убедиться, что написано хуже...

Чтобы убедиться, что написано хуже достаточно разобраться кто кого
из [l]lseek вызывает ;)

> кстати, глядя на этот lseek() от OpenBSD сразу видно, что
> SMP не поддерживается. я думал, они уже сделали?

Сделали. А что Вы такое нашли, противоречащее этому?

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

> а вообще, было бы очень интересно, если бы лично вы привели пример плохого кода, и обьяснили, в чем он плох. только не из драйвера какого-нибудь, и не из reiserfs, а поближе к kernel/, или mm/.

В какой версии ядра искать пример? А пока поищете в дереве исходников директиву goto. Или использование goto уже не считается плохим стилем программирования?

Кроме того расскажите, имел ли место первоначальный дизайн ядра?

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

> Ну хоть я не alman, но вот пример: lseek. Черт ногу сломит.

lseek? Это тот который умеет устанавливать поинтер далеко за концом файла, а при первой записи забивать пустоту нулями? Полезная функция, представляю что там наворочали с учётом VFS.

Кстати, в реализации Линукса lseek за конец файла действительно предотвращает дефрагментацию? Для примера: я знаю что будет записан файл 600Мб. Создаю файл файл с аттрибутом write, затем lseek на 600Мб от начала. Пишу ноль байт, а потом целый день вписываю туда помаленьку (E-mule). Так вот, будут ли иноды этого файла фрагментированы или нет? То есть будут ли блоки этого файла перемеживаться с другими файлами, которые были открыты/дописаны/удалены во время операций с большим файлом?

Применительно к Ext2? Применительно к FAT?

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

> В какой версии ядра искать пример? 2.6.x

> А пока поищете в дереве исходников директиву goto. goto - оператор.

> Или использование goto уже не считается плохим стилем программирования? Теоретиками-экстремистами считается плохим стилем. Но на практике это не обязательно так.

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

>ты не видел OpenServer? ;) счастливый человек. ;)
Слава богу не видел :), и имею большие шансы уже не увидеть.

>десятка уже неподдерживаема сто лет в обед. но вообще барахла там и впрямь >немало. но они иногда патчат. медленнее соляриса но быстрее sgi. впрочем, hp-ux >никто в здравом уме в инетку не выставит.
это точно

>так без vxfs или без vxvm? vxfs таки hp лицензировала и оно там внутри теперь
Без vxfs. Про vxvm я не помню юзаем мы его или нет. Все-таки переставлять чпукс редко приходится :), жаль что приходиться поддерживать

>необходимость smit - только от того, что в AIX все через одно место сделано. вон в >солярке отлично все без SunMC админится
В том, что aix не админится правкой конфигов есть много плюсов и я думаю что все к этому придут.

>есть специальный security pack - там оно есть
Не знал, но вообще hpux'у secutiry pack'и не помогут :)

>и на чем жить? на linux все крутить? ;)
Мне последнее время все больше больше aix нравится. Из комерческих юниксов он однозначно The Best, да и pSeries ну очень удачные машинки. А если надо попой в инет, но однозначно линукс, комерческие юниксы по любому страшно выставлять.

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

>Гы-Гы, там поди Ultrix на Alpha стоит :))

Слышь, не гони про Ultrix на Alpha. Там Ultrix на VAX стоит. А может и на PDP-11.

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

Ну, bbb немного переборщил, но в целом примерно так...

По человечески жалко Tru64 - ось на порядок лучше, да HP ее загнет...

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

> Кстати, в реализации Линукса lseek за конец файла действительно предотвращает дефрагментацию? Для примера: я знаю что будет записан файл 600Мб. Создаю файл файл с аттрибутом write, затем lseek на 600Мб от начала. Пишу ноль байт, а потом целый день вписываю туда помаленьку (E-mule).

Это не совсем так. Вы спутали фрагментацию со sparse файлами. В Вашем случае, если файловая система поддерживает sparse файлы (ext2 например), будет записан ф-л логическим размером 600 MB, и физическим (реально на диске) 1 байт. Если же нет -- то за один заход пропишуться все 600 MB, но будет ли он фрагментирован -- опять-таки зависит от "подлежащей" файловай системы.

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

>> и на чем жить? на linux все крутить? ;)

> Мне последнее время все больше больше aix нравится.

Мазохист, батенька? Один только grep с ограничением на длинну строки 32kB чего стоит. И head, который может вернуть "успех" ($? == 0) не дописав заказанное количество строк.

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

А c Альфой не все так просто. Можно надеяться. Во всяком случае она продается лучше, чем итаниум. Пока. Вспомним историю - PDP DEС хоронило примерно с середины 80-х. Однако он до сих пор жив и не собирается помирать - платы до сих пор выпускаются. И покупаются :-). Недавно 30-ти летие отмечали - ух и пьянка была :-). Последняя версия RT-11 и RSX-11 относятся к 2000 году.... VAX хоронят уже примерно 5 лет и что? Сначала Compaq, потом HP по прежнему продолжают предлагать решения на VAX. А куда деваться? Заказчиков много лояльных. Гораздо больше, чем кажется на первый взгляд. См. хотя бы тот же интел. Ну не хочет он доверять управление конвейерами своему глюкалу.

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

Во всех комерческих юниксах приходится менять стандартные утилиты на гнутые, тут уж ничего ты попишешь. И ограничение кстати 2К :). AIX мне нравиться совсем за другое.

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

А ты книги почитай - там про goto подробно рассказано. Есть места, где без goto слишком сложно/тормознуто получится.

P.S. А джампы в ассемблере - разве не goto?

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

>А ты книги почитай - там про goto подробно рассказано. Есть места, где без goto слишком сложно/тормознуто получится.

Вот только инсинуаций, пожалуйста, не надо. Какие книги? URL или ISDN этих книг. Если без goto получается слишком сложно - это прежде всего проблема программиста. Если тормознуто - проблема компилятора.

>P.S. А джампы в ассемблере - разве не goto?

Да, goto реализуется путём джампов. Ну и что это доказывает?

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

> Нет к разнообразию: > > generic_file_llseek > no_llseek > dcache_dir_lseek > default_llseek > seq_lseek

Все эти функции --- реализации метода ->lseek() для конкретных файловах систем, которые вызываются из generic кода. То же самое, что и VOP_SEEK() во FreeBSD. То, что в OpenBSD такого метода нет --- недостаток так как файловая система не получает уведомления о вызове seek(2).

> > и файлу fs/read_write.c. > > > чтобы убедиться, что написано хуже... > > Чтобы убедиться, что написано хуже достаточно разобраться кто кого > из [l]lseek вызывает ;) > > > кстати, глядя на этот lseek() от OpenBSD сразу видно, что > > SMP не поддерживается. я думал, они уже сделали? > > Сделали. А что Вы такое нашли, противоречащее этому? >

Я, к примеру, после поверхностного осмотра этого кода вижу в нём самый обыкновенный БАГ --- VOP_GETATTR() вызывается без лока на vnode.

>

Никита.

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