FreeBSD on Niagara UltraSPARC T1

>Опять же, прогнозы.. А где факты ? Я не имею ввиду именно этот пост, а то, что было выше.

>> Моё предубуждение, что OpenBSD жила, живёт, и жить будет.

>Пусть так. Дело не в этом, а в конкретных вещах. Для примера - смотри kevent и kqueue выше, кстати где ты умудрился нагрубить. Вот там конструктив был и читать было интересно. А большинство из того, что ниже обычный для данного ресурса треп из года в год особенно не меняющийся. В частности и мое сообщение, я уж извинюсь, просто скотились как обычно..

Да, забавно. Только что посмотрел по неткрафту и увидел, что
ftp.openbsd.org стоит на соляре :) А ftp.netbsd.org стоит, видать, на netbsd, но реально тормознут. Значит, либо канал либо система.

>>Из коробки винда стопудово лучше работает, так что ставь себе вантуз если коробка есть главное

>Из коробки винда просто стоит. Она не работает - там нечему работать.

Ну, скажем, здесь ты поторопился.
Если руки не кривые - работает.
Примеры:
www.lebedev.ru
www.na.infn.it
Если не ошибусь...
И ещё сервер РАНа на винде стоит. Ничего.

>Ткнуть тебя в новость об интервью, чего не хватает FreeBSD, чтобы догнать линукс или сам спустишься и почитаешь?

Идиот что ли? У FreeBSD свой путь. Она не догоняет линукс, не догоняла, и догонять не должна. И если будет пытаться - она в пролёте.
Разные системы. И линукс здесь не ориентир, чтоб все на него смотрели и мерялись с ним по фичности.

>KDE - нет. Того кошмара с переключением языка иксами под KDE во FreeBSD мне надолго хватило.

Ну ЧЁ ты гонишь???
Я сам кучу времени назад, ещё давно, ставил кде, под фрёй.
Всё работало и на ура, и проблем с русификацией не было.
Нормальные люди русифицируют ВСЁ ВСЕГДА и ПОД ЛЮБОЙ СИСТЕМОЙ через РУСИФИКАЦИЮ ИКСОВ!!! Вали в ФАК если ты этого ещё не знал, уважаемый!!! После ЧЕЛОВЕЧАЧЕЙ русификации у тебя работает кириллица, везде, как в кде, так и в любом приложении, где есть кириллические шрифты, а также в любом оконном менеджере. И кде здесь как было не при чём, так и осталось.

И конкретно FreeBSD здесь просто В ПРИНЦИПЕ не может быть "причём".
Потому что за русификацию графического режима отвечают ИКСЫ, которые, как тебе это ни странно покажется, во всех UNIX-like одни и те же.

>Кстати, а как ты сидишь сразу в трех менеджерах? И нафига сидеть в blackbox, когда fluxbox делает его по всем параметрам?

"Сразу", имеется в виду когда хочу какой - тот и запускаю.
Флакбокс поддерживает большую функциональность, но не стабилен как блэкбокс, и не поддерживает такие хоткейсы как новейший bbkeys. Либо поддерживает, но у меня ещё ни разу они не заработали. Поэтому у меня эти хоткейсы всё равно через bbkeys идут. Знаешь, люди вырезают из блэкбокса не нужно, делают реально минималистичный менеджер, и в то же время со всем необходимым. Я даже такое видел. А ты говоришь fluxbox.
Зачем мне слит нужен? Зачем мне иконки на столе? Зачем мне контекстное меню, мне что, горячих клавиш мало? смысл? Лично для себя я во флаке нашёл только 2 новых вещи, кот. для меня полезны - это прозрачность всяких штук, и табы. Всё остальное я видел в гробу.

>Во FreeBSD еще и конфиги придется откуда-то извне скачивать? Ужоснах.

Да, в линуксе скачивать и редактировать конфиги не надо. Там их за тебя уже продумали. А ты не знал, что у фрибсд все порты - свои, как и пакеты? Типа, они сами своё кде с нуля пишут, свои боксы и т.д.и т.п.? :)

>Кстати, таблицы роутинга настроить гораздо проще, чем KDE под фрей.

Да, я это уже понял. Сделать десктоп, заточенный под конкретного юзера, сложнее чем поднять сервер.

>Не понял - ты хочешь сказать, что у тебя mutt и др. того же класса (lynx, links, fetchmail) не работают?!

>Вообще лгать нехорошо.

работают.
Здесь как раз аргумент в том, что это всё одинаково хорошо работает под любой системой.

>Коробочный вариант какого дистрибутива и какой версии тебя не устраивает?

Единственный дистриб, который бы мен, возможно, устроил, был бы gentoo. Про доводку Free и gentoo сравнение писать, надеюсь, не надо?

>Не понял. Функциональность у линукса больше, поэтому он не нужен?

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

>Чуть иной порядок. Все базовые вещи лежат там же. Все конфиги подписаны. Нужные настроечные файлы будут при установки софта добавляться автоматом.

Во многих дистрибах линукса бардак в /etc.
Это мне сказали те, кто сами сидят под линуксом.

>Могу ошибаться, но все последние дыры в криптографии были одновременно на всех ОС.

