--phCU5ROyZO6kBE05
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 20, 2003 at 07:16:38PM +0200, Christian Limpach wrote:
> On Mon, 20 Oct 2003 09:47:16 -0700 Bill Studenmund <wrstuden@netbsd.org> =
wrote:
>=20
> > You're way over-engineering this. :-) All newfs needs is exactly what's
> > in struct partition now, with info from the static part of disklabel. I
> > agree we may need more stuff in the future, but let's wait until then f=
or=20
> > implementing it.
>=20
> but then we should also wait with adding any ioctl until we have a real
> need for one ;-)

And what makes you think we don't now?

I have changes I made to the Apple partition map goop to support
re-writing it, for newfs. I think they are ugly, as re-writing the whole
disklabel just doesn't work too well. However the "update this partition"
operation would map quite easily. So we DO need this now. :-)

> > Note that there will be two info stores. There will be whatever is on
> > the disk, and what's in the kernel. What is in the kernel will be just
> > the minimum needed, and the struct we talked about above will probably =
do
> > it.=20
> > What is on the disk will depend on the partitioning scheme in use.
>=20
> hmm, wouldn't that be quite inconvenient:  tools like newfs will have to
> know how to interact with two stores.  I'd hope that newfs would use
> functions from some library which would update both stores!? =20

No! newfs and everthing else just talks to the kernel. If the partitioning=
=20
scheme is something the kernel can re-write (or technically update), then=
=20
it rewrites the disklabel. In a wedges world, it passes the request down=20
to the wedge daemon.

The problem with a library that all tools use is that all the tools have=20
to grow as new partitioing schemes come into play. While we could do that,=
=20
I think it'd be easier (looking towards wedges) to have newfs and friends=
=20
tell the kernel what to do. For now the kernel does what it can, but in=20
the future, it talks to the wedge daemon (which will want to know this=20
anyway).

> Also, if the store in the kernel is minimal, then filesystem specific data
> shouldn't be stored in it.  On the other hand, some kind of filesystem
> identifier (name or some kind of UUID) should probably be stored in the
> kernel...

File system data represent 64 bits (8 bytes) per partition. I think a
minimal store can deal with that. If it were much more I'd agree we might
not want it in the kernel anymore. Also, the hassle of getting it from=20
somewhere else will most likely be more hassle than 8 bytes per partition=
=20
are worth. :-)

Take care,

Bill

--phCU5ROyZO6kBE05
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/lGMLWz+3JHUci9cRAgh2AJ9HBl2Vz29o8PQSQtb09KEkXc5xcwCfZPCz
gmEGeRjE+yyZTUkHwi9xK2U=
=mDwx
-----END PGP SIGNATURE-----

--phCU5ROyZO6kBE05--