|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 13 Mar 2002 10:08:37
To : Vladimir Bormotov
Subject : Re: Writing a driver programme
--------------------------------------------------------------------------------
v.ua> <m37kojqsg4.fsf@vb.dn.ua>
From: Valentin Nechayev <netch@segfault.kiev.ua>
>>> Vladimir Bormotov wrote:
VN> Во времена позднего 0.* Линус как-то делал такую попытку.
> а, тогда ясно. Еслди Линус не может запинать "идейную линию" ядра в
> нормальную модульность, чтоб каждый год не ломать интерфейсы внутрених
> подсистем, а только расширять, то конечно на C++ это так сходу не
> переписать. Там думать нужно просто с другой стороны. Совершенно.
Я плохо себе представляю, как можно не ломать интерфейсы внутренних
подсистем, если меняется фактически вся внутренняя логика работы.
Сравнить тот же SMP в 2.0 и 2.4. Драйверы для 2.4 должны продолжать
сидеть на одном giant kernel lock? Им должна обеспечиваться такая возможность?
А почему собственно?
Или completion ports, введенные в основную ветку в 2.4.10.
Фактически, вся система работы не-spinlock'овой семафоризации оказалась
вывернутой наизнанку. Тоже надо было делать переходники для всего старого,
или вообще не переходить?
Когда требуют ABI compatibility, обычно имеют в виду несколько другое.
Унутренности ядра менять приходится постоянно. Вот заменить, например,
код для нового SIOGIFCONF в 2.2, чтобы старый ifconfig не показывал
счетчики переданных пакетов как счетчики ошибок - да, имело смысл
(а еще больше имело смысл не перетасовывать поля в структуре).
Hо сохранять, например, устройство namei/dentry cache - зачем?
Или Вы про принудительную маркировку модулей? Это, фактически, шаг
жестокой перестраховки, в отсутствие более иного механизма проверки
состояния ABI. Hо не более того.
>> А дейсвительно критичные места, их можно прям в eiffel заинлайнить, на
>> том-же C ;)) По идее, с C++ все гораздо проще...
VN> Hу это еще надо посмотреть. Грабли могут вылезти совершенно
VN> неожиданно.
> конечно может. Hо в итоге довольно классно получается. У нас даже пару раз
> были такие дружесвеные инсинуации помочь людям из SmallEiffel с
> кодогенератором, но мы потом почитали список рассылки, и поняли что нашей
> помощи им не нужно, они круче ;) поставили новую бету, и вперед ;)))
Hу это вопрос туманный. Даже те, кто круче, могут споткнуться на элементарщине
- заскок подсознания оно явление регулярное.
VN>> А иметь гимор с реализациями Си++, которые и теперь в GPL мире
VN>> хреноватые, а тогда вообще живыми не были - нет, увольте-с.
>> в смысле было-бы проще, еслиб был компилятор, реализация которого который
>> четко соотвевует стандарту.
VN> И он в ядро будет пихать exceptions, rtti и прочую муть?
> зачем?
> Hикто ведь не заставляет пользовать exception. Зато получить контроль
> типов более жесткий, это очень хорошо, реально помогает писать код.
В условиях ядра? Я представляю себе reinterpret_cast по нескольку штук
на странице... картина Репина, холст, масло, черный хлеб ;)
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
