--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 07, 2007 at 03:36:14PM +0900, YAMAMOTO Takashi wrote:
> > > i meant, the framework should be designed so that it can track
> > > which parts of disks are used by who, rather than hardcoding your pol=
icy.
> >=20
> > I won't comment on that, because that is a rather hypothetical
> > statement... when it's finished, we'll get back to it. :)
>=20
> how about something like the attached patch?
> "query" part is not yet, but it shouldn't be too hard.

I think we've since agreed with you about making the framework track usage=
=20
rather than hardcoding policy (see the semantic change I proposed).

I'm not sure I like this change. It's a very good implementation of what=20
someone suggested we have in the form of byte range locking. However, I=20
don't see the advantage of byte range locking. I think we should just do=20
partition use verification and thats it.

I've heard two reasons for byte range locking. One was that folks have had=
=20
partitions move around while in use. I agree this is really bad, but I=20
think it's flat-out a bug! Open partitions SHOULD NOT MOVE. I don't care=20
what part of it you are using, it should stay put. :-) So I think the=20
direct fix is to prevent changing live partitions, not adding a different=
=20
checking method.

The other reason I've heard given for byte range locking is for something
like writing boot blocks in the first 8k or 32k of a file system. I don't
think that's a good reason though. That's the only access I can think of
where you would want sub-partition ideas. However it's exactly a time when
you NEED to know what you are doing, so requiring userland to know doesn't
seem that bad a deal. Plus, we are discussing open checks that are
performed at some secure level - after we have started booting multi-user.
However I always thought of that as a time when we would NOT want to be
updating the boot code. Put another way, if you are the kind of person who
might want to update boot code after booting multi-user (like me, to be
honest :-), chances are you don't care about these checks.  Likewise, if
you care about not overwriting active partitions, chances are you don't=20
want to update boot code after startup.

So we're talking about a lot of complexity that I don't think will ever=20
get used. I say we leave it out and just go with partitions. Partitions=20
that don't move around.

Take care,

Bill

--2fHTh5uZTiUOsy+g
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFofEnWz+3JHUci9cRAgcyAJ9Vpdmf82LE2jSzdFk/05+zPMy/TACdGZJk
jDzcwNM2C3wcspnz6UWQKBc=
=43RK
-----END PGP SIGNATURE-----

--2fHTh5uZTiUOsy+g--