Alan Cox предложил изменения в devices.txt

А я Гауляйтер **КОХ**

>Если я например пишу драйвер для АЦП - для них нет предопределенных классов в ядре, мне придется создать его, зарегистрировать и все ради того чтобы чтобы файл устройства создался в юзерспейсе автоматом ?

Для АЦП рекомендую misc_class или uio_class. ИМХО лучше, чем лезть в /proc/devices за номером. Ещё некоторые драйверы делают старший номер параметром, можно и так.

> может вам и linux то не нужен.

был ненужен; использовали µC/OS. но время идет, всё меняется...

> busybox настолько мал в современном понимании что не использовать его - я даже не представляю почему :)

а я не представляю _зачем_ его использовать (в нашем случае, естественно). тем более, ресурсы достаточно ограничены.

> Или вы bash используете и иже с ним полноценные утилиты ?

нет. один исполняемый файл, собранный статически (ядро вызывает его вместо init'а) и несколько файлов устройств (думаю, понятно где всё это находится). зачем в такую гармонию пихать базибокс или юдев? только ради динамических номеров устройств (которые на скорость не повлияют... положительно)? бред полнейший.

>Для АЦП рекомендую misc_class
Да - пожалуй подойдет, спасибо, я интересовался когда подходящим - с наскоку не нашел для char, про misc не знал.
>Ещё некоторые драйверы делают старший номер параметром, можно и так.
тут не понял о каком параметре речь - если параметр модулю - то мы вроде о динамическом выделении говорим. Я в логах писал полученные динамически номера.

>Список _не динозавров_ в студию. Кто получает адреса автоматом? Всё, с чем я работал я видел в devices.txt

Тогда Вы и старших номеров > 255 не видели? Я тоже не видел, но они могут быть =) Не динозавры - по крайней мере все драйверы, которые получают старший номер через register_chrdev(0, ...), например все драйверы из класса UIO. И не думаю, что Alan Cox или ещё кто-нибудь будет увеличивать количество жестко закрепленных старших номеров. Закидают помидорами на lkml.

Понятно. Думаю все равно что-то адекватное придумают или до упора будут поддерживать. initrd вон давно хотят похоронить - до сих пор живет :)

>Alan Cox послал в LKML патч, приводящий файл Documentation/devices.txt, содержащий имена и статические номера поблочных и посимвольных устройств Linux, в соответствие с реальностью.
>Documentation/devices.txt
>.txt
Мне кажется, с этим как-то связана его фамилия.

> отучаемся говорить за всех

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

эээ,
да и это я это просто к примеру привел...

>нет. один исполняемый файл, собранный статически (ядро вызывает его вместо init'а) и несколько файлов устройств (думаю, понятно где всё это находится). зачем в такую гармонию пихать базибокс или юдев? только ради динамических номеров устройств (которые на скорость не повлияют... положительно)? бред полнейший.

Busybox нужен хотя бы для отладки. Если во время выполнения вашей программы вы, например, захотите посмотреть логи ядра, или файл который создала эта программа и который хранится внутри устройства. Или вот ситуация: налажен серийный выпуск embedded-устройств и однажды в ремонт приходит такой вот экземплярчик который не включается. Разбирать его естественно не хочется. Программа не запускается то ли из-за программной ошибки, то ли из-за аппаратной проблемы. Я в таком случае запущу gdbserver и проведу отладку в системе, а вы? Если у вас даже шелла нет?

> Busybox нужен хотя бы для отладки.

чуть выше я написал: «в штатном режиме». вариант отладки при этом исключён чуть больше чем полностью. я нигде ранее не говорил, что болею базибокс-фобией. базибокс нужен там, где он нужен. в нашем случае — ненужен (для особо внимательных повторюсь — в штатном режиме).

> Если во время выполнения вашей программы вы, например, захотите посмотреть логи ядра, или файл который создала эта программа и который хранится внутри устройства.

фс ридонли, хранится в памяти, никакие файлы не создаются. а если _я_ захочу посмотреть логи ядра, то я их возьму и посмотрю, потому что у меня отладочная система, со всем необходимым инструментарием.

> Или вот ситуация: налажен серийный выпуск embedded-устройств и однажды в ремонт приходит такой вот экземплярчик который не включается.

если прибор не включается, от базибокса пользы будет чуть меньше, чем от наклейки на корпусе =)

> Программа не запускается то ли из-за программной ошибки, то ли из-за аппаратной проблемы. Я в таком случае запущу gdbserver и проведу отладку в системе, а вы? Если у вас даже шелла нет?

