Модули ядра не на C

1) net

2) net

mozhno sdelat' interaction cherez sysfs ili procfs. t.e., pishesh' v file - yadro vypolnyaet nekotorye dejstviya.

Модули ядра - нет и не надо.

Можно, насколько я помню, FUSE-шные модули на питоне писать.

Если очень хочется, можно сделать generig message passing interface ядро<->юзерленд, и писать "серверы" в микроядерном понимании, в т.ч. реализующие драйверы устройств и т.п.

Только это никому не нужно низачем.

На ADA можно писать модули ядра. Но это не для слабонервных. И только для некоторые rt-веток ядра подойдет, но в принципе это возможно.

В вопросу "зачем", -- видимо для разработки больших кусков (~ миллиона строк кода и выше) кода, работающих по необходимости в ядре, с жесткими требованиями по стабильности/воспроизводимости результата/времени отклика.

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

А почему не на bash'е ? :-) BTW, обычно всё что можно вынести из ядра - выносят в userspace. Для того, чтобы в kernel что-то вносить надо иметь ОЧЕНЬ веские причины (imho)

Поэтому я за микрокернел

Дык автор ясно дает понять - "модули ядра на питоне", кто мы такие, чтобы переть в другую степь?

Я понимаю, конечно, можно и на перле наваять простенькую оснастку с трасляцией нативного изврата в C нужного формата, но смысл? :) ИМХО это все от непонимания концепции юзерспейсных компонент и тяжкого и длительного вендавозного стажа...

> В вопросу "зачем", -- видимо для разработки больших кусков (~ миллиона строк кода и выше) кода, работающих по необходимости в ядре, с жесткими требованиями по стабильности/воспроизводимости результата/времени отклика.

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

// wbr

>> В вопросу "зачем", -- видимо для разработки больших кусков (~ миллиона строк кода и выше) кода, работающих по необходимости в ядре, с жесткими требованиями по стабильности/воспроизводимости результата/времени отклика.

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

У меня подобных требований ни разу не возникало. Однако кто знает, может на каких-то embeded системах, на каком-нибудь mmu-less процессоре, это и будет иметь смысл определенны.

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

> У меня подобных требований ни разу не возникало. Однако кто знает, может на каких-то embeded системах, на каком-нибудь mmu-less процессоре, это и будет иметь смысл определенны.

для таких особых случаев есть соотв. инструментарий. та-же VxWorks & K. зачем туда Linux то пихать? у него есть своя архитектура, свои требования и ограничения. если они не совпадают с требованиями к системе, наверное, лучше выбрать нечто отличное от Linux.

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

белые люди делают это с соотв. поддержкой со стороны аппаратного обеспечения, где действительно можно достичь жесткого реального времени. ни ни как не на Linux или GPOS :)

// wbr

> белые люди делают это с соотв. поддержкой со стороны аппаратного обеспечения, где действительно можно достичь жесткого реального времени. ни ни как не на Linux или GPOS :)

Я не про vanilla linux говорил, а про различные его realtime расширения. К обычному кернелу ADA вообще не прибилдиться. С другой стороны, не обязательно применять ADA только там, где требуеться стабильность огромного куска кода.

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

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