--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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. H=
e=20
> > changed the name of the lock on all of struct proc. That is used outsid=
e=20
> > of just the RAS code.
>=20
> 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).
>=20
> 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=
=20
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=20
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=
=20
both are in pkgsrc.

I appreciate you changing all references to the fields in question, but=20
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 stu=
ff
> is slightly out of date.

It's not just layout, it's the structure. You've changed the structure=20
(names), so you should bump the version.

The kernel version is the identifier for the kernel's "external" =20
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=20
not changed the name of the lock field (I think the RAS stuff is=20
sufficiently kernel-private that replacing it with padding is ok). But=20
since you changed the lock name, you should have bumped the kernel=20
version, in which case there's no reason not to have removed the padding.=
=20
:-|

Also, since we are hoping 2.0 will branch "soon," this change might be the=
=20
last change to struct proc before 2.0. Do you really want 2.0 to ship with=
=20
"to be removed" padding??

I think you should just remove the padding and bump the kernel version.

Take care,

Bill

--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/r9xuWz+3JHUci9cRAhg0AJ0RWt8mPxi83VRywN1h2/WZzZPz3QCfcoSh
fUkKIhi7YMuXG/N1sparxpM=
=tsIq
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--