Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, netch80, Вы писали:
N>>MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А?
C>Потому что была заменена более новым udev'ом, в котором можно конфигурировать наааааааамного больше всего, чем в devfs.

Вопрос не в том. Я краем глаза видел обсуждение этой замены. Важным была не только конфигуряемость — это меньший вопрос. Большим вопросом было то, что было решено увести из ядра сложность реализации. А вот почему — потому что "сложно"? Недостаточная причина. Наверно, не справились?

Здравствуйте, netch80, Вы писали:

N>Ну я на freebsd это могу и для devfs сделать. Средствами ядра (devfs, devfs.conf...) А чем userspace тут настолько лучше?

Freebsd'шный devfs я не видел и не знаю, чем он отличается от linux'ового. Сравнение udev и devfs для linux см. здесь.

Здравствуйте, netch80, Вы писали:

N>Вопрос не в том. Я краем глаза видел обсуждение этой замены. Важным была не только конфигуряемость — это меньший вопрос. Большим вопросом было то, что было решено увести из ядра сложность реализации.
Нет.

N>А вот почему — потому что "сложно"? Недостаточная причина. Наверно, не справились?
А почитать про вопрос более подробно слабО?

В ядре неудобно и сложно делать кастомные политики именования и обработки событий. В udev созданием имен устройств занимаются обычные shell-скрипты, а в devfs политика именования зашита в код. Или ты предлагаешь пользователю заниматься перекомпилированием ядра и правкой ядерных исходников если ему не понравится система наименования устройств?

Далее, вопрос с событиями — нужно как-то передавать события о появлении/удалении устройств в userspace. В изначальном devfs это было сделано очень неудобно так что возникают race condition'ы — в udev это решается с помощью userspace-фреймоворка. Собственно, udev и начался с попытки добавить userspace-обработку событий к devfs, когда стало понятно, что проще все перенести в userspace.

Ну и вопрос надежности — в devfs примерно 90Кб ядерного кода, а в udev около 16. Чем меньше некритичного к скорости кода в ядре — тем лучше.

PS: сейчас делаю встроенное устройство, где использую udevfs (микро-devfs). Помогает уменьшить размер образа на несколько килобайт и позволяет не думать о каталоге /dev.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, netch80, Вы писали:

N>>Вопрос не в том. Я краем глаза видел обсуждение этой замены. Важным была не только конфигуряемость — это меньший вопрос. Большим вопросом было то, что было решено увести из ядра сложность реализации.
C>Нет.
N>>А вот почему — потому что "сложно"? Недостаточная причина. Наверно, не справились?
C>А почитать про вопрос более подробно слабО?

А понять, что читал — слабО?:)) Из того факта, что я читал чьё-то мнение и комментарии, не значит, что я безусловно должен согласиться с оценками и выводами. Тем более, имея перед глазами примеры, которые как минимум показывают, что есть и другие пути (а как максимум — опровергают).

C>В ядре неудобно и сложно делать кастомные политики именования и обработки событий.

А живые примеры такой работающей политики как минимум на уровне назначения прав и разрешения видимости — наверно, мне приснились.

C> В udev созданием имен устройств занимаются обычные shell-скрипты, а в devfs политика именования зашита в код. Или ты предлагаешь пользователю заниматься перекомпилированием ядра и правкой ядерных исходников если ему не понравится система наименования устройств?