Простейший пример: NetBSD при установке позволяет выбрать алгоритм для шифрования паролей. Фря - нет, только md5. Насчёт оупена - не знаю. Сомневаюсь, что многие дистрибы линукса это позволяют пользователю выбрать. Если md5 легче ломается, то, узнав твои пароли, если они совпадают с какими-то, можно попытаться подобрать пароли и ещё к чему-нибудь, куда ты коннектился. - Это аргуимент, зачем это может быть нужно.

>>>Я не слышал от серьёзных секъюрити организаций об их заинтересованности в Selinux вотличие от OpenBSD.

>Список секьюрити организаций. И прикрути себе уже спеллчекер. Две ошибки на предложение. И этот человек пишет статьи.

Опираясь на публикации в инете и интервью.

>Две ошибки на предложение.

Спасибо, уел. Набираю 2-мя пальцами, и тороплюсь. Потому и ошибки.

>И этот человек пишет статьи.

Да, пишу. Ссылки дать? Английский знаешь?

>IBM достаточно серьезная организация?

Возможно.

>И где слушаешь?

Что значит "слушаю"?

>Почему у тебя все время "слышал", "сказали", "где-то читал". Сам-то давно линукс видел?

Шелл к нему имею. Я себе на комп не ставил.

>>Понимаешь, в отличие от меня и тебя, эти люди разбираются в безопасности, и разбираются хорошо. У меня есть основания им доверять. И то, что защита OpenBSD - это фикция, я слышал только на лоре от местных "линуксопоцикленных".

>Ссылку на эту контору и ее проекты.

Лень гуглить. Это из стандартных новостей, в том числе и с лора ссылки.
Почти в любом обсуждении о безопасности или интервью вспоминают OpenBSD. И не видел ни разу, чтоб её полили грязью. Ни разу.

>>Понимаешь, в отличие от меня и тебя, эти люди разбираются в безопасности, и разбираются хорошо. У меня есть основания им доверять. И то, что защита OpenBSD - это фикция, я слышал только на лоре от местных "линуксопоцикленных".

>> цитаты других местных бандитос

:)

интересно зачем вам всем безопасность на десктопе? :) Зачем хитрые механизмы связанные с аутентификацией и всякими доступами к фс (и другим частям ос), шифрованием файликов и т.д. на борту рутера? Зачем терминальному серверу (и большей части других серваков :)) супермощный сетевой стек? и т.д.

Ведь защищать надо что-то, а не все подряд... Нет смысла в защите компонентов системы (в общем смысле) на которые атака производится не будет вовсе, либо вероятность такового события очень мала.

Защита стоит денег.

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

Безопасность - лавирование между бешенными суммами необходимыми на разные средства обеспечения этой безопасности и стоимостью информации (системы), которую надо защищать (смотрите на списки файерволлов и других средств защиты периметра и смотрите на их цены - от тысяч до десятков и сотен тысяч долларов. В других областях такая же картина.). И нет смысла говорить, что что-то безопасней другого. На десктопе - может быть разница и есть - оба сем-а ОС достались "бесплатно", запросы по безопасности принимают самые причудливые формы, и предпочтения каждого пользователя уникальны.

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

типок с pf vs iptables начинающий админ, но нехватка базовых знаний делает его обычным юзером.

sun-ich просто какой-то флеймер, сам себе противоречивый и совершенно не владеет предметными областями, в которые лезет против грамотных оппонентов

анонимы с руганью - обычные дятлы красноглазые.

собственно защитники bsd признали, что десктоп им не нужен. bsd это выбор серверов :) (тут я улыбаюсь) однако прежде чем аргументами с ссылкой на разговоры в курилках пытаться переубедить молодёжь, потрудитесь всё таки написать примеры приведённые про pf, и ответить наконец: о каком Роутере (именно с большой буквы) может идти речь, если MPD (multiplay routing tables)в bsd как небыло и так и нет?
(тупые обёртки в виде малопроизводительных патчей от японских девелоперов, портированные с irix идут в лес)

Поздравлям!

>MPD (multiplay routing tables)

Сами то вы кто, после ткой фразы?

> Для архитектур i386, arm (обе) и MIPS32 - соответственно 5%, 8%, 7% составляет платформно-зависимый код. Это _без_ учета подавляющего большинства драйверов.

$ pwd
/pub/ftp/pub/Linux/kernel/kernel/v2.4/linux-2.4.24
Press any key to continue...
$ grep -r PAGE_SIZE fs kernel net | wc -l
287

$ pwd
/pub/ftp/pub/Linux/kernel/kernel/v2.6/linux-2.6.16.1

$ grep -r PAGE_SIZE fs kernel net | wc -l
577

не знаю как вам, а мне это кажется весьма забавным и назвать это платформонезависимым кодом как-то язык не поворачивается :)
ps: drivers мы в расчет даже не берем..

// wbr

> да вы читали код-то? Качество кода linux во много раз лучше:
огромные функции, куча макросов и #ifdef все это превращает код NetBSD в какую-то малопонятную кучу малу.

ну конечно, кто бы спорил...

$ pwd
/pub/ftp/pub/Linux/kernel/kernel/v2.6/linux-2.6.16.1/include/linux
$ less fs.h

первое попавшееся под руку:

