Re: (PLEASE READ THIS) Re: weird 3c590 problems

Khimenko Victor (khim@sch57.msk.ru)
Tue, 28 Apr 1998 02:02:23 +0400 (MSD)

27-Apr-98 21:42 you wrote:
> Actually, I'll just comment one more thing here, since it's an
> interesting topic, and almost completely ignored by the folks out there
> developing linux.
>
No. This topic is not ignored. Here all is VERY clear. Sometimes it's better
to use not very latest versions of software (if you are must support a lot of
systems, when you produce distrudutions -- RedHat 5.0 still uses 2.0.32 with
patches, NOT 2.0.33, libc 5.3.12 (yes, 5.3.12) with patches, not 5.4.x, etc.)
and this is perfectly NORMAL (I am not sure that RedHat will be more stable
with libc 5.4.44, for example). The only thing must be clear here: YOU AND
ONLY YOU (and NOT MANTAINER) is responsible for support in this case. If you
want ask developer about ANY problem then you MUST make sure that this problem
is still persist in latest version of kernel (libc, glibc, etc.). If you COULD
reproduce this -- ask mantainer. If not -- you are free to do anything, but
NOT try bother mantainer with your problems... The ONLY exception from this
rule is situation where bug could not be reproduced without some patch (for
example if you have SCSI driver, not included in mainstream on your system and
found bug with 3c590). If bug is could be related to some of the patch -- for
example I am could not use some very new protocol (not in mainstream) with my
ne2000 but could use this new protocol with DEC tulip for exmaple. In this case
you could ask mantainer of tulip driver as LAST RESORT only -- when both author
of patch and you could not find bugs in patch for new protocol.

> Those are your adjectives. "previous version" does not imply unstable
> and untested. On the contrary, I assure you that my previous versions
> plus patches are both stable and tested. Months of testing in hundreds
> of machines with huge varietries of hardware. Yes, it is unsupported,
> and so what? Is anyone buying support contracts around here?
>
Yes. This is allright until you ask mantainer to investigate. You not buying
support from them -- he's do support on it's own. Try to make his life easily:
make sure that this bug is still not fixed.

P.S. Situations where one bug will closed by other and resulting product is
working just fine is sutiation where "all bugs is fixed"... For example in
glibc is function sigismember(). This function could return 0 (no member),
1 (is member), -1 (wrong parameter). This function is called in the following
code:
-- cut --
for (s = 1; s <= NSIG; s++) {
if (sigismember(set, s) && sigismember(&sigwaited, s) == 1) {
-- cut --
this code is definitely wrong: sigismember could be != 0 not only when
sigismember() == 1, but also when sigismember() == -1 !! But really sigmember()
defined in glibc will return -1 only for s < 1 or s > NSIG so you could not
detect this error... This code is "right". Just a real-life example...

P.S. Really in glibc there was
-- cut --
for (s = 0; s <= NSIG; s++) {
if (sigismember(set, s) && sigismember(&sigwaited, s) == 1) {
-- cut --
and I am sent patch with the following
-- cut --
for (s = 1; s <= NSIG; s++) {
if (sigismember(set, s) == 1 && sigismember(&sigwaited, s) == 1) {
-- cut --
first line was accepted while second was declined since sigismember could not
be -1 for s in [1,NSIG]...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu