base: Create a central header listing all signals used within gem5

Information
Submitter:	Ali Saidi
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 9355:adc19edfa256
---------------------------
base: Create a central header listing all signals used within gem5

There is currently no central place where all signals used within gem5
are listed. This patch adds a header file and with a name space
containing constants for all signals used within gem5. This simplifies
the task of finding a non-conflicting signal when implementing new
functionality that requires signals.

Testing Done

Ship It!

What exactly is the point of this?  For those that know how signals work, this is just unnecessary confusion.  If you want to centralize all signal handlers, then move them.

Andreas Sandberg Nov. 7, 2012, 6:48 a.m. (Nov. 7, 2012, 6:48 a.m.)

This came about as a way to avoid having to grep through the entire source code to find unused signals when I was looking for a free signal to use to control hardware virtualization. I accidentally used both SIGTMR (it's not exactly obvious that/why we have a 1s timer ticking in the background) and SIGUSR1 before grepping for all calls that install signal handlers. I agree that the usefulness of this is currently somewhat limited since most of the signals have a well defined meaning (SIGTERM, SIGABT, SIGFPE, etc.). However, it will become more useful as we start to use other signals (e.g., for hardware virtualization).

Nathan Binkert Nov. 7, 2012, 7:14 a.m. (Nov. 7, 2012, 7:14 a.m.)

I'd much rather see all signal handling code centralized rather than defining nonstandard names for things (or provide a wrapper for signal(2) in such a way that we error out if there's already a handler).  It's an accident that we don't have all signal handlers in a single place anyway.

I'm not going to put my foot down or anything, but I really think you're replacing one confusion with another.

Steve Reinhardt Nov. 15, 2012, 9:52 a.m. (Nov. 15, 2012, 9:52 a.m.)

I'm with Nate on this one.  Unless we port to a non-POSIX OS this layer of abstraction is just overkill.  It seems like just doing all the signal handling in initSignals() should be enough centralization to avoid confusion.

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Status: Closed (submitted)