From owner-freebsd-arch@FreeBSD.ORG Sun Sep 12 20:27:30 2004 Return-Path: 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 2E0A616A4CE for ; Sun, 12 Sep 2004 20:27:30 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B01543D48 for ; Sun, 12 Sep 2004 20:27:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8CKPGFS016427; Sun, 12 Sep 2004 14:25:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 12 Sep 2004 14:25:52 -0600 (MDT) Message-Id: <20040912.142552.83283958.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <36513.1094632246@critter.freebsd.dk> References: <36513.1094632246@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 20:27:30 -0000 In message: <36513.1094632246@critter.freebsd.dk> Poul-Henning Kamp writes: : : A brief talk about malloc's 'A' option on that channel raised again the : idea that we should have a variant of abort(2) which takes a reason : which will be logged in the syslog buffers so people can see what is : wrong rather than just get a core dump. : : Given that we are usually pretty stumped when we get to call abort(2) : it needs to work without malloc or anything like it and varargs into : the kernel is not at all in my future. Only in malloc. Everywhere else, people have enough state to cope. Do we really want to have another kernel API just to support malloc failures? : My proposal therefore is a system call something like: : : abort2(const char *why, int nargs, void **args); : : this would terminate the process like abort(2) and in addition produce : a message in the syslog buffer along these lines: : : Aborted $procname pid $pid uid $uid gid $gid. : Aborted $procname pid $pid $why $arg1 $arg2... : : A typical usage would be: : : if (speed > mach1) { : void *msg[2]; : : msg[0] = speed; : msg[1] = mach1; : : abort2("Supersonic speed not supported", 2, msg); : } : : and the output in syslog would be: : : Aborted sophwith pid 23 uid 100 gid 100. : Aborted sophwith pid 23 Supersonic speed not supported 0x4dd 0x3aa : : Is this workable ? : : Anyone want to try their hands at an implementation ? That's really ugly. abort2(const char *fmt, ...) would be a much better user interface. Your interface really sucks from a programming point of view. If the only goal is to have the output in syslog, then use syslog directly on the args. No kernel APIs are needed: void abort2(const char *fmt, ...) { va_list args; syslog(LOG_ERR, "Aborted %s pid %d uid %d gid %d\n", __progname, getpid(), getuid(), getgid()); va_start(ap, fmt); vsyslog(LOG_ERR, fmt, ap); abort(); } The work to build the array is likely of similar complexity to the work needed to build the buffers above. The connection to syslog is more complex, I'll grant, but on the whole 99+% of the potential users of this API would have enough context/state remaining in the program to be able to do so. Wanrer From owner-freebsd-arch@FreeBSD.ORG Sun Sep 12 21:13:59 2004 Return-Path: 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 CA66D16A4CE for ; Sun, 12 Sep 2004 21:13:59 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 346B743D49 for ; Sun, 12 Sep 2004 21:13:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i8CLDtuW061110; Sun, 12 Sep 2004 23:13:55 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 12 Sep 2004 14:25:52 MDT." <20040912.142552.83283958.imp@bsdimp.com> Date: Sun, 12 Sep 2004 23:13:55 +0200 Message-ID: <61109.1095023635@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 21:13:59 -0000 In message <20040912.142552.83283958.imp@bsdimp.com>, "M. Warner Losh" writes: >: Given that we are usually pretty stumped when we get to call abort(2) >: it needs to work without malloc or anything like it and varargs into >: the kernel is not at all in my future. > >Only in malloc. Everywhere else, people have enough state to cope. >Do we really want to have another kernel API just to support malloc >failures? Well, the problem is that practically nothing else works once malloc fails, and people seem to find the lack of visible explanation a problem. syslog() or anything else using varargs is not going to work... -- 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. From owner-freebsd-arch@FreeBSD.ORG Sun Sep 12 21:21:30 2004 Return-Path: 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 5050C16A4CF for ; Sun, 12 Sep 2004 21:21:30 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E890C43D2F for ; Sun, 12 Sep 2004 21:21:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8CLKBFk016830; Sun, 12 Sep 2004 15:20:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 12 Sep 2004 15:20:47 -0600 (MDT) Message-Id: <20040912.152047.16265436.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <61109.1095023635@critter.freebsd.dk> References: <20040912.142552.83283958.imp@bsdimp.com> <61109.1095023635@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 21:21:30 -0000 In message: <61109.1095023635@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040912.142552.83283958.imp@bsdimp.com>, "M. Warner Losh" writes: : : >: Given that we are usually pretty stumped when we get to call abort(2) : >: it needs to work without malloc or anything like it and varargs into : >: the kernel is not at all in my future. : > : >Only in malloc. Everywhere else, people have enough state to cope. : >Do we really want to have another kernel API just to support malloc : >failures? : : Well, the problem is that practically nothing else works once malloc : fails, and people seem to find the lack of visible explanation a : problem. : : syslog() or anything else using varargs is not going to work... Wouldn't it be better to have a more generic 'Put this into dmesg' thing that doesn't require malloc to work? It seems silly to bloat the kernel for only a malloc failure case... Warner From owner-freebsd-arch@FreeBSD.ORG Sun Sep 12 21:25:17 2004 Return-Path: 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 A60E416A4CF for ; Sun, 12 Sep 2004 21:25:17 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 112FD43D41 for ; Sun, 12 Sep 2004 21:25:17 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i8CLPDQC061287; Sun, 12 Sep 2004 23:25:14 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 12 Sep 2004 15:20:47 MDT." <20040912.152047.16265436.imp@bsdimp.com> Date: Sun, 12 Sep 2004 23:25:13 +0200 Message-ID: <61286.1095024313@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 21:25:17 -0000 In message <20040912.152047.16265436.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <61109.1095023635@critter.freebsd.dk> > "Poul-Henning Kamp" writes: >: In message <20040912.142552.83283958.imp@bsdimp.com>, "M. Warner Losh" writes: >: >: >: Given that we are usually pretty stumped when we get to call abort(2) >: >: it needs to work without malloc or anything like it and varargs into >: >: the kernel is not at all in my future. >: > >: >Only in malloc. Everywhere else, people have enough state to cope. >: >Do we really want to have another kernel API just to support malloc >: >failures? >: >: Well, the problem is that practically nothing else works once malloc >: fails, and people seem to find the lack of visible explanation a >: problem. >: >: syslog() or anything else using varargs is not going to work... > >Wouldn't it be better to have a more generic 'Put this into dmesg' >thing that doesn't require malloc to work? It seems silly to bloat >the kernel for only a malloc failure case... That is what I thought I proposed... -- 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. From owner-freebsd-arch@FreeBSD.ORG Sun Sep 12 21:33:30 2004 Return-Path: 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 69DE516A4CE for ; Sun, 12 Sep 2004 21:33:30 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 157D043D2D for ; Sun, 12 Sep 2004 21:33:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8CLWlS3016942; Sun, 12 Sep 2004 15:32:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 12 Sep 2004 15:33:23 -0600 (MDT) Message-Id: <20040912.153323.115746063.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <61286.1095024313@critter.freebsd.dk> References: <20040912.152047.16265436.imp@bsdimp.com> <61286.1095024313@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 21:33:30 -0000 In message: <61286.1095024313@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040912.152047.16265436.imp@bsdimp.com>, "M. Warner Losh" writes: : >In message: <61109.1095023635@critter.freebsd.dk> : > "Poul-Henning Kamp" writes: : >: In message <20040912.142552.83283958.imp@bsdimp.com>, "M. Warner Losh" writes: : >: : >: >: Given that we are usually pretty stumped when we get to call abort(2) : >: >: it needs to work without malloc or anything like it and varargs into : >: >: the kernel is not at all in my future. : >: > : >: >Only in malloc. Everywhere else, people have enough state to cope. : >: >Do we really want to have another kernel API just to support malloc : >: >failures? : >: : >: Well, the problem is that practically nothing else works once malloc : >: fails, and people seem to find the lack of visible explanation a : >: problem. : >: : >: syslog() or anything else using varargs is not going to work... : > : >Wouldn't it be better to have a more generic 'Put this into dmesg' : >thing that doesn't require malloc to work? It seems silly to bloat : >the kernel for only a malloc failure case... : : That is what I thought I proposed... You proposed 'put this into dmesg, with a lot of other stuff and then abort the program.' I was wanting 'put this into dmesg' and nothing else... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 00:09:40 2004 Return-Path: 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 D194816A4CE for ; Mon, 13 Sep 2004 00:09:40 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4BB643D41 for ; Mon, 13 Sep 2004 00:09:40 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i8D09dvA093305; Sun, 12 Sep 2004 17:09:39 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i8D09cup093302; Sun, 12 Sep 2004 17:09:38 -0700 (PDT) (envelope-from dillon) Date: Sun, 12 Sep 2004 17:09:38 -0700 (PDT) From: Matthew Dillon Message-Id: <200409130009.i8D09cup093302@apollo.backplane.com> To: "M. Warner Losh" References: <20040912.152047.16265436.imp@bsdimp.com> <20040912.153323.115746063.imp@bsdimp.com> cc: arch@freebsd.org cc: phk@phk.freebsd.dk Subject: Re: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 00:09:40 -0000 :... :: >: :: >: syslog() or anything else using varargs is not going to work... :: > :: >Wouldn't it be better to have a more generic 'Put this into dmesg' :: >thing that doesn't require malloc to work? It seems silly to bloat :: >the kernel for only a malloc failure case... :: :: That is what I thought I proposed... : :You proposed 'put this into dmesg, with a lot of other stuff and then :abort the program.' I was wanting 'put this into dmesg' and nothing :else... : :Warner I like the idea of an abort2() [though I wish it were named something else] but I see no need for it to be made a system call. It simply would not be appropriate... abort2() does not do anything that couldn't be done in userland (even if malloc is non-operational at the time). A system call would be a hack to avoid having to clean up the related libc functions and/or provide a path through libc to implement the feature (perhaps a special syslogx() call). -Matt Matthew Dillon From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 07:45:32 2004 Return-Path: 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 E205E16A4CE for ; Mon, 13 Sep 2004 07:45:32 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3137F43D46 for ; Mon, 13 Sep 2004 07:45:32 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i8D7jQpC071270; Mon, 13 Sep 2004 09:45:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 12 Sep 2004 15:33:23 MDT." <20040912.153323.115746063.imp@bsdimp.com> Date: Mon, 13 Sep 2004 09:45:26 +0200 Message-ID: <71269.1095061526@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 07:45:33 -0000 In message <20040912.153323.115746063.imp@bsdimp.com>, "M. Warner Losh" writes: >You proposed 'put this into dmesg, with a lot of other stuff and then >abort the program.' I was wanting 'put this into dmesg' and nothing >else... The reason why I don't like that is that it opens us up to a DoS. By having the syscall abort the process we make it a lot harder to spam the kernel. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 16:22:48 2004 Return-Path: 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 E286316A4CE for ; Mon, 13 Sep 2004 16:22:48 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 596DA43D4C for ; Mon, 13 Sep 2004 16:22:48 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8DHMamK007356 for ; Mon, 13 Sep 2004 12:22:36 -0500 Date: Mon, 13 Sep 2004 12:22:36 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: 4.x device failure? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 16:22:49 -0000 Hello, I'm testing out my AoE driver and have a question about how to handle device failure. I have a function, aoedev_down, that fails all outstanding bufs and if the device is currently open, calls disk_invalidate and flags the device for destruction on close. This function is also called on module unload, once per device. The module unload will wait until all devices are closed before returning. The test I'm running is to mount an AoE device and unload the AoE module. The mount persists (while AoE unload waits) and upon umount I get a panic and eventual hang syncing disks. I would have thought that calling disk_invalidate would cause anyone depending on that disk to see it as gone, but that's apparently not so. I never see the close. Surely there's a way to pull a disk out from under those that have it open without a panic? Opinions? Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 17:28:04 2004 Return-Path: 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 3957516A50B for ; Mon, 13 Sep 2004 17:28:04 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA07343D2F for ; Mon, 13 Sep 2004 17:28:03 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8DHT0fc029634; Mon, 13 Sep 2004 11:29:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4145D7E8.9040209@samsco.org> Date: Mon, 13 Sep 2004 11:24:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: 4.x device failure? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 17:28:04 -0000 Sam wrote: > Hello, > > I'm testing out my AoE driver and have a question about > how to handle device failure. I have a function, > aoedev_down, that fails all outstanding bufs and if the > device is currently open, calls disk_invalidate and flags > the device for destruction on close. This function > is also called on module unload, once per device. The > module unload will wait until all devices are closed > before returning. > > The test I'm running is to mount an AoE device and unload > the AoE module. The mount persists (while AoE unload > waits) and upon umount I get a panic and eventual hang > syncing disks. I would have thought that calling > disk_invalidate would cause anyone depending on that > disk to see it as gone, but that's apparently not so. > I never see the close. > > Surely there's a way to pull a disk out from under > those that have it open without a panic? Opinions? > > Cheers, > > Sam > Are you calling disk_destroy()? disk_invalidate() only frees the disk slice objects, it doesn't actually remove the disk object and cdevsw. You also need to manually track opens in your disk driver and only call disk_destroy() once all references are closed. What panic are you getting? Scott From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 18:21:04 2004 Return-Path: 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 D04F616A4CE for ; Mon, 13 Sep 2004 18:21:04 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A19D43D2F for ; Mon, 13 Sep 2004 18:21:02 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8DJKjB0008043; Mon, 13 Sep 2004 14:20:45 -0500 Date: Mon, 13 Sep 2004 14:20:45 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Scott Long In-Reply-To: <4145D7E8.9040209@samsco.org> Message-ID: References: <4145D7E8.9040209@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: 4.x device failure? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 18:21:04 -0000 > Are you calling disk_destroy()? disk_invalidate() only frees > the disk slice objects, it doesn't actually remove the disk > object and cdevsw. You also need to manually track opens in > your disk driver and only call disk_destroy() once all references > are closed. What panic are you getting? > > Scott OK - the panic was due to calling disk_invalidate, which calls dsgone on the disk slice. Later on the filesystem tries to use this null pointer and falls over. Bad me, I guess. Now I don't call disk_invalidate until the device is closed (when disk_destroy is also called). The panic is gone, but now I have a condition I can't recover from. To recap, the AoE device is mounted and I unload the module. The unload procedure fails outstanding bufs for the device and waits for the device to be closed. The close never comes. Umounting the filesystem fails because he tries to open the device, I see it's now gone, and return ENODEV. "Device not configured" What I'm looking for is a way to tell those who have the device open, "this device is gone. Clean up yourselves." kldstat also hangs, presumably because I'm in the middle of the unload procedure. Sam From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 18:42:14 2004 Return-Path: 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 DB62316A4CE for ; Mon, 13 Sep 2004 18:42:14 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75D9443D4C for ; Mon, 13 Sep 2004 18:42:14 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8DJg2qu008185; Mon, 13 Sep 2004 14:42:02 -0500 Date: Mon, 13 Sep 2004 14:42:02 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Scott Long In-Reply-To: Message-ID: References: <4145D7E8.9040209@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: 4.x device failure? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 18:42:15 -0000 > To recap, the AoE device is mounted and I unload the module. > The unload procedure fails outstanding bufs for the device > and waits for the device to be closed. The close never comes. > Umounting the filesystem fails because he tries to open the > device, I see it's now gone, and return ENODEV. "Device not configured" I'm sorry, it's due to the strategy when i fail the buffer with ENXIO (obviously). Failing with EIO displays identical behaviour, just a different error message. Sam From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 18:56:14 2004 Return-Path: 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 D164316A4CE for ; Mon, 13 Sep 2004 18:56:14 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24B1443D3F for ; Mon, 13 Sep 2004 18:56:14 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i8DIuBBf082342; Mon, 13 Sep 2004 20:56:11 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Sam From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 13 Sep 2004 12:22:36 CDT." Date: Mon, 13 Sep 2004 20:56:11 +0200 Message-ID: <82341.1095101771@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-arch@freebsd.org Subject: Re: 4.x device failure? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 18:56:14 -0000 In message , Sam writes: > >Surely there's a way to pull a disk out from under >those that have it open without a panic? Opinions? No, we're not quite there yet. I/O errors from disk devices very often leads to filesystem or buffer cache panics. We're working on it. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 19:12:34 2004 Return-Path: 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 67D9916A4CE for ; Mon, 13 Sep 2004 19:12:34 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 232CF43D49 for ; Mon, 13 Sep 2004 19:12:34 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8DKCHE8008355; Mon, 13 Sep 2004 15:12:17 -0500 Date: Mon, 13 Sep 2004 15:12:17 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Poul-Henning Kamp In-Reply-To: <82341.1095101771@critter.freebsd.dk> Message-ID: References: <82341.1095101771@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: 4.x device failure? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 19:12:34 -0000 Ah. Well that answers it. I'll fail unloading of the module if devices are open. This leads to a curiosity as to how the RAID failover modules work at all. I guess if you abstract the real disk(s) under a logical disk you can change the bottom layer without affecting the top. I'll have to look at that code a little closer. Thanks - Sam On Mon, 13 Sep 2004, Poul-Henning Kamp wrote: > In message , Sam writes: >> > >> Surely there's a way to pull a disk out from under >> those that have it open without a panic? Opinions? > > No, we're not quite there yet. I/O errors from disk devices very > often leads to filesystem or buffer cache panics. We're working > on it. > > -- > 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. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 19:35:54 2004 Return-Path: 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 8634116A4CE for ; Mon, 13 Sep 2004 19:35:54 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B842343D1F for ; Mon, 13 Sep 2004 19:35:53 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i8DJZqui083279; Mon, 13 Sep 2004 21:35:52 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Sam From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 13 Sep 2004 15:12:17 CDT." Date: Mon, 13 Sep 2004 21:35:52 +0200 Message-ID: <83278.1095104152@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-arch@freebsd.org Subject: Re: 4.x device failure? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 19:35:54 -0000 In message , Sam writes: >Ah. Well that answers it. I'll fail unloading of the >module if devices are open. > >This leads to a curiosity as to how the RAID >failover modules work at all. I guess if you abstract >the real disk(s) under a logical disk you can change >the bottom layer without affecting the top. I'll have >to look at that code a little closer. You should really start to study GEOM in 5.x which gives a nice clean framework for all this sort of stuff. You can start here for instance: http://phk.freebsd.dk/pubs/bsdcan-04.slides.geomtut.pdf -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 19:37:18 2004 Return-Path: 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 3A2DA16A4CE for ; Mon, 13 Sep 2004 19:37:18 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94B7043D4C for ; Mon, 13 Sep 2004 19:37:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8DJZrYa030571; Mon, 13 Sep 2004 13:35:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Sep 2004 13:36:35 -0600 (MDT) Message-Id: <20040913.133635.102122423.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <71269.1095061526@critter.freebsd.dk> References: <20040912.153323.115746063.imp@bsdimp.com> <71269.1095061526@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 19:37:18 -0000 In message: <71269.1095061526@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040912.153323.115746063.imp@bsdimp.com>, "M. Warner Losh" writes: : : >You proposed 'put this into dmesg, with a lot of other stuff and then : >abort the program.' I was wanting 'put this into dmesg' and nothing : >else... : : The reason why I don't like that is that it opens us up to a DoS. : By having the syscall abort the process we make it a lot harder to : spam the kernel. That's actually a good reason... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Sep 13 20:33:40 2004 Return-Path: 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 20C1916A4CE for ; Mon, 13 Sep 2004 20:33:40 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57C8243D2F for ; Mon, 13 Sep 2004 20:33:37 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8DKYYMr030651; Mon, 13 Sep 2004 14:34:34 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <41460365.50508@samsco.org> Date: Mon, 13 Sep 2004 14:30:29 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: <82341.1095101771@critter.freebsd.dk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Poul-Henning Kamp cc: freebsd-arch@freebsd.org Subject: Re: 4.x device failure? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 20:33:40 -0000 It's not impossible to remove a disk object from a running system, you just have to be very careful about it. Like I mentioned before, keep a reference count on your disk, and only call disk_destroy() when it has gone to 0 (and prevent new opens while you are waiting to destroy). This isn't great, of course, since you can't destroy a disk with active references, but it's not impossible. Scott Sam wrote: > Ah. Well that answers it. I'll fail unloading of the > module if devices are open. > > This leads to a curiosity as to how the RAID > failover modules work at all. I guess if you abstract > the real disk(s) under a logical disk you can change > the bottom layer without affecting the top. I'll have > to look at that code a little closer. > > Thanks - > > Sam > > On Mon, 13 Sep 2004, Poul-Henning Kamp wrote: > >> In message , Sam writes: >> >>> >> >>> Surely there's a way to pull a disk out from under >>> those that have it open without a panic? Opinions? >> >> >> No, we're not quite there yet. I/O errors from disk devices very >> often leads to filesystem or buffer cache panics. We're working >> on it. >> >> -- >> 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. >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Sep 14 03:18:19 2004 Return-Path: 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 4BF2916A4CE for ; Tue, 14 Sep 2004 03:18:19 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D6D943D60 for ; Tue, 14 Sep 2004 03:18:19 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 2321950BA6 for ; Tue, 14 Sep 2004 12:18:18 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 8C59650B8C for ; Tue, 14 Sep 2004 12:18:16 +0900 (JST) Date: Tue, 14 Sep 2004 12:18:16 +0900 Message-ID: <7macvto7wn.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: arch@FreeBSD.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: stderr is seekable? (lseek(2)) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 03:18:19 -0000 When I tested this program, it finished successfully. But on Linux, lseek(2) returns -1 and errno is ESPIPE. I expected to be returned ESPIPE as Linux did. Is our behavior correct, or there is something wrong? ----- #include #include #include #include int main(int argc, char **argv) { off_t r = lseek(2, 1, SEEK_CUR); printf("r=%d\n", r); if (r == -1) { printf("errno=%d, %s\n", errno, strerror(errno)); } return 0; } ----- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-arch@FreeBSD.ORG Tue Sep 14 03:31:10 2004 Return-Path: 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 8084216A4CE for ; Tue, 14 Sep 2004 03:31:10 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62A2B43D5F for ; Tue, 14 Sep 2004 03:31:10 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 1960A72DF6; Mon, 13 Sep 2004 20:31:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 16F8272DF4; Mon, 13 Sep 2004 20:31:10 -0700 (PDT) Date: Mon, 13 Sep 2004 20:31:10 -0700 (PDT) From: Doug White To: Jun Kuriyama In-Reply-To: <7macvto7wn.wl@black.imgsrc.co.jp> Message-ID: <20040913203044.X34536@carver.gumbysoft.com> References: <7macvto7wn.wl@black.imgsrc.co.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org Subject: Re: stderr is seekable? (lseek(2)) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 03:31:10 -0000 On Tue, 14 Sep 2004, Jun Kuriyama wrote: > > When I tested this program, it finished successfully. But on Linux, > lseek(2) returns -1 and errno is ESPIPE. > > I expected to be returned ESPIPE as Linux did. Is our behavior > correct, or there is something wrong? You might poke -standards about this, someone there probably has a copy of POSIX and can see waht the required behavior is. I'm inclined to call this a "bonus feature" on our part :) > > ----- > #include > #include > #include > #include > > int > main(int argc, char **argv) > { > off_t r = lseek(2, 1, SEEK_CUR); > printf("r=%d\n", r); > if (r == -1) { > printf("errno=%d, %s\n", errno, strerror(errno)); > } > return 0; > } > ----- > > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Sep 14 08:02:43 2004 Return-Path: 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 CE4A016A4CE for ; Tue, 14 Sep 2004 08:02:43 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id E835443D46 for ; Tue, 14 Sep 2004 08:02:42 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i8E82W2438474; Tue, 14 Sep 2004 10:02:36 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i8E82VI114382; Tue, 14 Sep 2004 10:02:31 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i8E82Se01438; Tue, 14 Sep 2004 10:02:30 +0200 (MET DST) Date: Tue, 14 Sep 2004 10:02:35 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Jun Kuriyama In-Reply-To: <7macvto7wn.wl@black.imgsrc.co.jp> Message-ID: <20040914094556.C77243@beagle.kn.op.dlr.de> References: <7macvto7wn.wl@black.imgsrc.co.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: stderr is seekable? (lseek(2)) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 08:02:43 -0000 On Tue, 14 Sep 2004, Jun Kuriyama wrote: JK> JK>When I tested this program, it finished successfully. But on Linux, JK>lseek(2) returns -1 and errno is ESPIPE. JK> JK>I expected to be returned ESPIPE as Linux did. Is our behavior JK>correct, or there is something wrong? Posix requires to return EPIPE when the file is a socket, pipe or fifo. I assume you start the program with stderr connected to tty? This case seems not to be specified, so we are free to return whatever we want (but should probably document it). There is only one place in Posix that talks about seeking and terminals: in the read() man page. But this place does not place any requirement on lseek(), but on pread() with an implied seek (to return an error). harti JK> JK>----- JK>#include JK>#include JK>#include JK>#include JK> JK>int JK>main(int argc, char **argv) JK>{ JK> off_t r = lseek(2, 1, SEEK_CUR); JK> printf("r=%d\n", r); JK> if (r == -1) { JK> printf("errno=%d, %s\n", errno, strerror(errno)); JK> } JK> return 0; JK>} JK>----- JK> JK> JK> From owner-freebsd-arch@FreeBSD.ORG Tue Sep 14 10:39:15 2004 Return-Path: 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 678D416A4CF for ; Tue, 14 Sep 2004 10:39:15 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B92BA43D45 for ; Tue, 14 Sep 2004 10:39:14 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i8EAdD4u021146; Tue, 14 Sep 2004 20:39:13 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) i8EAd979025522; Tue, 14 Sep 2004 20:39:11 +1000 Date: Tue, 14 Sep 2004 20:39:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jun Kuriyama In-Reply-To: <7macvto7wn.wl@black.imgsrc.co.jp> Message-ID: <20040914201045.P33434@delplex.bde.org> References: <7macvto7wn.wl@black.imgsrc.co.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org Subject: Re: stderr is seekable? (lseek(2)) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 10:39:15 -0000 On Tue, 14 Sep 2004, Jun Kuriyama wrote: > > When I tested this program, it finished successfully. But on Linux, > lseek(2) returns -1 and errno is ESPIPE. > > I expected to be returned ESPIPE as Linux did. Is our behavior > correct, or there is something wrong? FreeBSD's behaviour is wrong for at least named pipes. lseek() on named pipes was fixed in rev.1.52 of vfs_syscalls.c, but was broken in rev.1.319 of vfs_syscalls.c and rev.1.123 of sys_generic.c. The DFLAG_SEEKABLE flag added in rev.1.188 of vfs_vnops.c doesn't work, since the fileops table for named pipes is the same as for vnodes. % Index: vfs_syscalls.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v % retrieving revision 1.51 % retrieving revision 1.52 % diff -u -2 -r1.51 -r1.52 % --- vfs_syscalls.c 19 Sep 1996 18:20:27 -0000 1.51 % +++ vfs_syscalls.c 19 Dec 1996 19:41:36 -0000 1.52 % @@ -37,5 +37,5 @@ % * % * @(#)vfs_syscalls.c 8.13 (Berkeley) 4/15/94 % - * $Id: vfs_syscalls.c,v 1.50 1996/09/03 14:21:53 bde Exp $ % + * $Id: vfs_syscalls.c,v 1.51 1996/09/19 18:20:27 nate Exp $ % */ % % @@ -699,7 +699,7 @@ % p->p_dupfd = 0; % vp = nd.ni_vp; % - % + % fp->f_flag = flags & FMASK; % - fp->f_type = DTYPE_VNODE; % + fp->f_type = (vp->v_type == VFIFO ? DTYPE_FIFO : DTYPE_VNODE); % fp->f_ops = &vnops; % fp->f_data = (caddr_t)vp; % @@ -2347,5 +2347,5 @@ % (fp = fdp->fd_ofiles[fd]) == NULL) % return (EBADF); % - if (fp->f_type != DTYPE_VNODE) % + if (fp->f_type != DTYPE_VNODE && fp->f_type != DTYPE_FIFO) % return (EINVAL); % *fpp = fp; % Index: vfs_syscalls.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v % retrieving revision 1.318 % retrieving revision 1.319 % diff -u -2 -r1.318 -r1.319 % --- vfs_syscalls.c 11 Jun 2003 00:56:59 -0000 1.318 % +++ vfs_syscalls.c 18 Jun 2003 19:53:59 -0000 1.319 % @@ -40,5 +40,5 @@ % % #include % -__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.318 2003/06/11 00:56:59 obrien Exp $"); % +__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.319 2003/06/18 19:53:59 phk Exp $"); % % /* For 4.3 integer FS ID compatibility */ % @@ -1342,5 +1342,5 @@ % if ((error = fget(td, uap->fd, &fp)) != 0) % return (error); % - if (fp->f_type != DTYPE_VNODE) { % + if (!(fp->f_ops->fo_flags & DFLAG_SEEKABLE)) { % fdrop(fp, td); % return (ESPIPE); % Index: vfs_vnops.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/vfs_vnops.c,v % retrieving revision 1.187 % retrieving revision 1.188 % diff -u -2 -r1.187 -r1.188 % --- vfs_vnops.c 18 Jun 2003 18:16:39 -0000 1.187 % +++ vfs_vnops.c 18 Jun 2003 19:53:59 -0000 1.188 % @@ -40,5 +40,5 @@ % % #include % -__FBSDID("$FreeBSD: src/sys/kern/vfs_vnops.c,v 1.187 2003/06/18 18:16:39 phk Exp $"); % +__FBSDID("$FreeBSD: src/sys/kern/vfs_vnops.c,v 1.188 2003/06/18 19:53:59 phk Exp $"); % % #include "opt_mac.h" % @@ -81,5 +81,5 @@ % .fo_stat = vn_statfile, % .fo_close = vn_closefile, % - .fo_flags = DFLAG_PASSABLE % + .fo_flags = DFLAG_PASSABLE | DFLAG_SEEKABLE % }; % % Index: sys_generic.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/sys_generic.c,v % retrieving revision 1.122 % retrieving revision 1.123 % diff -u -2 -r1.122 -r1.123 % --- sys_generic.c 11 Jun 2003 00:56:57 -0000 1.122 % +++ sys_generic.c 18 Jun 2003 19:53:59 -0000 1.123 % @@ -40,5 +40,5 @@ % % #include % -__FBSDID("$FreeBSD: src/sys/kern/sys_generic.c,v 1.122 2003/06/11 00:56:57 obrien Exp $"); % +__FBSDID("$FreeBSD: src/sys/kern/sys_generic.c,v 1.123 2003/06/18 19:53:59 phk Exp $"); % % #include "opt_ktrace.h" % @@ -138,5 +138,5 @@ % if ((error = fget_read(td, uap->fd, &fp)) != 0) % return (error); % - if (fp->f_type != DTYPE_VNODE) { % + if (!(fp->f_ops->fo_flags & DFLAG_SEEKABLE)) { % error = ESPIPE; % } else { % @@ -361,9 +361,9 @@ % % if ((error = fget_write(td, uap->fd, &fp)) == 0) { % - if (fp->f_type == DTYPE_VNODE) { % + if (!(fp->f_ops->fo_flags & DFLAG_SEEKABLE)) { % + error = ESPIPE; % + } else { % error = dofilewrite(td, fp, uap->fd, uap->buf, % uap->nbyte, uap->offset, FOF_OFFSET); % - } else { % - error = ESPIPE; % } % fdrop(fp, td); % Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Sep 16 18:42:04 2004 Return-Path: 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 CAA6716A4CE for ; Thu, 16 Sep 2004 18:42:04 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 754F443D2D for ; Thu, 16 Sep 2004 18:42:04 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id E353BACAFB; Thu, 16 Sep 2004 20:42:01 +0200 (CEST) Date: Thu, 16 Sep 2004 20:42:01 +0200 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Message-ID: <20040916184201.GD30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QTrnGtbQvXh53f+1" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Subject: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 18:42:04 -0000 --QTrnGtbQvXh53f+1 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. I implemented parse_capacity() function which can be use to convert a string with a human-readable capacity value to a off_t value. It can be used by utilities like: % truncate -s 8g test # mdconfig -a -t malloc -s 16M Patch can be found here: http://people.freebsd.org/~pjd/patches/parse_capacity.patch Any comments before committing? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --QTrnGtbQvXh53f+1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBSd55ForvXbEpPzQRArAoAKDQPCnb9bRNDIPFGOgWOsA3Ni8RoQCg6TQr iJUhLyLnIGGuvKnjxU+/75I= =+ATK -----END PGP SIGNATURE----- --QTrnGtbQvXh53f+1-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 16 22:51:39 2004 Return-Path: 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 9768016A4CF for ; Thu, 16 Sep 2004 22:51:39 +0000 (GMT) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B95043D5A for ; Thu, 16 Sep 2004 22:51:38 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 19531 invoked by uid 207); 16 Sep 2004 22:51:37 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.81):. Processed in 0.843526 secs); 16 Sep 2004 22:51:37 -0000 Received: from dialup81.ach.sch.gr (HELO gothmog.gr) ([81.186.70.81]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Sep 2004 22:51:36 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i8GMnTfM055867; Fri, 17 Sep 2004 01:49:29 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i8GMnTNr055866; Fri, 17 Sep 2004 01:49:29 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Fri, 17 Sep 2004 01:49:29 +0300 From: Giorgos Keramidas To: Pawel Jakub Dawidek Message-ID: <20040916224929.GA50482@gothmog.gr> References: <20040916184201.GD30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <20040916184201.GD30151@darkness.comp.waw.pl> Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 22:51:39 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2004-09-16 20:42, Pawel Jakub Dawidek wrote: > http://people.freebsd.org/~pjd/patches/parse_capacity.patch > Any comments before committing? Is it intentional that it works even for "negative" capacities? : $ ./foo : -10 fffffffffffffff6 | -10 fffffffffffffff6 : -10240 ffffffffffffd800 | -10k ffffffffffffd800 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="foo.c" #include #include struct data { off_t d_off; const char *d_str; }; static struct data v[] = { { -10, "-10" }, { -10 * 1024, "-10k" }, }; static const size_t vlen = sizeof(v) / sizeof(v[0]); extern off_t parse_capacity(const char *capacity); static void foo(const struct data *); static void foo(const struct data *dp) { off_t val; val = parse_capacity(dp->d_str); printf("%10lld %016llx | %10s %016llx\n", dp->d_off, dp->d_off, dp->d_str, (unsigned long long)val); } int main(void) { size_t k; for (k = 0; k < vlen; k++) foo(v + k); return 0; } --vtzGhvizbBRQ85DL-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 16 23:03:28 2004 Return-Path: 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 AC82216A4CE; Thu, 16 Sep 2004 23:03:28 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45A2743D48; Thu, 16 Sep 2004 23:03:28 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id AFBD9AC995; Fri, 17 Sep 2004 01:03:25 +0200 (CEST) Date: Fri, 17 Sep 2004 01:03:25 +0200 From: Pawel Jakub Dawidek To: Giorgos Keramidas Message-ID: <20040916230325.GJ30151@darkness.comp.waw.pl> References: <20040916184201.GD30151@darkness.comp.waw.pl> <20040916224929.GA50482@gothmog.gr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAyj+rJ4YBxgwLMg" Content-Disposition: inline In-Reply-To: <20040916224929.GA50482@gothmog.gr> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 23:03:28 -0000 --uAyj+rJ4YBxgwLMg Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 17, 2004 at 01:49:29AM +0300, Giorgos Keramidas wrote: +> On 2004-09-16 20:42, Pawel Jakub Dawidek wrote: +> > http://people.freebsd.org/~pjd/patches/parse_capacity.patch +> > Any comments before committing? +>=20 +> Is it intentional that it works even for "negative" capacities? Actually I wasn't sure if I should permit for this or deny it. I decided to allow for negative values, because application still have to check the return value, so instead of '=3D=3D 0', '<=3D 0' can be used to detect an error. Simlar problem was for humanize_number(3) - it should support negative values, because avaliable size on file system could be less than 0. With parse_capacity(3) it is a big harder to imagine, but we can add support in the future to growfs(8) to shrink file system when negative value is given or something like this... :) --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --uAyj+rJ4YBxgwLMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBShu9ForvXbEpPzQRAousAKCSU2rhdHDlPpaGK2EgaX/2guLMbACfaLXe lAm1UdcnEx1Lx1RP7ctmLsg= =TIuk -----END PGP SIGNATURE----- --uAyj+rJ4YBxgwLMg-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 01:11:18 2004 Return-Path: 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 D87F816A4CE; Fri, 17 Sep 2004 01:11:18 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7864043D4C; Fri, 17 Sep 2004 01:11:18 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i8H1BHrK006754; Thu, 16 Sep 2004 20:11:17 -0500 (CDT) (envelope-from dan) Date: Thu, 16 Sep 2004 20:11:17 -0500 From: Dan Nelson To: Giorgos Keramidas Message-ID: <20040917011116.GG29528@dan.emsphone.com> References: <20040916184201.GD30151@darkness.comp.waw.pl> <20040916224929.GA50482@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916224929.GA50482@gothmog.gr> X-OS: FreeBSD 5.3-BETA3 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: Pawel Jakub Dawidek cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 01:11:19 -0000 In the last episode (Sep 17), Giorgos Keramidas said: > On 2004-09-16 20:42, Pawel Jakub Dawidek wrote: > > http://people.freebsd.org/~pjd/patches/parse_capacity.patch > > Any comments before committing? > > Is it intentional that it works even for "negative" capacities? > > : $ ./foo > : -10 fffffffffffffff6 | -10 fffffffffffffff6 > : -10240 ffffffffffffd800 | -10k ffffffffffffd800 I'd call that a feature. Imagine a "resizefs" command, where you would enter a positive number to grow, and a negative one to shrink. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 04:02:02 2004 Return-Path: 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 CA34016A4CE; Fri, 17 Sep 2004 04:02:02 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2105D43D41; Fri, 17 Sep 2004 04:02:02 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.34) id 1C8ADw-0000aL-FF; Fri, 17 Sep 2004 11:19:52 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i8H44j0m054756; Fri, 17 Sep 2004 11:04:45 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i8H44joH054717; Fri, 17 Sep 2004 11:04:45 +0700 (NOVST) (envelope-from danfe) Date: Fri, 17 Sep 2004 11:04:45 +0700 From: Alexey Dokuchaev To: Pawel Jakub Dawidek Message-ID: <20040917040445.GA52078@regency.nsu.ru> References: <20040916184201.GD30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916184201.GD30151@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2.1i cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 04:02:02 -0000 On Thu, Sep 16, 2004 at 08:42:01PM +0200, Pawel Jakub Dawidek wrote: > Hello. > > I implemented parse_capacity() function which can be use to convert a > string with a human-readable capacity value to a off_t value. > > It can be used by utilities like: > > % truncate -s 8g test > # mdconfig -a -t malloc -s 16M > > Patch can be found here: > > http://people.freebsd.org/~pjd/patches/parse_capacity.patch > > Any comments before committing? Methinks you could probably come up with a better name, since "engeneering number mode" (using K, M, T, etc) is used for bandwidth, for instance, not just for `capacity'. IMHO. Making it that user can easily guess its name from already-there humanize_number(3). ./danfe From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 04:11:41 2004 Return-Path: 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 6F5B816A4CF; Fri, 17 Sep 2004 04:11:41 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0970943D45; Fri, 17 Sep 2004 04:11:41 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i8H4Bece087879; Thu, 16 Sep 2004 23:11:40 -0500 (CDT) (envelope-from dan) Date: Thu, 16 Sep 2004 23:11:40 -0500 From: Dan Nelson To: Alexey Dokuchaev Message-ID: <20040917041139.GB52634@dan.emsphone.com> References: <20040916184201.GD30151@darkness.comp.waw.pl> <20040917040445.GA52078@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040917040445.GA52078@regency.nsu.ru> X-OS: FreeBSD 5.3-BETA3 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: Pawel Jakub Dawidek cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 04:11:41 -0000 In the last episode (Sep 17), Alexey Dokuchaev said: > Methinks you could probably come up with a better name, since > "engeneering number mode" (using K, M, T, etc) is used for bandwidth, > for instance, not just for `capacity'. IMHO. Making it that user > can easily guess its name from already-there humanize_number(3). dehumanize_number? :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 08:14:19 2004 Return-Path: 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 F29CB16A4CE for ; Fri, 17 Sep 2004 08:14:18 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86BF143D53 for ; Fri, 17 Sep 2004 08:14:18 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id B787EACAE0; Fri, 17 Sep 2004 10:14:16 +0200 (CEST) Date: Fri, 17 Sep 2004 10:14:16 +0200 From: Pawel Jakub Dawidek To: Alexey Dokuchaev Message-ID: <20040917081416.GL30151@darkness.comp.waw.pl> References: <20040916184201.GD30151@darkness.comp.waw.pl> <20040917040445.GA52078@regency.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gRtU5zt8zDjMv0mc" Content-Disposition: inline In-Reply-To: <20040917040445.GA52078@regency.nsu.ru> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 08:14:19 -0000 --gRtU5zt8zDjMv0mc Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 17, 2004 at 11:04:45AM +0700, Alexey Dokuchaev wrote: +> > I implemented parse_capacity() function which can be use to convert a +> > string with a human-readable capacity value to a off_t value. +> >=20 +> > It can be used by utilities like: +> >=20 +> > % truncate -s 8g test +> > # mdconfig -a -t malloc -s 16M +> >=20 +> > Patch can be found here: +> >=20 +> > http://people.freebsd.org/~pjd/patches/parse_capacity.patch +> >=20 +> > Any comments before committing? +>=20 +> Methinks you could probably come up with a better name, since +> "engeneering number mode" (using K, M, T, etc) is used for bandwidth, +> for instance, not just for `capacity'. IMHO. Making it that user can +> easily guess its name from already-there humanize_number(3). Fell free to suggest a better one:) I talked about this name with few people before name was choosen and this is the list of proposals: - dehumanize_number(), - read_humanized_number(), - parse_humanized_humber(), - computerize_number(), - digitalize_number(), - obfuscate_number(), - parse_capacity(), - parse_number(). :) I really don't want to start bikeshed about function name here. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --gRtU5zt8zDjMv0mc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBSpzYForvXbEpPzQRAjIyAKCBJL/3Ijji5EF+cnE+JocgHF1XAQCg2Au2 Btgo93906PU22Yh9nMLWp6Q= =55fO -----END PGP SIGNATURE----- --gRtU5zt8zDjMv0mc-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 08:39:05 2004 Return-Path: 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 5B50D16A4D0; Fri, 17 Sep 2004 08:39:05 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98C2F43D45; Fri, 17 Sep 2004 08:39:04 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.34) id 1C8EY2-0007OF-FQ; Fri, 17 Sep 2004 15:56:54 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i8H8fl0m047945; Fri, 17 Sep 2004 15:41:47 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i8H8flQp047886; Fri, 17 Sep 2004 15:41:47 +0700 (NOVST) (envelope-from danfe) Date: Fri, 17 Sep 2004 15:41:46 +0700 From: Alexey Dokuchaev To: Pawel Jakub Dawidek Message-ID: <20040917084146.GA45371@regency.nsu.ru> References: <20040916184201.GD30151@darkness.comp.waw.pl> <20040917040445.GA52078@regency.nsu.ru> <20040917081416.GL30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040917081416.GL30151@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2.1i cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 08:39:05 -0000 On Fri, Sep 17, 2004 at 10:14:16AM +0200, Pawel Jakub Dawidek wrote: > On Fri, Sep 17, 2004 at 11:04:45AM +0700, Alexey Dokuchaev wrote: > +> > I implemented parse_capacity() function which can be use to convert a > +> > string with a human-readable capacity value to a off_t value. > +> > > +> > It can be used by utilities like: > +> > > +> > % truncate -s 8g test > +> > # mdconfig -a -t malloc -s 16M > +> > > +> > Patch can be found here: > +> > > +> > http://people.freebsd.org/~pjd/patches/parse_capacity.patch > +> > > +> > Any comments before committing? > +> > +> Methinks you could probably come up with a better name, since > +> "engeneering number mode" (using K, M, T, etc) is used for bandwidth, > +> for instance, not just for `capacity'. IMHO. Making it that user can > +> easily guess its name from already-there humanize_number(3). > > Fell free to suggest a better one:) > I talked about this name with few people before name was choosen and > this is the list of proposals: > > - dehumanize_number(), This one is good. > - parse_humanized_humber(), And this one. > > :) > I really don't want to start bikeshed about function name here. Neither do I. I just wanted to point out that `capacity' probably isn't the best choice. ./danfe From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 13:17:34 2004 Return-Path: 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 0015E16A4CE for ; Fri, 17 Sep 2004 13:17:33 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56E3043D1D for ; Fri, 17 Sep 2004 13:17:33 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id CDD21ACAF1; Fri, 17 Sep 2004 15:17:26 +0200 (CEST) Date: Fri, 17 Sep 2004 15:17:26 +0200 From: Pawel Jakub Dawidek To: Alexey Dokuchaev Message-ID: <20040917131726.GR30151@darkness.comp.waw.pl> References: <20040916184201.GD30151@darkness.comp.waw.pl> <20040917040445.GA52078@regency.nsu.ru> <20040917081416.GL30151@darkness.comp.waw.pl> <20040917084146.GA45371@regency.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E+d41Xxi+aYmIyHQ" Content-Disposition: inline In-Reply-To: <20040917084146.GA45371@regency.nsu.ru> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 13:17:34 -0000 --E+d41Xxi+aYmIyHQ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 17, 2004 at 03:41:46PM +0700, Alexey Dokuchaev wrote: +> > Fell free to suggest a better one:) +> > I talked about this name with few people before name was choosen and +> > this is the list of proposals: +> >=20 +> > - dehumanize_number(), +>=20 +> This one is good. Ok! I'm going with this one. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --E+d41Xxi+aYmIyHQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBSuPmForvXbEpPzQRAgXYAKC3N3lXpanlB0ex0CuLKkHNOJIxuACeNMke 2Ygk2K37ErMmnA/7tJ4cofc= =4Pkm -----END PGP SIGNATURE----- --E+d41Xxi+aYmIyHQ-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 16:34:16 2004 Return-Path: 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 CA5F716A4CE for ; Fri, 17 Sep 2004 16:34:16 +0000 (GMT) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9010F43D31 for ; Fri, 17 Sep 2004 16:34:16 +0000 (GMT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.12.8p2/8.12.8) with ESMTP id i8HGYFn2027923 for ; Fri, 17 Sep 2004 10:34:15 -0600 (MDT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6p3/8.12.6) with ESMTP id i8HGYFhC066660 for ; Fri, 17 Sep 2004 10:34:15 -0600 (MDT) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6p3/8.12.6/Submit) id i8HGYBAh066657; Fri, 17 Sep 2004 10:34:11 -0600 (MDT) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16715.4611.108597.354107@piglet.timing.com> Date: Fri, 17 Sep 2004 10:34:11 -0600 To: freebsd-arch@freebsd.org X-Mailer: VM 7.00 under Emacs 21.2.95.2 X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a on Daffy.timing.com X-Virus-Status: Clean Subject: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 16:34:16 -0000 Hi, I've recently done a port of OpenBSD diff(1) to FreeBSD for licensing reasons (the diff(1) in base FreeBSD is GPL licensed), OpenBSD has a BSD-style license). I was going to work with Warner to see if I could get this into the ports collection. But we were also curious to see if other people thought it might be OK to replace the GNU diff in base with the OpenBSD diff. For reference, here is the OpenBSD diff source and manpage: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/diff/ There would also have to be some integration with other programs (such as diff3(1)). Regards, Ben Mesander From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 19:05:17 2004 Return-Path: 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 0697E16A4CE for ; Fri, 17 Sep 2004 19:05:17 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 992D643D49 for ; Fri, 17 Sep 2004 19:05:16 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8HJ4wBM020015; Fri, 17 Sep 2004 13:04:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Sep 2004 13:05:49 -0600 (MDT) Message-Id: <20040917.130549.22012205.imp@bsdimp.com> To: ben@timing.com From: "M. Warner Losh" In-Reply-To: <16715.4611.108597.354107@piglet.timing.com> References: <16715.4611.108597.354107@piglet.timing.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 19:05:17 -0000 In message: <16715.4611.108597.354107@piglet.timing.com> Ben Mesander writes: : I've recently done a port of OpenBSD diff(1) to FreeBSD for : licensing reasons (the diff(1) in base FreeBSD is GPL licensed), : OpenBSD has a BSD-style license). : : I was going to work with Warner to see if I could get this into : the ports collection. But we were also curious to see if other : people thought it might be OK to replace the GNU diff in base : with the OpenBSD diff. : : For reference, here is the OpenBSD diff source and manpage: : http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/diff/ : : There would also have to be some integration with other programs : (such as diff3(1)). Needless to say, I think this is an excellent idea. I'm happy to do the leg work to get this into the tree, so that's not an issue. :-) OpenBSD's diff is much smaller than gnu's. It seems to use less memory as well for many operations. Its speed seems about the same. Most of these impressions are based on light testing, so YMMV. This would be in keeping with our march to get rid of other gnu products in our tree: awk, sort, etc. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 19:12:49 2004 Return-Path: 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 4306516A4CE for ; Fri, 17 Sep 2004 19:12:49 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A227C43D41 for ; Fri, 17 Sep 2004 19:12:48 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8HJCiSX072900; Fri, 17 Sep 2004 15:12:45 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8HJCfVJ072899; Fri, 17 Sep 2004 15:12:41 -0400 (EDT) (envelope-from green) Date: Fri, 17 Sep 2004 15:12:40 -0400 From: Brian Fundakowski Feldman To: "M. Warner Losh" Message-ID: <20040917191240.GR36708@green.homeunix.org> References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040917.130549.22012205.imp@bsdimp.com> User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 19:12:49 -0000 On Fri, Sep 17, 2004 at 01:05:49PM -0600, M. Warner Losh wrote: > In message: <16715.4611.108597.354107@piglet.timing.com> > Ben Mesander writes: > : I've recently done a port of OpenBSD diff(1) to FreeBSD for > : licensing reasons (the diff(1) in base FreeBSD is GPL licensed), > : OpenBSD has a BSD-style license). > : > : I was going to work with Warner to see if I could get this into > : the ports collection. But we were also curious to see if other > : people thought it might be OK to replace the GNU diff in base > : with the OpenBSD diff. > : > : For reference, here is the OpenBSD diff source and manpage: > : http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/diff/ > : > : There would also have to be some integration with other programs > : (such as diff3(1)). > > Needless to say, I think this is an excellent idea. I'm happy to do > the leg work to get this into the tree, so that's not an issue. :-) > > OpenBSD's diff is much smaller than gnu's. It seems to use less > memory as well for many operations. Its speed seems about the same. > Most of these impressions are based on light testing, so YMMV. > > This would be in keeping with our march to get rid of other gnu > products in our tree: awk, sort, etc. So if we get rid of three GNU, can we get one SCO (cscope)? But seriously, is this better than ports/textproc/freegrep which "should" have been the FreeBSD grep years ago? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 19:16:22 2004 Return-Path: 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 C4F7616A4CE for ; Fri, 17 Sep 2004 19:16:22 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EC8B43D48 for ; Fri, 17 Sep 2004 19:16:22 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8HJGJ7N072963; Fri, 17 Sep 2004 15:16:19 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8HJGJHh072962; Fri, 17 Sep 2004 15:16:19 -0400 (EDT) (envelope-from green) Date: Fri, 17 Sep 2004 15:16:19 -0400 From: Brian Fundakowski Feldman To: "M. Warner Losh" Message-ID: <20040917191619.GS36708@green.homeunix.org> References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040917191240.GR36708@green.homeunix.org> User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 19:16:22 -0000 On Fri, Sep 17, 2004 at 03:12:40PM -0400, Brian Fundakowski Feldman wrote: > On Fri, Sep 17, 2004 at 01:05:49PM -0600, M. Warner Losh wrote: > > In message: <16715.4611.108597.354107@piglet.timing.com> > > Ben Mesander writes: > > : I've recently done a port of OpenBSD diff(1) to FreeBSD for > > : licensing reasons (the diff(1) in base FreeBSD is GPL licensed), > > : OpenBSD has a BSD-style license). > > : > > : I was going to work with Warner to see if I could get this into > > : the ports collection. But we were also curious to see if other > > : people thought it might be OK to replace the GNU diff in base > > : with the OpenBSD diff. > > : > > : For reference, here is the OpenBSD diff source and manpage: > > : http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/diff/ > > : > > : There would also have to be some integration with other programs > > : (such as diff3(1)). > > > > Needless to say, I think this is an excellent idea. I'm happy to do > > the leg work to get this into the tree, so that's not an issue. :-) > > > > OpenBSD's diff is much smaller than gnu's. It seems to use less > > memory as well for many operations. Its speed seems about the same. > > Most of these impressions are based on light testing, so YMMV. > > > > This would be in keeping with our march to get rid of other gnu > > products in our tree: awk, sort, etc. > > So if we get rid of three GNU, can we get one SCO (cscope)? http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/grep/ > But seriously, is this better than ports/textproc/freegrep which > "should" have been the FreeBSD grep years ago? P.S. Totally kicking myself for not noticing you didn't explicitly mention the OpenBSD grep among your short list of GNU programs. So anyway, OpenBSD diff, OpenBSD grep, didn't someone write a FreeBSD-destined sort(1), too? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 19:45:57 2004 Return-Path: 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 9EAE716A4CE for ; Fri, 17 Sep 2004 19:45:57 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F39B43D31 for ; Fri, 17 Sep 2004 19:45:57 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i8HJjs6u021410; Fri, 17 Sep 2004 15:45:56 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <16715.4611.108597.354107@piglet.timing.com> References: <16715.4611.108597.354107@piglet.timing.com> Date: Fri, 17 Sep 2004 15:45:53 -0400 To: Ben Mesander , freebsd-arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 19:45:57 -0000 At 10:34 AM -0600 9/17/04, Ben Mesander wrote: >Hi, > > I've recently done a port of OpenBSD diff(1) to FreeBSD for >licensing reasons (the diff(1) in base FreeBSD is GPL licensed), >OpenBSD has a BSD-style license). > > I was going to work with Warner to see if I could get this into >the ports collection. But we were also curious to see if other >people thought it might be OK to replace the GNU diff in base >with the OpenBSD diff. I think that FreeBSD should prefer BSD-licensed utilities whenever they are available and work well enough. (and when they have all the features that people are used to for that utility). Assuming OpenBSD's diff does the job, I'm all for having us switch to it. It makes more sense for gnu's diff to be the version that ends up available as a port. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 19:52:49 2004 Return-Path: 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 9EC9216A4CE; Fri, 17 Sep 2004 19:52:49 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C6D443D55; Fri, 17 Sep 2004 19:52:49 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id A590F1CEC; Fri, 17 Sep 2004 21:53:28 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 52876B85E; Fri, 17 Sep 2004 21:52:48 +0200 (CEST) To: Brian Fundakowski Feldman References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 17 Sep 2004 21:52:48 +0200 In-Reply-To: <20040917191240.GR36708@green.homeunix.org> (Brian Fundakowski Feldman's message of "Fri, 17 Sep 2004 15:12:40 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 19:52:49 -0000 Brian Fundakowski Feldman writes: > But seriously, is this better than ports/textproc/freegrep which > "should" have been the FreeBSD grep years ago? freegrep still has a few bugs (like trying to grep directories), is considerably slower than GNU grep, and lacks locale support IIRC. On the other hand, it uses FTS and therefore handles symlinks much better than GNU grep. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 19:53:21 2004 Return-Path: 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 85A7916A4CF for ; Fri, 17 Sep 2004 19:53:21 +0000 (GMT) Received: from post-24.mail.nl.demon.net (post-24.mail.nl.demon.net [194.159.73.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BD5643D1D for ; Fri, 17 Sep 2004 19:53:20 +0000 (GMT) (envelope-from dodell@sitetronics.com) Received: from gibsonnet.demon.nl ([82.161.57.57]:19613 helo=[192.168.1.19]) by post-24.mail.nl.demon.net with esmtp (Exim 4.34) id 1C8OnH-000FYz-Ew; Fri, 17 Sep 2004 19:53:19 +0000 Message-ID: <414B40B0.5030809@sitetronics.com> Date: Fri, 17 Sep 2004 21:53:20 +0200 From: "Devon H. O'Dell" User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <16715.4611.108597.354107@piglet.timing.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 19:53:21 -0000 Garance A Drosihn wrote: > At 10:34 AM -0600 9/17/04, Ben Mesander wrote: > >> Hi, >> >> I've recently done a port of OpenBSD diff(1) to FreeBSD for >> licensing reasons (the diff(1) in base FreeBSD is GPL licensed), >> OpenBSD has a BSD-style license). >> >> I was going to work with Warner to see if I could get this into >> the ports collection. But we were also curious to see if other >> people thought it might be OK to replace the GNU diff in base >> with the OpenBSD diff. > > > I think that FreeBSD should prefer BSD-licensed utilities whenever > they are available and work well enough. (and when they have all > the features that people are used to for that utility). Assuming > OpenBSD's diff does the job, I'm all for having us switch to it. > It makes more sense for gnu's diff to be the version that ends up > available as a port. Does OpenBSD's diffutils include sdiff? If not, this will be broken. --Devon From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 19:59:19 2004 Return-Path: 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 B0C5F16A4CE; Fri, 17 Sep 2004 19:59:19 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 643EB43D4C; Fri, 17 Sep 2004 19:59:19 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i8HJxEF9020531; Fri, 17 Sep 2004 15:59:15 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040917191240.GR36708@green.homeunix.org> References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> Date: Fri, 17 Sep 2004 15:59:13 -0400 To: Brian Fundakowski Feldman , "M. Warner Losh" From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 19:59:19 -0000 At 3:12 PM -0400 9/17/04, Brian Fundakowski Feldman wrote: >On Fri, Sep 17, 2004, M. Warner Losh wrote: > > >> OpenBSD's diff is much smaller than gnu's. It seems to use less >> memory as well for many operations. Its speed seems about the same. > > Most of these impressions are based on light testing, so YMMV. > >But seriously, is this better than ports/textproc/freegrep which >"should" have been the FreeBSD grep years ago? It's certainly better when it comes to doing diff's... :-) IIRC (and I may not), the main reason that grep isn't in the base system is that it was significantly slower in some situations. But my memory of that work is pretty fuzzy. In principle I think we should replace the grep, too, as long as the replacement works as well as the version we are currently using. The thing is, none of these replacements are "urgent" to get done, and they easily get forgotten about as more urgent projects pop up. [So says Garance, who is still trying to get around to replacing the `patch' in the base system with a BSD-licensed version...] -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 20:03:51 2004 Return-Path: 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 D3E9516A4CE for ; Fri, 17 Sep 2004 20:03:51 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64C0843D31 for ; Fri, 17 Sep 2004 20:03:51 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8HK3kiI073285; Fri, 17 Sep 2004 16:03:46 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8HK3k1D073284; Fri, 17 Sep 2004 16:03:46 -0400 (EDT) (envelope-from green) Date: Fri, 17 Sep 2004 16:03:45 -0400 From: Brian Fundakowski Feldman To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20040917200345.GT36708@green.homeunix.org> References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 20:03:52 -0000 On Fri, Sep 17, 2004 at 09:52:48PM +0200, Dag-Erling Smørgrav wrote: > Brian Fundakowski Feldman writes: > > But seriously, is this better than ports/textproc/freegrep which > > "should" have been the FreeBSD grep years ago? > > freegrep still has a few bugs (like trying to grep directories), is > considerably slower than GNU grep, and lacks locale support IIRC. On > the other hand, it uses FTS and therefore handles symlinks much better > than GNU grep. Do you happen to know anything about the OpenBSD grep? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 21:21:39 2004 Return-Path: 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 F0C9B16A4CE; Fri, 17 Sep 2004 21:21:39 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8039643D2D; Fri, 17 Sep 2004 21:21:39 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id C6B36402C; Fri, 17 Sep 2004 23:22:18 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 70250B85E; Fri, 17 Sep 2004 23:21:38 +0200 (CEST) To: Brian Fundakowski Feldman References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> <20040917200345.GT36708@green.homeunix.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 17 Sep 2004 23:21:38 +0200 In-Reply-To: <20040917200345.GT36708@green.homeunix.org> (Brian Fundakowski Feldman's message of "Fri, 17 Sep 2004 16:03:45 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 21:21:40 -0000 Brian Fundakowski Feldman writes: > Do you happen to know anything about the OpenBSD grep? a little: des@dwp ~/projects/openbsd/src/usr.bin/grep% head -5 grep.c /* $OpenBSD: grep.c,v 1.29 2004/08/05 21:47:33 deraadt Exp $ */ /*- * Copyright (c) 1999 James Howard and Dag-Erling Co=EFdan Sm=F8rgrav * All rights reserved. I don't know how much they've changed it, but I do know that it still uses whichever regexp engine you happen to have in libc. In our case, that means good old Henry Spencer. Last I talked to him, he was going to release a new, improved, and much faster regexp engine, but that was years ago and I still haven't seen anything come out of it. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 22:26:35 2004 Return-Path: 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 3121F16A4CE for ; Fri, 17 Sep 2004 22:26:35 +0000 (GMT) Received: from Daffy.timing.com (w.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0229443D1F for ; Fri, 17 Sep 2004 22:26:35 +0000 (GMT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.12.8p2/8.12.8) with ESMTP id i8HMPJn2071077 for ; Fri, 17 Sep 2004 16:25:19 -0600 (MDT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6p3/8.12.6) with ESMTP id i8HMPIhC067345 for ; Fri, 17 Sep 2004 16:25:18 -0600 (MDT) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6p3/8.12.6/Submit) id i8HMPI6I067342; Fri, 17 Sep 2004 16:25:18 -0600 (MDT) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16715.25678.610402.410860@piglet.timing.com> Date: Fri, 17 Sep 2004 16:25:18 -0600 To: freebsd-arch@freebsd.org In-Reply-To: <414B40B0.5030809@sitetronics.com> References: <16715.4611.108597.354107@piglet.timing.com> <414B40B0.5030809@sitetronics.com> X-Mailer: VM 7.00 under Emacs 21.2.95.2 X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a on Daffy.timing.com X-Virus-Status: Clean Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 22:26:35 -0000 Devon H. O'Dell writes: > Does OpenBSD's diffutils include sdiff? If not, this will be broken. > > --Devon It does not appear to have sdiff. I'm a long time UNIX user and have never used sdiff, but I suppose it's more than likely that everyone else on this mailing list uses it every day (some law about the perversity of the universe tending towards a maximum). A quick glance at the GNU sources of sdiff makes it seem to me that it may be possible to replace diff and diff3 with the OpenBSD versions and retain GNU sdiff until a replacement is written. So I can see at least 3 alternatives: 1. Replace diff, diff3 with OpenBSD versions, and lose sdiff. 2. Replace diff, diff3 with OpenBSD versions, use existing sdiff for now. 3. Leave things as they are. Opinions? Thanks, Ben Mesander From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 22:36:40 2004 Return-Path: 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 93F8616A4CE for ; Fri, 17 Sep 2004 22:36:40 +0000 (GMT) Received: from av6-1-sn2.hy.skanova.net (av6-1-sn2.hy.skanova.net [81.228.8.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9747D43D1D for ; Fri, 17 Sep 2004 22:36:39 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: by av6-1-sn2.hy.skanova.net (Postfix, from userid 502) id 66CA737E49; Sat, 18 Sep 2004 00:36:38 +0200 (CEST) Received: from smtp2-2-sn2.hy.skanova.net (smtp2-2-sn2.hy.skanova.net [81.228.8.178]) by av6-1-sn2.hy.skanova.net (Postfix) with ESMTP id 52CDB37E45 for ; Sat, 18 Sep 2004 00:36:38 +0200 (CEST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by smtp2-2-sn2.hy.skanova.net (Postfix) with SMTP id 23E9037E42 for ; Sat, 18 Sep 2004 00:36:37 +0200 (CEST) Received: (qmail 55571 invoked by uid 1001); 17 Sep 2004 22:36:36 -0000 Date: Sat, 18 Sep 2004 00:36:36 +0200 From: Erik Trulsson To: Ben Mesander Message-ID: <20040917223636.GA55502@falcon.midgard.homeip.net> Mail-Followup-To: Ben Mesander , freebsd-arch@freebsd.org References: <16715.4611.108597.354107@piglet.timing.com> <414B40B0.5030809@sitetronics.com> <16715.25678.610402.410860@piglet.timing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16715.25678.610402.410860@piglet.timing.com> User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 22:36:40 -0000 On Fri, Sep 17, 2004 at 04:25:18PM -0600, Ben Mesander wrote: > Devon H. O'Dell writes: > > Does OpenBSD's diffutils include sdiff? If not, this will be broken. > > > > --Devon > > It does not appear to have sdiff. > > I'm a long time UNIX user and have never used sdiff, but I suppose > it's more than likely that everyone else on this mailing list uses > it every day (some law about the perversity of the universe tending > towards a maximum). Most of us actually probably do use sdiff - at least indirectly. mergemaster(8) uses sdiff, and most FreeBSD users use mergemaster when updatimg their systems. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 22:37:27 2004 Return-Path: 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 1509A16A516 for ; Fri, 17 Sep 2004 22:37:26 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CE9243D41 for ; Fri, 17 Sep 2004 22:37:26 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 6105E4496; Sat, 18 Sep 2004 00:38:05 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id D27B9B85E; Sat, 18 Sep 2004 00:37:24 +0200 (CEST) To: Ben Mesander References: <16715.4611.108597.354107@piglet.timing.com> <414B40B0.5030809@sitetronics.com> <16715.25678.610402.410860@piglet.timing.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 18 Sep 2004 00:37:24 +0200 In-Reply-To: <16715.25678.610402.410860@piglet.timing.com> (Ben Mesander's message of "Fri, 17 Sep 2004 16:25:18 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 22:37:28 -0000 Ben Mesander writes: > I'm a long time UNIX user and have never used sdiff, but I suppose > it's more than likely that everyone else on this mailing list uses > it every day (some law about the perversity of the universe tending > towards a maximum). mergemaster(8) uses sdiff(1) to merge modified files. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 23:03:32 2004 Return-Path: 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 A5C8C16A4D0 for ; Fri, 17 Sep 2004 23:03:32 +0000 (GMT) Received: from mail-in-01.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEF4E43D45 for ; Fri, 17 Sep 2004 23:03:31 +0000 (GMT) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (dsl-213-023-057-140.arcor-ip.net [213.23.57.140]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 2A68E39ECD for ; Sat, 18 Sep 2004 01:03:30 +0200 (CEST) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.13.1/8.12.10) with ESMTP id i8HN3Tg9068268 for ; Sat, 18 Sep 2004 01:03:29 +0200 (CEST) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.13.1/8.13.1/Submit) id i8HN3TVP068267 for freebsd-arch@freebsd.org; Sat, 18 Sep 2004 01:03:29 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Fri, 17 Sep 2004 23:03:27 +0000 (UTC) Message-ID: References: <16715.4611.108597.354107@piglet.timing.com> <414B40B0.5030809@sitetronics.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 23:03:32 -0000 Devon H. O'Dell wrote: > Does OpenBSD's diffutils include sdiff? If not, this will be broken. No, it does not, which is very inconvenient for mergemaster. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 23:06:25 2004 Return-Path: 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 14B7B16A4CE for ; Fri, 17 Sep 2004 23:06:25 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE1AE43D4C for ; Fri, 17 Sep 2004 23:06:24 +0000 (GMT) (envelope-from chitt@speakeasy.net) Received: (qmail 23098 invoked from network); 17 Sep 2004 23:06:24 -0000 Received: from dsl093-133-046.sfo4.dsl.speakeasy.net (HELO [192.168.0.50]) (chitt@[66.93.133.46]) (envelope-sender )encrypted SMTP for ; 17 Sep 2004 23:06:24 -0000 In-Reply-To: References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> <20040917200345.GT36708@green.homeunix.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2FE38EA4-08FE-11D9-A03E-000A95C705DC@speakeasy.net> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Fri, 17 Sep 2004 16:06:20 -0700 To: des@des.no (=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=) X-Mailer: Apple Mail (2.619) cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 23:06:25 -0000 > I don't know how much they've changed it, but I do know that it still > uses whichever regexp engine you happen to have in libc. In our case, > that means good old Henry Spencer. Last I talked to him, he was going > to release a new, improved, and much faster regexp engine, but that > was years ago and I still haven't seen anything come out of it. Actually, that's not quite correct. Spencer's latest regexp(3) was integrated into PostgreSQL 7.4 to provide wide-byte regexp support (released on 2003-11-17). Last I checked, it was being used regularly and with good success as it's gotten a good ten months of production use. :) From the PostgreSQL 7.4 release notes: "Faster and more powerful regular expression code "The entire regular expression module has been replaced with a new version by Henry Spencer, originally written for Tcl. The code greatly improves performance and supports several flavors of regular expressions." -sc -- Sean Chittenden From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 23:14:11 2004 Return-Path: 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 2A74916A4CE; Fri, 17 Sep 2004 23:14:11 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8CBE43D48; Fri, 17 Sep 2004 23:14:10 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.248.230) by smtp01.syd.iprimus.net.au (7.0.031.3) id 4148DCF4000CD9E8; Sat, 18 Sep 2004 09:14:02 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 87FDE424C; Sat, 18 Sep 2004 09:14:50 +1000 (EST) Date: Sat, 18 Sep 2004 09:14:50 +1000 From: Tim Robbins To: Dag-Erling Sm?rgrav Message-ID: <20040917231450.GA4756@cat.robbins.dropbear.id.au> References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> <20040917200345.GT36708@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 23:14:11 -0000 On Fri, Sep 17, 2004 at 11:21:38PM +0200, Dag-Erling Sm?rgrav wrote: > Brian Fundakowski Feldman writes: > > Do you happen to know anything about the OpenBSD grep? > > a little: > > des@dwp ~/projects/openbsd/src/usr.bin/grep% head -5 grep.c > /* $OpenBSD: grep.c,v 1.29 2004/08/05 21:47:33 deraadt Exp $ */ > > /*- > * Copyright (c) 1999 James Howard and Dag-Erling Co?dan Sm?rgrav > * All rights reserved. > > I don't know how much they've changed it, but I do know that it still > uses whichever regexp engine you happen to have in libc. In our case, > that means good old Henry Spencer. Last I talked to him, he was going > to release a new, improved, and much faster regexp engine, but that > was years ago and I still haven't seen anything come out of it. Recent releases of tcl use a new regular expression package of his, but he still doesn't appear to have done a standalone release. I considered replacing our current implementation with the Tcl back before I added multibyte character support, and it turned out to be much slower on almost all "reasonable" test cases I could come up with. Tim From owner-freebsd-arch@FreeBSD.ORG Fri Sep 17 23:35:11 2004 Return-Path: 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 C789A16A4CE for ; Fri, 17 Sep 2004 23:35:11 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FE1843D39 for ; Fri, 17 Sep 2004 23:35:11 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8HNZ8tM074549; Fri, 17 Sep 2004 19:35:08 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8HNZ8l7074548; Fri, 17 Sep 2004 19:35:08 -0400 (EDT) (envelope-from green) Date: Fri, 17 Sep 2004 19:35:07 -0400 From: Brian Fundakowski Feldman To: Sean Chittenden Message-ID: <20040917233507.GW36708@green.homeunix.org> References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> <20040917200345.GT36708@green.homeunix.org> <2FE38EA4-08FE-11D9-A03E-000A95C705DC@speakeasy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FE38EA4-08FE-11D9-A03E-000A95C705DC@speakeasy.net> User-Agent: Mutt/1.5.6i cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 23:35:11 -0000 On Fri, Sep 17, 2004 at 04:06:20PM -0700, Sean Chittenden wrote: > >I don't know how much they've changed it, but I do know that it still > >uses whichever regexp engine you happen to have in libc. In our case, > >that means good old Henry Spencer. Last I talked to him, he was going > >to release a new, improved, and much faster regexp engine, but that > >was years ago and I still haven't seen anything come out of it. > > Actually, that's not quite correct. Spencer's latest regexp(3) was > integrated into PostgreSQL 7.4 to provide wide-byte regexp support > (released on 2003-11-17). Last I checked, it was being used regularly > and with good success as it's gotten a good ten months of production > use. :) > > From the PostgreSQL 7.4 release notes: > > "Faster and more powerful regular expression code > > "The entire regular expression module has been replaced with a new > version by Henry Spencer, originally written for Tcl. The code greatly > improves performance and supports several flavors of regular > expressions." I'll certainly have to try it out and see whether or not it's faster than Oniguruma (http://www.geocities.jp/kosako1/oniguruma/). Either one should be more than suitable for libc if it's got enough of a performance improvement. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 00:28:56 2004 Return-Path: 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 978FE16A4CE; Sat, 18 Sep 2004 00:28:56 +0000 (GMT) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D72B43D49; Sat, 18 Sep 2004 00:28:56 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.248.230) by smtp02.syd.iprimus.net.au (7.0.031.3) id 4148EDE5000C8E74; Sat, 18 Sep 2004 10:28:49 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id C45B04252; Sat, 18 Sep 2004 10:29:37 +1000 (EST) Date: Sat, 18 Sep 2004 10:29:37 +1000 From: Tim Robbins To: Brian Fundakowski Feldman Message-ID: <20040918002937.GA4944@cat.robbins.dropbear.id.au> References: <16715.4611.108597.354107@piglet.timing.com> <20040917.130549.22012205.imp@bsdimp.com> <20040917191240.GR36708@green.homeunix.org> <20040917200345.GT36708@green.homeunix.org> <2FE38EA4-08FE-11D9-A03E-000A95C705DC@speakeasy.net> <20040917233507.GW36708@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040917233507.GW36708@green.homeunix.org> User-Agent: Mutt/1.4.1i cc: Dag-Erling Sm?rgrav cc: Sean Chittenden cc: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 00:28:56 -0000 On Fri, Sep 17, 2004 at 07:35:07PM -0400, Brian Fundakowski Feldman wrote: > On Fri, Sep 17, 2004 at 04:06:20PM -0700, Sean Chittenden wrote: > > >I don't know how much they've changed it, but I do know that it still > > >uses whichever regexp engine you happen to have in libc. In our case, > > >that means good old Henry Spencer. Last I talked to him, he was going > > >to release a new, improved, and much faster regexp engine, but that > > >was years ago and I still haven't seen anything come out of it. > > > > Actually, that's not quite correct. Spencer's latest regexp(3) was > > integrated into PostgreSQL 7.4 to provide wide-byte regexp support > > (released on 2003-11-17). Last I checked, it was being used regularly > > and with good success as it's gotten a good ten months of production > > use. :) > > > > From the PostgreSQL 7.4 release notes: > > > > "Faster and more powerful regular expression code > > > > "The entire regular expression module has been replaced with a new > > version by Henry Spencer, originally written for Tcl. The code greatly > > improves performance and supports several flavors of regular > > expressions." > > I'll certainly have to try it out and see whether or not it's faster > than Oniguruma (http://www.geocities.jp/kosako1/oniguruma/). Either > one should be more than suitable for libc if it's got enough of a > performance improvement. Oniguruma is not suitable because it does not have proper locale support -- it uses its own character type tables instead of using , and its own multibyte character encoding functions instead of . Tim From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 00:52:30 2004 Return-Path: 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 7CBFF16A4CE for ; Sat, 18 Sep 2004 00:52:30 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id E1D6743D1F for ; Sat, 18 Sep 2004 00:52:29 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 16815 invoked by uid 89); 18 Sep 2004 00:52:28 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 18 Sep 2004 00:52:28 -0000 Received: (qmail 16810 invoked by uid 89); 18 Sep 2004 00:52:28 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 18 Sep 2004 00:52:28 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8I0qRmt039011; Fri, 17 Sep 2004 20:52:27 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: "freebsd-arch@freebsd.org" Content-Type: text/plain Message-Id: <1095468747.31297.241.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 20:52:27 -0400 Content-Transfer-Encoding: 7bit Subject: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 00:52:30 -0000 Hi, I finally found some time to take a peek at the sched_4bsd scheduler and found two things I could not explain: It looks like the thread priority of a thread in the kernel is normally its user priority. ( Unless it slept with priority change or due to mutex priority inheritance) If this is true kernel threads can be preempted while holding for example the root vnode lock (or other important kernel resources) while not getting a chance to run until there are no more user processes with better priority. I am probably missing a priority adjustment on kernel entry somewhere but seem to be unable to find it :-( I am also stomped by the special case of adding a thread X with better priority than the current thread to the runqueue if they belong to the same ksegroup. In this case both kg_last_assigned and kg_avail_opennings might be zero and setrunqueue() will not call sched_add(). Because of this it looks like the current thread will neither be preempted not will TDF_NEEDRESCHED be set to force rescheduling at the kernel boundary. This situation should resolve itself at the next sched_switch - however this might take a long time. (Especially if essential interrupt threads are blocked by mutexes held by thread X) Thanks in advance for any hints. Stephan PS: I am impressed how clean and easy to read the scheduler sources are. Looks like a lot of hard work went into this. From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 01:20:31 2004 Return-Path: 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 3BB4F16A4CE for ; Sat, 18 Sep 2004 01:20:31 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB99B43D39 for ; Sat, 18 Sep 2004 01:20:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id CA8617A3D2; Fri, 17 Sep 2004 18:20:30 -0700 (PDT) Message-ID: <414B8D5E.7000700@elischer.org> Date: Fri, 17 Sep 2004 18:20:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Stephan Uphoff References: <1095468747.31297.241.camel@palm.tree.com> In-Reply-To: <1095468747.31297.241.camel@palm.tree.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 01:20:31 -0000 Stephan Uphoff wrote: >Hi, > >I finally found some time to take a peek at the sched_4bsd scheduler >and found two things I could not explain: > >It looks like the thread priority of a thread in the kernel is normally >its user priority. >( Unless it slept with priority change or due to mutex priority >inheritance) > exactly. > >If this is true kernel threads can be preempted while holding >for example the root vnode lock (or other important kernel >resources) while not getting a chance to run until there are no more >user processes with better priority. > This is also true, though it is a slightly more complicated thing than that. Preempting threads are usually interrupt threads and are thus usually short lived,. The theory is however that as long as the CPU is doing something, teh throughput is still being maintianed. (For this reason we have not worked on the problem you mention yet, though it will eventually get to the top of someone's list :-) . >I am probably missing a priority adjustment on kernel entry somewhere >but seem to be unable to find it :-( > > >I am also stomped by the special case of adding a thread X with better >priority than the current thread to the runqueue if they belong to the >same ksegroup. In this case both kg_last_assigned and kg_avail_opennings >might be zero and setrunqueue() will not call sched_add(). >Because of this it looks like the current thread will neither be >preempted not will TDF_NEEDRESCHED be set to force rescheduling at the >kernel boundary. >This situation should resolve itself at the next sched_switch - however >this might take a long time. (Especially if essential interrupt threads >are blocked by mutexes held by thread X) > you are correct. I am not yet preempting a running thread with a lesser priority if they are siblings (unless there is a slot available) Thsi is not becasue I don't want to do it, but simply because it has not been done yet.. we did have NO preemption, so having "some" preemption is still better than where we were. Special case code to check curthread for a preemption could be done but at the moment the decision code for whether to preempt or not is in maybe_preempt() and I don't want to duplicate that. it is on th edrawing board though. The other thing is, that even if we should be able to preempt a running thread, there is no guarantee that it is on THIS CPU. It may be on another CPU and that gets nasty in a hurry. > >Thanks in advance for any hints. > > Stephan > >PS: I am impressed how clean and easy to read the scheduler sources are. > Looks like a lot of hard work went into this. > There is a lot to clean up yet.. what version are you reading? -current? > >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 13:32:54 2004 Return-Path: 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 C8EB416A4CE for ; Sat, 18 Sep 2004 13:32:54 +0000 (GMT) Received: from mail-in-01.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3B3543D1F for ; Sat, 18 Sep 2004 13:32:53 +0000 (GMT) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (dsl-213-023-057-015.arcor-ip.net [213.23.57.15]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 340C45B54D for ; Sat, 18 Sep 2004 15:32:52 +0200 (CEST) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.13.1/8.12.10) with ESMTP id i8IDWpJA055056 for ; Sat, 18 Sep 2004 15:32:51 +0200 (CEST) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.13.1/8.13.1/Submit) id i8IDWp4O055055 for freebsd-arch@freebsd.org; Sat, 18 Sep 2004 15:32:51 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Sat, 18 Sep 2004 13:32:50 +0000 (UTC) Message-ID: References: <16715.4611.108597.354107@piglet.timing.com> <414B40B0.5030809@sitetronics.com> <16715.25678.610402.410860@piglet.timing.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Subject: Re: diff(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 13:32:54 -0000 Ben Mesander wrote: > A quick glance at the GNU sources of sdiff makes it seem to me that it > may be possible to replace diff and diff3 with the OpenBSD versions > and retain GNU sdiff until a replacement is written. GNU sdiff calls diff with "--sdiff-merge-assist", which suggests that the two are rather more intertwined. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 17:42:36 2004 Return-Path: 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 9C3A216A4CE for ; Sat, 18 Sep 2004 17:42:36 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 219F043D1F for ; Sat, 18 Sep 2004 17:42:36 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 26260 invoked by uid 89); 18 Sep 2004 17:42:35 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 18 Sep 2004 17:42:35 -0000 Received: (qmail 26249 invoked by uid 89); 18 Sep 2004 17:42:34 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 18 Sep 2004 17:42:34 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8IHgXmt042638; Sat, 18 Sep 2004 13:42:34 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <414B8D5E.7000700@elischer.org> References: <1095468747.31297.241.camel@palm.tree.com> <414B8D5E.7000700@elischer.org> Content-Type: text/plain Message-Id: <1095529353.31297.1192.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 18 Sep 2004 13:42:33 -0400 Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 17:42:36 -0000 On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > Stephan Uphoff wrote: > > > >If this is true kernel threads can be preempted while holding > >for example the root vnode lock (or other important kernel > >resources) while not getting a chance to run until there are no more > >user processes with better priority. > > > > This is also true, though it is a slightly more complicated thing than > that. > Preempting threads are usually interrupt threads and are thus usually > short lived,. But interrupt threads often wake up other threads ... > > > The theory is however that as long as the CPU is doing something, teh > throughput is > still being maintianed. Mhhh .. yes - I guess the only problem is with pathetic cases. ( Tons of cpu bound threads and nice values that prevent the preempted thread to gain a better priority) > (For this reason we have not worked on the > problem you mention yet, though > it will eventually get to the top of someone's list :-) Great > > > >I am also stomped by the special case of adding a thread X with better > >priority than the current thread to the runqueue if they belong to the > >same ksegroup. In this case both kg_last_assigned and kg_avail_opennings > >might be zero and setrunqueue() will not call sched_add(). > >Because of this it looks like the current thread will neither be > >preempted not will TDF_NEEDRESCHED be set to force rescheduling at the > >kernel boundary. > >This situation should resolve itself at the next sched_switch - however > >this might take a long time. (Especially if essential interrupt threads > >are blocked by mutexes held by thread X) > > > > you are correct. I am not yet preempting a running thread with a lesser > priority if they are siblings > (unless there is a slot available) Thsi is not becasue I don't want to > do it, but simply because it has not been done yet.. > we did have NO preemption, so having "some" preemption is still better > than where we were. > Special case code to check curthread for a preemption could be done but > at the moment the decision code for > whether to preempt or not is in maybe_preempt() and I don't want to > duplicate that. it is on th edrawing board though. > The other thing is, that even if we should be able to preempt a running > thread, there is no guarantee that it is on THIS > CPU. It may be on another CPU and that gets nasty in a hurry. Yes .. this could get nasty. This happens when the thread is bound to another cpu or someone changed thr_concurrency - otherwise the current thread must be a sibling right ? Maybe something brutal like: if ((curthread->td_ksegrp == kg) && (td->td_priority > curthread->td_priority)) curthread->td_flags |= TDF_NEEDRESCHED; in setrunqueue for the else case of "if (kg->kg_avail_opennings > 0)" would do the trick (without preemption) for the easy but probably more common cases? Maybe I can find some time next week to think about a clean fix. I find it always helpful having a small task in mind while reading source code. > >PS: I am impressed how clean and easy to read the scheduler sources are. > > Looks like a lot of hard work went into this. > > > > There is a lot to clean up yet.. But there is a huge difference between thinking about a little vacuuming and wishing for some bulldozers ;-) > what version are you reading? -current? current (Sep 16) Thanks for the detailed answer. Stephan From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 21:11:58 2004 Return-Path: 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 8B5E716A4CE for ; Sat, 18 Sep 2004 21:11:58 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 663DD43D4C for ; Sat, 18 Sep 2004 21:11:58 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 29439 invoked from network); 18 Sep 2004 21:11:58 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 18 Sep 2004 21:11:57 -0000 Received: from slimer.baldwin.cx (slimer.baldwin.cx [192.168.0.16]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8ILBrTx010381; Sat, 18 Sep 2004 17:11:53 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Sat, 18 Sep 2004 16:53:35 -0400 User-Agent: KMail/1.6.2 References: <1095468747.31297.241.camel@palm.tree.com> <414B8D5E.7000700@elischer.org> <1095529353.31297.1192.camel@palm.tree.com> In-Reply-To: <1095529353.31297.1192.camel@palm.tree.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409181653.35242.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: "freebsd-arch@freebsd.org" cc: Julian Elischer cc: Stephan Uphoff Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 21:11:58 -0000 On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > > Stephan Uphoff wrote: > > >If this is true kernel threads can be preempted while holding > > >for example the root vnode lock (or other important kernel > > >resources) while not getting a chance to run until there are no more > > >user processes with better priority. > > > > This is also true, though it is a slightly more complicated thing than > > that. > > Preempting threads are usually interrupt threads and are thus usually > > short lived,. > > But interrupt threads often wake up other threads ... That are lower priority and thus won't be preempted to. Instead, they run when the interrupt thread goes back to sleep after it finishes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 23:08:37 2004 Return-Path: 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 F17C716A4CE for ; Sat, 18 Sep 2004 23:08:37 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 81EFD43D46 for ; Sat, 18 Sep 2004 23:08:37 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 27848 invoked by uid 89); 18 Sep 2004 23:08:35 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 18 Sep 2004 23:08:35 -0000 Received: (qmail 27822 invoked by uid 89); 18 Sep 2004 23:08:35 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 18 Sep 2004 23:08:35 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8IN8Ymt043878; Sat, 18 Sep 2004 19:08:35 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: John Baldwin In-Reply-To: <200409181653.35242.jhb@FreeBSD.org> References: <1095468747.31297.241.camel@palm.tree.com> <1095529353.31297.1192.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> Content-Type: text/plain Message-Id: <1095548914.43781.27.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 18 Sep 2004 19:08:34 -0400 Content-Transfer-Encoding: 7bit cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 23:08:38 -0000 On Sat, 2004-09-18 at 16:53, John Baldwin wrote: > On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > > On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > > > Stephan Uphoff wrote: > > > >If this is true kernel threads can be preempted while holding > > > >for example the root vnode lock (or other important kernel > > > >resources) while not getting a chance to run until there are no more > > > >user processes with better priority. > > > > > > This is also true, though it is a slightly more complicated thing than > > > that. > > > Preempting threads are usually interrupt threads and are thus usually > > > short lived,. > > > > But interrupt threads often wake up other threads ... > > That are lower priority and thus won't be preempted to. Instead, they run > when the interrupt thread goes back to sleep after it finishes. Lower priority than the interrupt threads. They can however have a priority better than the interrupted thread holding the kernel resource. In this case the newly awoken threads will be next to run. If they are compute bound in user space or wake other threads with better priorities it might take a while until the system switches back to the interrupted thread. Stephan From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 23:17:21 2004 Return-Path: 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 1708F16A4CE for ; Sat, 18 Sep 2004 23:17:21 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF78B43D48 for ; Sat, 18 Sep 2004 23:17:20 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 24877 invoked from network); 18 Sep 2004 23:17:20 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Sep 2004 23:17:20 -0000 Received: from hydrogen.funkthat.com (hcxina@localhost.funkthat.com [127.0.0.1])i8INHJuU084806; Sat, 18 Sep 2004 16:17:20 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8INHJWE084805; Sat, 18 Sep 2004 16:17:19 -0700 (PDT) Date: Sat, 18 Sep 2004 16:17:19 -0700 From: John-Mark Gurney To: Andre Oppermann Message-ID: <20040918231719.GV72089@funkthat.com> Mail-Followup-To: Andre Oppermann , freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20040906050435.GA72089@funkthat.com> <41408D4C.E33B6F98@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41408D4C.E33B6F98@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: better MTU support... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 23:17:21 -0000 Andre Oppermann wrote this message on Thu, Sep 09, 2004 at 19:05 +0200: Ok, finally got a switch (and gige cards, if_re needs work) capable of jumbo frames.. > John-Mark Gurney wrote: > > In a recent experiment w/ Jumbo frames, I found out that sending ip > > frames completely ignores the MTU set on host routes. This makes it > > difficult (or next to impossible) to support a network that has both > > regular and jumbo frames on it as you can't restrict some hosts to the > > smaller frames. > > What you should do instead is to set the MTU on the interface to 9018 > or so and then have a default route with MTU 1500 for everything else. > Now you can specify larger MTUs for hosts that support it. > > Otherwise you are opening a can of worms... This doesn't fix it, since the output still doesn't honor the mtu on the route.. Note, I'm not testing tcp, only udp and icmp since I've seen that TCP already works fine... # netstat -rnWfinet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Netif Expire default 192.168.0.14 UGS 0 11 1500 em0 127.0.0.1 127.0.0.1 UH 0 40 16384 lo0 192.168.0 link#5 UC 0 0 9000 em0 192.168.0.1 00:a0:c9:59:8b:6c UHLW 0 33 1500 em0 175 192.168.0.3 00:0a:95:9e:8b:88 UHLW 0 1988 9000 em0 374 192.168.0.14 00:a0:c9:31:30:5e UHLW 1 8 1500 em0 955 192.168.0.20 00:07:e9:0d:aa:ca UHLW 0 18 9000 em0 187 192.168.0.21 00:07:e9:0d:ad:06 UHLW 0 2 9000 lo0 tcpdump output: 16:02:14.311079 IP 192.168.0.21 > 192.168.0.1: icmp 5008: echo request seq 14 16:02:15.320981 IP 192.168.0.21 > 192.168.0.1: icmp 5008: echo request seq 15 16:04:54.720890 IP 192.168.0.21 > 128.223.122.47: icmp 5008: echo request seq 0 16:04:55.727148 IP 192.168.0.21 > 128.223.122.47: icmp 5008: echo request seq 1 16:05:02.288989 IP 192.168.0.21 > 192.168.0.20: icmp 5008: echo request seq 0 16:05:02.289856 IP 192.168.0.20 > 192.168.0.21: icmp 5008: echo reply seq 0 16:05:03.296481 IP 192.168.0.21 > 192.168.0.20: icmp 5008: echo request seq 1 16:05:03.297282 IP 192.168.0.20 > 192.168.0.21: icmp 5008: echo reply seq 1 So, as you can see, it's broken... with my patch, ip properly fragments the packets to machines with smaller mtu... > > I now have a patch to ip_output that makes it obay the MTU set on the > > route instead of that of the interface. > > Your patch corrects a problem in ip_output where a smaller MTU on an > rtentry was ignored but that is only for the non-TCP cases. When you > open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu). > If not it would be a bug. > > Could you try your large MTU setup again using the procedure I desribed > above? > > That should solve your immediate problem. Nope, it doesn't... > For the general 'bug' in ip_output that it doesn't honour a smaller MTU > on a route I'd like to do a more throughout fix. Routes should be > created with MTU 0 if the MTU is not different from the if_mtu. Only > in those cases where you want to have a lower MTU you set it. For cloned > routes the MTU would be cloned from the parent. This range of changes is > more intrusive. On top of that comes the new ARP code which will have a > MTU field as well. This one is supposed to store different MTUs for mixed > MTU L2 networks. How to transport the MTU information is a separate > discussion. > > If the fix above works for you I'd like to do the real fix later (< end > of year) and not change the current behaviour in ip_output at the moment. It wouldn't be hard to add to my patch the check to see if the route's mtu is 0 and just use the if mtu... which then solves the ip part of your more complete fix... Then when you finally fix the route/arp stuff nothing else should be necessary... Sound good? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."