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

Первый :) А зачем это?

и что?

>Затем следует удаление .... и устаревших устройств.

А зачем?!

Пусть будет. Хотя, возможно, что я неправ, но тогда пусть мне объяснят - почему!

Размер ядра - не критерий, т.к. его можно собирать без поддержки, а пересобирать, если надо что-то экзотичное.

И это тянет на новость???

>Пусть будет. Хотя, возможно, что я неправ, но тогда пусть мне объяснят - почему!

Осиль сначала прочитать пост. Там говорится о правке в текстовом файле.

Монструальный чувак! Главное чтоб udev, hald и прочие от этого работать не перестали.

Какой ещё .txt? Есть конспирологическая теория гласящая, что у всех kernel разработчиков винда в дуалбуте. devices.txt это серьёзный пруф.

Мощно. Теперь-то венде точно капец.

> Какой ещё .txt?
А есть мнение, что лучше опознавать "текст.txt" или "текст.odt" вместо просто "текст"

Расширение жгет

>А зачем это?

>и что?

>А зачем?!

>И это тянет на новость???

Да, что вы все так волнуетесь ? Это не для вас. Это для тех, кто перед ковырянием в ядре всё-таки заглядывает в /usr/src/linux/Documentation .

>Какой ещё .txt? Есть конспирологическая теория гласящая, что у всех kernel разработчиков винда в дуалбуте. devices.txt это серьёзный пруф.

$ find /usr/src/linux-2.6.29-gentoo-r1 -iname *.txt | wc -l
757

> А зачем?!
> Пусть будет. Хотя, возможно, что я неправ, но тогда пусть мне объяснят - почему!

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

> [lanana]
WUT?

как всегда куча пиз#@жа не по теме
а между тем там есть уж совсем страшная фигня, в этом списке девайсов
вот к примеру на кой нам это:

 26 block       Second Matsushita (Panasonic/SoundBlaster) CD-ROM
                  0 = /dev/sbpcd4       Panasonic CD-ROM controller 1 unit 0
                  1 = /dev/sbpcd5       Panasonic CD-ROM controller 1 unit 1
                  2 = /dev/sbpcd6       Panasonic CD-ROM controller 1 unit 2
                  3 = /dev/sbpcd7       Panasonic CD-ROM controller 1 unit 3

Как бы это... неожиданная новость. Они бы лучше другим занялись, а не всякой фигней.

ну-ну
уж если Алан по вашему фигней занимается...

Как я понял эти переименования касаются всех ядер линейки 2.6?
Более удобно_читаемые имена устройств есть хорошо.
Microrevolution is coming!...

А за новость respect и +1.
Побольше бы тем про ядро.

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

>Какой ещё .txt? Есть конспирологическая теория гласящая, что у всех kernel разработчиков винда в дуалбуте. devices.txt это серьёзный пруф.

Какой еще дуалбут? Они все Linux давно в VMware пишут, запущенной на Висте. Зачем, по твоему, в 6-ю версию встроили отладчик ядра?

Епт. Тут даже по ссылке идти не надо.
Или теперь для полной Ъшности новость тоже не читается?
Речь идет о документации, а не о приведении имен в другой вид.

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

Предлагаю на каждый микропатч в ядре создавать новость.

>Предлагаю на каждый микропатч в ядре создавать новость.

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

> Second Matsushita (Panasonic/SoundBlaster) CD-ROM

Это не фигня. В играх про магию это называется "undead".

Мне казалось, что эти девайсы умерли ещё до появления линукса. Я был неправ. :)

патч, приводящий файл Documentation/devices.txt, содержащий имена и статические номера поблочных и посимвольных устройств Linux, в соответствие с реальностью.

oops, а я подумал что они и имена изменят

> Первый кусок патча .....
> Вторая часть патча ......
> ... И в качестве подробностей линк на diff-файл

(давясь слезами) (всхлипывая) трогательно-то как! Какое знаковое событие в жизни сообщества! Забыли только инкеремнтировать версию с 2.6 до 2.8

Специально для тебя и других всхлип^Wметанирующих - это важно потому что номера устройств должны быть уникальны в системе в первую очередь при формировании вызовов ioctl если ты хочешь чтобы этот вызов дошел до твоего устройства и не конфликтовал с другими. При создании драйвера ты обязан соблюдать правила и не занимать мажорные номера закрепленные за другими. И откуда еще можно узнать что занято а что нет если не в документации идущей с ядром ?

>Какой ещё .txt? Есть конспирологическая теория гласящая, что у всех kernel разработчиков винда в дуалбуте. devices.txt это серьёзный пруф.

дурак?

>Какой ещё .txt? Есть конспирологическая теория гласящая, что у всех kernel разработчиков винда в дуалбуте. devices.txt это серьёзный пруф.

Пасивный вантузятнег детектед.

Это ченджер, я такой юзал однажды

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

Какая замечательная, важная новость. Не хватает только тэга "Истории успеха" который бы поведал нам о блаженности гармонии м/ду Документацией и СуровымРеальнымМиром

> А в итоге с того времени прошло уже (сколько там?) лет, а номера до сих пор актуальны.

Насколько я знаю, сейчас драйвер не обязан сам выбирать номера для своих девайсов, можно это сделать автоматом. Старые драйверы, для которых уже были выбраны номера, продолжают их юзать. И вот для таких драйверов, реальность и devices.txt расходились во мнениях.

Alan Cox ответственный (за файл), крутой и бородатый. Так-то вот!

