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

[Jerry McAllister]

> 
> 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?

No, you are missing the point about the kernel.    
Sure, something is wrong with zebra and needs fixing.   No argument.
But, the point about the kernel is as you essentianly concede above
that the kernel should not panic on a user world program - regardless 
of how bad the user world program is.   The kernel should be robust
enough to let the program to die and sluff it off.   

It is really weird argument to imply that the kernel flaw should be
left in place to force the user world program to be fixed.

////jerry

>  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
>  
> _______________________________________________
> freebsd-bugs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
> To unsubscribe, send any mail to "freebsd-bugs-unsubscribe at freebsd.org"
>