Предлагается внести в mount считывание файлов из /etc/fstab.d, реализованное предлагаемым патчем. Если к нему есть замечания, будем исправлять. Надеюсь, это позволит избежать повторения #5889, #5797, #5635
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 более не требуется, и риску порчи он более не подвержен, закрываю.
