if accessing a file on a read-only filesystem changes that filesystem it's a bug
see the recent thread about ext3 journal replays when mounting read-only as an
example.
however, the result may be a lot less 'special case pwoer management' code and a
lot more re-use of code that's in place for other uses.
if work on the current versions was stopped (other then trying to avoid
regressions) and a new version (with new userspace tools) was built in a way
that satisfies everyone the old version could be phased out in a year or two
(per the normal feture removal process)
if simply splitting the functions cleans everything up enough to satisfy
everyone then we're almost done right? ;-)
however I think that there are other fundamental disagreements here, and neither
the 'do absolutly everything in the kernel' or the 'do almost nothing in the
kernel' approaches are going to fly in the long run. I think the
userspace<->kernel interface is going to be different then either apprach is
doing now, and as such it's an oppurtunity to make more drastic changes if they
are appropriate.
for example, why should we have LVM snapshot code and hibernate
snapshot/filesystem checkpoint code instead of just useing the LVM code (which
gets excercised and tested far more then the other code ever would be)? saying
that if you want to suspend to disk you need to use LVM is a change, but it's
a change that people could probably live with.
David Lang
-