static inline loff_t i_size_read(struct inode *inode)
{
#if BITS_PER_LONG==32 && defined(CONFIG_SMP)
        loff_t i_size;
        unsigned int seq;

        do {
                seq = read_seqcount_begin(&inode->i_size_seqcount);
                i_size = inode->i_size;
        } while (read_seqcount_retry(&inode->i_size_seqcount, seq));
        return i_size;
#elif BITS_PER_LONG==32 && defined(CONFIG_PREEMPT)
        loff_t i_size;

        preempt_disable();
        i_size = inode->i_size;
        preempt_enable();
        return i_size;
#else
        return inode->i_size;
#endif
}

platform independent code просто прелесть..
тут же параграфом ниже:

#define file_list_lock() spin_lock(&files_lock);
#define file_list_unlock() spin_unlock(&files_lock);

#define get_file(x)     atomic_inc(&(x)->f_count)
#define file_count(x)   atomic_read(&(x)->f_count)

и сразу после:

static inline void lock_super(struct super_block * sb)
{
    get_fs_excl();
    mutex_lock(&sb->s_lock);
}

static inline void unlock_super(struct super_block * sb)
{
    put_fs_excl();
    mutex_unlock(&sb->s_lock);
}

..и так чередуясь друг с другом. давайте определимся: мы все-таки за inline или же за макросы?

// wbr

>$ grep -r PAGE_SIZE fs kernel net | wc -l

>287

>$ pwd

>/pub/ftp/pub/Linux/kernel/kernel/v2.6/linux-2.6.16.1

>$ grep -r PAGE_SIZE fs kernel net | wc -l

>577

>не знаю как вам, а мне это кажется весьма забавным и назвать это платформонезависимым кодом как-то язык не поворачивается :)

Почему?!!! Или использование PAGE_SIZE хуже, чем, например, INT_MAX или CHAR_BIT, PATH_MAX из limits.h? Или десятков других символических констант, определенных в POSIX? И, если моя память мне ни с кем не изменяет, PAGESIZE входит в POSIX. Или POSIX - платформно-зависимый интерфейс?

Вы не могли бы привести определение "платформозависимости", которым вы пользуетесь?

> ps: drivers мы в расчет даже не берем..

Я и не брал, хотя много Linux'овых драйверов работают на нескольких платформах.

> Почему?!!! Или использование PAGE_SIZE хуже, чем, например, INT_MAX или CHAR_BIT, PATH_MAX из limits.h? Или десятков других символических констант, определенных в POSIX? И, если моя память мне ни с кем не изменяет, PAGESIZE входит в POSIX. Или POSIX - платформно-зависимый интерфейс?

/*
* Flags is a 32-bit value that allows up to 31 non-fs dependent flags to
* be given to the mount() call (ie: read-only, no-dev, no-suid etc).
*
* data is a (void *) that can point to any structure up to
* PAGE_SIZE-1 bytes, which can contain arbitrary fs-dependent
* information (or be NULL).
*
* Pre-0.97 versions of mount() didn't have a flags word.
* When the flags word was introduced its top half was required
* to have the magic value 0xC0ED, and this remained so until 2.4.0-test9.
* Therefore, if this magic number is present, it carries no information
* and must be discarded.
*/
long do_mount(char * dev_name, char * dir_name, char *type_page,
unsigned long flags, void *data_page)
{

мне просто интересно, как это будет работать для систем с PAGE_SIZE в несколько мегабайт или вообще без страничной трансляции памяти? MMU-less systems.

причем что собственно к самому do_mount() никаких притензий не возникает и это чисто абстрактный независимый от железа интерфейс.

ну а INT_MAX != PAGE_SIZE. совсем. я соглашусь с их равенством лишь тогда, когда вы мне представите систему, в которой INT_MAX не имеет смысла aka отсутствует :)

> И, если моя память мне ни с кем не изменяет, PAGESIZE входит в POSIX. Или POSIX - платформно-зависимый интерфейс?

ну почему же, входит:

http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html#tag_13_24

--- cut ---
{PAGESIZE}
Size in bytes of a page.
Minimum Acceptable Value: 1
{PAGE_SIZE}
[XSI] [Option Start]
Equivalent to {PAGESIZE}. If either {PAGESIZE} or {PAGE_SIZE} is defined, the other is defined with the same value.
--- cut ---

забавно смотрится минимально допустимое значение.. ;) AFAIU в POSIX макро PAGE_SIZE несет скорее консультативную нагрузку и редко кто в трезвом уме и твердой памяти на нее ссылается. тем более с такой завидной регулярностью.

// wbr

>>> да вы читали код-то? Качество кода linux во много раз лучше:

>> огромные функции, куча макросов и #ifdef все это превращает код NetBSD в какую-то малопонятную кучу малу.

> ну конечно, кто бы спорил...

Там же русским языком сказано - _огромные_ функции, _куча_ макросов и #ifdef. Никто и не говорил, что в Linux совсем нет макросов и #ifdef. Ты указал, что они есть - и что? Ты _сравни_ их количество с NetBSD, об _этом_ речь.

> ..и так чередуясь друг с другом. давайте определимся: мы все-таки за inline или же за макросы?

За inline. Ты вообще читал Documentation/CodingStyle? "Generally, inline functions are preferable to macros resembling functions".

