Date: Thu, 17 Apr 2003 09:39:26 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sbin/sunlabel Makefile Message-ID: <20030417063926.GD61799@sunbay.com> In-Reply-To: <45523.1050527162@critter.freebsd.dk> References: <20030416205506.GB10181@sunbay.com> <45523.1050527162@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--k4f25fnPtRuIRUb3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 16, 2003 at 11:06:02PM +0200, Poul-Henning Kamp wrote: > In message <20030416205506.GB10181@sunbay.com>, Ruslan Ermilov writes: >=20 > >disklabel will soon be enabled on sparc64 too, once > >the endianness fixes are committed. This is needed > >to cross-release architectures that use BSD labels, > >that is i386 and Alpha. >=20 > I guess we should paint the big picture, just to make sure we don't > get a confused bikeshed at this point. >=20 > The plan/goal, such as it is: >=20 > All disk partition programs, should work on all > architectures/endianess. (presently: fdisk, disklabel, > sunlabel, gpt) >=20 Yes. Haven't looked into fdisk and gpt yet. > Some of these programs will need to grow "-m $architecture" > like arguments, for instance disklabel which needs to be able > to tell the difference between an i386 and alpha layout. fdisk(8) > may also need to learn i386/pc98. >=20 Yes. And disklabel(8) already provides -m. > Make release tools will learn to DTRT, this may include KLD'ing > GEOM modules. >=20 Yes. And they already know about -m in disklabel. With uncommitted patches, sparc64, i386, and alpha were able to build WORKING snapshots of i386 and alpha. > As for the naming of bsdlabel/disklabel. I am all for a repo-copy > disklabel->bsdlabel, with a compatibility symlink on alpha/i386/pc98. >=20 That would also mean renaming disklabel.h to bsdlabel.h, and providing compatibility shim in disklabel.h, no? > Thinking a bit more about it, I think we should not symlink anything > else to that name on other architectures, but rather have a small > shellscript which explains what the tool is called on the present > platform. >=20 There's nothing wrong if these tools will additionally be known by the common disklabel name, but if and only if they support the same getopt() set. "make release" can be easily taught of selecting the right labelling tool based on TARGET_ARCH. The disklabel name will then serve only as commonly known alias in the daily maintenance. Symlinking as opposed to hardlinking is also preferred, as it would give the idea of what the actual label is for the wondering. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --k4f25fnPtRuIRUb3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+nkweUkv4P6juNwoRAp4pAJsHSUvuX2FkycfYaQvUOkDmzpIpOQCfXJ9u okphfbBT7BnKJQUjtoNIwks= =FQ5P -----END PGP SIGNATURE----- --k4f25fnPtRuIRUb3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030417063926.GD61799>