Userspace linux что это

Обновлено: 01.07.2024

Содержание

История

FUSE была официально включена в главное дерево кода Linux в версии 2.6.14 [1]

Использование

FUSE особенно полезна для написания виртуальных файловых систем. В отличие от традиционных файловых систем, которые по существу сохраняют информацию для восстановления данных с диска, виртуальные файловые системы не хранят данные непосредственно. Они действуют как представление, трансляция существующей файловой системы или устройства хранения.

В принципе, любой ресурс, доступный для использования FUSE, может быть экспортирован в файловую систему.

Примеры использования

Достоинства

  1. Простой API;
  2. Простая установка (не требует патчить или перекомпилировать ядро);
  3. Безопасная реализация;
  4. Очень эффективный интерфейс Userspace — kernel;
  5. Для использования не требует привилегий root'а;
  6. Работает с ядрами Linux 2.4.X и 2.6.X;
  7. Развивается давно; обладает высокой стабильностью.

Как я могу демонтировать файловую систему?

FUSE может быть демонтирована либо:

В более поздних версиях не нужны корневые права доступа, если файловая система была установлена ​​пользователем, делающим размонтирование.

Почему система называется FUSE? Есть эмулятор ZX Spectrum под таким же названием Fuse.

Во время крещения системы, автор FUSE ( файловой системы) не слышал о Fuse (the Speccy emulator) . Автор FUSE (в файловой системе) также создал эмулятор Speccy под названием Spectemu .

Имя должно было быть умной аббревиатурой " Filesystem в USErspace" , но выбор оказался неудачный. С тех пор автор поклялся никогда не назвать проект от общего термина.

Можно ли установить FUSE c fstab ?

Да, начиная с версии 2.4.0 это возможно. Файловая система должна придерживаться некоторых правил о параметрах командной строки, чтобы иметь возможность работать таким образом. Ниже приведен пример монтажа в SSHFS:

Монтаж осуществляется с помощью /sbin/mount.fuse вспомогательного скрипта.

Почему другие пользователи не имеют доступ к установленной файловой системе?

FUSE накладывает это ограничение в целях защиты процессов других пользователей от блуждающих в FUSE. Чтобы снять это ограничение для всех пользователей или только для корня, устанавливайте файловую систему с -oallow_other или -oallow_root . Некорневые пользователи могут только использовать эти опции монтирования , если user_allow_other указан в /etc/fuse.conf .

flush() и, возможно, release() . Смотрите также комментарии в fuse_lowlevel.h

Не проще ли было бы если бы был один метод Close () ?

Нет, потому что отношения между Close() и выходным файлом не так просты, как люди, как правило, себе представляют. UNIX позволяет открывать файлы , чтобы приобрести несколько ссылок

  • после fork() два процесса относятся к тому же открытому файлу;
  • dup() и dup2() сделают еще один дескриптор, ссылающийся на один файл;
  • вызов mmap() обеспечивает отображение памяти относящейся к открытому файлу.

Это означает, что на один open() , может быть больше, чем один Close() и, возможно, munmap () вызовы , пока открытый файл не будет окончательно закрыт.

Могу ли я вернуть ошибку от release() ?

Нет, это не возможно. Если вам нужно возвращать ошибки при закрытии, вы должны сделать flush() .

Как я узнаю, который flush() является последним перед release() ?

Вы не узнаете. Все вызовы flush() должны обрабатываться одинаково. Общее исключение, когда участвует именованный канал. При строительстве именованного канала flush() будет происходить сразу после open() .

Почему не открывается FUSE вперед произвольных вызовов ioctl () ?

Потому что это невозможно: данные , передаваемые ioctl() не имеет строго определенную длину и структуру , как read() и write() . Рассмотрите возможность использования getxattr () и setxattr () вместо этого.

Есть ли способ узнать, GID UID или PID процесса, выполняющего операцию?

Да, используйте fuse_get_context () функцию.

Как следует начинать темы?

Разные темы следует начинать с init() .

Можно ли хранить указатель на личные данные в структуре fuse_file_info ?

Да, fh поле для этой цели. Это поле может быть установлено на open() и create() методах, и доступен во всех других методах , имеющих - структуру fuse_file_info параметра. Обратите внимание, что изменение значения 'fh' в любом другом методе как open() , opendir () или create() не окажет никакого влияния.

