Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/sys



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



Home | Main Index | Thread Index | Old Index