Вопросы Теги

Что означает то, когда что-то говорит, что файлы устройств UNIX статичны?

Википедия, "Фактор (Unix)" с интересным взятием:

фактор сначала появился на 5-м Unix Исследования выпуска в 1974, когда "пользователь поддержал" утилиту (разделите 6 из руководства). В 7-м выпуске в 1979, это было перемещено в основной раздел "команд" руководства (разделите 1). Оттуда, факторная утилита была скопирована во все другие варианты Unix, включая коммерческий Unixes и BSD. В некоторых вариантах Unix это классифицировано как "игра" больше, чем серьезная утилита и поэтому зарегистрировано в раздел 6.

Таким образом, казалось бы, что некоторый пользователь (пользователи) любил играть вокруг с простыми множителями и записал фактор - и после того как это существовало, вероятно, не было никаким серьезным основанием не включать его как команду в последующих версиях Unix. Таким образом, "практические применения" фактора могут зависеть от того, что Вы считаете практичными - если Вы в теорию простого числа, это - вероятно, большой tool/game/whatever.

4
26.10.2013, 01:56
3 ответа

Я предполагаю, что Вы обращаетесь к этому абзацу:

В отличие от традиционных систем Unix, где узлы устройства в/dev каталоге были статическим набором файлов, динамично обеспечивает Linux udev диспетчер устройств, только узлы для устройств на самом деле представляют в системе. Хотя devfs раньше обеспечивал схожую функциональность, Greg Kroah-Hartman процитировал много reasons3 для предпочтения ее реализации по devfs:

От 1-го предложения они обращаются к другим системам Unix где устройства в /dev статически создаются и сохраняются от перезагрузки до перезагрузки. Предыдущие версии Linux (думают 2,4 версии Ядра) раньше работали это слишком, более новые версии больше не ведут себя этим способом. Другие Unixes обычно включают единый набор файлов устройств, когда Вы устанавливаете их, и только редко это необходимый для ручного создания дополнительных.

В 2,4 Вы могли использовать mknod управляйте к вручную для создания любых необходимых файлов устройств. Например:

$ mknod ./dev/random b 12 5

Примечание: Это указывает, создают /dev/random дескриптор файла, как блочное устройство с количеством основного устройства 12 и незначительным номером устройства 5.

Файлы устройств под/dev

OP задал следующий последующий вопрос относительно полной функциональности /dev каталог. Вот его вопрос:

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

В исследовании этого я полагал, что запущу с Linux, С нуля проекта для получения общего представления о как /dev управляется в более новых версиях ядра Linux. Я знаю, что в прошлом (думают версии Ядра 2.4 и прежде), /dev каталог был статическим набором файлов, которые буквально заняли место на жестком диске, но с появлением udev и sysfs это больше не имело место.

Традиционно, эти специальные файлы были созданы во время установки распределением, с помощью mknod команда. В последние годы системы Linux начали использовать udev управлять ими /dev файлы во времени выполнения. Например, udev создаст узлы, когда устройства обнаруживаются и удаляют их, когда устройства удалены (включая устройства замены в горячем режиме во времени выполнения). Таким образом, /dev каталог содержит (по большей части) только записи для устройств, которые на самом деле существуют в системе в текущее время, в противоположность устройствам, которые могли существовать.

Так уведенный дни необходимости волноваться о Ваших файлах устройств под /dev. Этим каталогом теперь полностью управляют udev и sysfs от перезагрузки до перезагрузки.

Дополнительный udev & sysfs ресурсы

Ссылки

