From owner-freebsd-arch Sun Sep 22 15:43:19 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 D5DB937B401 for ; Sun, 22 Sep 2002 15:43:18 -0700 (PDT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [62.212.105.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 549AD43E4A for ; Sun, 22 Sep 2002 15:43:18 -0700 (PDT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id B35CD2C3D1; Mon, 23 Sep 2002 00:43:15 +0200 (CEST) Date: Mon, 23 Sep 2002 00:43:15 +0200 From: Thomas Quinot To: freebsd-arch@freebsd.org Subject: Code factoring in /etc/periodic/security firewall checks Message-ID: <20020922224315.GA71199@melusine.cuivre.fr.eu.org> References: <20020918235930.D58595@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020918235930.D58595@melusine.cuivre.fr.eu.org> User-Agent: Mutt/1.4i X-message-flag: WARNING! Using Outlook can damage your computer. 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 Much code duplication exists in /etc/periodic/security scripts. I would like to propose that most of the complexity of these scripts be factored out into a common file. The patch at http://www.cuivre.fr.eu.org/~thomas/periodic-security/ factors the common code out of 100.chksetuid, 200.chkmounts, 500.ipfwdenied, 600.ip6fwdenied and 700.kernelmsg. It also adds a new script, 501.ipfdenied, similar in purpose to 500.ipfwdenied but for use with ipfilter. If there are no objections I intend to commit this to -CURRENT around Oct. 1st. Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 22 18:47:41 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 AEF1737B401 for ; Sun, 22 Sep 2002 18:47:40 -0700 (PDT) Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42BFF43E97 for ; Sun, 22 Sep 2002 18:47:40 -0700 (PDT) (envelope-from billh@gnuppy.monkey.org) Received: from billh by gnuppy.monkey.org with local (Exim 3.36 #1 (Debian)) id 17tIJt-0000t5-00; Sun, 22 Sep 2002 18:47:29 -0700 Date: Sun, 22 Sep 2002 18:47:29 -0700 To: Terry Lambert Cc: Daniel Eischen , freebsd-arch@FreeBSD.ORG Subject: Re: New Linux threading model Message-ID: <20020923014729.GA3362@gnuppy.monkey.org> References: <3D8B62DB.C27B7E07@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8B62DB.C27B7E07@mindspring.com> User-Agent: Mutt/1.4i From: Bill Huey (Hui) 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, Sep 20, 2002 at 11:03:07AM -0700, Terry Lambert wrote: > By going to 1:1, they dodge this issue; but in so doing, they > increase threads overhead to that of processes: threads become > a mechanism for sharing some resources: the moral equivalent of > the old rfork()/sfork() system calls for heap and descriptor > space sharing, with seperate stacks. Conceptually this is definitely the case, but this says otherwise for the particular operations they outline in this email: http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1581.html Not sure what to think about this... bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 22 20:42:18 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 7826537B401 for ; Sun, 22 Sep 2002 20:42:16 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 168D343E42 for ; Sun, 22 Sep 2002 20:42:12 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0439.cvx22-bradley.dialup.earthlink.net ([209.179.199.184] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17tK6d-0007kd-00; Sun, 22 Sep 2002 20:41:56 -0700 Message-ID: <3D8E8A99.CED8BAD0@mindspring.com> Date: Sun, 22 Sep 2002 20:29:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bill Huey (Hui)" Cc: Daniel Eischen , freebsd-arch@FreeBSD.ORG Subject: Re: New Linux threading model References: <3D8B62DB.C27B7E07@mindspring.com> <20020923014729.GA3362@gnuppy.monkey.org> 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 "Bill Huey (Hui)" wrote: > On Fri, Sep 20, 2002 at 11:03:07AM -0700, Terry Lambert wrote: > > By going to 1:1, they dodge this issue; but in so doing, they > > increase threads overhead to that of processes: threads become > > a mechanism for sharing some resources: the moral equivalent of > > the old rfork()/sfork() system calls for heap and descriptor > > space sharing, with seperate stacks. > > Conceptually this is definitely the case, but this says otherwise > for the particular operations they outline in this email: > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1581.html > > Not sure what to think about this... The first set were the microbenchmarks I was talking about being unrepresentative of a system load where the test processes were actually competing with other processes, because they were run in a single process on an otherwise quiescent system. The second set match the overload behaviour I suggested that should be expected under overload conditions, where the overall performance degrades to (effectively) non-affinity performance. They noted these as issues, themselves, near the end of the email, without providing a real analysis as to why: | The results of this test series are: | | - - LinuxThreads indeed had several problems | | - - NGPT indeed run much faster (twice the performance) | | - - NPTL runs four times faster than NGPT in a benchmark which by all | means should favor an M-on-N implementation. This still misses the multiple benchmark processes running multithreaded simultaneously, which I think would demonstrate a third stair-step in performance. Note that there is probably a fourth, which would be missed, unless the test programs were copied to duplicate program inages, rather than running out of the same executable image file, to ensure against page sharing among the competing images. I'd still like to see *that* benchmark, because I believe it would be worst-case for the scheduler design, but common enough with, e.g., a mail server like sendmail, qmail, or postfix, or with Samba. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 24 0: 3:47 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 C8CF037B401 for ; Tue, 24 Sep 2002 00:03:42 -0700 (PDT) Received: from yahoo.com (host-148-244-255-250.block.alestra.net.mx [148.244.255.250]) by mx1.FreeBSD.org (Postfix) with SMTP id 8E7E443E42 for ; Tue, 24 Sep 2002 00:03:33 -0700 (PDT) (envelope-from MarketingandMore0923@yahoo.com) From: Tools4Marketing To: Reply-To: Subject: Lists: Publicity - Libraries - Bookstores - Galleries - Producers - Custom - Agents - (more) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20020924070333.8E7E443E42@mx1.FreeBSD.org> Date: Tue, 24 Sep 2002 00:03:33 -0700 (PDT) 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 UNLIMITED USE LISTS . . .DOWNLOAD WITHIN MINUTES. -------------------------------------------------------------- NEW LISTS: PBS STATIONS, UK MEDIA, POLITICAL MEDIA, NEW AGE MEDIA, UK LIBRARIES, SCIENTIFIC JOURNALS, FILM & TV PRODUCERS, ART PUBLISHERS, LITERARY AGENTS, MENS MEDIA. -------------------------------------------------------------- IF WE DO NOT HAVE THE LIST YOU NEED, WE WILL COMPILE A CUSTOM LIST ACCORDING TO YOUR SPECIFICATIONS -------------------------------------------------------------- Call to place your order or for more information. US & CANADA TOLL-FREE NUMBER: 888 330 4919 (24/7) If you would like more information via email, please write us at sendlistinfo@netscape.net - Thank you. -------------------------------------------------------------- LIBRARIES LISTS INCLUDE: Name, Address, phone, fax and email address (when available). AVAILABLE FORMATS: Excel Spreadsheet & Text Database 1,200 U.S. Public Libraries WITH EMAIL ADDRESSES - $109 1,200 U.S. Public Libraries - $89 1,000 U.S. University Libraries WITH EMAIL ADDRESSES - $89 1,000 U.S. University Libraries - $69 400+ Community College Libraries WITH EMAIL ADDRESSES - $59 400+ Community College Libraries - $49 1,093 U.S. K-12 Private School Libraries WITH EMAIL ADDRESSES - $109 1,093 U.S. K-12 Private School Libraries - $89 200 U.K. Public Libraries WITH EMAIL ADDRESSES - $49 200 U.K. Public Libraries - $39 250 U.K. University Libraries WITH EMAIL ADDRESSES - $49 250 U.K. University Libraries - $39 528 Australian Public Libraries WITH EMAIL ADDRESSES - $79 528 Australian Public Libraries - $69 279 Australian College & Univ. Libraries WITH EMAIL ADDRESSES - $49 279 Australian College & Univ. Libraries - $39 200 Canadian Libraries WITH EMAIL ADDRESSES - $49 200 Canadian Libraries - $39 100 New Zealand Libraries WITH EMAIL ADDRESSES - $39 100 New Zealand Libraries - $29 1,000 U.S. Medical Libraries - $79 313 U.S. Law Libraries - $49 193 U.S. Religious Libraries - $39 ---------------------------------------------- BOOKSTORES LIST INCLUDES: Name, Address, phone, fax and email address (when available). AVAILABLE FORMATS: Excel Spreadsheets & Text Databases 1,900+ Independent Bookstores WITH EMAIL ADDRESSES - $149 1,900+ Independent Bookstores - $129 1,900+ College Bookstores WITH EMAIL ADDRESSES - $149 1,900+ College Bookstores - $129 3,000+ Christian Bookstores WITH EMAIL ADDRESSES - $169 3,000+ Christian Bookstores - $149 2,200+ Chain Bookstores - $129 575+ Book Distributors & Chain HQs - WITH EMAIL ADDRESSES - $59 575+ Book Distributors & Chain HQs - $ 49 675 Canadian General Bookstores WITH EMAIL ADDRESSES - $69 675 Canadian General Bookstores - $59 175 Canadian University Bookstores - WITH EMAIL ADDRESSES - $39 175 Canadian University Bookstores - $29 550+ New Age Bookstores - WITH EMAIL ADDRESSES - $59 550+ New Age Bookstores - $49 125 African-American Bookstores - $29 You will be able to download your lists WITHIN MINUTES. ----------------------------------------------- MEDIA LISTS LISTS INCLUDE: Contact Name, Title/Position, Company, Address, Phone, Fax and Email Address (when available) AVAILABLE FORMATS: Excel Spreadsheet and Microsoft Word PBS Stations (800+ Contacts) - $99 Scientific Journals (500 Contacts) - $99 UK Media List (500 Contacts) - $99 Political Media List (1,100+ Contacts) - $149 Canadian National Media (590+ Contacts) - $99 New Age Media (250+ Contacts) - $99 Mens Interest Media (400 Contacts) - $99 Womens Interest Media (1,350+ Contacts) - $149 Teen Interest Media (216 Contacts) - $99 Eclectic Newsweeklies (575+ Contacts) - $99 College Radio Stations (520+ Contacts) - $99 Local TV News (North Region) (840+ Contacts) - $99 Local TV News (Midwest Region) (870+ Contacts) - $99 Local TV News (West Region) (890+ Contacts) - $99 Local TV News (South Region) (1,100+ Contacts) - $129 Local TV News (All Regions) (3,700+ Contacts) - $249 Drive Time Radio - Top 50 Markets (300+ Contacts) - $69 Australian National Media List (360+ Contacts) - $99 Drive Time Radio - Top 100 Markets (600 Contacts) - $99 Newspapers - Top 100 Papers (1,100+ Contacts) - $99 National Media List (1000+ Contacts) - $99 Sex & Relationships Media List (402 Contacts) - $99 Music Industry Media List (1,142 Contacts) - $149 Fashion & Beauty List (1,400 Contacts) - $149 Motion Picture, Film & Video (695 Contacts) - $99 National Public Radio (265 Contacts) - $99 Sports Media List (427 Contacts) - $99 African American Media List (1500 Contacts) - $149 Environmental Media List (763 Contacts) - $99 Gay and Lesbian Media List (260 Contacts) - $99 Book Industry Media List (502 Contacts) - $99 Christian Media List (370 Contacts) - $99 Family & Parenting Media List (789 Contacts) - $99 College Newspaper Contacts (1,400+ Contacts) - $99 ------------------------------------------------- TV & FILM PRODUCERS, DIRECTORS, DEVELOPMENT EXECS, (MORE) 3,000+ Contacts - $299 (Entire List) 800+ Producers Only - $99 650+ Development, Creative & Acquisitions Contacts Only - $89 Lists Include: Contact Name, Title, Company, Address, Phone and Fax Number Available Formats: Excel Spreadsheet and Text Database PUBLISHING COMPANY CONTACTS 1,700+ U.S. Publishing Contacts - $149 300 Art Publishing Contacts - $49 List Includes: Contact Name, Title, Company, Address, Phone, Number, Fax Number and Email Address (when available) Available Formats: Excel Spreadsheet and Text Database LITERARY AGENTS 300+ Contacts - $59 List Includes: Contact Name, Title, Company, Address, Phone, Number, Fax Number and Email Address (when available) Available Formats: Excel Spreadsheet and Text Database MUSIC AGENTS/MANAGERS 150+ Contacts - $39 List Includes: Contact Name, Title, Company, Address, Phone, Fax Number and Email Address (when available) Available Formats: Excel Spreadsheet and Text Database VIDEO STORE LISTS 1573 Independent Video Stores (West) - $79 2556 Independent Video Stores (Midwest) - $99 2037 Independent Video Stores (East) - $99 2987 Independent Video Stores (South) - $129 9150 Independent Video Stores (National)- $299 Lists Include: Store Name, Address and Phone Number Available Formats: Excel Spreadsheet and Text Database MUSIC STORE LISTS 997 Independent Music Stores (Midwest) - $79 1215 Independent Music Stores (South) - $89 1444 Independent Music Stores (East) - $89 1355 Independent Music Stores (West) - $89 5008 Independent Music Stores (National)- $249 Lists Include: Store Name, Address and Phone Number Available Formats: Excel Spreadsheet and Text Database ART GALLERY LISTS US National List WITH EMAIL ADDRESSES: $169 (1090 Galleries) US National List: $149 (1090 Galleries) Southern US: $39 (140 Galleries) Central US: $39 (150 Galleries) Western US: $69 (272 Galleries) Eastern US: $89 (530 Galleries) United Kingdom: $69 (230 Galleries) Canada: $49 (165 Galleries) Australia: $29 (50 Galleries) Lists Include: Gallery Name, Address, Phone Number and Fax Number Available Formats: Excel Spreadsheet and Text Database OUR GUARANTEE: We will gladly refund postage (up to 34 cents per item) for any undeliverable addresses over 5% of the total list. We will also correct the undeliverable contacts and issue you an updated list. ------------------------ You will be able to download your lists WITHIN MINUTES. Call to place your order or for more information. US & CANADA TOLL-FREE NUMBER: 888 330 4919 (24/7) If you would like more information via email, please write us at sendlistinfo@netscape.net - Thank you. ------------------------------------------------------------------- To be removed from any future mailings, please send a message with your email address in the subject line to PublicityRemoval@netscape.net. Requests will be processed within 48 hours at that address only. Apologies for any inconvience. Thank you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 26 2:45:11 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 19E6837B401 for ; Thu, 26 Sep 2002 02:45:09 -0700 (PDT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32ECE43E77 for ; Thu, 26 Sep 2002 02:45:08 -0700 (PDT) (envelope-from mark@grimreaper.grondar.org) Received: from storm.FreeBSD.org.uk (uucp@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.5/8.12.5) with ESMTP id g8Q9j7Ln084191 for ; Thu, 26 Sep 2002 10:45:07 +0100 (BST) (envelope-from mark@grimreaper.grondar.org) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.12.5/8.12.5/Submit) with UUCP id g8Q9j7p6084190 for arch@freebsd.org; Thu, 26 Sep 2002 10:45:07 +0100 (BST) Received: from grimreaper.grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.6/8.12.5) with ESMTP id g8Q9hURP072845 for ; Thu, 26 Sep 2002 10:43:30 +0100 (BST) (envelope-from mark@grimreaper.grondar.org) Message-Id: <200209260943.g8Q9hURP072845@grimreaper.grondar.org> To: arch@freebsd.org Subject: [patch] module-with-thread exit routine. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <72685.1033033378.0@grimreaper.grondar.org> Date: Thu, 26 Sep 2002 10:43:30 +0100 From: Mark Murray 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 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72685.1033033378.1@grimreaper.grondar.org> Hi If an unloadable module has a thread (like random.ko has), then unloading the module is problematic because of the race between the module termination and the unload. The thread must "die" in a part of the code that will not be unloaded. The random device has its own code to do this, but I think this is better put with the kthread stuff. Attached is a patch to the kthread code. I've been running this for at least three months. Comments? M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72685.1033033378.2@grimreaper.grondar.org> Content-Description: kthread.diff Index: kern/kern_kthread.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_kthread.c,v retrieving revision 1.24 diff -u -d -r1.24 kern_kthread.c --- kern/kern_kthread.c 11 Sep 2002 08:13:53 -0000 1.24 +++ kern/kern_kthread.c 11 Sep 2002 11:14:02 -0000 @@ -133,6 +133,19 @@ PROC_UNLOCK(p); sx_xunlock(&proctree_lock); exit1(td, W_EXITCODE(ecode, 0)); + /* NOTREACHED */ +} + + +/* Helper routine to enable kthread_exit() to work while a module is + * being (or has been) unloaded. + */ +void +kthread_set_wakeup_exit(void *control) +{ + wakeup(control); + kthread_exit(0); + /* NOTREACHED */ } /* Index: sys/kthread.h =================================================================== RCS file: /home/ncvs/src/sys/sys/kthread.h,v retrieving revision 1.7 diff -u -d -r1.7 kthread.h --- sys/kthread.h 19 Mar 2002 20:18:36 -0000 1.7 +++ sys/kthread.h 19 Jul 2002 20:14:32 -0000 @@ -47,6 +47,7 @@ int kthread_create(void (*)(void *), void *, struct proc **, int flags, const char *, ...) __printflike(5, 6); void kthread_exit(int) __dead2; +void kthread_set_wakeup_exit(void *) __dead2; int kthread_resume(struct proc *); /* XXXKSE */ int kthread_suspend(struct proc *, int); /* XXXKSE */ void kthread_suspend_check(struct proc *); /* XXXKSE */ ------- =_aaaaaaaaaa0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 26 8: 8:49 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 5DD1C37B47B for ; Thu, 26 Sep 2002 08:08:44 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id A964043E86 for ; Thu, 26 Sep 2002 08:08:43 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26402 invoked from network); 26 Sep 2002 15:08:43 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Sep 2002 15:08:43 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g8QF8fBv091921; Thu, 26 Sep 2002 11:08:41 -0400 (EDT) (envelope-from jhb@FreeBSD.org) 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: <200209260943.g8Q9hURP072845@grimreaper.grondar.org> Date: Thu, 26 Sep 2002 11:08:43 -0400 (EDT) From: John Baldwin To: Mark Murray Subject: RE: [patch] module-with-thread exit routine. Cc: 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 26-Sep-2002 Mark Murray wrote: > Hi > > If an unloadable module has a thread (like random.ko has), then > unloading the module is problematic because of the race between > the module termination and the unload. > > The thread must "die" in a part of the code that will not be > unloaded. > > The random device has its own code to do this, but I think this > is better put with the kthread stuff. > > Attached is a patch to the kthread code. I've been running this > for at least three months. > > Comments? You don't need it. Look at the crash module I have. It has a thread and I committed an extra wakeup() inside of exit1() for kthread's a while ago to handle just this case. Here's an excerpt from the crash module code: In the kthread's main loop (it usually gets events via a sysctl from userland): static void crash_thread(void *arg) { int ev; while (1) { mtx_lock(&event_mtx); while ((ev = event) == 0) cv_wait(&event_cv, &event_mtx); event = 0; mtx_unlock(&event_mtx); ... switch (ev) { case -1: mtx_lock(&Giant); kthread_exit(0); break; ... } } } Here's the unload() function that the module calls for MOD_UNLOAD: static int unload(void *arg) { mtx_lock(&event_mtx); event = -1; cv_signal(&event_cv); msleep(kthread, &event_mtx, PWAIT, "crshun", 0); mtx_unlock(&event_mtx); mtx_destroy(&event_mtx); cv_destroy(&event_cv); ... return (0); } The actual wakeup in exit1 is from: revision 1.129 date: 2001/06/27 06:15:44; author: jhb; state: Exp; lines: +13 -16 ... - When a kthread exits, do a wakeup() on its proc pointers. This can be used by kernel modules that have kthreads and want to ensure they have safely exited before completely the MOD_UNLOAD event. and is at: /* * If this is a kthread, then wakeup anyone waiting for it to exit. */ if (p->p_flag & P_KTHREAD) wakeup(p); PROC_UNLOCK(p); The trick is to avoid missing the wakeup. The way I do it above is to make sure and sleep on the kthread address before and drop event_mtx at the same time so that I am asleep before the kthread gets to run. Since the wakeup() is under the proc lock another valid way that might be easier to accomplish for some kthreads would be something like this: static int unload(void *arg) { mtx_lock(&event_mtx); event = -1; cv_signal(&event_mtx); PROC_LOCK(kthread); mtx_unlock(&event_mtx); msleep(kthread, &kthread->p_mtx, PWAIT | PDROP, "crshun", 0); ... } Well, except that you need to use PDROP in that case since a kthread might have already been harvested by init() and not have a proc mutex around any longer to release when you get woken up. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 26 18: 3:18 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 1C5BD37B410 for ; Thu, 26 Sep 2002 18:03:13 -0700 (PDT) Received: from mx1.FreeBSD.org (mke-24-209-122-123.wi.rr.com [24.209.122.123]) by mx1.FreeBSD.org (Postfix) with SMTP id 231AF43E97 for ; Thu, 26 Sep 2002 18:03:11 -0700 (PDT) (envelope-from nharlan@wi.rr.com) From: "nharlan" Date: Thu, 26 Sep 2002 20:15:30 To: freebsd-arch@FreeBSD.org Subject: $60,000,000 IN 6 MONTHS! VERIFIABLE! CHEAT-PROOF! MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20020927010311.231AF43E97@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 MY PERSONAL GOAL IS TO MAKE CERTAIN THAT YOU RECEIVE $60,000,000 IN 6 MONTHS OR LESS! FACT #1 Those who "get in" on a proven successful program at it's "birth" are guaranteed success! FACT #2 THE UP WAS JUST BORN! YOU ARE AT YOUR DREAM LOCATION! THIS IT "IT"! * JUST LAUNCHED! *YOU CANNOT LOSE! *WE WON'T LET YOU! *OUR GOAL IS TO GET YOU $60,000,000 IN 6 MONTHS OR LESS! *JOIN A "FRATERNITY OF HELPERS" WHO WILL HELP YOU SUCCEED! *"THE ULITMATE PROGRAM" (UP) IS THE BEST PROGRAM IN EXISTENCE! *THE LAST PROGRAM YOU WILL EVER JOIN! STOP playing around with programs that possibly get you $20,000 or $40,000. We will help YOU get $60,000,000 IN 6 MONTHS OR LESS! The UP out-performs any other program because it's self-regulated. 100% Cheatproof and Verifiable. YOU VERIFY EACH MEMBER IS "REAL" BEFORE YOU JOIN! Thereby eliminating ALL guesswork! SIMPLE TO DO + YOU ARE NEVER ALONE! "FRATERNITY OF HELPERS" helping EACH OTHER SUCCEED! "Your success is Our Success"! Get your FREE copy ot THE "UP"! Request THE UP by email, with 'SEND UP" in the Subject LIne to: nharlan@wi.rr.com OR Go to the Official UP Site for more information at: http://www.theultimateprogram.com/default.asp?up=2054 My goal is for you to receive: $60,000,000 IN 6 MONTHS OR LESS! WE CAN DO THIS! When YOU SUCCEED, I SUCCEED, AND WE ALL WIN! JOIN THE UP TODAY before the Members List fills up! Sincerely, Nancy Harlan UP Member nharlan@wi.rr.com ******************************************************************** GO TO THE OFFICIAL SITE: http://www.theultimateprogram.com/default.asp?up=2054 ANY QUESTIONS, ANYTIME! nharlan@wi.rr.com ******************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 27 6: 0: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 5A49237B401; Fri, 27 Sep 2002 06:00:13 -0700 (PDT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A04443E6E; Fri, 27 Sep 2002 06:00:12 -0700 (PDT) (envelope-from mark@grimreaper.grondar.org) Received: from storm.FreeBSD.org.uk (uucp@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.5/8.12.5) with ESMTP id g8RD0BLn000526; Fri, 27 Sep 2002 14:00:11 +0100 (BST) (envelope-from mark@grimreaper.grondar.org) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.12.5/8.12.5/Submit) with UUCP id g8RD0BDa000525; Fri, 27 Sep 2002 14:00:11 +0100 (BST) Received: from grimreaper.grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.6/8.12.5) with ESMTP id g8RCvmwf032794; Fri, 27 Sep 2002 13:57:48 +0100 (BST) (envelope-from mark@grimreaper.grondar.org) Message-Id: <200209271257.g8RCvmwf032794@grimreaper.grondar.org> To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: [patch] module-with-thread exit routine. References: In-Reply-To: ; from John Baldwin "Thu, 26 Sep 2002 11:08:43 EDT." Date: Fri, 27 Sep 2002 13:57:48 +0100 From: Mark Murray 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 > > Attached is a patch to the kthread code. I've been running this > > for at least three months. > > > > Comments? > > You don't need it. Look at the crash module I have. It has a thread > and I committed an extra wakeup() inside of exit1() for kthread's a > while ago to handle just this case. Here's an excerpt from the crash > module code: This looks good. But I have some questions: > In the kthread's main loop (it usually gets events via a sysctl from > userland): > > static void > crash_thread(void *arg) > { > int ev; > > while (1) { > mtx_lock(&event_mtx); > while ((ev = event) == 0) > cv_wait(&event_cv, &event_mtx); > event = 0; > mtx_unlock(&event_mtx); What is the cv_wait for? For the random_kthread, can I just ignore it? > ... > switch (ev) { > case -1: > mtx_lock(&Giant); > kthread_exit(0); > break; > ... > } This looks like I can just call kthread_exit() directly with no shenanigans. Am I on the right track? > Here's the unload() function that the module calls for MOD_UNLOAD: > > static int > unload(void *arg) > { > > mtx_lock(&event_mtx); > event = -1; > cv_signal(&event_cv); > msleep(kthread, &event_mtx, PWAIT, "crshun", 0); > mtx_unlock(&event_mtx); > mtx_destroy(&event_mtx); > cv_destroy(&event_cv); I'm not sure of the event_cv relevance. Can I not just set the event (or equivalent) variable and wait for event_mtx to become available? > revision 1.129 > date: 2001/06/27 06:15:44; author: jhb; state: Exp; lines: +13 -16 > ... > - When a kthread exits, do a wakeup() on its proc pointers. This can be > used by kernel modules that have kthreads and want to ensure they have > safely exited before completely the MOD_UNLOAD event. This looks like its useful to me! :-) M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 27 8:35:53 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 A1E3637B404 for ; Fri, 27 Sep 2002 08:35:49 -0700 (PDT) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36DBF43E65 for ; Fri, 27 Sep 2002 08:35:49 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2446 invoked from network); 27 Sep 2002 15:35:48 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Sep 2002 15:35:48 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g8RFZkBv095315; Fri, 27 Sep 2002 11:35:47 -0400 (EDT) (envelope-from jhb@FreeBSD.org) 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: <200209271257.g8RCvmwf032794@grimreaper.grondar.org> Date: Fri, 27 Sep 2002 11:35:49 -0400 (EDT) From: John Baldwin To: Mark Murray Subject: Re: [patch] module-with-thread exit routine. Cc: 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 27-Sep-2002 Mark Murray wrote: >> > Attached is a patch to the kthread code. I've been running this >> > for at least three months. >> > >> > Comments? >> >> You don't need it. Look at the crash module I have. It has a thread >> and I committed an extra wakeup() inside of exit1() for kthread's a >> while ago to handle just this case. Here's an excerpt from the crash >> module code: > > This looks good. But I have some questions: > >> In the kthread's main loop (it usually gets events via a sysctl from >> userland): >> >> static void >> crash_thread(void *arg) >> { >> int ev; >> >> while (1) { >> mtx_lock(&event_mtx); >> while ((ev = event) == 0) >> cv_wait(&event_cv, &event_mtx); >> event = 0; >> mtx_unlock(&event_mtx); > > What is the cv_wait for? For the random_kthread, can I just ignore it? Well, the way this module works is it has a kthread that executes events that are signaled to them via the 'event' variable. The user can use a sysctl to write a value that gets put in 'event' and then the sysctl handler does a 'cv_signal'. The unload() function is similar. Basically, MOD_UNLOAD needs to poke the thread somehow to tell it to commit suicide. For the crash module, I use a special value of the 'event' variable. >> ... >> switch (ev) { >> case -1: >> mtx_lock(&Giant); >> kthread_exit(0); >> break; >> ... >> } > > This looks like I can just call kthread_exit() directly with no shenanigans. > Am I on the right track? > >> Here's the unload() function that the module calls for MOD_UNLOAD: >> >> static int >> unload(void *arg) >> { >> >> mtx_lock(&event_mtx); >> event = -1; >> cv_signal(&event_cv); >> msleep(kthread, &event_mtx, PWAIT, "crshun", 0); >> mtx_unlock(&event_mtx); >> mtx_destroy(&event_mtx); >> cv_destroy(&event_cv); > > I'm not sure of the event_cv relevance. Can I not just set the event (or > equivalent) variable and wait for event_mtx to become available? Think of the cv as a wakeup to the kthread to tell it to go examine 'event' and see that it needs to die. The trick here is you need to make sure you don't miss the wakeup. Thus, you need to atomically signal the thread to die and then block waiting for it to die. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 27 9:30:14 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 209BF37B404; Fri, 27 Sep 2002 09:30:14 -0700 (PDT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ACDD43E6E; Fri, 27 Sep 2002 09:30:13 -0700 (PDT) (envelope-from mark@grimreaper.grondar.org) Received: from storm.FreeBSD.org.uk (uucp@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.5/8.12.5) with ESMTP id g8RGUCB0002563; Fri, 27 Sep 2002 17:30:12 +0100 (BST) (envelope-from mark@grimreaper.grondar.org) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.12.5/8.12.5/Submit) with UUCP id g8RGUCJD002562; Fri, 27 Sep 2002 17:30:12 +0100 (BST) Received: from grimreaper.grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.6/8.12.5) with ESMTP id g8RGT0wf051750; Fri, 27 Sep 2002 17:29:00 +0100 (BST) (envelope-from mark@grimreaper.grondar.org) Message-Id: <200209271629.g8RGT0wf051750@grimreaper.grondar.org> To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: [patch] module-with-thread exit routine. References: In-Reply-To: ; from John Baldwin "Fri, 27 Sep 2002 11:35:49 EDT." Date: Fri, 27 Sep 2002 17:29:00 +0100 From: Mark Murray 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 > Think of the cv as a wakeup to the kthread to tell it to go examine > 'event' and see that it needs to die. The trick here is you need to > make sure you don't miss the wakeup. Thus, you need to atomically > signal the thread to die and then block waiting for it to die. Aaaaah! That makes sense. Thanks! M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 27 16: 6:41 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 47C6F37B401; Fri, 27 Sep 2002 16:06:40 -0700 (PDT) Received: from postman.medtronic.com (postman.medtronic.COM [144.15.157.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5223043E6A; Fri, 27 Sep 2002 16:06:39 -0700 (PDT) (envelope-from ellery.coleman@medtronic.com) Received: from MSPM1BMSGH01.ent.core.medtronic.com (localhost [127.0.0.1]) by postman.medtronic.com (8.10.1/8.10.1) with ESMTP id g8RN6Uw02631; Fri, 27 Sep 2002 18:06:30 -0500 (CDT) Received: from LAXM1BMSGM50.ent.core.medtronic.com ([10.0.20.215]) by MSPM1BMSGH01.ent.core.medtronic.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 27 Sep 2002 18:06:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Memory Allocation Accounting (a conceptual question) Date: Fri, 27 Sep 2002 16:01:37 -0700 Message-ID: <913C3C216F747D4289B2E9151578E9B4390AD9@LAXM1BMSGM50.ent.core.medtronic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Memory Allocation Accounting (a conceptual question) Thread-Index: AcJmedXL4qfsynEaSAOgZEKG/1eybQ== From: "Coleman, Ellery" To: Cc: X-OriginalArrivalTime: 27 Sep 2002 23:06:14.0043 (UTC) FILETIME=[7A1B06B0:01C2667A] 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 Hey guys, Can you reference any articles/FAQ's that deal with the following = questions: 1- Does the modern unix kernel (ie. FreeBSD, solaris, linux) implement = Memory Allocation Accounting (MMA)? In my mind, an MMA system would = keep track of how much memory each process has "checked out" and = returned since it began running. So if a proccess checks out 512MB = throughout it's lifetime, and only returns 256MB before it dies, the = kernel would have a record of this. And there would be some command = line tool which enabled users to access this accounting information. =20 2- If modern kernels do not implement MMA, can this info be retrieved by = sifting through the /proc filesystem? (perhaps i could put together a = system memory allocation map using perl to sift through the /proc data?) 3- If i were able to determine that a process had died without returning = all of it's memory, does the modern unix kernel provide a mechanism that = would allow me to retrieve/recycle this wasted memory? If these are stupid questions, or if there are some elementary kernel = design principles that preclude the MMA functionality as i have = described it, please enlighten me. Many Thanks in advance for any = comments/suggestions. best regards, o-> el To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 27 16:27: 6 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 4DAEB37B401; Fri, 27 Sep 2002 16:27:04 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A901443E65; Fri, 27 Sep 2002 16:27:03 -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 g8RNQvj1026813; Fri, 27 Sep 2002 16:26:57 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g8RNQvRg026812; Fri, 27 Sep 2002 16:26:57 -0700 Date: Fri, 27 Sep 2002 16:26:57 -0700 From: Brooks Davis To: "Coleman, Ellery" Cc: freebsd-questions@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Memory Allocation Accounting (a conceptual question) Message-ID: <20020927162656.A25196@Odin.AC.HMC.Edu> References: <913C3C216F747D4289B2E9151578E9B4390AD9@LAXM1BMSGM50.ent.core.medtronic.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <913C3C216F747D4289B2E9151578E9B4390AD9@LAXM1BMSGM50.ent.core.medtronic.com>; from ellery.coleman@medtronic.com on Fri, Sep 27, 2002 at 04:01:37PM -0700 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 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 27, 2002 at 04:01:37PM -0700, Coleman, Ellery wrote: >=20 > 3- If i were able to determine that a process had died without > returning all of it's memory, does the modern unix kernel provide a > mechanism that would allow me to retrieve/recycle this wasted memory? This can't happen for normal memory. The kernel tracks who has access to a page and allows the page to be reused once on one is accessing it. (It's actually more complicated then that in most modern VMs, but the principle holds.) It's still generally considered poor programming practice to fail to free() things you malloc(), but it's not actually necessicary to do so. Some forms of shared memory such as System V shared memory can persist after everyone is done using them is you don't clean up, but you'd know your were using one of those. -- 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 --x+6KMIRAuhnl3hBn 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 iD8DBQE9lOk/XY6L6fI4GtQRAuE9AKDL5a7dQTT9qZ2EHaJ//TnQ8c4HVwCfVbnI iS35mSYwnxXgzZ+QvGUt3W8= =KWBH -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message