Здравствуйте, butcher, Вы писали:
B>Здравствуйте, stasik_garifulin.
B>Вы писали 20 мая 2004 г., 13:31:43:
s>> А почему драйвер должен это делать? В общем случае нет никаких s>> правил, определяющих как должен называться (где должен s>> располагаться) файл устройства. B>Правила есть, на счёт их точно сказать не могу, но покрайней мере B>существует договорённость (возможно даже на уровне стандарта), как, B>где и какие должный быть файлы устройств. B>--
ага... все на major/minor основано... во FreeBSD даже файлик лежит, где расписано, какие чиселки за чем значаться..
и любой файл имеет тип: дир/файл/блочное/символьное устройтсво... а кернель цепляет к этому файлу vnode_ops (это FreeBSD)
которые обрабатывают обращения к этому файлу... все просто . Почти как виртуальные функции в С++
Здравствуйте, Sergey J. A., Вы писали:
SJA>Может кто подскажет какую ссылочку на описание архитектуры Linux. Что-нибудь наподобие "Inside Windows 2000" от М.Руссинович и Д.Соломона. Много встречал доков, которые описывают архитектуру, но поверхносно... Хотелось бы знать как допустим организованы драйвера, как поддерживается PnP, потоки, процессы...
SJA>А то недавно прочёл одну книжку, и понял, что мои представления о внутреннем устройстве OS несколько однобокие и больше склоняються к архитектуре NT.
вот по VM линуксовому... http://www.skynet.ie/~mel/projects/vm/guide/html/understand/
SJA>И ещё маааленький вопрос : SJA>Почему нужно явно создавать файлы устройств с помощъю mknod (вроде). Почему не сделано так — файлы сами появляються когда драйвер загружен ?
до devfs работало это так:
1. mknod cоздает файл с типом char device или block device. У этого файла есть специальные параметры major и minor.
пока это файл ничего не означает и никуда не привязан, можешь хоть 1000 их создать. Только место в каталоге диска съестся и больше ничего не произойдет.
2. Чтобы работать с устройством, его надо открыть open(). При этому ядро, видя, что это устройство, производит поиск драйвера с заявленным major. После этого к FILE этого файла цепляются т.н. fops которые содержать в себе функции для работы с этим файлом (read()/write()/ioctl()/close() etc). В open() передается minor и уже драйвер знает че с ним дальше делать (например dsp пользует это для каналов).
3. дальше работаешь как с обычным файлом.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, butcher, Вы писали:
B>>Здравствуйте, stasik_garifulin.
B>>Вы писали 20 мая 2004 г., 13:31:43:
s>>> А почему драйвер должен это делать? В общем случае нет никаких s>>> правил, определяющих как должен называться (где должен s>>> располагаться) файл устройства. B>>Правила есть, на счёт их точно сказать не могу, но покрайней мере B>>существует договорённость (возможно даже на уровне стандарта), как, B>>где и какие должный быть файлы устройств. B>>--
A>ага... все на major/minor основано... во FreeBSD даже файлик лежит, где расписано, какие чиселки за чем значаться.. A>и любой файл имеет тип: дир/файл/блочное/символьное устройтсво... а кернель цепляет к этому файлу vnode_ops (это FreeBSD) A>которые обрабатывают обращения к этому файлу... все просто . Почти как виртуальные функции в С++
кто нить реально зарабатывает на том что пишет драйвера под линух?
Было приведено куча ссылок на очень интересные инфы касающейся линукса. Всё это ужасно хочеться понять и изучить — но и хотелосm бы выяснить на сколько это пополнить кроме знаний и мой корман. Вопрос орриентирован в осноном на возможность зарабатывания написанием драйверов. Среди моих знакомых есть люди кто не плохо зарабатывает писаниной драйверов под винды — насколько перспективно это в линухе.?
Здравствуйте, AI, Вы писали:
AI>Среди моих знакомых есть люди кто не плохо зарабатывает писаниной драйверов под винды — насколько перспективно это в линухе.?
некоторые чукчам снег выгодгно продают
Все зависит от тебя и твоей удачи.
Хотя я считаю, что увеличение доли открытых ос в промышленных сегментах будет увеличиваться.
Есть места где используется дос на старом железе и есть люди(были до недавнего времени) которые под это железо на ассемблере писали.
так что, если будешь ты хороший специалист по написанию драйверов под линукс, то жизнь тебя стороной не обойдет
Здравствуйте, AI, Вы писали:
AI>кто нить реально зарабатывает на том что пишет драйвера под линух? AI>Было приведено куча ссылок на очень интересные инфы касающейся линукса. Всё это ужасно хочеться понять и изучить — но и хотелосm бы выяснить на сколько это пополнить кроме знаний и мой корман. Вопрос орриентирован в осноном на возможность зарабатывания написанием драйверов. Среди моих знакомых есть люди кто не плохо зарабатывает писаниной драйверов под винды — насколько перспективно это в линухе.?
вроде как контора rtsoft набирала в недавнем времени народ под это дело...
Здравствуйте, Sergey J. A., Вы писали:
SJA>Может кто подскажет какую ссылочку на описание архитектуры Linux. Что-нибудь наподобие "Inside Windows 2000" от М.Руссинович и Д.Соломона. Много встречал доков, которые описывают архитектуру, но поверхносно... Хотелось бы знать как допустим организованы драйвера, как поддерживается PnP, потоки, процессы...
SJA>А то недавно прочёл одну книжку, и понял, что мои представления о внутреннем устройстве OS несколько однобокие и больше склоняються к архитектуре NT.
SJA>И ещё маааленький вопрос : SJA>Почему нужно явно создавать файлы устройств с помощъю mknod (вроде). Почему не сделано так — файлы сами появляються когда драйвер загружен ?
Заранее извиняюсь за то, что прочитал только половину ответов, надеюсь не сдублирую чье-нибудь сообшенгие.
Теперь по порядку.
Документацию нужно начинать искать в linux/Documentation, там много ценных и не очень ссылок.
Есть достаточно неплохое описание drivers, mm, kernel, некие наброски на описание fs и достаточно
скудный материал по архитектуре net (скорее всего из-за замороченного кода... при всем уважении
к Алексею Кузнецову). Все это при желании можно найти в сети.
Да, кстати, если Вы действительно хорошо знаете архитектуру NT, то изучение kernel и mm не составит
большого труда, т.к. фундаментальные концепции в оной практически идентичны аналогичным в Linux.
Насчет devfs вроде уже ответили. Концепция классического /dev очень проста — ядро поддерживало ограниченное
число драйверов и для каждого из них в /dev был свой node. Сейчас динамическая система имен устройств
реализуется либо через devfs либо udev.
Здравствуйте, glyph, Вы писали:
G> Я сам ищу такую вещь: в "Unix для профессионалов" в гритсах покойным в самом начале упомянту некий Лайонз. И написано, что он в свое время выпустил книгой комментарии более чем к 10 тыс. строк кода Юникс. Потом из-за проблем с авторскими правами книгу изъяли, но она еще долго циркулировала в виде самиздата. Говорят, что можно найти где-то в сети, но я уже год ищу без толку.
"Lions' book" — это описание Bell Unix V7.
Может, оно и интересно исторически, но в современных системах всё настолько не так,
что практически это ничего не даст.
Для понимания же общих принципов годится на порядки более доступная книга Морриса Баха.
Здравствуйте, netch80, Вы писали:
N>"Lions' book" — это описание Bell Unix V7.
Нашел я эту книгу... Ценность представляет сомнительную... N>Может, оно и интересно исторически, но в современных системах всё настолько не так, N>что практически это ничего не даст.
А, о! Не "сомнительную", а историческую... N>Для понимания же общих принципов годится на порядки более доступная книга Морриса Баха.
Поищу, спасибо...
. Почти как виртуальные функции в С++
