Gentoo Linux сборник статей



Pdf просмотр
страница57/79
Дата14.11.2016
Размер5.55 Mb.
Просмотров11398
Скачиваний1
1   ...   53   54   55   56   57   58   59   60   ...   79
Листинг 1.1: Исследование информации о файле устройства
# ls -l /dev/hda
brw-rw---- 1 root disk 3, 0 Jul 5 2000 /dev/hda
В предыдущем примере мы увидели, что /dev/hda — это блочное устройство.
Однако важнее то, что ему присвоено два специальных номера 3, 0. Эта пара называется major-minor. Она используется ядром, чтобы соотнести файл устройства и реальное устройство. major (старший) относится к типу устройства, minor (младший) к конкретному устройству. Выглядит запутано, не правда ли?
Ещё два примера — /dev/hda4 и /dev/tty5. Первое устройство соответствует четвёртому разделу на первом IDE-устройстве. Его пара major-minor 3, 4. Другими словами, minor соответствует разделу, тогда как major соответствует устройству.
Во втором примере пара major-minor — 4, 5. В этом случае первое число соответствует драйверу терминала, тогда как второе соответствует номеру терминала (в данном случае пятый терминал).
676

Руководство по файловой системе для устройств
Проблемы
Если вы заглядывали в папку /dev, вы обнаружили, что там перечислены не только все ваши устройства, но и все возможные устройства, которые только могут быть. Другими словами, у вас есть файлы устройств для устройств, которых у вас нет. Управление такой кучей устройств по крайней мере можно назвать громоздким. Представьте, что надо поменять права на все устройства, реально существующие в вашей системе, оставив остальные без изменений.
Затем вы добавили новое оборудование в вашу систему, для него может не оказаться уже существующего файла. Продвинутые пользователи знают, что эта задача может быть выполнена с помощью команды ./MAKEDEV внутри директории /dev, но разве вы сразу знаете, что за устройство вам придётся создать?
Когда у вас есть программы, взаимодействующие с оборудованием при помощи файлов устройств, вы не можете смонтировать корневой раздел только для чтения, в то время как в дальнейшем нет необходимости в том, чтобы он был смонтирован на чтение и запись. И вы не можете иметь /dev на отдельном разделе, так как mount необходим, /dev чтобы монтировать разделы.
Решения
Как вы могли себе представить, kernel hackers нашли достаточно решений для вышеперечисленных проблем. Однако многие из этих решений имеют собственные проблемы описанные в http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#faq-why. Мы не будем обсуждать эти варианты, а сконцентрируемся на одном способе, который был реализован в официальной версии исходников ядра:
devfs как абсолютный победитель?
devfs решает все перечисленные проблемы. Она просто предоставляет пользователю доступ к существующим устройствам, добавляет новые device nodes (файлы устройств), когда найдены новые устройства, и делает возможным монтировать корневую файловую систему в режиме read only (только чтение). А также решает многие проблемы, которые мы раньше не обсуждали, потому что они не так интересны для пользователей...
Как пример, с devfs вам не надо беспокоится о паре major/minor. Она продолжат поддерживаться (для обратной совместимости), но в ней нет необходимости. Это позволяет Linux поддерживать ещё больше устройств, так как больше нет
677

Руководство по файловой системе для устройств ограничений (числа всегда имеют границы :)
Однако у devfs есть свои проблемы, не столь очевидные для пользователей, но достаточно серьезные, чтобы разработчики ядра пометили ее как obsolete
(устаревшее), порекомендовав использовать udev, которая также поддерживается
Gentoo.
Чтобы узнать, почему devfs считается устаревшей, читайте udev FAQ и udev versus devfs document.
2. Навигация через дерево устройств
Директории
Одна из первых особенностей которые вы можете заметить это то что devfs использует директории для объединения устройств вместе. Это повышает читабельность, так как теперь все связанные между собой устройства находятся внутри одной общей директории.
Например, все устройства, относящиеся к IDE, находятся в директории /dev/ide/, а все относящиеся к SCSI в директории /dev/scsi/. SCSI и IDE диски во многом похожи, у них одинаковая структура поддиректорий.
IDE и SCSI диски управляются при помощи адаптера (встроенного или отдельной платой), называемого host. Каждый адаптер может иметь несколько каналов.
Канал называется bus. На каждом канале может быть несколько IDs
(идентификаторов). ID служит для идентификации диска. Этот ID называется target. Многие SCSI устройства могут иметь множество LUN (Logical Unit Numbers
(Номер Логического Устройства)), Например устройства которые управляют несколькими носителями одновременно (hi-end tapedrives). У вас скорее всего будет только один lun, lun0/.
Итак, несмотря на то, что раньше использовался /dev/hda4, теперь появился
/dev/ide/host0/bus0/target0/lun0/part4. Это намного проще... нет, не спорьте со мной... это проще... как бы то ни было! :)
Примечание: Вы также можете использовать более похожие на Unix названия для жёстких дисков, такие как c0b0t0u0p2. Они могут быть найдены в /dev/ide/hd,
/dev/scsi/hd и.т.д.
Чтобы дать вам лучше понять идею с директориями, вот листинг директорий которые есть у меня:
Листинг 2.1: Дирректории в /dev cdroms/ cpu/ discs/ floppy/
ide/ input/ loop/ misc/
netlink/ printers/ pts/ pty/
scsi/ sg/ shm/ sound/
sr/ usb/ vc/ vcc/
678

