Setjmp/Longjmp in the kernel?

Setjmp/Longjmp in the kernel?

[John W. M. Stevens]

Greetings,

I ported an Object Oriented infrastructure to work with the Linux
kernel about two years ago.  For various reasons, that work was
dropped for a while.  Now, upon picking it back up again, there
are some new features that were not present in the original port
that I need to support.

Among these is a simple exception support system.  The core
of this system is based on the existence of a setjmp/longjmp
facility.  In digging through the source code, I've found a
few, architechturally specific implementations of such a
facility, but no generalized, multi-platform support.

A FAQ I found seems to suggest this deliberate, and that such
support will not ever be added to Linux.  Am I correct in
my understanding?  If so, is an architechturally specific
implementation (such as was done for ppc) acceptable?

Thanks,
John S.

Re: Setjmp/Longjmp in the kernel?

[Alan Cox]

On Sun, 2003-02-09 at 22:10, John W. M. Stevens wrote:
> Among these is a simple exception support system.  The core
> of this system is based on the existence of a setjmp/longjmp
> facility.  In digging through the source code, I've found a
> few, architechturally specific implementations of such a
> facility, but no generalized, multi-platform support.

setjmp/longjmp are normally very hard to follow and maintain,
especially when the kernel has locks, sleeping rules and
multiple threads flying around.

You will see lots of code which does either


int foo_func()
{
	alloc this
	alloc that
	_foo_func()
	free this
	free that
}

or has a single exit path and uses goto out type constructs 

instead

Re: Setjmp/Longjmp in the kernel?

[Olaf Titz]

> int foo_func()
> {
> 	alloc this
> 	alloc that
> 	_foo_func()
> 	free this
> 	free that
> }

Not that this matters any bit, but the proper order is of course
 	alloc this
 	alloc that
 	_foo_func()
 	free that
 	free this

even if only for aesthetical reasons :-)

(with locks, it does matter...)

Olaf

Re: Setjmp/Longjmp in the kernel?

[Kasper Dupont]

Olaf Titz wrote:
> 
> Not that this matters any bit, but the proper order is of course
>         alloc this
>         alloc that
>         _foo_func()
>         free that
>         free this
> 
> even if only for aesthetical reasons :-)
> 
> (with locks, it does matter...)

For locks it is only when you lock the order matters, not when
you unlock. For allocations there is of course the possibility
that the first allocation suceeds and the second fails, which
you must handle in some way.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: Setjmp/Longjmp in the kernel?

[John W. M. Stevens]

On Wed, Feb 12, 2003 at 11:55:32AM +0100, Kasper Dupont wrote:
> Olaf Titz wrote:
> > 
> > Not that this matters any bit, but the proper order is of course
> >         alloc this
> >         alloc that
> >         _foo_func()
> >         free that
> >         free this
> > 
> > even if only for aesthetical reasons :-)
> > 
> > (with locks, it does matter...)
> 
> For locks it is only when you lock the order matters, not when
> you unlock. For allocations there is of course the possibility
> that the first allocation suceeds and the second fails, which
> you must handle in some way.

The usual way is with "pools".

Every resource allocated after a "mark" point gets dumped into
a separate pool, and then when processing returns to the mark
point, the pools are drained, one way or the other.

For locks, the pools are ordered, and you swim backwards through
the pool.

John S.