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