Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Aug 2011 18:48:00 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Nathan Whitehorn <nwhitehorn@freebsd.org>
Cc:        "freebsd-current@FreeBSD.org Current" <freebsd-current@freebsd.org>
Subject:   Re: Well, there goes Windows!
Message-ID:  <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net>
In-Reply-To: <4E51B228.7030001@freebsd.org>
References:  <CAGH67wRFP9nFQLr0Gh-h4rKWrndZSy=6Q%2BKLC_U5Fg4RD%2BJMCw@mail.gmail.com> <4E4DB9A7.4040404@freebsd.org> <CAGH67wQoXOju3=OTh%2B6JoKLxkp7Vzqu8vg%2BO9X=DPXB5EkBJtQ@mail.gmail.com> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <C429B7D4-08DD-4A86-BC4E-07B29B755736@xcllnt.net> <4E51B228.7030001@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote:
>>=20
>>> The regular partitioning editor only commits early in this =
particular case, and asks about each subpartition tree separately with a =
big scary dialog box. In the spirit of the autopartitioner, it makes one =
large scary dialog, and always runs in early commit mode instead of =
potentially showing many scary dialogs about partitions the user doesn't =
necessarily even know about. This behavior could be changed, but I think =
is the most friendly for the case in question: namely, "I want to blow =
away everything and let the installer handle all partitioning details by =
itself".
>> What about inserting a special class for doing commit/undo. The GEOM
>> simply keeps all modifications in memory and 1) forgets everything on
>> an undo operation or 2) writes all dirty sectors on a commit. This
>> could be used even instead of the gpart-private support, which also
>> removes the quirk for the null scheme.
>>=20
>=20
> Where would this class go? If it went below gpart (between gpart and =
userland), then it seems like we would lose the ability of gpart to =
validate its parameters. Who would be responsible for inserting this =
GEOM into the stack?

Between the disk GEOM and the gpart GEOM. The gpart utility would
still interact with the GEOM is before.

--=20
Marcel Moolenaar
marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4>