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

On Tue, Jun 26, 2007 at 11:09:21AM +0200, Juergen Hannken-Illjes wrote:
> On Tue, Jun 26, 2007 at 10:54:35AM +0200, Geert Hendrickx wrote:
> > On Tue, Jun 26, 2007 at 10:37:00AM +0200, Juergen Hannken-Illjes wrote:
> > > An LKM will fail to load if the kernel version doesn't match so we can
> > > expect admins to think twice before they use `modload -f'.
> >=20
> > But when pulled up to the stable branches, the kernel version will matc=
h.
> >=20
> > 	Geert
>=20
> Ok.  So its only safe to pull up to (not yet released) netbsd-4 and leave
> the other releases as they are now.

No, we really need to fix this in all the releases.

To be honest, my vote is to ignore LKM incompat here. I think it's great=20
that we strive for it, and in most cases I think we should. Here, however,=
=20
we are only talking about something that's used inside of ufs. I really=20
don't think anything outside of ufs uses it. Do ffs, ext2fs, and lfs use=20
it, or do they defer to ufs code? i.e. they make ufs_foo() calls.

So my vote is just make the change and note it in the release notes. The=20
only thing that'd be impacted would be something reaching into the=20
innnards of ufs.

This issue has made me a fan of Mac OS X's kext system. You end up with=20
acres of kexts, each with a version. But we could easily handle this by=20
just bumping the ufs module's version. Then only ufs-using modules would=20
have a version mis-match.

Take care,

Bill

--8t9RHnE3ZwKMSgU+
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFGgWF/Wz+3JHUci9cRAq30AJ9X6UQmS5ZbpnpPxfsoQwhsKQJNOwCeMMxz
xYIXqaiqsuxsGeZVXlOzoPI=
=ui4h
-----END PGP SIGNATURE-----

--8t9RHnE3ZwKMSgU+--