On Tue, Jun 26, 2007 at 11:57:04AM -0700, Bill Stouder-Studenmund wrote:
> 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'.
> > > 
> > > But when pulled up to the stable branches, the kernel version will match.
> > > 
> > > 	Geert
> > 
> > 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 
> that we strive for it, and in most cases I think we should. Here, however, 
> we are only talking about something that's used inside of ufs. I really 
> don't think anything outside of ufs uses it. Do ffs, ext2fs, and lfs use 
> it, or do they defer to ufs code? i.e. they make ufs_foo() calls.

The only uses of `struct dquot' fields are in `ufs/ufs/ufs_quota.c'.  All
other file systems use functions provided by this file.

> So my vote is just make the change and note it in the release notes. The 
> only thing that'd be impacted would be something reaching into the 
> innnards of ufs.
> 
> This issue has made me a fan of Mac OS X's kext system. You end up with 
> acres of kexts, each with a version. But we could easily handle this by 
> just bumping the ufs module's version. Then only ufs-using modules would 
> have a version mis-match.
> 
> Take care,
> 
> Bill

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)