Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Sep 2002 13:20:22 -0700 (PDT)
From:      Juli Mallett <jmallett@FreeBSD.org>
To:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/alpha/osf1 osf1_signal.c src/sys/compat/linprocfs linprocfs.c src/sys/compat/linux linux_misc.c linux_signal.c src/sys/compat/svr4 svr4_filio.c svr4_signal.c src/sys/conf files src/sys/fs/procfs procfs_ctl.c src/sys/kern init_main.c ...
Message-ID:  <200209302020.g8UKKMRt092756@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
jmallett    2002/09/30 13:20:22 PDT

  Modified files:
    sys/alpha/osf1       osf1_signal.c 
    sys/compat/linprocfs linprocfs.c 
    sys/compat/linux     linux_misc.c linux_signal.c 
    sys/compat/svr4      svr4_filio.c svr4_signal.c 
    sys/conf             files 
    sys/fs/procfs        procfs_ctl.c 
    sys/kern             init_main.c kern_exit.c kern_fork.c 
                         kern_kthread.c kern_proc.c kern_sig.c 
                         subr_trap.c tty.c 
    sys/sys              proc.h 
  Added files:
    sys/kern             subr_sigq.c 
    sys/sys              ksiginfo.h 
  Log:
  First half of implementation of ksiginfo, signal queues, and such.  This
  gets signals operating based on a TailQ, and is good enough to run X11,
  GNOME, and do job control.  There are some intricate parts which could be
  more refined to match the sigset_t versions, but those require further
  evaluation of directions in which our signal system can expand and contract
  to fit our needs.
  
  After this has been in the tree for a while, I will make in kernel API
  changes, most notably to trapsignal(9) and sendsig(9), to use ksiginfo
  more robustly, such that we can actually pass information with our
  (queued) signals to the userland.  That will also result in using a
  struct ksiginfo pointer, rather than a signal number, in a lot of
  kern_sig.c, to refer to an individual pending signal queue member, but
  right now there is no defined behaviour for such.
  
  CODAFS is unfinished in this regard because the logic is unclear in
  some places.
  
  Sponsored by:   New Gold Technology
  Reviewed by:    bde, tjr, jake [an older version, logic similar]
  
  Revision  Changes    Path
  1.20      +2 -1      src/sys/alpha/osf1/osf1_signal.c
  1.56      +1 -1      src/sys/compat/linprocfs/linprocfs.c
  1.131     +2 -1      src/sys/compat/linux/linux_misc.c
  1.36      +2 -1      src/sys/compat/linux/linux_signal.c
  1.17      +3 -0      src/sys/compat/svr4/svr4_filio.c
  1.19      +1 -1      src/sys/compat/svr4/svr4_signal.c
  1.707     +1 -0      src/sys/conf/files
  1.45      +2 -1      src/sys/fs/procfs/procfs_ctl.c
  1.208     +2 -0      src/sys/kern/init_main.c
  1.178     +8 -1      src/sys/kern/kern_exit.c
  1.165     +1 -0      src/sys/kern/kern_fork.c
  1.25      +9 -8      src/sys/kern/kern_kthread.c
  1.155     +3 -2      src/sys/kern/kern_proc.c
  1.192     +36 -28    src/sys/kern/kern_sig.c
  1.1       +301 -0    src/sys/kern/subr_sigq.c (new)
  1.224     +3 -1      src/sys/kern/subr_trap.c
  1.186     +9 -5      src/sys/kern/tty.c
  1.1       +78 -0     src/sys/sys/ksiginfo.h (new)
  1.261     +1 -1      src/sys/sys/proc.h

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209302020.g8UKKMRt092756>