From owner-freebsd-arch Tue Oct 1 1:24: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7658937B407 for ; Tue, 1 Oct 2002 01:23:58 -0700 (PDT) Received: from mx7.mail.ru (mx7.mail.ru [194.67.57.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5932D43E3B for ; Tue, 1 Oct 2002 01:23:57 -0700 (PDT) (envelope-from jobforu@bk.ru) Received: from drweb by mx7.mail.ru with drweb-scanned (Exim MX.7) id 17wIJw-0003Df-00 for freebsd-arch@freebsd.org; Tue, 01 Oct 2002 12:23:56 +0400 Received: from [81.25.2.62] (helo=jobforU) by mx7.mail.ru with smtp (Exim SMTP.7) id 17wIJv-00037h-00 for freebsd-arch@freebsd.org; Tue, 01 Oct 2002 12:23:55 +0400 From: "footman" To: freebsd-arch@freebsd.org Subject: Ðàáîòà â ñåòè. X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Reply-To: jobForU@bk.ru Date: Tue, 1 Oct 2002 12:22:54 +0300 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-Envelope-To: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Çäðàâñòâóéòå. Äî÷èòàéòå äî êîíöà, îáåùàåì, Âàì ïîíðàâèòñÿ. Ïðåäëîæåíèå îò GoldenStream Ïðåäëàãàåì ðàáîòó, êîòîðàÿ áóäåò ïðèíîñèòü Âàì óäîâîëüñòâèå è äîõîä (òîëüêî âåëè÷èíà äîõîäîâ áóäåò íàïðÿìóþ çàâèñåòü îò âàøåé àêòèâíîñòè: áóäåòå ìíîãî ñóåòèòüñÿ – áóäåò ìíîãî äåíåã). Ñóòü ðàáîòû çàêëþ÷àåòñÿ â ðàññûëêå E-MAIL. ÂÑÅ, ×ÒÎ ÂÀÌ ÍÓÆÍÎ ÁÓÄÅÒ ÄÅËÀÒÜ, ÝÒÎ ÐÀÑÑÛËÀÒÜ ÃÎÒÎÂÛÅ ÏÈÑÜÌÀ ÏÎ E-MAIL, È ÂÐÅÌß ÎÒ ÂÐÅÌÅÍÈ ÕÎÄÈÒÜ ÍÀ ÏÎ×ÒÓ ÈËÈ Â ÁÀÍÊ ÇÀ ÄÅÍÜÃÀÌÈ! Ýòîò ïðîåêò ïðèîáðåë îãðîìíóþ ïîïóëÿðíîñòü âî âñåì ìèðå. À ó íàñ â Ðîññèè îí òîëüêî ïîÿâèëñÿ. Ãëàâíîå ïðåèìóùåñòâî - Ìàêñèìàëüíàÿ ïðîñòîòà, è ëåãàëüíîñòü. Ñàìàÿ íèçêàÿ ñåáåñòîèìîñòü çàòðàò çàðàáîòêà â Èíòåðíåòå. ×òîáû âñ¸ ïîëó÷èëîñü, ÍÓÆÍÎ ÒÎËÜÊÎ ÒÎ×ÍÎ ÑËÅÄÎÂÀÒÜ ÈÍÑÒÐÓÊÖÈßÌ. Êàê îáåùàþò: «100 000$ çà 6 ìåñÿöåâ», íå çíàþ, åù¸ íå ïðîâåðèë, íî 1000$ â ìåñÿö äëÿ íà÷àëà – «çåð ãóä, Âàëüäåìàð». Åñëè çàèíòåðåñóåòåñü, íå çàèíòåðåñóåòåñü èëè ïðîñòî òàê – ïèøèòå: job4U@bk.ru Ñ óâàæåíèåì. footman P.S. Åñëè íå õîòèòå, òî ïðîñòî óäàëèòå, à ìàòþêè íå øëèòå è ñïîêîéíî ñïèòå. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 1 8: 4:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7FA537B401 for ; Tue, 1 Oct 2002 08:04:56 -0700 (PDT) Received: from dmlb.org (pc1-cmbg2-6-cust106.cam.cable.ntl.com [80.4.4.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3976443E6A for ; Tue, 1 Oct 2002 08:04:56 -0700 (PDT) (envelope-from dmlb@dmlb.org) Received: from slave.my.domain ([192.168.200.39]) by dmlb.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 17wOZy-0002sX-00; Tue, 01 Oct 2002 16:04:54 +0100 Received: from dmlb by slave.my.domain with local (Exim 3.36 #1) id 17wOZy-000AQm-00; Tue, 01 Oct 2002 16:04:54 +0100 Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 01 Oct 2002 16:04:53 +0100 (BST) From: Duncan Barclay To: footman Subject: Re: XXXXXX X XXXX. Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 01-Oct-2002 footman wrote: > > Çäðàâñòâóéòå. > > Äî÷èòàéòå äî êîíöà, îáåùàåì, Âàì ïîíðàâèòñÿ. Ïðåäëîæåíèå îò GoldenStream > > Ïðåäëàãàåì ðàáîòó, êîòîðàÿ áóäåò ïðèíîñèòü Âàì óäîâîëüñòâèå è äîõîä (òîëüêî > âåëè÷èíà äîõîäîâ áóäåò íàïðÿìóþ çàâèñåòü îò âàøåé àêòèâíîñòè: áóäåòå ìíîãî > ñóåòèòüñÿ – áóäåò ìíîãî äåíåã). > Ñóòü ðàáîòû çàêëþ÷àåòñÿ â ðàññûëêå E-MAIL. ÂÑÅ, ×ÒÎ ÂÀÌ ÍÓÆÍÎ ÁÓÄÅÒ ÄÅËÀÒÜ, > ÝÒÎ ÐÀÑÑÛËÀÒÜ ÃÎÒÎÂÛÅ ÏÈÑÜÌÀ ÏÎ E-MAIL, È ÂÐÅÌß ÎÒ ÂÐÅÌÅÍÈ ÕÎÄÈÒÜ ÍÀ ÏÎ×ÒÓ > ÈËÈ Â ÁÀÍÊ ÇÀ ÄÅÍÜÃÀÌÈ! > Ýòîò ïðîåêò ïðèîáðåë îãðîìíóþ ïîïóëÿðíîñòü âî âñåì ìèðå. À ó íàñ â Ðîññèè îí > òîëüêî ïîÿâèëñÿ. Ãëàâíîå ïðåèìóùåñòâî - Ìàêñèìàëüíàÿ ïðîñòîòà, è ëåãàëüíîñòü. > Ñàìàÿ íèçêàÿ ñåáåñòîèìîñòü çàòðàò çàðàáîòêà â Èíòåðíåòå. > ×òîáû âñ¸ ïîëó÷èëîñü, ÍÓÆÍÎ ÒÎËÜÊÎ ÒÎ×ÍÎ ÑËÅÄÎÂÀÒÜ ÈÍÑÒÐÓÊÖÈßÌ. > > Êàê îáåùàþò: «100 000$ çà 6 ìåñÿöåâ», íå çíàþ, åù¸ íå ïðîâåðèë, íî 1000$ â > ìåñÿö äëÿ íà÷àëà – «çåð ãóä, Âàëüäåìàð». > > Åñëè çàèíòåðåñóåòåñü, íå çàèíòåðåñóåòåñü èëè ïðîñòî òàê – ïèøèòå: job4U@bk.ru > > Ñ óâàæåíèåì. > footman > > P.S. Åñëè íå õîòèòå, òî ïðîñòî óäàëèòå, à ìàòþêè íå øëèòå è ñïîêîéíî ñïèòå. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > -- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@dmlb.org | the alcoholics, and the permanently stoned. dmlb@freebsd.org| Steven King To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 1 8:13:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF97337B401 for ; Tue, 1 Oct 2002 08:13:51 -0700 (PDT) Received: from dmlb.org (pc1-cmbg2-6-cust106.cam.cable.ntl.com [80.4.4.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 556EF43E3B for ; Tue, 1 Oct 2002 08:13:51 -0700 (PDT) (envelope-from dmlb@dmlb.org) Received: from slave.my.domain ([192.168.200.39]) by dmlb.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 17wOib-0002tM-00 for freebsd-arch@freebsd.org; Tue, 01 Oct 2002 16:13:50 +0100 Received: from dmlb by slave.my.domain with local (Exim 3.36 #1) id 17wOib-000AR2-00 for freebsd-arch@freebsd.org; Tue, 01 Oct 2002 16:13:49 +0100 Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 01 Oct 2002 16:13:49 +0100 (BST) From: Duncan Barclay To: freebsd-arch@freebsd.org Subject: Apologies Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Re: XXXXXX X XXXX. Sorry, hit the reply button instead of move to spam folder. Duncan -- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@dmlb.org | the alcoholics, and the permanently stoned. dmlb@freebsd.org| Steven King To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 1 9:37:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4236637B401 for ; Tue, 1 Oct 2002 09:37:20 -0700 (PDT) Received: from dmlb.org (pc1-cmbg2-6-cust106.cam.cable.ntl.com [80.4.4.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA3D843E77 for ; Tue, 1 Oct 2002 09:37:19 -0700 (PDT) (envelope-from dmlb@dmlb.org) Received: from slave.my.domain ([192.168.200.39]) by dmlb.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 17wQ1M-00030J-00; Tue, 01 Oct 2002 17:37:16 +0100 Received: from dmlb by slave.my.domain with local (Exim 3.36 #1) id 17wQ1M-000AjI-00; Tue, 01 Oct 2002 17:37:16 +0100 Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <00a701c26968$0449b5d0$3600010a@caymas.com> Date: Tue, 01 Oct 2002 17:37:16 +0100 (BST) From: Duncan Barclay To: David Francheski Subject: RE: Apologies Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 01-Oct-2002 David Francheski wrote: > Hi Duncan, > > I don't know if you can help me or not. > I've successfully subscribed to freebsd-arch, but for some reason when > I attempt to post/send a message to freebsd-arch, it's immediately > rejected > With the following message (see below). It looks like the list is rejecting your mail servers (or the people that you are relying through). You should contact postmaster@freebsd.org for help. Also, people on the lists will not like HTML mail. Please post plain text. > Can you help me with this? > Appreciate it, > > Sincerely, > David L. Francheski > -- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@dmlb.org | the alcoholics, and the permanently stoned. dmlb@freebsd.org| Steven King To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 1 11:44:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F060137B401; Tue, 1 Oct 2002 11:44:24 -0700 (PDT) Received: from smtpariane.oleane.net (smtpariane.oleane.net [195.25.12.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 036D943E42; Tue, 1 Oct 2002 11:44:23 -0700 (PDT) (envelope-from kamion@oleane.net) Received: from s2.ws.oleane.net (s2.ws.oleane.net [194.2.28.18]) by smtpariane.oleane.net with ESMTP id g91IiL922444; Tue, 1 Oct 2002 20:44:21 +0200 Received: (from kamion@localhost) by s2.ws.oleane.net (8.9.3/8.9.3/Debian 8.9.3-21) id UAA17367; Tue, 1 Oct 2002 20:44:22 +0200 Date: Tue, 1 Oct 2002 20:44:22 +0200 Message-Id: <200210011844.UAA17367@s2.ws.oleane.net> To: , www.chapodo.com@FreeBSD.ORG, , www.chapodo.com@FreeBSD.ORG, , www.chapodo.com@FreeBSD.ORG, , www.chapodo.com@FreeBSD.ORG, , www.chapodo.com@FreeBSD.ORG From: johnettaqjm@aaris.net (johnettaqjm@aaris.net) Subject: Hiya! Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Voici le résultat du formulaire envoyé par johnettaqjm@aaris.net (johnettaqjm@aaris.net) le Mardi, Octobre 1, 2002 at 20:44:22 --------------------------------------------------------------------------- bw: Hey! Here's my pic! It's REALLY private, so PLEASE just keep it between us, Click here http://rd.yahoo.com/64tjpyq/*http://members.aol.com/zoe6362/Nancy.exe AOL users click here! :) 36w 71 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 4 15:41:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C8DF37B401 for ; Fri, 4 Oct 2002 15:41:09 -0700 (PDT) Received: from phalanx.trit.org (phalanx.trit.org [63.198.170.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61A9743E42 for ; Fri, 4 Oct 2002 15:41:08 -0700 (PDT) (envelope-from dima@trit.org) Received: from harpoon.trit.org (harpoon.trit.org [192.168.4.193]) by phalanx.trit.org (Postfix) with ESMTP id A8AF8D603 for ; Fri, 4 Oct 2002 22:41:07 +0000 (UTC) Received: from harpoon.trit.org (localhost [127.0.0.1]) by harpoon.trit.org (8.12.5/8.12.5) with ESMTP id g94Meson000552 for ; Fri, 4 Oct 2002 22:41:03 GMT (envelope-from dima@trit.org) Received: (from dima@localhost) by harpoon.trit.org (8.12.5/8.12.5/Submit) id g94MepkH000551 for arch@freebsd.org; Fri, 4 Oct 2002 22:40:51 GMT X-Authentication-Warning: harpoon.trit.org: dima set sender to dima@trit.org using -f Date: Fri, 4 Oct 2002 22:40:51 +0000 From: Dima Dorfman To: arch@freebsd.org Subject: fnmatch() in the kernel Message-ID: <20021004224006.GA304@trit.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The DEVFS rule subsystem has a need for glob-style pattern matching in the kernel (so you can specify a pattern to describe which devices you want your rule to match). To effect this, I would like to import fnmatch(3) into the kernel. Would libkern be a good place for it? Attached are the diff to libkern.h and the diff between the kernel fnmatch.c and the userland fnmatch.c. If anybody has objections to this or thinks it should go somewhere else, please speak up. The overhead for having this in the kernel is ~1 kB of text on i386, so I do not plan to make this optional (esp. since it will be used by DEVFS). On a procedural note, should I ask for a repo-copy of lib/libc/gen/fnmatch.c to sys/libkern/fnmatch.c, or is this not necessary in this case? (I think it is appropriate, but I don't recall ever seeing something like this done.) Thanks, Dima. Index: sys/libkern.h =================================================================== RCS file: /ref/cvsf/src/sys/sys/libkern.h,v retrieving revision 1.31 diff -u -r1.31 libkern.h --- sys/libkern.h 2 Sep 2002 20:16:22 -0000 1.31 +++ sys/libkern.h 4 Oct 2002 21:40:16 -0000 @@ -74,6 +74,7 @@ #ifndef HAVE_INLINE_FLS int fls(int); #endif +int fnmatch(const char *, const char *, int); int locc(int, char *, u_int); void qsort(void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *)); @@ -112,5 +113,17 @@ *bb++ = c; return (b); } + +/* fnmatch() return values. */ +#define FNM_NOMATCH 1 /* Match failed. */ + +/* fnmatch() flags. */ +#define FNM_NOESCAPE 0x01 /* Disable backslash escaping. */ +#define FNM_PATHNAME 0x02 /* Slash must be matched by slash. */ +#define FNM_PERIOD 0x04 /* Period must be matched by period. */ +#define FNM_LEADING_DIR 0x08 /* Ignore / after Imatch. */ +#define FNM_CASEFOLD 0x10 /* Case insensitive search. */ +#define FNM_IGNORECASE FNM_CASEFOLD +#define FNM_FILE_NAME FNM_PATHNAME #endif /* !_SYS_LIBKERN_H_ */ --- ../../lib/libc/gen/fnmatch.c Fri Feb 1 01:32:19 2002 +++ fnmatch.c Fri Oct 4 21:51:24 2002 @@ -32,25 +32,18 @@ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. + * + * $FreeBSD$ */ -#if defined(LIBC_SCCS) && !defined(lint) -static char sccsid[] = "@(#)fnmatch.c 8.2 (Berkeley) 4/16/94"; -#endif /* LIBC_SCCS and not lint */ -#include -__FBSDID("$FreeBSD$"); - /* * Function fnmatch() as specified in POSIX 1003.2-1992, section B.6. * Compares a filename or pathname to a pattern. */ -#include -#include -#include -#include - -#include "collate.h" +#include +#include +#include #define EOS '\0' @@ -101,12 +94,12 @@ if (c == EOS) if (flags & FNM_PATHNAME) return ((flags & FNM_LEADING_DIR) || - strchr(string, '/') == NULL ? + index(string, '/') == NULL ? 0 : FNM_NOMATCH); else return (0); else if (c == '/' && flags & FNM_PATHNAME) { - if ((string = strchr(string, '/')) == NULL) + if ((string = index(string, '/')) == NULL) return (FNM_NOMATCH); break; } @@ -218,16 +211,12 @@ if (flags & FNM_CASEFOLD) c2 = tolower((unsigned char)c2); - if (__collate_load_error ? - c <= test && test <= c2 : - __collate_range_cmp(c, test) <= 0 - && __collate_range_cmp(test, c2) <= 0 - ) + if (c <= test && test <= c2) ok = 1; } else if (c == test) ok = 1; } while ((c = *pattern++) != ']'); - *newp = (char *)pattern; + *newp = (char *)(uintptr_t)pattern; return (ok == negate ? RANGE_NOMATCH : RANGE_MATCH); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 4 16:14:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 813FA37B401 for ; Fri, 4 Oct 2002 16:14:11 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C73DE43E4A for ; Fri, 4 Oct 2002 16:14:10 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g94N04s7006417; Fri, 4 Oct 2002 16:00:04 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g94N04s2006416; Fri, 4 Oct 2002 16:00:04 -0700 Date: Fri, 4 Oct 2002 16:00:04 -0700 From: Brooks Davis To: Dima Dorfman Cc: arch@FreeBSD.ORG Subject: Re: fnmatch() in the kernel Message-ID: <20021004160004.A2051@Odin.AC.HMC.Edu> References: <20021004224006.GA304@trit.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021004224006.GA304@trit.org>; from dima@trit.org on Fri, Oct 04, 2002 at 10:40:51PM +0000 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 04, 2002 at 10:40:51PM +0000, Dima Dorfman wrote: > The DEVFS rule subsystem has a need for glob-style pattern matching in > the kernel (so you can specify a pattern to describe which devices you > want your rule to match). To effect this, I would like to import > fnmatch(3) into the kernel. Would libkern be a good place for it? > Attached are the diff to libkern.h and the diff between the kernel > fnmatch.c and the userland fnmatch.c. If anybody has objections to > this or thinks it should go somewhere else, please speak up. This will also be useful for ipfw2 post if_xname. > On a procedural note, should I ask for a repo-copy of > lib/libc/gen/fnmatch.c to sys/libkern/fnmatch.c, or is this not > necessary in this case? (I think it is appropriate, but I don't > recall ever seeing something like this done.) That's what we did for strlc{at,py}. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9nh1zXY6L6fI4GtQRAp4OAJ0WVkVXhjqkC2y37gqSCytk+JqM7ACeNG3C ppD8spisrmQA6iUXuf6JUEk= =4fFo -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 4 17: 9:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6499737B404; Fri, 4 Oct 2002 17:09:11 -0700 (PDT) Received: from smtp1.electric.net (smtp1.electric.net [216.129.90.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72ECB43E75; Fri, 4 Oct 2002 17:09:10 -0700 (PDT) (envelope-from davidf@caymas.com) Received: from hm1.electric.net ([216.129.90.33]) by smtp1.electric.net with smtp (Exim 4.04) id 17xcVF-0003Or-8H; Fri, 04 Oct 2002 17:09:05 -0700 Received: from osmtp3.electric.net ([216.129.90.30]) by hm1.electric.net (NAVGW 2.5.2.12) with SMTP id M2002100417090514475 ; Fri, 04 Oct 2002 17:09:05 -0700 Received: from [216.210.192.146] (helo=DAVIDFW2K) by osmtp3.electric.net with asmtp (Exim 3.22 #1) id 17xcVE-0008qk-04; Fri, 04 Oct 2002 17:09:04 -0700 Reply-To: From: "David Francheski" To: , Cc: Subject: Running independent kernel instances on dual-Xeon/E7500 system Date: Fri, 4 Oct 2002 17:08:55 -0700 Organization: Caymas Systems Message-ID: <006001c26c03$6a6e2420$3600010a@caymas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a dual-Xeon processor (with E7500 chipset) motherboard. Can anybody tell me what the development effort would be to boot and run two independent copies of the FreeBSD kernel, one on each Xeon processor? By this I mean that an SMP enabled kernel would not be utilized, each kernel would be UP. Regards, David L. Francheski To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 4 17:22:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60B5537B401 for ; Fri, 4 Oct 2002 17:22:24 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id EBC8543E81 for ; Fri, 4 Oct 2002 17:22:23 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 96231 invoked by uid 1000); 5 Oct 2002 00:22:25 -0000 Date: Fri, 4 Oct 2002 17:22:25 -0700 (PDT) From: Nate Lawson To: David Francheski Cc: freebsd-arch@FreeBSD.ORG, freebsd-smp@FreeBSD.org Subject: Re: Running independent kernel instances on dual-Xeon/E7500 system In-Reply-To: <006001c26c03$6a6e2420$3600010a@caymas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 4 Oct 2002, David Francheski wrote: > I have a dual-Xeon processor (with E7500 chipset) motherboard. > Can anybody tell me what the development effort would be to > boot and run two independent copies of the FreeBSD kernel, > one on each Xeon processor? By this I mean that an SMP > enabled kernel would not be utilized, each kernel would be UP. > > Regards, > David L. Francheski Not possible without another BIOS, PCI bus, and separate memory -- i.e. another PC. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 4 23: 6:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E36C737B401 for ; Fri, 4 Oct 2002 23:06:20 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D24A43E75 for ; Fri, 4 Oct 2002 23:06:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9566EpS079477; Sat, 5 Oct 2002 08:06:15 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Dima Dorfman Cc: arch@FreeBSD.ORG Subject: Re: fnmatch() in the kernel In-Reply-To: Your message of "Fri, 04 Oct 2002 22:40:51 -0000." <20021004224006.GA304@trit.org> Date: Sat, 05 Oct 2002 08:06:14 +0200 Message-ID: <79476.1033797974@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20021004224006.GA304@trit.org>, Dima Dorfman writes: >The DEVFS rule subsystem has a need for glob-style pattern matching in >the kernel (so you can specify a pattern to describe which devices you >want your rule to match). To effect this, I would like to import >fnmatch(3) into the kernel. Would libkern be a good place for it? I think so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 0:20:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 1839D37B401; Sat, 5 Oct 2002 00:20:22 -0700 (PDT) Date: Sat, 5 Oct 2002 00:20:22 -0700 From: Juli Mallett To: arch@FreeBSD.org Subject: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021005002021.A14635@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patch description: Make the kernel use reliable signal queues, of a type which provides information on the source of the signal source, sufficient to provide RTS siginfo_t exporting. Signal senders now operate using these info structures, structs called 'ksiginfo', which have been dequeued before being sent. The p_sig and p_code fields have gone away, though their use could *possibly* be replaced by taking the head of the signal queue, in the case of dumping core files, though I am not entirely sure. To accomodate situations where allocation of a 'ksiginfo' is a failure mode (no memory), the destination process is told to exit via a new member of 'struct proc', p_suicide, which tells a process to kill itself next time it goes through userret. It is done this way to prevent a recursive failure case, and to prevent possibly dying with extraneous locks held, as signals are sent from odd places of the kernel. Only i386-related machdep changes are included for the signal senders, but the changes are small enough that I will make them before commit. Testing: Tested on i386 only, but the changes are mostly MI or exact between architectures. I have run this on both my desktop/laptop and on our house fileserver. In the process of stressing signals and edge cases, I've actually managed to run into a few other bugs, but none in this code. I've run a ton of native binaries, including things like GNOME2 and X11. I've also run a good deal of Linux binaries, such as xski, simnow, etc. Also some binary-only FreeBSD applications like p4 and p4d. So far I have yet to run into a kernel or user-space failure case that I have not addressed. Imprvements over what was committed: Various sundry, including some style changes to the subr_sigq.c and ksiginfo.h files from bde. The most notable change is that the most recently sent && lowest numbered signal is sent, in the normal course of events, rather than simply the lowest numbered or most recently sent. This [seems to] satisfy the RTS rules about which signals are delivered first, at least as explained by Garrett Wollman. I have not implemented any KSE-related or userland RTS-related features, though this should *ehlp* both things, and I'm willing to do such. %%% diff -Nrdu -x *CVS* -x *dev* sys/alpha/osf1/osf1_signal.c kernel/alpha/osf1/osf1_signal.c --- sys/alpha/osf1/osf1_signal.c Tue Oct 1 12:15:46 2002 +++ kernel/alpha/osf1/osf1_signal.c Sat Oct 5 01:18:21 2002 @@ -30,7 +30,7 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $FreeBSD: src/sys/alpha/osf1/osf1_signal.c,v 1.22 2002/10/01 17:15:46 jmallett Exp $ + * $FreeBSD: src/sys/alpha/osf1/osf1_signal.c,v 1.21 2002/10/01 00:07:25 jmallett Exp $ */ #include @@ -46,6 +46,7 @@ #include #include #include +#include #include #include #include @@ -523,7 +524,7 @@ p = td->td_proc; PROC_LOCK(p); - bss = p->p_siglist; + ksiginfo_to_sigset_t(p, &bss); SIGSETAND(bss, p->p_sigmask); PROC_UNLOCK(p); bsd_to_osf1_sigset(&bss, &oss); diff -Nrdu -x *CVS* -x *dev* sys/compat/linprocfs/linprocfs.c kernel/compat/linprocfs/linprocfs.c --- sys/compat/linprocfs/linprocfs.c Tue Oct 1 12:15:49 2002 +++ kernel/compat/linprocfs/linprocfs.c Sat Oct 5 01:18:43 2002 @@ -38,7 +38,7 @@ * * @(#)procfs_status.c 8.4 (Berkeley) 6/15/94 * - * $FreeBSD: src/sys/compat/linprocfs/linprocfs.c,v 1.58 2002/10/01 17:15:49 jmallett Exp $ + * $FreeBSD: src/sys/compat/linprocfs/linprocfs.c,v 1.57 2002/10/01 00:07:25 jmallett Exp $ */ #include @@ -651,7 +651,7 @@ * running on anything but i386, so ignore that for now. */ PROC_LOCK(p); - sbuf_printf(sb, "SigPnd:\t%08x\n", p->p_siglist.__bits[0]); + sbuf_printf(sb, "SigPnd:\t%08x\n", 0); /* XXX */ /* * I can't seem to find out where the signal mask is in * relation to struct proc, so SigBlk is left unimplemented. diff -Nrdu -x *CVS* -x *dev* sys/compat/linux/linux_misc.c kernel/compat/linux/linux_misc.c --- sys/compat/linux/linux_misc.c Tue Oct 1 12:15:50 2002 +++ kernel/compat/linux/linux_misc.c Sat Oct 5 01:18:44 2002 @@ -25,7 +25,7 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $FreeBSD: src/sys/compat/linux/linux_misc.c,v 1.133 2002/10/01 17:15:50 jmallett Exp $ + * $FreeBSD: src/sys/compat/linux/linux_misc.c,v 1.132 2002/10/01 00:07:25 jmallett Exp $ */ #include "opt_mac.h" @@ -36,6 +36,7 @@ #include #include #include +#include #include #include #include @@ -806,6 +807,7 @@ int linux_wait4(struct thread *td, struct linux_wait4_args *args) { + struct proc *p; struct wait_args /* { int pid; int *status; @@ -821,6 +823,8 @@ (void *)args->rusage); #endif + p = td->td_proc; + tmp.pid = args->pid; tmp.status = args->status; tmp.options = (args->options & (WNOHANG | WUNTRACED)); @@ -832,7 +836,9 @@ if ((error = wait4(td, &tmp)) != 0) return error; - SIGDELSET(td->td_proc->p_siglist, SIGCHLD); + PROC_LOCK(p); + signal_delete(p, NULL, SIGCHLD); + PROC_UNLOCK(p); if (args->status) { if ((error = copyin((caddr_t)args->status, &tmpstat, diff -Nrdu -x *CVS* -x *dev* sys/compat/linux/linux_signal.c kernel/compat/linux/linux_signal.c --- sys/compat/linux/linux_signal.c Tue Oct 1 12:15:50 2002 +++ kernel/compat/linux/linux_signal.c Sat Oct 5 01:18:44 2002 @@ -25,7 +25,7 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $FreeBSD: src/sys/compat/linux/linux_signal.c,v 1.38 2002/10/01 17:15:50 jmallett Exp $ + * $FreeBSD: src/sys/compat/linux/linux_signal.c,v 1.37 2002/10/01 00:07:25 jmallett Exp $ */ #include @@ -34,6 +34,7 @@ #include #include #include +#include #include #include @@ -390,7 +391,7 @@ #endif PROC_LOCK(p); - bset = p->p_siglist; + ksiginfo_to_sigset_t(p, &bset); SIGSETAND(bset, p->p_sigmask); bsd_to_linux_sigset(&bset, &lset); PROC_UNLOCK(p); diff -Nrdu -x *CVS* -x *dev* sys/compat/svr4/svr4_filio.c kernel/compat/svr4/svr4_filio.c --- sys/compat/svr4/svr4_filio.c Tue Oct 1 12:15:50 2002 +++ kernel/compat/svr4/svr4_filio.c Sat Oct 5 01:18:45 2002 @@ -25,7 +25,7 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $FreeBSD: src/sys/compat/svr4/svr4_filio.c,v 1.19 2002/10/01 17:15:50 jmallett Exp $ + * $FreeBSD: src/sys/compat/svr4/svr4_filio.c,v 1.18 2002/10/01 00:07:26 jmallett Exp $ */ #include @@ -39,6 +39,7 @@ #include #include #include +#include #include @@ -135,7 +136,9 @@ DPRINTF(("sigmask = 0x%x\n", td->td_proc->p_sigmask)); DPRINTF(("sigignore = 0x%x\n", td->td_proc->p_sigignore)); DPRINTF(("sigcaught = 0x%x\n", td->td_proc->p_sigcatch)); +#if 0 /* XXX - use ksiginfo_to_sigset_t ? */ DPRINTF(("siglist = 0x%x\n", td->td_proc->p_siglist)); +#endif } #if defined(GROTTY_READ_HACK) diff -Nrdu -x *CVS* -x *dev* sys/compat/svr4/svr4_signal.c kernel/compat/svr4/svr4_signal.c --- sys/compat/svr4/svr4_signal.c Tue Oct 1 12:15:50 2002 +++ kernel/compat/svr4/svr4_signal.c Sat Oct 5 01:18:46 2002 @@ -25,7 +25,7 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $FreeBSD: src/sys/compat/svr4/svr4_signal.c,v 1.21 2002/10/01 17:15:50 jmallett Exp $ + * $FreeBSD: src/sys/compat/svr4/svr4_signal.c,v 1.20 2002/10/01 00:07:26 jmallett Exp $ */ #include @@ -565,7 +565,7 @@ if (SCARG(uap, mask) == NULL) return 0; PROC_LOCK(td->td_proc); - bss = td->td_proc->p_siglist; + ksiginfo_to_sigset_t(td->td_proc, &bss); SIGSETAND(bss, td->td_proc->p_sigmask); PROC_UNLOCK(td->td_proc); bsd_to_svr4_sigset(&bss, &sss); diff -Nrdu -x *CVS* -x *dev* sys/fs/procfs/procfs_ctl.c kernel/fs/procfs/procfs_ctl.c --- sys/fs/procfs/procfs_ctl.c Tue Oct 1 12:15:51 2002 +++ kernel/fs/procfs/procfs_ctl.c Sat Oct 5 01:20:20 2002 @@ -38,7 +38,7 @@ * * From: * $Id: procfs_ctl.c,v 3.2 1993/12/15 09:40:17 jsp Exp $ - * $FreeBSD: src/sys/fs/procfs/procfs_ctl.c,v 1.47 2002/10/01 17:15:51 jmallett Exp $ + * $FreeBSD: src/sys/fs/procfs/procfs_ctl.c,v 1.46 2002/10/01 00:07:26 jmallett Exp $ */ #include @@ -51,6 +51,7 @@ #include #include #include +#include #include #include @@ -221,7 +222,7 @@ p->p_flag &= ~P_TRACED; /* remove pending SIGTRAP, else the process will die */ - SIGDELSET(p->p_siglist, SIGTRAP); + signal_delete(p, NULL, SIGTRAP); PROC_UNLOCK(p); /* give process back to original parent */ diff -Nrdu -x *CVS* -x *dev* sys/i386/i386/machdep.c kernel/i386/i386/machdep.c --- sys/i386/i386/machdep.c Mon Sep 30 02:02:22 2002 +++ kernel/i386/i386/machdep.c Sat Oct 5 01:20:27 2002 @@ -1,4 +1,6 @@ /*- + * Copyright (c) 2002 Juli Mallett. + * Copyright (c) 2002 New Gold Technology. * Copyright (c) 1992 Terrence R. Lambert. * Copyright (c) 1982, 1987, 1990 The Regents of the University of California. * All rights reserved. @@ -75,6 +77,7 @@ #include #include #include +#include #include #include @@ -408,11 +411,7 @@ #endif /* COMPAT_43 */ void -sendsig(catcher, sig, mask, code) - sig_t catcher; - int sig; - sigset_t *mask; - u_long code; +sendsig(sig_t catcher, struct ksiginfo *ksi, sigset_t *mask) { struct sigframe sf; struct proc *p; @@ -420,15 +419,16 @@ struct sigacts *psp; struct trapframe *regs; struct sigframe *sfp; - int oonstack; + int oonstack, sig; + sig = ksi->ksi_signo; td = curthread; p = td->td_proc; PROC_LOCK_ASSERT(p, MA_OWNED); psp = p->p_sigacts; #ifdef COMPAT_43 if (SIGISMEMBER(psp->ps_osigset, sig)) { - osendsig(catcher, sig, mask, code); + osendsig(catcher, sig, mask, ksi->ksi_code); return; } #endif @@ -473,15 +473,11 @@ sf.sf_siginfo = (register_t)&sfp->sf_si; sf.sf_ahu.sf_action = (__siginfohandler_t *)catcher; - /* Fill in POSIX parts */ - sf.sf_si.si_signo = sig; - sf.sf_si.si_code = code; + ksiginfo_to_siginfo_t(ksi, &sf.sf_si); sf.sf_si.si_addr = (void *)regs->tf_err; - sf.sf_si.si_pid = p->p_pid; - sf.sf_si.si_uid = p->p_ucred->cr_uid; } else { /* Old FreeBSD-style arguments. */ - sf.sf_siginfo = code; + sf.sf_siginfo = ksi->ksi_code; sf.sf_addr = regs->tf_err; sf.sf_ahu.sf_handler = catcher; } diff -Nrdu -x *CVS* -x *dev* sys/i386/ibcs2/ibcs2_signal.c kernel/i386/ibcs2/ibcs2_signal.c --- sys/i386/ibcs2/ibcs2_signal.c Tue Oct 1 12:15:51 2002 +++ kernel/i386/ibcs2/ibcs2_signal.c Sat Oct 5 01:20:29 2002 @@ -25,12 +25,13 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $FreeBSD: src/sys/i386/ibcs2/ibcs2_signal.c,v 1.25 2002/10/01 17:15:51 jmallett Exp $ + * $FreeBSD: src/sys/i386/ibcs2/ibcs2_signal.c,v 1.22 2002/08/25 13:17:09 charnier Exp $ */ #include #include #include +#include #include #include #include @@ -452,11 +453,11 @@ struct ibcs2_sigpending_args *uap; { struct proc *p = td->td_proc; - sigset_t bss; + sigset_t curset; ibcs2_sigset_t iss; PROC_LOCK(p); - bss = p->p_siglist; + ksiginfo_to_sigset_t(p, &bss); SIGSETAND(bss, p->p_sigmask); PROC_UNLOCK(p); bsd_to_ibcs2_sigset(&bss, &iss); diff -Nrdu -x *CVS* -x *dev* sys/i386/linux/linux_sysvec.c kernel/i386/linux/linux_sysvec.c --- sys/i386/linux/linux_sysvec.c Sat Sep 7 17:31:44 2002 +++ kernel/i386/linux/linux_sysvec.c Sat Oct 5 01:20:41 2002 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -108,8 +109,8 @@ struct image_params *iparams); static void linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t *params); -static void linux_sendsig(sig_t catcher, int sig, sigset_t *mask, - u_long code); +static void linux_sendsig(sig_t catcher, struct ksiginfo *ksi, + sigset_t *mask); /* * Linux syscalls return negative errno's, we do positive and map them @@ -395,15 +396,18 @@ */ static void -linux_sendsig(sig_t catcher, int sig, sigset_t *mask, u_long code) +linux_sendsig(sig_t catcher, struct ksiginfo *ksi, sigset_t *mask) { register struct thread *td = curthread; register struct proc *p = td->td_proc; register struct trapframe *regs; struct l_sigframe *fp, frame; l_sigset_t lmask; - int oonstack, i; + int oonstack, i, sig; + u_long code; + sig = ksi->ksi_signo; + code = ksi->ksi_code; PROC_LOCK_ASSERT(p, MA_OWNED); if (SIGISMEMBER(p->p_sigacts->ps_siginfo, sig)) { /* Signal handler installed with SA_SIGINFO. */ diff -Nrdu -x *CVS* -x *dev* sys/kern/imgact_elf.c kernel/kern/imgact_elf.c --- sys/kern/imgact_elf.c Sat Sep 21 17:07:16 2002 +++ kernel/kern/imgact_elf.c Sat Oct 5 01:20:56 2002 @@ -1100,7 +1100,6 @@ status->pr_gregsetsz = sizeof(gregset_t); status->pr_fpregsetsz = sizeof(fpregset_t); status->pr_osreldate = osreldate; - status->pr_cursig = p->p_sig; status->pr_pid = p->p_pid; fill_regs(td, &status->pr_reg); diff -Nrdu -x *CVS* -x *dev* sys/kern/init_main.c kernel/kern/init_main.c --- sys/kern/init_main.c Tue Oct 1 12:15:51 2002 +++ kernel/kern/init_main.c Sat Oct 5 01:20:56 2002 @@ -39,7 +39,7 @@ * SUCH DAMAGE. * * @(#)init_main.c 8.9 (Berkeley) 1/21/94 - * $FreeBSD: src/sys/kern/init_main.c,v 1.210 2002/10/01 17:15:51 jmallett Exp $ + * $FreeBSD: src/sys/kern/init_main.c,v 1.209 2002/10/01 00:07:26 jmallett Exp $ */ #include "opt_init_path.h" @@ -347,6 +347,8 @@ LIST_INSERT_HEAD(PGRPHASH(0), &pgrp0, pg_hash); LIST_INIT(&pgrp0.pg_members); LIST_INSERT_HEAD(&pgrp0.pg_members, p, p_pglist); + + TAILQ_INIT(&p->p_sigq); pgrp0.pg_session = &session0; mtx_init(&session0.s_mtx, "session", NULL, MTX_DEF); diff -Nrdu -x *CVS* -x *dev* sys/kern/kern_exit.c kernel/kern/kern_exit.c --- sys/kern/kern_exit.c Tue Oct 1 12:15:51 2002 +++ kernel/kern/kern_exit.c Sat Oct 5 01:20:57 2002 @@ -36,7 +36,7 @@ * SUCH DAMAGE. * * @(#)kern_exit.c 8.7 (Berkeley) 2/12/94 - * $FreeBSD: src/sys/kern/kern_exit.c,v 1.180 2002/10/01 17:15:51 jmallett Exp $ + * $FreeBSD: src/sys/kern/kern_exit.c,v 1.179 2002/10/01 00:07:27 jmallett Exp $ */ #include "opt_compat.h" @@ -67,6 +67,7 @@ #ifdef KTRACE #include #endif +#include #include #include @@ -209,12 +210,12 @@ PROC_LOCK(p); if (p == p->p_leader) { q = p->p_peers; + PROC_UNLOCK(p); while (q != NULL) { - PROC_LOCK(q); psignal(q, SIGKILL); - PROC_UNLOCK(q); q = q->p_peers; } + PROC_LOCK(p); while (p->p_peers) msleep(p, &p->p_mtx, PWAIT, "exit1", 0); } @@ -244,7 +245,7 @@ */ PROC_LOCK(p); p->p_flag &= ~(P_TRACED | P_PPWAIT); - SIGEMPTYSET(p->p_siglist); + signal_delete(p, NULL, 0); PROC_UNLOCK(p); if (timevalisset(&p->p_realtimer.it_value)) callout_stop(&p->p_itcallout); @@ -473,6 +474,12 @@ */ if (p->p_flag & P_KTHREAD) wakeup(p); + + /* + * And now, kill off its signals... + */ + signal_delete(p, NULL, 0); + PROC_UNLOCK(p); /* diff -Nrdu -x *CVS* -x *dev* sys/kern/kern_fork.c kernel/kern/kern_fork.c --- sys/kern/kern_fork.c Tue Oct 1 12:15:51 2002 +++ kernel/kern/kern_fork.c Sat Oct 5 01:20:57 2002 @@ -36,7 +36,7 @@ * SUCH DAMAGE. * * @(#)kern_fork.c 8.6 (Berkeley) 4/8/94 - * $FreeBSD: src/sys/kern/kern_fork.c,v 1.167 2002/10/01 17:15:51 jmallett Exp $ + * $FreeBSD: src/sys/kern/kern_fork.c,v 1.166 2002/10/01 00:07:27 jmallett Exp $ */ #include "opt_ktrace.h" @@ -605,6 +605,7 @@ LIST_INSERT_AFTER(p1, p2, p_pglist); PGRP_UNLOCK(p1->p_pgrp); LIST_INIT(&p2->p_children); + TAILQ_INIT(&p2->p_sigq); callout_init(&p2->p_itcallout, 0); diff -Nrdu -x *CVS* -x *dev* sys/kern/kern_kthread.c kernel/kern/kern_kthread.c --- sys/kern/kern_kthread.c Tue Oct 1 12:15:51 2002 +++ kernel/kern/kern_kthread.c Sat Oct 5 01:20:57 2002 @@ -23,7 +23,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/kern/kern_kthread.c,v 1.27 2002/10/01 17:15:51 jmallett Exp $ + * $FreeBSD: src/sys/kern/kern_kthread.c,v 1.26 2002/10/01 00:07:27 jmallett Exp $ */ #include @@ -37,6 +37,7 @@ #include #include #include +#include #include @@ -144,33 +145,29 @@ { /* * Make sure this is indeed a system process and we can safely - * use the p_siglist field. + * use the signal queue. */ PROC_LOCK(p); if ((p->p_flag & P_KTHREAD) == 0) { PROC_UNLOCK(p); return (EINVAL); } - SIGADDSET(p->p_siglist, SIGSTOP); + signal_add(p, NULL, SIGSTOP); wakeup(p); - return msleep(&p->p_siglist, &p->p_mtx, PPAUSE | PDROP, "suspkt", timo); + return msleep(&p->p_sigq, &p->p_mtx, PPAUSE | PDROP, "suspkt", timo); } int kthread_resume(struct proc *p) { - /* - * Make sure this is indeed a system process and we can safely - * use the p_siglist field. - */ PROC_LOCK(p); if ((p->p_flag & P_KTHREAD) == 0) { PROC_UNLOCK(p); return (EINVAL); } - SIGDELSET(p->p_siglist, SIGSTOP); + signal_delete(p, NULL, SIGSTOP); PROC_UNLOCK(p); - wakeup(&p->p_siglist); + wakeup(&p->p_sigq); return (0); } @@ -178,9 +175,9 @@ kthread_suspend_check(struct proc *p) { PROC_LOCK(p); - while (SIGISMEMBER(p->p_siglist, SIGSTOP)) { - wakeup(&p->p_siglist); - msleep(&p->p_siglist, &p->p_mtx, PPAUSE, "ktsusp", 0); + while (signal_queued(p, SIGSTOP)) { + wakeup(&p->p_sigq); + msleep(&p->p_sigq, &p->p_mtx, PPAUSE, "ktsusp", 0); } PROC_UNLOCK(p); } diff -Nrdu -x *CVS* -x *dev* sys/kern/kern_proc.c kernel/kern/kern_proc.c --- sys/kern/kern_proc.c Tue Oct 1 12:15:51 2002 +++ kernel/kern/kern_proc.c Sat Oct 5 01:20:58 2002 @@ -31,7 +31,7 @@ * SUCH DAMAGE. * * @(#)kern_proc.c 8.7 (Berkeley) 2/14/95 - * $FreeBSD: src/sys/kern/kern_proc.c,v 1.157 2002/10/01 17:15:51 jmallett Exp $ + * $FreeBSD: src/sys/kern/kern_proc.c,v 1.156 2002/10/01 00:07:27 jmallett Exp $ */ #include "opt_ktrace.h" @@ -58,6 +58,7 @@ #include #include #endif +#include #include #include @@ -408,7 +409,7 @@ RANGEOF(struct kse, ke_startcopy, ke_endcopy)); #endif PROC_LOCK(p); - if (SIGPENDING(p)) + if (signal_pending(p)) newke->ke_flags |= KEF_ASTPENDING; PROC_UNLOCK(p); mtx_lock_spin(&sched_lock); @@ -1014,7 +1015,7 @@ strncpy(kp->ki_comm, p->p_comm, sizeof(kp->ki_comm) - 1); strncpy(kp->ki_ocomm, p->p_comm, sizeof(kp->ki_ocomm) - 1); } - kp->ki_siglist = p->p_siglist; + ksiginfo_to_sigset_t(p, &kp->ki_siglist); kp->ki_sigmask = p->p_sigmask; kp->ki_xstat = p->p_xstat; kp->ki_acflag = p->p_acflag; diff -Nrdu -x *CVS* -x *dev* sys/kern/kern_sig.c kernel/kern/kern_sig.c --- sys/kern/kern_sig.c Tue Oct 1 12:15:51 2002 +++ kernel/kern/kern_sig.c Sat Oct 5 01:20:58 2002 @@ -1,4 +1,6 @@ /* + * Copyright (c) 2002 New Gold Technoloy. All rights reserved. + * Copyright (c) 2002 Juli Mallett. All rights reserved. * Copyright (c) 1982, 1986, 1989, 1991, 1993 * The Regents of the University of California. All rights reserved. * (c) UNIX System Laboratories, Inc. @@ -36,7 +38,7 @@ * SUCH DAMAGE. * * @(#)kern_sig.c 8.7 (Berkeley) 4/18/94 - * $FreeBSD: src/sys/kern/kern_sig.c,v 1.195 2002/10/01 17:15:51 jmallett Exp $ + * $FreeBSD: src/sys/kern/kern_sig.c,v 1.194 2002/10/01 00:16:16 jmallett Exp $ */ #include "opt_compat.h" @@ -70,6 +72,7 @@ #include #include #include +#include #include @@ -116,6 +119,9 @@ SYSCTL_INT(_kern, OID_AUTO, coredump, CTLFLAG_RW, &do_coredump, 0, "Enable/Disable coredumps"); +static int stopmask = + sigmask(SIGSTOP) | sigmask(SIGTSTP) | sigmask(SIGTTIN) | sigmask(SIGTTOU); + /* * Signal properties and actions. * The array below categorizes the signals and their default actions @@ -178,12 +184,12 @@ PROC_LOCK_ASSERT(p, MA_OWNED); mtx_assert(&sched_lock, MA_NOTOWNED); - return (SIGPENDING(p) ? issignal(td) : 0); + return (signal_pending(p) ? issignal(td) : 0); } /* * Arrange for ast() to handle unmasked pending signals on return to user - * mode. This must be called whenever a signal is added to p_siglist or + * mode. This must be called whenever a signal is added to p_sigq or * unmasked in p_sigmask. */ void @@ -194,7 +200,7 @@ PROC_LOCK_ASSERT(p, MA_OWNED); mtx_lock_spin(&sched_lock); - if (SIGPENDING(p)) { + if (signal_pending(p)) { p->p_sflag |= PS_NEEDSIGCHK; /* XXXKSE for now punish all KSEs */ FOREACH_KSEGRP_IN_PROC(p, kg) { @@ -341,7 +347,7 @@ (sigprop(sig) & SA_IGNORE && ps->ps_sigact[_SIG_IDX(sig)] == SIG_DFL)) { /* never to be seen again */ - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); if (sig != SIGCONT) /* easier in psignal */ SIGADDSET(p->p_sigignore, sig); @@ -494,7 +500,7 @@ if (sigprop(sig) & SA_IGNORE) { if (sig != SIGCONT) SIGADDSET(p->p_sigignore, sig); - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); } ps->ps_sigact[_SIG_IDX(sig)] = SIG_DFL; } @@ -641,7 +647,7 @@ mtx_lock(&Giant); PROC_LOCK(p); - siglist = p->p_siglist; + ksiginfo_to_sigset_t(p, &siglist); PROC_UNLOCK(p); mtx_unlock(&Giant); error = copyout(&siglist, uap->set, sizeof(sigset_t)); @@ -664,10 +670,12 @@ struct osigpending_args *uap; { struct proc *p = td->td_proc; + sigset_t siglist; mtx_lock(&Giant); PROC_LOCK(p); - SIG2OSIG(p->p_siglist, td->td_retval[0]); + ksiginfo_to_sigset_t(p, &siglist); + SIG2OSIG(siglist, td->td_retval[0]); PROC_UNLOCK(p); mtx_unlock(&Giant); return (0); @@ -1219,7 +1227,10 @@ u_long code; { register struct sigacts *ps = p->p_sigacts; + struct ksiginfo *ksi; + ksiginfo_alloc(&ksi, p, sig); + ksi->ksi_code = code; PROC_LOCK(p); if ((p->p_flag & P_TRACED) == 0 && SIGISMEMBER(p->p_sigcatch, sig) && !SIGISMEMBER(p->p_sigmask, sig)) { @@ -1229,8 +1240,9 @@ ktrpsig(sig, ps->ps_sigact[_SIG_IDX(sig)], &p->p_sigmask, code); #endif - (*p->p_sysent->sv_sendsig)(ps->ps_sigact[_SIG_IDX(sig)], sig, - &p->p_sigmask, code); + (*p->p_sysent->sv_sendsig)(ps->ps_sigact[_SIG_IDX(sig)], ksi, + &p->p_sigmask); + ksiginfo_destroy(&ksi); SIGSETOR(p->p_sigmask, ps->ps_catchmask[_SIG_IDX(sig)]); if (!SIGISMEMBER(ps->ps_signodefer, sig)) SIGADDSET(p->p_sigmask, sig); @@ -1244,11 +1256,8 @@ SIGADDSET(p->p_sigignore, sig); ps->ps_sigact[_SIG_IDX(sig)] = SIG_DFL; } - } else { - p->p_code = code; /* XXX for core dump/debugger */ - p->p_sig = sig; /* XXX to verify code */ + } else psignal(p, sig); - } PROC_UNLOCK(p); } @@ -1308,7 +1317,7 @@ } if (prop & SA_CONT) - SIG_STOPSIGMASK(p->p_siglist); + signal_delete_mask(p, stopmask); if (prop & SA_STOP) { /* @@ -1321,10 +1330,10 @@ (p->p_pgrp->pg_jobc == 0) && (action == SIG_DFL)) return; - SIG_CONTSIGMASK(p->p_siglist); + signal_delete_mask(p, sigmask(SIGCONT)); p->p_flag &= ~P_CONTINUED; } - SIGADDSET(p->p_siglist, sig); + signal_add(p, NULL, sig); signotify(p); /* uses schedlock */ /* @@ -1362,10 +1371,10 @@ if (prop & SA_CONT) { /* * If SIGCONT is default (or ignored), we continue the - * process but don't leave the signal in p_siglist as - * it has no further action. If SIGCONT is held, we + * process but don't leave the signal in p_sigq as it + * has no further action. If SIGCONT is held, we * continue the process and leave the signal in - * p_siglist. If the process catches SIGCONT, let it + * p_sigq. If the process catches SIGCONT, let it * handle the signal itself. If it isn't waiting on * an event, it goes back to run state. * Otherwise, process goes back to sleep state. @@ -1373,7 +1382,7 @@ p->p_flag &= ~P_STOPPED_SIG; p->p_flag |= P_CONTINUED; if (action == SIG_DFL) { - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); } else if (action == SIG_CATCH) { /* * The process wants to catch it so it needs @@ -1403,7 +1412,7 @@ * Just make sure the signal STOP bit set. */ p->p_flag |= P_STOPPED_SIG; - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); goto out; } @@ -1437,7 +1446,7 @@ /* * Already active, don't need to start again. */ - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); goto out; } if ((p->p_flag & P_TRACED) || (action != SIG_DFL) || @@ -1461,7 +1470,7 @@ mtx_unlock_spin(&sched_lock); stop(p); p->p_xstat = sig; - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); PROC_LOCK(p->p_pptr); if ((p->p_pptr->p_procsig->ps_flag & PS_NOCLDSTOP) == 0) { @@ -1478,7 +1487,7 @@ /* NOTREACHED */ } else { /* Not in "NORMAL" state. discard the signal. */ - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); goto out; } @@ -1553,7 +1562,7 @@ * be awakened. */ if ((prop & SA_CONT) && action == SIG_DFL) { - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); return; } @@ -1609,13 +1618,13 @@ for (;;) { int traced = (p->p_flag & P_TRACED) || (p->p_stops & S_SIG); - mask = p->p_siglist; + ksiginfo_to_sigset_t(p, &mask); SIGSETNAND(mask, p->p_sigmask); if (p->p_flag & P_PPWAIT) SIG_STOPSIGMASK(mask); if (SIGISEMPTY(mask)) /* no signal to send */ return (0); - sig = sig_ffs(&mask); + sig = signal_queued_mask(p, mask); prop = sigprop(sig); _STOPEVENT(p, S_SIG, sig); @@ -1625,7 +1634,7 @@ * only if P_TRACED was on when they were posted. */ if (SIGISMEMBER(p->p_sigignore, sig) && (traced == 0)) { - SIGDELSET(p->p_siglist, sig); + signal_delete(p, NULL, sig); continue; } if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) == 0) { @@ -1660,16 +1669,16 @@ * then it will leave it in p->p_xstat; * otherwise we just look for signals again. */ - SIGDELSET(p->p_siglist, sig); /* clear old signal */ + signal_delete(p, NULL, sig); /* clear old signal */ sig = p->p_xstat; if (sig == 0) continue; /* - * Put the new signal into p_siglist. If the - * signal is being masked, look for other signals. + * Put the new signal into p_sigq. If the signal + * is being masked, look for other signals. */ - SIGADDSET(p->p_siglist, sig); + psignal(p, sig); if (SIGISMEMBER(p->p_sigmask, sig)) continue; signotify(p); @@ -1759,7 +1768,7 @@ */ return (sig); } - SIGDELSET(p->p_siglist, sig); /* take the signal! */ + signal_delete(p, NULL, sig); /* take the signal! */ } /* NOTREACHED */ } @@ -1791,16 +1800,16 @@ { struct thread *td = curthread; register struct proc *p = td->td_proc; + struct ksiginfo *ksi; struct sigacts *ps; sig_t action; sigset_t returnmask; - int code; KASSERT(sig != 0, ("postsig")); PROC_LOCK_ASSERT(p, MA_OWNED); ps = p->p_sigacts; - SIGDELSET(p->p_siglist, sig); + ksiginfo_dequeue(&ksi, p, sig); action = ps->ps_sigact[_SIG_IDX(sig)]; #ifdef KTRACE if (KTRPOINT(td, KTR_PSIG)) @@ -1814,6 +1823,7 @@ * Default action, where the default is to kill * the process. (Other cases were ignored above.) */ + ksiginfo_destroy(&ksi); sigexit(td, sig); /* NOTREACHED */ } else { @@ -1852,17 +1862,13 @@ ps->ps_sigact[_SIG_IDX(sig)] = SIG_DFL; } p->p_stats->p_ru.ru_nsignals++; - if (p->p_sig != sig) { - code = 0; - } else { - code = p->p_code; - p->p_code = 0; - p->p_sig = 0; - } if (p->p_flag & P_KSES) - if (signal_upcall(p, sig)) + if (signal_upcall(p, sig)) { + ksiginfo_destroy(&ksi); return; - (*p->p_sysent->sv_sendsig)(action, sig, &returnmask, code); + } + (*p->p_sysent->sv_sendsig)(action, ksi, &returnmask); + ksiginfo_destroy(&ksi); } } @@ -1901,7 +1907,6 @@ PROC_LOCK_ASSERT(p, MA_OWNED); p->p_acflag |= AXSIG; if (sigprop(sig) & SA_CORE) { - p->p_sig = sig; /* * Log signals which would cause core dumps * (Log as LOG_INFO to appease those who don't want diff -Nrdu -x *CVS* -x *dev* sys/kern/subr_sigq.c kernel/kern/subr_sigq.c --- sys/kern/subr_sigq.c Wed Dec 31 18:00:00 1969 +++ kernel/kern/subr_sigq.c Sat Oct 5 01:21:00 2002 @@ -0,0 +1,323 @@ +/*- + * Copyright (c) 2002 New Gold Technology. All rights reserved. + * Copyright (c) 2002 Juli Mallett. All rights reserved. + * + * This software was written by Juli Mallett for the + * FreeBSD project. Redistribution and use in source and binary forms, with + * or without modification, are permitted provided that the following + * conditions are met: + * + * 1. Redistribution of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. + * 2. Redistribution in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING + * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD: src/sys/kern/subr_sigq.c,v 1.4 2002/10/01 03:19:49 jmallett Exp $ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +MALLOC_DECLARE(M_KSIGINFO); +MALLOC_DEFINE(M_KSIGINFO, "ksiginfos", "Kernel signal info structures"); + +int +ksiginfo_alloc(struct ksiginfo **ksip, struct proc *p, int signo) +{ + int error; + struct ksiginfo *ksi; + + error = 0; + + PROC_LOCK_ASSERT(p, MA_NOTOWNED); + ksi = malloc(sizeof *ksi, M_KSIGINFO, M_ZERO | M_NOWAIT); + if (ksi == NULL) { + PROC_LOCK(p); + p->p_suicide = 1; + PROC_UNLOCK(p); + } + ksi->ksi_signo = signo; + if (curproc != NULL) { + ksi->ksi_pid = curproc->p_pid; + ksi->ksi_ruid = curproc->p_ucred->cr_uid; + } + *ksip = ksi; + return (error); +} + +int +ksiginfo_dequeue(struct ksiginfo **ksip, struct proc *p, int signo) +{ + int error; + struct ksiginfo *ksi; + + error = 0; + ksi = NULL; + + PROC_LOCK_ASSERT(p, MA_OWNED); + if (TAILQ_EMPTY(&p->p_sigq)) { + error = EDOOFUS; + goto out; + } + /* + * If we have no signo, get the lowest numbered one that's pending. + * XXX This should probably be duplicated from signal_pending, using + * a pointer to a struct ksiginfo for the 'lowest' value, to avoid + * traversing the list the same amount twice. + */ + if (!signo) + signo = signal_pending(p, 0); + TAILQ_FOREACH(ksi, &p->p_sigq, ksi_queue) { + if (ksi->ksi_signo == signo) + goto out; + } + error = ESRCH; + ksi = NULL; +out: + if (ksi != NULL) + TAILQ_REMOVE(&p->p_sigq, ksi, ksi_queue); + *ksip = ksi; + return (error); +} + +int +ksiginfo_destroy(struct ksiginfo **ksip) +{ + int error; + struct ksiginfo *ksi; + + error = 0; + + ksi = *ksip; + if (ksi == NULL) { + error = EDOOFUS; + goto out; + } + free(ksi, M_KSIGINFO); + ksi = NULL; +out: + *ksip = ksi; + return (error); +} + +int +ksiginfo_to_siginfo_t(struct ksiginfo *ksi, siginfo_t *si) +{ + int error; + + error = 0; + + si->si_addr = ksi->ksi_addr; + si->si_code = ksi->ksi_code; + si->si_errno = ksi->ksi_errno; + si->si_signo = ksi->ksi_signo; + si->si_status = ksi->ksi_status; + si->si_uid = ksi->ksi_ruid; + si->si_pid = ksi->ksi_pid; + + return (error); +} + +int +ksiginfo_to_sigset_t(struct proc *p, sigset_t *setp) +{ + int error; + sigset_t set; + struct ksiginfo *ksi; + + error = 0; + SIGEMPTYSET(set); + + PROC_LOCK_ASSERT(p, MA_OWNED); + /* + * We could set EDOOFUS here, however if there are no queued + * signals, then an empty signal set _is_ valid. + */ + if (TAILQ_EMPTY(&p->p_sigq)) + goto out; + TAILQ_FOREACH(ksi, &p->p_sigq, ksi_queue) + SIGADDSET(set, ksi->ksi_signo); +out: + *setp = set; + return (error); +} + +int +signal_add(struct proc *p, struct ksiginfo *ksi, int signo) +{ + int error; + + error = 0; + + PROC_LOCK_ASSERT(p, MA_OWNED); + if (ksi == NULL) { + PROC_UNLOCK(p); + error = ksiginfo_alloc(&ksi, p, signo); + PROC_LOCK(p); + if (error) + return (error); + } + TAILQ_INSERT_HEAD(&p->p_sigq, ksi, ksi_queue); +out: + return (error); +} + +int +signal_delete(struct proc *p, struct ksiginfo *ksi, int signo) +{ + int error; + + error = 0; + + PROC_LOCK_ASSERT(p, MA_OWNED); + if (ksi == NULL) { + while (signal_queued(p, signo)) { + error = ksiginfo_dequeue(&ksi, p, signo); + if (error) + return (error); + error = ksiginfo_destroy(&ksi); + if (error) + return (error); + } + } +out: + if (ksi != NULL) { + TAILQ_REMOVE(&p->p_sigq, ksi, ksi_queue); + ksiginfo_destroy(&ksi); + } + return (error); +} + +int +signal_delete_mask(struct proc *p, int mask) +{ + int error; + struct ksiginfo *ksi, *prev; + + error = 0; + ksi = prev = NULL; + + PROC_LOCK_ASSERT(p, MA_OWNED); + if (TAILQ_EMPTY(&p->p_sigq)) + goto out; + TAILQ_FOREACH(ksi, &p->p_sigq, ksi_queue) { + if (prev != NULL) { + TAILQ_REMOVE(&p->p_sigq, prev, ksi_queue); + error = ksiginfo_destroy(&prev); + if (error) + return (error); + } + if (sigmask(ksi->ksi_signo) & mask) + prev = ksi; + } + if (prev != NULL) { + TAILQ_REMOVE(&p->p_sigq, prev, ksi_queue); + error = ksiginfo_destroy(&prev); + if (error) + return (error); + } +out: + return (error); +} + +int +signal_pending(struct proc *p) +{ + int error, pending; + sigset_t set; + + error = 0; + pending = 0; + + PROC_LOCK_ASSERT(p, MA_OWNED); + if (TAILQ_EMPTY(&p->p_sigq)) + goto out; + if (p->p_flag & P_TRACED) { + pending = 1; + goto out; + } + error = ksiginfo_to_sigset_t(p, &set); + if (error) + goto out; + pending = !sigsetmasked(&set, &p->p_sigmask); + if (pending) + goto out; +out: + return (pending); +} + +int +signal_queued(struct proc *p, int signo) +{ + int error, lowest, pending; + struct ksiginfo *ksi; + + error = 0; + lowest = 0; + pending = 0; + ksi = NULL; + + PROC_LOCK_ASSERT(p, MA_OWNED); + if (TAILQ_EMPTY(&p->p_sigq)) + goto out; + TAILQ_FOREACH(ksi, &p->p_sigq, ksi_queue) { + pending = ksi->ksi_signo; + + if (signo == pending) + goto out; + else if (signo == 0) { + if (pending < lowest) + lowest = pending; + } + } + if (signo) + pending = 0; + else + pending = lowest; +out: + return (pending); +} + +int +signal_queued_mask(struct proc *p, sigset_t mask) +{ + int pending; + struct ksiginfo *ksi; + + pending = 0; + ksi = NULL; + + PROC_LOCK_ASSERT(p, MA_OWNED); + if (TAILQ_EMPTY(&p->p_sigq)) + goto out; + TAILQ_FOREACH(ksi, &p->p_sigq, ksi_queue) { + if (SIGISMEMBER(mask, ksi->ksi_signo)) { + pending = ksi->ksi_signo; + goto out; + } + } +out: + return (pending); +} diff -Nrdu -x *CVS* -x *dev* sys/kern/tty.c kernel/kern/tty.c --- sys/kern/tty.c Tue Oct 1 12:15:52 2002 +++ kernel/kern/tty.c Sat Oct 5 01:21:00 2002 @@ -44,7 +44,7 @@ * SUCH DAMAGE. * * @(#)tty.c 8.8 (Berkeley) 1/21/94 - * $FreeBSD: src/sys/kern/tty.c,v 1.188 2002/10/01 17:15:52 jmallett Exp $ + * $FreeBSD: src/sys/kern/tty.c,v 1.187 2002/10/01 00:07:27 jmallett Exp $ */ /*- @@ -102,6 +102,7 @@ #include #include #include +#include #include #include @@ -1841,21 +1842,24 @@ ttycheckoutq(struct tty *tp, int wait) { int hiwat, s; - sigset_t oldmask; + sigset_t oldmask, newmask; hiwat = tp->t_ohiwat; SIGEMPTYSET(oldmask); s = spltty(); if (wait) - oldmask = curproc->p_siglist; + ksiginfo_to_sigset_t(curproc, &oldmask); if (tp->t_outq.c_cc > hiwat + OBUFSIZ + 100) while (tp->t_outq.c_cc > hiwat) { ttstart(tp); if (tp->t_outq.c_cc <= hiwat) break; - if (!(wait && SIGSETEQ(curproc->p_siglist, oldmask))) { - splx(s); - return (0); + if (!wait) { + ksiginfo_to_sigset_t(curproc, &newmask); + if (SIGSETEQ(newmask, oldmask)) { + splx(s); + return (0); + } } SET(tp->t_state, TS_SO_OLOWAT); tsleep(TSA_OLOWAT(tp), PZERO - 1, "ttoutq", hz); diff -Nrdu -x *CVS* -x *dev* sys/netncp/ncp_ncp.c kernel/netncp/ncp_ncp.c --- sys/netncp/ncp_ncp.c Tue Oct 1 12:15:52 2002 +++ kernel/netncp/ncp_ncp.c Sat Oct 5 01:21:30 2002 @@ -29,7 +29,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/netncp/ncp_ncp.c,v 1.11 2002/10/01 17:15:52 jmallett Exp $ + * $FreeBSD: src/sys/netncp/ncp_ncp.c,v 1.10 2002/09/30 20:48:28 jmallett Exp $ * * Core of NCP protocol */ @@ -42,6 +42,7 @@ #include #include #include +#include #include #include @@ -80,11 +81,15 @@ if (p == NULL) return 0; - tmpset = p->p_siglist; + PROC_LOCK(p); + ksiginfo_to_sigset_t(p, &tmpset); SIGSETNAND(tmpset, p->p_sigmask); SIGSETNAND(tmpset, p->p_sigignore); - if (SIGNOTEMPTY(p->p_siglist) && NCP_SIGMASK(tmpset)) + if (signal_queued(p, 0) && NCP_SIGMASK(tmpset)) { + PROC_UNLOCK(p); return EINTR; + } + PROC_UNLOCK(p); return 0; } diff -Nrdu -x *CVS* -x *dev* sys/netsmb/smb_subr.c kernel/netsmb/smb_subr.c --- sys/netsmb/smb_subr.c Tue Oct 1 12:15:53 2002 +++ kernel/netsmb/smb_subr.c Sat Oct 5 01:21:32 2002 @@ -29,7 +29,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/netsmb/smb_subr.c,v 1.9 2002/10/01 17:15:53 jmallett Exp $ + * $FreeBSD: src/sys/netsmb/smb_subr.c,v 1.8 2002/09/30 20:48:29 jmallett Exp $ */ #include #include @@ -42,6 +42,7 @@ #include #include #include +#include #include @@ -75,11 +76,15 @@ if (p == NULL) return 0; - tmpset = p->p_siglist; + PROC_LOCK(p); + ksiginfo_to_sigset_t(p, &tmpset); SIGSETNAND(tmpset, p->p_sigmask); SIGSETNAND(tmpset, p->p_sigignore); - if (SIGNOTEMPTY(p->p_siglist) && SMB_SIGMASK(tmpset)) + if (signal_queued(p, 0) && SMB_SIGMASK(tmpset)) { + PROC_UNLOCK(p); return EINTR; + } + PROC_UNLOCK(p); return 0; } diff -Nrdu -x *CVS* -x *dev* sys/nfsclient/nfs_socket.c kernel/nfsclient/nfs_socket.c --- sys/nfsclient/nfs_socket.c Tue Oct 1 12:15:53 2002 +++ kernel/nfsclient/nfs_socket.c Sat Oct 5 01:21:34 2002 @@ -37,7 +37,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/nfsclient/nfs_socket.c,v 1.90 2002/10/01 17:15:53 jmallett Exp $"); +__FBSDID("$FreeBSD: src/sys/nfsclient/nfs_socket.c,v 1.89 2002/09/30 21:15:33 jmallett Exp $"); /* * Socket operations for use by nfs @@ -61,6 +61,7 @@ #include #include #include +#include #include #include @@ -1239,11 +1240,15 @@ return (0); p = td->td_proc; - tmpset = p->p_siglist; + PROC_LOCK(p); + ksiginfo_to_sigset_t(p, &tmpset); SIGSETNAND(tmpset, p->p_sigmask); SIGSETNAND(tmpset, p->p_sigignore); - if (SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset)) + if (signal_queued(p, 0) && NFSINT_SIGMASK(tmpset)) { + PROC_UNLOCK(p); return (EINTR); + } + PROC_UNLOCK(p); return (0); } diff -Nrdu -x *CVS* -x *dev* sys/sys/ksiginfo.h kernel/sys/ksiginfo.h --- sys/sys/ksiginfo.h Wed Dec 31 18:00:00 1969 +++ kernel/sys/ksiginfo.h Sat Oct 5 01:22:02 2002 @@ -0,0 +1,78 @@ +/*- + * Copyright (c) 2002 New Gold Technology. All rights reserved. + * Copyright (c) 2002 Juli Mallett. All rights reserved. + * + * This software was written by Juli Mallett for the + * FreeBSD project. Redistribution and use in source and binary forms, with + * or without modification, are permitted provided that the following + * conditions are met: + * + * 1. Redistribution of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. + * 2. Redistribution in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING + * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD: src/sys/sys/ksiginfo.h,v 1.3 2002/10/01 00:16:17 jmallett Exp $ + */ + +#ifndef _SYS_KSIGINFO_H_ +#define _SYS_KSIGINFO_H_ + +#ifndef _KERNEL +#error "no user-serviceable parts inside" +#endif + +#include +#include + +/* + * Structures and prototypes for working with the in-kernel representation + * of pending signals, and all the information we have about them. + */ + +/* + * This is pushed to userland in the form of a siginfo_t, which is POSIX + * defined. This is for in-kernel representations only, and has no ABI + * consumers. + */ +struct ksiginfo { + TAILQ_ENTRY(ksiginfo) ksi_queue; /* Entry in the signal queue. */ + void *ksi_addr; /* [Fault] address. */ + int ksi_code; /* [Trap] code. */ + int ksi_errno; /* Error number. */ + int ksi_signo; /* Signal number. */ + int ksi_status; /* Exit status (SIGCHLD). */ + uid_t ksi_ruid; /* Real UID of sender. */ + pid_t ksi_pid; /* PID of sender. */ +}; + +struct proc; + +__BEGIN_DECLS; +int ksiginfo_alloc(struct ksiginfo **, struct proc *, int); +int ksiginfo_dequeue(struct ksiginfo **, struct proc *, int); +int ksiginfo_destroy(struct ksiginfo **); +int ksiginfo_to_siginfo_t(struct ksiginfo *, siginfo_t *); +int ksiginfo_to_sigset_t(struct proc *, sigset_t *); +int signal_add(struct proc *, struct ksiginfo *, int); +int signal_delete(struct proc *, struct ksiginfo *, int); +int signal_delete_mask(struct proc *, int); +int signal_pending(struct proc *); +int signal_queued(struct proc *, int); +int signal_queued_mask(struct proc *, sigset_t); +__END_DECLS; + +#endif /* !_SYS_KSIGINFO_H_ */ diff -Nrdu -x *CVS* -x *dev* sys/sys/proc.h kernel/sys/proc.h --- sys/sys/proc.h Tue Oct 1 12:15:53 2002 +++ kernel/sys/proc.h Sat Oct 5 01:22:05 2002 @@ -36,7 +36,7 @@ * SUCH DAMAGE. * * @(#)proc.h 8.15 (Berkeley) 5/19/95 - * $FreeBSD: src/sys/sys/proc.h,v 1.264 2002/10/01 17:15:53 jmallett Exp $ + * $FreeBSD: src/sys/sys/proc.h,v 1.263 2002/10/01 00:07:28 jmallett Exp $ */ #ifndef _SYS_PROC_H_ @@ -497,6 +497,7 @@ TAILQ_HEAD(, ksegrp) p_ksegrps; /* (kg_ksegrp) All KSEGs. */ TAILQ_HEAD(, thread) p_threads; /* (td_plist) Threads. (shortcut) */ TAILQ_HEAD(, thread) p_suspended; /* (td_runq) suspended threads */ + TAILQ_HEAD(, ksiginfo) p_sigq; /* (c) Queued signals. */ struct ucred *p_ucred; /* (c) Process owner's identity. */ struct filedesc *p_fd; /* (b) Ptr to open files structure. */ /* Accumulated stats for all KSEs? */ @@ -535,17 +536,15 @@ u_int p_swtime; /* (j) Time swapped in or out. */ struct itimerval p_realtimer; /* (h?/k?) Alarm timer. */ struct bintime p_runtime; /* (j) Real time. */ + int p_suicide; /* (c) Commit signal suicide. */ int p_traceflag; /* (o) Kernel trace points. */ struct vnode *p_tracep; /* (c + o) Trace to vnode. */ - sigset_t p_siglist; /* (c) Sigs arrived, not delivered. */ struct vnode *p_textvp; /* (b) Vnode of executable. */ char p_lock; /* (c) Proclock (prevent swap) count. */ struct klist p_klist; /* (c) Knotes attached to this proc. */ struct sigiolst p_sigiolst; /* (c) List of sigio sources. */ int p_sigparent; /* (c) Signal to parent on exit. */ sigset_t p_oldsigmask; /* (c) Saved mask from pre sigpause. */ - int p_sig; /* (n) For core dump/debugger XXX. */ - u_long p_code; /* (n) For core dump/debugger XXX. */ u_int p_stops; /* (c) Stop event bitmask. */ u_int p_stype; /* (c) Stop event type. */ char p_step; /* (c) Process is stopped. */ diff -Nrdu -x *CVS* -x *dev* sys/sys/signalvar.h kernel/sys/signalvar.h --- sys/sys/signalvar.h Sat Jun 29 12:26:22 2002 +++ kernel/sys/signalvar.h Sat Oct 5 01:22:06 2002 @@ -189,12 +189,6 @@ #ifdef _KERNEL -/* Return nonzero if process p has an unmasked pending signal. */ -#define SIGPENDING(p) \ - (!SIGISEMPTY((p)->p_siglist) && \ - (!sigsetmasked(&(p)->p_siglist, &(p)->p_sigmask) || \ - (p)->p_flag & P_TRACED)) - /* * Return the value of the pseudo-expression ((*set & ~*mask) != 0). This * is an optimized version of SIGISEMPTY() on a temporary variable @@ -212,11 +206,12 @@ return (1); } +struct ksiginfo; +struct mtx; struct pgrp; -struct thread; struct proc; struct sigio; -struct mtx; +struct thread; extern int sugid_coredump; /* Sysctl variable kern.sugid_coredump */ extern struct mtx sigio_lock; @@ -251,7 +246,7 @@ /* * Machine-dependent functions: */ -void sendsig(sig_t action, int sig, sigset_t *retmask, u_long code); +void sendsig(sig_t action, struct ksiginfo *, sigset_t *retmask); #endif /* _KERNEL */ diff -Nrdu -x *CVS* -x *dev* sys/sys/sysent.h kernel/sys/sysent.h --- sys/sys/sysent.h Sun Sep 1 16:41:24 2002 +++ kernel/sys/sysent.h Sat Oct 5 01:22:06 2002 @@ -51,8 +51,9 @@ #define SCARG(p,k) ((p)->k) /* get arg from args pointer */ /* placeholder till we integrate rest of lite2 syscallargs changes XXX */ -struct image_params; struct __sigset; +struct ksiginfo; +struct image_params; struct trapframe; struct vnode; @@ -68,8 +69,8 @@ /* translate trap-to-signal mapping */ int (*sv_fixup)(register_t **, struct image_params *); /* stack fixup function */ - void (*sv_sendsig)(void (*)(int), int, struct __sigset *, - u_long); /* send signal */ + void (*sv_sendsig)(void (*)(int), struct ksiginfo *, + struct __sigset *); /* send signal */ char *sv_sigcode; /* start of sigtramp code */ int *sv_szsigcode; /* size of sigtramp code */ void (*sv_prepsyscall)(struct trapframe *, int *, u_int *, %%% Thanks, juli. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 0:30:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 8896837B401; Sat, 5 Oct 2002 00:30:12 -0700 (PDT) Date: Sat, 5 Oct 2002 00:30:12 -0700 From: Juli Mallett To: David Francheski Cc: freebsd-arch@FreeBSD.ORG, freebsd-smp@FreeBSD.org Subject: Re: Running independent kernel instances on dual-Xeon/E7500 system Message-ID: <20021005003012.A14963@FreeBSD.org> References: <006001c26c03$6a6e2420$3600010a@caymas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <006001c26c03$6a6e2420$3600010a@caymas.com>; from davidf@caymas.com on Fri, Oct 04, 2002 at 05:08:55PM -0700 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: David Francheski [ Data: 2002-10-04 ] [ Subjecte: Running independent kernel instances on dual-Xeon/E7500 system ] > > I have a dual-Xeon processor (with E7500 chipset) motherboard. > Can anybody tell me what the development effort would be to > boot and run two independent copies of the FreeBSD kernel, > one on each Xeon processor? By this I mean that an SMP > enabled kernel would not be utilized, each kernel would be UP. You want to take OSF Mach and port -current to run on top of it just like the Lites project did. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 1:11:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31B3A37B401; Sat, 5 Oct 2002 01:11:43 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DEB843E4A; Sat, 5 Oct 2002 01:11:42 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g958BUvU023576; Sat, 5 Oct 2002 01:11:34 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210050811.g958BUvU023576@gw.catspoiler.org> Date: Sat, 5 Oct 2002 01:11:30 -0700 (PDT) From: Don Lewis Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] To: jmallett@FreeBSD.ORG Cc: arch@FreeBSD.ORG In-Reply-To: <20021005002021.A14635@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 5 Oct, Juli Mallett wrote: > To > accomodate situations where allocation of a 'ksiginfo' is a failure > mode (no memory), the destination process is told to exit via a new > member of 'struct proc', p_suicide, which tells a process to kill itself > next time it goes through userret. I hope that doesn't happen when I fg my editor ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 1:12:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 4D84237B401; Sat, 5 Oct 2002 01:12:57 -0700 (PDT) Date: Sat, 5 Oct 2002 01:12:57 -0700 From: Juli Mallett To: Don Lewis Cc: arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021005011257.A16980@FreeBSD.org> References: <20021005002021.A14635@FreeBSD.org> <200210050811.g958BUvU023576@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210050811.g958BUvU023576@gw.catspoiler.org>; from dl-freebsd@catspoiler.org on Sat, Oct 05, 2002 at 01:11:30AM -0700 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Don Lewis [ Data: 2002-10-05 ] [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > On 5 Oct, Juli Mallett wrote: > > To > > accomodate situations where allocation of a 'ksiginfo' is a failure > > mode (no memory), the destination process is told to exit via a new > > member of 'struct proc', p_suicide, which tells a process to kill itself > > next time it goes through userret. > > I hope that doesn't happen when I fg my editor ... In this situation (can't allocate 64 bytes) you're screwed if you have an editor in the background, coming to the foreground, anyway. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 2:29:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4511837B401; Sat, 5 Oct 2002 02:29:10 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD00D43E42; Sat, 5 Oct 2002 02:29:09 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g959T1vU023691; Sat, 5 Oct 2002 02:29:05 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210050929.g959T1vU023691@gw.catspoiler.org> Date: Sat, 5 Oct 2002 02:29:01 -0700 (PDT) From: Don Lewis Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] To: jmallett@FreeBSD.ORG Cc: dl-freebsd@catspoiler.org, arch@FreeBSD.ORG In-Reply-To: <20021005011257.A16980@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 5 Oct, Juli Mallett wrote: > * De: Don Lewis [ Data: 2002-10-05 ] > [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] >> On 5 Oct, Juli Mallett wrote: >> > To >> > accomodate situations where allocation of a 'ksiginfo' is a failure >> > mode (no memory), the destination process is told to exit via a new >> > member of 'struct proc', p_suicide, which tells a process to kill itself >> > next time it goes through userret. >> >> I hope that doesn't happen when I fg my editor ... > > In this situation (can't allocate 64 bytes) you're screwed if you have an > editor in the background, coming to the foreground, anyway. A lot of things that receive SIGCHLD, such as shells and inetd could also be affected a temporary shortage of kmem. Somehow it seems wasteful to have to allocate kmem to deliver SIGKILL. How is an ordinary userland program prevented from consuming all of kmem by blocking signal delivery and looping on kill()? Does a quota system need to be added? The following code never sets error to anything other than zero. It also looks like it is missing a return statement for the malloc() failed case. +int +ksiginfo_alloc(struct ksiginfo **ksip, struct proc *p, int signo) +{ + int error; + struct ksiginfo *ksi; + + error = 0; + + PROC_LOCK_ASSERT(p, MA_NOTOWNED); + ksi = malloc(sizeof *ksi, M_KSIGINFO, M_ZERO | M_NOWAIT); + if (ksi == NULL) { + PROC_LOCK(p); + p->p_suicide = 1; + PROC_UNLOCK(p); + } + ksi->ksi_signo = signo; + if (curproc != NULL) { + ksi->ksi_pid = curproc->p_pid; + ksi->ksi_ruid = curproc->p_ucred->cr_uid; + } + *ksip = ksi; + return (error); +} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 2:29:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58AC637B401; Sat, 5 Oct 2002 02:29:18 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAD2443E3B; Sat, 5 Oct 2002 02:29:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0020.cvx22-bradley.dialup.earthlink.net ([209.179.198.20] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17xlFK-0001IY-00; Sat, 05 Oct 2002 02:29:14 -0700 Message-ID: <3D9EB0A4.4CD09E20@mindspring.com> Date: Sat, 05 Oct 2002 02:28:04 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Lawson Cc: David Francheski , freebsd-arch@FreeBSD.ORG, freebsd-smp@FreeBSD.org Subject: Re: Running independent kernel instances on dual-Xeon/E7500 system References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Lawson wrote: > On Fri, 4 Oct 2002, David Francheski wrote: > > I have a dual-Xeon processor (with E7500 chipset) motherboard. > > Can anybody tell me what the development effort would be to > > boot and run two independent copies of the FreeBSD kernel, > > one on each Xeon processor? By this I mean that an SMP > > enabled kernel would not be utilized, each kernel would be UP. > > > > Regards, > > David L. Francheski > > Not possible without another BIOS, PCI bus, and separate memory -- > i.e. another PC. IPL'ing is not the same as "running". So long as you crafted the memory image of the second OS and its page tables, etc., using the first processor, there should be no problem running a second copy of an OS on an AP, as a result of a START IPI from the BP, after the code is crafted. Thus there is no need for a separate BIOS. For running, there are two types of devices which one cares about: devices which can be duplicated, and therefore assigned as seperate resources, and devices which cannot. For PCI devices, this breaks down to an interrupt routing issue. There are four PCI interrupts: A, B, C, and D. So long as no device allocated to each processor does not share an interrupt, there is no problem. Thus you do not need a separate PCI bus. Note: For devices which cannot be shared, but which are required, there are two approaches: the device may be virtualized, and then access to it contended between the processors, or the device may be virtualized in one instance, and accessed via proxy to the other processor (e.g. via IPI triggers for IPC). VMWare operates this way for a number of its own devices, which can not be physical devices, since they must be shared with the host OS, rather than assigned directly to the VMWare "machine", or to the host OS (both are available options for many devices). The memory can be seperated logically, rather than physically. In fact, one could either use the PAE mode in exclusively 4K page mode, or the PSE-36, exclusively in 4M page mode, without significant changes to the VM system, to permit motherboards that can handle it to wupport up to 4G of physical RAM per CPU, up to 16 CPUs (the practical limitations on this due to motherboard availability is 4). Thus there is no need for physically seperate memory. The 4K mode would require an additional layer of indirection (Peter Wemm may actually have completed some or all of the code necessary for PAE use alread), and the 4M (PSE-36) mode would require hacking the system to be able to use 4M pages, rather than 4K (mostly, this effect the paging paths themselves; you would likely get 2M pages (for PAE large pages, which are 2M instead of 4M in size) for use in PAE out of this for free, if you went to a "power of two multiple of 4K" size parameter for paging operations. -- I've personally considered pursuing the ability to run code seperately, though with the same 4G address space, seperated, so as to permit running a debugger against a "crashed" FreeBSD "system" running on an AP, doing the debugging from the BP, as a hosted system. The cost in labor would be 2-3 months of continuous work, I think... that is the estimate I arrived at, when I considered the project previously. Doing this certaily beats the cost of buying an ICE to get similar capability. It would be interesting to see what other people have to say on this, other than "can't be done" (not to pick on you in particular, here; this is the knee-jerk reaction many people have to things like this). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 3: 0:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D99E137B401; Sat, 5 Oct 2002 03:00:43 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E2EB43E6A; Sat, 5 Oct 2002 03:00:43 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g95A0ZvU023752; Sat, 5 Oct 2002 03:00:39 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210051000.g95A0ZvU023752@gw.catspoiler.org> Date: Sat, 5 Oct 2002 03:00:35 -0700 (PDT) From: Don Lewis Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] To: jmallett@FreeBSD.ORG Cc: arch@FreeBSD.ORG In-Reply-To: <20021005002021.A14635@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 5 Oct, Juli Mallett wrote: > diff -Nrdu -x *CVS* -x *dev* sys/kern/kern_exit.c kernel/kern/kern_exit.c > --- sys/kern/kern_exit.c Tue Oct 1 12:15:51 2002 > +++ kernel/kern/kern_exit.c Sat Oct 5 01:20:57 2002 > @@ -209,12 +210,12 @@ > PROC_LOCK(p); > if (p == p->p_leader) { > q = p->p_peers; > + PROC_UNLOCK(p); > while (q != NULL) { > - PROC_LOCK(q); > psignal(q, SIGKILL); > - PROC_UNLOCK(q); > q = q->p_peers; > } > + PROC_LOCK(p); > while (p->p_peers) > msleep(p, &p->p_mtx, PWAIT, "exit1", 0); > } This scary looking fragment of code in exit1() is relying on the lock on p->p_leader being continuously held to prevent the p_peers list from changing while the list traversal is in progress. The code in kern_fork.c and elsewhere in kern_exit.c holds a lock on p_leader while the list modifications are done. The existing code looks like it could deadlock if q is locked because it is in fork() or exit(). Process p will block when it tries to lock q, and q will block when it tries to lock its p_leader, which happens to be p. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 3: 2: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 6EEF437B401; Sat, 5 Oct 2002 03:02:08 -0700 (PDT) Date: Sat, 5 Oct 2002 03:02:08 -0700 From: Juli Mallett To: Don Lewis Cc: arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021005030208.A22398@FreeBSD.org> References: <20021005011257.A16980@FreeBSD.org> <200210050929.g959T1vU023691@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210050929.g959T1vU023691@gw.catspoiler.org>; from dl-freebsd@catspoiler.org on Sat, Oct 05, 2002 at 02:29:01AM -0700 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Don Lewis [ Data: 2002-10-05 ] [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > The following code never sets error to anything other than zero. It > also looks like it is missing a return statement for the malloc() failed > case. Oops. That's because of the hefty use of the 'd' key in vi when removing local additions. Thanks. > +int > +ksiginfo_alloc(struct ksiginfo **ksip, struct proc *p, int signo) > +{ > + int error; > + struct ksiginfo *ksi; > + > + error = 0; > + > + PROC_LOCK_ASSERT(p, MA_NOTOWNED); > + ksi = malloc(sizeof *ksi, M_KSIGINFO, M_ZERO | M_NOWAIT); > + if (ksi == NULL) { > + PROC_LOCK(p); > + p->p_suicide = 1; > + PROC_UNLOCK(p); > + } > + ksi->ksi_signo = signo; > + if (curproc != NULL) { > + ksi->ksi_pid = curproc->p_pid; > + ksi->ksi_ruid = curproc->p_ucred->cr_uid; > + } > + *ksip = ksi; > + return (error); > +} > > > > > > -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 7:32:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B51DB37B401; Sat, 5 Oct 2002 07:32:12 -0700 (PDT) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCF843E4A; Sat, 5 Oct 2002 07:32:11 -0700 (PDT) (envelope-from antony.t.curtis@ntlworld.com) Received: from ntlworld.com ([81.98.112.116]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021005143209.SBZP28874.mta06-svc.ntlworld.com@ntlworld.com>; Sat, 5 Oct 2002 15:32:09 +0100 Message-ID: <3D9EF6E9.9040700@ntlworld.com> Date: Sat, 05 Oct 2002 15:27:53 +0100 From: Antony T Curtis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021004 X-Accept-Language: en-gb, en-us, en MIME-Version: 1.0 To: Terry Lambert Cc: Nate Lawson , David Francheski , freebsd-arch@FreeBSD.ORG, freebsd-smp@FreeBSD.org Subject: Re: Running independent kernel instances on dual-Xeon/E7500 system References: <3D9EB0A4.4CD09E20@mindspring.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm interested in persueing the idea of creating some form of partitioning within one machine.... Kind of like wrapping up as many global variables as possible and sharing the memory between them. Things like netgraph to be used to allow each 'partition' to have its own network interface and for communication between them. Admittedly, I'm no expert on operating systems but I have been trying to study the FreeBSD sources to see if I can do some crude implementation, partly to satisfy my own curiosity. Terry Lambert wrote: > Nate Lawson wrote: > >>On Fri, 4 Oct 2002, David Francheski wrote: >> >>>I have a dual-Xeon processor (with E7500 chipset) motherboard. >>>Can anybody tell me what the development effort would be to >>>boot and run two independent copies of the FreeBSD kernel, >>>one on each Xeon processor? By this I mean that an SMP >>>enabled kernel would not be utilized, each kernel would be UP. >>> >>>Regards, >>>David L. Francheski >> >>Not possible without another BIOS, PCI bus, and separate memory -- >>i.e. another PC. > > > IPL'ing is not the same as "running". So long as you crafted the > memory image of the second OS and its page tables, etc., using the > first processor, there should be no problem running a second copy > of an OS on an AP, as a result of a START IPI from the BP, after > the code is crafted. Thus there is no need for a separate BIOS. > > For running, there are two types of devices which one cares about: > devices which can be duplicated, and therefore assigned as seperate > resources, and devices which cannot. For PCI devices, this breaks > down to an interrupt routing issue. There are four PCI interrupts: > A, B, C, and D. So long as no device allocated to each processor > does not share an interrupt, there is no problem. Thus you do not > need a separate PCI bus. > > Note: For devices which cannot be shared, but which are required, > there are two approaches: the device may be virtualized, and then > access to it contended between the processors, or the device may > be virtualized in one instance, and accessed via proxy to the other > processor (e.g. via IPI triggers for IPC). VMWare operates this > way for a number of its own devices, which can not be physical > devices, since they must be shared with the host OS, rather than > assigned directly to the VMWare "machine", or to the host OS (both > are available options for many devices). > > The memory can be seperated logically, rather than physically. In > fact, one could either use the PAE mode in exclusively 4K page mode, > or the PSE-36, exclusively in 4M page mode, without significant > changes to the VM system, to permit motherboards that can handle it > to wupport up to 4G of physical RAM per CPU, up to 16 CPUs (the > practical limitations on this due to motherboard availability is 4). > Thus there is no need for physically seperate memory. The 4K mode > would require an additional layer of indirection (Peter Wemm may > actually have completed some or all of the code necessary for PAE > use alread), and the 4M (PSE-36) mode would require hacking the > system to be able to use 4M pages, rather than 4K (mostly, this > effect the paging paths themselves; you would likely get 2M pages > (for PAE large pages, which are 2M instead of 4M in size) for use > in PAE out of this for free, if you went to a "power of two multiple > of 4K" size parameter for paging operations. > > -- > > I've personally considered pursuing the ability to run code seperately, > though with the same 4G address space, seperated, so as to permit > running a debugger against a "crashed" FreeBSD "system" running on an > AP, doing the debugging from the BP, as a hosted system. The cost > in labor would be 2-3 months of continuous work, I think... that is > the estimate I arrived at, when I considered the project previously. > Doing this certaily beats the cost of buying an ICE to get similar > capability. > > > It would be interesting to see what other people have to say on this, > other than "can't be done" (not to pick on you in particular, here; > this is the knee-jerk reaction many people have to things like this). > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > -- Antony T Curtis BSc Unix Analyst Programmer http://homepage.ntlworld.com/antony.t.curtis/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 11:17: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A18A37B401; Sat, 5 Oct 2002 11:16:58 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07DCD43E3B; Sat, 5 Oct 2002 11:16:58 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g95IGvgQ026881 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 5 Oct 2002 14:16:57 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g95IGu7K026880; Sat, 5 Oct 2002 14:16:56 -0400 (EDT) (envelope-from wollman) Date: Sat, 5 Oct 2002 14:16:56 -0400 (EDT) From: Garrett Wollman Message-Id: <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu> To: jmallett@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <20021005002021.A14635@FreeBSD.org> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.ORG, mike@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20021005002021.A14635@FreeBSD.org> you write: >To accomodate situations where allocation of a 'ksiginfo' is a >failure mode (no memory), the destination process is told to exit via >a new member of 'struct proc', p_suicide, which tells a process to >kill itself next time it goes through userret. This is one of the reasons why I much prefer to keep the existing signal-pending bitmaps. It should *always* be possible to deliver a (non-real-time) signal to a process; it is legitimate that the delivery of additional information may fail due to a lack of resources. This also makes it possible to optimize the common case of an application which has not requested RTS behavior for the signal it is receiving. Obviously, SIGSTOP and SIGKILL can never have RTS behavior since they cannot be caught. Since there are special delivery rules for both of them (see POSIX once again) they need to be special-cased anyway. (Likewise SIGCONT, although it is at least conceivable that an application might want extended information for SIGCONT, though Tana only knows what they'd do with it.) >The most notable change is that the most recently sent && lowest >numbered signal is sent, in the normal course of events, rather than >simply the lowest numbered or most recently sent. This still isn't right. Real-time signals are QUEUED -- i.e., signals of the same species are delivered in FIFO, not LIFO, order. POSIX further specifies that signal N will be delivered before signal N+k, for SIGRTMIN <= N <= N+k <= SIGRTMAX. The relative delivery order of any signals outside of this range is unspecified beyond the special behavior of SIGCONT, SIGSTOP, and SIGKILL. Please read section 2.4 of the System Interfaces volume of IEEE Std.1003.1-2001 very carefully before proceeding. If you do not have a copy of the standard, I think Mike Barcroft still has a few copies of The Open Group's ``authorized guidebook'' which includes a CD-ROM of the full standard. -GAWollman -- Garrett A. Wollman | [G]enes make enzymes, and enzymes control the rates of wollman@lcs.mit.edu | chemical processes. Genes do not make ``novelty- Opinions not those of| seeking'' or any other complex and overt behavior. MIT, LCS, CRS, or NSA| - Stephen Jay Gould (1941-2002) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 11:33:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 7D60737B401; Sat, 5 Oct 2002 11:33:33 -0700 (PDT) Date: Sat, 5 Oct 2002 11:33:33 -0700 From: Juli Mallett To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021005113333.A56357@FreeBSD.org> References: <20021005002021.A14635@FreeBSD.org> <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu>; from wollman@lcs.mit.edu on Sat, Oct 05, 2002 at 02:16:56PM -0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Garrett Wollman [ Data: 2002-10-05 ] [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > >The most notable change is that the most recently sent && lowest > >numbered signal is sent, in the normal course of events, rather than > >simply the lowest numbered or most recently sent. > > This still isn't right. Real-time signals are QUEUED -- i.e., signals > of the same species are delivered in FIFO, not LIFO, order. POSIX > further specifies that signal N will be delivered before signal N+k, > for SIGRTMIN <= N <= N+k <= SIGRTMAX. The relative delivery order of > any signals outside of this range is unspecified beyond the special > behavior of SIGCONT, SIGSTOP, and SIGKILL. OK, well, then it's a matter of :s/_INSERT_HEAD/_INSERT_TAIL/. As for only doing this for RTS, we'd have to duplicate large portions of the signal code, and sendsig stuff, and have two seperate interfaces. > Please read section 2.4 of the System Interfaces volume of IEEE > Std.1003.1-2001 very carefully before proceeding. If you do not have > a copy of the standard, I think Mike Barcroft still has a few copies > of The Open Group's ``authorized guidebook'' which includes a CD-ROM > of the full standard. I have one of those, and I meant to stuff it on our fileserver and move the appropriate data into our books directory. Haven't yet. I suck. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 12:27:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79CB337B401; Sat, 5 Oct 2002 12:27:12 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F8EA43E6A; Sat, 5 Oct 2002 12:27:12 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0044.cvx22-bradley.dialup.earthlink.net ([209.179.198.44] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17xuZy-0001vF-00; Sat, 05 Oct 2002 12:27:10 -0700 Message-ID: <3D9F3CC1.CF467B87@mindspring.com> Date: Sat, 05 Oct 2002 12:25:53 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: jmallett@FreeBSD.ORG, arch@FreeBSD.ORG, mike@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] References: <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garrett Wollman wrote: (Likewise SIGCONT, although it is at least > conceivable that an application might want extended information for > SIGCONT, though Tana only knows what they'd do with it.) Restart on a different tty. Like "login/attach" in VMS, so you can take over a persistent session remotely, or just from a different terminal, when your lab sign-up has expired... 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 15:42:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6F9837B404 for ; Sat, 5 Oct 2002 15:42:11 -0700 (PDT) Received: from montevideo.com.uy (r200-61-110-20.multitel.net.uy [200.61.110.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3886C43E77 for ; Sat, 5 Oct 2002 15:42:04 -0700 (PDT) (envelope-from rplsd@montevideo.com.uy) From: "La Sociedad Digital" To: (La Sociedad Digital) Subject: Presentacion de La Sociedad Digital / A Sociedade Digital. Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 7 Oct 2002 08:20:06 -0300 Reply-To: "La Sociedad Digital" Content-Transfer-Encoding: 8bit Message-Id: <20021005224204.3886C43E77@mx1.FreeBSD.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Presentacion de La Sociedad Digital. (texto version española/texto version portuguesa). Boletín 1 / Octubre de 2002. LA SOCIEDAD DIGITAL - PORTAL IBEROAMERICANO DE LA SOCIEDAD DE LA INFORMACIÓN. http://www.sociedaddigital.org PRESENTACION: La Sociedad Digital se ha constituido en el principal Portal de la Sociedad de la Información en Ibero América, comprendiendo en la actualidad cerca de quince secciones con un total de documentos estimable en aproximadamente 800, que cubren las áreas más importantes de la Sociedad de la Información. Ello ha sido posible gracias al aporte y la preocupación de un conjunto de especialistas de uno y otro lado del Atlántico, concentrados en este proyecto abierto que comenzó a ser construido en su expresión virtual en octubre de 2001. En la actualidad, la mayor parte de las secciones del Portal se encuentran operativas. El proyecto se viene desarrollando de conformidad con las coordenadas propias de su primera fase: constitución ordenada de un reservorio de información actualizada de elevadas trascendencia para la comprensión de la sociedad en Red conjuntamente con aportes propios producto de investigación colectiva por parte de los equipos de La Sociedad Digital o de aportes individuales de los miembros de su Board de Directores, en el marco de sus respectivas especialidades. ---------------------------------------------------------------------- --------- ESTRUCTURA: Las actuales secciones disponibles del Proyecto Portal de la Sociedad de la Información http://www.sociedaddigital.org son las siguientes: ---------------------------------------------------------------------- -------- NOVEDADES: Las incorporaciones documentales más recientes en el Portal: ---------------------------------------------------------------------- -------- EVENTOS CIENTÍFICOS A DESTACAR: ---------------------------------------------------------------------- ------- INFORMACIONES DEL BOARD: ---------------------------------------------------------------------- ------ PROYECTOS EN DESARROLLO: En este momento, La Sociedad Digital se encuentra desarrollando varios proyectos nuevos, los que se encuentran en diferentes etapas de progreso. En síntesis: (a) Los aspectos operativos: el Portal se encuentra en remodelación, para una presentación en el futuro que pueda considerarse más amigable en su relación con el usuario, y que permitirá un despliegue de mayor agilidad de su contenido documental, así como la correlación temática de sus contenidos. (b) El sistema estadístico: dentro de los proyectos de investigación oportunamente planteados se diseñó un completo sistema estadístico que pudiera ser considerado como uno de los más completos del mundo, reuniendo y conciliando información de al menos veinte fuentes confiables de información, para permitir conocer los principales indicadores de la Sociedad de la Información, al menos en tres grandes niveles de desagregación: contexto mundial, contexto continental y situación de los países. Los indicadores mencionados comprenden accesibilidad, desarrollo de telecomunicaciones, infraestructura de Internet, comercio electrónico, lenguajes en la Red e indicadores representativos de ciencia y tecnología. El trabajo continúa y se estima que estará disponible "en red" en aproximadamente dos meses. (c) Estudio del estado de la Sociedad de la Información en América Latina: este proyecto de investigación, de naturaleza colectiva y abierta, ha culminado su fase de diseño y de términos de referencia. En el decurso del mes de junio comenzará a ser operativo, y se espera llegar con un diagnóstico adecuado hacia fines del presente año y convertirlo en un aporte independiente y trascendente para ser presentado en la Cumbre de la Sociedad de la Información en Junio de 2003. Informaciones y contribuciones en info sociedaddigital.org (d) Colección de estudios e información sobre aspectos prácticos del comercio electrónico: se constituirá en una de las secciones del Portal, considerada de alta utilidad. Se continúa trabajando en la clasificación de la biblioteca virtual aportada por el Consejero Hugo Gallegos de Perú y la sección se encontrará "en Red" en aproximadamente veinte días. --------------------------------------------------------------------- ---------- Usted recibe este mensaje porque su dirección de correo electrónico está incluida dentro de las más de 100.000 que conforman LA SOCIEDAD DIGITAL, construida por referencias o bien por la relevancia de su trabajo, comunidad científica donde se discuten ideas, visiones, experiencias, prácticas e información sobre temas relacionados con La Sociedad de la Información, en especial en Ibero América, impulsada por la Asociación Civil sin fines de lucro La Sociedad Digital. Si quiere tramitar el ALTA o la BAJA, o remitir una dirección de correo electrónico a la comunidad, envíe un mensaje a info@sociedaddigital.org Si desea dar a conocer algún artículo, estudio u otro texto de su autoría o recomendarnos un trabajo de otro autor, envíe su material o recomendaciones a info sociedaddigital.org La Sociedad Digital es un esfuerzo nacido en el Uruguay, co participado por especialistas de toda Iberoamerica y dirigido a la comunidad digital ibero americana. ---------------------------------------------------------------------- -------- Visite nuestro Portal y consulte todos los recursos gratuitos de información y conocimiento sobre Sociedad de la Información disponibles en http://www.sociedaddigital.org Hasta nuestro próximo encuentro! Equipo de comunicación de LaSocDig. Boletim 1 / Outubro de 2002. LA SOCIEDAD DIGITAL - PORTAL IBERO-AMERICANO DA SOCIEDADE DE INFORMAÇÃO www.sociedaddigital.org APRESENTAÇÃO La Sociedad Digital tem se constituído no principal portal da sociedade de informação da região ibero-americana, compreendendo, na atualidade, cerca de quinze seções com um total de documentos estimado em aproximadamente 800, que abordam as áreas mais importantes da sociedade da informação. Isto tem sido possível graças ao aporte e preocupação de um conjunto de especialistas dos dois lados do Atlântico, que se concentraram neste projeto aberto, cuja constituição, em sua expressão virtual, iniciou-se em outubro de 2001. No momento, a maior parte das seções do portal se encontra em funcionamento. O projeto vem se aperfeiçoando na seqüência das mesmas coordenadas estabelecidas em sua primeira fase: constituição ordenada de um reservatório de informações atualizadas e de elevada transcendência para a compreensão da sociedade da Rede, conjuntamente com as contribuições das equipes de La Sociedad Digital, produto da investigação coletiva, bem como outros aportes individuais dos membros de seu corpo de conselheiros, em suas respectivas especialidades. O Projeto Portal da Sociedade da Informação e suas seções disponíveis no endereço www.sociedaddigital.org ---------------------------------------------------------------------- ------ PROJETOS EM DESENVOLVIMENTO: Neste momento, La Sociedad Digital encontra-se desenvolvendo vários projetos novos, os quais se encontram em diferentes fases. Em síntese: (a) Aspectos operativos: o Portal se encontra em reformulação para uma apresentação futura mais amigável em sua relação com o usuário, com um desdobramento mais ágil de seus documentos e da correlação temática de seus conteúdos. (b) Sistema estatístico: dentro dos projetos de investigação a serem oportunamente implantados, elaborou-se um sistema estatístico que pudesse ser considerado como um dos mais completos do mundo, reunindo e conciliando informações extraídas de, pelo menos, vinte fontes confiáveis de informação, ao menos em três grandes níveis de desagregação: contexto mundial, contexto continental e situação dos países. Os indicadores mencionados compreendem: acessibilidade, desenvolvimento das telecomunicações, infraestrutura da Internet, comércio eletrônico, linguagens da Rede e indicadores representativos da ciência e tecnologia. O trabalho continua e se estima que estará disponível em, aproximadamente, dois meses. (c) Estudos sobre a Sociedade da Informação na América Latina: este projeto de investigação, de natureza coletiva e aberta, finalizou sua fase de elaboração e de termos de referência. No decurso do mês de junho entrou em operação e se espera chegar a um diagnóstico adequado até o final do ano, ocasião em que será convertido em aporte independente e transcendente, para ser apresentado à Cúpula da Sociedade de Informação, em junho de 2003. Informações e contribuições no info@sociedaddigital.org (d) Estudos sobre o comércio eletrônico na América Latina: o projeto, como o anterior, de natureza coletiva e aberta, também concretizou sua fase de elaboração e de termos de referência. Seu funcionamento está previsto para o decurso do mês de julho, culminando em dezembro de 2002. Estará contribuindo assim para a continuidade dos estudos que, a respeito do comércio eletrônico, desenvolveram-se na ALADI entre 2000 e 2001. Informações e contribuições no info@sociedaddigital.org (e) Coletâneas de estudos e informações sobre aspectos práticos do comércio eletrônico: será uma das seções do Portal, considerada de alta utilidade. Está em desenvolvimento o trabalho de classificação da biblioteca virtual, contribuição do Conselheiro Hugo Gallegos, do Peru. A seção estará disponível na Rede em, aproximadamente, vinte dias. --------------------------------------------------------------------- ---------- Você recebe essa mensagem porque seu correio eletrônico está incluído em mais de 100.000 que configuram LA SOCIEDAD DIGITAL, comunidade científica, onde se discutem idéias, visões, experiências, práticas e informações sobre temas relacionados com a Sociedade da Informação, em especial na região ibero-americana, promovida pela associação civil sem fins lucrativos La Sociedad Digital, e pela Sociedad Digital Internet Research. Se desejar incluir, excluir ou redefinir a direção do correio eletrônico, envie uma mensagem para info@sociedaddigital.org Se desejar enviar algum artigo, estudo, texto de sua autoria ou recomendar o trabalho de outro autor, envie seu material ou recomendações a info@sociedaddigital.org ---------------------------------------------------------------------- -------- Visite nosso Portal e consulte todos os recursos gratuitos de informação e conhecimento sobre Sociedade da Informação, disponíveis no endereço www.sociedaddigital.org Até nosso próximo encontro!!! Equipe de Comunicação de LaSocDig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 19: 8: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCF4037B401; Sat, 5 Oct 2002 19:08:06 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 781B843E75; Sat, 5 Oct 2002 19:08:06 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 2DBD4AE165; Sat, 5 Oct 2002 19:08:06 -0700 (PDT) Date: Sat, 5 Oct 2002 19:08:06 -0700 From: Alfred Perlstein To: Juli Mallett Cc: Garrett Wollman , arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021006020806.GV95327@elvis.mu.org> References: <20021005002021.A14635@FreeBSD.org> <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu> <20021005113333.A56357@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021005113333.A56357@FreeBSD.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Juli Mallett [021005 11:33] wrote: > * De: Garrett Wollman [ Data: 2002-10-05 ] > [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > > >The most notable change is that the most recently sent && lowest > > >numbered signal is sent, in the normal course of events, rather than > > >simply the lowest numbered or most recently sent. > > > > This still isn't right. Real-time signals are QUEUED -- i.e., signals > > of the same species are delivered in FIFO, not LIFO, order. POSIX > > further specifies that signal N will be delivered before signal N+k, > > for SIGRTMIN <= N <= N+k <= SIGRTMAX. The relative delivery order of > > any signals outside of this range is unspecified beyond the special > > behavior of SIGCONT, SIGSTOP, and SIGKILL. > > OK, well, then it's a matter of :s/_INSERT_HEAD/_INSERT_TAIL/. As for > only doing this for RTS, we'd have to duplicate large portions of the > signal code, and sendsig stuff, and have two seperate interfaces. > > > Please read section 2.4 of the System Interfaces volume of IEEE > > Std.1003.1-2001 very carefully before proceeding. If you do not have > > a copy of the standard, I think Mike Barcroft still has a few copies > > of The Open Group's ``authorized guidebook'' which includes a CD-ROM > > of the full standard. > > I have one of those, and I meant to stuff it on our fileserver and move > the appropriate data into our books directory. Haven't yet. I suck. You've done a lot of very good work. I'd also like to thank Garrett for taking the time to do the standards digging. That said I'm concerned that you haven't addressed the issue of the signal bitmask, basically being unable to send a non-siginfo style signal shouldn't fail because of lack of memory. I'm wondering if this is actually an issue or not, please pardon me for not UTSL'ing as of yet if it is taken care of. I'm not sure if this is feasable but it would seem like having a bitmask for RTS and non-RTS might work, with the special case being deqeueing the siginfo when it shows up in the RTS mask. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 5 19:20:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 7906437B401; Sat, 5 Oct 2002 19:20:12 -0700 (PDT) Date: Sat, 5 Oct 2002 19:20:12 -0700 From: Juli Mallett To: Alfred Perlstein Cc: Garrett Wollman , arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <20021005192012.A87801@FreeBSD.org> References: <20021005002021.A14635@FreeBSD.org> <200210051816.g95IGu7K026880@khavrinen.lcs.mit.edu> <20021005113333.A56357@FreeBSD.org> <20021006020806.GV95327@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021006020806.GV95327@elvis.mu.org>; from bright@mu.org on Sat, Oct 05, 2002 at 07:08:06PM -0700 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Alfred Perlstein [ Data: 2002-10-05 ] [ Subjecte: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] ] > You've done a lot of very good work. I'd also like to thank Garrett for > taking the time to do the standards digging. Yeah, Garrett's great for keeping us from being lazy by letting us be just lazy enough to have to do some real work :) > That said I'm concerned that you haven't addressed the issue of the > signal bitmask, basically being unable to send a non-siginfo style > signal shouldn't fail because of lack of memory. I'm wondering if > this is actually an issue or not, please pardon me for not UTSL'ing > as of yet if it is taken care of. I've been talking with rwatson about a number of possibilities. The idea I like best so far is to just send a fake kernel-originated (as far as the siginfo_t says) signal for each signal that can be sent, e.g. static struct ksiginfo nullsig[NSIG]; (in a SYSINIT) bzero(&nullsig, sizeof nullsig); for (i = 0; i < NSIG; i++) nullsig[i].ksi_signo = i; (if we fail allocation) *ksip = &nullsig[signo]; Robert has pointed out a number of other possibilites, particular with regards to just disregarding the signal, and letting the upper layer decide if it should be re-sent... Both of us are looking into this... Right now I think it may end up being a combination of methods, possibly adding some new facilities in the kernel like an OOM killer, where an app can be flagged (by root) as non-killable in the OOM kase... And sending SIGNOMEM to apps which have installed handlers for it, so that they can free optional resources, if they are so inclined, etc. > I'm not sure if this is feasable but it would seem like having a > bitmask for RTS and non-RTS might work, with the special case being > deqeueing the siginfo when it shows up in the RTS mask. I prefer a generalised approach to all signals, especially since SunOS (ok, Solaris) sends "sender" information for all signals (istr), and that furthermore SIGCHLD contains information about what child died. Very useful stuff, IMO. Thanks, juli. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message