10
27.01.2020, 20:47
  • 1
    Это не "более старые" системы Unix, это - традиционные системы Unix. OpenBSD все еще использует статические записи. Это - даже относительно недавнее изобретение в Linux, чтобы иметь динамические записи. –  kurtm 26.10.2013, 03:11
  • 2
    Кроме того, ради записи это было (и продолжает быть), эксперт, редкий для создания файлов устройств вручную. Большинство операционных систем заполнило бы/dev с большим количеством файлов устройств на установке, которая покроет большую часть использования. Одно обычно единственное / для создания их с необычными комбинациями аппаратных средств. Я делаю это на своем находящемся в OpenBSD сервере последовательной консоли, который имеет 3 последовательных карты с 8 портами. –  kurtm 26.10.2013, 03:18
  • 3
    @kurtm - расширенный на основе Вашей обратной связи, спасибо. –  slm♦ 26.10.2013, 03:24
  • 4
    @slm, можно ли добавить, что детали о техническом методе раньше сохраняли файлы устройств через перезагрузки? как они физически хранятся на диске? им была нужна специальная поддержка файловой системы? –  strugee 04.11.2013, 02:53
  • 5
    @strugee - Хорошо, я включу его немного. На работе теперь. интриги кармы –  slm♦ 04.11.2013, 19:00

"файлы устройств" - это особый тип файлов (примерно так же, как каталоги, символические ссылки, именованные каналы и сокеты домена unix являются специальными типами файлов). Они не хранят пользовательские данные напрямую, вместо этого они хранят старший и младший номер устройства и тип устройства (char или block). Файловые системы, разработанные для unix-подобных систем, будут поддерживать хранение файлов устройств.

Когда к «файлу устройства» обращается либо приложение, либо команда монтирования, старший и младший номер устройства и тип устройства извлекаются из файловой системы. На основе этих чисел ядро ​​выбирает драйвер и открывает его.

Традиционно файлы устройств просто существовали в каталоге корневой файловой системы с именем / dev, обычно создаваемом с помощью инструмента MAKEDEV, который считывает файлы конфигурации и создает узлы устройств. Это называется статической настройкой и использовалась в течение многих лет практически во всех unix-подобных ОС, включая Linux. У этого подхода есть несколько недостатков.

  • Файлы устройств существовали, даже если соответствующее оборудование отсутствовало в текущей системе. Было сложно сказать, что было, а что нет.
  • Если в обновлении ядра появятся новые типы устройств, администратору, вероятно, придется вручную создавать для них узлы устройств.
  • Было ограниченное количество старших и младших номеров, статическое назначение пары каждому возможному узлу устройства (помните, что одно физическое устройство может иметь много узлов устройств из-за разделения) было не масштабируемым.

Первая попытка Linux решить эту проблему была названа devfs (некоторые другие unix-подобные операционные системы также имеют файловую систему devfs, но я не знаю подробностей). Это была виртуальная файловая система, в которой ядро ​​предоставляло узлы устройств. Afaict он был относительно мертворожденным, он продвигал свою собственную нестандартную схему именования устройств, нравится вам это или нет, и не предлагал огромных преимуществ по сравнению со статическим / dev

. Позже появился udev. Здесь использовалась другая модель. Файл tmpfs был смонтирован на / dev, и dameon пользовательского пространства управлял узлами устройств в нем на основе уведомлений от ядра. https://lwn.net/Articles/65197/

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

1
27.01.2020, 20:47

En el sistema Altos 386 (i386/SCO SysV Unix ), un ejemplo de un dispositivo estático que tuvo que crearse en la actualización del kernel (o reinstalar )fue la plétora de /dev/mt entradas para admitir unidades de cinta SCSI HP Dat. El número mayor era para el controlador de cinta en el bus SCSI y los menores eran para el número de dispositivo SCSI y las características (raw, rewind no rewind vienen a la mente ). Había dos buses SCSI y podían admitir múltiples unidades de cinta mixtas y sistemas de archivos de extensión HD montados en cada bus.

Los desarrolladores eran solo entradas en el sistema de archivos raíz hechas con MAKEDDEV. A efectos prácticos, podrían vincularse a nombres más utilizables, por lo que el dispositivo de rebobinado en el dispositivo SCSI 5 podría vincularse a /dev/st (cinta SCSI para distinguirlo de una unidad DC300 incorporada)

Más tarde, tuvimos que hacer lo mismo cuando comenzamos a usar Slackware Linux y tuvimos que parchear manualmente el kernel.99b para usar las tarjetas ethernet combinadas 3Com 3C509b correctamente. Estos tenían conectores cat5, BNC y AUI y el juego estaba obteniendo la interfaz correcta en el momento del arranque

0
27.01.2020, 20:47

Теги

Похожие вопросы