>long do_mount(char * dev_name, char * dir_name, char *type_page,

>unsigned long flags, void *data_page)

> мне просто интересно, как это будет работать для систем с PAGE_SIZE в несколько мегабайт

А вам не интересно, как будет работать TCP при межпланетных сообщениях?

> или вообще без страничной трансляции памяти? MMU-less systems.

do_mount РАБОТАЕТ на системах без MMU. Потому что ему без разницы. на какого размера блок указывает data_page. То, что он _называется_ data_page, не говорит ни о чем, кроме того. что когда-то очень давно под эту область памяти выделялась страница. Ну так когда-то Linux был только для i386.

Насчет MMU-less систем - это вообще отдельная песня. Unix (и Linux) изначально рассчитан на машины с защитой памяти, так что отсуствие константы PAGE_SIZE на MMU-less системах - наименьшая из проблем. Не подскажите, работает ли какой-нибудь другой современный свободный Unix на MMU-less системах?

> ну а INT_MAX != PAGE_SIZE. совсем

Там была еще MAX_PATH. У меня на столе лежат несколько систем, в которых ее нет. Означает ли это, что MAX_PATH == PAGE_SIZE? Или что "макро MAX_PATH несет скорее консультативную нагрузку и редко кто в трезвом уме и твердой памяти на нее ссылается" ?

Повторюсь - определение "платформнозависимости" в студию!

>> geom - требует (требовал ?) giant во всех мыслимых местах... С чего бы > еще его PHK начинал "переписывать".

>А что, переписывает-с? Ссылочку бы, а иначе добро пожаловать в лужу. Giant там отродясь был условным, в зависимости от требований нижних устройств.

http://people.freebsd.org/~phk/plan.html

Изменения в GEOM меньше, но включая удаления giant, vnodes - главное.

static inline loff_t i_size_read(struct inode *inode) { #if BITS_PER_LONG==32 && defined(CONFIG_SMP) loff_t i_size; unsigned int seq;

do { seq = read_seqcount_begin(&inode->i_size_seqcount); i_size = inode->i_size; } while (read_seqcount_retry(&inode->i_size_seqcount, seq)); return i_size; #elif BITS_PER_LONG==32 && defined(CONFIG_PREEMPT) loff_t i_size;

preempt_disable(); i_size = inode->i_size; preempt_enable(); return i_size; #else return inode->i_size; #endif }

> platform independent code просто прелесть..

А где здесь платформозависимость ?

"Разработчик фаловых систем" не осилил того факта что loff_t - 64-разрядное целое и потому на 32-разрядных системах при включенном SMP или preemption для доступа к нему нужен лок или временное запрещение этого самого preemption ?

> do_mount РАБОТАЕТ на системах без MMU.


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

> Потому что ему без разницы. на какого размера блок указывает data_page. То, что он _называется_ data_page, не говорит ни о чем, кроме того. что когда-то очень давно под эту область памяти выделялась страница. Ну так когда-то Linux был только для i386.

так и тащим за собой древние наследия от i386 в синтаксисе и семантике кода через всю широту поддерживаемых платформ? отличная идея! AFAIU L1_CACHE_BYTES из той-же оперы? или они то-же, допустим, на i386 означают одно, а на отличной системе - совершенно другое? дизайн проекта на 5 баллов, не спорю.

> Насчет MMU-less систем - это вообще отдельная песня. Unix (и Linux) изначально рассчитан на машины с защитой памяти, так что отсуствие константы PAGE_SIZE на MMU-less системах - наименьшая из проблем. Не подскажите, работает ли какой-нибудь другой современный свободный Unix на MMU-less системах?

сомневаюсь, что кому-то приходило в голову портировать UNIX like OS на систему без аппаратной защиты памяти. лично я знаю лишь ребят с фруктом в виде логотипа, которые рассматривали подобные варианты для своих железок с BSD (NetBSD конкретно). но в конце таки решили, что и половины её возможностей для их целей нафик не нужно и проще написать свое мелкое ядро + обвязку.

> Там была еще MAX_PATH. У меня на столе лежат несколько систем, в которых ее нет. Означает ли это, что MAX_PATH == PAGE_SIZE? Или что "макро MAX_PATH несет скорее консультативную нагрузку и редко кто в трезвом уме и твердой памяти на нее ссылается" ?

MAX_PATH означает лишь глубокую ущербность изначального дизайна системы. к аппаратной зависимости оно отношения не имеет и вы это, IMHO, отлично должны понимать :)

// wbr

> Отсутствие ядерного NAT'а и гребаный natd, работающий в user space, который способен удавить систему interrupt'ами даже на каких-то 200 юзерах, активно юзающих мул - это костыль. Такая конкретика подойдет?

Уважаемый, netgraph не зря придумали!

> "Разработчик фаловых систем" не осилил того факта что loff_t - 64-разрядное целое и потому на 32-разрядных системах при включенном SMP или preemption для доступа к нему нужен лок или временное запрещение этого самого preemption ?

мне показалось, или платформозависимый код как минимум должен находиться в arch/xyz? или это очередное грязное исключение из, в сущьности, изначально неплохих правил? почему в том же fs.h вообще фигурируют такие вещи, как зависимость от разрядности машинного слова, от SMP/non-SMP и иже с ними?

