Subject: Re: Nightmare File Corruptions with 1.6Q - FFS?
To: John Franklin <firstname.lastname@example.org>
From: Frederick Bruckman <email@example.com>
Date: 04/15/2003 08:33:11
On Tue, 15 Apr 2003, John Franklin wrote:
> On Sat, Apr 12, 2003 at 09:46:05AM +0200, Jaromir Dolecek wrote:
> > Greywolf wrote:
> > > That's a pretty lax call; I'd say that anything which affects kernel
> > > structures changing AT ALL, let alone on a significant level such as,
> > > oh, say, FILE SYSTEM STRUCTURE CHANGES, warrants a kernel indicator.
> > It does not affect general kernel structures. It affects code
> > for one file system, in that fs specific code. Would we bump kernel
> > version whenever random filesystem gets improved significantly?
> > We did not for LFS, and there is no reason to do for FFS/UFSv2, IMHO.
It's more than just an improvement -- the API changed in such a way
that "lsof" can't be built, and "lsof" uses __NetBSD_Version__, so,
even assuming "lsof" is fixed eventually (for __NetBSD_Version >=
1061800), it will still never build on NetBSD 1.6Q-1/2.
> Apparently not, but we should. It was my understanding that whenever
> kernel APIs or structures change, the letter gets bumped. IMHO, we
> should do it for FFS, we should do it for LFS, heck we should do it for
> NTFS, even though only a scant few ever use it!
> Be liberal with the letter bumps. We have plenty of letters, and if we
> get into 16AA, 16AB, 16AC... so be it. It's better to have too many
> than to not know when something changes.
There's only two digits for that in __NetBSD_Version__, but still that
gives 99, or up to something like 1.6ZZZU, so there seems to be enough
room to bump for API changes.