Как формируются файлы устройств для доступа к драйверам

Добрый день.
Все основные операции с "железом" проходят в ядре, и представляют из себя драйвера устройств. Они могут быть "вшиты" в монолитное ядро ОС, либо быть выполнены в виде модуля ядра. Чтобы осуществить полную операцию взаимодействия с железом мы должны:
а) написать драйвер устройства в виде модуля ядра и загрузить его. (для конкретики пусть это будет устройство на шине usb)
б) написать приложение(скажем на языке с++)? которое будет открывать файл устройства - /dev/usb0 на запись и чтение, и тем самым обмениваться данными с usb устройством.

Исходя из выше сказанного файл устройства по сути является связующим звеном или "мостом" между пользовательским приложением и приложением на уровне ядра(драйвером).

Если все вышесказанное является верным, будем переходить к вопросу)))

Как и в какое время формируется файл устройства и конкретно интерфейс. Т.е. как линукс определяет что у нас действительно есть usb шина или скажем ide контроллер. И как линукс при включении "незнакомого" ему устройства определить его??

Для конкретного примера представим, что вы купили usb контроллер на шине pci. Воткнули его в комп и загружаете линукс. Если данный контроллер поддерживается линуксом, то я так понимаю он увидит интерфейс USB. А если контроллер не поддерживается? И линукс не то чтобы файл устройства не видит, а не видит интерфейс....

И последний пример. Вставляем в usb самопальное устройство выполненое на каком-нибудь avr/pic контроллере... Как будет определяться usb устройство в папке /dev и как работать именно с файлом устройства??

http://dmilvdv.narod.ru/Translate/index.html
Драйверы устройств Linux, Третья Редакция\
ближе к теме будет там "Глава 3, Символьные драйверы"

Более ничем помочь не могу

Все устройства, подключенные к ПК определяются в процессе загрузки ядра. В совр. компах есть "виртуальная системная шина", которая "подключена ко всем устройствам" , соб-но у нее ядро и спрашивает список оборудования и типы устройств.
Каждый драйвер связывается со соот-им устройством по его старшему номеру, по к-му опр-ся тип устройства (у мониторов свой номер, у винчестеров - свой). А если устройств одного типа несколько - то еще и с его младшим номером. В папке /dev создаются файлы типа "устройства", которые имеют имя и старший и младший номер, тем самым устанавливают соответствие между устройством со стороны пользователя и драйвером. На тот случай, если ФС не поддерживает файлы типа "устройство", то создается виртуальная файловая система devfs (UNIX-системы все чаще используют этот способ).

1.USB подсистема инициализируется во время загрузки ядра, до запуска процесса Init при условии что она включена при компиляции ядра. Если она модульная то загружается из образа initrd как правило. Основное её назначение - найти USB мосты в компьютере и подключённые к ним хабы. После чего именно она обрабатывает все подключаемые USB устройства, инициализирует 0-ую точку, управляет энергопотреблением, предоставляет драйверам высокоуровневые функции для работы с USB устройствами.

2. За конкретные устройства отвечают уже драйверы. Много их есть в ядре, либо в виде модулей, либо вкомпиленные. Драйвер загружается при подключении USB устройства, или вручную, что редко - но бывает.

3. За создание устройств в dev если они нужны отвечает UDEV, либо можно их вручную создать утилитой. В современных дистрибутивах всё делается автоматически. Как будет называться устройство - определяет либо сам драйвер либо UDEV. В любом случае ядро само создать файл на диске или в виртуальной ФС не может, и оно просто уведомляет UDEV посредством сокета, что это надо сделать.

4. утилита lsusb видит все работоспособные USB устройства в системе, даже если для них нет драйверов.

Фактически вариантов здесь несколько:
1. Драйвер загрузился, опознал и инициализировал своё устройство, и после этого пожелал создать файл в /dev
Он вызывает функцию create_device или аналог, например в USB стеке есть функция именно для этого, задаёт имя устройства, класс, категорию для отображения в /sys и сообщает UDEV что надо создать файл устройства, связать его с заданными MAJOR и MINOR номерами.
UDEV не вдаваясь в подробности создаёт устройство с заданным именем.
2. Драйвер загрузился, но устройство создать не пожелал, предполагая что оно будет создано вручную, но сообщил UDEV что устройство добавлено. UDEV проверяет свои правила, и если находит правило для этого устройства сам создаёт его. Так создаются многие стандартные устройства в системе. Например приём часто используется при добавлении USB-com портов модемов.
3. UDEV не нашёл правила и ничего не создал. Пользователь может, зная то что ему нужно создать файл устройства вручную.
4. Работа без драйвера. Ядро не нашло драйвера, и udev соответственно ничего не создал. Пользовательские приложения могут самостоятельно обращаться к USB устройствам, с помощью механизма предоставленного USB стэком в Linux. Для этого в системе есть библиотека libusb. Драйвер в этом случае не нужен, устройства в dev обычно не создаются. Так работают CUPS, SANE и некоторые другие приложения.

Твой случай - контроллер Atmel или PIC - по умолчанию имеют свои VendorID и DeviceID. Но что они будут делать определяет твоя прошивка. Поэтому ядро никаких устройств в /dev для них не создаст, если ты не напишешь драйвер сам. Самое простое в твоём случае - работа с ними через библиотеку libusb.