// wbr

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

grep -r CONFIG_MMU сделайте и увидите что никакого "полного перетряхивания всей системы" не было.

> Там же русским языком сказано - _огромные_ функции, _куча_ макросов и #ifdef. Никто и не говорил, что в Linux совсем нет макросов и #ifdef. Ты указал, что они есть - и что? Ты _сравни_ их количество с NetBSD, об _этом_ речь.

можно ссылочку на монстра в пределах /sys/sys? чисто для проформы, чтобы не выглядить голословным. искать можно тут:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/

> За inline. Ты вообще читал Documentation/CodingStyle? "Generally, inline functions are preferable to macros resembling functions".

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

ps: смешанный стиль макро+inline, к сожалению, наблюдается в обоих системах. может быть когда-нибудь inline победит, но пока что de facto это не так :-/

// wbr

> мне показалось, или платформозависимый код как минимум должен находиться в arch/xyz?

Во первых вы не еще не доказали что этот код - платформозависимый.
И какого рожна код vfs должен делать в arch ?

> почему в том же fs.h вообще фигурируют такие вещи, как зависимость от разрядности машинного слова, от SMP/non-SMP и иже с ними? 

А как иначе ? Вы предлагаете снабдить платформозависимый код знанием подробностей внутреннего устройства vfs ?

Кстати почему вы приводя текст функции i_size_read() не привели предшествующий ей комментарий ? Дешевенький приемчик-то. Там ведь прямо для вас написано:

/*
 * NOTE: in a 32bit arch with a preemptable kernel and
 * an UP compile the i_size_read/write must be atomic
 * with respect to the local cpu (unlike with preempt disabled),
 * but they don't need to be atomic with respect to other cpus like in
 * true SMP (so they need either to either locally disable irq around
 * the read or for example on x86 they can be still implemented as a
 * cmpxchg8b without the need of the lock prefix). For SMP compiles
 * and 64bit archs it makes no difference if preempt is enabled or not.
 */

Что из этого вам недоступно ?

> ps: смешанный стиль макро+inline, к сожалению, наблюдается в обоих системах. может быть когда-нибудь inline победит, но пока что de facto это не так :-/

Не победит, ибо некоторые вещи inline функцией не сделаешь. И кстати что вам так дались макросы. У вас макрософобия ?

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

"Итит твою мать, профессор..." (с) П.П. Шариков

Неужто специальное ядро используется? Чисто под диаграммы Феймана? Хакирами из CERN заточенное?

> Не победит, ибо некоторые вещи inline функцией не сделаешь.

например? не беря в расчет объявления DECLARE_FOO(a, b, c) и условную компиляцию.

> И кстати что вам так дались макросы. У вас макрософобия ?

да, что-то навроде того

#define __wait_event(wq, condition)                                     \
do {                                                                    \
        wait_queue_t __wait;                                            \
        init_waitqueue_entry(&__wait, current);                         \
                                                                        \
        add_wait_queue(&wq, &__wait);                                   \
        for (;;) {                                                      \
                set_current_state(TASK_UNINTERRUPTIBLE);                \
                if (condition)                                          \
                        break;                                          \
                schedule();                                             \
        }                                                               \
        current->state = TASK_RUNNING;                                  \
        remove_wait_queue(&wq, &__wait);                                \
} while (0)

#define wait_event(wq, condition)                                       \
do {                                                                    \
        if (condition)                                                  \
                break;                                                  \
        __wait_event(wq, condition);                                    \
} while (0)

#define __wait_event_interruptible(wq, condition, ret)                  \
do {                                                                    \
        wait_queue_t __wait;                                            \
        init_waitqueue_entry(&__wait, current);                         \
                                                                        \
        add_wait_queue(&wq, &__wait);                                   \
        for (;;) {                                                      \
                set_current_state(TASK_INTERRUPTIBLE);                  \
                if (condition)                                          \
                        break;                                          \
                if (!signal_pending(current)) {                         \
                        schedule();                                     \
                        continue;                                       \
                }                                                       \
                ret = -ERESTARTSYS;                                     \
                break;                                                  \
        }                                                               \
        current->state = TASK_RUNNING;                                  \
        remove_wait_queue(&wq, &__wait);                                \
} while (0)

(c) sched.h

// wbr

> Неужто специальное ядро используется? Неужто специальное ядро используется?

Вот невежества достойные плоды !

Числодробильные задачи (особенно использующие большие объемы памяти) вполне могут показывать разное быстродействие на разных ОС в зависимости от качества реализации системы виртуальной памяти.

> Числодробильные задачи (особенно использующие большие объемы памяти) вполне могут показывать разное быстродействие на разных ОС в зависимости от качества реализации системы виртуальной памяти.

...ну что с задачами, оную почти не использующие [в сравнении с доступным объемом RAM]?

// wbr

> Уважаемый, netgraph не зря придумали!

Во-во-во. Я про этот костыль и говорил. В стиле бздунов - сделать отвратительную реализацию ната и через 10 лет прихреначить сбоку нетграф...

>> Не победит, ибо некоторые вещи inline функцией не сделаешь.

> например? не беря в расчет объявления DECLARE_FOO(a, b, c) и условную компиляцию.

