>>>Доверенными считаю базовые обязанности ядра: менеджмент памятью и процессами.
>>Гм. Интересная формулировка, "доверенные обязанности". Мне такое в голову не
>у ядра есть несколько базовых обязательных обязанностей.
>По теме нам интересны - управление памятью и межпроцессное взаимодействие.
>Они названы доверенными, т.к. лишь с их помощью контролируеться "бардак",
>происходящий в операционной системе.
Вообще-то Вы забыли как минимум работу с железом (брокер портов и DMA даже по версии Таненбаума), ну да ладно.>может это и плохо, но общую стоимость разработки Линуха никто толком никогда
>не подсчитывал - следовательно, резкость ее подъема вряд-ли возможна ;)
>мы просто об этом не узнаем :)
Если Вы умудрились пропустить и оценки стоимости ядра, и предложение одним товарищем тридцати, что ли, миллионов за копию linux/ не под GPL (не помню -- BSD/MIT-like?) -- то Вы, конечно же, и этого просто не узнаете.
Понимаете, трепаться можно ни о чём. Можно же -- с интересными людьми -- выковыривая и из _трёпа_ "за жисть" интересные и уже обобщённые факты в т.ч. по технологии и организации.
Мне почему-то такие вот интересные и уже пережёванные вещи много кто забрасывает, за что им признателен.
>ну а сроки... творя прекрасное (дай бог) - мы не ограничены в сроках ;)
Ещё как ограничены, кроме только сна подавляющему большинству творческого времени остаётся много меньше полумиллиона часов.
>>Здесь проблема не в процессоре, на который так напирает уважаемый gmm20.
>>I/O было, есть и пока собирается оставаться и так тем ещё
>>ботлнеком -- отключите DMA на диске (ведь "however"-то у Вас не
>>выполняется, как и у меня?) и подумайте, а стоит ли флагом
>>махать.
>ну вот ведь способны, когда хотите :)
Блин. Я-то это и так знал. И _сразу_ сказал. Хотя, конечно, домогаться пояснений при широких обобщениях -- разумно.
>Именно это и нужно обсуждать. Насколько реальна эта затея чисто технически и
>программно.
Так _сразу_ и сказал. "Программно" тут, btw, и есть половина "технически".
>Аргумент "это рулез" или "фтопку" не представляет научного интереса.
Тьфу. Это вообще не аргумент.
>По теме: ИМО, не должно быть больших проблем с DMA.
Вы же не ядерный разработчик. Значит, этому МО цена -- около нуля.
>Выделяем (по запросу драйвера) буффер DMA из памяти ядра [...]
Почитайте про одни bounce buffers и вагон проблем с DMA и _разным_ железом на i386, где память по факту (железно) сегментирована. Даже когда 32-bit сдохнет, боюсь, с ровностью периферии ровнее не станет, особенно сразу.
>Не претендую на 100% правильность решения проблемы. Но на то он и
>спор. Это ведь поиск решения
Ещё раз: я _не_ спорю с Вами. Не обижайтесь, но спорить получается на одной почве и на сравнимом уровне. А не когда два не-ядерщика обсуждают стратегию развития ядра, причём один из них всё-таки читал kernel-traffic и читает kernelnewbies, а другой не в курсе того, что стоимость разработки ядра Linux всё-таки оценивалась, но возражает по конкретно этому вопросу (да, это тоже вполне сознательный типичный наезд -- просто помогает погуглить что-то вроде linux kernel development costs).
>>>мое умение писать драйвера пока к делу отношения не имеет.
>>Ещё как имеет.
>вот теперь, когда дело дошло (??) до деталей - да, имеет ;)
Нет. Как имело, так и имеет. Простите, мне и такие вещи приходится знать заранее. ;)
>ИМО, нечно потенциально полезное - лучше, чем реально бесполезное ;)
Вопрос в SNR (сигнал/шум) и результате.
>ну дык жизнь многогранна... день на день не приходиться. Когда языком, когда
>напильником... ;)
Соответственно и результат -- или нет, или может быть.
>Что я преследую местными постами - получить может быть каких-нить технических проблемм,
>может быть даже задач, связанных с реализацией подобного подхода.
>И вот, я вижу сдвиг - кто-то видит в работе DMA потенциальные проблемы.
Так здрасьте, подпишитесь на linux-kernel@ и отфильтруйте по одному DMA недельку трафика -- увидите столько сдвигов...
>>Ясно же написал -- дрова надо освобождать (тестированием, копейкой помочь, ну или
>>напильником, если выходит). И вендорам капать на мозги как потребителям,
>>желательно крупным, в эту сторону. И всё.
>это метод социнженерии. И он тоже небезнадежен.
>Просто есть подозрение, что есть и техническое решение ;)
Оно результирует в том, что никому не нужно. См. про привычки, think "а где мой офисный пакет?" или "хочу POSIX!!".
>>Уйти от кривостей x86* уже особо не выйдет
>Вкратце, если можно.
1) кривая адресация памяти (x86)
>В чем же такая большая и непреодолимая проблема x86?
>На какой платформе нет таких проблем, о которых мы говорим?
Часть решена в AMD64, но спасибо Intel со своим кривым EM64T, разбавившим архитектуру x86_64 -- надеяться на наличие того же IOMMU там теперь не получается :(
>>А одиночки уже не роляют.
>оглянитесь. Вокруг много людей, в принципе на что-то способных, но без цели.
Я, видите ли, не первый год занимаюсь подбрасыванием целей людям (как и мне в своё время хорошие друзья, зная интересы). "Много людей" ничего само по себе не определяет.
>Заинтересовать их, дать им цель - и армия одиночек асилит невпихуемое :)
Уй.
Рассказать историю linux.kiev.ua? Она довольно забавна, включая шуточное начало, кризис, смену движка и отвечающего, и как раз такие вот раздумия над тем, что же способно объединить армию вебмастеров одной странички (с двумя родными языками и вагоном цветистой местной специфики). Отчасти изложено здесь:
http://www.linux.kiev.ua/ru/site/about/
http://www.linux.kiev.ua/ru/devel/hosting/web/
но многое из личного там отсутствует (хотя секретов и нет). При этом есть много вещей, которые у нас делать бессмысленно ровно потому, что есть opennet.ru и их лучше сделать здесь (нарисовать статью, забросить ссылку, etc).
