On Tue, May 10, 2022 at 03:15:05PM +0200, Miklos Szeredi wrote: > On Tue, 10 May 2022 at 13:53, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > What exactly are the attributes that systemd requires? > > > > We keep a repo with ideas for (kernel) extensions - we should probably > > publish that somewhere - but the list we used for a prototype roughly > > contains: > > > > * mount flags MOUNT_ATTR_RDONLY etc. > > * time flags MOUNT_ATTR_RELATIME etc. (could probably be combined with > > mount flags. We missed the opportunity to make them proper enums > > separate from other mount flags imho.) > > * propagation "flags" (MS_SHARED) > > * peer group > > * mnt_id of the mount > > * mnt_id of the mount's parent > > * owning userns > > Sounds good thus far. And hey, we don't even need a new syscall: > statx(2) could handle these fine. > > > There's a bit more advanced stuff systemd would really want but which I > > think is misplaced in a mountinfo system call including: > > * list of primary and auxiliary block device major/minor > > It's when you need to return variable size arrays or list of strings > that the statx kind of interface falls down. > > For that a hierarchical namespace is a much better choice, as it can > represent arbitrary levels of arrays, while doing that with a > specialized syscall is going to be cumbersome. > > > I just have a really hard time understanding how this belongs into the > > (f)getxattr() system call family and why it would be a big deal to just > > make this a separate system call. > > Fragmenting syntactically equivalent interfaces is bad, unifying them Fwiw, turning this around: unifying semantically distinct interfaces because of syntactical similarities is bad. Moving them into a syntactically equivalent system call that expresses the difference in semantics in its name is good.