Например макросы с переменным числом аргументов, в виде inline функций будут более громоздкими, менее читаемыми и да еще и бог знает что компилятор в этом случае нагенерирует.

Или вот, по вашему что читабельнее:

#define invalid_vm86_irq(irq) ((irq) < 3 || (irq) > 15)

или

static inline int invalid_vm86_irq(int irq) { return irq < 3 || irq > 15; }

?

> да, что-то навроде того > (c) sched.h

1) Не вижу в приведенном примере ничего ужасного. Все вполне читаемо; 2) Не нравится ? Где ваши патчи ?

>> Числодробильные задачи (особенно использующие большие объемы памяти) вполне могут показывать разное быстродействие на разных ОС в зависимости от качества реализации системы виртуальной памяти. > ...ну что с задачами, оную почти не использующие [в сравнении с доступным объемом RAM]?

Это вопрос или попытка сарказма ? Если второе, то добро пожаловать в очередную лужу. Ключевые слова malloc(), anonymous memory, page fault.

> Например макросы с переменным числом аргументов, в виде inline функций будут более громоздкими, менее читаемыми и да еще и бог знает что компилятор в этом случае нагенерирует.

да, вне всяких сомнений, это стоящий случай. а главное, очень нужный в практике:

$ pwd
/pub/ftp/pub/Linux/kernel/kernel/v2.6/linux-2.6.16.1
$ grep -r VA_ARGS * | wc -l
      59

> Или вот, по вашему что читабельнее:
> #define invalid_vm86_irq(irq) ((irq) < 3 || (irq) > 15)
> или
> static inline int invalid_vm86_irq(int irq) { return irq < 3 || irq > 15; } 

оба читаемы весьма так себе :-/

/**
 * Description is here.
 *
 * @param in irq  IRQ number to check.
 * @return        true if IRQ is invalid or false otherwise.
 */
static inline int
invalid_vm86_irq(int irq)
{
    return irq < 3 || irq > 15;
} 

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

> 1) Не вижу в приведенном примере ничего ужасного. Все вполне читаемо;

на вкус и цвет, несомненно, товарищей нет :)

> 2) Не нравится ? Где ваши патчи ?

патчи? на это? оцените вероятность успешного приема патчей в sched.h :)))

// wbr

> оба читаемы весьма так себе :-/

Это не я, это уродское "TeX paragraphs w/quoting" форматирование.

/** * Description is here. * * @param in irq IRQ number to check. * @return true if IRQ is invalid or false otherwise. */ static inline int invalid_vm86_irq(int irq) { return irq < 3 || irq > 15; }

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

> патчи? на это? оцените вероятность успешного приема патчей в sched.h :)))

Зависит от содержимого патчей. There is no cabal, really.

> Отсутствие ядерного NAT'а и гребаный natd, работающий в user space, который способен удавить систему interrupt'ами даже на каких-то 200 юзерах, активно юзающих мул - это костыль. Такая конкретика подойдет?

Вроде в новой версии FreeBSD был анонс ядерного nat

200*4kb/sec == 6400 mbit/sec ( пусть минимально каждый по 4 kb/sec )
У тебя есть канал такой ширины в Internet ?
И ты его отдаешь под eMule ?
Наверное очень богатый ?

Пусть костыль - но скорость CPU сейчас такова, у меня например тянет 350-400 хостов и ничего

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

> так и тащим за собой древние наследия от i386 в синтаксисе и семантике кода через всю широту поддерживаемых платформ?

Так и тащим старые названия параметров кое-где.

> дизайн проекта на 5 баллов, не спорю.

Все большие и долгоживущие кодовые базы несут в себе некоторое количество анахронизмов. do_mount, который вы приводите в пример, появился в Linux лет 15 назад.

>> Насчет MMU-less систем - это вообще отдельная песня. Unix (и Linux) изначально рассчитан на машины с защитой памяти, так что отсуствие константы PAGE_SIZE на MMU-less системах - наименьшая из проблем. Не подскажите, работает ли какой-нибудь другой современный свободный Unix на MMU-less системах?

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

Не понял. "Сомневаюсь"? Вы не знаете о ucLinux, порте Linux на MMU-less процессоры? Есть такая штука, и работает. Так что на _практике_, Linux очень даже переносим, хотя у него в драйверах и используется PAGE_SIZE. Преносим в том числе туда, куда не ступала нога никакого другого Unix :)

> MAX_PATH означает лишь глубокую ущербность изначального дизайна системы. к аппаратной зависимости оно отношения не имеет и вы это, IMHO, отлично должны понимать :)

Я это отлично понимаю. Так вот, MAX_PATH - это всего лишь размер буфера. Точно такое значение имеет и PAGE_SIZE в драйверах - размер буфера, с которым работают процедуры управления VM. И, верите или нет, это тоже к аппаратной зависимости отношения не имеет. Аппаратно-зависимый код - это код, который в принципе не может исполняться на аппаратной платформе, отличной от той, на которой написан. Драйверы Linux опровергают это на практике. Считайте PAGE_SIZE такой же частью API Linux, как MAX_PATH - часть API POSIX.

[насчет "глубокой ущербности дизайна системы", проявляющегося в MAX_PATH - вы это серьезно?]

>http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/



/*
 * Determine the root device and, if instructed to, the root file system.
 */