Руководство по файловой системе для устройств
Обратная совместимость при помoщи devfsd
Использование этой новой структуры выглядит здорово, но многие утилиты и программы используют предыдущую, старую структуру. Для уверенности, что система не будет нарушена, был создан devfsd. Этот демон создаёт символьные ссылки на новые файлы устройств, но со старыми именами (compatibility symlinks).
Листинг 2.2: Созданные символьные ссылки
$ ls -l /dev/hda4
lr-xr-xr-x 1 root root 33 Aug 25 12:08 /dev/hda4 -> ide/host0/bus0/target0/lun0/part4
При помощи devfsd, вы можете устанавливать права доступа, создавать новые файлы устройств и т.д. Всё это описывается в следующей главе.
3. Администрирование дерева устройств
Перезагрузка devfsd
Если вы изменили файл /etc/devfsd.conf, и хотите чтобы изменения вступили в силу, вым не обязательно перезагружаться. В зависимости от того, что вы хотите, вы можете использовать любой из следующих сигналов:
SIGHUP заставит devfsd перечитать конфигурационный файл, перегрузить разделяемые объекты (shared objects) и сгенерировать событие REGISTER для каждого листа в дереве устройств.
SIGUSR1 сделает то же самое, но не будет событий REGISTER.
Чтобы послать сигнал, просто используйте kill или killall:
Листинг 3.1: Посылка сигнала SIGHUP демону devfsd
# kill -s SIGHUP `pidof devfsd`
или
# killall -s SIGHUP devfsd
Удаление compatibility symlinks
Предупреждение: В настоящее время Gentoo не может существовать без этих ссылок.
679