Всем привет! Мы продолжаем запуски новых потоков по уже полюбившимся вам курсам и сейчас спешим сообщить о том, что у нас стартует новый набор по курсу «Администратор Linux», который запустится в конце апреля. К этому событию и будет приурочена новая публикация. С оригиналом материала можно ознакомиться тут.

Виртуальные файловые системы выполняют роль некой волшебной абстракции, которая позволяет философии Linux говорить, что «всё является файлом».


Что такое файловая система? Опираясь на слова одного из первых контрибьюторов и авторов Linux Робера Лава, «Файловая система – это иерархическое хранилище данных, собранное в соответствии с определенной структурой». Как бы то ни было, это определение в равной мере хорошо подходит для VFAT (Virtual File Allocation Table), Git и Cassandra (база данных NoSQL). Так что именно определяет такое понятие, как «файловая система»?

Основы файловой системы

Ядро Linux имеет определенные требования к сущности, которая может считаться файловой системой. Она должна реализовывать методы open() , read() и write() для постоянных объектов, которые имеют имена. С точки зрения объектно-ориентированного программирования, ядро определяет обобщенную файловую систему (generic filesystem) в качестве абстрактного интерфейса, а эти три большие функции считаются «виртуальными» и не имеют конкретного определения. Соответственно, реализация файловой системы по умолчанию называется виртуальной файловой системой (VFS).


Если мы можем открывать, читать и записывать в сущность, то эта сущность считается файлом, как мы видим из примера в консоли сверху.
Феномен VFS лишь подчеркивает наблюдение, характерное для Unix-подобных систем, которое гласит, что «всё является файлом». Подумайте, насколько странно, что тот маленький пример сверху с /dev/console показывает, как на самом деле работает консоль. На картинке изображена интерактивная Bash сессия. Отправка строки в консоль (virtual console device) отображает ее на виртуальном экране. VFS имеет другие, еще более странные свойства. Например, она дает возможность осуществлять поиск по ним.

Знакомые нам системы, такие как ext4, NFS и /proc имеют три важные функции в структуре данных С, которая называется file_operations. Кроме того, определенные файловые системы расширяют и переопределяют функции VFS привычным объектно-ориентированным способом. Как отмечает Роберт Лав, абстракция VFS позволяет пользователям Linux беспечно копировать файлы в или из сторонних операционных систем или абстрактных сущностей, таких как pipes, не беспокоясь об их внутреннем формате данных. Со стороны пользователя (userspace) с помощью системного вызова процесс может копировать из файла в структуры данных ядра с помощью метода read() одной файловой системы, а затем использовать метод write() другой файловой системы для вывода данных.

