Ссылку не я вам давал… обратитесь по адресу.
Но там отчётливо фигурирует CentOS.
А чем так уж существенно CentOS отличается от RHEL по вашему мнению?
… на CentOS разрабатываются и функционируют большинство телекоммуникационных проектов: VoIP, SIP, SS7, E1/T1/J1… — OpenSer, FreeSWITCH, YATE… Asterisk до того как был куплен Microsoft и тем погиб…
А мне рассказ о .NET, напротив, кажется абсолютно притянутым за уши:
— просто .NET, после многолетних попыток противопоставить его Java (для чего он только и создавался изначально) — практически сдох…
— и перевод его в разряд Open Source — это попытка «хоть тушкой, хоть чучелом» реанимировать покойника.
В тексте отчётливо сквозит деформация общей картины мира, навеянная многолетним пребыванием в средах Microsoft. Такой себе… «взгляд на Open Source с аргументами от Windows».
Ну, здесь я увлёкся и неправ.
Имел в виду великое множество проектов, совершенно открытых и свободных, которые годами сопровождают свои изделия, и которыми пользуется весь мир:
— чипы Broadcom
— чипы Ralink для WiFi
— проект Zaptel/DAHDI, который является интерфейсом к десяткам моделей разнородного оборудования и единственным интерфейсом, используемым всеми софтверными PBX: Asterisk, FreeSWITCH, YATE; но это вообще не драйвер в общепринятом смысле — там ведётся активная обработка потока в режиме ядра, например, нижний уровень сигнализации SS7.
Это только малая часть, названная только для того, чтобы было понятно о чём речь. Все они прекрасно справляются с поддержкой своих проектов ещё с версии ядра даже 2.4, используя LINUX_VERSION_CODE.
Это не говоря уже про проприетарые или полу-проприетарные проекты, которые имеют точно такое же право быть:
— VirtualBox
— NVIDIA со своими драйверами и поддержкой CUDA.
Идея всеобщего глобализма и затея объеденить под крышкой дерева исходных кодов ядра все вообще в природе устройства, протоколы… и вообще любые затеи, меня лично, не греет. Не верю я в идеи всеобщего глобального счастья.
И закончим на этом, потому что публикация и обсуждение совершенно о другом.
Можете привести пример, когда штатного modprobe, /proc и т.д.
Ну, например, когда в ядре 3.10 все модули, использующие API procfs (описанный во всех книгах, LDD3 и т.д. и т.п.) единомоментно перестали компилироваться «на дух» ;-).
А вообще… Мне довольно часто приходилось кого-то чему-то обучать (хотя никогда штатным преподавателем не был). И за многие годы такой практики я выработал такое правило: в программировании (любом!) самое бессмысленное занятие — спрашивать «зачем», единственный осмысленный вопрос — «как». Это касается любых аспектов: языков программирования, трюков на этих языках… и всё-всё-всё: если какая-то фича тебе не нравится — не используй.
Как там говорилось?:
— Что-то меня беспокоит Гондурас!
— Беспокоит? А ты его не чеши…
Я как-раз имел в виду порчу каких-то данных (внутри файловой системы), критических для системы, а не нарушение елостности структуры самой файловой системы.
Но всё это не имеет, собственно, прямого касательства к расматриваемому предмету.
Это как-раз и есть расплата за монолитность ядра в противовес микроядерному, о чём так увлечённо спорили Торвальдс с Таненбаумом. Но эта тема уведёт нас слишком далеко… от моих, по крайней мере, намерений.
Это не решение, а так… отговорка:
1. «засланные» модули все пестрят LINUX_VERSION_CODE — как поле брани телами погибших…
2. это хороший совет, когда вы пишете код… ночами и на коленке, в порядке хобби… удовлетворения либидо; если же это промышленный проект, выполняемый в рамках штатнго расписаия, то на это никто не даст разрешения, да и времени на это нет;
3. и тем более, если это какая-то частная, специальная разработка, и вовсе даже не драйвер (в традиционном смысле), а модуль… некоторых «специальных эффектов», который для команды ядра представлять интереса не может, потому что просто не стыкуется с их философией.
Потому что прототипы меняются, чаще всего, когда кто-то делает рефакторинг (или переписывает всё). Тот, кто делает рефакторинг видит экспортированные функции и знает, что кроме модулей входящих в состав ядра, могут быть и внешние модули.
Это всё сображения «с точки зрения банальной эрудиции»… может быть, а может и не быть…
Но опыт показывает, что API экспортируемых функций меняется произвольно, и часто, и даже чаще, чем многие не экспортируемые. А чтобы мои утверждения не выглядели так же голословно (может быть, а может и не быть) я приведу некоторые (на самом дел их гораздо больше), из самых последних:
— версия 3.9 — меняется API WiFi
— версия 3.12 — меняется полостью API драйверов блочных устройств;
— версия 3.15 — меняется весь API, отвечающий за работу poll, select;
— версия 3.17 — меняется API сетевого стека;
— версия 3.17 — снова меняется API WiFi
Это не изменения в реализации названных подсистем. Это изменения в экспортируемых API, которые делают модули, работающие до сих пор с этими подсистемами, не компилирующимися.
В дополнение к тексту… нужны, как кажется по комментариям, некоторые дополнения, которые не включались в текст из нежелания раздувать и так немалый объём для короткой заметки.
Необходимость кодирования для ядра Linux возникает у программистов 2-х категорий: а). коммитеров, добавляющих (пытающихся) свои коммиты в дерево кодов ядра и б). разработчики автономных проектов, в рамках которых возникают опросы создания модулей ядра (или драйверов, как их простейшей формы). Но коммитеры предпочитают статические изменения в ядре, которые вносятся патчем с последующей сборкой ядра. Меня же интересовали, главным образом, потребности практикующих разработчики, которым требуется динамически внести изменения в функционирование отдельных ветвей ядра (сетевые протоколы, например).
Я не хочу обсуждать здесь вопрос зачем. Сконцентрируемся на вопроса как. Некоторую ясность в вопрос зачем добавят, возможно и не сняв его полностью, последующие части бсуждения (не зря в заголовке написано: часть 1).
Очень много попутных вопросов-ответов, аргументов-возражений и т.д. обкатывались на протяжении последих лет 5-ти в темах, обсуждаемых а форуме Linux изнутри. Я не могу все их обсудить ни в комментариях ни в тексте, но их намётки можно найти в этом форуме. Кроме того, итогом почти 10-ти летней работы с модулями вылились в учебный курс, выполенный на заказ, и тренинги по которому были проведен с 5-ю различными группами (в разных городах-филиалах) разработчиков одной из крупнейших международных софтверных компаний. Полный текст (>400 страниц) и архив из доброй сотни модулей для самых разнообразных случаев можно свободно взять (всё под лицензий Creative Commons Attribution ShareAlike) в моём блоге: Практикум по Linux Kernel.
Вот такое пространное объяснение мне показалось необходимым к тому, чтобы в комментариях мы обсуждали только вещи, относящиеся к публикации. Просто потому что:
Вы спешите…
Если бы вы были чуть проницательнее, ил читали чуть размереннее и внимательнее, то заподозрили бы, что меня интересует, в подавляющем большинстве случаев, sys_call_table.
Спешите…
ну зачем могут понадобиться файловые операции из ядра?
Зачем?
Ну, например, для чтения своих конфигурационных параметров из /etc/…, или записи некоторых специфических логов.
Плюс — теряется совместимость между разными версиями ядра,
Объясните (смоделируйте, опишите ситуацию) почему прототипы неэкспортируемых функций, например, должны меняться чаще, чем экспортируемых… только конкретно, на примерах, без… «из сображений банальной эрудиции»…
Но там отчётливо фигурирует CentOS.
А чем так уж существенно CentOS отличается от RHEL по вашему мнению?
… на CentOS разрабатываются и функционируют большинство телекоммуникационных проектов: VoIP, SIP, SS7, E1/T1/J1… — OpenSer, FreeSWITCH, YATE… Asterisk до того как был куплен Microsoft и тем погиб…
— просто .NET, после многолетних попыток противопоставить его Java (для чего он только и создавался изначально) — практически сдох…
— и перевод его в разряд Open Source — это попытка «хоть тушкой, хоть чучелом» реанимировать покойника.
Ну, здесь я увлёкся и неправ.
Имел в виду великое множество проектов, совершенно открытых и свободных, которые годами сопровождают свои изделия, и которыми пользуется весь мир:
— чипы Broadcom
— чипы Ralink для WiFi
— проект Zaptel/DAHDI, который является интерфейсом к десяткам моделей разнородного оборудования и единственным интерфейсом, используемым всеми софтверными PBX: Asterisk, FreeSWITCH, YATE; но это вообще не драйвер в общепринятом смысле — там ведётся активная обработка потока в режиме ядра, например, нижний уровень сигнализации SS7.
Это только малая часть, названная только для того, чтобы было понятно о чём речь. Все они прекрасно справляются с поддержкой своих проектов ещё с версии ядра даже 2.4, используя LINUX_VERSION_CODE.
Это не говоря уже про проприетарые или полу-проприетарные проекты, которые имеют точно такое же право быть:
— VirtualBox
— NVIDIA со своими драйверами и поддержкой CUDA.
Идея всеобщего глобализма и затея объеденить под крышкой дерева исходных кодов ядра все вообще в природе устройства, протоколы… и вообще любые затеи, меня лично, не греет. Не верю я в идеи всеобщего глобального счастья.
И закончим на этом, потому что публикация и обсуждение совершенно о другом.
Вот когда мы дойдём до sys_call_table, вот тогда и посмотрим зачем.
…
Ну, например, когда в ядре 3.10 все модули, использующие API procfs (описанный во всех книгах, LDD3 и т.д. и т.п.) единомоментно перестали компилироваться «на дух» ;-).
А вообще… Мне довольно часто приходилось кого-то чему-то обучать (хотя никогда штатным преподавателем не был). И за многие годы такой практики я выработал такое правило: в программировании (любом!) самое бессмысленное занятие — спрашивать «зачем», единственный осмысленный вопрос — «как». Это касается любых аспектов: языков программирования, трюков на этих языках… и всё-всё-всё: если какая-то фича тебе не нравится — не используй.
Как там говорилось?:
Не видел — это не обязательно означает, что такое невозможно.
Но всё это не имеет, собственно, прямого касательства к расматриваемому предмету.
Это как-раз и есть расплата за монолитность ядра в противовес микроядерному, о чём так увлечённо спорили Торвальдс с Таненбаумом. Но эта тема уведёт нас слишком далеко… от моих, по крайней мере, намерений.
Это не решение, а так… отговорка:
1. «засланные» модули все пестрят LINUX_VERSION_CODE — как поле брани телами погибших…
2. это хороший совет, когда вы пишете код… ночами и на коленке, в порядке хобби… удовлетворения либидо; если же это промышленный проект, выполняемый в рамках штатнго расписаия, то на это никто не даст разрешения, да и времени на это нет;
3. и тем более, если это какая-то частная, специальная разработка, и вовсе даже не драйвер (в традиционном смысле), а модуль… некоторых «специальных эффектов», который для команды ядра представлять интереса не может, потому что просто не стыкуется с их философией.
Это всё сображения «с точки зрения банальной эрудиции»… может быть, а может и не быть…
Но опыт показывает, что API экспортируемых функций меняется произвольно, и часто, и даже чаще, чем многие не экспортируемые. А чтобы мои утверждения не выглядели так же голословно (может быть, а может и не быть) я приведу некоторые (на самом дел их гораздо больше), из самых последних:
— версия 3.9 — меняется API WiFi
— версия 3.12 — меняется полостью API драйверов блочных устройств;
— версия 3.15 — меняется весь API, отвечающий за работу poll, select;
— версия 3.17 — меняется API сетевого стека;
— версия 3.17 — снова меняется API WiFi
Это не изменения в реализации названных подсистем. Это изменения в экспортируемых API, которые делают модули, работающие до сих пор с этими подсистемами, не компилирующимися.
Необходимость кодирования для ядра Linux возникает у программистов 2-х категорий: а). коммитеров, добавляющих (пытающихся) свои коммиты в дерево кодов ядра и б). разработчики автономных проектов, в рамках которых возникают опросы создания модулей ядра (или драйверов, как их простейшей формы). Но коммитеры предпочитают статические изменения в ядре, которые вносятся патчем с последующей сборкой ядра. Меня же интересовали, главным образом, потребности практикующих разработчики, которым требуется динамически внести изменения в функционирование отдельных ветвей ядра (сетевые протоколы, например).
Я не хочу обсуждать здесь вопрос зачем. Сконцентрируемся на вопроса как. Некоторую ясность в вопрос зачем добавят, возможно и не сняв его полностью, последующие части бсуждения (не зря в заголовке написано: часть 1).
Очень много попутных вопросов-ответов, аргументов-возражений и т.д. обкатывались на протяжении последих лет 5-ти в темах, обсуждаемых а форуме Linux изнутри. Я не могу все их обсудить ни в комментариях ни в тексте, но их намётки можно найти в этом форуме. Кроме того, итогом почти 10-ти летней работы с модулями вылились в учебный курс, выполенный на заказ, и тренинги по которому были проведен с 5-ю различными группами (в разных городах-филиалах) разработчиков одной из крупнейших международных софтверных компаний. Полный текст (>400 страниц) и архив из доброй сотни модулей для самых разнообразных случаев можно свободно взять (всё под лицензий Creative Commons Attribution ShareAlike) в моём блоге: Практикум по Linux Kernel.
Вот такое пространное объяснение мне показалось необходимым к тому, чтобы в комментариях мы обсуждали только вещи, относящиеся к публикации. Просто потому что:
(с) Козьма Прутков.
Если бы вы были чуть проницательнее, ил читали чуть размереннее и внимательнее, то заподозрили бы, что меня интересует, в подавляющем большинстве случаев, sys_call_table.
Спешите…
Зачем?
Ну, например, для чтения своих конфигурационных параметров из /etc/…, или записи некоторых специфических логов.
Объясните (смоделируйте, опишите ситуацию) почему прототипы неэкспортируемых функций, например, должны меняться чаще, чем экспортируемых… только конкретно, на примерах, без… «из сображений банальной эрудиции»…