setjmp/lonjmp

Yury Tarasievich grog at grsu.by
Fri Feb 4 05:26:28 PST 2005


Joerg Sonnenberger wrote:
On Fri, Feb 04, 2005 at 02:41:45PM +0200, Yury Tarasievich wrote:

A word from "the masses": this is completely justified -- developer's -- 
point of view. On the other hand: cleaning of the code per se gives 
plenty of opportunities to break what's working. Like, reducing vinum 
functionality (or breaking it), or having ipfw removed. Doesn't look good.


I had a quite impossible panic from vinum a while ago which most likely
relates to longjmp handling. But I'm not sure and the current code is
exactly for the interwindling of code pathes via longjmp hard to follow.
Concerning the removal of ipfw1, it won't happen soon. Once ipfw2
Removal of ipfw1 proper could happen every time, for me.
Not so with notion to remove ipfw2.
Generally, no advanced concept usage at all is interchangeable with 
another (as, like in this case, IPFW2 vs. PF, or vinum vs. HW RAID 
controllers).

fully works, it can die. Another requirement or ipfw(2) is to use
the normal firewall API, since it currently hooks into way too
much places directly. This means an improvement in usability too,
because ipfw would be fully dynamically loadable.
Well, I want to believe. :)






More information about the Kernel mailing list