kern/42030: panic when zebra works on detaching tun interface

[Ted Mittelstaedt]

The following reply was made to PR kern/42030; it has been noted by GNATS.

From: "Ted Mittelstaedt" <tedm at toybox.placo.com>
To: "Pawel Malachowski" <pawmal-posting at freebsd.lublin.pl>
Cc: <freebsd-gnats-submit at 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