#include "md.h"
#if NMD == 0
#undef MEMORY_DISK_HOOKS
#endif

#ifdef MEMORY_DISK_HOOKS
static struct device fakemdrootdev[NMD];
extern struct cfdriver md_cd;
#endif

#ifdef MEMORY_DISK_IS_ROOT
#define BOOT_FROM_MEMORY_HOOKS 1
#endif

#include "raid.h"
#if NRAID == 1
#define BOOT_FROM_RAID_HOOKS 1
#endif

#ifdef BOOT_FROM_RAID_HOOKS
extern int numraid;
extern struct device *raidrootdev;
#endif

/*
 * The device and wedge that we booted from.  If booted_wedge is NULL,
 * the we might consult booted_partition.
 */
struct device *booted_device;
struct device *booted_wedge;
int booted_partition;

/*
 * Use partition letters if it's a disk class but not a wedge.
 * XXX Check for wedge is kinda gross.
 */
#defineDEV_USES_PARTITIONS(dv)\
(device_class((dv)) == DV_DISK &&\
 !device_is_a((dv), "dk"))

void
setroot(struct device *bootdv, int bootpartition)
{
struct device *dv;
int len;
#ifdef MEMORY_DISK_HOOKS
int i;
#endif
dev_t nrootdev;
dev_t ndumpdev = NODEV;
char buf[128];
const char *rootdevname;
const char *dumpdevname;
struct device *rootdv = NULL;/* XXX gcc -Wuninitialized */
struct device *dumpdv = NULL;
struct ifnet *ifp;
const char *deffsname;
struct vfsops *vops;

#ifdef MEMORY_DISK_HOOKS
for (i = 0; i < NMD; i++) {
fakemdrootdev[i].dv_class  = DV_DISK;
fakemdrootdev[i].dv_cfdata = NULL;
fakemdrootdev[i].dv_cfdriver = &md_cd;
fakemdrootdev[i].dv_unit   = i;
fakemdrootdev[i].dv_parent = NULL;
snprintf(fakemdrootdev[i].dv_xname,
    sizeof(fakemdrootdev[i].dv_xname), "md%d", i);
}
#endif /* MEMORY_DISK_HOOKS */

#ifdef MEMORY_DISK_IS_ROOT
bootdv = &fakemdrootdev[0];
bootpartition = 0;
#endif

/*
 * If NFS is specified as the file system, and we found
 * a DV_DISK boot device (or no boot device at all), then
 * find a reasonable network interface for "rootspec".
 */
vops = vfs_getopsbyname("nfs");
if (vops != NULL && vops->vfs_mountroot == mountroot &&
    rootspec == NULL &&
    (bootdv == NULL || device_class(bootdv) != DV_IFNET)) {
IFNET_FOREACH(ifp) {
if ((ifp->if_flags &
     (IFF_LOOPBACK|IFF_POINTOPOINT)) == 0)
break;
}
if (ifp == NULL) {
/*
 * Can't find a suitable interface; ask the
 * user.
 */
boothowto |= RB_ASKNAME;
} else {
/*
 * Have a suitable interface; behave as if
 * the user specified this interface.
 */
rootspec = (const char *)ifp->if_xname;
}


а функция еще продолжается и продолжается,
и нашел я эту функцию просто зайдя в каталог kern и ткнув в первый попавшийся файл

>патчи? на это? оцените вероятность успешного приема патчей в sched.h :)))

100% если вы аргументируете почему это нужно и что именно это упрощает:
http://groups.google.com/group/linux.kernel/browse_thread/thread/47ad273f1a4c...

> (c) sched.h

макросы группы wait_event - это как раз пример того, что с помощью inline-функции не сделаешь. Посмотри внимательно на аргумент condition.

> Уж извините, но это вообще ужоснах. У меня например монитор не резиновый.

вообще-то, самая длинная строка в приведенном коде - 60 символов. AFAIR с этим вполне справлялся даже CGA [ну уж EGA то точно] :)

> По моему (и не только:) скромному мнению подробно комментировать нужно вещи неочевидные с первого взгляда.

из одного названия функции invalid_vm86_irq() я могу лишь предположить, что она проверяет корректность номера IRQ для режима эмуляции vm86 на i386. это весьма грубое предположение. и вот так, с ходу, я, допустим, не могу с уверенностью сказать, чем именно руководствовался автор отбрасывая IRQ0..2 и почему в конкретно данном случае они невалидны. равно как и область применимости функции etc. даже возвражаемое зрачение не очевидно без непосредственной консультации с конкретным кодом.

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

// wbr

>>по причине уже существующего PRа + лицензия GPL?

>я думаю в те времена linux был не так известен,

Помню летом 2000 года с Эмпайр Стэйт Билдинг был очень хорошо выден гигантский пингвин на стене одного из зданий. Да и linuxjournal уже на половину был рекламой забит.

>можно ссылочку на монстра в пределах /sys/sys? чисто для проформы,
или например файловые системы, вы вроде в них специалист
две функции
msdosfs_mount
и
ffs_mountfs

огромные функции, которые очень сильно дублируют друг друга,
в Linux это сделано легко и элегантно с помощью
get_sb_bdev(fs_type, flags, dev_name, data, ...);