>Насколько я знаю, сейчас драйвер не обязан сам выбирать номера для своих девайсов, можно это сделать автоматом. Старые драйверы, для которых уже были выбраны номера, продолжают их юзать. И вот для таких драйверов, реальность и devices.txt расходились во мнениях.

Есть номера зарезервированные за определенными устройствами, а другие динамически выделяются.
Для всех драйверов, которые внесены в ядро эти номера (major, minor) уже закреплены и это отображено в devices.txt.
Динамические же скорее используются для драйверов, которые еще на стадии написания и за которыми еще не закреплены статические номера.

Поправьте меня, если я не прав.

>Насколько я знаю, сейчас драйвер не обязан сам выбирать номера для своих девайсов, можно это сделать автоматом.

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

>Для всех драйверов, которые внесены в ядро эти номера (major, minor) уже закреплены и это отображено в devices.txt. Динамические же скорее используются для драйверов, которые еще на стадии написания и за которыми еще не закреплены статические номера. Поправьте меня, если я не прав.

Ты абсолютно не прав! Новые драйвера устройств должны динамически получать major и minor номера. Статически закреплены номера за "динозаврами" и специальными файлами типа /dev/mem Поправьте меня, если я не прав.

>а между тем там есть уж совсем страшная фигня, в этом списке девайсов
>вот к примеру на кой нам это:

 >26 block       Second Matsushita (Panasonic/SoundBlaster) CD-ROM
 >                0 = /dev/sbpcd4       Panasonic CD-ROM controller 1 unit 0
 >               1 = /dev/sbpcd5       Panasonic CD-ROM controller 1 unit 1
 >                 2 = /dev/sbpcd6       Panasonic CD-ROM controller 1 unit 2
 >                 3 = /dev/sbpcd7       Panasonic CD-ROM controller 1 unit 3

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

ss:~$ cat /proc/devices
Character devices:
  1 mem
  2 pty
  3 ttyp
  4 ttyS
  5 cua
  6 lp
  7 vcs
 10 misc
 29 fb
 36 netlink
128 ptm
129 ptm
136 pts
137 pts

Block devices:
  1 ramdisk
  2 fd
  3 ide0
  7 loop
 22 ide1
 25 sbpcd
 43 nbd

>Новые драйвера устройств должны динамически получать major и minor номера.

Все это вроде бы удобно но на данный момент есть пара проблем с этим - юзерспейс ничего не знает о мажорном номере которые выделяются автоматом, если твой новый драйвер не относится к какому-то предопределенному классу устройств - файл устройства нужно создавать ручками в юзерспейсе и придется лезти за мажором в /proc/devices, ядро не передаст хотплугу юзерспейсному ничего чтобы тот же udev автоматом создал файл устройства в /dev.

>Ты абсолютно не прав! Новые драйвера устройств должны динамически получать major и minor номера. Статически закреплены номера за "динозаврами" и специальными файлами типа /dev/mem Поправьте меня, если я не прав.

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

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

> ss:~$ cat /proc/devices

Он говорил про документацию к ядру, а не /proc/devices:

# cat /usr/src/linux/Documentation/devices.txt | grep -A5 "Second Matsushita"
 26 block	Second Matsushita (Panasonic/SoundBlaster) CD-ROM
		  0 = /dev/sbpcd4	Panasonic CD-ROM controller 1 unit 0
		  1 = /dev/sbpcd5	Panasonic CD-ROM controller 1 unit 1
		  2 = /dev/sbpcd6	Panasonic CD-ROM controller 1 unit 2
		  3 = /dev/sbpcd7	Panasonic CD-ROM controller 1 unit 3

> Ты абсолютно не прав! Новые драйвера устройств должны динамически получать major и minor номера. Статически закреплены номера за "динозаврами" и специальными файлами типа /dev/mem Поправьте меня, если я не прав.

а с embedded что бум делать? пихать туда юдев? для многих девайсов это слишком жирно. возможность собрать ядро без динамических номеров обязательно должна быть, хотя бы под опцией “Configure standard kernel features (for small systems)”. иначе развод =)

>файл устройства нужно создавать ручками в юзерспейсе и придется лезти за мажором в /proc/devices, ядро не передаст хотплугу юзерспейсному ничего чтобы тот же udev автоматом создал файл устройства в /dev.

Драйвер может сам создать файл с помощью device_create(), передать ему какое-нибудь имя, а udev сам в соответствии со своими правилами может изменить имя и права на файл. Например, в drivers/char/mem.c:992 создаются устройства mem, kmem, null, port, zero, full, random, urandom, kmsg, oldmem. А в /etc/udev/rules.d/40-permissions.rules и 40-basic-permissions.rules им назначаются права доступа. Userspace и не должен ничего знать об major/minor.

>а с embedded что бум делать? пихать туда юдев?

Используем mdev из состава busybox.

>Он говорил про документацию к ядру, а не /proc/devices:

Ашшо один

Учимся читать

Читаем внимательно
>если твой новый драйвер не относится к какому-то предопределенному классу устройств

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

> Используем mdev из состава busybox.

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

Обрисуйте примерную картину ваших разработок если конечно это интересно и есть время, может вам и linux то не нужен. busybox настолько мал в современном понимании что не использовать его - я даже не представляю почему :) Или вы bash используете и иже с ним полноценные утилиты ?

>выбирать между (ранее ненужными) базибоксом и юдевом? а в чём профит?

1. Посмотреть, какие номера получают устройства при загрузке девайса

2. Жестко забить файлы с соответствующими major'ами и minor'ами в /dev

3. ???

4. PROFIT!

Старшие номера не рандомизируются, пока что.