Вообще-то система _наименования_ устройств — та вещь, которую менять _очень_ стрёмно и лучше не разрешать её, даже если она в чём-то не нравится. Например, хотя бы потому, что те же имена выступают и в части внутренней диагностики, и при загрузке (`root=/dev/hda1'). И если кто-то вдруг решит, что ему нужен не hda1, а ad1s1... может, желание будет и понятное, но диверсионное.

А то что могла бы осмысленно делать devfs — контролировать выставление прав и доступы — на уровне ядра делается беспроблемно. Вот кусочек из фрёвого /etc/rc.d/named:

        # Mount a devfs in the chroot directory if needed
        #
        umount ${named_chrootdir}/dev 2>/dev/null
        devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
        devfs -m ${named_chrootdir}/dev rule apply path null unhide
        devfs -m ${named_chrootdir}/dev rule apply path random unhide

Соответственно в намедовом корне есть /dev/null и /dev/random, и ему достаточно.

А что делать, например, в single mode, когда udevd не может быть запущен, а админ играется с модулями? Вот он подгрузит scsi, а /dev/sda не появится. Пускать руками каждый раз синхронизатор? Запускать приблуду в фон?

C>Далее, вопрос с событиями — нужно как-то передавать события о появлении/удалении устройств в userspace. В изначальном devfs это было сделано очень неудобно так что возникают race condition'ы — в udev это решается с помощью userspace-фреймоворка. Собственно, udev и начался с попытки добавить userspace-обработку событий к devfs, когда стало понятно, что проще все перенести в userspace.

То есть причина именно в том, что одна конкретная реализация была неудобной?:))

C>Ну и вопрос надежности — в devfs примерно 90Кб ядерного кода, а в udev около 16. Чем меньше некритичного к скорости кода в ядре — тем лучше.
C>PS: сейчас делаю встроенное устройство, где использую udevfs (микро-devfs). Помогает уменьшить размер образа на несколько килобайт и позволяет не думать о каталоге /dev.

Так что — в нём возвращаемся к devfs?:)) И это после того, как расхвалили udev?

Здравствуйте, netch80, Вы писали:

C>>В ядре неудобно и сложно делать кастомные политики именования и обработки событий.
N>А живые примеры такой работающей политики как минимум на уровне назначения прав и разрешения видимости — наверно, мне приснились.
Эээ... Как? Я не вижу никаких хуков для кастомизации в fs/devfs/base.c

Максимум что в devfs можно сделать — насоздавать симлинки.

N>Вообще-то система _наименования_ устройств — та вещь, которую менять _очень_ стрёмно и лучше не разрешать её, даже если она в чём-то не нравится. Например, хотя бы потому, что те же имена выступают и в части внутренней диагностики, и при загрузке (`root=/dev/hda1'). И если кто-то вдруг решит, что ему нужен не hda1, а ad1s1... может, желание будет и понятное, но диверсионное.
Не согласен.

Мне, например, жутко нравится ifrename. А еще кастомные политики могут быть полезны с устройствами из lvm или всяких NASов (Network Attached Storage).

Кроме того, в udev поддерживает персистентное именование. А то меня жутко раздражало — воткнешь USB-драйв в первый порт и у тебя будет /dev/sdc, а если воткнуть во второй порт — то уже /dev/sdd. Как ты предлагаешь такое решать в devfs? Создавать кучу симлинков — так и получим udev видом в профиль.

N>А то что могла бы осмысленно делать devfs — контролировать выставление прав и доступы — на уровне ядра делается беспроблемно. Вот кусочек из фрёвого /etc/rc.d/named:
N>

N>        # Mount a devfs in the chroot directory if needed
N>        #
N>        umount ${named_chrootdir}/dev 2>/dev/null
N>        devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
N>        devfs -m ${named_chrootdir}/dev rule apply path null unhide
N>        devfs -m ${named_chrootdir}/dev rule apply path random unhide
N>

N>Соответственно в намедовом корне есть /dev/null и /dev/random, и ему достаточно.
А откуда мы будем маски прав (или, не дай бог, POSIX ACLи) брать? Например, udev автоматически проставляет группу floppy для извлекаемых устройств.

N>А что делать, например, в single mode, когда udevd не может быть запущен, а админ играется с модулями? Вот он подгрузит scsi, а /dev/sda не появится. Пускать руками каждый раз синхронизатор? Запускать приблуду в фон?
В single-mode проще всего использовать статический /dev. Ну или что-то типа udevfs с минимумом без всяких наворотов.

C>>Далее, вопрос с событиями — нужно как-то передавать события о появлении/удалении устройств в userspace. В изначальном devfs это было сделано очень неудобно так что возникают race condition'ы — в udev это решается с помощью userspace-фреймоворка. Собственно, udev и начался с попытки добавить userspace-обработку событий к devfs, когда стало понятно, что проще все перенести в userspace.
N>То есть причина именно в том, что одна конкретная реализация была неудобной?
Нет, они все будут неудобные. На LKML был флейм о порядке добавления устройств и об интересных race-condition'ах связаных с этим. Например, если поднятие одного устройства ведет к поднятию нескольких дочерних устройств.

C>>PS: сейчас делаю встроенное устройство, где использую udevfs (микро-devfs). Помогает уменьшить размер образа на несколько килобайт и позволяет не думать о каталоге /dev.
N>Так что — в нём возвращаемся к devfs? И это после того, как расхвалили udev?
А мне полный devfs/udev не нужен, а достаточен udevfs, так как после запуска девайса в production на нем ничего больше меняться в железе не будет. А вот на десктоп такое я ставить не собираюсь.

Здравствуйте, netch80, Вы писали:

Q>>>>Так, а зачем виртуальная, если есть реальная. Замапил обычные файлы в память и все дела — все будет работать синхронно.
N>>>Дададад. Исключительно синхронно. Вы притворяетесь или реально не понимаете, насколько сложные механизмы внутри ОС стоят за "простыми" операциями над FS?
N>>>Или Вы собрались реализовывать преобразование состояния процесса в кусок реальной FS на лету, с апдейтом по каждому мелкому чиху?
EK>>Хм. А что, дорожка "утиль -> fs -> fuse (или что там) -> демон" и выгребание состояния демона каким-то образом короче?

N>По крайней мере эффективнее (и значительно), если в демоне постоянно что-то происходит, а контроль или управление производится периодически по мере необходимости.

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


Q>>>> А то FUSE, VFS, драйвера. Не надо уподобляться MS и выдумывать проблемы на ровном месте.
N>>>MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А?
EK>>Из за технических проблем. А разве нет?

N>А откуда эти проблемы возникли? Именно из-за того, что пытались на уровне VFS совместить работу с двумя источниками активности — внутренним (обновления устройств) и внешним (чтение/запись devfs из userland), и у них не получилось.

Честно говоря, я там код не смотрел, но почему именно здесь проблема? "Внешний" доступ из userland'а -- это, собственно, штатный способ доступа. "Внутренний" -- ну фиг знает, можно же было через ту же дверь ходить....


N>Хотя чем udev значительно лучше — мне не понять.

А какие альтернативы? Даже гипотетически.

Здравствуйте, wf, Вы писали:
"Все есть файл."

это концепт для понимания, а не для реализации. Анализ и Проектирование (то есть этапы до непосредственной реализации) — это этапы для того, чтобы выразить реальную потребность в математической модели. Естественно при создании этой модели использовать те кубики, которые лучше подходят по форме, а не те, которые самые красивые.

Так что если услышите, что "Сеть — это компьютер", не спешите встраивать в каждую программу сетевые возможности.

Для реализации Ваших задумок готового тулкита нет. Есть только API Fuse, на который Вам уже указали, но это довольно низкоуровневый кубик.

Если Вы заинтересованы в иерархическом представлении сервисов, то Файловая Система — не единственная такая возможность. Например, SNMP тоже даёт такое представление. Или большинство ORB-подобных вещей (тот же DBus, который уже очень популярен в современном Unix)

Всего!