glenux/mfm

Fork 1

Refactoriser le pipeline mount/umount et expliciter les capacités des drivers #60

New issue

Open

opened 2026-04-11 22:06:21 +00:00 by glenux · 0 comments

glenux commented

2026-04-11 22:06:21 +00:00

Owner

Contexte

Le support de kio-fuse introduit dans #58 met en évidence une divergence d architecture entre les drivers de src/models/* et le pipeline commun existant.

Aujourd hui :

GoCryptFSConfig, SshFSConfig et HttpDirFSConfig deleguent largement a GX::Models::Concerns::Base pour mount, mounted?, umount et la preparation du mountpoint.
KioFuseConfig implemente son propre flux, avec montage via DBus, notion de real_mount_point, exposition via symlink, et nettoyage specifique.

Cette divergence complique l uniformisation du comportement, augmente le risque de regressions, et rend les decisions de montage/demontage implicites dans chaque driver.

Problemes observes

1. Les drivers prennent des decisions d execution eux-memes

Le comportement est aujourd hui distribue entre :

src/models/concerns/base.cr
src/models/gocryptfs_config.cr
src/models/sshfs_config.cr
src/models/httpdirfs_config.cr
src/models/kio_fuse_config.cr

KioFuseConfig doit contourner le pipeline standard, ce qui montre que le contrat abstrait actuel est trop pauvre pour exprimer des strategies differentes de montage.

2. Le pipeline de mount/umount n est pas generique

Le pipeline standard suppose implicitement :

un mountpoint reel accessible via @mount_point
une creation du repertoire par Dir.mkdir_p
un demontage via fusermount -u
un check mounted? base sur la sortie de mount

Ces hypotheses ne sont pas universelles. KIO en est le premier contre-exemple explicite.

3. La logique de lien/symlink et de nettoyage est locale a KIO

Dans src/models/kio_fuse_config.cr, les methodes suivantes encapsulent une semantique nouvelle qui n est ni decrite ni partagee :

expose_mount
ensure_mountpoint_available
cleanup_exposed_path
dir_empty?

Cela cree une logique de cycle de vie du mountpoint differente de celle des autres drivers, sans point central de decision.

Proposition

Faire evoluer l architecture pour que :

chaque driver expose explicitement ses capacites et son comportement
le pipeline de montage/demontage soit centralise et aussi generique que possible
la gestion des alias/symlinks et du nettoyage de mountpoint soit centralisee

Direction de conception

A. Introduire un contrat explicite de capacites par driver

Chaque driver devrait declarer, directement ou via une petite structure dediee, des informations telles que :

strategie de montage : process direct, DBus, custom
strategie de demontage : fusermount, DBus, custom
mode de verification mounted? : parsing mount, autre outil, custom
besoin d un mountpoint pre-cree ou non
support d un alias de presentation distinct du point de montage reel

Objectif : sortir les decisions implicites des implementations et les rendre pilotables par un pipeline commun.

B. Centraliser le workflow mount/umount

Introduire un orchestrateur commun qui gere, selon les capacites exposees par le driver :

preparation du mountpoint
execution du montage
post-traitement apres montage
verification d etat
execution du demontage
post-traitement apres demontage

Les drivers resteraient responsables de leurs parametres et actions specifiques, mais pas de l orchestration complete.

C. Centraliser la gestion des alias/symlinks

Extraire la logique de creation/nettoyage des alias de montage dans un composant unique.

Ce composant devrait definir une politique claire sur :

suppression d un symlink pre-existant
suppression ou refus d un repertoire vide
comportement si le chemin existe deja et n est pas vide
etat a restaurer apres demontage

References code

Pipeline actuel commun

src/models/concerns/base.cr

Drivers actuels

src/models/gocryptfs_config.cr
src/models/sshfs_config.cr
src/models/httpdirfs_config.cr
src/models/kio_fuse_config.cr

Support DBus ajoute pour KIO

src/utils/dbus.cr

Resultat attendu

A terme, kio-fuse ne devrait plus etre un driver qui reimplemente tout son cycle de vie. Il devrait pouvoir declarer ses specificites tout en restant coherent avec le comportement des autres drivers.

Cette evolution doit permettre :

une semantique uniforme de mount/umount
des points d extension explicites pour les drivers atypiques
une centralisation des decisions de cycle de vie du mountpoint
une meilleure testabilite du pipeline

Notes

Cette issue est volontairement separee de #58 :

#58 couvre l ajout fonctionnel de kio-fuse
cette issue couvre la remise a plat architecturale rendue necessaire par cette integration

## Contexte Le support de `kio-fuse` introduit dans #58 met en évidence une divergence d architecture entre les drivers de `src/models/*` et le pipeline commun existant. Aujourd hui : - `GoCryptFSConfig`, `SshFSConfig` et `HttpDirFSConfig` deleguent largement a `GX::Models::Concerns::Base` pour `mount`, `mounted?`, `umount` et la preparation du mountpoint. - `KioFuseConfig` implemente son propre flux, avec montage via DBus, notion de `real_mount_point`, exposition via symlink, et nettoyage specifique. Cette divergence complique l uniformisation du comportement, augmente le risque de regressions, et rend les decisions de montage/demontage implicites dans chaque driver. ## Problemes observes ### 1. Les drivers prennent des decisions d execution eux-memes Le comportement est aujourd hui distribue entre : - `src/models/concerns/base.cr` - `src/models/gocryptfs_config.cr` - `src/models/sshfs_config.cr` - `src/models/httpdirfs_config.cr` - `src/models/kio_fuse_config.cr` `KioFuseConfig` doit contourner le pipeline standard, ce qui montre que le contrat abstrait actuel est trop pauvre pour exprimer des strategies differentes de montage. ### 2. Le pipeline de mount/umount n est pas generique Le pipeline standard suppose implicitement : - un mountpoint reel accessible via `@mount_point` - une creation du repertoire par `Dir.mkdir_p` - un demontage via `fusermount -u` - un check `mounted?` base sur la sortie de `mount` Ces hypotheses ne sont pas universelles. KIO en est le premier contre-exemple explicite. ### 3. La logique de lien/symlink et de nettoyage est locale a KIO Dans `src/models/kio_fuse_config.cr`, les methodes suivantes encapsulent une semantique nouvelle qui n est ni decrite ni partagee : - `expose_mount` - `ensure_mountpoint_available` - `cleanup_exposed_path` - `dir_empty?` Cela cree une logique de cycle de vie du mountpoint differente de celle des autres drivers, sans point central de decision. ## Proposition Faire evoluer l architecture pour que : 1. chaque driver expose explicitement ses capacites et son comportement 2. le pipeline de montage/demontage soit centralise et aussi generique que possible 3. la gestion des alias/symlinks et du nettoyage de mountpoint soit centralisee ## Direction de conception ### A. Introduire un contrat explicite de capacites par driver Chaque driver devrait declarer, directement ou via une petite structure dediee, des informations telles que : - strategie de montage : process direct, DBus, custom - strategie de demontage : fusermount, DBus, custom - mode de verification `mounted?` : parsing `mount`, autre outil, custom - besoin d un mountpoint pre-cree ou non - support d un alias de presentation distinct du point de montage reel Objectif : sortir les decisions implicites des implementations et les rendre pilotables par un pipeline commun. ### B. Centraliser le workflow mount/umount Introduire un orchestrateur commun qui gere, selon les capacites exposees par le driver : - preparation du mountpoint - execution du montage - post-traitement apres montage - verification d etat - execution du demontage - post-traitement apres demontage Les drivers resteraient responsables de leurs parametres et actions specifiques, mais pas de l orchestration complete. ### C. Centraliser la gestion des alias/symlinks Extraire la logique de creation/nettoyage des alias de montage dans un composant unique. Ce composant devrait definir une politique claire sur : - suppression d un symlink pre-existant - suppression ou refus d un repertoire vide - comportement si le chemin existe deja et n est pas vide - etat a restaurer apres demontage ## References code ### Pipeline actuel commun - `src/models/concerns/base.cr` ### Drivers actuels - `src/models/gocryptfs_config.cr` - `src/models/sshfs_config.cr` - `src/models/httpdirfs_config.cr` - `src/models/kio_fuse_config.cr` ### Support DBus ajoute pour KIO - `src/utils/dbus.cr` ## Resultat attendu A terme, `kio-fuse` ne devrait plus etre un driver qui reimplemente tout son cycle de vie. Il devrait pouvoir declarer ses specificites tout en restant coherent avec le comportement des autres drivers. Cette evolution doit permettre : - une semantique uniforme de mount/umount - des points d extension explicites pour les drivers atypiques - une centralisation des decisions de cycle de vie du mountpoint - une meilleure testabilite du pipeline ## Notes Cette issue est volontairement separee de #58 : - #58 couvre l ajout fonctionnel de `kio-fuse` - cette issue couvre la remise a plat architecturale rendue necessaire par cette integration