Определения функций, которые принадлежат к базовым типам VFS, находятся в файлах fs/*.c исходного кода ядра, в то время как подкаталоги fs/ содержат определенные файловые системы. В ядре также содержатся сущности, такие как cgroups , /dev и tmpfs , которые требуются в процессе загрузки и поэтому определяются в подкаталоге ядра init/ . Заметьте, что cgroups , /dev и tmpfs не вызывают «большую тройку» функций file_operations , а напрямую читают и пишут в память.
На приведенной ниже диаграмме показано, как userspace обращается к различным типам файловых систем, обычно монтируемых в системах Linux. Не показаны такие конструкции как pipes , dmesg и POSIX clocks , которые также реализуют структуру file_operations , доступ к которым проходит через слой VFS.


VFS — это «слой оболочки» между системными вызовами и реализациями определенных file_operations , таких как ext4 и procfs . Функции file_operations могут взаимодействовать либо с драйверами устройств, либо с устройствами доступа к памяти. tmpfs , devtmpfs и cgroups не используют file_operations , а напрямую обращаются к памяти.
Существование VFS обеспечивает возможность переиспользовать код, так как основные методы, связанные с файловыми системами, не должны быть повторно реализованы каждым типом файловой системы. Переиспользование кода – широкоприменяемая практика программных инженеров! Однако, если повторно используемый код содержит серьезные ошибки, от них страдают все реализации, которые наследуют общие методы.

/tmp: Простая подсказка

Простой способ обнаружить, что VFS присутствуют в системе – это ввести mount | grep -v sd | grep -v :/ , что покажет все смонтированные ( mounted ) файловые системы, которые не являются резидентами на диске и не NFS, что справедливо на большинстве компьютеров. Одним из перечисленных маунтов ( mounts ) VFS, несомненно, будет /tmp , верно?


Все знают, что хранение /tmp на физическом носителе – безумие! Источник.

Почему нежелательно хранить /tmp на физическом носителе? Потому что файлы в /tmp являются временными, а устройства хранения медленнее, чем память, где создается tmpfs. Более того, физические носители более подвержены износу при перезаписи, чем память. Наконец, файлы в /tmp могут содержать конфиденциальную информацию, поэтому их исчезновение при каждой перезагрузке является неотъемлемой функцией.

Помимо /tmp , VFS (виртуальные файловые системы), которые наиболее знакомы пользователям Linux – это /proc и /sys . ( /dev располагается в общей памяти и не имеет file_operations ). Почему именно эти два компонента? Давайте разберемся в этом вопросе.

procfs создает снимок мгновенного состояния ядра и процессов, которые он контролирует для userspace . В /proc ядро выводит информацию о том, какими средствами оно располагает, например, прерывания, виртуальная память и планировщик. Кроме того, /proc/sys – это место, где параметры, настраиваемые с помощью команды sysctl , доступны для userspace . Статус и статистика отдельных процессов выводится в каталогах /proc/ .


Здесь /proc/meminfo — это пустой файл, который тем не менее содержит ценную информацию.

Поведение /proc файлов показывает, какими непохожими могут быть дисковые файловые системы VFS. С одной стороны, /proc/meminfo содержат информацию, которую можно посмотреть командой free . С другой же, там пусто! Как так получается? Ситуация напоминает знаменитую статью под названием «Существует ли луна, когда на нее никто не смотрит? Реальность и квантовая теория», написанную профессором физики Корнельского университета Дэвидом Мермином в 1985 году. Дело в том, что ядро собирает статистику памяти, когда происходит запрос к /proc , и на самом деле в файлах /proc ничего нет, когда никто туда не смотрит. Как сказал Мермин, «Фундаментальная квантовая доктрина гласит, что измерение, как правило, не выявляет ранее существовавшего значения измеряемого свойства.» (А над вопросом про луну подумайте в качестве домашнего задания!)
Кажущаяся пустота procfs имеет смысл, поскольку располагающаяся там информация динамична. Немного другая ситуация с sysfs . Давайте сравним, сколько файлов размером не менее одного байта есть в /proc и в /sys .


Procfs имеет один файл, а именно экспортированную конфигурацию ядра, которая является исключением, поскольку ее нужно генерировать только один раз за загрузку. С другой стороны, в /sys лежит множество более объемных файлов, многие из которых занимают целую страницу памяти. Обычно файлы sysfs содержат ровно одно число или строку, в отличие от таблиц информации, получаемой при чтении таких файлов, как /proc/meminfo .

Цель sysfs – предоставить свойства доступные для чтения и записи того, что ядро называет «kobjects» в userspace. Единственная цель kobjects – это подсчет ссылок: когда удаляется последняя ссылка на kobject, система восстановит ресурсы, связанные с ним. Тем не менее, /sys составляет большую часть знаменитого «stable ABI для userspace» ядра, которое никто никогда, ни при каких обстоятельствах не может «сломать». Это не означает, что файлы в sysfs статичны, что противоречило бы подсчету ссылок на нестабильные объекты.
Стабильный двоичный интерфейс приложений ядра (kernel's stable ABI) ограничивает то, что может появиться в /sys , а не то, что на самом деле присутствует в данный конкретный момент. Листинг разрешений на файлы в sysfs обеспечивает понимание того, как конфигурируемые параметры устройств, модулей, файловых систем и т.д. могут быть настроены или прочитаны. Делаем логический вывод, что procfs также является частью stable ABI ядра, хотя это не указано явно в документации.


Файлы в sysfs описывают одно конкретное свойство для каждой сущности и могут быть читаемыми, перезаписываемыми или и то и другое сразу. «0» в файле говорит о том, что SSD не может быть удален.

Вторую часть перевода начнем с того, как наблюдать за VFS с помощью инструментов eBPF и bcc, а сейчас ждем ваши комментарии и традиционно приглашаем на открытый вебинар, который уже 9 апреля проведет наш преподаватель — Владимир Дроздецкий.

В этой серии постов мы внимательно рассмотрим один из главных ингредиентов в контейнере – namespaces. В процессе мы создадим более простой клон команды docker run – нашу собственную программу, которая будет принимать на входе команду (вместе с её аргументами, если таковые имеются) и разворачивать контейнер для её выполнения, изолированный от остальной системы, подобно тому, как вы бы выполнили docker run для запуска из образа.

Что такое namespace?

Linux namespace – это абстракция над ресурсами в операционной системе. Мы можем думать об namespace, как о ящике. В этом ящике находятся системные ресурсы, которые точно зависят от типа ящика (namespace). В настоящее время существует семь типов пространств имён (namespaces): Cgroups, IPC, Network, Mount, PID, User, UTS.

Например, Network namespace включает в себя системные ресурсы, связанные с сетью, такие как сетевые интерфейсы (например, wlan0 , eth0 ), таблицы маршрутизации и т.д., Mount namespace включает файлы и каталоги в системе, PID содержит ID процессов и так далее. Таким образом, два экземпляра Network namespace A и B (соответствующие двум ящикам одного типа в нашей аналогии) могут содержать различные ресурсы – возможно, A содержит wlan0 , тогда как B содержит eth0 и отдельную копию таблицы маршрутизации.

Пространства имён (namespaces) – не какая-то дополнительная фича или библиотека, которую вам нужно установить, например, с помощью пакетного менеджера apt. Они предоставляются самим ядром Linux и уже являются необходимостью для запуска любого процесса в системе. В любой данный момент времени любой процесс P принадлежит ровно одному экземпляру namespace каждого типа. Поэтому, когда ему требуется сказать «обнови таблицу маршрутизации в системе», Linux показывает ему копию таблицы маршрутизации namespace, к которому он принадлежит в этот момент.

Для чего это нужно?

Абсолютно ни для чег… конечно, я просто пошутил. Одним их замечательных свойств ящиков является то, что вы можете добавлять и удалять вещи из ящика и это никак не повлияет на содержимое других ящиков. Тут та же идея с namespaces – процесс P может «сойти с ума» и выполнить sudo rm –rf / , но другой процесс Q, принадлежащий другому Mount namespace, не будет затронут, поскольку они они используют отдельные копии этих файлов.

Обратите внимание, что содержащийся в namespace ресурс не обязательно представляет собой уникальную копию. В ряде случаев, возникших намеренно или ввиду бреши в безопасности, два и более namespaces будут содержать одну и ту же копию, например одного и того же файла. Таким образом, изменения, внесенные в этот файл в одном Mount namespace, фактически будут видны во всех других Mount namespaces, которые также ссылаются на него. Поэтому мы тут откажемся от нашей аналогии с ящиком, поскольку предмет не может одновременно находиться в двух разных ящиках.

Ограничение — это забота

Мы можем видеть namespaces, которым принадлежит процесс! Типичным для Linux образом они отображаются как файлы в каталоге /proc/$pid/ns данного процесса с process id $pid :

Вы можете открыть другой терминал, выполнить ту же команду и это должно дать вам тот же результат. Это потому, что как мы упоминали ранее, процесс обязательно должен принадлежать некоторому пространству имён (namespace) и до тех пор, пока мы мы явно не зададим к какому, Linux добавляет его в namespaces по умолчанию.

Давайте немного вмешаемся в это. Во втором терминале мы можем выполнить что-то вроде этого:

Команда unshare запускает программу (опционально) в новом namespace. Флаг -u говорит ей запустить bash в новом UTS namespace. Обратите внимание, что наш новый процесс bash указывает на другой файл uts , тогда как все остальные остаются прежними.

Создание новых namespaces обычно требует доступа с правами суперпользователя. Здесь и далее мы будем считать, что как unshare , так и наша реализация выполняются с помощью sudo .

Одним из следствий того, что мы только что проделали, является то, что теперь мы можем изменить системный hostname из нашего нового процесса bash и это не повлияет ни на какой другой процесс в системе. Вы можете проверить это, выполнив hostname в первом терминале и увидев, что имя хоста там не изменилось.

Но что, например, такое контейнер?

Надеюсь, теперь у вас есть некоторое представление о том, что может делать namespace. Вы можете предположить, что контейнеры по своей сути — обыкновенные процессы с отличающимися от других процессов namespaces, и вы будете правы. Фактически это квота. Контейнер без квот не обязан принадлежать уникальному namespace каждого типа — он может совместно использовать некоторые из них.

Например, когда вы набираете docker run --net=host redis , всё, что вы делаете — говорите докеру не создавать новый Network namespace для процесса redis. И, как мы видели, Linux добавит этот процесс участником дефолтного Network namespace, как и любой другой обычный процесс. Таким образом, с точи зрения сети процесс redis точно такой же, как и все остальные. Это возможность настройки не только сети, docker run позволяет вам делать такие изменения для большей части существующих namespaces. Тут возникает вопрос, что же такое контейнер? Остаётся ли контейнером процесс, использующий все, кроме одного, общие namespace? ¯\_(ツ)_/¯ Обычно контейнеры идут вместе с понятием изоляции, достигаемой через namespaces: чем меньше количество namespaces и ресурсов, которые процесс делит с остальными, тем более он изолирован и это всё, что действительно имеет значение.

Изолирование

В оставшейся части этого поста мы заложим основу для нашей программы, которую назовём isolate . isolate принимает команду в качестве аргументов и запускает её в новом процессе, изолированном от остальной системы и в ограниченном собственными namespaces. В следующих постах мы рассмотрим добавление поддержки отдельных namespaces для команды процесса, запускаемого isolate .

В зависимости от области применения, мы сфокусируемся на User, Mount, PID и Network namespaces. Остальные же будут относительно тривиальны для реализации после того, как мы закончим (фактически, мы добавим поддержку UTS здесь в первичной реализации программы). А рассмотрение, например, Cgroups, выходит за рамки этой серии (изучение cgroups — другого компонента контейнеров, используемого для управления тем, сколько ресурсов может использовать процесс).

Пространства имён могут очень быстро оказаться сложными и есть много разных путей, которыми можно воспользоваться при изучении каждого namespace, но мы не можем выбрать их все разом. Мы будем обсуждать только те пути, которые имеют отношение к разрабатываемой нами программе. Каждый пост будет начинаться с некоторых экспериментов в консоли над рассматриваемым namespace с целью разобраться с действиями, требуемыми для настройки этого namespace. В результате у нас уже будет представление о том, чего мы хотим достичь, а затем последует и соответствующая реализация в isolate .

Чтобы избежать перегрузки постов кодом, мы не будем включать такие вещи, как вспомогательные функции, не являющиеся необходимыми для понимания реализации. Вы можете найти полный исходный код здесь на Github.

Реализация

Исходный код для этого поста можно найти здесь. Наша реализация isolate будет простой программой, которая считывает строку с командой из stdin и клонирует новый процесс, выполняющий её с указанными аргументами. Клонированный процесс с командой будет выполняться в собственном UTS namespace точно также, как мы делали это ранее с unshare . В следующих постах мы увидим, что namespaces не обязательно работают (или хотя бы обеспечивают изоляцию) из коробки и нам нужно будет выполнить некоторую настройку после их создания (но перед реальным запуском команды), чтобы команда действительно выполнялась изолированной.

Эта комбинация создания-настройки namespace потребует некоторого взаимодействия между основным процессом isolate и дочерним процессом запускаемой команды. В результате часть основной работы здесь будет заключаться в настройке связующего канала между обоими процессами — в нашем случае мы будем использовать Linux pipe из-за его простоты.

Нам нужно сделать три вещи:

  1. Создать основной процесс isolate , читающий данные из stdin.
  2. Клонировать новый процесс, который будет запускать команду в новом UTS namespace.
  3. Настроить пайп таким образом, чтобы процесс выполнения команды начинал её запуск только после получения сигнала от основного процесса о завершении настройки namespace.

Вот основной процесс:

Обратите внимание на clone_flags , которые мы передаем в наш вызов clone . Видите, как просто создать процесс в его собственном namespace? Всё, что нам нужно сделать, это установить флаг для типа namespace ( CLONE_NEWUTS флаг соответствует UTS namespace), а Linux позаботится об остальном.

Далее процесс команды ожидает сигнала перед её запуском:

Наконец, мы может попробовать это запустить:

Сейчас isolate — это немногим больше, чем программа, которая просто форкает команду (у нас есть UTS, работающий для нас). В следующем посте мы сделаем еще один шаг, рассмотрев User namespaces заставим isolate выполнять команду в собственном User namespace. Там мы увидим, что на самом деле надо проделать некоторую работу, чтобы иметь пригодный к использованию namespace, в котором может выполняться команда.

Greg Kroah-Hartman предложил документировать kernelspace <-> userspace ABI для каждого ядра, даже если эти механизмы взаимодействия часто меняются. Для этого предложено описывать их в stable, unstable, testing и т.п. директориях в Documentation/.

По словам Грега, именно благодаря тому, что Linux динамически развивающаяся система, эта ОС и захватывает практически весь компьютерный мир от телефонов до суперкомпьютеров. И именно механизмы взаимодействия компонентов, меняющиеся и изменяющиеся согласно нуждам пользователей и разработчиков, позволяют ей быть таковой.

В целом идея воспринята весьма позитивно, хотя дискуссия все еще ведется.


вы им скажите чтоб по русски сразу писали, а не на своем буржуинском, а то чтож потом 1/6 части суши мучаться с переводом :)


Не надо на русском, вы чего?! Сейчас большинство ЛОРа вас камнями закидают и заставить учить великий и могучий английский :) И будут доказывать, что без знания оного вы никто и звать вас - никак :)

Доминировать будет тот язык, за которым технологический прогресс. (И ещё тот, у которых денег больше, вот. :))

Привет от братьев китайцев ;-)

не допустим к доке лоббистов от 1C ! :-)

китайцы нам такие же братья как крысы или тараканы

Это правильная идея. Может быть благодаря этому линукс и перерастёт во что-нибудь модульное (модульное употреблено в контексте "не монолитное").

> Сейчас большинство ЛОРа вас камнями закидают и заставить учить великий и могучий английский :) И будут доказывать, что без знания оного вы никто и звать вас - никак

Любой человек должен знать два или более языков. В случе IT специалиста знание английского обязательно. Какие могут быть возражения?

>Любой человек должен знать два или более языков. В случе >IT специалиста знание английского обязательно. >Какие могут быть возражения?

Угу, а еще он должен быть добрым, мудрым, и красивым. Непонятно только кому должен.

> Greg Kroah-Hartman предложил документировать kernelspace <-> userspace ABI для каждого ядра, даже если эти механизмы взаимодействия часто меняются. Для этого предложено описывать их в stable, unstable, testing и т.п. директориях в Documentation/.

Хто у нас там звиздел в том самом Documentation(Documentation/stable_api_nonsense.txt) про суперстабильный kernelspace <-> userspace ABI?

The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.

> китайцы нам такие же братья как крысы или тараканы

Вот-вот, и я о том же.

>>Greg Kroah-Hartman предложил документировать kernelspace <-> userspace ABI для каждого ядра, даже если эти механизмы взаимодействия часто меняются. Для этого предложено описывать их в stable, unstable, testing и т.п. директориях в Documentation/.

>Хто у нас там звиздел в том самом Documentation(Documentation/stable_api_nonsense.txt) про суперстабильный kernelspace <-> userspace ABI?

>The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.

Он абсолютно прав: то, что стало стабильным, больше уже никогда не меняется, и примером тому являются syscall. Более того, то, что однажды экспортировано в userspace, уже никогда не меняется, только расширяется с обратной совместимостью, что зачастую опять-таки не документируется.

Новые протоколы, например WE over netlink, wconf, sysfs users и т.п. не документированы, и используются каждым так, как он того хочет.

Грег же предлагает, чтобы это документировалось в обязательном порядке.

> Он абсолютно прав: то, что стало стабильным, больше уже никогда не меняется

Как можно использовать kernel <-> userspace ABI, если оно не экспортировано в юзерспейс? :) Соответсвенно или ABI стабильное или оно нестабильное, третьего не дано, поскольку ABI не может быть частично беременным. Так кто врет - тот кто написал stable_api_nonsense.txt или Грэг?

>>Любой человек должен знать два или более языков. В случе >IT специалиста знание английского обязательно. >Какие могут быть возражения?

>Угу, а еще он должен быть добрым, мудрым, и красивым. Непонятно только кому должен.

Прежде всего себе.

>> Он абсолютно прав: то, что стало стабильным, больше уже никогда не меняется

> Как можно использовать kernel <-> userspace ABI, если оно не экспортировано в юзерспейс? :) Соответсвенно или ABI стабильное или оно нестабильное, третьего не дано, поскольку ABI не может быть частично беременным.

А теперь начинаем думать.

В ядре создается новый драйвер, который экспортирует некие данные используя sysfs. Драйвер принят в ядро, механизм экспорта передан в userspace, точка поставлена. Драйвер со временем поменялся, и теперь он может передавать данные, используя как старый механизм через sysfs, так и новый, например через netlink. Стабильности здесь, как видишь, нет, но первый интерфейс уже никогда не поменяется.

Или другой вариант из настоящей жизни. Много лет назад был создан WE - wireless extensions via ioctl, все работает как надо. Но со временем wifi эволюционировал, и были добавлены новые версии WE, а со временем появился WE over netlink, причем все версии обратно совместимы друг с другом. Но _стабильного_ WE в целом, т.е. такого, который не меняется, нет и не может быть. Есть стабильные версии с обратной совместимостью, но сам протокол развивается дальше.

Или еще один пример. Для конфигурации wifi стека был написан протокол wconf, с которым работали softmac based карточки, но потом пришел devicescape стек, и протокол был расширен, чтобы поддерживать и новые карточки. Стабильности в том плане, что все заморожено и не развивается, нет. Но есть строгие правила, которых придерживается kernelspace.

>Так кто врет - тот кто написал stable_api_nonsense.txt или Грэг?

Это один и тот же человек.

> И именно механизмы взаимодействия компонентов, меняющиеся и изменяющиеся согласно нуждам пользователей и разработчиков, позволяют ей быть таковой.

Что-то мне подсказывает, что нужды пользователей предпочитают один раз поставить дрова и не дергаться при очередном пуке очередного Васи Пупкина.

Пока не будет стабильного ABI на достаточно долгий срок, мы так и будем пользовать недоделанные дрова, которые нужно будет пересобирать при каждом патче. Производителям железа неинтересно поддерживать сотню с лишним дистрибутивов, в которых десяток разных ядер - релизы и апдейты.

>> И именно механизмы взаимодействия компонентов, меняющиеся и изменяющиеся согласно нуждам пользователей и разработчиков, позволяют ей быть таковой.

>Что-то мне подсказывает, что нужды пользователей предпочитают один раз поставить дрова и не дергаться при очередном пуке очередного Васи Пупкина.

>Пока не будет стабильного ABI на достаточно долгий срок, мы так и будем пользовать недоделанные дрова, которые нужно будет пересобирать при каждом патче. Производителям железа неинтересно поддерживать сотню с лишним дистрибутивов, в которых десяток разных ядер - релизы и апдейты.

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

Все технически грамотные компании так и делают и прибыль не теряют.

NVidia и ATI очень ограничены лицензионными соглашениями с авторами прошивок GPU и т.п.

> Все технически грамотные компании так и делают и прибыль не теряют.

Угу. Adaptec - грамотная компания ? Её дровишки под определенное железо входят в состав ядра. Правда, работают они. не дай боже еще раз мне с этой железякой под линухом столкнуться.

PS. Никто не знает железо лучше, чем его разработчики.

>> Все технически грамотные компании так и делают и прибыль не теряют.

>Угу. Adaptec - грамотная компания ? Её дровишки под определенное железо входят в состав ядра. Правда, работают они. не дай боже еще раз мне с этой железякой под линухом столкнуться.

Кривое железо бывает у всех.

>PS. Никто не знает железо лучше, чем его разработчики.

Да, NVidia с ее чипсетом nforce - тоже все было закрыто, а сейчас и в сетевые и в sata драйвера патчи шлют,и даже просят, чтобы включили, т.к. понимают, что есть Linux и кто за ним стоит.

Broadcom - никогда никому спеки не давал, а теперь с удовольствием сетевые драйвера помогает делать на nextreme и tigon чипсетах.

Те, кто не открывает спецификации в конечном итоге проигрывает, т.к. всегда находится открытая альтернатива.


>Что-то мне подсказывает, что нужды пользователей предпочитают один раз поставить дрова и не дергаться при очередном пуке очередного Васи Пупкина. >мы так и будем пользовать недоделанные дрова, которые нужно будет пересобирать при каждом патче

а зачем вы ставите драйвера ручками и сидите на суперпоследней версии ядра?

> Кривое железо бывает у всех.

Это кривое железо отлично живет на оффтопике.

> а зачем вы ставите драйвера ручками и сидите на суперпоследней версии ядра?

Во-первых, как же мне быть, если дров для ядра моего дистрибутива нету ? У меня не FC, не RH, не SuSE и не RF.

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

Читайте также: