Re: 5.3-RELEASE bringt mir coredump (signal 6)

On Mon, Nov 15, 2004 at 03:52:59PM +1100, Peter Ross wrote:
> Bernd Walter wrote:
> > Naja - warum in signal(3), die nur eine Vereinfachung von sigaction(2)
> > ist und nicht dort?
> > OK - dort steht es bei FreeBSD »ebenfalls«.
> > Was ist mit den anderen Funktionen, die mit Signalabfangen zu tun
> > sigblock(2), sigpause(2), sigpending(2), sigprocmask(2), ...
> >
> > Oder wie wäre es mit Funktionen/Programmen die Signale auslösen kön
> > nen:
> > kill(1), kill(2), ualarm(3).
> > In kill(1) steht nur noch ein Auszug, in der dahinterliegenden C
> > Funktion kill(2) steht hingegen nichts mehr.
>
> signal(4) (oder (7))? Und die Systenrufe bekommen einen "SEE ALSO
> signal(x)" Eintrag.

Kat 4 sind Devices und Devicetreiber - da passt das nicht rein.
7 ist natürlich als Fallback immer geeignet.
Ich meine es ist sicherlich nicht verkehrt in kill(2) oder so
reinzupacken, aber überall ist schon irgendwie doof, zumal ich
in die zugehörigen Manpages normalerweise nicht reinschaue wenn ich
einen Namen eines Signals suche, sondern wenn mir die Syntax der
Funktion nicht klar ist.

> Die Signale sind nichts, was sich alle Tage aendert, und im allgemeinen

SIGTHR ist noch nicht so sehr alt - wird wohl kaum einer ohne
Hintergrundwissen nutzen, aber gehört letzlich der Vollständigkeit
halber dazu.
Man hat sich auch in der Vergangenheit unter anderem deswegen
zurückgehalten neue Signale zu definieren, weil es ein Limit auf 32
Stück gab - lagt IIRC an den 32 bitigen Masken.

> mag ich keine Funktionsbeschreibungen, die mir sagen, dass ich mit "aufruf
> $option" den Aufruf mit einer bestimmten Option taetigen kann, ohne zu
> sagen, was denn die Optionen sind.

Das finded sich zu hauf und ist auch gut so.
Ein Hinweis wo man die Informationen herbekommen kann ist aber
sicherlich nötig.
Das ist ein generelles Problem - errno Möglichkeiten sind auch
prinzipbedingt schon mal unvollständig beschrieben.
Bei Signalen kommt noch hinzu, dass die Kurzbeschreibungen nun
wirklich nicht eindeutig sind falls man noch nicht mit zu tun hatte.
Ich habe ja schon SIGQUIT und SIGABORT verglichen - der Unterschied
ist weder dem Namen noch der Beschreibung so richtig zu entnehmen.
Außerdem verschweigt die Manpage bereits jetzt, dass die Signale
in bestimmten Fällen nicht nutzbar sind, sprich die ganzen #ifdef
im header File.

> Es ist bestimmt kein Drama, mal in /usr/include nachzuschauen, aber es
> erfordert einige Kenntnis des Systems und auch des "richtigen Lesens" , um
> dort das Richtige zu finden. (Wer mal nach einer bestimmten Definition
> gesucht hat und dabei von Praeprozesser-Define-Klausel zu Klausel, von
> #include zu #include gehuepft ist, wird das bestaetigen).

Bei solchen defines geht es in der Regel nur bis in sys/foo.h.

> Schoener ist es, wenn die manpages in sich geschlossen alle Informationen
> enthalten, die fuer den Anwender wichtig sind.
>
> Der Aufruf von kill(1) gehoert schon fast zu einer Unix-Einfuehrung dazu,
> dort kann ich noch kein detailiertes Wissen ueber include-Files
> voraussetzen.

Ein Unixadmin sollte Programmieren können und ein einfacher Unix Anwender
braucht weder Detailkenntnisse über alle Signale noch wird er bewusst
Kategorie 3 Manpages lesen.
Ich denke für den normalen Anwender sind die Angaben in kill(1) schon
ausreichend.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message