>>>из системы в систему, как это происходит сейчас.
>>
>>На это уходит времени на порядки меньше, чем на собсно написание драйвера.
>
>Чем на написание драйвера? Меньше. На порядки - нет. Скажем так, зависит от сложности драйвера. Злосчастный драйвер ath (в Линухе - ath5k) портировать (около пары недель, НЕ чистого времени) оказалось намного быстрее, чем написать (несколько месяцев). Более точные цифры могу вычислить, если нужно; впрочем, это прекрасно делается гуглом:). Как минимум, один порядок разницы во времени.
Или, скажем, trunk (OpenBSD) -> lagg (FreeBSD): даже при наличии расхваленного netgraph'а в последней портирование оказалось на порядок быстрее.
>>Во всяком случае, между *BSD-системами.
>> А что касается объединения кодовой базы
>>*BSD и Linux - это не только нереально по лицензионным
>>соображениям
>
>Linux-а я вообще не касался. О нем речь не идет.
Да, это я позже заметил, сорри.
>>но и потребует кардинальной переработки (или доработки) либо ядра Linux,
>>либо ядер *BSD, либо их всех.
>
>Переделки/доделки - да, само собой.
И далеко не маленькие - скажем, раз уж пошла такая пьянка, на уровне того же сетевого стека все эти ОС отличаются заметно. FreeBSD, например, поддерживает несколько фаерволов, в то время как в OpenBSD сетевые операции "пронизаны" pf'ом. Что выбрать? Внедрять в срочном порядке netgraph в OpenBSD (и рушить этим весь имеющийся отлаженный и функциональный сетевой стек, умеющий MPLS, assymetric routing, equal cost multipath routing, routing priorities и много других страшных слов) или выкидывать его из FreeBSD? Или писать костыль для того самого волшебного "driver abstraction layer", который весьма заметно (вряд ли меньше, чем на 15%, а скорее на все 30-50%) снизит пропускную способность этого самого стека?
>>>о BSD-licensed драйверах с общим API и заканчиваются.
>>
>>Бред. В OpenBSD тоже немало кода приходит.
>
>Само собой, только это проходит аудит OpenBSD-шников как минимум.
То есть в приходящие в тот же Линукс драйвера никакой аудит не проходят??? Всё, точно завязываю с Линуксом... Чесслово, никогда не думал, что проведение проверок качества кода может быть поставлено кем-то в минус, но раз для вас это так, значит, видимо, я действительно чего-то в этой жизни не понимаю...
>как максимум драйвер пишется заново "по мотивам".
Если имеющийся драйвер, по мнению разработчиков OpenBSD (а они, поверьте, тоже не из воздуха эти мнения берут), ценнен только как документация для написания своего драйвера, либо его нельзя добавить по лицензионным соображениям, то да - а что, есть лучший другой путь?
>Часто драйвера переносятся из системы в систему
>именно "по мотивам". Из за разного API.
Не так уж частно. Из-за API - действительно редкость, во всяком случае. В хорошем драйвере (вы, возможно, удивитесь) используются те же технологии разделения кода на функциональные блоки, что и в прикладном программировании - не ООП, но ФП. Как минимум потому, что такой подход очень облегчает последующее обслуживание. В Linux это тоже в своё время поняли (кажется, в районе 1997-го, но могу сильно ошибаться), и с тех пор провели, без преувеличения (и какого-либо сарказма) большую работу по приведению кода в "божественный вид" ((c) одного преподавателя из МИЭМа). А при таком подходе адаптация под другую ОС обычно заключается в двух вещах: полуавтоматическая замена некоторых имён/констант и переписывание одной или нескольких функций, непосредственно взаимодействующих с ОС. Например, как-то так:
jelezka_probe(device_ptr *device) {
if (jelezka_test(device->baseaddr)) {
return 1;
else
return 0;
}
jelezka_test(char *regbase) {
int nres;
<здесь много обращений к различным смещениям от regbase, в ходе которых вычисляется nres>
return nres;
}
В случае портирования могут измениться имена (скажем, jelezka->zhelezka) и быть (частично) переписана jelezka_probe() - а jelezka_test() останется той же, т.к. оперирует значениями, не зависящими от ОС.
>>>Этот промежуточный слой будет не сильно толстым на самом деле.
>>
>>С чего это вы решили? Пожалуйста, набросайте такой слой (вместе с проектом)
>>для, скажем Linux и самой популярной из *BSD - FreeBSD.
>
>Не стану. С меня достаточно понимания того, что это технически это реально.
>
>Не пытайтесь доказать мне обратное.
Не буду.
>Но в человека-часах оценить не смогу.
Понимаете, построить Дворец Советов тоже было технически реально. А в реале Советы сели в лужу.
>FreeBSD-шники мурыжили SMP много-много лет.
>В конце концов таки заработало, как хотели.
Ну, не так уж много. Зачесались поздновато, это да. :( Кстати, было бы интересно сравнить затраты, которые ушли на допиливание SMP у FreeBSD и Linux...
>Здесь такой же случай, была бы цель поставлена.
>Сделать можно.
>>>Внимательнее нужно ЧИТАТЬ!
>>>Я написал все достаточно понятно.
>>
>>Самоувернность хороша немного в других вещах.
>
>При чем тут самоуверенность вообще? :)
Вы уверены, что пишете понятно. Вы же ведь постарались. И поэтому должно быть понятно. Мысль, что, несмотря на ваши старания, всё равно может быть непонятно, или неоднозначно понятно, к сожалению, не всегда вовремя приходит в голову... Сам не идеален, не скрою.
>>Вы высказываетесь не всегда конкретно (видимо,
>>не слишком разбираясь в вопросе - вы хоть одно ядро изучали
>>когда-либо как-нибудь кроме как по новостям да config-make?).
>
>Нет. Я не занимаюсь ядрами. Мне не интересны ядра. Совсем. Я пишу
>прикладные приложения.
>Здесь можно в ответ написать какое-нибудь оскорбление :)
Не собираюсь - скорее, наоборот. Лично я уважаю людей, которые не боятся, в отличие от пятнадцатилетних мегахакеров, признаться, что чего-то не знают (хотя незнание всегда будет по определению больше знания, но ведь до этого ещё додуматься надо...). :)
