Система разработки ядра Линукса даёт сбои

> Не согласен. Узкое место - межпроцессная синхронизация посоредством именнованых семафоров. В Линухе в именнованой шаред мемори нельзя создать неименованный POSIX семафор.

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

// wbr

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

> Только так можно синхронизировать процессы в qnx4 и так можно в qnx6. Это к вопросу о том, что весь код почти без переделки легко перекомпилируется под Линуксом. Я к тому, что не легко.

если говорить о QNX6 vs Linux, то в обеих системах pthreads реализован вполне приемлемо в соответствии со стандартом POSIX -> если это основной механизм распараллеливания исполнения кода, то проблем в принципе далеко не так много. разделяемая же память, семафоры etc - да, тут как правило есть нестыковки. точнее, кто-то что-то не реализует и опа, уже проблема.

// wbr

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

pthreads по ряду технических причин не пользовал вообще. Кроме того qnx4 pthreads можно считать не поддерживает... хотя говорят, что поддерживает, но не в этом дело...

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

Микроядру сообщения не посылаются. Но процессам-сервисам ядра посылаются. Я в данном случае под ядром имел в виду не само микроядро а микроядро+сервисы. Давайте определимся как эти процессы тогда называть. Есть пользовательские процессы, есть "сервисы ядра" (некий специфический случай процессов как то процессы драйверов, файловых сис тем) и микроядро.

>распределение тех или иных подсистем между независимыми процессами и >передача управляющих запросов посредством сообщений в первую очередь >диктует требование чётко прописывать протокол обмена сообщениями между >этими процессами. разбиение же системы на независимые модули с чётко >заданными интерфейсами взаимодействия и стандартизация API/ABI в свою >очередь действительно заметно упрощает разработку, отладку и в >особенности сопровождение ПО.

Ага. Все хорошо сформулировали. Я упростил для краткости.

>ждем'c. попытки опровержения объективной реальности - это всегда
>захватывающее зрелище.

Я пытаюсь опровергнуть не обьективную реальность а ваше о ней представление :) т.е субьективнуюю реальность :p

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

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

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

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

>десктопный вариант? был всю жизнь от самого рождения. вообще-то, это
>одна из отличительных черт QNX. включая полнофункциональную среду
>разработки ПО на базе Eclipse для 6ки.

Ну и кто его использовал кроме разработчиков решений под ваши специализированные заморочки ? Вы же собственно "применимость QNX к десктопу" меряли по критерию "удобство разработки и тестирования специализированных решений под QNX". Это не реальность, это ваша версия реалности - и в этом подходе нет ничего нового.

>не понял. приведённое выше - это ваши аргументы в пользу >невозможности создания GPOS на основе микроядра? это что - все :-?

Вы не поняли или не захотели понять эти аргументы. Проверить у вас в QNX нихрена нельзя эту применимость в общем случае ! То что "у меня работатет" это не серьезный аргумент на самом деле. Так как у вас есть конкретные условия и конкретные задачи. И вам совершенно плевать как оно будет у других людей, как и разработчикаv QNX на проблемы НЕ КАСТОМЕРОВ.

А всплывающие проблемы вам уже называли более компетентные чем я в QNX товарищи - про сетевой стек и графическую подсистему тут флейм был уже. Стороны остались при своем.

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

И оптимизация затрудняется тем что для ее нужно оптимизировать _протоколы_ которые нужно заново перепроектировать и переувязывать.
Просто какие то хаки в коде использовать не получится. А все современные GPOS это многочисленные хаки для оптимизации всего и все
и для обхода кривого железа. Кривое железо в QNX в принципе никакое обходить не нужно - не будем включать в список совместимости и все ! Или напишем "железо кривое - для решения ваших зачач купите другую железку".

Вот вам написали про эту же проблему другими словами :

>И то, что без надобностей сискалы рекомендуют не дёргать. Потоков там
>сотню на процесс создать и хватит, в то время, как чисто userspace
>радотают десятки тысяч. С сокетами там, не select/poll дёргать, а
>поинтереснее способами пользоваться. Особенно, в серверах с кучей
>клиентов. Для pppoe придумали модуль ядра, т.к. гонять гонять пакеты
>kernelspace - userspace - kernelspace несколько накладно и уже 20-30
>пользователей, качающих файло через 600Mz шлюз загружают его до
>просадки скорости сети. А с модулем - загрузка по нулям... Можно ещё
>много примеров привести. Например, напомнить недавнюю дисскуссию с >участием Торвальдса, на тему "а давайте вынесем драйвера в
>userspace". И чем это всё кончилось. Здесь же, фактически, то же >предлагается..

>Многопоточные/многозадачные системы просто отлаживать? Дебаггера то под них нету...

Кончайте пукать в лужу.

Про TVD никогда не слышали ? Да ?

То что даёт ггуль не открывается.

Ссылку в студию!

>Вы не поняли или не захотели понять эти аргументы. Проверить у вас в QNX нихрена нельзя эту применимость в общем случае ! То что "у меня работатет" это не серьезный аргумент на самом деле. Так как у вас есть конкретные условия и конкретные задачи. И вам совершенно плевать как оно будет у других людей, как и разработчикаv QNX на проблемы НЕ КАСТОМЕРОВ.

