> > 2.0 has some known races and deadlocks in the quota code. I've send the
> > reporter some fixes, but I'm still waiting for feedback. It would be nice if
> > those could be incorporated into 2.0.34.
>
> They can go into 2.0.35. Any change now invalidates all the hard testing
> done in 2.0.34. So once Linus ships 2.0.34 send me the diffs
Well, this patch could make it into either one, it's really harmless. It
fixes some compiler warnings, mostly variables declared implicitly as int.
Here is the summary:
- (warning) variables implictly declared as int
- (warning) #ifdef 0 instead of #if 0
- (warning) unused variables and functions
- (stupid compiler warning) in string.h, change the case 3: to default: to
make the compiler shut up; it makes no difference otherwise
- (harmless error) a number of SCSI drivers implement the reset function
with only one parameter, even though the API requires two
- (warning) in seagate.c PARITY is defined both in the Makefile with -D
and in the source with #define; I kept only the Makefile instance and
commented out the other one, with a warning
I have another patch waiting, it implements smart dependencies based on
Michael Chastain's 2.1 version. It's really convenient - it literally
saves hours of compile time - but since it touches so many files and could
potentially break stuff, it's better to wait for .35 before putting it in.
Oh, and one comment about the 2.0.x + egcs/pgcc controvercy: in my
experience, the problems appear only when the kernel is compiled with a
level of optimization higher than the default -O2. People just change it
to some insane values like -O6 - which even the maintainers of the
compiler warn that it's not 100% safe, at least for pgcc - and then wonder
why things break...
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu