drivers/char/sonypi.h broken

drivers/char/sonypi.h broken

[Richard Gooch]

  Hi, Linus. I now find that drivers/char/sonypi.h has been broken in
2.4.10-pre12. I get the following compile errors:

sonypi.h:195: `SONYPI_EVENT_PKEY_P1' undeclared here (not in a function)
sonypi.h:195: initializer element for `sonypi_pkeyev[0].event' is not constant
sonypi.h:196: `SONYPI_EVENT_PKEY_P2' undeclared here (not in a function)
sonypi.h:196: initializer element for `sonypi_pkeyev[1].event' is not constant
sonypi.h:197: `SONYPI_EVENT_PKEY_P3' undeclared here (not in a function)
sonypi.h:197: initializer element for `sonypi_pkeyev[2].event' is not constant
make[2]: *** [sonypi.o] Error 1

I have no idea what the values should be, so I'm unable to generate a
patch. Hopefully the guilty party (i.e. the lazy bastard who sent in a
broken patch without bothering to compile the fucking thing first)
will be shamed into generating a patch ASAP.

Yes, I'm annoyed. So much for syncing up tonight with -pre12, testing
(yeah, some of us still believe in TESTING), and thence onto coding.
I've spent the evening flushing out other people's turds. Grrr.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: drivers/char/sonypi.h broken

[Stelian Pop]

In alcove.lists.linux.kernel, you wrote:

>   Hi, Linus. I now find that drivers/char/sonypi.h has been broken in
> 2.4.10-pre12. I get the following compile errors:
> 
> sonypi.h:195: `SONYPI_EVENT_PKEY_P1' undeclared here (not in a function)
[...]

Already submitted a patch for this here and cc:'ed to Linus. 
See: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0109.2/0617.html

> Hopefully the guilty party (i.e. the lazy bastard who sent in a
> broken patch without bothering to compile the fucking thing first)
> will be shamed into generating a patch ASAP.

Calm down. The lazy bastard here is either Linus or Alan. This driver
update is a merge from the -ac tree, where this driver remained 
unmodified for several weeks now.

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
|---------------- Free Software Engineer -----------------|
| Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alcôve, liberating software ---------------|

Re: drivers/char/sonypi.h broken

[Alan Cox]

> Yes, I'm annoyed. So much for syncing up tonight with -pre12, testing
> (yeah, some of us still believe in TESTING), and thence onto coding.
> I've spent the evening flushing out other people's turds. Grrr.

Turn off the computer, go spend a day cooling down for god sake.

One header file disappeared in the email pile somewhere. Of course if you'd
_bothered_ to check the l/k archive before ranting you'd have found the
posting about it.

Alan

Re: drivers/char/sonypi.h broken

[Richard Gooch]

Alan Cox writes:
> > Yes, I'm annoyed. So much for syncing up tonight with -pre12, testing
> > (yeah, some of us still believe in TESTING), and thence onto coding.
> > I've spent the evening flushing out other people's turds. Grrr.
> 
> Turn off the computer, go spend a day cooling down for god sake.

Well, I went to bed shortly after my missive :-)

> One header file disappeared in the email pile somewhere. Of course
> if you'd _bothered_ to check the l/k archive before ranting you'd
> have found the posting about it.

Hm. I got testy because there were three broken things I stumbled over
in 12 hours. I think this just highlights the need for BitKeeper or
equivalent, where automated regression testing (even a simple "does it
compile and link?") is performed, and if the test fails, it gets
bounced and doesn't even get to Linus.

Alan: I realise it's impractical for you to manually test each
patchlet that you send to Linus, since you carry a large number of
them. But would you consider an automated system? I'm thinking of a
script that you use to "mail" each patch to Linus. Said script applies
and compiles, and either bounces the patch, or sends it off the Linus.
That way you get the same fire-and-forget behaviour you have now with
email, but with better testing.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: drivers/char/sonypi.h broken

[Alan Cox]

> in 12 hours. I think this just highlights the need for BitKeeper or
> equivalent, where automated regression testing (even a simple "does it
> compile and link?") is performed, and if the test fails, it gets
> bounced and doesn't even get to Linus.

I do compile/link tests but not a million combinations of them. Its
o(N!) remember..

Re: drivers/char/sonypi.h broken

[Richard Gooch]

Alan Cox writes:
> > in 12 hours. I think this just highlights the need for BitKeeper or
> > equivalent, where automated regression testing (even a simple "does it
> > compile and link?") is performed, and if the test fails, it gets
> > bounced and doesn't even get to Linus.
> 
> I do compile/link tests but not a million combinations of them. Its
> o(N!) remember..

Yes, and even if you were able to do so, there is still the problem of
testing against the version that Linus applies the patch to (which as
you said earlier, is a moving target). I guess one solution would be
to have the tool Linus uses (or should use:-) also do a test, and if
it fails, to bounce it. That would be done against Linus' working
tree.

However, that would reduce Linus' flexibility in applying a series of
patches which involves global API changes. Hm. Perhaps an option so
that Linus can accept a patch if he knows it's part of a global API
change.

Another alternative, which has been raised before, is Linus' patch
queue is made public. As I understand it, Linus files pending patches
into a special folder, and then later feeds that folder, en-masse,
into patch(1), and a release/pre-patch is born. That patch queue could
be distributed using the kernel.org mirror system. This would be a
generally useful thing, and with automated regression testing, reduces
the window for merge errors.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca