Date: Mon, 30 Sep 2002 18:08:37 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Juli Mallett <jmallett@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: 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: <20021001010837.GB61347@dragon.nuxi.com> In-Reply-To: <200210010007.g9107Tkb058991@freefall.freebsd.org> References: <200210010007.g9107Tkb058991@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 30, 2002 at 05:07:29PM -0700, Juli Mallett wrote: > jmallett 2002/09/30 17:07:28 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 subr_sigq.c > sys/sys ksiginfo.h proc.h > Log: > (Forced commit, to clarify previous commit of ksiginfo/signal queue code.) > > I've added a structure, kernel-private, to represent a pending or in-delivery > signal, called `ksiginfo'. It is roughly analogous to the basic information > that is exported by the POSIX interface 'siginfo_t', but more basic. I've > added functions to allocate these structures, and further to wrap all signal > operations using them. I think you broke world with this commit. But that aside, what does this gain us? Where was it discussed that this was a good direction to go in? I don't recall seeing it on arch@. I don't recall a patch being posted to arch@. We *just* had a thread about the need to stabilize 5-CURRENT, and now we have a commit to very low-level infrastructure. This has the potential to FUBAR signals all over again. AND now we aren't going to know if its KSE or juli-signals that is the cause. Is there really sufficient time to get these changes panned out and stabilized by 5.0-RELEASE? Perhaps they should live in a perforce branch for a while. 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?20021001010837.GB61347>