On Fri, Nov 07, 2003 at 06:52:32PM +0000, David Laight wrote: > > You are talking about the RAS code, but David changed more than that. He > > changed the name of the lock on all of struct proc. That is used outside > > of just the RAS code. > > There is a very good tool for detecting source compatibility (gcc), > whereas binary compatibility gets harder - hence the need to change > version numbers (or, IMHO, better the names of the symbols). > > In this case the non-ras change was to rename a structure field, > changing the kernel version won't make it any easier/harder to > decide why the sources dont build. Depends on what sources you're talking about. If you're talking about the kernel sources we distribute, yes, you're right. That won't help. However that's not what the kernel version is for, so the point is spurious. > I did try to find all the code is src/sys that referenced these fields, > as always a couple escaped - probably when I way trying to edit the > shell variable that contained the great long list of filenames... - and > there was an odd typo in an arch I can't compile. As for making edits like this, I'd suggest either id-utils or cscope. They both are in pkgsrc. I appreciate you changing all references to the fields in question, but that's still not a reason not to bump the version. > In any case, it is probably better to change the structure layout > as infrequently as possible - just so it doesn't matter if user-space stuff > is slightly out of date. It's not just layout, it's the structure. You've changed the structure (names), so you should bump the version. The kernel version is the identifier for the kernel's "external" interface. That interface is used both by userland (via libkvm) and LKMs (well external kernel code). I say "external" as we're a bit fast & loose about what headers are and aren't "external". But struct proc sure counts as "external." I'll agree with Matt that userland probably isn't using it (thanks to sysctl), but I think that any external kernel code that touches on processes will care about this. If you really wanted to get away without a version bump, you should have not changed the name of the lock field (I think the RAS stuff is sufficiently kernel-private that replacing it with padding is ok). But since you changed the lock name, you should have bumped the kernel version, in which case there's no reason not to have removed the padding. :-| Also, since we are hoping 2.0 will branch "soon," this change might be the last change to struct proc before 2.0. Do you really want 2.0 to ship with "to be removed" padding?? I think you should just remove the padding and bump the kernel version. Take care, Bill
Attachment:
pgpXJtZv0gavA.pgp
Description: PGP signature