> > > 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. > 99 88 0:34 / /mnt/foo rw,noatime shared:42 slave:13 foofs /dev/foo,errors=continue Something like that? It assumes, that fs types never have ':' in them, but that's acceptable. Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
