[room] [Comm] Adm... давайте по делу :-/

[Alexei V. Mezin]

Michael Shigorin пишет:

> Алексей, это всё трёп, и даже не в пользу бедных.  Вы в силах
> предложить _конструктивное_ решение ... ?

Запинать апстрим, чтоб они прекратили безобразие, эмоционально описанное как
 > поинтересоваться у этих пиндосов, какого лешего они  изуродовали
 > рекомендованный к применению интерфейс до невозможности сделать
 > в нём неинтрузивные правки для поддержки /etc/fstab.d/.

К сожалению не могу. Но и полностью отказываться от использования 
"наследственного" софта не хочу. И уверен, что не я один.

> Вы ознакомились со ссылками в bugzilla, которые я зачем-то
> специально отыскивал и постил сюда?
Да. И могу кратко резюмировать: в багзилле подумали, и пришли к выводу, 
что не смотря на наличие ПРАВИЛЬНОГО способа работать с fstab, 
собственный велосипед изобретен в таком количестве приложений, что 
патчить их все не хватит ресурса.

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

Предложение для затравки: написать "грязный хак" в виде ядерного модуля, 
перехватывающего обращение к /ets/fstab, и выдающего наружу оригинальный 
fstab + строчки, добавленные в этот виртуальный файл всякими 
fstab-sync-скриптами.

Из плюсов: оригинальный fstab имеет классическое имя и открывается 
только на чтение. В случае сбоя системы, и, например, загрузки в 
runlevel 1, доступ к fstab получается естественным. В процессе штатной 
загрузки все диски монтируются согласно fstab, а потом в виде сервиса 
запускается-загружается наш модуль, и далее уже подменяет содержимое 
fstab. При необходимости исправления оригинального файла, модуль 
выгружается (сервис останавливается).

Из минусов: а не будет ли мешать (тормозить) перехват системного вызова 
нормальной работе системы?