Есть другая версия... yfcrjkmrj z gjvy. предыдущие посты klalafluda у qnx6 нет проблем в плане использования на desktop. Просто фирма - разработчик не хотела его распространять под это дело. Время упущено. Поздно спорить. Что есть, то и имеем, но это не значит что qnx не может использоваться под desktop - я не вижу технических проблем.

TotalView Debugger

PS: тот же ddd+gdb позволяет отлаживать на ура многопоточные программы.

TVD это "тяжёлая артиллерия" - можно отлаживать _распределённые_ программы размазанные по кластеру.

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

>Только так можно синхронизировать процессы в qnx4 и так можно в qnx6. Это к вопросу о том, что весь код почти без переделки легко перекомпилируется под Линуксом. Я к тому, что не легко

Семафоры и разделяемая память - это разные объекты.

было время собирать в ядро, настало время его делить...

Да разнве, но в qnx4 posix семафор можно создать только в шаред мемори.

Странно. Ведь семафор д.б. объектом ядра, недоступным процессам.. QNX не рулит?

> Есть шансы найти откуда ноги растут?

Разумеется, есть. Сообщения должны быть поинформативнее. Что бы как минимум, можно было установить:

1) В какой строке, какого исходника она генерируется;

2) Кто писал этот кусок кода.

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

> Код должен быть разделен на контролируемые порции.

Ыыыы! А сейчас там всё в одном файле? Он и так разделён. Именно, на контролируемые. Иначе в одиночку 30 Mb патчей не наложить...

> И желательно аппаратно.

А ИИ вам не нужен? ;-) Чем микроядро будет лучше в такой ситуации?

> Да уж.. пальцем в небо. Берём драйвер для железки написанный под 2.6.8, думаю к 2.6.20 он уже не подойдёт.

И что вы этим хотели сказать? Я и не утверждал наличие API/ABI совместимости между версиями.

> Ыыыы! А сейчас там всё в одном файле? Он и так разделён. Именно, на контролируемые. Иначе в одиночку 30 Mb патчей не наложить..

Обсуждаемая новость несколько противоречит вашему высказыванию, не находите?

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

Нет, разумеется. Мортон жалуется не на это.

> Мортон жалуется не на это.

В самом деле? А на что?

> В самом деле? А на что?

А почитать? Он жалуется на:

1) Патчей присылают слишком много, чтобы справится одному;

2) Патчи частично взаимопересекаются и приходится писать корректирующие патчи;

3) Сообщения об ошибках шлют ему, а не авторам кода.

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

Ну. А вы утверждаете, что всё наоборот. Всё логично структурировано, нигде не пересекается и один человек в состоянии наложить 30МБ патчей. Кто из вас лжет - вы или Мортон?

> Кто из вас лжет - вы или Мортон?

Ну если вы на такой тон перешли, то отвечу. Никто. Просто вы - дурак.

Как ни структурируй исходники, но когда куча людей ведёт независимую разработку, *всегда* будут возникать накладки с присланными патчами. Хоть там микро, хоть нано, хоть экзо ядро. А пришлют два и более патчей к одной подсистеме и будут они мешать наложению друг друга, а то и не работать совместно.

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

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

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

> Что запустил? Я вот тут давеча пример из своего компутера приводил. Запустил, пишет в лог: "kernel: [254744.692000] APIC error on CPU0: 40(40)"

Иди обновляй дрова нвидии ))

* Исправлены ошибки взаимодействия с набором системной логики ATi RS480/482

Так и будешь из-за кривых дров и биосов менять винду на солярис а потом обратно на линукс как дурак ))

> Ну так о том и речь - оставить ядру ядрово, а остальных - гнать из нулевого кольца поганою метлою.

Мля... Осильте уже документ (http://www.kroah.com/log/linux/stable_api_nonsense.html) и успокойтесь. Галаперидольчику примите. Хоть в userspace засуньте, оно всё равно на ядро будет завязано.

> и вам тут же откроется истина

Ещё один обладатель Истинной Истины? Нимб не жмёт?

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

по скольку мне в сущности совершенно все равно, каким именно путём разрешатся те или иные проблемы ядра Linux [и разрешатся ли вообще], в целях экономии времени и сил я предпочту тихо удалиться из нашего спора. пардон.

// wbr

> Мля... Осильте уже документ..и успокойтесь. Галаперидольчику примите. Хоть в userspace засуньте, оно всё равно на ядро будет завязано. > Ещё один обладатель Истинной Истины? Нимб не жмёт?

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

>Иди обновляй дрова нвидии )) * Исправлены ошибки взаимодействия с набором системной логики ATi RS480/482 Так и будешь из-за кривых дров и биосов менять винду на солярис а потом обратно на линукс как дурак ))

Ну вот, а же говорил, что lspci некоторые спрашивают не для того что бы туда заглядывать. Где ты там нвидию видел, дурачина? :о)

