Created attachment 988 [details]
/etc/fstab.d reading

Известно, что /etc/fstab напрямую читается в kdelibs? и glibc  

Угу, в kdelibs за это отвечает kdecore/kmountpoint.cpp. Можно попробовать
переписать этот код для поддрежки /etc/fstab.d

А в glibc - misc/fstab.c 
Возникла идея заменить соответствующие части кода, дублирующие 
функциональность из glibc, на вызов функций из glibc. 

Для надежности было бы неплохо распаковать исходники все wm и их аплетов...
И поискать еще вхождения /etc/fstab для того, чтобы представить себе объем работ...

Вы предлагаете изменить getfsent(3), или ограничиться утилитой mount(8)?

Вообще, плохо, конечно, что так много софта реализуют свой собственный
getfsent(8), надо бы такие программы обвешать багами.

Предлагаю: 
- изменить getfsent (как это уже сделано для mount) 
- обнаружить и развесить баги на программы, которые читают /etc/fstab 
самобытно 
- написать для вышеозначенных программ патчи с тем, чтобы они использовали 
getfsent 
Не знаю, насколько данная задача для вас приоритетна; если данный план 
разумен, то я мог бы поручить это одному из разработчиков @etersoft 
 

Не стану утверждать, что эта задача для меня приоритетна.
План действий выглядит логично.
Убедить glibc'шный upstream в необходимости расширения функциональности getfsent
будет очень сложно.  Впрочем, этот факт не является препятствием.

После детельного изучения kdelibs с него снимаются все обвинения - используется
getmntent из glibc

> После детельного изучения kdelibs с него снимаются все обвинения - используется
> getmntent из glibc

Но это добавляет проблемы, если getfsent пропатчить на предмет /etc/fstab.d
как два байта переслать, то интерфейс getmntent и так ориентирован на множество
файлов и унесен на уровень конечного приложения, т.е. придется перелопачивать
весь софт для поиска getmntent и патчить, патчить и еще раз патчить.

Ага, начиная с coreutils и заканчивая несколькими сотнями аплетов для
разнообразных WM...

Стоит ли овчинка выделки?

Я считаю что стоит и по возможности буду участвовать в приведении программ к 
использованию библиотечной функции из glibc. 

(In reply to comment #12)
> Я считаю что стоит и по возможности буду участвовать в приведении программ к 
> использованию библиотечной функции из glibc. 

Какой именно, getfsent или getmntent? getfsent обсолитнули и суперсиднули
getmntent. А обвязка вокруг getmntent для поддержки /etc/fstab.d будет выглядеть
байт в байт как текущий getfsent с трехстрочным патчем.

fstab.d - это серьезно. Это надо апстрим убеждать соглажаться :-) 

IMHO нехорошо, что getmntent предполагает, что "/etc/fstab" и "/etc/mtab" (? "/
proc/mounts") зашиты в приложениях как константы. Нет функций, их возвращающих.

Если сделать функции, возвращающие список файлов fstab(/etc/fstab и /etc/fstab.
d) и список файлов mtab (пока один единств.) - то вполне можно реализовать 
getfsent через getmntent + один список.
И аналогично сделать getmfsent (mounted fs).

И вот это все проталкивать в upstream.

Делать обвязку для getmntent, чтобы ей указывали на один файл, а она читала из 
другого - это жуть IMHO.

....а нельзя сделать что-то типа shadow ?
Чтобы /etc/fstab был сокетом, за который отвечал бы демон.
А демон бы рабивал fstab на постоянную часть и fstab.d ?
Правда это уже по сложности что-то типа CVS получается  

Поскольку выбранным направлением стали новые методы автомонтирования, и 
изменение /etc/fstab более не требуется,
и риску порчи он более не подвержен, закрываю.