SBC with Power fail signal impending signal, to allow Linux to shutdown properly

SBC with Power fail signal impending signal, to allow Linux to shutdown properly

Post by Tiscal » Wed, 19 Mar 2003 17:13:32



Hello All
I would like some help, I am looking for a single board computer with a
Flash IDE socket (to boot Linux), that would give an early power fail
signal, or failing that, a SBC (possibly ITX) that runs from a single rail,
that would enable me to build my own power fail circuit, that would store
the supply long enough to shut Linux down in an orderly fashion.
Any pointers would be appreciated.

Thanks

Jeff Allan

 
 
 

SBC with Power fail signal impending signal, to allow Linux to shutdown properly

Post by Tiscal » Wed, 19 Mar 2003 22:37:02


Hello All
I would like some help, I am looking for a single board computer with a
Flash IDE socket (to boot Linux), that would give an early power fail
signal, or failing that, a SBC (possibly ITX) that runs from a single rail,
that would enable me to build my own power fail circuit, that would store
the supply long enough to shut Linux down in an orderly fashion.
Any pointers would be appreciated.

Thanks

Jeff Allan

 
 
 

1. Linux signal() semantics - can BSD signal() be emulated?

I'm porting a piece of software from our school's Sequent Dynix
(a BSD-style OS) to Linux.  This software relies fairly heavily
on signals, but apparently the semantics of signals differs
between Dynix and Linux.

The problem is that the software uses signals to implement a
threads-style abstraction with preemption, i.e. setitimer() is
used to set up a SIGVTALRM every so often, then a longjmp() is
done to move to a different thread.  Under Dynix, the new thread
will be preempted and the signal handler called when the SIGVTALRM
is generated again by the timer.

Linux, however, is a different story.  Under Linux, the signal
is blocked until the signal handler returns, and thus the thread
that "takes over" will run until completion or until it
voluntarily yields (i.e. longjmp()s back to the thread that was
running in the signal handler, which returns from the handler).

I have tried:

1)      Compiling with -I/usr/include/bsd & -D__FAVOR_BSD
2)      Linking with -lbsd
3)      Turning off the SA_ONESHOT flag in the sa_flags structure
        using sigaction().
4)      Most combinations of (1)-(3) above.

Questions:

a)      Is there another flag in sa_flags to set to emulate Dynix'
        (BSD-ish) signals?  Or compile flags or libraries to try?
b)      Is there any information about how signal handling and
        delivery in Linux work?  I poked around in the kernel for
        a while, but didn't make much headway.
c)      Do you have any other suggestions for BSD-like nonblocking
        signals?

Many thanks.  I'll summarize any answers I get (via posting or
email) to the net.

                        - Don (not speaking for UA)

2. DNS question?

3. Signal handlers are not reset after signal delivery

4. Apache CGI Spawn Problem

5. Signal handling: signal() vs. sigaction()

6. Forbidden _ You don't have permission...

7. blocking signals in signal handler -- True or False quiz

8. ppp connection

9. ** POSIX signals limited to 32 signals?

10. Registering signal inside signal handler

11. signal.c: wrong rt signals comment, 2.4.20-pre11

12. signal inside signal

13. trap "<new trap action>; $(get_old_trap SIGNAL)" SIGNAL