[c, linux] получить список монтированных файловых систем
список примонтированных системmount -l
mount -lнеявно предполагает, что procfs примонтирована в /proc. Тогда и вызывать не нужно.
/etc/mtab ?
/etc/mtab ?кругом враги и / монтирован в ro
Известно, что где-то в системе примонтировано procfs, но не известно точно где, для этого, собственно, и нужно считать список маунтов.так out of curiosity, или точно известно и это реальный вопрос?
так out of curiosity,out of curiosity вопрос и есть. Иллюстрация прекрасного и цельного API линукса
А если нет /lib/ld-linux.so или libc.so, то вообще пиздец, почти ничего не запустится. Вопрос-то в чем? Какие могут быть причины не до конца загрузить ОС, не смонтировав /proc?
EDIT: Чтоб не быть троллем, по делу: рекурсивный обход через getdents+statfs спасут отца русской демократии.
EDIT: Чтоб не быть троллем, по делу: рекурсивный обход через getdents+statfs спасут отца русской демократии.
прок и сисфс давно являются неотъемлемыми частями апи ядра, несогласные могут проследовать в биореактор
он щас этому всему научится, а потом так и будет писать - из чистой обиды на несправедливость жизни
параноик — это навсегда
параноик — это навсегда
прок и сисфс давно являются неотъемлемыми частями апи ядра, несогласные могут проследовать в биореактора точки их монтирования тоже? Почему тогда ядро не монтирует само сисфс и процфс?
Почему есть $PATH $LD_PATH и прочие параметры, и только proc прибит гвоздями?
/proc прибит ровно настолько же насколько /bin
/binкстати, что там есть критичного кроме лодера? И можно ли лодер переназначить каким-нибудь аргументом ядра?
Насколько я помню позиция прошивок и модулей из /lib не важна, их можно перезначать. А о перенсении лодера по другому пути я как-то не задумывался
uups, посмотрел на лоадер, он лежит в /lib, так что /bin вообще ничем не прибит на своё место
ещё апдейт:
At compile time, the path of the dynamic linker that should be used is embedded into the executable's .interp sectionТак что ничего не прибито.
Кроме лоадера, я думаю у тебя еще многие загрузочные скрипты обрадуются, когда не найдут свой любимый /bin/sh.
недоработка, да. Вот положение лодера можно завести в опции компилятора и пересборке мира переехать на новое местоположение. А вот скриптописцы почему-то до ужаса любят /bin/sh и /usr/bin/env и процедуры сборки для скриптов не предусмотрено. А следовало бы.
процедуры сборки для скриптов не предусмотрено. А следовало бы.да, и не забыть про процедуру сборки для процедуры сборки.
sed тебя спасет 
Кстати система сборки скриптов - это не новость. Автомейк же есть, хоть он и используется для вполне конкретного типа скриптов.
Кстати система сборки скриптов - это не новость. Автомейк же есть, хоть он и используется для вполне конкретного типа скриптов.
sed тебя спасетну можно сделать eclass и подключать его автоматически через профайл
Да, и не забыть протестировать сборку кросс-тулчейном, собранным на Motorola 68000, запускаемого на PA-RISC с таргетом DEC Alpha, а то знаем мы эти сказки про портируемость.процедуры сборки для скриптов не предусмотрено. А следовало бы.да, и не забыть про процедуру сборки для процедуры сборки.
statfs(2) и поиск вширь от корня.
/bin/sh и /usr/bin/env и процедуры сборки для скриптов не предусмотрено. А следовало бы.afaik есть стандарт LSB которому нужно следовать, потому что даже единственный файл требуемый ядром (статически собранный /init по-умолчанию) приводит к вызову env и sh
> afaik есть стандарт LSB
LSB такой стандарт, что ему лучше не следовать.
> даже единственный файл требуемый ядром
> (статически собранный /init по-умолчанию) приводит к вызову env и sh
Чё?
---
Q5: а нафига A4?
A5: чтоб сосать.
LSB такой стандарт, что ему лучше не следовать.
> даже единственный файл требуемый ядром
> (статически собранный /init по-умолчанию) приводит к вызову env и sh
Чё?
---
Q5: а нафига A4?
A5: чтоб сосать.
Чё?Это первый бинарник которому ядро передает управление после загрузки. Если не веришь, распакуй свой initramfs и посмотри.
Если не веришь, распакуй свой initramfs и посмотри.это просто такой вот initramfs, он вообще говоря может быть разным. Гугол вон в адроиде, насколько я слыашл, запаковывает всё в один бинарь, включая туда и разрешение зависимостей, для ускорения загрузки
> статически собранный
не обязательно
> /init по-умолчанию
это для initrd, без него так:
if (!run_init_process("/sbin/init") ||
!run_init_process("/etc/init") ||
!run_init_process("/bin/init") ||
!run_init_process("/bin/sh"
> приводит к вызову env и sh
what? ну так то почти все запущенные программы являются потомками того инита
> Это первый бинарник которому ядро передает управление после загрузки
Формально нет. /sbin/modprobe и /sbin/hotplug обычно запускаются раньше.
не обязательно
> /init по-умолчанию
это для initrd, без него так:
if (!run_init_process("/sbin/init") ||
!run_init_process("/etc/init") ||
!run_init_process("/bin/init") ||
!run_init_process("/bin/sh"
> приводит к вызову env и sh
what? ну так то почти все запущенные программы являются потомками того инита
> Это первый бинарник которому ядро передает управление после загрузки
Формально нет. /sbin/modprobe и /sbin/hotplug обычно запускаются раньше.
> Формально нет. /sbin/modprobe и /sbin/hotplug обычно запускаются раньше.
Возможно мы говорим про разные версии ядра, потому что я никогда этого не замечал. Да и как тогда бы загружались системы без модулей?
>> приводит к вызову env и sh
> what? ну так то почти все запущенные программы являются потомками того инита
В окружении initramfs они (env и sh) могут использоваться для подготовки перед запуском init из основной системы. В основной системе обычно init парсит /etc/inittab (я не говорю про systemd) и исполняет указанные в нём файлы (которые обычно являются скриптами).
Суть моих слов в том, что пути к некоторым файлам (например sh и env) это константы, которые не стоит менять, на которые можно рассчитывать и не требовать конфигурации. Кусочек кода ядра это подтверждает.
Возможно мы говорим про разные версии ядра, потому что я никогда этого не замечал. Да и как тогда бы загружались системы без модулей?
>> приводит к вызову env и sh
> what? ну так то почти все запущенные программы являются потомками того инита
В окружении initramfs они (env и sh) могут использоваться для подготовки перед запуском init из основной системы. В основной системе обычно init парсит /etc/inittab (я не говорю про systemd) и исполняет указанные в нём файлы (которые обычно являются скриптами).
Суть моих слов в том, что пути к некоторым файлам (например sh и env) это константы, которые не стоит менять, на которые можно рассчитывать и не требовать конфигурации. Кусочек кода ядра это подтверждает.
> Гугол вон в адроиде, насколько я слыашл, запаковывает всё в один бинарь
Как в busybox, когда все исполняемые файлы это симлинки на один бинарник, а кусок кода который будет исполняться определяется из argv[0] ?
Как в busybox, когда все исполняемые файлы это симлинки на один бинарник, а кусок кода который будет исполняться определяется из argv[0] ?
> Да и как тогда бы загружались системы без модулей?
Линуксоеды иногда такие смешные...
---
"Narrowness of experience leads to narrowness of imagination."
Линуксоеды иногда такие смешные...
---
"Narrowness of experience leads to narrowness of imagination."
> Гугол вон в адроиде, насколько я слыашл, запаковывает всё в один бинарькак я понял он собирает его вместе со всеми параметрами, на этапе компиляции вшивая конфигурацию сервисов
Как в busybox, когда все исполняемые файлы это симлинки на один бинарник, а кусок кода который будет исполняться определяется из argv[0] ?
Оставить комментарий
yroslavasako
Как в линуксе с пользовательскими полномочиями получить список примонтированных систем? Известно, что где-то в системе примонтировано procfs, но не известно точно где, для этого, собственно, и нужно считать список маунтов.Что-то в голову никакого способа умного не приходит, либо модуль к ядру вырисовывается, либо сервис от имени рута (рут может сам примонтировать procfs в темп).