Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 May 2004 12:51:10 +0200
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        geom@freebsd.org
Subject:   Re: some comments on geom(8)
Message-ID:  <20040520105110.GN845@darkness.comp.waw.pl>
In-Reply-To: <25148.1085049736@critter.freebsd.dk>
References:  <25148.1085049736@critter.freebsd.dk>

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

--0kOoSRP9h7WTOD7G
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 20, 2004 at 12:42:16PM +0200, Poul-Henning Kamp wrote:
+>=20
+> These are merely comments and not binding in any way.
+>=20
+> The idea behind the gctl_*(9) api was to avoid class specific code
+> in userland to the extent possible and to converge on a common command
+> set for geom classes to make life easier and more intuitive for
+> administrators.
+>=20
+> For a simple operation like "create", I have a hard time seeing why
+> we need class specific code in userland.
+>=20
+> I would expect to be able to type:
+>=20
+> 	create stripe ad0s1 ad1s1
+>=20
+> into geom(8) and see it construct a g_ctl containing:
+>=20
+> 	verb		"create"
+> 	class		"stripe"
+> 	nprovider	"2"
+> 	provider0	"ad0s1"
+> 	provider1	"ad1s1"
+>=20
+> which I would expect the geom_stripe class in the kernel to understand.
+>=20
+> If I had typed
+>=20
+> 	create stripe -stripe 64 ad0s1 ad1s1
+>=20
+> It would be:
+>=20
+> 	verb		"create"
+> 	class		"stripe"
+> 	nprovider	"2"
+> 	provider0	"ad0s1"
+> 	provider1	"ad1s1"
+> 	stripe		"64"
+>=20
+> Similar
+> 	destroy foobar
+> should examine the XML status to find the class of the "foobar"
+> generate something like:
+>=20
+> 	verb		"destroy"
+> 	class		"foo"
+> 	target		"foobar"
+>=20
+> But as I said: these are non-binding comments, do it which ever=20
+> way makes sense to you guys.

I agree, but I've found it quite hard to implement, because
for example in CONCAT and STRIPE class there are two ways to
create it: manual way and auto-configuration way.
In your example we have to interpret keywords in kernel and we can't
provide 'usage' without communicating with kernel part.

Also to all commands I want to pass to the kernel, for example:
'gconcat label', 'gconcat clear'.

I think geom(8) stays in the middle. It is very easy to write
class-specific utility and if it works like your example one have
to only prepare one structure with commands and options description
and no code at all.

I want to send more detailed description on current@ after commiting
manual pages.

--=20
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

--0kOoSRP9h7WTOD7G
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFArI2eForvXbEpPzQRAjbxAJ9w06rE+BiKqWCFtepY4LC2uhv0ggCdHqfp
/zb1txqQ23W8Rzx83JOQ/KM=
=/UZd
-----END PGP SIGNATURE-----

--0kOoSRP9h7WTOD7G--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040520105110.GN845>