>ps: смешанный стиль макро+inline, к сожалению, наблюдается в обоих >системах. может быть когда-нибудь inline победит, но пока что de facto это не >так :-/

а мир не черно белый и inline никогда не победит, есть вещи которые не сделаешь без макросов в C.

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

я отнюдь не утверждаю, что *весь* код в ядре Linux - редкостный отстой.

> Не понял. "Сомневаюсь"? Вы не знаете о ucLinux, порте Linux на MMU-less процессоры? Есть такая штука, и работает. Так что на _практике_, Linux очень даже переносим, хотя у него в драйверах и используется PAGE_SIZE. Преносим в том числе туда, куда не ступала нога никакого другого Unix :)

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

> Я это отлично понимаю. Так вот, MAX_PATH - это всего лишь размер буфера. Точно такое значение имеет и PAGE_SIZE в драйверах - размер буфера, с которым работают процедуры управления VM.

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

> И, верите или нет, это тоже к аппаратной зависимости отношения не имеет. Аппаратно-зависимый код - это код, который в принципе не может исполняться на аппаратной платформе, отличной от той, на которой написан. Драйверы Linux опровергают это на практике. Считайте PAGE_SIZE такой же частью API Linux, как MAX_PATH - часть API POSIX.

тут мы явно не сходимся во мнениях.

> [насчет "глубокой ущербности дизайна системы", проявляющегося в MAX_PATH - вы это серьезно?]

совершенно серьезно. по крайней мере, лично я не вижу никакой действительно серьезной идеологической причины ограничивать название файла или полный путь к файлу каким-то лимитом свыше a'la NAME_MAX или PATH_MAX. естественно за исключением чисто технических трудностей, вызванных изначальной кривизной дизайна системы.

и то, что NAME_MAX/PATH_MAX присутствуют в POSIX, отнюдь не улучшает его. скорее, так уж исторически повелось.

ps: разве что вы меня аргументированно убедите, что путь, допустим, в 32k или любой другой действительно никогда-никогда-никогда и никому не понадобится и не имеет ни малейшего права на существование даже теоретически.

// wbr

> а функция еще продолжается и продолжается,
и нашел я эту функцию просто зайдя в каталог kern и ткнув в первый попавшийся файл

да, портянка что надо. правда, AFAIR мы про macro vs inline. или вы считаете, что товарищ Торвальдс забабахал бы ее как #define в mount.h? право, это уже несколько перебор!

// wbr

> нет, я к тому, что ATM я не могу назвать других UNIX like систем, которые бы были перенесены на аппаратные платформы без механизма защиты памяти. а тем более работали бы на них в полной мере как UNIX like система.

А Linux - перенесен и работает. По-моему, это весомый довод в пользу "достаточно высокого" качества его исходного кода.

> я отнюдь не утверждаю, что *весь* код в ядре Linux - редкостный отстой.

А вы не пробовали _сравнить_ код Linux с кодом, например, NetBSD?

>> И, верите или нет, это тоже к аппаратной зависимости отношения не имеет. Аппаратно-зависимый код - это код, который в принципе не может исполняться на аппаратной платформе, отличной от той, на которой написан. Драйверы Linux опровергают это на практике. Считайте PAGE_SIZE такой же частью API Linux, как MAX_PATH - часть API POSIX.

> тут мы явно не сходимся во мнениях.

По поводу чего? Определения "аппаратно-зависимого кода" ? Того, как драйверы используют PAGE_SIZE? Того, что PAGE_SIZE входит в API, но не делает автоматически этот API машинно-зависимым?

> ps: разве что вы меня аргументированно убедите, что путь, допустим, в 32k или любой другой действительно никогда-никогда-никогда и никому не понадобится и не имеет ни малейшего права на существование даже теоретически.

Класс! "Даже теоретически". Я в восхищении, серьезно. Надо же так поставить задачу, что любое решение можно было изящным движением руки отвергнуть,

Ну да ладно... Вот мой аргумент: виртуальная память существует уже 50 лет. И до сих пор размер страницы больше 8 (или 16) Кбайт ни в одной широко распространенной архитектуре не используется. Поддерживается - но не используется.

P.S. kalafuda, вы кто по профессии? Я - программист, rtc - тоже наврняка программист, мы вам объясняем программистским языком. А вы то ли не понимаете, то ли просто троллите. В последнем случае дискуссию пора сворачивать, в первом - скажите, может, мы сможем более понятно объяснить? А то ваше мнение о MAX_PATH так смахивает на рассуждения о сферическом коне в вакууме...

> огромные функции, которые очень сильно дублируют друг друга, в Linux это сделано легко и элегантно с помощью get_sb_bdev(fs_type, flags, dev_name, data, ...);

NetBSD/3.99.20 - ffs_mount - 279 строк кода.
Linux/2.4.21 ext2_read_super - 262 строки кода.
и еще не факт, что из них сложнее.

ну а что до дублирования, то foo_mount() в NetBSD делает примерно то-же, что и пачка super_operations в Linux. просто во втором случае код несколько более разнесен.

// wbr

Да в пизду этот BSD ... сделали порт на Niagara ... круто типа ... я же на своей машине не могу могу установить FreeBSD 6.1... линукс ставиться без проблем ...