> Многопоточные/многозадачные системы просто отлаживать?

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

> А интересно, как твой многомудрый мозг отловит race conditions

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

> рейсы возникают когда какой-нибудь дятел поленился сделать проверку или взвести семафор.

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

> Рейсы возникают когда одному потоку приходится ожидать ресурса занятого другим потоком.

RTFM: "A race condition or race hazard is a flaw in a system or process whereby the output of the process is unexpectedly and critically dependent on the sequence or timing of other events" - http://en.wikipedia.org/wiki/Race_condition

> Рейсы возникают когда одному потоку приходится ожидать ресурса занятого другим потоком...

s/Рейсы/Взаимные блокировки/, и всё высказывание будет верным.

> http://en.wikipedia.org/wiki/Race_condition

Я не понял, вы со мной согласны или хотите поспорить?

> Я не понял, вы со мной согласны или хотите поспорить?

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

> s/Рейсы/Взаимные блокировки/, и всё высказывание будет верным.

s/Взаимные блокировки/дидлоки/ ?

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

Кончайте демагогией заниматься ;)

Не нужно путать _проектирование_ и _отладку_ Отладка для того и существует чтобы проверить как работает то что вы на бумажке нарисовали. Даже если вы на языке FM опишите задачу а потом вам автоматический кодогенератор код сгенерирует это еще не гарантирует того что код будет правильный и рабочий.

PS: лет 10 назад общался с командой которая такие вещи пыталась проделать. До сих пор бьются но пока не нашли "серебряной пули" ;)

>перед объективными фактами.

Пацтулом. С нетерпением ждём "объективных фактов" ROTFL ;)

> Я говорю что "рейсы" - это последствия кривого кодирования

рейсы - это соревнования за ресурс. при кривом программировании никто за ресурс не соревнуется.

> при кривом программировании никто за ресурс не соревнуется.

Эт как ? Падает в сегфолт еще до точки входа в main() ? ;)

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

Опустимся до микроядерности - станем вторым виндовсом. Но то, что держать ядро монолитным становится проблематично эт 100%. надо там действительно что-то менять в организации процесса.

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

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

Скорее уж тогда возвысимся, поскольку микроядерность стоит на более высокой ступени эволюции :-)

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

Ужас какой ;) Может тогда вообще ничего не писать ? Вообще.

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

Пацтулом ;) Вот оказывается какой ты - "современный кодер" ;)

Ну-ка, покажи как где тут race ;)


#include "mpi.h"
#include <stdio.h>
#include <math.h>

double f(double);

double f(double a)
{
    return (4.0 / (1.0 + a*a));
}

int main(int argc,char *argv[])
{
    int    n, myid, numprocs, i;
    double PI25DT = 3.141592653589793238462643;
    double mypi, pi, h, sum, x;
    double startwtime = 0.0, endwtime;
    int    namelen;
    char   processor_name[MPI_MAX_PROCESSOR_NAME];

    MPI_Init(&argc,&argv);
    MPI_Comm_size(MPI_COMM_WORLD,&numprocs);
    MPI_Comm_rank(MPI_COMM_WORLD,&myid);
    MPI_Get_processor_name(processor_name,&namelen);

    fprintf(stdout,"Process %d of %d is on %s\n",
            myid, numprocs, processor_name);
    fflush(stdout);

    n = 10000;                  /* default # of rectangles */
    if (myid == 0)
        startwtime = MPI_Wtime();


    MPI_Bcast(&n, 1, MPI_INT, 0, MPI_COMM_WORLD);

    h   = 1.0 / (double) n;
    sum = 0.0;
    /* A slightly better approach starts from large i and works back */
    for (i = myid + 1; i <= n; i += numprocs)
    {
        x = h * ((double)i - 0.5);
        sum += f(x);
    }
    mypi = h * sum;

    MPI_Reduce(&mypi, &pi, 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD);

    if (myid == 0) {
        endwtime = MPI_Wtime();
        printf("pi is approximately %.16f, Error is %.16f\n",
               pi, fabs(pi - PI25DT));
        printf("wall clock time = %f\n", endwtime-startwtime);
        fflush(stdout);
    }

    MPI_Finalize();
    return 0;
}

> Может тогда вообще ничего не писать ? Вообще.

А ты вообще пишешь что?

> Скорее уж тогда возвысимся, поскольку микроядерность стоит на более высокой ступени эволюции :-)

Да. на более высокой. тупиковой. У офтопика микроядро. И что мы видим - куча косяков и глюков. поменял комп - сноси винду. железочку одну сменил - переставляй. А линь банально перелил образом с одного веника на другой, и все в шоколаде. Ну максимум чуток в /etc/ подрехтовать конфиги и все. Так что не убедили.

> У офтопика микроядро.

Дети, кто вам это сказал? PR-отдел Microsoft?

> Дети, кто вам это сказал? PR-отдел Microsoft?

А с чего вы взяли, что человек про Виндовс излагает? Описанных проблем за виндовсом не числится, так что он, видимо, про QNX рассуждает. :-D