а я поставлю отладочную прошивку и не буду насиловать себе моск.

Комп (P133) используется как роутер 

ss:/home/ss# lspci
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:09.0 Ethernet controller: Winbond Electronics Corp 89C940
00:0a.0 VGA compatible controller: S3 Inc. 86C764_1 [Trio 32/64 vers 1]
00:0b.0 Ethernet controller: Winbond Electronics Corp 89C940

Сама плата это ISA девайс (отдельный панасовский контроллер а не звуковуха) которая была подарена вместе с CD приводом ввиду утери (а может быть отсутствия как класс) драйверов для Windows в далёком 1996 году. Работает до сих пор.


Пример был неудачным :)

Наиболее оптимальным выходом был бы кернельный "демон" типа devfs/udev (подменяемый на пользовательский для экзотических случаев). То что есть безнадежно неудобоваримо.

> Комп (P133) используется как роутер 

а что за ядро у вас?
дело в том, что у меня 2.6.29-rc8-git5 и я не нашел в недрах ядра ничего, что б напоминало sbpcd.[ch] (как было раньше судя по гуглу и некоторым быстренько нагугленным темам из lklm). Нет вообще никакого упоминания кроме как в devices.txt  Возможно оно в новых ядрах как обычный cdrom или его вообще вышвырнули. Тогда пример удачный был ;) Но все это риторика...

> вот к примеру на кой нам это:


Вероятно, железо ещё поддерживается и применяется. :)

> 25 sbpcd

Что за звуковуха? ;-) Не думал, что были PCI с поддержкой этих интерфейсов. Или раритет мучаем? ;-)

> Сама плата это ISA девайс (отдельный панасовский контроллер а не звуковуха)

Ага, у меня была в своё время такая же... :) Ввиду того, что на звуковухе оказался выломан один из штырьков для нужного интерфейса. :)

>а что за ядро у вас?

2.2.(не помню сколько)

железяка пережила несколько поколений потомков :)

> Предлагаю открыть реалити шоу: "Linux kernel developers IRL"

Уже есть. LKML называется, с матами Линуса в прямом эфире.

Коксуем вместе!

> Пример был неудачным :)

Кто ж туда будет новые ядра ставить. Так что наоборот, пример с железкой неудачный.

прочел новость - не понял
почитал первые комменты - а все понятно
почитал следующие комменты - не понял
как страшно жить в кернелдеве....

как все запущено

>> Программа не запускается то ли из-за программной ошибки, то ли из-за аппаратной проблемы. Я в таком случае запущу gdbserver и проведу отладку в системе, а вы? Если у вас даже шелла нет?

> а я поставлю отладочную прошивку и не буду насиловать себе моск.

Будет забавно, когда проблема на отладочной прошивке не проявится.

> Будет забавно, когда проблема на отладочной прошивке не проявится.

будет забавно, когда кошка щенят родит =) а с подобными проблемами я как-нибудь сам разберусь.

зы: поскольку проблемы отладки никакого отношения ни к динамическим номерам устройств, ни к сабжу не имеют, может, не будем дальше развивать тему в этом направлении, как вы считаете?

> зы: поскольку проблемы отладки никакого отношения ни к динамическим номерам устройств, ни к сабжу не имеют, может, не будем дальше развивать тему в этом направлении, как вы считаете?

Она сама в этом направлении развивается. Проблема статических номеров - это в основном проблема всраиваемого оборудования. И эта проблема решается. Только часть разработчиков (такие как вы) это решение не принимает. Потому и держат этот список.

Вот так я вас обощил. :)

Вот это да!

>Только часть разработчиков (такие как вы) это решение не принимает.

а другая часть разработчиков (не будем показывать пальцем) навязывают другим _якобы_ крайне важную и необходимую функциональность.

впрочем, такие разработчики, думаю, очень ценны для производителя оффтопика. это я (лично) Вам на заметку))

>> Только часть разработчиков (такие как вы) это решение не принимает.

> а другая часть разработчиков (не будем показывать пальцем) навязывают другим _якобы_ крайне важную и необходимую функциональность.

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

> впрочем, такие разработчики, думаю, очень ценны для производителя оффтопика. это я (лично) Вам на заметку))

Зачем это написано? Попытка перехода на личности? Не выйдет. :)

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

>принять такую точку зрения как правильную - нет.

твоя права наша не понимать :))

> Вот и спалилась куча народа, ни разу не смотревшего документацию на ядро :-)

+5