В догонку - в lkml такой флейм поднялся по поводу "Какого фига убрали девфс! Я его люблю верните суки!" что вот это вот -
http://lkml.org/lkml/2003/12/23/307
решили даже в фак поместить :)))
Столько геморроя (devfs, теперь вот udev) - и все ради чего? Чтоб лемминги, которым команда mknod кажется слишком сложной для понимания, чувствовали себя хорошо. "/dev is too big" - нет слов.
И вааще зачем нужен /dev - это давно устаревший предрассудок (все есть файл). Давайте лучше сделаем демона (сервис) и он как бы и возьмет на себя общение между девайсами и userlevel. Через сокеты можно будет к подключаться непосредственно к устройствам. Преимуществ куча - можно например подключится к демону на соседнем компе и слать ему данные в аналог, например, /dev/dsp.
а локально то этот демон будет работать с девайсом через что ?
или это будет не демон, а ядерный модуль ?
короче, как не крутись, а жить этой шняге в кернелспейсе, отчего не будет ни надежности, ни секурности...
Вот блин, рассуждают ... А ты попробуй на реальном серваке в SAN'е порулить парой сотней девайсов, да еще с постоянным подключением новых девайсов НА ХОДУ, да еще плюс VxVM/LVM. Вообще IMHO Linux так до сих пор не вырос из детских штанишек в области работы на предприятии с кучей дисковых устройств. Соляра здесь десять очков форы даст.
Хе, динозавры тоже в свое время сто очков форы давали всяким там млекопитающим размерами с крысу. Однако ж вымерли - только скелеты, обглоданные теми же самыми крысами, и остались. А с серверами, на которых пара сотен девайсов навешана, будет (ИМХО) то же самое - кластеры их обгладают, что хоть сейчас в палеонтологический музей здавай. Единственная проблема, почему этого до сих пор не случилось- девайсы нельзя по сети шарить ...
>>то есть мне предлагается наизусть помнить все миноры и мажоры ? вот мне делать больне нечего.
Во-во ... Любимый аргумент леммингов (я не имею ввиду здесь присутсвующих) - "Мы что должны помнить все ключи команды find?" А файл /usr/src/linux/Documentation/devices.txt на что?
>Чтоб лемминги, которым команда mknod кажется слишком сложной для понимания, чувствовали себя хорошо. "/dev is too big" - нет слов.
А сколько времени тратиться на открытие файла устройства ???
В каталоге, в котором может быть несколько тысяч устройств ??
Проблема в основном в падении производительности при работе с устройствами
>Через сокеты можно будет к подключаться непосредственно к устройствам.
Проблемы это не решит, придётся окрыть соответсвуюшее количество сокетов, где-то держать их список, со всеми номерами
+ каждый сокет - это буфер, сколько понадобится памяти, чтобы
держать все эти сокеты открытыми? Причем больше половины из них
не будет использоваться
> Единственная проблема, почему этого до сих пор не случилось- девайсы нельзя по сети шарить ...
Обшибаешься. Давно такое есть в линуксе. nbd называется. Network Block
Device. В частности, применяется в качестве свопа для бездисковых
рабочих станций.
udef и должен отменить MAKEDEV. задача udev таже самая, что и у MAKEDEV --
создание нодов в /dev/. но udev создает ноды автоматически "налету": когда
устройство (любое) подключается или отключается, происходит вызов
/sbin/hotplug, при этом udev создает или удаляет в /dev/ соответствующий
данному устройству нод. имя, права доступа, и все остальное, характеризующее
нод задается в конфигурационном файле или определяется из sysfs.
по стравнению с devfs у udev есть несколько концептуальных ограничений.
например теряется возможность автоматической подгрузки драйвера устройства при
отрытии нода в /dev.
зато есть и очевидные преимущетсва. имена устройствам теперь можно присваивать
любые (они ведь задаются через текстовый конфиг). надеюсь, что до /dev/A:,
/dev/C: дело не дойдет =). при использовании udev, файловая система для /dev не
имеет значения (это может быть ramfs, например). все операции выполняются в
userspace. ну и т.п.
Это был контр-аргумент к твоему утверждению о том, что неохота помнить _все_ major/minor устройств. Как оказалось, не все. Более того, обычному пользователю за глаза хватит и MAKEDEV.
а если хочешь подключить себе звуковую ... или скажем сетевуху
другой топологии с сервака :) нет проблемм !!!
читай http://plan9.bell-labs.com/plan9dist/
Здесь хоть кто-нибудь статью, то которую обсуждаете читал??
Там вполне ясно написано чем плох devfs, /dev и чем хорош udev.
Кстати тем кто с санкой и с большим кол-вом дисков тоже советую почитать.
Одна из прелестей udev, в том, что она работает в userspace, а значит может swap'иться (в отличее от dev). Если спросите зачем свопить, то советую сначала прочитать статью...
И вообще как вы devfs и sysfs перепутали/смешали довольно весело...
> Это был контр-аргумент к твоему утверждению о том, что неохота помнить _все_ major/minor устройств. Как оказалось, не все. Более того, обычному пользователю за глаза хватит и MAKEDEV.
Да ну. Стоит взять какой-нить винмодем, и, эта, devices.txt в пролете.
>>то есть мне предлагается наизусть помнить все миноры и мажоры ? вот мне делать больне нечего.
>Во-во ... Любимый аргумент леммингов (я не имею ввиду здесь >присутсвующих) - "Мы что должны помнить все ключи команды find?" А >файл /usr/src/linux/Documentation/devices.txt на что?
Я напрмер занимаюсь в этой области и знаю это всё практически наизусть, но есть ещё куча людей: врачей, инженеров и проч. которым НЕ нужно знать всё о системе, они работают в своей области, и всё. Этим людям не
нужно поминть кучу команд, и они не должны быть программерами, чтобы юзать систему. Им достаточно пару раз кликнуть мышкой, чтобы запустить приложение. Но щас какие-нибудь придурки скажут, что пусть врачи, инженеры и проч. юзают Винды...И это грустно...
ИМХО Линух никогда не станет полноценной ДЕСКТОПНОЙ осью, а форточки - историей...если так рассуждать(вынь - ламерам, линух - крутым рограммерам).......:(((((((((((((
Не переживай. Капитализм возьмет свое: "крутые программеры" захотят кушать и тут же вспомнять, для кого они пишут програмы и кто их кормит.
P.S. Если программирование - это искусство целенаправленного ограничения степеней свободы автомата, то найдите lim (x->0) F{}, где F{} - степени свободы автомата (или возможные состояния + направления переходов, по вкусу), x - желание пользователя тратить свое время на изучение промежуточного языка для своего инструмента профессиональной деятельности, и Вы получите то, чем Вы, на самом деле, занимаетесь...