[lkml]   [2008]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 4/6] vfs: mountinfo show dominating group id
On Wed, Mar 19, 2008 at 01:19:42PM +0100, Miklos Szeredi wrote:
> > So maybe some alternative, multi line format would be better?
> >
> > MountID: 99
> > ParentID: 88
> > DevID: 0:34
> > Type: foofs
> > Source: /dev/foo
> > Root: /
> > MountPoint: /mnt/foo
> > MountOpts: rw,noatime
> > Opts: rw,errors=continue
> > Propagation: shared:42
> Which still doesn't fully solve the problem, since ->show_options()
> can also spew newlines + MountID:. Oh well.

a) ban newlines in ->show_options(); that's a requirement that is easy
to formulate and understand, so it has a chance to survive the contact
with reality.

b) the order is all wrong - *everything* that depends on fs type should
be after fs type and everything else should be prior to it. That way
you don't need to know what the hell does this fs type spew in order to
parse type-independent information. In particular, "source" (BTW, why
do you capitalize those?) certainly has no business being in front of
fs type; as the matter of fact, I'm not at all sure that we _want_ it
separated from the rest of type-dependent options. The fact that mount(2)
gets it in a separate argument is a historical accident...

c) since you are tagging the fields anyway, why do you need newlines?
Moreover, you don't really need to tag everything - there's a well-defined
beginning and optional fields between it and (type+rest) are the only
things that needs to be tagged... BTW, why bother with Propagation: part
and gluing shared:... with slave:... into a single field? Separate them
with whitespace - you have recognizable prefixes right there.

 \ /
  Last update: 2008-03-19 22:25    [W:0.052 / U:13.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site