On Sun, May 25, 2003 at 11:22:06PM +0100, Dr. David Alan Gilbert wrote: > * Brian M. Carlson (sandals@crustytoothpaste.ath.cx) wrote: > > On Sun, May 25, 2003 at 07:35:23PM +0100, Dr. David Alan Gilbert wrote: > > > * Brian M. Carlson (sandals@crustytoothpaste.ath.cx) wrote: > > > > > > > > Indeed they are. The Linux kernel is part of the release criteria (at > > > > least it was for 3.0) [0]. The site states: > > > > > > Which kernel version? On which architecture? With which drivers? > > > > I really don't know. I'm not a mind reader. All I know is what is on the > > web site. I also know that gcc is the only compiler that consistently > > compiles the Linux kernel correctly--in general, that is. > > > > > Its fair to say Gcc shouldn't have any bugs that show up in a few > > > kernel builds, but you can't expect them to test everything; like gcc > > > the kernel is a big piece of code. > > > > No, I can't expect them to test everything, but I can expect them to > > give it at least a once through. This would have (or at least should > > have) been caught, because gcc 3.3 introduced a complete incompatibility > > with older versions: creating an error when pasting together two such > > tokens. I don't know what the standard says on this issue, but at most > > it requires a diagnostic, and a warning suffices. Changing the warning > > to an error breaks *a lot* of code that otherwise works, including the > > kernel. > > Well, I've just compiled Linux 2.5.69 with gcc 3.3 (Debian as in Sid) - > all looks fine to me (although not tried to boot it). > I'm just pointing out that they probably did a similar test; they > compiled >>A<< linux kernel with some particular set of drivers > (hopefully a fairly large chunk) and hopefully they checked it and it > was OK; the fact that it fails in one (fairly obscure) driver is hardly > cause for criticising them for not meeting their release criteria. The way I compiled the kernel was to copy the latest /boot/config-2.4.* file to .config in the source directory. Then run make oldconfig. I do this because I'm lazy and I don't want to spend forever and ever configuring the kernel. Everything that I have to configure follows these rules: if it can be a module it becomes a module, debugging is disabled, non-binary and non-ternary options are left at their defaults, and generally I choose the option that will allow the greatest degree of expansion while not being reckless. However, I will point out that just even using the options in the Debian configuration (/boot/config-2.4.20-[13]-k7) would have caused problems, because the ambassador module is enabled there. This to me makes it seem very likely that even the stable 2.4.20 would have failed to compile. And it did, you see the bug to which this is merged. I will also give you that this module is probably obscure, and I probably will never use it. But that doesn't mean that *someone* won't use it, and that's what counts. > > If a .c file doesn't turn into a .o file, and it did with 3.2 [0], that's > > a regression, and therefore a bug. You can argue for all eternity > > that it's not bug, but a feature, and I'll tell you that if Debian ever > > ships any version of gcc in unstable that doesn't compile the kernel, > > that's a bug. > > Well I've got to say that that particular line has to come up in my > category as the weirdest use of #define macroing that I've seen. I > haven't got a clue if thats valid code or not. I'll admit, it's...I can't say unusual, because it's not. I've seen it plenty of places before. Perhaps weird is a good word. I'm not really sure if it's valid either. -- Brian M. Carlson <sandals@crustytoothpaste.ath.cx> 0x560553e7 "Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all." --Douglas Adams
Attachment:
pgpq7vsn4buP4.pgp
Description: PGP signature