On Mon, 2020-02-24 at 11:24 +0100, Miklos Szeredi wrote: > On Fri, Feb 21, 2020 at 9:21 PM James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: [...] > > Could I make a suggestion about how this should be done in a way > > that doesn't actually require the fsinfo syscall at all: it could > > just be done with fsconfig. The idea is based on something I've > > wanted to do for configfd but couldn't because otherwise it > > wouldn't substitute for fsconfig, but Christian made me think it > > was actually essential to the ability of the seccomp and other > > verifier tools in the critique of configfd and I belive the same > > critique applies here. > > > > Instead of making fsconfig functionally configure ... as in you > > pass the attribute name, type and parameters down into the fs > > specific handler and the handler does a string match and then > > verifies the parameters and then acts on them, make it table > > configured, so what each fstype does is register a table of > > attributes which can be got and optionally set (with each attribute > > having a get and optional set function). We'd have multiple tables > > per fstype, so the generic VFS can register a table of attributes > > it understands for every fstype (things like name, uuid and the > > like) and then each fs type would register a table of fs specific > > attributes following the same pattern. The system would examine the > > fs specific table before the generic one, allowing > > overrides. fsconfig would have the ability to both get and > > set attributes, permitting retrieval as well as setting (which is > > how I get rid of the fsinfo syscall), we'd have a global parameter, > > which would retrieve the entire table by name and type so the whole > > thing is introspectable because the upper layer knows a-priori all > > the attributes which can be set for a given fs type and what type > > they are (so we can make more of the parsing generic). Any > > attribute which doesn't have a set routine would be read only and > > all attributes would have to have a get routine meaning everything > > is queryable. > > And that makes me wonder: would a > "/sys/class/fs/$ST_DEV/options/$OPTION" type interface be feasible > for this? Once it's table driven, certainly a sysfs directory becomes possible. The problem with ST_DEV is filesystems like btrfs and xfs that may have multiple devices. The current fsinfo takes a fspick'd directory fd so the input to the query is a path, which gets messy in sysfs, although I could see something like /sys/class/fs/mount/<path>/$OPTION working. James
