Date: Sat, 7 Sep 2002 20:41:33 -0400 From: Mike Barcroft <mike@FreeBSD.org> To: Juli Mallett <jmallett@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha machdep.c src/sys/i386/i386 machdep.c src/sys/ia64/ia64 machdep.c src/sys/pc98/i386 machdep.c src/sys/sparc64/sparc64 machdep.c Message-ID: <20020907204132.J47192@espresso.q9media.com> In-Reply-To: <20020907163423.A14528@FreeBSD.org>; from jmallett@FreeBSD.org on Sat, Sep 07, 2002 at 04:34:23PM -0700 References: <200209071912.g87JCs0I062248@freefall.freebsd.org> <20020907163423.A14528@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Juli Mallett <jmallett@FreeBSD.org> writes: > Note that until everything is refactored as I want, I can't make these > fields "honest", about who's sending the signal, just about who the signal > is being delivered to. I'm now torn, do I want to continue to push just > to break the kernel API for signal senders, or do I want to push to also > use siginfo's instead of signal numbers, in the kernel? This would allow > code sending signals to send *much* more information, too. SVR4 uses > siginfo much more "nicely" than we use things, I think. Being able to > get meaningful information is very nice. I'd like to see p_xstat replaced with a p_xsiginfo in struct proc to help facilitate waitid(2). I think the extra information provided by siginfo_t would be useful for debugging large applications that have many processes. If using siginfo_t's instead of plain int's helps facilitate other POSIX interfaces, the 56 byte overhead (on ILP32) isn't much to pay. Best regards, Mike Barcroft 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?20020907204132.J47192>