Messages in this thread | | | From | "Khimenko Victor" <> | Date | Tue, 28 Apr 1998 02:02:23 +0400 (MSD) | Subject | Re: (PLEASE READ THIS) Re: weird 3c590 problems |
| |
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
| |