----- Original Message ----- > From: "Stan Hoeppner" <stan@xxxxxxxxxxxxxxxxx> > >>> And... all the way back to Jason's original question: > >>> > >>> The way that you get the information out of a kernel/kernel RPM to > >>> determine which XFS version it's running... is? Cause it's clearly > >>> not obvious to either him or me. > >> > >> The "version" of XFS that you are running is that of the > >> kernel you are running. i.e. 2.6.32-279.x.y or 2.6.32-358.x.y. > > > > IOWS: There is no spoon. ;) > > Excellent quote Eric, love the Matrix movies. > > I think the problem here is a lack of understanding of the kernel > development and commit process. AFAIK there's not a single Linux > subsystem that has a standalone version number or versioning scheme. > Not the other filesystems, not the USB subsystem, SCSI, ATA, etc. The > version of each is simply the version of the kernel they are included > in. > > I've been wondering throughout this thread where anyone got the idea > that there is an XFS version that can be traced/tracked. Maybe because > xfsprogs have a version number? The way to track XFS changes from > kernel to kernel is to look at the commits, as others have already > stated. I got it from the fact that Jason was asked -- and when I was working with Dave a couple weeks ago, *I* was asked -- "which XFS code we had". Filesystems are one of the few kernel subsystems which "leave tracks", and for it, therefore, *matters* which version of the code you're running, and that's why the issue comes up. There *is* an "XFS version", by inspection of these conversations, and by general knowledge of how filesystem drivers work. That it's backwards compatible isn't really germane to the point that *there are different versions of the code*. If those versions matter, than that's why we version-number things: so the people having problems and the people providing support can have reasonable, cogent conversations where they know what the hell they're talking about. And yes, I *don't* know kernel build practice, cause *I don't work with those people*. We're sorta hoping you guys do, and therefore can tell us *which quantity we're supposed to be trying to find*, so that we can answer the questions you ask us while you're trying to help us fix problems in your code, for free. If the question is "which GIT version was checked out to build the kernel SRPM that made the kernel RPM I'm running from", just say that, and if necessary, we'll go off and look. But let's not try to pretend that "there is no version" of the XFS kernel code, because clearly there is. If there's no "version number"... well, that's not something I would be bragging about. I really do apologize for sounding so combative about this stuff; I'm not really trying to be, but "things have version numbers" has been best practice for 3 decades for a reason, and I think it's a pretty good one: avoiding fights like this. Cheers, -- jra Cheers, -- jra -- Jay R. Ashworth Baylink jra@xxxxxxxxxxx Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
