Date: Thu, 18 Sep 2003 21:50:06 -0700 (PDT) From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: freebsd-bugs@FreeBSD.org Subject: RE: kern/42030: panic when zebra works on detaching tun interface Message-ID: <200309190450.h8J4o6RQ080573@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/42030; it has been noted by GNATS. From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Pawel Malachowski" <pawmal-posting@freebsd.lublin.pl> Cc: <freebsd-gnats-submit@FreeBSD.org> Subject: RE: kern/42030: panic when zebra works on detaching tun interface Date: Thu, 18 Sep 2003 21:42:52 -0700 OK, your right, I was being too simplistic. It is a kernel problem - but only insofar that what the FreeBSD kernel _should_ be doing is be smart enough to recognize that Zebra is doing something wrong and make it dump core. Same with Linux - the Linux kernel (which also panics with Zebra doing the same thing) should be doing this too. Basically your going about this backwards - your trying to get a FreeBSD kernel hacker to fix FreeBSD and tell you exactly what the Zebra program is doing wrong, so you can go to the Zebra people and the work of chasing the bug is done for them. This is understandable given the total lack of response of Kunihiro to fixing bugs in Zebra unless they are handed to him on a silver platter. But morally, since Zebra makes both Linux and FreeBSD kernels panic (totally different kernels, mind) when doing this, the Zebra maintainer should be the one to do the work fixing the Zebra code first, don't you think? Setting aside that, even if a FreeBSD kernel hacker does look into this, the result is not going to help you - the only thing that's going to happen is that perhaps the FreeBSD kernel won't panic anymore. But the Zebra program will still be broken. Since the goal of most people is to get a working application, it seems that the speedier way to this goal is to get the Zebra (ie: Quagga) people to fix it. Then once they do, they can tell you exactly what causes the panic - then you can write a nice little test code fragment and retitle the PR something such as "FreeBSD kernel doesen't handle this XYZ condition properly" Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200309190450.h8J4o6RQ080573>