Руководство по файловой системе для устройств
Если вы хотите удалить из вашей системы ссылки которые засоряют /dev (в
Gentoo они используются по умолчанию), отредактируйте /etc/devfsd.conf и удалите следующие две строчки:
Листинг 3.2: /etc/devfsd.conf для обратной совместимости
# Закоментируйте эти две строчки для удаления симлинков
REGISTER .* MKOLDCOMPAT
UNREGISTER .* RMOLDCOMPAT
Вам придётся перезагрузится, чтобы изменения вступили в силу.
Удаление возможности автосоздания файлов устройств
Когда вы загружаете модуль, devfs автоматически создаёт файлы устройств. Если вы не хотите, чтобы он так делал, удалите эту строчку из /etc/devfsd.conf:
Листинг 3.3: /etc/devfsd.conf, autoload functionality
LOOKUP .* MODLOAD
4. Вопросы, относящиеся к правам доступа
Установка/изменение прав доступа при помощи PAM
Хотя вы можете установить права доступа в /etc/devfsd.conf, мы советуем использовать PAM (Pluggable Authentification Modules (). Так как PAM имеет решающий голос при установке прав доступа, и может проигнорировать изменения, которые вы сделали в /etc/devfsd.conf.
PAM использует /etc/security/console.perms для установки прав доступа. Файл состоит из двух частей: в первой описываются группы, а во второй права.
Давайте сначала взглянем на часть с группами. Как пример мы рассмотрим sound- group:
Листинг 4.1: Sound group в /etc/security/console.perms
=/dev/dsp* /dev/audio* /dev/midi* \
/dev/mixer* /dev/sequencer* \
/dev/sound/* /dev/snd/* /dev/beep \
/dev/admm* \
/dev/adsp* /dev/aload* /dev/amidi* /dev/dmfm* \
/dev/dmmidi* /dev/sndstat
680

Руководство по файловой системе для устройств
Синтаксис достаточно прост: вы начинаете с имени группы, и заканчиваете списком устройств, принадлежащих этой группе.
Теперь для того, чтобы с группами можно было что-нибудь сделать, рассмотрим следующую часть, описывающую, как управлять правами.
Листинг 4.2: Права доступа для sound group в /etc/security/console.perms
0600 0600 root.audio

Первое поле — это проверка терминала. На большинстве систем это console-group. PAM будет проверять это поле при каждом входе в систему.
Если вход произошёл на устройстве, содержащемся в console-group, PAM проверит и возможно сменит права на некоторые файлы устройств.

Второе поле содержит права, которые установятся на файл устройства после удачного входа в систему. Когда человек вошел в систему, а файлы устройств принадлежат пользователю и группе по умолчанию, PAM сменит владельца на вошедшего пользователя и установит на них права из второго поля. В данном случае используется 0600 (пользователь имеет право на чтение/запись, все остальные нет).

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

Четвёртое поле определяет права, которые будут установлены на файлы устройств после возврата в состояние по умолчанию. Другими словами, если человек, который владеет правами на все файлы устройств, выйдет из системы, PAM установит права обратно в состояние по умолчанию, описанному в этом четвёртом поле.

Пятое поле определяет собственника (с группой если вам надо) к которому будут установлены атрибуты устройства после возврата в состояние по умолчанию Другими словами, если человек, владеющий правами на все файлы устройств, выйдет из системы, PAM установит собственника обратно в состояние по умолчанию, описанному в пятом поле.
Установка/изменение прав доступа при помощи devfsd
Если вы действительно хотите установить права, используя /etc/devfsd.conf, тогда используйте синтаксис приведённый в этом примере:
Листинг 4.3: Права в /etc/devfsd.conf
REGISTER ^cdroms/.* PERMISSIONS root.cdrom 0660
Второе поле — это группа устройств, начиная с /dev. Это регулярное выражение, означающее, что вы можете выбрать несколько файлов устройств с одним правилом.
Четвёртое поле — это владелец файла устройства. В отличие от PAM, он не
681

Руководство по файловой системе для устройств изменяется (если он не упоминается в console.perms, так как PAM главнее).
Пятое поле содержит права на файлы устройств.
Ручная установка прав и их сохранение devfsd
Это обычная ситуация для Gentoo: если вы делаете chown (CHange OWNer
(Смена владельца)) и chmod (CHange MODe (Смена вида)) некоторым файлам устройств, то devfsd сохраняют информацию, когда вы вы выключаете систему.
Это происходит из-за того, что файл /etc/devfsd.conf содержит следующие строчки:
Листинг 4.4: /etc/devfsd.conf для сохранения прав доступа
REGISTER ^pt[sy]/.* IGNORE
CHANGE ^pt[sy]/.* IGNORE
CREATE ^pt[sy]/.* IGNORE
DELETE ^pt[sy] IGNORE
REGISTER ^log IGNORE
CHANGE ^log IGNORE
CREATE ^log IGNORE
DELETE ^log IGNORE
REGISTER .* COPY /lib/dev-state/$devname $devpath
CHANGE .* COPY $devpath /lib/dev-state/$devname
CREATE .* COPY $devpath /lib/dev-state/$devname
DELETE .* CFUNCTION GLOBAL unlink
/lib/dev-state/$devname
RESTORE /lib/dev-state
Другими словами, изменённые файлы устройств копируются в /lib/dev-state, когда выключается система, и копируются в /dev, когда система грузится.
Другая возможность - монтировать /lib/dev-state в /dev во время загрузки. Чтобы это сделать, вы должны быть уверены, что devfs не монтируется автоматически
(это значит, что вы должны перекомпилировать ядро), и что /dev/console существует. Затем, где-то в начале bootscripts (загрузочных скриптов) вашей системы, вы должны разместить:
Листинг 4.5: Монтирование /lib/dev-state в /dev mount --bind /dev /lib/dev-state mount -t devfs none /dev devfsd /dev
682

Ebuild HOWTO (Англ.)
Ebuild HOWTO (Англ.)
Ссылка на оригинал:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?
part=2&chap=1
С версии: 1.4
1.a. The Portage tree
Introduction
The Portage tree is typically found at /usr/portage and is organized in a hierarchical structure consisting of category directories, followed by specific package directories.
Here's an example; you can find the util-linux-2.11y.ebuild file in the /usr/portage/sys- apps/util-linux directory. There may be several other versions of util-linux ebuilds alongside util-linux-2.11y.ebuild. This is because all ebuilds for a particular package
(regardless of version), share the same mycat/mypkg directory in /usr/portage.
Checking Out the Portage Tree from CVS
If you are unfamiliar with the CVS system, please read the
CVS Tutorial for more information.
The Portage tree can be found in the gentoo-x86 module of the Gentoo Linux tree. To check out the module (about 350 megabytes) you would first set up CVS via the above guide, then check out the gentoo-x86 module.
What (not) to put in the Portage tree
Before writing a new ebuild, check bugs.gentoo.org to see if an ebuild has already been written for the package, but has not yet been added to the Portage tree. Go to bugs.gentoo.org
, choose query and select Advanced Search; as product select Gentoo
Linux, as component select ebuilds. In the search field put the name of the ebuild and as status select NEW, ASSIGNED, REOPENED and RESOLVED (RESOLVED is important), then submit the query. For you lazy people, click here
In general, the Portage tree should only be used for storing .ebuild files, as well as any relatively small companion files, such as patches or sample configuration files. These types of files should be placed in the /usr/portage/mycat/mypkg/files directory to keep the main mycat/mypkg directory uncluttered. Exceptions to this rule are for larger patch files (we recommend this for patches above 20KB) which should be put onto the Gentoo mirrors so that people do not waste excessive amounts of bandwidth and hard drive space. Also, you should not add binary (non-ASCII) files to the Portage CVS tree. If you need to do this in another CVS tree, for example, if you need to add a small PNG graphic for whatever reason, be sure to add it to CVS by using the -kb option, like so:
Code Listing 1.1: Adding binary files to CVS
# cvs add -kb myphoto.png
The -kb option tells CVS that myphoto.png is a binary file and should be treated
683

Ebuild HOWTO (Англ.)
specially. For example, merging the differences between two different versions of this file should not be allowed to happen, for obvious reasons. Also, speaking of merging changes, any patches you add to Portage should generally not be compressed. This will allow CVS to merge changes and correctly inform developers of conflicts.
Remember, the packages that you commit must be ready out of the box for end users when committed as stable. Make sure that you have a good set of default settings that will satisfy the majority of systems and users that will use your package. If your package is broken, and you are not sure how to get it to work, check some other distributions that have done their own versions of the package. You can check
Mandriva or
Debian or
Fedora for some examples.
When committing to CVS, all developers should use repoman commit instead of cvs commit to submit their ebuilds. Before committing, please run repoman full to make sure you didn't forget something.
CVS Commit Policy

Always run repoman scan before you commit.

Please run repoman full before you commit.

Always test that package.mask is okay by doing emerge --pretend mypkg before you commit and check that it doesn't contain any conflicts.

Always update the ChangeLog before you commit.

Always commit the updated package.mask before the updated package, in case conflicts occur while you commit package.mask.

Always do atomic commits; if you commit a package with a new license, or that is masked, then first commit the revised package.mask and/or license, then commit the ebuild, ChangeLog, patches and metadata.xml all in one go to avoid breaking users' installations.
The files Directory
As noted earlier, under each package subdirectory is a files/ directory. Any patches, configuration files, or other ancillary files your package might require should be added to this directory; any files bigger than 20KB-or-so should go to the mirrors to lower the amount of (unneeded) files our users have to download. You may want to consider naming patches you create yourself just to get your package to build with a version- specific name, such as mypkg-1.0-gentoo.diff, or more simply, 1.0-gentoo.diff. Also note that the gentoo extension informs people that this patch was created by us, the Gentoo
Linux developers, rather than having been grabbed from a mailing list or somewhere else. Again, you should not compress these patches because CVS does not play well with binary files.
Consider prefixing or suffixing (such as mypkg-1.0) every file you put into the files/ directory, so that the files used for each individual version on an ebuild are distinguishable from one another, and so that the changes between different revisions are visible. This is generally a really good idea :). You may want to use a different suffix if you wish to convey more meaning with the patch name.
If you have many files that should go into the files/ directory, consider creating subdirectories such as files/1.0/ and putting the relevant files in the appropriate subdirectory. If you use this method, you do not need to add version information to the names of the files, which is often more convenient.
684

Ebuild HOWTO (Англ.)
1.b. Ebuild scripts
Introduction
Ebuild scripts are the basis for the entire portage system. They contain all the information required to download, unpack, compile and install a set of sources, as well as how to perform any optional pre/post install/removal or configuration steps. While most of Portage is written in Python, the ebuild scripts themselves are written in bash, since using bash allows us to call commands as we would from the command-line. One of the important design principles behind ebuild scripts is to have the commands therein be analogs of those one would type on the command-line if installing the package manually. For this purpose, using bash syntax is a very good thing.
Ebuild scripts are interpreted by the ebuild and emerge commands. Think of the ebuild command as a low-level building tool. It can build and install a single ebuild, but no more. It will check to see if dependencies are satisfied, but it will not attempt to auto- resolve them. On the other hand emerge is a high level engine for ebuild, and has the ability to auto-merge dependencies if needed, perform pretend merges so that user can see what ebuilds would be merged, and more. Generally, emerge blows ebuild out of the water except in one area. With ebuild, you can incrementally step through the various parts of a package emerge (fetching, unpacking, compiling, installing and merging) one at a time. For developers, this is an invaluable debugging tool, because it allows you to isolate ebuild problems to a specific portion of the ebuild.
Naming ebuild files
Ebuild file names consist of four logical subsections:
pkg-ver{_suf{#}}{-r#}.ebuild
Note: The brackets ({}) delineate optional fields and do not appear in the literal package name. # represents any non-zero positive integer.
The first subsection, pkg, is the package name, which should only contain lowercase letters, the digits 0-9, and any number of single hyphen (-), underscore (_) or plus (+) characters. Examples: util-linux, sysklogd and gtk+. We have some packages in
Portage that don't follow these rules, but your packages should.
The second subsection, ver, is the version of the package, which should normally be same as the version on the main source tarball. The version is normally made up of two or three (or more) numbers separated by periods, such as 1.2 or 4.5.2, and may have a single letter immediately following the last digit; e.g., 1.4b or 2.6h. The package version is joined to the package name with a hyphen. For example: foo-1.0, bar-2.4.6.
Important: If you're thinking of using a trailing letter in your version string, note that the trailing letter should not be used to signify alpha or beta status for the package, since alphas and betas are prereleases and letter revisions are newer versions. This is an important distinction because Portage uses an ebuild's version number to determine if it is newer or older than other packages with the same category and name. It's very important that version numbers faithfully represent the version of the package so that
Portage properly performs its dependency checking duties.
The third subsection, {_suf{#}}, is optional may contain one of these predefined suffixes, listed in least-recent to most-recent order:
Suffix
Meaning
_alpha Alpha release
685

Ebuild HOWTO (Англ.)
_beta Beta release
_pre
Prerelease
_rc
Release candidate
(none) Normal release
_p
Patch level (normally accompanied by trailing integer)
Any of these suffixes may be immediately followed by a non-zero positive integer, e.g., linux-2.4.0_pre10. Assuming identical version parts, the suffixes are ordered as follows
(lower means older): _alpha < _beta < _pre < _rc < (no suffix) < _p.
When comparing identical suffixes with trailing integers, the one with the larger integer will be considered most recent. Example: foo-1.0_alpha4 is more recent than foo-1.0_alpha3.
The fourth subsection of the package name is the Gentoo Linux-specific revision number ({-r#}). This subsection, like the suffix, is also optional. # is a non-zero positive integer; e.g., package-4.5.3-r3.
This revision number is independent of the version of the source tarball and is used to inform people that a new and improved Gentoo Linux revision of a particular package is available. Initial releases of ebuilds must have no revision number; e.g., package-4.5.3 and are considered by Portage to have a revision number of zero. This means that counting goes as follows: 1.0 (initial version), 1.0-r1, 1.0-r2, etc.
If you make non-trivial improvements to an existing ebuild file, you should copy the ebuild file to a new file with the revision number incremented by 1. Remember to always make mentions of your changes in the ChangeLog when you bump a revision and in your CVS commit message; not doing so is against policy.
... and I suppose that we actually have a fifth section of the ebuild name as well -- the
.ebuild extension itself.
Contents of an ebuild file
This section is an introduction to ebuilds. For the full listing of everything possible in an ebuild, there is a manpage which talks about the internal format, variables, and functions in an ebuild script: man 5 ebuild.



Поделитесь с Вашими друзьями:
1   ...   53   54   55   56   57   58   59   60   ...   79


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал