From owner-freebsd-hackers Sun Feb 18 1:31:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 7221637B401; Sun, 18 Feb 2001 01:31:27 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 14UQBh-0006wX-00; Sun, 18 Feb 2001 09:31:25 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f1I9WOg04446; Sun, 18 Feb 2001 10:32:24 +0100 (CET) (envelope-from wkb) Date: Sun, 18 Feb 2001 10:32:24 +0100 From: Wilko Bulte To: Luigi Rizzo Cc: Warner Losh , FreeBSD-hackers@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: hotplug ata device? Message-ID: <20010218103224.A4042@freebie.demon.nl> References: <200102180153.f1I1rNW92992@harmony.village.org> <200102180155.f1I1tEY21445@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102180155.f1I1tEY21445@iguana.aciri.org>; from rizzo@aciri.org on Sat, Feb 17, 2001 at 05:55:14PM -0800 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 17, 2001 at 05:55:14PM -0800, Luigi Rizzo wrote: > > In message <20010217190246.A313@freebie.demon.nl> Wilko Bulte writes: > > : Is it possible to have something like the 'camcontrol rescan' that > > : the SCSI CAM subsystem has? > > > > NO. These cards are not hot pluggable. I've blown out two IDE > > Controllers hot plugging them. DO NOT TRY TO HOTPLUG THEM OR YOU WILL > > BE SORRY. > > > > I hate to shout like that, but after the second IDE controller fried, > > I got real conservative. > > i think he was referring to compactflash memories which you can stick > into pcmcia adapters and are hot-pluggable. I am refering to a CF flash memory card, which is connected to an onboard IDE controller. -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 1:33:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 1307A37B401; Sun, 18 Feb 2001 01:33:19 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 14UQDV-000Bll-00; Sun, 18 Feb 2001 09:33:17 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f1I9YFf04456; Sun, 18 Feb 2001 10:34:15 +0100 (CET) (envelope-from wkb) Date: Sun, 18 Feb 2001 10:34:15 +0100 From: Wilko Bulte To: Warner Losh Cc: Luigi Rizzo , keichii@peorth.iteration.net, FreeBSD-hackers@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: hotplug ata device? Message-ID: <20010218103415.B4042@freebie.demon.nl> References: <200102180220.f1I2KKR21592@iguana.aciri.org> <200102180224.f1I2O6W93349@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102180224.f1I2O6W93349@harmony.village.org>; from imp@harmony.village.org on Sat, Feb 17, 2001 at 07:24:06PM -0700 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 17, 2001 at 07:24:06PM -0700, Warner Losh wrote: > In message <200102180220.f1I2KKR21592@iguana.aciri.org> Luigi Rizzo writes: > : i actually wonder, aren't there removable disk frames which support > : hot swap (by turning off power with the keylock, or the like) ? > > I've not seen any, but I suppose they exist. The TAPR ones, however, > definitely are not those beasts. they are simple and don't support > hotswap. > > : Plus, it is actually curious that you can fry the IDE controller, > : the simplest ones used to be just a couple of '245 and an > : address decoder... > > I think that the main problem is lack of good grounding causing large > transients when the card is removed. But I could be wrong about > that. Each time I fried one it was definitely a remove + insert > sequence. Thanks for all the input :-) I will stop my hot-swap experiments here and now. To think that a few stupid TTL buffer chips would have made it possible to hotswap :-( W/ -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 1:36:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 447B037B401; Sun, 18 Feb 2001 01:36:46 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1I9aaW01826; Sun, 18 Feb 2001 02:36:36 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102180936.f1I9aaW01826@harmony.village.org> To: Wilko Bulte Subject: Re: hotplug ata device? Cc: Luigi Rizzo , keichii@peorth.iteration.net, FreeBSD-hackers@FreeBSD.ORG, sos@FreeBSD.ORG In-reply-to: Your message of "Sun, 18 Feb 2001 10:34:15 +0100." <20010218103415.B4042@freebie.demon.nl> References: <20010218103415.B4042@freebie.demon.nl> <200102180220.f1I2KKR21592@iguana.aciri.org> <200102180224.f1I2O6W93349@harmony.village.org> Date: Sun, 18 Feb 2001 02:36:36 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010218103415.B4042@freebie.demon.nl> Wilko Bulte writes: : Thanks for all the input :-) I will stop my hot-swap experiments here and : now. To think that a few stupid TTL buffer chips would have made it : possible to hotswap :-( The design is such that that might be difficult.... When a CF card is plugged into a socket or removed, a specific powering sequences happen. These don't happen on the IDE adapter card since the CF card is operating in the alternate TRUE IDE mode.... Uggg. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 2:22:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 74AE537B401; Sun, 18 Feb 2001 02:22:34 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 14UQz5-0000CE-00; Sun, 18 Feb 2001 10:22:27 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.2) id f1IANQC04805; Sun, 18 Feb 2001 11:23:26 +0100 (CET) (envelope-from wkb) Date: Sun, 18 Feb 2001 11:23:26 +0100 From: Wilko Bulte To: Warner Losh Cc: Luigi Rizzo , keichii@peorth.iteration.net, FreeBSD-hackers@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: hotplug ata device? Message-ID: <20010218112326.A4791@freebie.demon.nl> References: <20010218103415.B4042@freebie.demon.nl> <200102180220.f1I2KKR21592@iguana.aciri.org> <200102180224.f1I2O6W93349@harmony.village.org> <20010218103415.B4042@freebie.demon.nl> <200102180936.f1I9aaW01826@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102180936.f1I9aaW01826@harmony.village.org>; from imp@harmony.village.org on Sun, Feb 18, 2001 at 02:36:36AM -0700 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 18, 2001 at 02:36:36AM -0700, Warner Losh wrote: > In message <20010218103415.B4042@freebie.demon.nl> Wilko Bulte writes: > : Thanks for all the input :-) I will stop my hot-swap experiments here and > : now. To think that a few stupid TTL buffer chips would have made it > : possible to hotswap :-( > > The design is such that that might be difficult.... When a CF card is > plugged into a socket or removed, a specific powering sequences > happen. These don't happen on the IDE adapter card since the CF card > is operating in the alternate TRUE IDE mode.... Uggg. Hm, I see. But TTL has a lot higher survivability than highly-integrated CMOS LSI stuff. Ah, well, as long as one knows what NOT to do ;) -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 9:59:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 247F937B65D for ; Sun, 18 Feb 2001 09:59:11 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f1IHwmB27757; Sun, 18 Feb 2001 09:58:48 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102181758.f1IHwmB27757@iguana.aciri.org> Subject: Re: boot1 changes and etherboot support In-Reply-To: <200102171701.TAA11901@siri.nordier.com> from Robert Nordier at "Feb 17, 2001 7: 1:32 pm" To: rnordier@nordier.com (Robert Nordier) Date: Sun, 18 Feb 2001 09:58:48 -0800 (PST) Cc: rizzo@aciri.org, rnordier@nordier.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > + put some conditional-compilation code in boot1.s > > + have a separate file, say bootrom.s, maybe in the same directory > > as the existing boot1 > > + pass the modified code to the etherboot people so they can include > > in their source tree. > > > > in all sincerity i'd love to have this code in the FreeBSD source tree > > rather than have to resort to some external repository. > > My preference would be for a separate file in a separate directory, > more or less similar to cdldr and pxeldr; I'd be least keen on handling > this with conditional-compilation. ok.. do you mind then if i follow your advice and create /sys/i386/romldr/ and put there the modified boot1, makefile etc ? There has been no other feedback so i think most other people is neutral. On a separate issue, and for picobsd purposes, it would be very convenient to have yet another boot sector type that would just take an ELF kernel appended to it, load into memory and start it. I suppose this would be a variant of boot2, but do you have any idea on how complex would it be to write such a beast ? If we had it, we could just 'dd' the boot code and the kernel onto a compactflash and boot from it without having to worry about creating a filesystem. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 10: 7:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A65F437B4EC for ; Sun, 18 Feb 2001 10:07:18 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1II7Gh49098; Sun, 18 Feb 2001 11:07:17 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1II69E73002; Sun, 18 Feb 2001 11:06:09 -0700 (MST) Message-Id: <200102181806.f1II69E73002@billy-club.village.org> To: Luigi Rizzo Subject: Re: boot1 changes and etherboot support Cc: rnordier@nordier.com (Robert Nordier), hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 18 Feb 2001 09:58:48 PST." <200102181758.f1IHwmB27757@iguana.aciri.org> References: <200102181758.f1IHwmB27757@iguana.aciri.org> Date: Sun, 18 Feb 2001 11:06:09 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102181758.f1IHwmB27757@iguana.aciri.org> Luigi Rizzo writes: : If we had it, we could just 'dd' the boot code and the kernel onto : a compactflash and boot from it without having to worry about : creating a filesystem. We'd also be able to load the kernel out of ROM :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 10:12:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 005F437B491 for ; Sun, 18 Feb 2001 10:12:51 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f1IICV127887; Sun, 18 Feb 2001 10:12:31 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102181812.f1IICV127887@iguana.aciri.org> Subject: Re: boot1 changes and etherboot support In-Reply-To: <200102181806.f1II69E73002@billy-club.village.org> from Warner Losh at "Feb 18, 2001 11: 6: 9 am" To: imp@village.org (Warner Losh) Date: Sun, 18 Feb 2001 10:12:31 -0800 (PST) Cc: rizzo@aciri.org, rnordier@nordier.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200102181758.f1IHwmB27757@iguana.aciri.org> Luigi Rizzo writes: > : If we had it, we could just 'dd' the boot code and the kernel onto > : a compactflash and boot from it without having to worry about > : creating a filesystem. > > We'd also be able to load the kernel out of ROM :-) the whole issue is the size of the ROM isn't it ? luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 10:26: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CA49637B401 for ; Sun, 18 Feb 2001 10:26:03 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1IIPfW03495; Sun, 18 Feb 2001 11:25:41 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102181825.f1IIPfW03495@harmony.village.org> To: Luigi Rizzo Subject: Re: boot1 changes and etherboot support Cc: rnordier@nordier.com, hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 18 Feb 2001 10:12:31 PST." <200102181812.f1IICV127887@iguana.aciri.org> References: <200102181812.f1IICV127887@iguana.aciri.org> Date: Sun, 18 Feb 2001 11:25:41 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102181812.f1IICV127887@iguana.aciri.org> Luigi Rizzo writes: : > We'd also be able to load the kernel out of ROM :-) : : the whole issue is the size of the ROM isn't it ? Yes. I saw a few datasheets for embedded systems that have 2M or 4M of flash. Some of that is for the BIOS, but part of it can be used for a system image. That's a very common thin on other platforms as well. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 11:28:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.wanadoo.nl (smtp.wanadoo.nl [194.134.193.6]) by hub.freebsd.org (Postfix) with ESMTP id 25D6437B67D for ; Sun, 18 Feb 2001 11:28:29 -0800 (PST) Received: from private1 (i1240.vwr.wanadoo.nl [194.134.212.221]) by smtp.wanadoo.nl (8.9.3/8.9.3) with SMTP id UAA10220 for ; Sun, 18 Feb 2001 20:28:25 +0100 (MET) Message-ID: <003201c099e1$6a794e40$ddd486c2@private1> From: "Ted Kiela" To: Subject: subscribe Date: Sun, 18 Feb 2001 20:31:38 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C099E9.CB5BE1C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C099E9.CB5BE1C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe ------=_NextPart_000_002F_01C099E9.CB5BE1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe
------=_NextPart_000_002F_01C099E9.CB5BE1C0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 13:34:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from siri.nordier.com (c2-dbn-60.dial-up.net [196.34.155.188]) by hub.freebsd.org (Postfix) with ESMTP id 6112837B4EC for ; Sun, 18 Feb 2001 13:34:29 -0800 (PST) Received: (from rnordier@localhost) by siri.nordier.com (8.9.3/8.6.12) id XAA15802; Sun, 18 Feb 2001 23:36:24 +0200 (SAST) From: Robert Nordier Message-Id: <200102182136.XAA15802@siri.nordier.com> Subject: Re: boot1 changes and etherboot support In-Reply-To: <200102181758.f1IHwmB27757@iguana.aciri.org> from Luigi Rizzo at "Feb 18, 2001 9:58:48 am" To: rizzo@aciri.org (Luigi Rizzo) Date: Sun, 18 Feb 2001 23:36:24 +0200 (SAST) Cc: hackers@freebsd.org, rnordier@nordier.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > > > + put some conditional-compilation code in boot1.s > > > + have a separate file, say bootrom.s, maybe in the same directory > > > as the existing boot1 > > > + pass the modified code to the etherboot people so they can include > > > in their source tree. > > > > > > in all sincerity i'd love to have this code in the FreeBSD source tree > > > rather than have to resort to some external repository. > > > > My preference would be for a separate file in a separate directory, > > more or less similar to cdldr and pxeldr; I'd be least keen on handling > > this with conditional-compilation. > > ok.. do you mind then if i follow your advice and create /sys/i386/romldr/ > and put there the modified boot1, makefile etc ? > There has been no other feedback so i think most other people is neutral. Seems good to me. > On a separate issue, and for picobsd purposes, it would be very > convenient to have yet another boot sector type that would just > take an ELF kernel appended to it, load into memory and start it. > I suppose this would be a variant of boot2, but do you have any > idea on how complex would it be to write such a beast ? I have a generic boot1, that would just about do this. Instead of understanding filesystems or file formats, it works off an embedded list of block address, block count pairs. I've used the same code to boot a.out and ELF kernels off ufs, fat, and iso9660 file systems; but it does need an installation utility rather than just dd. On the other hand, to create exactly what you had in mind isn't all that much work. A sort of combination of logic from boot1.s and btx/btxldr.s (which parses ELF) would do the job in pure assembly language; otherwise just stripping most of the functionality from boot2 should work in C (and would be similar to "rawboot" that phk did using the old aout bootblocks). -- Robert Nordier rnordier@nordier.com // Le monde est plein de fous, et qui n'en veut pas voir rnordier@FreeBSD.org // Doit se tenir tout seul, et casser son miroir. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 15:17:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with ESMTP id 14AEE37B503 for ; Sun, 18 Feb 2001 15:17:32 -0800 (PST) Received: from chopper.Poohsticks.ORG (drew@localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.10.1/8.10.1) with ESMTP id f1INHTn24123; Sun, 18 Feb 2001 16:17:29 -0700 Message-Id: <200102182317.f1INHTn24123@chopper.Poohsticks.ORG> To: David Rufino Cc: hackers@FreeBSD.ORG Subject: Re: character device driver In-reply-to: Your message of "Tue, 13 Feb 2001 19:31:50 GMT." <20010213193150.A882@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24119.982538249.1@chopper.Poohsticks.ORG> Date: Sun, 18 Feb 2001 16:17:29 -0700 From: Drew Eckhardt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010213193150.A882@btinternet.com>, daverufino@btinternet.com writ es: >Hi, > >I'm writing a character device driver in which each minor device can be >opened more than once. When a device is opened is there a way to associate >some private data for each opened instance ? As other people have noted, not in the general case. The solution I've used is to split the device minor number into a physical unit and open instance part. You keep the existing per-unit structure, and add per-instance data including a busy flag which causes opens to return EBUSY. In your user land application, you iterate over the devices in round-robin fashion as long as you get back EBUSY as you would for pty masters. -- Home Page For those who do, no explanation is necessary. For those who don't, no explanation is possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 15:26:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id E77D837B503 for ; Sun, 18 Feb 2001 15:26:26 -0800 (PST) Received: (qmail 26175 invoked from network); 18 Feb 2001 23:23:28 -0000 Received: from unknown (HELO telehouse.ch) ([195.134.140.11]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 18 Feb 2001 23:23:28 -0000 Message-ID: <3A905984.8CE67B77@telehouse.ch> Date: Mon, 19 Feb 2001 00:23:48 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Robert Nordier , hackers@FreeBSD.ORG Subject: Re: boot1 changes and etherboot support References: <200102181758.f1IHwmB27757@iguana.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > > > > + put some conditional-compilation code in boot1.s > > > + have a separate file, say bootrom.s, maybe in the same directory > > > as the existing boot1 > > > + pass the modified code to the etherboot people so they can include > > > in their source tree. > > > > > > in all sincerity i'd love to have this code in the FreeBSD source tree > > > rather than have to resort to some external repository. > > > > My preference would be for a separate file in a separate directory, > > more or less similar to cdldr and pxeldr; I'd be least keen on handling > > this with conditional-compilation. > > ok.. do you mind then if i follow your advice and create /sys/i386/romldr/ Yuck, why don't just call it '/sys/i386/romloader/'? I thought the cryptic 8 char name times are over by some years. With "ldr" you save exactly 3 characters but having the full name spelled out makes it far easier on the first glance to see what this is about. > and put there the modified boot1, makefile etc ? > There has been no other feedback so i think most other people is neutral. > > On a separate issue, and for picobsd purposes, it would be very > convenient to have yet another boot sector type that would just > take an ELF kernel appended to it, load into memory and start it. > I suppose this would be a variant of boot2, but do you have any > idea on how complex would it be to write such a beast ? > > If we had it, we could just 'dd' the boot code and the kernel onto > a compactflash and boot from it without having to worry about > creating a filesystem. That would be really cool! -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 21:23:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3D91537B503 for ; Sun, 18 Feb 2001 21:23:07 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1J5Mwh91074; Mon, 19 Feb 2001 00:22:58 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 19 Feb 2001 00:22:57 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Drew Eckhardt Cc: David Rufino , hackers@FreeBSD.ORG Subject: Re: character device driver In-Reply-To: <200102182317.f1INHTn24123@chopper.Poohsticks.ORG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Feb 2001, Drew Eckhardt wrote: > In message <20010213193150.A882@btinternet.com>, daverufino@btinternet.com writ > es: > >Hi, > > > >I'm writing a character device driver in which each minor device can be > >opened more than once. When a device is opened is there a way to associate > >some private data for each opened instance ? > > As other people have noted, not in the general case. > > The solution I've used is to split the device minor number into a > physical unit and open instance part. You keep the existing per-unit > structure, and add per-instance data including a busy flag which causes > opens to return EBUSY. In your user land application, you iterate over > the devices in round-robin fashion as long as you get back EBUSY as you > would for pty masters. There are been a number of discussions at various points about ways to introduce statefulness to VFS layers and the interface with the device code in specfs. My current favorite is to introduce statefulness at the VFS layer where sessions are created during vop_open() by adding a cookie pointer passed by reference to VOP_OPEN(). The vnode implementor can, if non-NULL was passed in, optionally return cookie information (a void *) which is held in the struct file and then passed into other VOP's associated with the open file. When VOP_CLOSE is called (when the struct file refcount hits 0), the session is terminated. For file systems not supporting stateful access, the cookie would simply be null; some VOP's (such as getattr, etc) would not care about state. But for those that did, the state information could be propagated down to the device open/close calls, which could now be bound to sessions, meaning that opens and closes would have the opportunity to pass their own cookie up to VFS (presumably to be stored in the VFS state), meaning that device accesses could be associated with state, and there would by symetric opens and closes on devices also. Another possibility here is the linux route, which passes the struct file down the VFS stack allowing the device to use the struct file to maintain state (I'm not sure of the details, but believe the Linux vmware driver uses this). In my mind, it is important that (in the general case) we provide a struct file state hook rather than having per-process state, to allow things like threads, process teams, aio, file descriptor passing, etc, to work properly. One advantage to tying VFS statefulness to device statefulness is you get some nice benefits like guarantees about open/close pairs on devices. I think there aren't too many VFS complications -- the only complications might be if vnodes are ever used for relevant calls (ioctl, read, write, ...) without a VOP_OPEN first -- a few used to exist but I think those have been cleaned up. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 18 21:52:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from www.evil.2y.net (ip-216-23-53-155.adsl.one.net [216.23.53.155]) by hub.freebsd.org (Postfix) with ESMTP id 1CB7B37B491; Sun, 18 Feb 2001 21:52:31 -0800 (PST) Received: (from cokane@localhost) by www.evil.2y.net (8.11.2/8.11.1) id f1J666472306; Mon, 19 Feb 2001 01:06:06 -0500 (EST) (envelope-from cokane) Date: Mon, 19 Feb 2001 01:06:06 -0500 From: Coleman Kane To: freebsd-hackers@FreeBSD.org, freebsd-multimedia@FreeBSD.org Subject: Voodoo Graphics Message-ID: <20010219010606.A70175@cokane.yi.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" X-Mailer: Mutt 1.0.1i X-Vim: vim:tw=70:ts=4:sw=4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii I would really like to verify whether or not my 3dfx driver works properly with the older Voodoo Graphics cards. Would it be possible for someone with -CURRENT to test this out for me, or anyone to loan me one of these cards for testing. I'd just like to clase that up and make sure it works for -stable. Thanks, Coleman Kane --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6kLfNERViMObJ880RAeroAKDhrTSfPFh+tptwwD7P8A+xiIswlwCg6osO HXO2Qk4ip9y88wjEtNTug8s= =HCKm -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 6:31:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from trauco.colomsat.net.co (trauco.colomsat.net.co [200.13.195.2]) by hub.freebsd.org (Postfix) with ESMTP id 5A6C637B491; Mon, 19 Feb 2001 06:31:22 -0800 (PST) Received: from yahoo.com (200.13.214.24) by trauco.colomsat.net.co (NPlex 4.0.068) id 3A8B0BD700018391; Mon, 19 Feb 2001 09:06:54 -0500 Message-ID: <3A912AC8.F8FE3935@yahoo.com> Date: Mon, 19 Feb 2001 09:16:40 -0500 From: "Yonny Cardenas B." Organization: Universidad de los Andes X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: questions Cc: hackersBSD Subject: MAKEDEV: 609: sysntax error Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello I cann't install FreeBSD in a box with main board Mega Trends and Pentium II. I have tried installing FreeBSD 4.0, but it has an error when it is finishing the instalation. sysinstall showed: MAKEDEV returned non-zero status. The comit operation completed with errors no updating /etc files. On console: 8386 blocks DEBUG: kget mib1 has length of 0. MAKEDEV: 609: sysntax error: ";;" unexpected (expecting "done") The computer has a 6Gb IDE disk Samsung SV0644A.it has a 1 GB Win98 primary disk partion and 2Gb extend disk partion for Win 98 too. I want install FreeBSD on remainder ot the disk. Thanks. Yonny Cardenas ycardena@yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 6:57:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from news.lucky.net (news.lucky.net [193.193.193.102]) by hub.freebsd.org (Postfix) with ESMTP id 6A38D37B491 for ; Mon, 19 Feb 2001 06:57:09 -0800 (PST) Received: (from mail@localhost) by news.lucky.net (8.Who.Cares/8.Who.Cares) id QVY12376 for freebsd-hackers@freebsd.org; Mon, 19 Feb 2001 16:57:04 +0200 (envelope-from news@news.ntu-kpi.kiev.ua) From: "Andrey Simonenko" To: freebsd-hackers@freebsd.org Subject: Re: Staticaly allocated buffers in library. Is it correct? Date: Mon, 19 Feb 2001 16:33:02 +0300 Organization: NTUU "KPI" Message-ID: <96rash$1m1d$1@igloo.uran.net.ua> References: X-Trace: igloo.uran.net.ua 982593233 55341 10.18.54.109 (19 Feb 2001 14:33:53 GMT) X-Complaints-To: newsmaster@news.ntu-kpi.kiev.ua X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG So, if I send problem report with my patches, I should inherit usage of staticaly allocated buffers. Am I right? milunovic wrote in message news:Pine.BSF.4.21.0102171202110.400-100000@scorpion.cosmos.all.net... > -----BEGIN PGP SIGNED MESSAGE----- > > On Fri, 16 Feb 2001, Andrey Simonenko wrote: > > > I patched some library files and noted that some functions, which parse some > > configuration files, use staticaly allocated buffers. Sizes of such > > staticaly allocated buffers are 8k, 10k and so on. These buffers are used to > > hold one line from parsed file. Usually it is enough for one line, but > > really this is error (I think). > > Well since config files can be only changed by root,I don't think that > root will use too long lines to case heap overflow.So this isn't big > problem. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 7:59: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from icon.bg (icon-bg.net [62.176.80.58]) by hub.freebsd.org (Postfix) with SMTP id 82FAF37B491 for ; Mon, 19 Feb 2001 07:58:51 -0800 (PST) Received: (qmail 86754 invoked by uid 1144); 19 Feb 2001 16:00:28 -0000 Date: Mon, 19 Feb 2001 18:00:28 +0200 From: Victor Ivanov To: freebsd-hackers@freebsd.org Subject: isa/pnp modem not in sio.c Message-ID: <20010219180028.A86601@icon.icon.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, A friend of mine has internal modem which is not detected autmagically by sio.c. It is V.34 ISA modem which behaves like a serial port. It is a 4.x system. Pnpinfo returns: Vendor ID GVC1601 (0x0116c31e), Serial Number 0x00000001 Device Description: Rockwell V.34 Plug & Play Modem I found a device list in sio.c and adding {0x0116c31e, NULL} to this list solves the problem (the device is detected and the modem is working just fine). The question is: do we need to do this every time after cvsup or there is an easier way to detect the modem at boot time (something in /boot)? --=20 Players win and Winners play Have a lucky day --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQCVAwUBOpFC+PD9M5lef5W3AQH4XQP9HGNC87ebial2L/rvb2fnjehSbhR+ymci SRqcuB90+dmZiuTk/yhK+fKDt5bmQcmq0v/UC6gzYWgRN1TscviDvOROIpcufveQ /c6SOtk7saFk5FoTnW/1pL5hA8owPSs+AwPowl7MSdom9Q3WqjiAVMxkk/HM4g4Y KL6uS0ASr/s= =SJ79 -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 8:23:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id BCD9D37B503 for ; Mon, 19 Feb 2001 08:23:32 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14UtFl-0000Xo-00; Mon, 19 Feb 2001 09:33:33 -0700 Message-ID: <3A914ADD.AF1B6714@softweyr.com> Date: Mon, 19 Feb 2001 09:33:33 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Victor Ivanov Cc: freebsd-hackers@freebsd.org Subject: Re: isa/pnp modem not in sio.c References: <20010219180028.A86601@icon.icon.bg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Victor Ivanov wrote: > > Hello, > > A friend of mine has internal modem which is not detected autmagically by > sio.c. It is V.34 ISA modem which behaves like a serial port. > > It is a 4.x system. > > Pnpinfo returns: > Vendor ID GVC1601 (0x0116c31e), Serial Number 0x00000001 > Device Description: Rockwell V.34 Plug & Play Modem > > I found a device list in sio.c and adding {0x0116c31e, NULL} to this list > solves the problem (the device is detected and the modem is working just > fine). > > The question is: do we need to do this every time after cvsup or there is an > easier way to detect the modem at boot time (something in /boot)? Submit a PR with a patch (diff -c sio.c.orig sio.c) so someone can commit it to the source. Then send me the PR number and I'll go commit it for you. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 8:57:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from out.newmail.net (out.newmail.net [212.150.54.158]) by hub.freebsd.org (Postfix) with SMTP id 59A5E37B491 for ; Mon, 19 Feb 2001 08:57:07 -0800 (PST) Received: from newmail.net ([10.10.1.75]) by out.newmail.net ; Mon, 19 Feb 2001 14:30:44 +0200 From: idobarnea@NewMail.Net Reply-To: idobarnea@NewMail.Net To: hackers@freebsd.org Cc: andrew@cnsec.co.za Date: Mon, 19 Feb 2001 14:25:50 Gmt +0200 Subject: Bug in creating ICMP error messages in FreeBSD4.2 Message-id: <3a912cee.150.0@NewMail.Net> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I encountered the following problem in the 4.2 version. In ip_forward, the following lines intend to save the mbuf in case we want to send ICMP error later: mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); if (mcopy && (mcopy->m_flags & M_EXT)) m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); Later on, before sending the ICMP packet we do: if (mcopy->m_flags & M_EXT) m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); The problem as I understand it is that the m_copydata and m_copyback, actually do nothing (It just copies from mcopy to itself). When bombing the kernel with lots (enough to make it issue an ICMP error) of ip packets with length 256 (which is 1 if reversing the byte order), the icmp_error function causes mbuf memory corruption, and later a kernel panic. I believe this caused the problem reported by Andrew Alston in this mailing list on 12.6.2000. I suggest adding a variable: struct ip save_ip_head; Replacing the m_copydata line with: m_copydata(mcopy, 0, sizeof(struct ip), &save_ip_head); And the same with the m_copyback line. Ido Barnea _________________________________________ Get Your Free Virus Protection Tool at http://www.VCatch.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 9:17:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id C6E0A37B491 for ; Mon, 19 Feb 2001 09:17:13 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1JHH2r59529; Mon, 19 Feb 2001 09:17:02 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102191717.f1JHH2r59529@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Wes Peters Cc: Victor Ivanov , freebsd-hackers@FreeBSD.ORG Subject: Re: isa/pnp modem not in sio.c In-Reply-To: <3A914ADD.AF1B6714@softweyr.com> Date: Mon, 19 Feb 2001 09:17:02 -0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > Victor Ivanov wrote: > > > > Hello, > > > > A friend of mine has internal modem which is not detected autmagically by > > sio.c. It is V.34 ISA modem which behaves like a serial port. > > > > It is a 4.x system. > > > > Pnpinfo returns: > > Vendor ID GVC1601 (0x0116c31e), Serial Number 0x00000001 > > Device Description: Rockwell V.34 Plug & Play Modem > > > > I found a device list in sio.c and adding {0x0116c31e, NULL} to this list > > solves the problem (the device is detected and the modem is working just > > fine). > > > > The question is: do we need to do this every time after cvsup or there is a n > > easier way to detect the modem at boot time (something in /boot)? > > Submit a PR with a patch (diff -c sio.c.orig sio.c) so someone can commit > it to the source. Then send me the PR number and I'll go commit it for > you. ;^) Actually, we want the device logical id, not the card vendor id. There can be more than one logical device per card. I constantly wonder why on earth the !#%$!^%!# modem vendors dont use the 'compatid' field to say 'this is compatable with a COM port' - and everything would work nicely. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 9:23:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1063637B401 for ; Mon, 19 Feb 2001 09:23:51 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1JHNII37074; Mon, 19 Feb 2001 09:23:18 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Feb 2001 09:23:18 -0800 (PST) From: Matt Dillon Message-Id: <200102191723.f1JHNII37074@earth.backplane.com> To: "Andrey Simonenko" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Staticaly allocated buffers in library. Is it correct? References: <96rash$1m1d$1@igloo.uran.net.ua> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :So, if I send problem report with my patches, I should inherit usage of :staticaly allocated buffers. :Am I right? : :milunovic wrote in message :news:Pine.BSF.4.21.0102171202110.400-100000@scorpion.cosmos.all.net... :> -----BEGIN PGP SIGNED MESSAGE----- :> :> On Fri, 16 Feb 2001, Andrey Simonenko wrote: :> :> > I patched some library files and noted that some functions, which parse :some :> > configuration files, use staticaly allocated buffers. Sizes of such :> > staticaly allocated buffers are 8k, 10k and so on. These buffers are :used to :> > hold one line from parsed file. Usually it is enough for one line, but :... Yes. System libraries traditionally use statically allocated buffers because, even now, there is no dynamic equivalent for fgets(). The closest you can get is to mmap() the file and extract the lines that way. But as long as the buffer sizes are reasonable and the library uses fgets() with the proper length limitation, using a statically allocated buffer is not a big deal. Most configuration files couldn't have long lines and still be legal anyway. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 10:45:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from num1sun.intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (Postfix) with ESMTP id 77B5737B4EC for ; Mon, 19 Feb 2001 10:45:40 -0800 (PST) Received: (from robin@localhost) by num1sun.intercore.com (8.11.2/8.11.2) id f1JIeiu08382 for freebsd-hackers@freebsd.org; Mon, 19 Feb 2001 13:40:44 -0500 (EST) Date: Mon, 19 Feb 2001 13:40:43 -0500 From: Robin Cutshaw To: freebsd-hackers@freebsd.org Subject: Build timings - FreeBSD 4.2 vs. Linux Message-ID: <20010219134043.A8347@intercore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We just got a couple of Compaq 8500 quad Xeon PIII 700 boxes as daily build servers for the XFree86 tree. I loaded SuSE Linux 7.0 on one box and FreeBSD 4.2-RELEASE on the other. I was surprised to see the large difference in build times. The Linux box compiled in 1 hour and 4 minutes. The FreeBSD box built in 2 hours and 50 minutes. I did stock builds with no parallelization turned on for either. Any ideas as to why it would take almost three times longer to build on FreeBSD? I'm sure that there are several things that can be done to make this faster (like do parallel builds) but I wanted to get the stock behaviour close before doing the parallel work. Thanks, Robin -- ---- Robin Cutshaw internet: robin@XFree86.Org Internet Labs, Inc. BellNet: 404-713-4000 XFree86 coreteam/board member "Time is just one damn thing after another" -- PBS/Nova ---- -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 10:54:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 925E237B4EC for ; Mon, 19 Feb 2001 10:54:17 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id TAA29316; Mon, 19 Feb 2001 19:54:07 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Robin Cutshaw Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux References: <20010219134043.A8347@intercore.com> From: Dag-Erling Smorgrav Date: 19 Feb 2001 19:54:06 +0100 In-Reply-To: Robin Cutshaw's message of "Mon, 19 Feb 2001 13:40:43 -0500" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robin Cutshaw writes: > Any ideas as to why it would take almost three times longer to build > on FreeBSD? Yup: 4.x sucks at SMP. Try the comparison again with uniprocessor kernels - I expect you'll see a much smaller difference. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 11: 3:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 61B3637B491 for ; Mon, 19 Feb 2001 11:03:18 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1JJ31h98936; Mon, 19 Feb 2001 14:03:02 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 19 Feb 2001 14:03:01 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Robin Cutshaw Cc: freebsd-hackers@freebsd.org Subject: Re: Build timings - FreeBSD 4.2 vs. Linux In-Reply-To: <20010219134043.A8347@intercore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG HAve you turned on soft updates on your object and target file systems? Synchronous file system events can have a large impact on complex compiles; using -pipe can mitigate the effect fairly significantly. If you want to compare Linux and FreeBSD with more similar file system semantics, remount your file systems on FreeBSD using the async flag, and compare the results. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Mon, 19 Feb 2001, Robin Cutshaw wrote: > > We just got a couple of Compaq 8500 quad Xeon PIII 700 boxes as daily > build servers for the XFree86 tree. I loaded SuSE Linux 7.0 on one > box and FreeBSD 4.2-RELEASE on the other. I was surprised to see the > large difference in build times. The Linux box compiled in 1 hour and > 4 minutes. The FreeBSD box built in 2 hours and 50 minutes. I did > stock builds with no parallelization turned on for either. > > Any ideas as to why it would take almost three times longer to build > on FreeBSD? > > I'm sure that there are several things that can be done to make this > faster (like do parallel builds) but I wanted to get the stock behaviour > close before doing the parallel work. > > Thanks, > Robin > -- > ---- > Robin Cutshaw internet: robin@XFree86.Org > Internet Labs, Inc. BellNet: 404-713-4000 > XFree86 coreteam/board member > > "Time is just one damn thing after another" -- PBS/Nova > ---- > -- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 11: 7:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by hub.freebsd.org (Postfix) with SMTP id CBB8D37B491 for ; Mon, 19 Feb 2001 11:07:29 -0800 (PST) Received: (qmail 21064 invoked from network); 19 Feb 2001 19:07:25 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 19 Feb 2001 19:07:25 -0000 Received: (qmail 12153 invoked from network); 19 Feb 2001 19:07:23 -0000 Received: from explorer.rsa.com (10.81.217.59) by spirit.dynas.se with SMTP; 19 Feb 2001 19:07:23 -0000 Received: (from mikko@localhost) by explorer.rsa.com (8.11.1/8.11.1) id f1JJ7KU66271; Mon, 19 Feb 2001 11:07:20 -0800 (PST) (envelope-from mikko) Date: Mon, 19 Feb 2001 11:07:20 -0800 (PST) From: Mikko Tyolajarvi Message-Id: <200102191907.f1JJ7KU66271@explorer.rsa.com> To: dillon@earth.backplane.com Cc: hackers@freebsd.org Subject: Re: Staticaly allocated buffers in library. Is it correct? Newsgroups: local.freebsd.hackers References: <200102191723.f1JHNII37074@earth.backplane.com> X-Newsreader: NN version 6.5.6 (NOV) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In local.freebsd.hackers you write: >: >:So, if I send problem report with my patches, I should inherit usage of >:staticaly allocated buffers. >:Am I right? >: >:milunovic wrote in message >:news:Pine.BSF.4.21.0102171202110.400-100000@scorpion.cosmos.all.net... >:> -----BEGIN PGP SIGNED MESSAGE----- >:> >:> On Fri, 16 Feb 2001, Andrey Simonenko wrote: >:> >:> > I patched some library files and noted that some functions, which parse >:some >:> > configuration files, use staticaly allocated buffers. Sizes of such >:> > staticaly allocated buffers are 8k, 10k and so on. These buffers are >:used to >:> > hold one line from parsed file. Usually it is enough for one line, but >:... > Yes. System libraries traditionally use statically allocated buffers > because, even now, there is no dynamic equivalent for fgets(). The > closest you can get is to mmap() the file and extract the lines that > way. How about fgetln(3)? /Mikko -- Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 11:14: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id B18E437B67D for ; Mon, 19 Feb 2001 11:13:57 -0800 (PST) Received: by smtp.nettoll.com; Mon, 19 Feb 2001 20:10:17 +0100 (MET) Message-Id: <4.3.0.20010219200743.054eae40@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 19 Feb 2001 20:12:11 +0100 To: Matt Dillon , "Andrey Simonenko" From: mouss Subject: Re: Staticaly allocated buffers in library. Is it correct? Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <200102191723.f1JHNII37074@earth.backplane.com> References: <96rash$1m1d$1@igloo.uran.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Matt, At 09:23 19/02/01 -0800, Matt Dillon wrote: > Yes. System libraries traditionally use statically allocated buffers > because, even now, there is no dynamic equivalent for fgets(). The > closest you can get is to mmap() the file and extract the lines that > way. > > But as long as the buffer sizes are reasonable and the library uses > fgets() with the proper length limitation, using a statically allocated > buffer is not a big deal. Most configuration files couldn't have long > lines and still be legal anyway. Note that the classical loop while (fgets(buf, n, fp) != NULL) { tokenize(buf, args...); ... } may have problems if the line is too long, so one needs to detect it by looking for the '\n'. if none is found, then one can either abort on error or ignore the line. In the latter case, you need to read the remaining chars so that the next fgets won't get them. regards, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 11:26:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 2A94537B401 for ; Mon, 19 Feb 2001 11:26:34 -0800 (PST) Received: by smtp.nettoll.com; Mon, 19 Feb 2001 20:25:02 +0100 (MET) Message-Id: <4.3.0.20010219202101.05cf15a0@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 19 Feb 2001 20:26:56 +0100 To: idobarnea@NewMail.Net, hackers@freebsd.org From: mouss Subject: Re: Bug in creating ICMP error messages in FreeBSD4.2 Cc: andrew@cnsec.co.za In-Reply-To: <3a912cee.150.0@NewMail.Net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 14:25 19/02/01 +0200, idobarnea@NewMail.Net wrote: >Hi, > I encountered the following problem in the 4.2 version. >In ip_forward, the following lines intend to save the mbuf in case we want to >send ICMP error later: > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); > if (mcopy && (mcopy->m_flags & M_EXT)) > m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); > >Later on, before sending the ICMP packet we do: > if (mcopy->m_flags & M_EXT) > m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); > >The problem as I understand it is that the m_copydata and m_copyback, actually >do nothing (It just >copies from mcopy to itself). I'm speaking from memory, so don't take this for more than it is:) As far as I understand: m_copym copies the mbuf, but if there is external storage, only pointers are copied. so you get two mbuf chains with a common external storage. m_copydata will copy the external storage. that's why there are both m_copym and m_copydata. so while m_copydata(mcopy, .... (mcopy...)) is surprising, it's not nothing. it copies the data pointed to in mcopy. cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 11:42:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by hub.freebsd.org (Postfix) with ESMTP id CA32137B401 for ; Mon, 19 Feb 2001 11:42:40 -0800 (PST) Received: from spock.ncc-1701.surfnet.nl ([192.87.111.34]) by survis.surfnet.nl with ESMTP (exPP) id 14UwCV-0002lk-00; Mon, 19 Feb 2001 20:42:24 +0100 Date: Mon, 19 Feb 2001 20:42:21 +0100 (CET) From: X-X-Sender: To: Panagiotis Astithas Cc: Julian Elischer , , Mark Santcroos , Alexander Langer Subject: Re: IrDA and FreeBSD In-Reply-To: <20010216000048.A4168@netmode.ece.ntua.gr> Message-ID: Organisation: SURFnet bv Address: "Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL" Phone: +31 302 305 305 Telefax: +31 302 305 329 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Panagiotis Astithas wrote: > I have also finished porting the findchip utility. You can find it > attached. It works fine(*) on my -stable machine, but I would like > someone to try it out on a -current box, just to be sure. It runs on current: Found SMC FDC37N958FR Controller at 0x3f0, DevID=0x01, Rev. 1 SIR Base 0x3e8, FIR Base 0x290 IRQ = 4, DMA = 3 Enabled: yes, Suspended: no UART compatible: yes Half duplex delay = 3 us This is a Dell Latitude CPi D266XT. If there is any more code to be tested please let me know. rvdp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 12:21:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id AA6A737B491 for ; Mon, 19 Feb 2001 12:21:34 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1JKLQr61572; Mon, 19 Feb 2001 12:21:27 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102192021.f1JKLQr61572@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robin Cutshaw Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux In-Reply-To: <20010219134043.A8347@intercore.com> Date: Mon, 19 Feb 2001 12:21:26 -0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robin Cutshaw wrote: > > We just got a couple of Compaq 8500 quad Xeon PIII 700 boxes as daily > build servers for the XFree86 tree. I loaded SuSE Linux 7.0 on one > box and FreeBSD 4.2-RELEASE on the other. I was surprised to see the > large difference in build times. The Linux box compiled in 1 hour and > 4 minutes. The FreeBSD box built in 2 hours and 50 minutes. I did > stock builds with no parallelization turned on for either. > > Any ideas as to why it would take almost three times longer to build > on FreeBSD? This is probably a silly question, but you did recompile the kernel for SMP, right? Have you tuned the FreeBSD kernel? It still ships with a worst-case configuration so that it runs optimally on i386 cpus. :-( Copy GENERIC to something else and remove all but 'cpu i686', rebuild and install. Also, get rid of 'sl', and 'ppp' from the kernel config as that messes up certain things (interrupt masks). Ideally, do a proper cleanup and configure it for your specific hardware (ie: remove all the other ethernet drivers, etc). > I'm sure that there are several things that can be done to make this > faster (like do parallel builds) but I wanted to get the stock behaviour > close before doing the parallel work. A couple of possibilities.. If you want to compare the two side by side, try mounting the freebsd filesystems in async mode, just like linux does by default. In particular, make sure you get /tmp, /var/tmp and wherever your build is. However, I'd recommend softupdates instead of async for longer term stability. It may not be quite as fast, but it should be pretty close to async mode. > Thanks, > Robin Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 12:44:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 3199837B4EC for ; Mon, 19 Feb 2001 12:44:32 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1JKiRT38061; Mon, 19 Feb 2001 12:44:27 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Feb 2001 12:44:27 -0800 (PST) From: Matt Dillon Message-Id: <200102192044.f1JKiRT38061@earth.backplane.com> To: Mikko Tyolajarvi Cc: hackers@freebsd.org Subject: Re: Staticaly allocated buffers in library. Is it correct? References: <200102191723.f1JHNII37074@earth.backplane.com> <200102191907.f1JJ7KU66271@explorer.rsa.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>:> > hold one line from parsed file. Usually it is enough for one line, but :>:... : :> Yes. System libraries traditionally use statically allocated buffers :> because, even now, there is no dynamic equivalent for fgets(). The :> closest you can get is to mmap() the file and extract the lines that :> way. : :How about fgetln(3)? : : /Mikko :-- : Mikko Työläjärvi_______________________________________mikko@rsasecurity.com Sure, if all you want to do is compile your program on a *BSD box. But fgetln() is a stupid function... it doesn't return a nul-terminated string, for example. It's a bad hack. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 12:47: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id EED8237B65D for ; Mon, 19 Feb 2001 12:46:58 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1JKkl738082; Mon, 19 Feb 2001 12:46:47 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Feb 2001 12:46:47 -0800 (PST) From: Matt Dillon Message-Id: <200102192046.f1JKkl738082@earth.backplane.com> To: mouss Cc: "Andrey Simonenko" , freebsd-hackers@FreeBSD.ORG Subject: Re: Staticaly allocated buffers in library. Is it correct? References: <96rash$1m1d$1@igloo.uran.net.ua> <4.3.0.20010219200743.054eae40@pop.free.fr> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> fgets() with the proper length limitation, using a statically allocated :> buffer is not a big deal. Most configuration files couldn't have long :> lines and still be legal anyway. : :Note that the classical loop : while (fgets(buf, n, fp) != NULL) { : tokenize(buf, args...); : ... : } :may have problems if the line is too long, so one needs to detect it by :looking for the '\n'. if none is found, then one can either abort on error :or ignore the line. In the latter case, you need to read the remaining chars :so that the next fgets won't get them. : :regards, :mouss Yes, but we are talking about simple stupid config files here. Programs which actually tokenize an input stream typically do not use fgets(). Tokenizers either use [f]lex, [f]getc(), read() (and handle the buffering themselves), or mmap(). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 13: 5:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id D592137B491 for ; Mon, 19 Feb 2001 13:05:27 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1JL50H18836; Mon, 19 Feb 2001 13:05:00 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Dag-Erling Smorgrav Cc: Robin Cutshaw , freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux In-Reply-To: Message from Dag-Erling Smorgrav of "19 Feb 2001 19:54:06 +0100." Date: Mon, 19 Feb 2001 13:04:59 -0800 Message-ID: <18832.982616699@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Yup: 4.x sucks at SMP. Try the comparison again with uniprocessor > kernels - I expect you'll see a much smaller difference. I rather doubt that SMP has anything whatsoever to do with this. 4.x's SMP implementation may be far from optimal, but I've done a lot of my own uniprocessor vs 2 vs 4 CPU configurations and I've never seen anything as bad as what Robin is describing here. I'm more suspicious of differences in the filesystem mount options. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 13:12:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ambrisko.com (adsl-216-103-208-74.dsl.snfc21.pacbell.net [216.103.208.74]) by hub.freebsd.org (Postfix) with ESMTP id 9820537B491 for ; Mon, 19 Feb 2001 13:12:13 -0800 (PST) Received: (from ambrisko@localhost) by ambrisko.com (8.11.2/8.11.1) id f1JLBwQ40203; Mon, 19 Feb 2001 13:11:58 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200102192111.f1JLBwQ40203@ambrisko.com> Subject: Re: boot1 changes and etherboot support In-Reply-To: <200102181825.f1IIPfW03495@harmony.village.org> "from Warner Losh at Feb 18, 2001 11:25:41 am" To: Warner Losh Date: Mon, 19 Feb 2001 13:11:58 -0800 (PST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: | In message <200102181812.f1IICV127887@iguana.aciri.org> Luigi Rizzo writes: | : > We'd also be able to load the kernel out of ROM :-) | : | : the whole issue is the size of the ROM isn't it ? | | Yes. I saw a few datasheets for embedded systems that have 2M or 4M | of flash. Some of that is for the BIOS, but part of it can be used | for a system image. That's a very common thin on other platforms as | well. Is this bits or bytes. The Intel firmware hub can have 4 or 8 Mbits that comes with any Intel 8XX system so with gzip you could fit a bunch of stuff in a standard off the shelf motherboard. Also CMOS memory is increasing and that could be used for some configuration info to be used as non-flash persistant storage such as IP address and such. Also having a small BIOS image like General Software would help save space. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 13:42:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D585C37B401 for ; Mon, 19 Feb 2001 13:42:19 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1JLgEh54111; Mon, 19 Feb 2001 14:42:15 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1JLfKE14156; Mon, 19 Feb 2001 14:41:20 -0700 (MST) Message-Id: <200102192141.f1JLfKE14156@billy-club.village.org> To: Doug Ambrisko Subject: Re: boot1 changes and etherboot support Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 19 Feb 2001 13:11:58 PST." <200102192111.f1JLBwQ40203@ambrisko.com> References: <200102192111.f1JLBwQ40203@ambrisko.com> Date: Mon, 19 Feb 2001 14:41:19 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102192111.f1JLBwQ40203@ambrisko.com> Doug Ambrisko writes: : Is this bits or bytes. The Intel firmware hub can have 4 or 8 Mbits that : comes with any Intel 8XX system so with gzip you could fit a bunch of : stuff in a standard off the shelf motherboard. Also CMOS memory is : increasing and that could be used for some configuration info to be : used as non-flash persistant storage such as IP address and such. Also : having a small BIOS image like General Software would help save space. Hmmm. I had assumed that it was bytes, but it may have been bits. It was an intel 8xx based design... Still, 2MBytes is enough for at least a kernel and the bare minimum to make a router... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 14: 0: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ntua.gr (achilles.noc.ntua.gr [147.102.222.210]) by hub.freebsd.org (Postfix) with ESMTP id 9D66E37B699 for ; Mon, 19 Feb 2001 13:59:58 -0800 (PST) Received: from netmode.ntua.gr (dolly.netmode.ece.ntua.gr [147.102.13.10]) by ntua.gr (8.9.3/8.9.3) with ESMTP id XAA14024; Mon, 19 Feb 2001 23:59:40 +0200 (EET) Received: (from past@localhost) by netmode.ntua.gr (8.11.1/8.11.1) id f1JM6uP30868; Tue, 20 Feb 2001 00:06:56 +0200 (EET) (envelope-from past) Date: Tue, 20 Feb 2001 00:06:55 +0200 From: Panagiotis Astithas To: Ronald.vanderPol@surfnet.nl Cc: Julian Elischer , hackers@freebsd.org, Mark Santcroos , Alexander Langer Subject: Re: IrDA and FreeBSD Message-ID: <20010220000655.A30803@netmode.ece.ntua.gr> Reply-To: past@netmode.ntua.gr References: <20010216000048.A4168@netmode.ece.ntua.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from Ronald.vanderPol@surfnet.nl on Mon, Feb 19, 2001 at 08:42:21PM +0100 X-Organizational-Unit: Network Management and Optimal Design Laboratory X-Organization: National Technical University of Athens, GREECE X-Work-Phone: +30-1-772-1-450 X-Work-FAX: +30-1-772-1-452 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 08:42:21PM +0100, Ronald.vanderPol@surfnet.nl wrote: > On Fri, 16 Feb 2001, Panagiotis Astithas wrote: > > > I have also finished porting the findchip utility. You can find it > > attached. It works fine(*) on my -stable machine, but I would like > > someone to try it out on a -current box, just to be sure. > > It runs on current: > > Found SMC FDC37N958FR Controller at 0x3f0, DevID=0x01, Rev. 1 > SIR Base 0x3e8, FIR Base 0x290 > IRQ = 4, DMA = 3 > Enabled: yes, Suspended: no > UART compatible: yes > Half duplex delay = 3 us > > This is a Dell Latitude CPi D266XT. > > If there is any more code to be tested please let me know. > > rvdp Well, as far as the linux irda-utils port is concerned, I think we have a dead end: the rest of the utilities assume kernel support for IrDA (ioctls, special address families for sockets, etc.). When we have the first layers of the netgraph implementation I will rewrite the necessary utilities. -past To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 14:21:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by hub.freebsd.org (Postfix) with SMTP id EA59337B401 for ; Mon, 19 Feb 2001 14:21:32 -0800 (PST) Received: (qmail 15521 invoked from network); 19 Feb 2001 22:21:31 -0000 Received: from jhs.muc.de (193.149.49.84) by slarti.muc.de with SMTP; 19 Feb 2001 22:21:31 -0000 Received: (from jhs@localhost) by jhs.muc.de (8.11.0/8.11.0) id f1JMH9C16878; Mon, 19 Feb 2001 22:17:09 GMT (envelope-from jhs) Date: Mon, 19 Feb 2001 22:17:09 GMT Message-Id: <200102192217.f1JMH9C16878@jhs.muc.de> To: hackers@freebsd.org Subject: COPTFLAGS without -O in /etc/make.conf breaks kernel make From: "Julian Stacey" Organization: Vector Systems Ltd - Munich Unix & Internet consultancy X-Web: http://www.jhs.muc.de http://bim.bsn.com/~jhs/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's a weirdness in 4.2-RELEASE kernel generation: - Compiling a GENERIC kernel _Without -O optimiser causes a broken make ! - Compiling a GENERIC kernel _With_ -O optimiser compiles OK. Seems weird - perhaps indicative of a problem elsewhere in FreeBSD ? (Optimisers occasionaly break things, but don't normaly _fix_ things !) Can anyone confirm the observation / comment / explain please ? If you wonder why you haven't seen this so far: - Default 4.2 systems compile kernel with -O - I noticed it while experimentaly adding "-pipe" to make variables. How to test: Breaks: echo "COPTFLAGS= -DHalloFromMakeDotConf" >> /etc/make.conf Breaks: echo "COPTFLAGS=" >> /etc/make.conf OK: echo "COPTFLAGS= -DHalloFromMakeDotConf -O" >> /etc/make.conf OK: echo "COPTFLAGS=-O" >> /etc/make.conf OK: grep -v COPTFLAGS /etc/make.conf > /tmp/co;cp /tmp/co /etc/make.conf Followed By: cd /sys/i386/conf;config -r GENERIC cd /sys/compile/GENERIC;make depend;make atomic.o # atomic.o for faster test Breakage: cc -c -DHalloFromMakeDotConf -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I/usr/include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 -fomit-frame-pointer ../../i386/i386/atomic.c In file included from ../../i386/i386/atomic.c:47: machine/atomic.h: In function `atomic_set_char': machine/atomic.h:106: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_char': machine/atomic.h:107: inconsistent operand constraints in an `asm' - Julian Stacey Unix Consultant - Munich Germany http://bim.bsn.com/~jhs/ Like Linux ? Then also look at FreeBSD with its 4200 packages ! Ihr Rauchen => mein allergischer Kopfschmerz ! Kau/Schnupftabak probieren ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 15: 2: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dom.fc.u-tokai.ac.jp (dom.fc.u-tokai.ac.jp [150.7.244.115]) by hub.freebsd.org (Postfix) with ESMTP id A6FFE37B401 for ; Mon, 19 Feb 2001 15:02:03 -0800 (PST) Received: (from bsd-ml@localhost) by dom.fc.u-tokai.ac.jp (8.9.3/3.7Wpl2/000825) id IAA21202 for freebsd-hackers@FreeBSD.ORG; Tue, 20 Feb 2001 08:02:55 +0900 (JST) Date: Tue, 20 Feb 2001 08:02:55 +0900 (JST) From: User bsd-ml Message-Id: <200102192302.IAA21202@dom.fc.u-tokai.ac.jp> To: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG auth c0e7d351 unsubscribe freebsd-hackers bsd-ml@dom.fc.u-tokai.ac.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 15:22:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id B7AA637B491 for ; Mon, 19 Feb 2001 15:22:36 -0800 (PST) Received: (qmail 10022 invoked by uid 1000); 19 Feb 2001 23:21:58 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Feb 2001 23:21:58 -0000 Date: Mon, 19 Feb 2001 15:21:58 -0800 (PST) From: Dan Phoenix To: freebsd-hackers@FreeBSD.ORG Subject: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to set up this challenge early next week. NOw that I have taken out the IO issue with the mail servers ...already proved postfix did better on I/O so now i want to eliminate that factor to 2 exactly the same machines. I running qmail ...1 running postfix to see which MTA has better sending speed on freebsd. What I have not decided on is benchmark program to use..... test will be how many outgoing it can send a sec for each. I welcome benchmark proggies anyone can offer as a solution for this. Much appreciated. Dan +------------------------------------------------------+ | BRAVENET WEB SERVICES | | dan@bravenet.com | | make installworld | | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +______________________________________________________+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 15:51:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from parodius.com (pentarou.parodius.com [205.149.163.62]) by hub.freebsd.org (Postfix) with ESMTP id C034E37B503 for ; Mon, 19 Feb 2001 15:51:49 -0800 (PST) Received: (from dpk@localhost) by parodius.com (8.11.2/8.11.2) id f1JNpjf07812 for freebsd-hackers@freebsd.org; Mon, 19 Feb 2001 15:51:45 -0800 (PST) (envelope-from dpk) Date: Mon, 19 Feb 2001 15:51:45 -0800 From: David Kirchner To: freebsd-hackers@freebsd.org Subject: Kernel debugging woes (was Re: Quotas crashing, 4.2-RELEASE, incomplete backtrace ...) Message-ID: <20010219155145.A5320@dpk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, First, apologies if this is not the appropriate place to post this. I'm trying to hack around the kernel, but I'm running in to roadblocks with gdb. Also, I'm not on this mailing list, so please Cc: me on any replies. I was having a problem with a 4.2-RELEASE box's quotas. I compiled up a debugging kernel, rebooted, and did the file copying (see included freebsd-questions post) until I got it to crash again. Unfortunately, the core dump didn't leave any useful information for me. Do you guys know what I need to do to get the parameter info for: #6 0xc01af64a in dqget () #7 0xc01aea6e in getinoquota () #8 0xc01b0785 in ufs_chown () #9 0xc01b03bb in ufs_setattr () #10 0xc01b29e9 in ufs_vnoperate () #11 0xc0178f4b in setfown () #12 0xc0178fe4 in chown () I have the arguments to the syscall2 and trap calls before and after it. What am I missing? I'm running 'gdb -k kernel.1 vmcore.1' in /var/adm/crash, I've verified that kernel.1 is a debugging kernel (so I didn't have to load the symbols from another kernel). I am able to get it to crash, but not through any one specific command (ie I just have to try to untar files onto this box until it happens). Any ideas? - dpk > Hi, > > I'm not a list member, so please Cc: me on any responses. Thanks. > > Unfortunately I am not able to give too much information here, but I'll > give you what I've got. First, the scenario. I'm copying a bunch of files > (>4GB total, no file larger than say 200k though) from a 3.2 box to a > 4.2-RELEASE box that has quotas enabled. This had caused the system to crash > a few times so I put in a debugging kernel. > > The uname -a: > > FreeBSD xxx.xxx.xxxxxx.net 4.2-RELEASE FreeBSD 4.2-RELEASE #1: Wed Feb 14 16:23:31 PST 2001 root@xxx.xxx.xxxxxx.net:/usr/src/sys/compile/XXXXXX i386 > > Here's the kgdb backtrace. Note the lack of any information about 'dqget' > or 'getinoquota'. In fact, there was no information in any of the calls > until I entered 'symbol-file kernel.debug'. Anyways, I hope someone here > could point me in the right direction for getting information out of gdb > regarding the dqget/getinoquota calls (this would be MUCH appreciated) - > they're clearly where the problem is: > > #0 dumpsys () at ../../kern/kern_shutdown.c:469 > #1 0xc0149b53 in boot (howto=256) at ../../kern/kern_shutdown.c:309 > #2 0xc0149ee9 in panic (fmt=0xc020bacf "page fault") > at ../../kern/kern_shutdown.c:556 > #3 0xc01e205e in trap_fatal (frame=0xea4dccf8, eva=0) > at ../../i386/i386/trap.c:951 > #4 0xc01e1d11 in trap_pfault (frame=0xea4dccf8, usermode=0, eva=0) > at ../../i386/i386/trap.c:844 > #5 0xc01e18b3 in trap (frame={tf_fs = -364052464, tf_es = -364052464, > tf_ds = -1071972336, tf_edi = -366369856, tf_esi = -948627884, > tf_ebp = -363999864, tf_isp = -363999964, tf_ebx = -923190656, > tf_edx = 0, tf_ecx = -364380800, tf_eax = 0, tf_trapno = 12, tf_err = 2, > tf_eip = -1071974838, tf_cs = 8, tf_eflags = 66118, tf_esp = -915035136, > tf_ss = -339913792}) at ../../i386/i386/trap.c:443 > #6 0xc01af64a in dqget () > #7 0xc01aea6e in getinoquota () > #8 0xc01b0785 in ufs_chown () > #9 0xc01b03bb in ufs_setattr () > #10 0xc01b29e9 in ufs_vnoperate () > #11 0xc0178f4b in setfown () > #12 0xc0178fe4 in chown () > #13 0xc01e2286 in syscall2 (frame={tf_fs = 134807599, tf_es = 47, > tf_ds = -1078001617, tf_edi = 134828032, tf_esi = 115, > tf_ebp = -1077937388, tf_isp = -363999276, tf_ebx = 0, tf_edx = 3, > tf_ecx = 0, tf_eax = 16, tf_trapno = 7, tf_err = 2, tf_eip = 134605024, > tf_cs = 31, tf_eflags = 514, tf_esp = -1077937752, tf_ss = 47}) > at ../../i386/i386/trap.c:1150 > #14 0xc01d6f75 in Xint0x80_syscall () > #15 0x8050a1d in ?? () > #16 0x8052c7e in ?? () > #17 0x8048135 in ?? () > > For now I'm disabling quotas on the box, but this is a less than optimal > solution. Any thoughts? > > - dpk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 16:10:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from faithful.dizzyd.com (c396142-a.lakwod2.co.home.com [24.183.233.142]) by hub.freebsd.org (Postfix) with ESMTP id 0649D37B6BC for ; Mon, 19 Feb 2001 16:10:15 -0800 (PST) Received: by faithful.dizzyd.com (Postfix, from userid 1000) id 5BA57105F; Mon, 19 Feb 2001 17:10:15 -0700 (MST) Date: Mon, 19 Feb 2001 17:10:15 -0700 To: freebsd-hackers@freebsd.org Subject: Creating BSD bootable CD Message-ID: <20010219171015.A16412@dizzyd.com> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i From: dizzyd@dizzyd.com (Dave Smith) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings... I certainly hope I'm posting this to the right list -- if not, please redirect me accordingly. Thanks. :) I'm interested in taking FreeBSD and putting it on a bootable CD for use in a so-called "appliance". Can anyone recommend a place to start? Specifically, I'm unsure how to create a bootable anything -- so it might be good to start with instructions on how to create a bootable floppy. What files will I need in /dev? Is there a HOWTO anywhere? Thanks. Diz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 16:17:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from deborah.paradise.net.nz (deborah.paradise.net.nz [203.96.152.32]) by hub.freebsd.org (Postfix) with ESMTP id 548FA37B503 for ; Mon, 19 Feb 2001 16:17:14 -0800 (PST) Received: from duron700.afterswish.com (203-79-83-91.cable.paradise.net.nz [203.79.83.91]) by deborah.paradise.net.nz (8.10.1/8.10.1) with ESMTP id f1K0H4o10628; Tue, 20 Feb 2001 13:17:04 +1300 (NZDT) Message-Id: <5.0.2.1.1.20010220131304.02b7b660@pop3.paradise.net.nz> X-Sender: dpreece@pop3.paradise.net.nz X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 20 Feb 2001 13:16:17 +1300 To: dizzyd@dizzyd.com (Dave Smith) From: David Preece Subject: Re: Creating BSD bootable CD Cc: freebsd-hackers@freebsd.org In-Reply-To: <20010219171015.A16412@dizzyd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 17:10 19/02/2001 -0700, you wrote: >I'm interested in taking FreeBSD and putting it on a bootable CD for use in >a so-called "appliance". Can anyone recommend a place to start? I started in the handbook, the section on backups and creating a bootable floppy was invaluable. It's also worth trawling the archives of freebsd-small, in particular look for "tinybsd" which (IIRC) is a configurable script for making a small installation of FreeBSD without going to the lengths that pico goes to, crunchgen etc. This is an eminently doable problem, you have a good half dozen valid approaches that can be taken. Dave To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 16:58:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from faithful.dizzyd.com (c396142-a.lakwod2.co.home.com [24.183.233.142]) by hub.freebsd.org (Postfix) with ESMTP id B1C5837B401 for ; Mon, 19 Feb 2001 16:58:46 -0800 (PST) Received: by faithful.dizzyd.com (Postfix, from userid 1000) id 3BD91105F; Mon, 19 Feb 2001 17:58:46 -0700 (MST) Date: Mon, 19 Feb 2001 17:58:46 -0700 To: David Preece Cc: freebsd-hackers@freebsd.org Subject: Re: Creating BSD bootable CD Message-ID: <20010219175846.A16500@dizzyd.com> Mail-Followup-To: David Preece , freebsd-hackers@freebsd.org References: <20010219171015.A16412@dizzyd.com> <5.0.2.1.1.20010220131304.02b7b660@pop3.paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <5.0.2.1.1.20010220131304.02b7b660@pop3.paradise.net.nz>; from davep@afterswish.com on Tue, Feb 20, 2001 at 01:16:17PM +1300 From: dizzyd@dizzyd.com (Dave Smith) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 20, 2001 at 01:16:17PM +1300, David Preece wrote: > I started in the handbook, the section on backups and creating a bootable > floppy was invaluable. It's also worth trawling the archives of > freebsd-small, in particular look for "tinybsd" which (IIRC) is a > configurable script for making a small installation of FreeBSD without > going to the lengths that pico goes to, crunchgen etc. Thanks. I'm already investigating this stuff. One more question -- is there a list of all valid /dev nodes? Thanks again. :) Diz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 17:21: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 644FB37B67D for ; Mon, 19 Feb 2001 17:21:00 -0800 (PST) Received: (qmail 24226 invoked by uid 666); 20 Feb 2001 01:32:49 -0000 Received: from i194-066.nv.iinet.net.au (HELO a) (203.59.194.66) by mail.m.iinet.net.au with SMTP; 20 Feb 2001 01:32:49 -0000 Message-ID: <001401c09adc$54e5c1c0$4501a8c0@a> From: "Nigel Taylor" To: Subject: Cvsup and ports Date: Tue, 20 Feb 2001 09:27:46 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C09B1F.627B19A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C09B1F.627B19A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all I recently did a CVSUP on my ports because i wanted to install = enlightenment did a make install and recieved the following error. Error: your port uses an old layout. Please update it to match this = bsd.port.mk. If you have updated your ports collection via cvsup and are = still getting this error, see Q12 and Q13 in the cvsup FAQ ob = http://www.polstra.com for further information. Now i have done everything it has said, still get the same error thank you Nigel Taylor ------=_NextPart_000_0011_01C09B1F.627B19A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all
 
I recently did a CVSUP on my ports = because i wanted=20 to install enlightenment did a make install and recieved the following=20 error.
 
Error: your port uses an old layout. = Please update=20 it to match this bsd.port.mk. If you have updated your ports collection = via=20 cvsup and are still getting this error, see Q12 and Q13 in the cvsup FAQ = ob http://www.polstra.com for further=20 information.
 
Now i have done everything it has said, = still get=20 the same error
 
thank you
 
Nigel Taylor
------=_NextPart_000_0011_01C09B1F.627B19A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 20:27:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id 3C4A037B401 for ; Mon, 19 Feb 2001 20:27:50 -0800 (PST) Received: (qmail 22544 invoked from network); 20 Feb 2001 04:27:48 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 20 Feb 2001 04:27:48 -0000 Received: (qmail 28055 invoked by uid 500); 20 Feb 2001 04:33:10 -0000 Date: 20 Feb 2001 04:33:10 -0000 Message-ID: <20010220043310.28054.qmail@yusufg.portal2.com> From: Yusuf Goolamabbas To: freebsd-hackers@freebsd.org Subject: Switching from buildkernel to config seems to recompile the entire kernel Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I cvsup'ed my 4.2-stable box and did the usual make buildworld make buildkernel KERNCONF= where KNAME is the name of theconfig file make installkernel KERNCONF= make installworld and then rebooted the box. A short while I modified my kernel config to remove sl and ppp. I then did a /usr/sbin/config This seems to recompile all the modules and the entire kernel even though I expected only a few things to be recompiled and the kernel relinked Or did I do something wrong Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 20:51:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by hub.freebsd.org (Postfix) with SMTP id D130D37B401 for ; Mon, 19 Feb 2001 20:51:56 -0800 (PST) Received: (qmail 47500507 invoked from network); 20 Feb 2001 04:51:54 -0000 Received: from d165.dhcp212-231.cybercable.fr (HELO gits.dyndns.org) ([212.198.231.165]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 20 Feb 2001 04:51:54 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id f1K4ppK20364; Tue, 20 Feb 2001 05:51:51 +0100 (CET) (envelope-from clefevre@poboxes.com) To: "Julian Stacey" Cc: hackers@FreeBSD.ORG Subject: Re: COPTFLAGS without -O in /etc/make.conf breaks kernel make References: <200102192217.f1JMH9C16878@jhs.muc.de> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C In-Reply-To: "Julian Stacey"'s message of "Mon, 19 Feb 2001 22:17:09 GMT" From: Cyrille Lefevre Reply-To: clefevre@poboxes.com Mail-Copies-To: never Date: 20 Feb 2001 05:51:48 +0100 Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Julian Stacey" writes: > Here's a weirdness in 4.2-RELEASE kernel generation: > - Compiling a GENERIC kernel _Without -O optimiser causes a broken make ! > - Compiling a GENERIC kernel _With_ -O optimiser compiles OK. this question is cyclic. and yes, the kernel *have* to be compiled w/ -O turned on. sorry, I don't remember why. if you want yo put something to COPTFLAGS, try something like this : # the only way I've found to see if I'm in the kernel tree or no ! IS_SYS?= ${.CURDIR:M*/sys*} # make sure COPTFLAGS contains -O for kernel builds. .if !empty(IS_SYS) COPTFLAGS= -O .endif # add your stuffs... COPTFLAGS+= -fomit-frame-pointer -fno-builtin Cyrille. -- home: mailto:clefevre@poboxes.com UNIX is user-friendly; it's just particular work: mailto:Cyrille.Lefevre@edf.fr about who it chooses to be friends with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 22: 3:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 9176537B401; Mon, 19 Feb 2001 22:03:20 -0800 (PST) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id f1K63HR35280; Tue, 20 Feb 2001 07:03:18 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.1/8.11.0) id f1K5iVo11778; Tue, 20 Feb 2001 06:44:31 +0100 (CET) (envelope-from asmodai) Date: Tue, 20 Feb 2001 06:44:30 +0100 From: Jeroen Ruigrok/Asmodai To: Nigel Taylor Cc: freebsd-hackers@freebsd.org, questions@freebsd.org Subject: Re: Cvsup and ports Message-ID: <20010220064430.B9031@daemon.ninth-circle.org> Reply-To: questions@freebsd.org References: <001401c09adc$54e5c1c0$4501a8c0@a> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001401c09adc$54e5c1c0$4501a8c0@a>; from latifa@iinet.net.au on Tue, Feb 20, 2001 at 09:27:46AM +0800 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20010220 02:30], Nigel Taylor (latifa@iinet.net.au) wrote: >I recently did a CVSUP on my ports because i wanted to install >enlightenment did a make install and recieved the following error. > >Error: your port uses an old layout. Please update it to match this >bsd.port.mk. If you have updated your ports collection via cvsup and >are still getting this error, see Q12 and Q13 in the cvsup FAQ ob >http://www.polstra.com for further information. Please ask questions like this on the freebsd-questions mailinglist. >Now i have done everything it has said, still get the same error You obviously missed to do something. :) Either: 1) make world 2) cd /usr/src/share/mk [after updating it]; make install And that should fix things. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 I'm a child of the air, I'm a witch of the wind... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 23:31: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B4BCD37B4EC for ; Mon, 19 Feb 2001 23:31:00 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f1K7SIl25543; Tue, 20 Feb 2001 09:28:18 +0200 (EET) (envelope-from ru) Date: Tue, 20 Feb 2001 09:28:18 +0200 From: Ruslan Ermilov To: mouss Cc: idobarnea@NewMail.Net, hackers@FreeBSD.ORG, andrew@cnsec.co.za Subject: Re: Bug in creating ICMP error messages in FreeBSD4.2 Message-ID: <20010220092818.A25414@sunbay.com> Mail-Followup-To: mouss , idobarnea@NewMail.Net, hackers@FreeBSD.ORG, andrew@cnsec.co.za References: <3a912cee.150.0@NewMail.Net> <4.3.0.20010219202101.05cf15a0@pop.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.0.20010219202101.05cf15a0@pop.free.fr>; from usebsd@free.fr on Mon, Feb 19, 2001 at 08:26:56PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 08:26:56PM +0100, mouss wrote: > At 14:25 19/02/01 +0200, idobarnea@NewMail.Net wrote: > >Hi, > > I encountered the following problem in the 4.2 version. > >In ip_forward, the following lines intend to save the mbuf in case we want to > >send ICMP error later: > > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); > > if (mcopy && (mcopy->m_flags & M_EXT)) > > m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); > > > >Later on, before sending the ICMP packet we do: > > if (mcopy->m_flags & M_EXT) > > m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); > > > >The problem as I understand it is that the m_copydata and m_copyback, actually > >do nothing (It just > >copies from mcopy to itself). > > I'm speaking from memory, so don't take this for more than it is:) > > As far as I understand: > m_copym copies the mbuf, but if there is external storage, only pointers > are copied. so you get two mbuf chains with a common external storage. > m_copydata will copy the external storage. > that's why there are both m_copym and m_copydata. so while > m_copydata(mcopy, .... (mcopy...)) > is surprising, it's not nothing. it copies the data pointed to in mcopy. > I wrote this code, and the above said is right. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 19 23:41:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 9375037B4EC; Mon, 19 Feb 2001 23:41:16 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 52C3E66B09; Mon, 19 Feb 2001 23:41:16 -0800 (PST) Date: Mon, 19 Feb 2001 23:41:16 -0800 From: Kris Kennaway To: questions@freebsd.org Cc: Nigel Taylor , freebsd-hackers@freebsd.org Subject: Re: Cvsup and ports Message-ID: <20010219234116.B77228@mollari.cthul.hu> References: <001401c09adc$54e5c1c0$4501a8c0@a> <20010220064430.B9031@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010220064430.B9031@daemon.ninth-circle.org>; from asmodai@wxs.nl on Tue, Feb 20, 2001 at 06:44:30AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 20, 2001 at 06:44:30AM +0100, Jeroen Ruigrok/Asmodai wrote: > -On [20010220 02:30], Nigel Taylor (latifa@iinet.net.au) wrote: > >I recently did a CVSUP on my ports because i wanted to install > >enlightenment did a make install and recieved the following error. > > > >Error: your port uses an old layout. Please update it to match this > >bsd.port.mk. If you have updated your ports collection via cvsup and > >are still getting this error, see Q12 and Q13 in the cvsup FAQ ob > >http://www.polstra.com for further information. >=20 > Please ask questions like this on the freebsd-questions mailinglist. >=20 > >Now i have done everything it has said, still get the same error >=20 > You obviously missed to do something. :) >=20 > Either: >=20 > 1) make world >=20 > 2) cd /usr/src/share/mk [after updating it]; make install >=20 > And that should fix things. Bad advice - the ports mk files aren't even in that location any more. The submitter needs to follow the directions in the error message and learn why his cvsup didn't delete some files, and how to fix it. Kris --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6kh+cWry0BWjoQKURAvpuAJsGdnn5+U0HVBWR5MMZPRSJRhq1bACghwiT /Xt18r4Q+he0JGFxbIeecLc= =LZ9J -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 1:23: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id 2736737B4EC for ; Tue, 20 Feb 2001 01:23:00 -0800 (PST) (envelope-from gordont@bluemtn.net) Received: (qmail 17728 invoked by uid 1078); 20 Feb 2001 09:22:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Feb 2001 09:22:57 -0000 Date: Tue, 20 Feb 2001 01:22:57 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Dan Phoenix Cc: Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My company (online greeting cards) sent our 4 million emails in 4 hours using a cluster of about 30 mailers with qmail on FreeBSD (old version of FreeBSD at that). That averages to 16,666 mail messages per minute or about 500 per minute per server. The best part was the servers weren't breaking a sweat. Again as with all benchmarks you are talking about, there are lots of other factors then just "How fast does it push the mail." For what we do, qmail is a great solution. I've personally never looked at postfix, but I understand it to be a great MTA as well. I think in the end, you will find that both are very similar and that it's just a matter of personal preference. That being said, I'll be interested to see what the numbers come out to be. -gordon On Mon, 19 Feb 2001, Dan Phoenix wrote: > I would like to set up this challenge early next week. > NOw that I have taken out the IO issue with the mail servers > ...already proved postfix did better on I/O so now i want to eliminate > that factor to 2 exactly the same machines. I running qmail ...1 running > postfix to see which MTA has better sending speed on freebsd. > > What I have not decided on is benchmark program to use..... > test will be how many outgoing it can send a sec for each. > I welcome benchmark proggies anyone can offer as a solution for this. > Much appreciated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 1:55:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 3E63637B401 for ; Tue, 20 Feb 2001 01:55:57 -0800 (PST) (envelope-from K.J.Koster@kpn.com) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01K0BX0W7ASO000CTI@research.kpn.com> for freebsd-hackers@FreeBSD.ORG; Tue, 20 Feb 2001 10:55:52 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Feb 2001 10:55:52 +0100 Content-return: allowed Date: Tue, 20 Feb 2001 10:55:51 +0100 From: "Koster, K.J." Subject: RE: isa/pnp modem not in sio.c To: 'Peter Wemm' Cc: freebsd-hackers@FreeBSD.ORG Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7C3E@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I constantly wonder why on earth the !#%$!^%!# modem vendors > dont use the > 'compatid' field to say 'this is compatable with a COM port' - and > everything would work nicely. > Because the drivers and the fluff they come with are rather excellent advertising platforms. Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 3:54:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netcetera.ch (netcetera-139.netcetera.ch [193.192.248.139]) by hub.freebsd.org (Postfix) with ESMTP id 857EF37B401 for ; Tue, 20 Feb 2001 03:54:12 -0800 (PST) (envelope-from jason@netcetera.ch) Received: from disco.netcetera.ch (disco [193.192.248.144]) by (8.9.3/8.7.3) with ESMTP id MAA20449 for ; Tue, 20 Feb 2001 12:54:10 +0100 (MET) From: Jason Brazile Received: by disco.netcetera.ch (8.9.3) id MAA00515; Tue, 20 Feb 2001 12:54:09 +0100 (MET) Date: Tue, 20 Feb 2001 12:54:09 +0100 (MET) Message-Id: <200102201154.MAA00515@disco.netcetera.ch> To: freebsd-hackers@freebsd.org Subject: make bug? (dependency names with '$') Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Background: I want to construct a portable Makefile to build a java application. When a java source file contains an inner class, it creates class file names with an embedded '$'. $ cat foo.java public class foo { private class bar { } } $ javac foo.java $ ls foo$bar.class foo.class foo.java Problem: - BSD make seems to have trouble with dependencies whose names contain $. - I can construct a case where GNU make is happy enough, but BSD make isn't. Test Case: $ cat Makefile X=foo$bar.class XX=foo$$bar.class XXX=foo\$$bar.class .PHONY: x xx xxx yy x: $(X) echo $(X) xx: $(XX) echo $(XX) xxx: $(XXX) echo $(XXX) yy: $(XX) echo $(XXX) # LATEST BSD make (e.g. main.c at revision 1.46 2001/02/19 03:59:04) $ make x make: don't know how to make fooar.class. Stop $ make xx make: don't know how to make fooar.class. Stop $ make xxx make: don't know how to make foo\ar.class. Stop $ make yy make: don't know how to make fooar.class. Stop # package: gmake-3.79.1 GNU version of 'make' utility $ gmake x gmake: *** No rule to make target `fooar.class', needed by `x'. Stop. $ gmake xx echo foo$bar.class foo.class $ gmake xxx gmake: *** No rule to make target `foo\$bar.class', needed by `xxx'. Stop. $ gmake yy echo foo\$bar.class foo$bar.class Conclusion: I could live with having to use something like the "yy" target if it worked with BSD make, because it works with GNU make. If people agree that this seems like a bug, I will try to see if I can find where the problem is, but there are probably others who would be more efficient at this. Jason ------------------------------------------------------------------------ Jason Brazile jason.brazile@netcetera.ch Netcetera AG, 8040 Zuerich phone +41 1 247 70 70 fax +41 1 247 70 75 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 6:11:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 1C3A937B491 for ; Tue, 20 Feb 2001 06:11:19 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Tue, 20 Feb 2001 15:08:39 +0100 (MET) Message-Id: <4.3.0.20010220150656.060411a0@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Feb 2001 15:10:41 +0100 To: Matt Dillon From: mouss Subject: Re: Staticaly allocated buffers in library. Is it correct? Cc: "Andrey Simonenko" , freebsd-hackers@FreeBSD.ORG In-Reply-To: <200102192046.f1JKkl738082@earth.backplane.com> References: <96rash$1m1d$1@igloo.uran.net.ua> <4.3.0.20010219200743.054eae40@pop.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:46 19/02/01 -0800, Matt Dillon wrote: > Yes, but we are talking about simple stupid config files here. Programs > which actually tokenize an input stream typically do not use fgets(). > Tokenizers either use [f]lex, [f]getc(), read() (and handle the buffering > themselves), or mmap(). I used the tokenize() just as an example. I consider that every program that reads a line thinks it is a line and that the next fgets will read the _next_ line. but fgets doesn't guarantee that. so we have the following alternatives: - assume the file is well formed (no too long lines). - check that the lines are not too long. I personally prefer the second alternative. It has a cost, but this is more robust. How many times have we seen things assumed for some time, and then the code reused by someone else in another purpose but failing to check that the assumptions are no more true. This has often resulted in security problems. So I'd go for "trust BUT control". and this is even more important in library functions. cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 6:31:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id EE6C137B491 for ; Tue, 20 Feb 2001 06:31:16 -0800 (PST) (envelope-from LConrad@Go2France.com) Received: from sv.Go2France.com (sv.meiway.com [212.73.210.79]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id C2F7816B11 for ; Tue, 20 Feb 2001 15:42:14 +0100 (CET) Message-Id: <5.0.0.25.0.20010220140218.02df9c10@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 20 Feb 2001 15:28:32 +0100 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: postfix: No buffer space available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry to bother you hackers again, but two submissions to -questions got no response so it looks like another scaleability issue on you people can handle : ================ On a very busy postfix relay hub, we're seeing this: Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer space available Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer space available Can we fix this with a systcl write? The server already has: # sysctl -a | grep maxfile kern.maxfiles: 16384 kern.maxfilesperproc: 16384 ... which fixed "fatal: too many files open" pb for this client last November. btw, Wietse Venema himself asked me to be informed of how I manage to tweak FreeBSD to handle this apparent scaleability issue. "sysctl -a" gives: kern.ostype: FreeBSD kern.osrelease: 4.1.1-RELEASE kern.osrevision: 199506 kern.version: FreeBSD 4.1.1-RELEASE #0: Tue Sep 26 00:46:59 GMT 2000 jkh@narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC kern.maxvnodes: 32525 kern.maxproc: 532 kern.maxfiles: 16384 kern.argmax: 65536 kern.securelevel: -1 kern.hostname: imgate2.snip.net kern.hostid: 0 kern.clockrate: { hz = 100, tick = 10000, tickadj = 5, profhz = 1024, stathz = 128 } kern.posix1version: 199309 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 982608649, usec = 136401 } Mon Feb 19 13:50:49 2001 kern.domainname: kern.osreldate: 411000 kern.bootfile: /kernel kern.maxfilesperproc: 16384 kern.maxprocperuid: 531 kern.dumpdev: kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 136 kern.ipc.nmbclusters: 1024 kern.ipc.semmap: 30 kern.ipc.semmni: 10 kern.ipc.semmns: 60 kern.ipc.semmnu: 30 kern.ipc.semmsl: 60 kern.ipc.semopm: 100 kern.ipc.semume: 10 kern.ipc.semusz: 92 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 kern.ipc.shmmax: 4194304 kern.ipc.shmmin: 1 kern.ipc.shmmni: 96 kern.ipc.shmseg: 64 kern.ipc.shmall: 1024 kern.ipc.shm_use_phys: 0 kern.ipc.mbuf_wait: 32 kern.ipc.mbtypes: 460 164 160 0 0 0 0 0 0 0 0 0 0 0 0 0 kern.ipc.nmbufs: 4096 kern.ipc.maxsockets: 1064 kern.dummy: 0 kern.ps_strings: 3217031152 kern.usrstack: 3217031168 kern.logsigexit: 1 kern.cam.cd.changer.min_busy_seconds: 5 kern.cam.cd.changer.max_busy_seconds: 15 kern.fallback_elf_brand: 9 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall kern.module_path: /;/boot/;/modules/ kern.acct_suspend: 2 kern.acct_resume: 4 kern.acct_chkfreq: 15 kern.timecounter.method: 0 kern.timecounter.hardware: i8254 kern.ps_arg_cache_limit: 256 kern.ps_argsopen: 1 kern.fast_vfork: 1 kern.randompid: 0 kern.ps_showallprocs: 1 kern.shutdown.poweroff_delay: 5000 kern.shutdown.kproc_shutdown_wait: 60 kern.sugid_coredump: 0 kern.coredump: 1 kern.corefile: %N.core kern.quantum: 100000 kern.ccpu: 1948 kern.fscale: 2048 kern.devstat.numdevs: 7 kern.devstat.generation: 7 kern.devstat.version: 4 kern.nselcoll: 60034 kern.consmute: 0 kern.filedelay: 30 kern.dirdelay: 29 kern.metadelay: 28 kern.chroot_allow_open_directories: 1 vm.loadavg: { 0.39 0.43 0.52 } vm.v_free_min: 886 vm.v_free_target: 2906 vm.v_free_reserved: 248 vm.v_inactive_target: 4359 vm.v_cache_min: 2906 vm.v_cache_max: 5812 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.swap_async_max: 4 vm.swap_idle_threshold1: 2 vm.swap_idle_threshold2: 10 vm.v_free_severe: 567 vm.stats.sys.v_swtch: 15651300 vm.stats.sys.v_trap: 1045137 vm.stats.sys.v_syscall: 53830549 vm.stats.sys.v_intr: 19460810 vm.stats.sys.v_soft: 3519936 vm.stats.vm.v_vm_faults: 610808 vm.stats.vm.v_cow_faults: 138115 vm.stats.vm.v_cow_optim: 0 vm.stats.vm.v_zfod: 310288 vm.stats.vm.v_ozfod: 309994 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_vnodein: 374 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodepgsin: 2490 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_intrans: 2 vm.stats.vm.v_reactivated: 125 vm.stats.vm.v_pdwakeups: 0 vm.stats.vm.v_pdpages: 0 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_pfree: 355480 vm.stats.vm.v_tfree: 809980 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_page_count: 127974 vm.stats.vm.v_free_reserved: 248 vm.stats.vm.v_free_target: 2906 vm.stats.vm.v_free_min: 886 vm.stats.vm.v_free_count: 97173 vm.stats.vm.v_wire_count: 8879 vm.stats.vm.v_active_count: 11659 vm.stats.vm.v_inactive_target: 4359 vm.stats.vm.v_inactive_count: 10259 vm.stats.vm.v_cache_count: 4 vm.stats.vm.v_cache_min: 2906 vm.stats.vm.v_cache_max: 5812 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.misc.zero_page_count: 70388 vm.stats.misc.cnt_prezero: 376460 vm.max_proc_mmap: 36401 vm.pageout_stats_max: 2906 vm.pageout_full_stats_interval: 20 vm.pageout_stats_interval: 5 vm.pageout_stats_free_max: 5 vm.swap_idle_enabled: 0 vm.defer_swapspace_pageouts: 0 vm.disable_swapspace_pageouts: 0 vm.max_page_launder: 32 vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS PIPE: 160, 0, 36, 66, 1232 SWAPMETA: 160, 255948, 0, 0, 0 tcpcb: 544, 1064, 135, 173, 116705 unpcb: 64, 0, 406, 490, 334655 ripcb: 192, 1064, 0, 42, 2 tcpcb: 544, 1064, 0, 0, 0 udpcb: 192, 1064, 15, 69, 518065 socket: 192, 1064, 556, 494, 969428 KNOTE: 64, 0, 13, 115, 515373 NFSNODE: 320, 0, 0, 0, 0 NFSMOUNT: 544, 0, 0, 0, 0 VNODE: 192, 0, 3547, 57, 3547 NAMEI: 1024, 0, 0, 32, 2582839 VMSPACE: 192, 0, 158, 226, 6604 PROC: 416, 0, 162, 181, 6612 DP fakepg: 64, 0, 0, 0, 0 PV ENTRY: 28, 368522, 37542, 93519, 2439070 MAP ENTRY: 48, 0, 1935, 2018, 198503 KMAP ENTRY: 48, 32121, 800, 93, 2352 MAP: 108, 0, 7, 3, 7 VM OBJECT: 96, 0, 3017, 1145, 198323 vm.zone_kmem_pages: 109 vm.zone_kmem_kvaspace: 50917376 vm.zone_kern_pages: 389 vfs.nfs.nfs_privport: 0 vfs.nfs.async: 0 vfs.nfs.commit_blks: 0 vfs.nfs.commit_miss: 0 vfs.nfs.realign_test: 0 vfs.nfs.realign_count: 0 vfs.nfs.bufpackets: 4 vfs.nfs.gatherdelay: 10000 vfs.nfs.gatherdelay_v3: 0 vfs.nfs.defect: 0 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_swappath: vfs.nfs.access_cache_timeout: 60 vfs.nfs.nfsv3_commit_on_close: 0 vfs.numdirtybuffers: 175 vfs.hidirtybuffers: 999 vfs.numfreebuffers: 3743 vfs.lofreebuffers: 222 vfs.hifreebuffers: 444 vfs.runningbufspace: 0 vfs.maxbufspace: 64192512 vfs.hibufspace: 63537152 vfs.lobufspace: 63471616 vfs.bufspace: 63471616 vfs.maxbdrun: 64 vfs.maxmallocbufspace: 3176857 vfs.bufmallocspace: 906240 vfs.getnewbufcalls: 256989 vfs.getnewbufrestarts: 0 vfs.vmiodirenable: 0 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 0 vfs.bufreusecnt: 3874 vfs.cache.numneg: 198 vfs.cache.numcache: 3175 vfs.cache.numcalls: 6561612 vfs.cache.dothits: 41443 vfs.cache.dotdothits: 4051 vfs.cache.numchecks: 9809415 vfs.cache.nummiss: 435273 vfs.cache.nummisszap: 367588 vfs.cache.numposzaps: 168979 vfs.cache.numposhits: 5454779 vfs.cache.numnegzaps: 2886 vfs.cache.numneghits: 86613 vfs.cache.numcwdcalls: 306 vfs.cache.numcwdfail1: 0 vfs.cache.numcwdfail2: 0 vfs.cache.numcwdfail3: 0 vfs.cache.numcwdfail4: 0 vfs.cache.numcwdfound: 306 vfs.cache.numfullpathcalls: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail3: 0 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfound: 0 vfs.write_behind: 1 vfs.reassignbufcalls: 1115698 vfs.reassignbufloops: 0 vfs.reassignbufsortgood: 229967 vfs.reassignbufsortbad: 327979 vfs.reassignbufmethod: 1 vfs.timestamp_precision: 0 vfs.usermount: 0 vfs.ffs.doreallocblks: 1 vfs.ffs.doasyncfree: 1 net.local.stream.sendspace: 8192 net.local.stream.recvspace: 8192 net.local.dgram.maxdgram: 2048 net.local.dgram.recvspace: 4096 net.local.inflight: 0 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.last: 5000 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 62 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.subnets_are_local: 0 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.drop_redirect: 0 net.inet.icmp.log_redirect: 0 net.inet.icmp.bmcastecho: 0 net.inet.tcp.rfc1323: 0 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.tcp_lq_overflow: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 65535 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.pcbcount: 135 net.inet.tcp.msl: 30000 net.inet.tcp.always_keepalive: 1 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.log_in_vain: 0 net.inet.udp.blackhole: 0 net.inet.accf.unloadable: 0 net.inet.raw.maxdgram: 8192 net.inet.raw.recvspace: 8192 net.link.generic.system.ifcount: 11 net.link.ether.inet.prune_intvl: 300 net.link.ether.inet.max_age: 1200 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 200 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 50 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: 20000701/FreeBSD-current net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.mapped_addr: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.errratelimit: 0 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 1 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 debug.mddebug: 0 debug.elf_trace: 0 debug.boothowto: -2147483648 debug.free_devt: 0 debug.fdexpand: 13 debug.sizeof.vnode: 164 debug.sizeof.proc: 408 debug.sizeof.specinfo: 76 debug.sizeof.disklabel: 276 debug.sizeof.diskslices: 1820 debug.sizeof.disk: 296 debug.ttydebug: 0 debug.nchash: 32767 debug.ncnegfactor: 16 debug.numneg: 198 debug.numcache: 3175 debug.vfscache: 1 debug.vnsize: 164 debug.ncsize: 36 debug.disablecwd: 0 debug.disablefullpath: 0 debug.numvnodes: 3547 debug.wantfreevnodes: 25 debug.freevnodes: 1171 debug.rush_requests: 0 debug.bpf_bufsize: 4096 debug.bpf_maxbufsize: 524288 debug.if_tun_debug: 0 debug.do_tcpdrain: 1 debug.ncr_debug: 0 debug.max_softdeps: 260200 debug.tickdelay: 2 debug.blk_limit_push: 0 debug.ino_limit_push: 0 debug.blk_limit_hit: 0 debug.ino_limit_hit: 0 debug.indir_blk_ptrs: 0 debug.inode_bitmap: 0 debug.direct_blk_ptrs: 0 debug.dir_entry: 0 debug.dircheck: 0 hw.machine: i386 hw.model: Pentium III/Pentium III Xeon/Celeron hw.ncpu: 1 hw.byteorder: 1234 hw.physmem: 533127168 hw.usermem: 496754688 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.atamodes: hw.availpages: 129991 machdep.consdev: { major = 12, minor = 255 } machdep.adjkerntz: 18000 machdep.disable_rtc_set: 0 machdep.wall_cmos_clock: 1 machdep.an_cache_mcastonly: 0 machdep.an_cache_iponly: 1 machdep.do_dump: 1 machdep.pccard.pcic_resume_reset: 1 machdep.enable_panic_key: 0 machdep.apm_suspend_delay: 1 machdep.apm_standby_delay: 1 machdep.ispc98: 0 machdep.msgbuf: machdep.msgbuf_clear: 0 machdep.panic_on_nmi: 1 machdep.i8254_freq: 1193182 machdep.cs_recv_delay: 570 machdep.wi_cache_mcastonly: 0 machdep.wi_cache_iponly: 1 machdep.conspeed: 9600 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 0 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 0 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 0 p1003_1b.synchronized_io: 0 p1003_1b.timers: 0 p1003_1b.aio_listio_max: 0 p1003_1b.aio_max: 0 p1003_1b.aio_prio_delta_max: 0 p1003_1b.delaytimer_max: 0 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 0 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 0 p1003_1b.timer_max: 0 jail.set_hostname_allowed: 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 6:41: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D840C37B491 for ; Tue, 20 Feb 2001 06:40:56 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1KEeth57579; Tue, 20 Feb 2001 07:40:56 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f1KEcBs02400; Tue, 20 Feb 2001 07:38:11 -0700 (MST) Message-Id: <200102201438.f1KEcBs02400@billy-club.village.org> To: Jason Brazile Subject: Re: make bug? (dependency names with '$') Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Feb 2001 12:54:09 +0100." <200102201154.MAA00515@disco.netcetera.ch> References: <200102201154.MAA00515@disco.netcetera.ch> Date: Tue, 20 Feb 2001 07:38:11 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102201154.MAA00515@disco.netcetera.ch> Jason Brazile writes: : I want to construct a portable Makefile to build a java application. That's not possible. Java specifies a half assed make system as part of the language, so it is nearly impossible to use another make system on top of it unless you are willing to live with a whole slew of problems. : When a java source file contains an inner class, it creates class : I could live with having to use something like the "yy" target if it : worked with BSD make, because it works with GNU make. This seems like a bug in make(1). Although I think you might want to investigate: d=$$ X=foo\$dbar.class x: echo $(X) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 6:45:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CE6AC37B491 for ; Tue, 20 Feb 2001 06:45:10 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1KEj9h57594; Tue, 20 Feb 2001 07:45:10 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f1KEgPs02427; Tue, 20 Feb 2001 07:42:25 -0700 (MST) Message-Id: <200102201442.f1KEgPs02427@billy-club.village.org> Subject: Re: make bug? (dependency names with '$') Cc: Jason Brazile , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Feb 2001 07:38:11 MST." <200102201438.f1KEcBs02400@billy-club.village.org> References: <200102201438.f1KEcBs02400@billy-club.village.org> <200102201154.MAA00515@disco.netcetera.ch> Date: Tue, 20 Feb 2001 07:42:25 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102201438.f1KEcBs02400@billy-club.village.org> Warner Losh writes: : This seems like a bug in make(1). Although I think you might want to : investigate: : : d=$$ : X=foo\$dbar.class : : x: : echo $(X) d=$$ X=foo$dbar.class x: $(X) echo "$(X)" Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 6:50:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.43.230.149]) by hub.freebsd.org (Postfix) with ESMTP id 524E437B401 for ; Tue, 20 Feb 2001 06:50:43 -0800 (PST) (envelope-from matt@gsicomp.on.ca) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.9.3) with SMTP id f1KEmpi90506; Tue, 20 Feb 2001 09:48:52 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <003001c09b4c$48226f90$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Yusuf Goolamabbas" , References: <20010220043310.28054.qmail@yusufg.portal2.com> Subject: Re: Switching from buildkernel to config seems to recompile the entire kernel Date: Tue, 20 Feb 2001 09:49:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I cvsup'ed my 4.2-stable box and did the usual > make buildworld > make buildkernel KERNCONF= > where KNAME is the name of theconfig file > make installkernel KERNCONF= > make installworld > > and then rebooted the box. A short while I modified my kernel config > to remove sl and ppp. I then did a /usr/sbin/config > > This seems to recompile all the modules and the entire kernel even though > I expected only a few things to be recompiled and the kernel relinked A surprising number of things get recompiled when the slightest change is made to a kernel configuration. I've often wondered myself why removing one line (such as psuedo-device bpf) forces lots of stuff to be recompiled (like the ahc driver). -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 6:51: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 3FC3E37B401 for ; Tue, 20 Feb 2001 06:51:03 -0800 (PST) (envelope-from K.J.Koster@kpn.com) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01K0C7BU20QM000CHK@research.kpn.com> for freebsd-hackers@FreeBSD.ORG; Tue, 20 Feb 2001 15:51:01 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Feb 2001 15:51:01 +0100 Content-return: allowed Date: Tue, 20 Feb 2001 15:51:00 +0100 From: "Koster, K.J." Subject: RE: make bug? (dependency names with '$') To: 'Jason Brazile' Cc: freebsd-hackers@FreeBSD.ORG Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7C43@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Jason, > > I want to construct a portable Makefile to build a java application. > I've played with Java and Make in the past, but I found that spawning a new instance of the Java compiler is more expensive than compiling a pretty big bunch of files. gcc starts up a lot quicker than a JVM. My solution (ahem) is to compile per (sub)package of my application and simply let the JAR file depend on all of the source files. Compiling this way is quicker in the majority of cases that I have. Have you looked at Apache's Ant project? I don't like it myself, but if you want a portable make, you might as well use a Java one. :) Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 7:48:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netcetera.ch (netcetera-139.netcetera.ch [193.192.248.139]) by hub.freebsd.org (Postfix) with ESMTP id 2FFAB37B4EC for ; Tue, 20 Feb 2001 07:48:28 -0800 (PST) (envelope-from jason@netcetera.ch) Received: from disco.netcetera.ch (disco [193.192.248.144]) by (8.9.3/8.7.3) with ESMTP id QAA12350; Tue, 20 Feb 2001 16:48:23 +0100 (MET) From: Jason Brazile Received: by disco.netcetera.ch (8.9.3) id QAA01397; Tue, 20 Feb 2001 16:48:22 +0100 (MET) Date: Tue, 20 Feb 2001 16:48:22 +0100 (MET) Message-Id: <200102201548.QAA01397@disco.netcetera.ch> To: imp@village.org Cc: freebsd-hackers@freebsd.org Subject: Re: make bug? (dependency names with '$') Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner wrote: > In message <200102201154.MAA00515@disco.netcetera.ch> Jason Brazile writes: > : I want to construct a portable Makefile to build a java application. > > That's not possible. Java specifies a half assed make system as part > of the language, so it is nearly impossible to use another make system > on top of it unless you are willing to live with a whole slew of > problems. Until someone started using inner classes, my Makefiles were being fairly successful at "living with a whole slew of problems". :-) > d=$$ > X=foo$dbar.class > > x: $(X) > echo "$(X)" Thanks for the suggestion. I named this target "w" in order to add to what I already had: X=foo$bar.class XX=foo$$bar.class XXX=foo\$$bar.class d=$$ W=foo$dbar.class .PHONY: x xx xxx yy w x: $(X) echo $(X) xx: $(XX) echo $(XX) xxx: $(XXX) echo $(XXX) yy: $(XX) echo $(XXX) w: $(W) echo "$(W)" However, other than the quotes, it doesn't seem to work differently from my previous "xx" target: $ make w make: don't know how to make fooar.class. Stop $ gmake w echo "foo$bar.class" foo.class $ make xx make: don't know how to make fooar.class. Stop $ gmake xx echo foo$bar.class foo.class Kees Jan wrote: > Have you looked at Apache's Ant project? I don't like it myself, but if you > want a portable make, you might as well use a Java one. :) Hmm, well thanks for reminding me about ant. I guess I should really consider it, unless I am ready to admit to being an old dog. Jason ------------------------------------------------------------------------ Jason Brazile jason.brazile@netcetera.ch Netcetera AG, 8040 Zuerich phone +41 1 247 70 70 fax +41 1 247 70 75 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 8:51:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from extreme.neko.tama.or.jp (extreme.neko.tama.or.jp [203.139.82.198]) by hub.freebsd.org (Postfix) with SMTP id 92BDA37B491 for ; Tue, 20 Feb 2001 08:51:32 -0800 (PST) (envelope-from tomoyuki@pobox.com) Received: (qmail 23674 invoked from network); 21 Feb 2001 01:51:28 +0900 Received: from localhost (127.0.0.1) by extreme.neko.tama.or.jp with SMTP; 21 Feb 2001 01:51:28 +0900 Date: Wed, 21 Feb 2001 01:51:28 +0900 (JST) Message-Id: <20010221.015128.41646024.tomoyuki@pobox.com> To: freebsd-hackers@freebsd.org Subject: OpenSSH 2.5.1 From: Tomoyuki Murakami X-Mailer: Mew version 1.95b106 on XEmacs 21.1.12 (Channel Islands) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I have made a patch to up ssh version 2.3.0(FreeBSD-current) to recently released OpenSSH 2.5.1. Too rough made and it should have more measurements especially in, - SKEY or OPIE functions. - Kerberos4/5 functions. I could not compile with -DSKEY option yet and I did not test Kerberos'. Patch file is too large(gziped 170k+ ;-)to attach here, so I put it in http://www.c-wind.com/~tomo/230-250.diff.gz - /usr/src/crypto/openssh diffs - MD5 (230-251.diff.gz) = 9ff326a90d1f0b6d2eb0f863defdc129 http://www.c-wind.com/~tomo/secure-251.tar.gz - /usr/src/secure Makefiles - MD5 (secure-251.tar.gz) = 7c23bc97fd1e8a48034509b2169dca91 Thanks, -- tomo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 9:13:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 762AE37B401 for ; Tue, 20 Feb 2001 09:13:40 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA35030; Tue, 20 Feb 2001 18:13:36 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Matthew Emmerton" Cc: "Yusuf Goolamabbas" , Subject: Re: Switching from buildkernel to config seems to recompile the entire kernel References: <20010220043310.28054.qmail@yusufg.portal2.com> <003001c09b4c$48226f90$1200a8c0@gsicomp.on.ca> From: Dag-Erling Smorgrav Date: 20 Feb 2001 18:13:35 +0100 In-Reply-To: "Matthew Emmerton"'s message of "Tue, 20 Feb 2001 09:49:07 -0500" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Matthew Emmerton" writes: > A surprising number of things get recompiled when the slightest change is > made to a kernel configuration. [...] Not relevant. The point here is that 'make buildkernel' uses a compile directory in /usr/obj, while the old 'config & make' method uses a compile directory in /usr/src. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 9:28:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id ACC8237B65D for ; Tue, 20 Feb 2001 09:28:33 -0800 (PST) (envelope-from renaud@waldura.org) Received: from renaud (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 01B4A3A4D8; Tue, 20 Feb 2001 09:28:32 -0800 (PST) Message-ID: <005501c09b62$8bd9c920$3902010a@zerog.int> From: "Renaud Waldura" To: , "Len Conrad" References: <5.0.0.25.0.20010220140218.02df9c10@mail.Go2France.com> Subject: Re: postfix: No buffer space available Date: Tue, 20 Feb 2001 09:28:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Have you tried playing with: kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.maxsockets: 4136 The first one looks particularly interesting. --Renaud ----- Original Message ----- From: "Len Conrad" To: Sent: Tuesday, February 20, 2001 6:28 AM Subject: postfix: No buffer space available > Sorry to bother you hackers again, but two submissions to -questions > got no response so it looks like another scaleability issue on you > people can handle : > > ================ > > On a very busy postfix relay hub, we're seeing this: > > Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer > space available > > Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer > space available > > Can we fix this with a systcl write? > > The server already has: > > # sysctl -a | grep maxfile > kern.maxfiles: 16384 > kern.maxfilesperproc: 16384 > > ... which fixed "fatal: too many files open" pb for this client last > November. > > btw, Wietse Venema himself asked me to be informed of how I manage to > tweak FreeBSD to handle this apparent scaleability issue. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 9:29:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from news.lucky.net (news.lucky.net [193.193.193.102]) by hub.freebsd.org (Postfix) with ESMTP id 94C3537B491 for ; Tue, 20 Feb 2001 09:29:33 -0800 (PST) (envelope-from news@news.ntu-kpi.kiev.ua) Received: (from mail@localhost) by news.lucky.net (8.Who.Cares/8.Who.Cares) id TLI20173 for freebsd-hackers@freebsd.org; Tue, 20 Feb 2001 19:29:29 +0200 (envelope-from news@news.ntu-kpi.kiev.ua) From: "Andrey Simonenko" To: freebsd-hackers@freebsd.org Subject: Re: Staticaly allocated buffers in library. Is it correct? Date: Tue, 20 Feb 2001 18:14:42 +0300 Organization: NTUU "KPI" Message-ID: <96u5ao$70r$1@igloo.uran.net.ua> References: <200102192046.f1JKkl738082@earth.backplane.com> X-Trace: igloo.uran.net.ua 982685848 7195 10.18.54.109 (20 Feb 2001 16:17:28 GMT) X-Complaints-To: newsmaster@news.ntu-kpi.kiev.ua X-Newsreader: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Let's look at implementation of getaddrinfo(3) function (there are some functions more which do the same way). We can find source for this function in /usr/src/lib/libc/net/getaddrinfo.c file. This functions in some case reads /etc/hosts file and try to find out there host name. getaddrinfo(3) calls some functions and function _gethtent() tries to read line by linefrom /etc/hosts file: static struct addrinfo * _gethtent(hostf, name, pai) FILE *hostf; const char *name; const struct addrinfo *pai; { char *p; char *cp, *tname, *cname; struct addrinfo hints, *res0, *res; int error; const char *addr; char hostbuf[8*1024]; again: if (!(p = fgets(hostbuf, sizeof hostbuf, hostf))) return (NULL); if (*p == '#') goto again; if (!(cp = strpbrk(p, "#\n"))) goto again; *cp = '\0'; if (!(cp = strpbrk(p, " \t"))) goto again; *cp++ = '\0'; We can see if line is bigger than 8k, then _gethtent() reads until the end of line. In most case this function doesn't find needed host name in such lines, but in some case it can find part of line as correct host name and tries to fetch IP address, but it also will not work, because we lose beginning of line when "goto again". This code can be simply rewriten as loop with fgets(), strlen()/strchr() and realloc(), but it causes speed lost in this function. Also I understand that 8k for line in /etc/hosts is enough and should not be problem for most of _real life_ situations. Matt Dillon wrote in message news:200102192046.f1JKkl738082@earth.backplane.com... > :> fgets() with the proper length limitation, using a statically allocated > :> buffer is not a big deal. Most configuration files couldn't have long > :> lines and still be legal anyway. > : > :Note that the classical loop > : while (fgets(buf, n, fp) != NULL) { > : tokenize(buf, args...); > : ... > : } > :may have problems if the line is too long, so one needs to detect it by > :looking for the '\n'. if none is found, then one can either abort on error > :or ignore the line. In the latter case, you need to read the remaining chars > :so that the next fgets won't get them. > : > :regards, > :mouss > > Yes, but we are talking about simple stupid config files here. Programs > which actually tokenize an input stream typically do not use fgets(). > Tokenizers either use [f]lex, [f]getc(), read() (and handle the buffering > themselves), or mmap(). > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 9:30: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5FBFD37B491 for ; Tue, 20 Feb 2001 09:30:00 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA35105; Tue, 20 Feb 2001 18:29:57 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Jason Brazile Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: make bug? (dependency names with '$') References: <200102201154.MAA00515@disco.netcetera.ch> From: Dag-Erling Smorgrav Date: 20 Feb 2001 18:29:56 +0100 In-Reply-To: Jason Brazile's message of "Tue, 20 Feb 2001 12:54:09 +0100 (MET)" Message-ID: Lines: 21 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Brazile writes: > I want to construct a portable Makefile to build a java application. Don't bother. a) use jikes instead of javac, it's much faster and gives better diagnostics. b) to rebuild, just list all the source (.java) files on the jikes command line. Jikes will figure out what needs rebuilding and what doesn't. If there are too many files, list them all (each on one line) in a text file (e.g. 'sources') and specify '@sources' on the command line. If there is a single file in your project that directly or indirectly depends on every other, you can also just specify that one file on the command line. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 9:36:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 4B33137B4EC for ; Tue, 20 Feb 2001 09:36:06 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 01DFA18C95; Tue, 20 Feb 2001 11:36:04 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1KHa4H54320; Tue, 20 Feb 2001 11:36:04 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Tue, 20 Feb 2001 11:36:04 -0600 From: "Jacques A. Vidrine" To: Andrey Simonenko Cc: freebsd-hackers@freebsd.org Subject: Re: Staticaly allocated buffers in library. Is it correct? Message-ID: <20010220113604.A54305@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Andrey Simonenko , freebsd-hackers@freebsd.org References: <200102192046.f1JKkl738082@earth.backplane.com> <96u5ao$70r$1@igloo.uran.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <96u5ao$70r$1@igloo.uran.net.ua>; from simon@comsys.ntu-kpi.kiev.ua on Tue, Feb 20, 2001 at 06:14:42PM +0300 X-Url: http://www.nectar.com/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 20, 2001 at 06:14:42PM +0300, Andrey Simonenko wrote: > Let's look at implementation of getaddrinfo(3) function (there are some > functions more which > do the same way). We can find source for this function in > /usr/src/lib/libc/net/getaddrinfo.c file. > > This functions in some case reads /etc/hosts file and try to find out there > host name. getaddrinfo(3) > calls some functions and function _gethtent() tries to read line by linefrom > /etc/hosts file: [snip code] > We can see if line is bigger than 8k, then _gethtent() reads until the end > of line. > In most case this function doesn't find needed host name in such lines, but > in some case it can find part of > line as correct host name and tries to fetch IP address, but it also will > not work, because we lose > beginning of line when "goto again". > > This code can be simply rewriten as loop with fgets(), strlen()/strchr() and > realloc(), but it causes > speed lost in this function. > > Also I understand that 8k for line in /etc/hosts is enough and should not be > problem for most of _real life_ > situations. I'm coming in late in this thread. What is it you are trying to accomplish? FWIW, I've rewritten this and lots of code like it while revamping nsswitch. Unlike the traditional code, I am careful to handle lines of arbitrary length by processing only chunks (e.g. 512 bytes) at a time. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 9:38: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 9A5F537B491 for ; Tue, 20 Feb 2001 09:38:04 -0800 (PST) (envelope-from LConrad@Go2France.com) Received: from sv.Go2France.com (sv.meiway.com [212.73.210.79]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 5AB5416B12 for ; Tue, 20 Feb 2001 18:49:04 +0100 (CET) Message-Id: <5.0.0.25.0.20010220183129.03d1da00@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 20 Feb 2001 18:35:19 +0100 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: Re: postfix: No buffer space available In-Reply-To: <005501c09b62$8bd9c920$3902010a@zerog.int> References: <5.0.0.25.0.20010220140218.02df9c10@mail.Go2France.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Have you tried playing with: > >kern.ipc.maxsockbuf: 262144 >kern.ipc.sockbuf_waste_factor: 8 >kern.ipc.maxsockets: 4136 > >The first one looks particularly interesting. We have of course looked at that, and "guessed" it was as interesting as you did. I'm looking for some more precise guidance, if it's available, before we go twisting knobs and pushing buttons to see what happens. however, the cowboy rode over the hill and found this Indian: # /sbin/sysctl -w kern.ipc.maxsockets=5000 sysctl: oid 'kern.ipc.maxsockets' is read only Len http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 10:24: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id F04DB37B401 for ; Tue, 20 Feb 2001 10:24:01 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1KINrW89862; Tue, 20 Feb 2001 11:23:53 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102201823.f1KINrW89862@harmony.village.org> To: "Matthew Emmerton" Subject: Re: Switching from buildkernel to config seems to recompile the entire kernel Cc: "Yusuf Goolamabbas" , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Feb 2001 09:49:07 EST." <003001c09b4c$48226f90$1200a8c0@gsicomp.on.ca> References: <003001c09b4c$48226f90$1200a8c0@gsicomp.on.ca> <20010220043310.28054.qmail@yusufg.portal2.com> Date: Tue, 20 Feb 2001 11:23:53 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <003001c09b4c$48226f90$1200a8c0@gsicomp.on.ca> "Matthew Emmerton" writes: : A surprising number of things get recompiled when the slightest change is : made to a kernel configuration. I've often wondered myself why removing one : line (such as psuedo-device bpf) forces lots of stuff to be recompiled (like : the ahc driver). This is due to a bug in kmod.mk that I've been testing a fix for. The short answer is that it is because all the targets depend on the symbolic link, which means that if the directory changes, they get recompiled. I'll go ahead and commit this later today if I can find time to hook up my laptop. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 10:25: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id ACABB37B65D for ; Tue, 20 Feb 2001 10:24:48 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Tue, 20 Feb 2001 19:22:20 +0100 (MET) Message-Id: <4.3.0.20010220192222.04fd4100@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Feb 2001 19:24:22 +0100 To: Len Conrad , freebsd-hackers@freebsd.org From: mouss Subject: Re: postfix: No buffer space available In-Reply-To: <5.0.0.25.0.20010220140218.02df9c10@mail.Go2France.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You might want to try setting net.inet.tcp.sendspace net.inet.tcp.recvspace to larger values. I have these in my /etc/sysctl.conf. regards, mouss At 15:28 20/02/01 +0100, Len Conrad wrote: >Sorry to bother you hackers again, but two submissions to -questions got >no response so it looks like another scaleability issue on you people can >handle : > >================ > >On a very busy postfix relay hub, we're seeing this: > >Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer >space available > >Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer >space available > >Can we fix this with a systcl write? > >The server already has: > ># sysctl -a | grep maxfile >kern.maxfiles: 16384 >kern.maxfilesperproc: 16384 > >... which fixed "fatal: too many files open" pb for this client last November. > >btw, Wietse Venema himself asked me to be informed of how I manage to >tweak FreeBSD to handle this apparent scaleability issue. > >"sysctl -a" > >gives: > >kern.ostype: FreeBSD >kern.osrelease: 4.1.1-RELEASE >kern.osrevision: 199506 >kern.version: FreeBSD 4.1.1-RELEASE #0: Tue Sep 26 00:46:59 GMT 2000 > jkh@narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC > >kern.maxvnodes: 32525 >kern.maxproc: 532 >kern.maxfiles: 16384 >kern.argmax: 65536 >kern.securelevel: -1 >kern.hostname: imgate2.snip.net >kern.hostid: 0 >kern.clockrate: { hz = 100, tick = 10000, tickadj = 5, profhz = 1024, >stathz = 128 } >kern.posix1version: 199309 >kern.ngroups: 16 >kern.job_control: 1 >kern.saved_ids: 0 >kern.boottime: { sec = 982608649, usec = 136401 } Mon Feb 19 13:50:49 2001 >kern.domainname: >kern.osreldate: 411000 >kern.bootfile: /kernel >kern.maxfilesperproc: 16384 >kern.maxprocperuid: 531 >kern.dumpdev: >kern.ipc.maxsockbuf: 262144 >kern.ipc.sockbuf_waste_factor: 8 >kern.ipc.somaxconn: 128 >kern.ipc.max_linkhdr: 16 >kern.ipc.max_protohdr: 60 >kern.ipc.max_hdr: 76 >kern.ipc.max_datalen: 136 >kern.ipc.nmbclusters: 1024 >kern.ipc.semmap: 30 >kern.ipc.semmni: 10 >kern.ipc.semmns: 60 >kern.ipc.semmnu: 30 >kern.ipc.semmsl: 60 >kern.ipc.semopm: 100 >kern.ipc.semume: 10 >kern.ipc.semusz: 92 >kern.ipc.semvmx: 32767 >kern.ipc.semaem: 16384 >kern.ipc.shmmax: 4194304 >kern.ipc.shmmin: 1 >kern.ipc.shmmni: 96 >kern.ipc.shmseg: 64 >kern.ipc.shmall: 1024 >kern.ipc.shm_use_phys: 0 >kern.ipc.mbuf_wait: 32 >kern.ipc.mbtypes: 460 164 160 0 0 0 0 0 0 0 0 0 0 0 0 0 >kern.ipc.nmbufs: 4096 >kern.ipc.maxsockets: 1064 >kern.dummy: 0 >kern.ps_strings: 3217031152 >kern.usrstack: 3217031168 >kern.logsigexit: 1 >kern.cam.cd.changer.min_busy_seconds: 5 >kern.cam.cd.changer.max_busy_seconds: 15 >kern.fallback_elf_brand: 9 >kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall >kern.module_path: /;/boot/;/modules/ >kern.acct_suspend: 2 >kern.acct_resume: 4 >kern.acct_chkfreq: 15 >kern.timecounter.method: 0 >kern.timecounter.hardware: i8254 >kern.ps_arg_cache_limit: 256 >kern.ps_argsopen: 1 >kern.fast_vfork: 1 >kern.randompid: 0 >kern.ps_showallprocs: 1 >kern.shutdown.poweroff_delay: 5000 >kern.shutdown.kproc_shutdown_wait: 60 >kern.sugid_coredump: 0 >kern.coredump: 1 >kern.corefile: %N.core >kern.quantum: 100000 >kern.ccpu: 1948 >kern.fscale: 2048 >kern.devstat.numdevs: 7 >kern.devstat.generation: 7 >kern.devstat.version: 4 >kern.nselcoll: 60034 >kern.consmute: 0 >kern.filedelay: 30 >kern.dirdelay: 29 >kern.metadelay: 28 >kern.chroot_allow_open_directories: 1 >vm.loadavg: { 0.39 0.43 0.52 } >vm.v_free_min: 886 >vm.v_free_target: 2906 >vm.v_free_reserved: 248 >vm.v_inactive_target: 4359 >vm.v_cache_min: 2906 >vm.v_cache_max: 5812 >vm.v_pageout_free_min: 34 >vm.pageout_algorithm: 0 >vm.swap_enabled: 1 >vm.swap_async_max: 4 >vm.swap_idle_threshold1: 2 >vm.swap_idle_threshold2: 10 >vm.v_free_severe: 567 >vm.stats.sys.v_swtch: 15651300 >vm.stats.sys.v_trap: 1045137 >vm.stats.sys.v_syscall: 53830549 >vm.stats.sys.v_intr: 19460810 >vm.stats.sys.v_soft: 3519936 >vm.stats.vm.v_vm_faults: 610808 >vm.stats.vm.v_cow_faults: 138115 >vm.stats.vm.v_cow_optim: 0 >vm.stats.vm.v_zfod: 310288 >vm.stats.vm.v_ozfod: 309994 >vm.stats.vm.v_swapin: 0 >vm.stats.vm.v_swapout: 0 >vm.stats.vm.v_swappgsin: 0 >vm.stats.vm.v_swappgsout: 0 >vm.stats.vm.v_vnodein: 374 >vm.stats.vm.v_vnodeout: 0 >vm.stats.vm.v_vnodepgsin: 2490 >vm.stats.vm.v_vnodepgsout: 0 >vm.stats.vm.v_intrans: 2 >vm.stats.vm.v_reactivated: 125 >vm.stats.vm.v_pdwakeups: 0 >vm.stats.vm.v_pdpages: 0 >vm.stats.vm.v_dfree: 0 >vm.stats.vm.v_pfree: 355480 >vm.stats.vm.v_tfree: 809980 >vm.stats.vm.v_page_size: 4096 >vm.stats.vm.v_page_count: 127974 >vm.stats.vm.v_free_reserved: 248 >vm.stats.vm.v_free_target: 2906 >vm.stats.vm.v_free_min: 886 >vm.stats.vm.v_free_count: 97173 >vm.stats.vm.v_wire_count: 8879 >vm.stats.vm.v_active_count: 11659 >vm.stats.vm.v_inactive_target: 4359 >vm.stats.vm.v_inactive_count: 10259 >vm.stats.vm.v_cache_count: 4 >vm.stats.vm.v_cache_min: 2906 >vm.stats.vm.v_cache_max: 5812 >vm.stats.vm.v_pageout_free_min: 34 >vm.stats.vm.v_interrupt_free_min: 2 >vm.stats.misc.zero_page_count: 70388 >vm.stats.misc.cnt_prezero: 376460 >vm.max_proc_mmap: 36401 >vm.pageout_stats_max: 2906 >vm.pageout_full_stats_interval: 20 >vm.pageout_stats_interval: 5 >vm.pageout_stats_free_max: 5 >vm.swap_idle_enabled: 0 >vm.defer_swapspace_pageouts: 0 >vm.disable_swapspace_pageouts: 0 >vm.max_page_launder: 32 >vm.zone: >ITEM SIZE LIMIT USED FREE REQUESTS > >PIPE: 160, 0, 36, 66, 1232 >SWAPMETA: 160, 255948, 0, 0, 0 >tcpcb: 544, 1064, 135, 173, 116705 >unpcb: 64, 0, 406, 490, 334655 >ripcb: 192, 1064, 0, 42, 2 >tcpcb: 544, 1064, 0, 0, 0 >udpcb: 192, 1064, 15, 69, 518065 >socket: 192, 1064, 556, 494, 969428 >KNOTE: 64, 0, 13, 115, 515373 >NFSNODE: 320, 0, 0, 0, 0 >NFSMOUNT: 544, 0, 0, 0, 0 >VNODE: 192, 0, 3547, 57, 3547 >NAMEI: 1024, 0, 0, 32, 2582839 >VMSPACE: 192, 0, 158, 226, 6604 >PROC: 416, 0, 162, 181, 6612 >DP fakepg: 64, 0, 0, 0, 0 >PV ENTRY: 28, 368522, 37542, 93519, 2439070 >MAP ENTRY: 48, 0, 1935, 2018, 198503 >KMAP ENTRY: 48, 32121, 800, 93, 2352 >MAP: 108, 0, 7, 3, 7 >VM OBJECT: 96, 0, 3017, 1145, 198323 >vm.zone_kmem_pages: 109 >vm.zone_kmem_kvaspace: 50917376 >vm.zone_kern_pages: 389 >vfs.nfs.nfs_privport: 0 >vfs.nfs.async: 0 >vfs.nfs.commit_blks: 0 >vfs.nfs.commit_miss: 0 >vfs.nfs.realign_test: 0 >vfs.nfs.realign_count: 0 >vfs.nfs.bufpackets: 4 >vfs.nfs.gatherdelay: 10000 >vfs.nfs.gatherdelay_v3: 0 >vfs.nfs.defect: 0 >vfs.nfs.diskless_valid: 0 >vfs.nfs.diskless_rootpath: >vfs.nfs.diskless_swappath: >vfs.nfs.access_cache_timeout: 60 >vfs.nfs.nfsv3_commit_on_close: 0 >vfs.numdirtybuffers: 175 >vfs.hidirtybuffers: 999 >vfs.numfreebuffers: 3743 >vfs.lofreebuffers: 222 >vfs.hifreebuffers: 444 >vfs.runningbufspace: 0 >vfs.maxbufspace: 64192512 >vfs.hibufspace: 63537152 >vfs.lobufspace: 63471616 >vfs.bufspace: 63471616 >vfs.maxbdrun: 64 >vfs.maxmallocbufspace: 3176857 >vfs.bufmallocspace: 906240 >vfs.getnewbufcalls: 256989 >vfs.getnewbufrestarts: 0 >vfs.vmiodirenable: 0 >vfs.bufdefragcnt: 0 >vfs.buffreekvacnt: 0 >vfs.bufreusecnt: 3874 >vfs.cache.numneg: 198 >vfs.cache.numcache: 3175 >vfs.cache.numcalls: 6561612 >vfs.cache.dothits: 41443 >vfs.cache.dotdothits: 4051 >vfs.cache.numchecks: 9809415 >vfs.cache.nummiss: 435273 >vfs.cache.nummisszap: 367588 >vfs.cache.numposzaps: 168979 >vfs.cache.numposhits: 5454779 >vfs.cache.numnegzaps: 2886 >vfs.cache.numneghits: 86613 >vfs.cache.numcwdcalls: 306 >vfs.cache.numcwdfail1: 0 >vfs.cache.numcwdfail2: 0 >vfs.cache.numcwdfail3: 0 >vfs.cache.numcwdfail4: 0 >vfs.cache.numcwdfound: 306 >vfs.cache.numfullpathcalls: 0 >vfs.cache.numfullpathfail1: 0 >vfs.cache.numfullpathfail2: 0 >vfs.cache.numfullpathfail3: 0 >vfs.cache.numfullpathfail4: 0 >vfs.cache.numfullpathfound: 0 >vfs.write_behind: 1 >vfs.reassignbufcalls: 1115698 >vfs.reassignbufloops: 0 >vfs.reassignbufsortgood: 229967 >vfs.reassignbufsortbad: 327979 >vfs.reassignbufmethod: 1 >vfs.timestamp_precision: 0 >vfs.usermount: 0 >vfs.ffs.doreallocblks: 1 >vfs.ffs.doasyncfree: 1 >net.local.stream.sendspace: 8192 >net.local.stream.recvspace: 8192 >net.local.dgram.maxdgram: 2048 >net.local.dgram.recvspace: 4096 >net.local.inflight: 0 >net.inet.ip.portrange.lowfirst: 1023 >net.inet.ip.portrange.lowlast: 600 >net.inet.ip.portrange.first: 1024 >net.inet.ip.portrange.last: 5000 >net.inet.ip.portrange.hifirst: 49152 >net.inet.ip.portrange.hilast: 65535 >net.inet.ip.forwarding: 0 >net.inet.ip.redirect: 1 >net.inet.ip.ttl: 64 >net.inet.ip.rtexpire: 62 >net.inet.ip.rtminexpire: 10 >net.inet.ip.rtmaxcache: 128 >net.inet.ip.sourceroute: 0 >net.inet.ip.intr_queue_maxlen: 50 >net.inet.ip.intr_queue_drops: 0 >net.inet.ip.accept_sourceroute: 0 >net.inet.ip.fastforwarding: 0 >net.inet.ip.keepfaith: 0 >net.inet.ip.gifttl: 30 >net.inet.ip.subnets_are_local: 0 >net.inet.icmp.maskrepl: 0 >net.inet.icmp.icmplim: 200 >net.inet.icmp.drop_redirect: 0 >net.inet.icmp.log_redirect: 0 >net.inet.icmp.bmcastecho: 0 >net.inet.tcp.rfc1323: 0 >net.inet.tcp.rfc1644: 0 >net.inet.tcp.mssdflt: 512 >net.inet.tcp.keepidle: 7200000 >net.inet.tcp.keepintvl: 75000 >net.inet.tcp.sendspace: 16384 >net.inet.tcp.recvspace: 16384 >net.inet.tcp.keepinit: 75000 >net.inet.tcp.delacktime: 100 >net.inet.tcp.v6mssdflt: 1024 >net.inet.tcp.log_in_vain: 0 >net.inet.tcp.blackhole: 0 >net.inet.tcp.delayed_ack: 1 >net.inet.tcp.tcp_lq_overflow: 1 >net.inet.tcp.path_mtu_discovery: 1 >net.inet.tcp.slowstart_flightsize: 1 >net.inet.tcp.local_slowstart_flightsize: 65535 >net.inet.tcp.tcbhashsize: 512 >net.inet.tcp.pcbcount: 135 >net.inet.tcp.msl: 30000 >net.inet.tcp.always_keepalive: 1 >net.inet.udp.checksum: 1 >net.inet.udp.maxdgram: 9216 >net.inet.udp.recvspace: 42080 >net.inet.udp.log_in_vain: 0 >net.inet.udp.blackhole: 0 >net.inet.accf.unloadable: 0 >net.inet.raw.maxdgram: 8192 >net.inet.raw.recvspace: 8192 >net.link.generic.system.ifcount: 11 >net.link.ether.inet.prune_intvl: 300 >net.link.ether.inet.max_age: 1200 >net.link.ether.inet.host_down_time: 20 >net.link.ether.inet.maxtries: 5 >net.link.ether.inet.useloopback: 1 >net.link.ether.inet.proxyall: 0 >net.inet6.ip6.forwarding: 0 >net.inet6.ip6.redirect: 1 >net.inet6.ip6.hlim: 64 >net.inet6.ip6.maxfragpackets: 200 >net.inet6.ip6.accept_rtadv: 0 >net.inet6.ip6.keepfaith: 0 >net.inet6.ip6.log_interval: 5 >net.inet6.ip6.hdrnestlimit: 50 >net.inet6.ip6.dad_count: 1 >net.inet6.ip6.auto_flowlabel: 1 >net.inet6.ip6.defmcasthlim: 1 >net.inet6.ip6.gifhlim: 30 >net.inet6.ip6.kame_version: 20000701/FreeBSD-current >net.inet6.ip6.use_deprecated: 1 >net.inet6.ip6.rr_prune: 5 >net.inet6.ip6.mapped_addr: 1 >net.inet6.ip6.rtexpire: 3600 >net.inet6.ip6.rtminexpire: 10 >net.inet6.ip6.rtmaxcache: 128 >net.inet6.icmp6.rediraccept: 1 >net.inet6.icmp6.redirtimeout: 600 >net.inet6.icmp6.errratelimit: 0 >net.inet6.icmp6.nd6_prune: 1 >net.inet6.icmp6.nd6_delay: 5 >net.inet6.icmp6.nd6_umaxtries: 3 >net.inet6.icmp6.nd6_mmaxtries: 3 >net.inet6.icmp6.nd6_useloopback: 1 >net.inet6.icmp6.nodeinfo: 1 >net.inet6.icmp6.errppslimit: 100 >net.inet6.icmp6.nd6_maxnudhint: 0 >debug.mddebug: 0 >debug.elf_trace: 0 >debug.boothowto: -2147483648 >debug.free_devt: 0 >debug.fdexpand: 13 >debug.sizeof.vnode: 164 >debug.sizeof.proc: 408 >debug.sizeof.specinfo: 76 >debug.sizeof.disklabel: 276 >debug.sizeof.diskslices: 1820 >debug.sizeof.disk: 296 >debug.ttydebug: 0 >debug.nchash: 32767 >debug.ncnegfactor: 16 >debug.numneg: 198 >debug.numcache: 3175 >debug.vfscache: 1 >debug.vnsize: 164 >debug.ncsize: 36 >debug.disablecwd: 0 >debug.disablefullpath: 0 >debug.numvnodes: 3547 >debug.wantfreevnodes: 25 >debug.freevnodes: 1171 >debug.rush_requests: 0 >debug.bpf_bufsize: 4096 >debug.bpf_maxbufsize: 524288 >debug.if_tun_debug: 0 >debug.do_tcpdrain: 1 >debug.ncr_debug: 0 >debug.max_softdeps: 260200 >debug.tickdelay: 2 >debug.blk_limit_push: 0 >debug.ino_limit_push: 0 >debug.blk_limit_hit: 0 >debug.ino_limit_hit: 0 >debug.indir_blk_ptrs: 0 >debug.inode_bitmap: 0 >debug.direct_blk_ptrs: 0 >debug.dir_entry: 0 >debug.dircheck: 0 >hw.machine: i386 >hw.model: Pentium III/Pentium III Xeon/Celeron >hw.ncpu: 1 >hw.byteorder: 1234 >hw.physmem: 533127168 >hw.usermem: 496754688 >hw.pagesize: 4096 >hw.floatingpoint: 1 >hw.machine_arch: i386 >hw.atamodes: >hw.availpages: 129991 >machdep.consdev: { major = 12, minor = 255 } >machdep.adjkerntz: 18000 >machdep.disable_rtc_set: 0 >machdep.wall_cmos_clock: 1 >machdep.an_cache_mcastonly: 0 >machdep.an_cache_iponly: 1 >machdep.do_dump: 1 >machdep.pccard.pcic_resume_reset: 1 >machdep.enable_panic_key: 0 >machdep.apm_suspend_delay: 1 >machdep.apm_standby_delay: 1 >machdep.ispc98: 0 >machdep.msgbuf: >machdep.msgbuf_clear: 0 >machdep.panic_on_nmi: 1 >machdep.i8254_freq: 1193182 >machdep.cs_recv_delay: 570 >machdep.wi_cache_mcastonly: 0 >machdep.wi_cache_iponly: 1 >machdep.conspeed: 9600 >user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: >user.bc_base_max: 99 >user.bc_dim_max: 2048 >user.bc_scale_max: 99 >user.bc_string_max: 1000 >user.coll_weights_max: 0 >user.expr_nest_max: 32 >user.line_max: 2048 >user.re_dup_max: 255 >user.posix2_version: 199212 >user.posix2_c_bind: 0 >user.posix2_c_dev: 0 >user.posix2_char_term: 0 >user.posix2_fort_dev: 0 >user.posix2_fort_run: 0 >user.posix2_localedef: 0 >user.posix2_sw_dev: 0 >user.posix2_upe: 0 >user.stream_max: 20 >user.tzname_max: 255 >p1003_1b.asynchronous_io: 0 >p1003_1b.mapped_files: 0 >p1003_1b.memlock: 0 >p1003_1b.memlock_range: 0 >p1003_1b.memory_protection: 0 >p1003_1b.message_passing: 0 >p1003_1b.prioritized_io: 0 >p1003_1b.priority_scheduling: 1 >p1003_1b.realtime_signals: 0 >p1003_1b.semaphores: 0 >p1003_1b.fsync: 0 >p1003_1b.shared_memory_objects: 0 >p1003_1b.synchronized_io: 0 >p1003_1b.timers: 0 >p1003_1b.aio_listio_max: 0 >p1003_1b.aio_max: 0 >p1003_1b.aio_prio_delta_max: 0 >p1003_1b.delaytimer_max: 0 >p1003_1b.mq_open_max: 0 >p1003_1b.pagesize: 4096 >p1003_1b.rtsig_max: 0 >p1003_1b.sem_nsems_max: 0 >p1003_1b.sem_value_max: 0 >p1003_1b.sigqueue_max: 0 >p1003_1b.timer_max: 0 >jail.set_hostname_allowed: 1 > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 10:28:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E431037B401 for ; Tue, 20 Feb 2001 10:28:16 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1KISBW89928; Tue, 20 Feb 2001 11:28:11 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102201828.f1KISBW89928@harmony.village.org> To: Jason Brazile Subject: Re: make bug? (dependency names with '$') Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Feb 2001 16:48:22 +0100." <200102201548.QAA01397@disco.netcetera.ch> References: <200102201548.QAA01397@disco.netcetera.ch> Date: Tue, 20 Feb 2001 11:28:11 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102201548.QAA01397@disco.netcetera.ch> Jason Brazile writes: : Warner wrote: : > In message <200102201154.MAA00515@disco.netcetera.ch> Jason Brazile writes: : > : I want to construct a portable Makefile to build a java application. : > : > That's not possible. Java specifies a half assed make system as part : > of the language, so it is nearly impossible to use another make system : > on top of it unless you are willing to live with a whole slew of : > problems. : : Until someone started using inner classes, my Makefiles were being : fairly successful at "living with a whole slew of problems". :-) There are bigger problems when you have .java files generated. That's why java's make like system is half assed, and the wrong half at that. There's no hook there to generate .java files. If you needed to support multiple versions of java w/o warnings, for example, you'd need to run your .java code through a preprocessor (since java's conditionals are too weak to allow for this possibility). That's when you start hitting heap bigtime problems. This does sound like a bug in our make :-(. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 10:32:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 4BBBB37B503 for ; Tue, 20 Feb 2001 10:32:09 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Tue, 20 Feb 2001 19:30:41 +0100 (MET) Message-Id: <4.3.0.20010220192849.059a49a0@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Feb 2001 19:32:43 +0100 To: clefevre@poboxes.com, "Julian Stacey" From: mouss Subject: Re: COPTFLAGS without -O in /etc/make.conf breaks kernel make Cc: hackers@FreeBSD.ORG In-Reply-To: References: <"Julian Stacey"'s message of "Mon, 19 Feb 2001 22:17:09 GMT"> <200102192217.f1JMH9C16878@jhs.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 05:51 20/02/01 +0100, Cyrille Lefevre wrote: >"Julian Stacey" writes: > > > Here's a weirdness in 4.2-RELEASE kernel generation: > > - Compiling a GENERIC kernel _Without -O optimiser causes a broken make ! > > - Compiling a GENERIC kernel _With_ -O optimiser compiles OK. > >this question is cyclic. and yes, the kernel *have* to be compiled >w/ -O turned on. sorry, I don't remember why. > >if you want yo put something to COPTFLAGS, try something like this : As far as I know, "-O" is necessary because of the "-Wuninitialized" option. but I'm not sure if removing the latter will make you able to compile without -O. cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 10:34:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with ESMTP id 29FFA37B401 for ; Tue, 20 Feb 2001 10:34:33 -0800 (PST) (envelope-from drew@chopper.Poohsticks.ORG) Received: from chopper.Poohsticks.ORG (drew@localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.10.1/8.10.1) with ESMTP id f1KIYMn29117; Tue, 20 Feb 2001 11:34:22 -0700 Message-Id: <200102201834.f1KIYMn29117@chopper.Poohsticks.ORG> To: mouss Cc: Len Conrad , freebsd-hackers@FreeBSD.ORG Subject: Re: postfix: No buffer space available In-reply-to: Your message of "Tue, 20 Feb 2001 19:24:22 +0100." <4.3.0.20010220192222.04fd4100@pop.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29113.982694061.1@chopper.Poohsticks.ORG> Date: Tue, 20 Feb 2001 11:34:21 -0700 From: Drew Eckhardt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <4.3.0.20010220192222.04fd4100@pop.free.fr>, usebsd@free.fr writes: >You might want to try setting > net.inet.tcp.sendspace > net.inet.tcp.recvspace >to larger values. I have these in my /etc/sysctl.conf. These control the default socket buffer size. Assuming postfix is not setting the appropriate socket options, when they are increased space will run out with even fewer connections. If they are decreased such that they are less than the bandwidth delay product, you will have TCP/IP performance problems. The original poster needs to play with some of the kern.ipc values instead, most notably kern.ipc.maxsockbuf. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 10:44:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 3703337B4EC for ; Tue, 20 Feb 2001 10:44:31 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Tue, 20 Feb 2001 19:41:52 +0100 (MET) Message-Id: <4.3.0.20010220193733.0576cd40@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Feb 2001 19:43:53 +0100 To: Drew Eckhardt From: mouss Subject: Re: postfix: No buffer space available Cc: Len Conrad , freebsd-hackers@FreeBSD.ORG In-Reply-To: <200102201834.f1KIYMn29117@chopper.Poohsticks.ORG> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:34 20/02/01 -0700, Drew Eckhardt wrote: >These control the default socket buffer size. Assuming postfix >is not setting the appropriate socket options, when they are increased >space will run out with even fewer connections. If they are decreased >such that they are less than the bandwidth delay product, you will have >TCP/IP performance problems. > >The original poster needs to play with some of the kern.ipc values >instead, most notably kern.ipc.maxsockbuf. You're right. a quick check shows that ENOBUFS may be caused by too many things, including mbuf allocation failures, and even the network interface queue has its "word"... cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 10:56:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 3A95337B491 for ; Tue, 20 Feb 2001 10:56:38 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f1KIuWm16458; Tue, 20 Feb 2001 12:56:32 -0600 (CST) (envelope-from dan) Date: Tue, 20 Feb 2001 12:56:31 -0600 From: Dan Nelson To: Len Conrad Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: postfix: No buffer space available Message-ID: <20010220125631.A10827@dan.emsphone.com> References: <5.0.0.25.0.20010220140218.02df9c10@mail.Go2France.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i In-Reply-To: <5.0.0.25.0.20010220140218.02df9c10@mail.Go2France.com>; from "Len Conrad" on Tue Feb 20 15:28:32 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Feb 20), Len Conrad said: > Sorry to bother you hackers again, but two submissions to -questions > got no response so it looks like another scaleability issue on you > people can handle : > > ================ > > On a very busy postfix relay hub, we're seeing this: > > Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer space available > Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer space available I bet you're running out of mbufs. If netstat -m shows either 'current' or 'peak' anywhere near 'max', you'll want to raise either maxusers or "options NMBCLUSTERS" and rebuild your kernel. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 11:35:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 39B1E37B4EC for ; Tue, 20 Feb 2001 11:35:40 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA17481; Tue, 20 Feb 2001 12:35:35 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id MAA05830; Tue, 20 Feb 2001 12:30:32 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14994.50647.712920.261989@nomad.yogotech.com> Date: Tue, 20 Feb 2001 12:30:31 -0700 (MST) To: Jason Brazile Cc: imp@village.org, freebsd-hackers@FreeBSD.ORG Subject: Re: make bug? (dependency names with '$') In-Reply-To: <200102201548.QAA01397@disco.netcetera.ch> References: <200102201548.QAA01397@disco.netcetera.ch> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Brazile writes: > > : I want to construct a portable Makefile to build a java application. > > > > That's not possible. Java specifies a half assed make system as part > > of the language, so it is nearly impossible to use another make system > > on top of it unless you are willing to live with a whole slew of > > problems. That's not true. I built a 100K line application using make w/out any problems. (It builds on Win9X, NT, FreeBSD, and Solaris). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 11:36: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 93FF037B503 for ; Tue, 20 Feb 2001 11:35:54 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA17494; Tue, 20 Feb 2001 12:35:38 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id MAA05819; Tue, 20 Feb 2001 12:29:14 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14994.50569.335995.104938@nomad.yogotech.com> Date: Tue, 20 Feb 2001 12:29:13 -0700 (MST) To: "Koster, K.J." Cc: "'Jason Brazile'" , freebsd-hackers@FreeBSD.ORG Subject: RE: make bug? (dependency names with '$') In-Reply-To: <59063B5B4D98D311BC0D0001FA7E4522026D7C43@l04.research.kpn.com> References: <59063B5B4D98D311BC0D0001FA7E4522026D7C43@l04.research.kpn.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > I want to construct a portable Makefile to build a java application. > > > I've played with Java and Make in the past, but I found that spawning a new > instance of the Java compiler is more expensive than compiling a pretty big > bunch of files. gcc starts up a lot quicker than a JVM. Jikes is your friend. We switched from using javac because of this. Nate ps. This should probably be moved to freebsd-java. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 11:36: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 810F237B4EC for ; Tue, 20 Feb 2001 11:35:54 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA17497; Tue, 20 Feb 2001 12:35:40 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id MAA05837; Tue, 20 Feb 2001 12:33:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14994.50826.777697.32696@nomad.yogotech.com> Date: Tue, 20 Feb 2001 12:33:30 -0700 (MST) To: Dag-Erling Smorgrav Cc: Jason Brazile , freebsd-hackers@FreeBSD.ORG Subject: Re: make bug? (dependency names with '$') In-Reply-To: References: <200102201154.MAA00515@disco.netcetera.ch> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Jason Brazile writes: > > I want to construct a portable Makefile to build a java application. > > Don't bother. > > a) use jikes instead of javac, it's much faster and gives better > diagnostics. Agreed. > b) to rebuild, just list all the source (.java) files on the jikes > command line. Jikes will figure out what needs rebuilding and what > doesn't. If there are too many files, list them all (each on one > line) in a text file (e.g. 'sources') and specify '@sources' on > the command line. Disagree. If you want it to be portable, don't use a non-standard extension to a tool, such as jikes dependency features. We used jikes for our day-day development, but move back to using 'javac' for our Q/A and final builds. That way we can complain to Sun when things don't work. ;) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 12: 1:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8A07037B6CE for ; Tue, 20 Feb 2001 12:01:40 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id VAA35739; Tue, 20 Feb 2001 21:01:30 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: nate@yogotech.com (Nate Williams) Cc: Jason Brazile , freebsd-hackers@FreeBSD.ORG Subject: Re: make bug? (dependency names with '$') References: <200102201154.MAA00515@disco.netcetera.ch> <14994.50826.777697.32696@nomad.yogotech.com> From: Dag-Erling Smorgrav Date: 20 Feb 2001 21:01:29 +0100 In-Reply-To: Nate Williams's message of "Tue, 20 Feb 2001 12:33:30 -0700 (MST)" Message-ID: Lines: 20 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams writes: > Disagree. If you want it to be portable, don't use a non-standard > extension to a tool, such as jikes dependency features. > > We used jikes for our day-day development, but move back to using > 'javac' for our Q/A and final builds. That way we can complain to Sun > when things don't work. ;) So what's the problem? javac also automatically builds dependencies, it's just not as good at it as jikes. For a final build, you want to start with a clean tree anyway, so javac's inability to correctly detect if a dependency is out of date is irrelevant. Also, my experience is that unless you're paying Sun significant amounts of $$, their reaction to bug reports is to close their eyes, hum real loud and hope they go away. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 13:24:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4F09E37B65D for ; Tue, 20 Feb 2001 13:24:20 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA19236; Tue, 20 Feb 2001 14:24:09 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id OAA06348; Tue, 20 Feb 2001 14:24:03 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14994.57437.646438.335790@nomad.yogotech.com> Date: Tue, 20 Feb 2001 14:23:41 -0700 (MST) To: Dag-Erling Smorgrav Cc: nate@yogotech.com (Nate Williams), Jason Brazile , freebsd-hackers@FreeBSD.ORG Subject: Re: make bug? (dependency names with '$') In-Reply-To: References: <200102201154.MAA00515@disco.netcetera.ch> <14994.50826.777697.32696@nomad.yogotech.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Disagree. If you want it to be portable, don't use a non-standard > > extension to a tool, such as jikes dependency features. > > > > We used jikes for our day-day development, but move back to using > > 'javac' for our Q/A and final builds. That way we can complain to Sun > > when things don't work. ;) > > So what's the problem? javac also automatically builds dependencies, > it's just not as good at it as jikes. Not in a way that's usable my make. Jike can be used to build external dependency files. > Also, my experience is that unless you're paying Sun significant > amounts of $$, their reaction to bug reports is to close their eyes, > hum real loud and hope they go away. True, but Sun is no different than anyone else in that regard. I have found the individual developers somewhat more easy to work with, if you can get a contact within Sun. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 13:38:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id AE8AC37B401 for ; Tue, 20 Feb 2001 13:38:53 -0800 (PST) (envelope-from LConrad@Go2France.com) Received: from sv.Go2France.com (sv.meiway.com [212.73.210.79]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 1F20316B13; Tue, 20 Feb 2001 22:49:54 +0100 (CET) Message-Id: <5.0.0.25.0.20010220223301.00a88e30@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 20 Feb 2001 22:36:04 +0100 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: Fwd: Re: Re: postfix: No buffer space available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's what has happened with the advice earlier: >tried to add the following via sysctl.conf > >kern.ipc.maxsockets = 5000 >kern.ipc.maxsockbuf = 524288 > >But neither parameter takes effect. are these read-only values?? and: ># netstat -m >445/720/4096 mbufs in use (current/peak/max): > 172 mbufs allocated to data > 273 mbufs allocated to packet headers >154/252/1024 mbuf clusters in use (current/peak/max) >684 Kbytes allocated to network (61% in use) >0 requests for memory denied >0 requests for memory delayed >0 calls to protocol drain routines Anybody got any other ideas how scale FreeBSD up to postfix's needs? tia, Len http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 13:50:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id A357437B491 for ; Tue, 20 Feb 2001 13:50:07 -0800 (PST) (envelope-from scanner@jurai.net) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id QAA72744; Tue, 20 Feb 2001 16:43:47 -0500 (EST) Date: Tue, 20 Feb 2001 16:43:47 -0500 (EST) From: To: Len Conrad Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Fwd: Re: Re: postfix: No buffer space available In-Reply-To: <5.0.0.25.0.20010220223301.00a88e30@mail.Go2France.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Len Conrad wrote: > >kern.ipc.maxsockets = 5000 > >kern.ipc.maxsockbuf = 524288 > > > >But neither parameter takes effect. If the sysctl's are read only that you want to change slap them in your /boot/loader.rc \ Increase MBUF's for purpose of testing Postfix under alot of connections. set kern.ipc.nmbclusters=65536 That is what I have on mine to increase mbuf's. But I beat Postfix to death with benchmarks and testing it for the book. heh Also you can set the above to read only variables in /boot/loader.rc as well. Then they take effect after reboot. Maxfiles is what i usually hit first, then ipc.sockets. Mbuf's havent been a real problem :) ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! Author of upcoming book on Postfix ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 14:42:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id CA4CD37B401 for ; Tue, 20 Feb 2001 14:42:16 -0800 (PST) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id DA7C63E69; Tue, 20 Feb 2001 23:42:15 +0100 (CET) Date: Tue, 20 Feb 2001 23:42:15 +0100 From: Jesper Skriver To: Gordon Tetlow Cc: Dan Phoenix , freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO--qmail vs postfix competition Message-ID: <20010220234215.C87801@FreeBSD.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gordont@bluemtn.net on Tue, Feb 20, 2001 at 01:22:57AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 20, 2001 at 01:22:57AM -0800, Gordon Tetlow wrote: > My company (online greeting cards) sent our 4 million emails in 4 hours > using a cluster of about 30 mailers with qmail on FreeBSD (old version of > FreeBSD at that). That averages to 16,666 mail messages per minute or > about 500 per minute per server. The best part was the servers weren't > breaking a sweat. Is that 4 million different emails, or a much lower number of mails with multiple recipients ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 15:13:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id 3377137B503 for ; Tue, 20 Feb 2001 15:13:14 -0800 (PST) (envelope-from gordont@bluemtn.net) Received: (qmail 17296 invoked by uid 1078); 20 Feb 2001 23:13:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Feb 2001 23:13:11 -0000 Date: Tue, 20 Feb 2001 15:13:11 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Jesper Skriver Cc: Dan Phoenix , Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: <20010220234215.C87801@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Jesper Skriver wrote: > On Tue, Feb 20, 2001 at 01:22:57AM -0800, Gordon Tetlow wrote: > > My company (online greeting cards) sent our 4 million emails in 4 hours > > using a cluster of about 30 mailers with qmail on FreeBSD (old version of > > FreeBSD at that). That averages to 16,666 mail messages per minute or > > about 500 per minute per server. The best part was the servers weren't > > breaking a sweat. > > Is that 4 million different emails, or a much lower number of mails with > multiple recipients ? Yep, that's 4 million unique emails. Actually, I should qualify that, it took 4 hours for the mail servers to accept and queue them. The outgoing probably took a bit longer, but from the way the queues stacked up, it probably wasn't more than 5 hours to get all the deliverable messages out (except for excite.com which wasn't taking mail at the time). -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 15:17:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id D4DDF37B401 for ; Tue, 20 Feb 2001 15:17:46 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 12375 invoked by uid 1000); 20 Feb 2001 23:17:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Feb 2001 23:17:08 -0000 Date: Tue, 20 Feb 2001 15:17:08 -0800 (PST) From: Dan Phoenix To: Gordon Tetlow Cc: Jesper Skriver , freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Date: Tue, 20 Feb 2001 15:13:11 -0800 (PST) > From: Gordon Tetlow > To: Jesper Skriver > Cc: Dan Phoenix , freebsd-hackers@FreeBSD.ORG > Subject: Re: qmail IO--qmail vs postfix competition > > On Tue, 20 Feb 2001, Jesper Skriver wrote: > > > On Tue, Feb 20, 2001 at 01:22:57AM -0800, Gordon Tetlow wrote: > > > My company (online greeting cards) sent our 4 million emails in 4 hours > > > using a cluster of about 30 mailers with qmail on FreeBSD (old version of > > > FreeBSD at that). That averages to 16,666 mail messages per minute or > > > about 500 per minute per server. The best part was the servers weren't > > > breaking a sweat. > > > > Is that 4 million different emails, or a much lower number of mails with > > multiple recipients ? > > Yep, that's 4 million unique emails. Actually, I should qualify that, it > took 4 hours for the mail servers to accept and queue them. The outgoing > probably took a bit longer, but from the way the queues stacked up, it > probably wasn't more than 5 hours to get all the deliverable messages out > (except for excite.com which wasn't taking mail at the time). > > -gordon > when you say "about 30 mailers" are you talking about 30 separate machines? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 15:35:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id A614E37B4EC for ; Tue, 20 Feb 2001 15:35:34 -0800 (PST) (envelope-from gordont@bluemtn.net) Received: (qmail 28165 invoked by uid 1078); 20 Feb 2001 23:35:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Feb 2001 23:35:31 -0000 Date: Tue, 20 Feb 2001 15:35:31 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Dan Phoenix Cc: Jesper Skriver , Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Dan Phoenix wrote: > On Tue, 20 Feb 2001, Gordon Tetlow wrote: > > > Yep, that's 4 million unique emails. Actually, I should qualify that, it > > took 4 hours for the mail servers to accept and queue them. The outgoing > > probably took a bit longer, but from the way the queues stacked up, it > > probably wasn't more than 5 hours to get all the deliverable messages out > > (except for excite.com which wasn't taking mail at the time). > > when you say "about 30 mailers" are you talking about 30 separate > machines? Yes, 30 machines that live to deliver. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 15:53:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 67E8337B491 for ; Tue, 20 Feb 2001 15:53:11 -0800 (PST) (envelope-from dphoenix@bravenet.com) Received: (qmail 19199 invoked by uid 1000); 20 Feb 2001 23:52:34 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Feb 2001 23:52:34 -0000 Date: Tue, 20 Feb 2001 15:52:34 -0800 (PST) From: Dan Phoenix To: Gordon Tetlow Cc: Jesper Skriver , freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just curious how you pull this off? so 4 million/30=133 thousand emails per mail server roughly. So how do you distribute between the machines evenly ....into ezmlm as well? On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Date: Tue, 20 Feb 2001 15:35:31 -0800 (PST) > From: Gordon Tetlow > To: Dan Phoenix > Cc: Jesper Skriver , freebsd-hackers@FreeBSD.ORG > Subject: Re: qmail IO--qmail vs postfix competition > > On Tue, 20 Feb 2001, Dan Phoenix wrote: > > > On Tue, 20 Feb 2001, Gordon Tetlow wrote: > > > > > Yep, that's 4 million unique emails. Actually, I should qualify that, it > > > took 4 hours for the mail servers to accept and queue them. The outgoing > > > probably took a bit longer, but from the way the queues stacked up, it > > > probably wasn't more than 5 hours to get all the deliverable messages out > > > (except for excite.com which wasn't taking mail at the time). > > > > when you say "about 30 mailers" are you talking about 30 separate > > machines? > > Yes, 30 machines that live to deliver. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 16:20:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id F346137B4EC for ; Tue, 20 Feb 2001 16:20:18 -0800 (PST) (envelope-from gordont@bluemtn.net) Received: (qmail 16979 invoked by uid 1078); 21 Feb 2001 00:20:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Feb 2001 00:20:16 -0000 Date: Tue, 20 Feb 2001 16:20:15 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Dan Phoenix Cc: Jesper Skriver , Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Dan Phoenix wrote: > Just curious how you pull this off? > so 4 million/30=133 thousand emails per mail server roughly. > So how do you distribute between the machines evenly ....into ezmlm as > well? We use Alteon load balancers to take care of the balancing part, after that, qmail just works. We did add a hack for a deferral server option to qmail, meaning after 10 minutes of undeliverable mail (configurable), the mail gets tossed to another server that tries for up to 2 days before discarding. This keeps our frontline mailservers from dealing with all the people that can't spell hotmail.com (you wouldn't believe the number). The frontline mailservers peaked at about 600-800 messages in the queue when sending out the 4 million while the deferral servers were sitting about 10000 messages (up from a normal 7000 or so, also we had 8 deferrals in rotation). Also of importance is that we are whitelisted everywhere possible to make sure that we are rate limited on the amount of mail we send (aol is a good example of that). I think that describes the general gist of our mail situation. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 16:22:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id 7C11737B491 for ; Tue, 20 Feb 2001 16:22:36 -0800 (PST) (envelope-from gordont@bluemtn.net) Received: (qmail 17850 invoked by uid 1078); 21 Feb 2001 00:22:33 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Feb 2001 00:22:33 -0000 Date: Tue, 20 Feb 2001 16:22:33 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Dan Phoenix Cc: Jesper Skriver , Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Gordon Tetlow wrote: > We use Alteon load balancers to take care of the balancing part, after > that, qmail just works. We did add a hack for a deferral server option to > qmail, meaning after 10 minutes of undeliverable mail (configurable), the > mail gets tossed to another server that tries for up to 2 days before > discarding. This keeps our frontline mailservers from dealing with all > the people that can't spell hotmail.com (you wouldn't believe the number). > The frontline mailservers peaked at about 600-800 messages in the queue > when sending out the 4 million while the deferral servers were sitting > about 10000 messages (up from a normal 7000 or so, also we had 8 deferrals > in rotation). > > Also of importance is that we are whitelisted everywhere possible to make > sure that we are rate limited on the amount of mail we send (aol is a good > example of that). > > I think that describes the general gist of our mail situation. Forgot to add info about the mailers. Each has a hardware raid controller with about 32MB of memory on the controller configured to RAID-1 2HDs for redundancy. Ideally, the mail never actually hits the disk but resides exclusively in memory. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 16:31:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id A595A37B491 for ; Tue, 20 Feb 2001 16:31:28 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-117-165.nnj.dialup.bellatlantic.net [151.198.117.165]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA10806; Tue, 20 Feb 2001 19:31:05 -0500 (EST) Message-ID: <3A930C49.BE0EE66B@bellatlantic.net> Date: Tue, 20 Feb 2001 19:31:05 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Dave Smith Cc: David Preece , freebsd-hackers@freebsd.org Subject: Re: Creating BSD bootable CD References: <20010219171015.A16412@dizzyd.com> <5.0.2.1.1.20010220131304.02b7b660@pop3.paradise.net.nz> <20010219175846.A16500@dizzyd.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dave Smith wrote: > > On Tue, Feb 20, 2001 at 01:16:17PM +1300, David Preece wrote: > > I started in the handbook, the section on backups and creating a bootable > > floppy was invaluable. It's also worth trawling the archives of > > freebsd-small, in particular look for "tinybsd" which (IIRC) is a > > configurable script for making a small installation of FreeBSD without > > going to the lengths that pico goes to, crunchgen etc. As far as I remember, there is not much special. Just create a bootable floppy image and give it as option -b to mkhybrid. (I strongly recommend mkhybrid over mkisofs because it tends to make defective filesystems in fewer cases). > Thanks. I'm already investigating this stuff. One more question -- is > there a list of all valid /dev nodes? cd /dev sh MAKEDEV all should do it. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 16:34: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id 639DA37B491; Tue, 20 Feb 2001 16:33:57 -0800 (PST) (envelope-from scanner@jurai.net) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id TAA76125; Tue, 20 Feb 2001 19:27:43 -0500 (EST) Date: Tue, 20 Feb 2001 19:27:43 -0500 (EST) From: To: Gordon Tetlow Cc: Dan Phoenix , Jesper Skriver , freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Forgot to add info about the mailers. Each has a hardware raid controller > with about 32MB of memory on the controller configured to RAID-1 2HDs for > redundancy. Ideally, the mail never actually hits the disk but resides > exclusively in memory. Aha. That explains it. You use HW raid. I wondered why you were only doing 4 million mails for *30* boxes. Dan, is doing 500K, on a completely idle box (cpu/ram/I/O wise), with vinum, Postfix, and RAID-0. Have you seen brad knowles papers on vinum vs HW raid? It's erm enlightening to say the least :) Id be happy to dig up the URL if you are interested. I personally will be using Vinum from now on. The performance is very impressive. ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 17:23:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from extreme.neko.tama.or.jp (extreme.neko.tama.or.jp [203.139.82.198]) by hub.freebsd.org (Postfix) with SMTP id 1985137B4EC for ; Tue, 20 Feb 2001 17:23:32 -0800 (PST) (envelope-from tomoyuki@pobox.com) Received: (qmail 24626 invoked from network); 21 Feb 2001 10:23:31 +0900 Received: from localhost (127.0.0.1) by extreme.neko.tama.or.jp with SMTP; 21 Feb 2001 10:23:31 +0900 Date: Wed, 21 Feb 2001 10:23:30 +0900 (JST) Message-Id: <20010221.102330.112602967.tomoyuki@pobox.com> To: freebsd-hackers@freebsd.org Subject: OpenSSH 2.5.1 From: Tomoyuki Murakami X-Mailer: Mew version 1.95b106 on XEmacs 21.1.12 (Channel Islands) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ------Repost----------------------- If duplicated, ignore this. thanks. ----------------------------------- Hi I have made a patch to up ssh version 2.3.0(FreeBSD-current) to recently released OpenSSH 2.5.1. Too rough made and it should have more measurements especially in, - SKEY or OPIE functions. - Kerberos4/5 functions. I could not compile with -DSKEY and -DK... options yet. Patch file is too large(gziped 170k+ ;-)to attach here, so I put it in http://www.c-wind.com/~tomo/230-250.diff.gz - /usr/src/crypto/openssh diffs - MD5 (230-251.diff.gz) = 9ff326a90d1f0b6d2eb0f863defdc129 http://www.c-wind.com/~tomo/secure-251.tar.gz - /usr/src/secure Makefiles - MD5 (secure-251.tar.gz) = 7c23bc97fd1e8a48034509b2169dca91 Thanks, -- tomo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 17:55:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 88E6A37B491 for ; Tue, 20 Feb 2001 17:55:06 -0800 (PST) (envelope-from renaud@waldura.org) Received: from renaud (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id B23F33A4D8; Tue, 20 Feb 2001 17:55:05 -0800 (PST) Message-ID: <026d01c09ba9$4ff6da50$3902010a@zerog.int> From: "Renaud Waldura" To: , "Len Conrad" References: <5.0.0.25.0.20010220223301.00a88e30@mail.Go2France.com> Subject: Re: Re: Re: postfix: No buffer space available Date: Tue, 20 Feb 2001 17:55:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >But neither parameter takes effect. They may be read-only if you're running with securelevel > 0. Otherwise they "take effect" just fine. > Anybody got any other ideas how scale FreeBSD up to postfix's needs? Yes, recompile your kernel with "maxusers 128" or more. This tweaks a bunch of stuff, notably mbufs. E.g. with 128 "users" I've got: 226/1920/10240 mbufs in use (current/peak/max): 159 mbufs allocated to data 67 mbufs allocated to packet headers 130/1438/2560 mbuf clusters in use (current/peak/max) 3116 Kbytes allocated to network (9% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines --Renaud ----- Original Message ----- From: "Len Conrad" To: Sent: Tuesday, February 20, 2001 1:36 PM Subject: Fwd: Re: Re: postfix: No buffer space available > Here's what has happened with the advice earlier: > > >tried to add the following via sysctl.conf > > > >kern.ipc.maxsockets = 5000 > >kern.ipc.maxsockbuf = 524288 > > > >But neither parameter takes effect. > > are these read-only values?? and: > > ># netstat -m > >445/720/4096 mbufs in use (current/peak/max): > > 172 mbufs allocated to data > > 273 mbufs allocated to packet headers > >154/252/1024 mbuf clusters in use (current/peak/max) > >684 Kbytes allocated to network (61% in use) > >0 requests for memory denied > >0 requests for memory delayed > >0 calls to protocol drain routines > > Anybody got any other ideas how scale FreeBSD up to postfix's needs? > > tia, > Len > > > http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K > http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 18:51:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id EA20237B401 for ; Tue, 20 Feb 2001 18:51:11 -0800 (PST) (envelope-from gordont@bluemtn.net) Received: (qmail 22660 invoked by uid 1078); 21 Feb 2001 02:51:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Feb 2001 02:51:09 -0000 Date: Tue, 20 Feb 2001 18:51:09 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Cc: Dan Phoenix , Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001 scanner@jurai.net wrote: > Aha. That explains it. You use HW raid. I wondered why you were > only doing 4 million mails for *30* boxes. Dan, is doing 500K, on a > completely idle box (cpu/ram/I/O wise), with vinum, Postfix, and RAID-0. > Have you seen brad knowles papers on vinum vs HW raid? It's erm > enlightening to say the least :) Id be happy to dig up the URL if you are > interested. I personally will be using Vinum from now on. The performance > is very impressive. Well, as I said, these boxes are rather bored. I don't think the load reaches above 0.05. Most of the time is delivering mail trying to negotiate with destination hosts. I don't think that the mailers are IO bound, but I haven't really looked to find out to tell you the truth. Once the mailers are set up we treat them as black boxes. They just work. Also, the 500K number, is that per day? The 4 million was in 4 hours, not a day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 19:16:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id 5F1C637B401 for ; Tue, 20 Feb 2001 19:16:47 -0800 (PST) (envelope-from scanner@jurai.net) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id WAA78907; Tue, 20 Feb 2001 22:10:32 -0500 (EST) Date: Tue, 20 Feb 2001 22:10:32 -0500 (EST) From: To: Gordon Tetlow Cc: Dan Phoenix , freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Well, as I said, these boxes are rather bored. I don't think the load > reaches above 0.05. Most of the time is delivering mail trying to > negotiate with destination hosts. I don't think that the mailers are IO > bound, but I haven't really looked to find out to tell you the truth. Once > the mailers are set up we treat them as black boxes. They just work. Aye. So is the one I was mentioning. I keep trying to get it to do more, but dan doesnt have any more mail to throw at it :-). It is totally idle though. Yes that is also a problem with his site, a good chunk of the mailings are to incorrect hotmeail.com, ecite.com, places :) And most of the places have VERY slow front end mail servers like you noted. Wish there was something one could do about that. But alas... > Also, the 500K number, is that per day? The 4 million was in 4 hours, not > a day. Below is what he was doing on a single ATA disk. Not even ATA100. Thehn we transitioned him to a 3 x 9.1GB IBM Deathstar Vinum RAID-0 stripe for /var/spool/postfix/. Not to shabby for a single disk IDE server. I was impressed. And yes these are for 24h. I don't have stats on the SCSI array yet. Hopefully I can get those tonight. But the IDE disk below was totally hammered. Between Postfix slamming the disks until there was no I/O left and logging on the same drive, it was pretty ugly to watch :-) Grand Totals ------------ messages 292315 received 288975 delivered 7 forwarded 6803 deferred (22932 deferrals) 28822 bounced 9 rejected 903m bytes received 930m bytes delivered 837 senders 485 sending hosts/domains 193110 recipients 28337 recipient hosts/domains smtpd 100118 connections 15 hosts/domains 0 avg. connect time (seconds) 8:17:03 total connect time ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 19:47:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2E05237B401 for ; Tue, 20 Feb 2001 19:47:48 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p06-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.71]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id MAA16663; Wed, 21 Feb 2001 12:47:36 +0900 (JST) Message-ID: <3A9339B1.CB2E24F3@newsguy.com> Date: Wed, 21 Feb 2001 12:44:49 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: scanner@jurai.net Cc: Len Conrad , freebsd-hackers@FreeBSD.ORG Subject: Re: Fwd: Re: Re: postfix: No buffer space available References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG scanner@jurai.net wrote: > > On Tue, 20 Feb 2001, Len Conrad wrote: > > > >kern.ipc.maxsockets = 5000 > > >kern.ipc.maxsockbuf = 524288 > > > > > >But neither parameter takes effect. > > If the sysctl's are read only that you want to change slap them in > your /boot/loader.rc > > \ Increase MBUF's for purpose of testing Postfix under alot of connections. > set kern.ipc.nmbclusters=65536 > > That is what I have on mine to increase mbuf's. But I beat Postfix to > death with benchmarks and testing it for the book. heh > Also you can set the above to read only variables in /boot/loader.rc as > well. Then they take effect after reboot. Maxfiles is what i usually hit > first, then ipc.sockets. Mbuf's havent been a real problem :) Let me take this opportunity to mention that the recommended way of doing this is placing the following line in /boot/loader.conf: kern.ipc.nmbclusters="65536" instead of editing /boot/loader.rc directly. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.fashionable.bsdconspiracy.net "Too bad sentience isn't a marketable commodity." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 20 20:28: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 10A6C37B491 for ; Tue, 20 Feb 2001 20:27:55 -0800 (PST) (envelope-from bmilekic@technokratis.com) Received: from jehovah ([24.202.203.190]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G93B2H02.2U1; Tue, 20 Feb 2001 23:27:53 -0500 Message-ID: <001801c09bbe$f85fe6e0$becbca18@jehovah> From: "Bosko Milekic" To: "Renaud Waldura" , , "Len Conrad" References: <5.0.0.25.0.20010220223301.00a88e30@mail.Go2France.com> <026d01c09ba9$4ff6da50$3902010a@zerog.int> Subject: Re: Re: Re: postfix: No buffer space available Date: Tue, 20 Feb 2001 23:30:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Since nobody else has asked this, I think I will: What network device are you using and with what driver? Please show the output of `ifconfig -a' when you notice this problem. Finally, try `ifconfig down' followed by `ifconfig up' when you notice this, and see if it temporarily fixes the problem. Thanks to Matthew Dodd and NetBSD, I think we may have a solution to the ep wedging problems (which has similar symptoms, by the way) sometime soon (i.e. when I get around to it this weekend, after first mid-term, if noone beats me to it). In the meantime, it would be nice to know if there are other devices exhibiting this behavior. (All this assuming, of course, that what you're describing is not the result of a kernel resource shortage, such as mbuf starvation, etc.) Regards, Bosko. Renaud Waldura wrote: > > >But neither parameter takes effect. > > They may be read-only if you're running with securelevel > 0. Otherwise they > "take effect" just fine. > > > > Anybody got any other ideas how scale FreeBSD up to postfix's needs? > > > Yes, recompile your kernel with "maxusers 128" or more. This tweaks a bunch > of stuff, notably mbufs. > > E.g. with 128 "users" I've got: > > 226/1920/10240 mbufs in use (current/peak/max): > 159 mbufs allocated to data > 67 mbufs allocated to packet headers > 130/1438/2560 mbuf clusters in use (current/peak/max) > 3116 Kbytes allocated to network (9% in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > > > --Renaud > > > > > > ----- Original Message ----- > From: "Len Conrad" > To: > Sent: Tuesday, February 20, 2001 1:36 PM > Subject: Fwd: Re: Re: postfix: No buffer space available > > > > Here's what has happened with the advice earlier: > > > > >tried to add the following via sysctl.conf > > > > > >kern.ipc.maxsockets = 5000 > > >kern.ipc.maxsockbuf = 524288 > > > > > >But neither parameter takes effect. > > > > are these read-only values?? and: > > > > ># netstat -m > > >445/720/4096 mbufs in use (current/peak/max): > > > 172 mbufs allocated to data > > > 273 mbufs allocated to packet headers > > >154/252/1024 mbuf clusters in use (current/peak/max) > > >684 Kbytes allocated to network (61% in use) > > >0 requests for memory denied > > >0 requests for memory delayed > > >0 calls to protocol drain routines > > > > Anybody got any other ideas how scale FreeBSD up to postfix's needs? > > > > tia, > > Len > > > > > > http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K > > http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 1:47:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gwdu42.gwdg.de (gwdu42.gwdg.de [134.76.10.26]) by hub.freebsd.org (Postfix) with ESMTP id AFC7D37B401 for ; Wed, 21 Feb 2001 01:47:37 -0800 (PST) (envelope-from rbeer@uni-goettingen.de) Received: from partner.uni-psych.gwdg.de ([134.76.136.114]) by gwdu42.gwdg.de with esmtp (Exim 3.14 #18) id 14VVrv-0001DK-00; Wed, 21 Feb 2001 10:47:31 +0100 Mime-Version: 1.0 X-Sender: rbeer@popper.gwdg.de Message-Id: In-Reply-To: <20010219171015.A16412@dizzyd.com> References: <20010219171015.A16412@dizzyd.com> Date: Tue, 20 Feb 2001 23:09:35 +0100 To: freebsd-hackers@freebsd.org From: Ragnar Beer Subject: Re: Creating BSD bootable CD Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! In a recent thread on freebsd-stable there were a couple of postings that I copied for you. Nevermind posted: ------------------------------------------------------------------------------ I've asked about this before. So that's my howto: 1. You will need the while cvs repository preferablely on local hard disks. You can get it by cvsuping 'cvs-all' target. 2. cvsup complete src tree to your /usr/src or any other place you are usually place your source tree. (we'll call it $SRCDIR) 3. You'll need a lot of free space (about 1.6-2Gb) Also, create some dir where you want to put release files, there should be about 1Gb free. 4. cd $SRCDIR/release make release CVSROOT=here_your_cvs_repo BUILDNAME="4.2-STABLE" \ RELEASETAG=RELENG_4 CHROOTDIR=your_dir_where_to_put_release_files (maybe I'm missing some flags, but now I have no source tree to look at. 5. wait some hours/days depending on your hardware and disk speed :)) 6. when it will finish, cd $CHROOTDIR/R/cdrom/disc1 mkisofs -o ~/FreeBSD-4.2-STABLE-image.iso -J -r -b floppies/boot.flp 7. burn it on CD using burncd for example. ------------------------------------------------------------------------------ And Thomas T. Veldhouse posted: ------------------------------------------------------------------------------ I use ncftp3: % mkdir freebsd && cd freebsd % ncftp3 releng4.freebsd.org ncftp> cd /pub/FreeBSD/snapshots/i386/4.2-20010213-STABLE ncftp> bin ncftp> get *.TXT *.inf ncftp> get -R bin catpages compat1x compat20 compat21 compat22 compat3x crypto dict ncftp> get -R doc floppies games info manpages ports proflibs src ncftp> bye % cd .. % mkisofs -r -o freebsd.iso -b floppies/boot.flp -c floppies/boot.cat -V"4.2-20010213-STABLE" freebsd/ That's it! Make sure you use the trailing forward slash. ------------------------------------------------------------------------------ Hope this helps! Ragnar >Greetings... > >I certainly hope I'm posting this to the right list -- if not, please redirect >me accordingly. Thanks. :) > >I'm interested in taking FreeBSD and putting it on a bootable CD for use in >a so-called "appliance". Can anyone recommend a place to start? Specifically, >I'm unsure how to create a bootable anything -- so it might be good to start >with instructions on how to create a bootable floppy. What files will I need >in /dev? Is there a HOWTO anywhere? > >Thanks. > >Diz > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 1:53:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cast-ext.ab.videon.ca (cast-ext.ab.videon.ca [206.75.216.34]) by hub.freebsd.org (Postfix) with SMTP id A551A37B491 for ; Wed, 21 Feb 2001 01:53:05 -0800 (PST) (envelope-from L.Brockman@videon.ca) Received: (qmail 1549 invoked from network); 21 Feb 2001 09:53:04 -0000 Received: from unknown (HELO videdmexg1.ab.videon.ca) ([24.108.62.15]) (envelope-sender ) by cast-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 21 Feb 2001 09:53:04 -0000 Received: by videdmexg1.ab.videon.ca with Internet Mail Service (5.5.2650.21) id <17QQH3V9>; Wed, 21 Feb 2001 02:55:26 -0700 Message-ID: From: Laurence Brockman To: freebsd-hackers@FreeBSD.ORG Subject: RE: qmail IO--qmail vs postfix competition Date: Wed, 21 Feb 2001 02:55:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd be interested in the URL :) Thanks, Laurence -- Laurence Brockman Unix Administrator Videon Cablesystems Alberta Inc 10450-178 St. Edmonton, AB T5S 1S2 l.brockman@videon.ca (780) 486-6527 -----Original Message----- From: scanner@jurai.net [mailto:scanner@jurai.net] Sent: Tuesday, February 20, 2001 5:28 PM To: Gordon Tetlow Cc: Dan Phoenix; Jesper Skriver; freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO--qmail vs postfix competition On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Forgot to add info about the mailers. Each has a hardware raid controller > with about 32MB of memory on the controller configured to RAID-1 2HDs for > redundancy. Ideally, the mail never actually hits the disk but resides > exclusively in memory. Aha. That explains it. You use HW raid. I wondered why you were only doing 4 million mails for *30* boxes. Dan, is doing 500K, on a completely idle box (cpu/ram/I/O wise), with vinum, Postfix, and RAID-0. Have you seen brad knowles papers on vinum vs HW raid? It's erm enlightening to say the least :) Id be happy to dig up the URL if you are interested. I personally will be using Vinum from now on. The performance is very impressive. ============================================================================ = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================ = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================ = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 3: 6:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 48F2A37B4EC for ; Wed, 21 Feb 2001 03:06:10 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 79725 invoked by uid 1000); 21 Feb 2001 11:04:16 -0000 Date: Wed, 21 Feb 2001 13:04:16 +0200 From: Peter Pentchev To: Tomoyuki Murakami Cc: freebsd-hackers@freebsd.org Subject: Re: OpenSSH 2.5.1 Message-ID: <20010221130415.A79571@ringworld.oblivion.bg> Mail-Followup-To: Tomoyuki Murakami , freebsd-hackers@freebsd.org References: <20010221.102330.112602967.tomoyuki@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010221.102330.112602967.tomoyuki@pobox.com>; from tomoyuki@pobox.com on Wed, Feb 21, 2001 at 10:23:30AM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 21, 2001 at 10:23:30AM +0900, Tomoyuki Murakami wrote: > ------Repost----------------------- > If duplicated, ignore this. thanks. > ----------------------------------- > Hi > > I have made a patch to up ssh version 2.3.0(FreeBSD-current) to > recently released OpenSSH 2.5.1. > Too rough made and it should have more measurements especially in, > > - SKEY or OPIE functions. > - Kerberos4/5 functions. > > I could not compile with -DSKEY and -DK... options yet. > > Patch file is too large(gziped 170k+ ;-)to attach here, so I put it in > > http://www.c-wind.com/~tomo/230-250.diff.gz > - /usr/src/crypto/openssh diffs > - MD5 (230-251.diff.gz) = 9ff326a90d1f0b6d2eb0f863defdc129 > > http://www.c-wind.com/~tomo/secure-251.tar.gz > - /usr/src/secure Makefiles > - MD5 (secure-251.tar.gz) = 7c23bc97fd1e8a48034509b2169dca91 I might be wrong, but I think that OpenSSH upgrades, just as upgrades for most software in src/contrib, are not handled with patches, but with imports on the vendor branch - then CVS examines the changes that the FreeBSD Project has made to the individual files, and tries to merge them into the newly imported version. Still, thanks for your time :) G'luck, Peter -- This sentence contains exactly threee erors. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 5:13:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from extreme.neko.tama.or.jp (extreme.neko.tama.or.jp [203.139.82.198]) by hub.freebsd.org (Postfix) with SMTP id 1CA1737B401 for ; Wed, 21 Feb 2001 05:13:21 -0800 (PST) (envelope-from tomoyuki@pobox.com) Received: (qmail 25437 invoked from network); 21 Feb 2001 22:13:14 +0900 Received: from localhost (127.0.0.1) by extreme.neko.tama.or.jp with SMTP; 21 Feb 2001 22:13:14 +0900 Date: Wed, 21 Feb 2001 22:13:14 +0900 (JST) Message-Id: <20010221.221314.71106066.tomoyuki@pobox.com> To: freebsd-hackers@freebsd.org Subject: Re: OpenSSH 2.5.1 From: Tomoyuki Murakami In-Reply-To: <20010221.102330.112602967.tomoyuki@pobox.com> References: <20010221.102330.112602967.tomoyuki@pobox.com> X-Mailer: Mew version 1.95b106 on XEmacs 21.1.12 (Channel Islands) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>> In OpenSSH 2.5.1 >>> I wrote: tomoyuki> tomoyuki> http://www.c-wind.com/~tomo/230-250.diff.gz correct url is http://www.c-wind.com/~tomo/230-251.diff.gz I'm very sorry for this. tomoyuki> - /usr/src/crypto/openssh diffs tomoyuki> - MD5 (230-251.diff.gz) = 9ff326a90d1f0b6d2eb0f863defdc129 >>> In Re: OpenSSH 2.5.1 >>> Peter Pentchev wrote: roam> I might be wrong, but I think that OpenSSH upgrades, just as upgrades roam> for most software in src/contrib, are not handled with patches, but roam> with imports on the vendor branch - then CVS examines the changes roam> that the FreeBSD Project has made to the individual files, and tries roam> to merge them into the newly imported version. OK. I could be so short-temperd or something. but, first of all, I personally needed the working functions of OpenSSH's port forward '-R' option. Thanks for your comment. -- tomo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 6: 7:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from num1sun.intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (Postfix) with ESMTP id 5481A37B491 for ; Wed, 21 Feb 2001 06:07:29 -0800 (PST) (envelope-from robin@num1sun.intercore.com) Received: (from robin@localhost) by num1sun.intercore.com (8.11.2/8.11.2) id f1LE28E11487; Wed, 21 Feb 2001 09:02:08 -0500 (EST) Date: Wed, 21 Feb 2001 09:02:07 -0500 From: Robin Cutshaw To: Peter Wemm Cc: Robin Cutshaw , freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux Message-ID: <20010221090207.A11473@intercore.com> References: <20010219134043.A8347@intercore.com> <200102192021.f1JKLQr61572@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102192021.f1JKLQr61572@mobile.wemm.org>; from peter@netplex.com.au on Mon, Feb 19, 2001 at 12:21:26PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 12:21:26PM -0800, Peter Wemm wrote: > > > > Any ideas as to why it would take almost three times longer to build > > on FreeBSD? > > This is probably a silly question, but you did recompile the kernel for > SMP, right? > Actually, I was using the stock GENERIC UP kernel. I wanted to get a baseline. > Have you tuned the FreeBSD kernel? It still ships with a worst-case > configuration so that it runs optimally on i386 cpus. :-( Copy GENERIC > to something else and remove all but 'cpu i686', rebuild and install. > Also, get rid of 'sl', and 'ppp' from the kernel config as that messes > up certain things (interrupt masks). Ideally, do a proper cleanup and > configure it for your specific hardware (ie: remove all the other ethernet > drivers, etc). > There's a problem here. I tried to configure an SMP kernel but when it booted the fxp0 (Compaq dual eepro100 adapter) got timeout errors and wouldn't work. I went back and did the config/make on the GENERIC kernel and booted it. Same thing. The stock GENERIC kernel that came with the dist works just fine. Any ideas? One other problem I've seen with the Compaq 8500 system. FreeBSD doesn't see the pci adapter on the secondary bus. I had to move the ethernet adapter to the primary bus for it to work. > > A couple of possibilities.. If you want to compare the two side by side, > try mounting the freebsd filesystems in async mode, just like linux does by > default. In particular, make sure you get /tmp, /var/tmp and wherever your > build is. > OK, I set softupdates on the disk/partition that the build source/target is on. It made no difference in timing. I then created a memory disk, set softupdates on it, and mounted it as /tmp. AMAZINGLY, the build went from 2:50 to 0:40, now much faster than the Linux system. I'm going to do the ram disk thing on Linux and see if it makes a difference. Once I figure out the fxp0 problem from above, I'll do a parallel build and see what speedups occur. Thanks! Robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-713-4000 robin@XFree86.Org XFree86 coreteam/board member "Time is just one damn thing after another" -- PBS/Nova ---- -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 6:37:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from out.newmail.net (out.newmail.net [212.150.54.158]) by hub.freebsd.org (Postfix) with SMTP id 6C0F837B401; Wed, 21 Feb 2001 06:37:40 -0800 (PST) (envelope-from idobarnea@NewMail.Net) Received: from newmail.net ([10.10.1.75]) by out.newmail.net ; Wed, 21 Feb 2001 09:55:57 +0200 From: idobarnea@NewMail.Net Reply-To: idobarnea@NewMail.Net To: Ruslan Ermilov , mouss , hackers@FreeBSD.ORG Date: Wed, 21 Feb 2001 09:50:58 Gmt +0200 Subject: Re: Bug in creating ICMP error messages in FreeBSD4.2 Message-id: <3a938f82.19b.0@NewMail.Net> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Mon, Feb 19, 2001 at 08:26:56PM +0100, mouss wrote: >> At 14:25 19/02/01 +0200, idobarnea@NewMail.Net wrote: >> >Hi, >> > I encountered the following problem in the 4.2 version. >> >In ip_forward, the following lines intend to save the mbuf in case we want to >> >send ICMP error later: >> > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); >> > if (mcopy && (mcopy->m_flags & M_EXT)) >> > m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); >> > >> >Later on, before sending the ICMP packet we do: >> > if (mcopy->m_flags & M_EXT) >> > m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); >> > >> >The problem as I understand it is that the m_copydata and m_copyback, actually >> >do nothing (It just >> >copies from mcopy to itself). >> >> I'm speaking from memory, so don't take this for more than it is:) >> >> As far as I understand: >> m_copym copies the mbuf, but if there is external storage, only pointers >> are copied. so you get two mbuf chains with a common external storage. >> m_copydata will copy the external storage. >> that's why there are both m_copym and m_copydata. so while >> m_copydata(mcopy, .... (mcopy...)) >> is surprising, it's not nothing. it copies the data pointed to in mcopy. >> >I wrote this code, and the above said is right. >-- >Ruslan Ermilov Oracle Developer/DBA, I understand that this is what you meant it to be. But look again at m_copydata. This is the relevant line: bcopy(mtod(m, caddr_t) + off, cp, count); If cp is mtod(m, caddr_t) and off is 0, this command has no effect. Anyway, even if I am wrong about this, the facts are that if you take FreeBSD 4.2-RELEASE machine, put net.inet.ip.forwarding to 1,and then blast the kernel with ip packets with len 256 and with destination to which it has a direct network route (on its local lan), but it can't resolve the arp entry the kernel crashes after a while. You can try this yourself. I can explain some more, and give exact conf' if anybody wants it. Now if you stop with a debugger in icmp_error you see that oip->ip_len equals 1, then you see the other stuff I talked about, and then you get a kernel panic. After you make the correction I suggested, and do the same thing, you see that oip->ip_len equals 256 (the right value), and you never get a kernel panic. I'll be glad to here other explanations to this kernel crash. Yours, Ido Barnea _________________________________________ Get Your Free Virus Protection Tool at http://www.VCatch.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 7:43:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 02EF637B69B for ; Wed, 21 Feb 2001 07:42:45 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 3000F18C91 for ; Wed, 21 Feb 2001 09:42:29 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1LFgT993374 for freebsd-hackers@freebsd.org; Wed, 21 Feb 2001 09:42:29 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Wed, 21 Feb 2001 09:42:29 -0600 From: "Jacques A. Vidrine" To: freebsd-hackers@freebsd.org Subject: portability sanity check Message-ID: <20010221094228.A93221@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Url: http://www.nectar.com/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is the following portable and safe? Given n different structure declarations, where each structure begins with the same member type, can any instance of any of the structures be cast to the (pointer) type of the first member? e.g. struct foo { const char *s; ... }; struct bar { const char *s; ... }; int gefahr(struct foo *Foo, struct bar *Bar) { return strcmp((const char *s)Foo, (const char *s)Bar); } Likewise if the first member were a more complex data type, but nevertheless the same between the different structures. It seems safe to me, but I can't explain why :-) Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 7:56:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B796E37B6A1 for ; Wed, 21 Feb 2001 07:56:32 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1LFuTh63040; Wed, 21 Feb 2001 08:56:29 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f1LFrvs07412; Wed, 21 Feb 2001 08:53:57 -0700 (MST) Message-Id: <200102211553.f1LFrvs07412@billy-club.village.org> To: "Jacques A. Vidrine" Subject: Re: portability sanity check Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 21 Feb 2001 09:42:29 CST." <20010221094228.A93221@hamlet.nectar.com> References: <20010221094228.A93221@hamlet.nectar.com> Date: Wed, 21 Feb 2001 08:53:57 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010221094228.A93221@hamlet.nectar.com> "Jacques A. Vidrine" writes: : Likewise if the first member were a more complex data type, but : nevertheless the same between the different structures. : : It seems safe to me, but I can't explain why :-) It is obfuscated 'C', but it is safe. The standard requires that (void *) &foo == (void *) &foo->s and that if s were a complex structure that it be laid out the same in all instances of s. So I think that it is "safe" to do that. There are times that you'd want to do this (like generic list routines), but such type punning, as this is known, is error prone and can lead to problems. It is best avoided in favor of macros, unions or some other less error prone technique. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 8:14: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 9149437B491 for ; Wed, 21 Feb 2001 08:13:55 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1LGDZx02058; Wed, 21 Feb 2001 17:13:35 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: "Jacques A. Vidrine" , freebsd-hackers@FreeBSD.ORG Subject: Re: portability sanity check In-Reply-To: Your message of "Wed, 21 Feb 2001 08:53:57 MST." <200102211553.f1LFrvs07412@billy-club.village.org> Date: Wed, 21 Feb 2001 17:13:35 +0100 Message-ID: <2056.982772015@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102211553.f1LFrvs07412@billy-club.village.org>, Warner Losh writes: >In message <20010221094228.A93221@hamlet.nectar.com> "Jacques A. Vidrine" writes: >: Likewise if the first member were a more complex data type, but >: nevertheless the same between the different structures. >: >: It seems safe to me, but I can't explain why :-) > >It is obfuscated 'C', but it is safe. The standard requires that >(void *) &foo == (void *) &foo->s and that if s were a complex >structure that it be laid out the same in all instances of s. So I >think that it is "safe" to do that. Safe, but stupid, since type-safety is lost when doing so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 8:22:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id B064037B698 for ; Wed, 21 Feb 2001 08:22:05 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 832C718C92; Wed, 21 Feb 2001 10:22:00 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1LGM0U93541; Wed, 21 Feb 2001 10:22:00 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Wed, 21 Feb 2001 10:22:00 -0600 From: "Jacques A. Vidrine" To: Poul-Henning Kamp Cc: Warner Losh , freebsd-hackers@FreeBSD.ORG Subject: Re: portability sanity check Message-ID: <20010221102200.A93525@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Poul-Henning Kamp , Warner Losh , freebsd-hackers@FreeBSD.ORG References: <200102211553.f1LFrvs07412@billy-club.village.org> <2056.982772015@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2056.982772015@critter>; from phk@critter.freebsd.dk on Wed, Feb 21, 2001 at 05:13:35PM +0100 X-Url: http://www.nectar.com/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 21, 2001 at 05:13:35PM +0100, Poul-Henning Kamp wrote: > In message <200102211553.f1LFrvs07412@billy-club.village.org>, Warner Losh writes: > >In message <20010221094228.A93221@hamlet.nectar.com> "Jacques A. Vidrine" writes: > >: Likewise if the first member were a more complex data type, but > >: nevertheless the same between the different structures. > >: > >: It seems safe to me, but I can't explain why :-) > > > >It is obfuscated 'C', but it is safe. The standard requires that > >(void *) &foo == (void *) &foo->s and that if s were a complex > >structure that it be laid out the same in all instances of s. So I > >think that it is "safe" to do that. > > Safe, but stupid, since type-safety is lost when doing so. Type-safety is a cruch for the weak-minded. :-) But seriously I think that for the purpose of building a utility function for use by qsort or similar, using a union just for such a purpose is more obfuscated. struct nothing_much_in_common_really { const char *s; union { struct foo foo; struct bar bar; } u; }; But if there is a better way, I'm all ears :-) Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 8:25:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 69A5037B699 for ; Wed, 21 Feb 2001 08:25:17 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id E964F18C92; Wed, 21 Feb 2001 10:25:16 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1LGPGo93551; Wed, 21 Feb 2001 10:25:16 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Wed, 21 Feb 2001 10:25:16 -0600 From: "Jacques A. Vidrine" To: Warner Losh Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: portability sanity check Message-ID: <20010221102516.B93525@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Warner Losh , freebsd-hackers@FreeBSD.ORG References: <20010221094228.A93221@hamlet.nectar.com> <200102211553.f1LFrvs07412@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102211553.f1LFrvs07412@billy-club.village.org>; from imp@village.org on Wed, Feb 21, 2001 at 08:53:57AM -0700 X-Url: http://www.nectar.com/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 21, 2001 at 08:53:57AM -0700, Warner Losh wrote: > The standard requires that (void *) &foo == (void *) &foo->s Thanks, that is what I was trying to track down but couldn't find it. I also thought that perhaps a structure has the same requirement alignments as its first member ... I think that means the same thing as you've stated. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 8:28:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 07E7237B503 for ; Wed, 21 Feb 2001 08:28:40 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1LGSWx02212; Wed, 21 Feb 2001 17:28:32 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Jacques A. Vidrine" Cc: Warner Losh , freebsd-hackers@FreeBSD.ORG Subject: Re: portability sanity check In-Reply-To: Your message of "Wed, 21 Feb 2001 10:22:00 CST." <20010221102200.A93525@hamlet.nectar.com> Date: Wed, 21 Feb 2001 17:28:31 +0100 Message-ID: <2210.982772911@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010221102200.A93525@hamlet.nectar.com>, "Jacques A. Vidrine" writes: >On Wed, Feb 21, 2001 at 05:13:35PM +0100, Poul-Henning Kamp wrote: >> In message <200102211553.f1LFrvs07412@billy-club.village.org>, Warner Losh writes: >> >In message <20010221094228.A93221@hamlet.nectar.com> "Jacques A. Vidrine" writes: >> >: Likewise if the first member were a more complex data type, but >> >: nevertheless the same between the different structures. >> >: >> >: It seems safe to me, but I can't explain why :-) >> > >> >It is obfuscated 'C', but it is safe. The standard requires that >> >(void *) &foo == (void *) &foo->s and that if s were a complex >> >structure that it be laid out the same in all instances of s. So I >> >think that it is "safe" to do that. >> >> Safe, but stupid, since type-safety is lost when doing so. > >Type-safety is a cruch for the weak-minded. As an old assembler programmer I couldn't agree more, but in a project like FreeBSD we have to realize that not everybody is that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 8:56:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4D9F337B491 for ; Wed, 21 Feb 2001 08:56:12 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1LGu8W97533; Wed, 21 Feb 2001 09:56:08 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102211656.f1LGu8W97533@harmony.village.org> To: "Jacques A. Vidrine" Subject: Re: portability sanity check Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 21 Feb 2001 10:25:16 CST." <20010221102516.B93525@hamlet.nectar.com> References: <20010221102516.B93525@hamlet.nectar.com> <20010221094228.A93221@hamlet.nectar.com> <200102211553.f1LFrvs07412@billy-club.village.org> Date: Wed, 21 Feb 2001 09:56:08 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010221102516.B93525@hamlet.nectar.com> "Jacques A. Vidrine" writes: : On Wed, Feb 21, 2001 at 08:53:57AM -0700, Warner Losh wrote: : > The standard requires that (void *) &foo == (void *) &foo->s : : Thanks, that is what I was trying to track down but couldn't find it. : I also thought that perhaps a structure has the same requirement : alignments as its first member ... I think that means the same thing : as you've stated. There is some verbage in the structure layout part of the standard that makes this a logical conclusion. However, it is overly tricky code. But then again to do the generic sort of thing you want to do, you have to resort to C macros, or other gross things to make it generic. The question becomes how do you do that in the least gross way... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 9: 0:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id C926437B491; Wed, 21 Feb 2001 09:00:39 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f1LGxGR81733; Wed, 21 Feb 2001 18:59:16 +0200 (EET) (envelope-from ru) Date: Wed, 21 Feb 2001 18:59:16 +0200 From: Ruslan Ermilov To: idobarnea@NewMail.Net, bmilekic@FreeBSD.org Cc: mouss , hackers@FreeBSD.org Subject: Re: Bug in creating ICMP error messages in FreeBSD4.2 Message-ID: <20010221185915.A80894@sunbay.com> Mail-Followup-To: idobarnea@NewMail.Net, bmilekic@FreeBSD.org, mouss , hackers@FreeBSD.ORG References: <3a938f82.19b.0@NewMail.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3a938f82.19b.0@NewMail.Net>; from idobarnea@NewMail.Net on Wed, Feb 21, 2001 at 09:50:58AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [redirected to -net] On Wed, Feb 21, 2001 at 09:50:58AM +0000, idobarnea@NewMail.Net wrote: > >On Mon, Feb 19, 2001 at 08:26:56PM +0100, mouss wrote: > > > At 14:25 19/02/01 +0200, idobarnea@NewMail.Net wrote: > > > > Hi, > > > > I encountered the following problem in the 4.2 version. > > > > In ip_forward, the following lines intend to save the mbuf in > > > > case we want to send ICMP error later: > > > > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); > > > > if (mcopy && (mcopy->m_flags & M_EXT)) > > > > m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); > > > > > > > > Later on, before sending the ICMP packet we do: > > > > if (mcopy->m_flags & M_EXT) > > > > m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); > > > > > > > > The problem as I understand it is that the m_copydata and m_copyback, > > > > actually do nothing (It just copies from mcopy to itself). > > > > > > I'm speaking from memory, so don't take this for more than it is:) > > > > > > As far as I understand: > > > m_copym copies the mbuf, but if there is external storage, only > > > pointers are copied. so you get two mbuf chains with a common > > > external storage. > > > m_copydata will copy the external storage. > > > that's why there are both m_copym and m_copydata. so while > > > m_copydata(mcopy, .... (mcopy...)) > > > is surprising, it's not nothing. it copies the data pointed to > > > in mcopy. > > > > > I wrote this code, and the above said is right. > > I understand that this is what you meant it to be. > But look again at m_copydata. > This is the relevant line: > bcopy(mtod(m, caddr_t) + off, cp, count); > If cp is mtod(m, caddr_t) and off is 0, this command has no effect. > > Anyway, even if I am wrong about this, the facts are that if you > take FreeBSD 4.2-RELEASE machine, put net.inet.ip.forwarding to 1, > and then blast the kernel with ip packets with len 256 and with > destination to which it has a direct network route (on its local > lan), but it can't resolve the arp entry the kernel crashes > after a while. You can try this yourself. I can explain some more, > and give exact conf' if anybody wants it. > > Now if you stop with a debugger in icmp_error you see that > oip->ip_len equals 1, then you see the other stuff I talked about, > and then you get a kernel panic. > > After you make the correction I suggested, and do the same thing, > you see that oip->ip_len equals 256 (the right value), and you > never get a kernel panic. > > I'll be glad to here other explanations to this kernel crash. > You are right, the code does nothing, though it was supposed to preserve the byte order of IP header fields in case ip_output() modifies them. The idea was to save the standard IP header in some area in mbuf that is unused for M_EXT mbufs, but obviously mtod() place is wrong, it points to the external data for M_EXT mbuf. Could you please try this patch: Index: ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.130.2.12 diff -u -p -r1.130.2.12 ip_input.c --- ip_input.c 2001/02/01 20:25:09 1.130.2.12 +++ ip_input.c 2001/02/21 16:48:10 @@ -1513,7 +1513,8 @@ ip_forward(m, srcrt) */ mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); if (mcopy && (mcopy->m_flags & M_EXT)) - m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); + m_copydata(mcopy, 0, sizeof(struct ip), + (caddr_t)(&mcopy->m_ext + 1)); #ifdef IPSTEALTH if (!ipstealth) { @@ -1661,7 +1662,8 @@ ip_forward(m, srcrt) return; } if (mcopy->m_flags & M_EXT) - m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); + m_copyback(mcopy, 0, sizeof(struct ip), + (caddr_t)(&mcopy->m_ext + 1)); icmp_error(mcopy, type, code, dest, destifp); } And if that does not work, this (more clear but slower) one: Index: ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.130.2.13 diff -u -p -r1.130.2.13 ip_input.c --- ip_input.c 2001/02/07 01:03:13 1.130.2.13 +++ ip_input.c 2001/02/21 16:10:35 @@ -1510,9 +1510,17 @@ ip_forward(m, srcrt) * we need to generate an ICMP message to the src. */ mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); - if (mcopy && (mcopy->m_flags & M_EXT)) - m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); + /* + * Make sure the copy is read-write. + */ + if (mcopy && (mcopy->m_flags & M_EXT)) { + struct mbuf *mtemp = mcopy; + + mcopy = m_dup(mtemp, M_DONTWAIT); + m_freem(mtemp); + } + #ifdef IPSTEALTH if (!ipstealth) { #endif @@ -1658,8 +1666,6 @@ ip_forward(m, srcrt) m_freem(mcopy); return; } - if (mcopy->m_flags & M_EXT) - m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); icmp_error(mcopy, type, code, dest, destifp); } Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 9: 8:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id D27E037B491 for ; Wed, 21 Feb 2001 09:08:32 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 7B04018C92; Wed, 21 Feb 2001 11:08:31 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1LH8VV93829; Wed, 21 Feb 2001 11:08:31 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Wed, 21 Feb 2001 11:08:31 -0600 From: "Jacques A. Vidrine" To: Warner Losh Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: portability sanity check Message-ID: <20010221110831.A93816@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Warner Losh , freebsd-hackers@FreeBSD.ORG References: <20010221102516.B93525@hamlet.nectar.com> <20010221094228.A93221@hamlet.nectar.com> <200102211553.f1LFrvs07412@billy-club.village.org> <20010221102516.B93525@hamlet.nectar.com> <200102211656.f1LGu8W97533@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102211656.f1LGu8W97533@harmony.village.org>; from imp@harmony.village.org on Wed, Feb 21, 2001 at 09:56:08AM -0700 X-Url: http://www.nectar.com/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 21, 2001 at 09:56:08AM -0700, Warner Losh wrote: > There is some verbage in the structure layout part of the standard > that makes this a logical conclusion. > > However, it is overly tricky code. But then again to do the generic > sort of thing you want to do, you have to resort to C macros, or other > gross things to make it generic. The question becomes how do you do > that in the least gross way... Someone will say ``Use C++'' here. Then I will ignite a copy of `The Annotated C++ Reference Manual' and hit them with it. I think using unions is actually out of the question if you want to be able to allow new `types' after compile time. When you say ``resort to C macros,'' do you mean macros to hide the `type punning', or do you have something else in mind? Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 9:36:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id BEAF137B491 for ; Wed, 21 Feb 2001 09:36:34 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1LHaIB03916; Wed, 21 Feb 2001 09:36:18 -0800 (PST) Date: Wed, 21 Feb 2001 09:36:18 -0800 From: Alfred Perlstein To: Robin Cutshaw Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux Message-ID: <20010221093617.I6641@fw.wintelcom.net> References: <20010219134043.A8347@intercore.com> <200102192021.f1JKLQr61572@mobile.wemm.org> <20010221090207.A11473@intercore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010221090207.A11473@intercore.com>; from robin@XFree86.Org on Wed, Feb 21, 2001 at 09:02:07AM -0500 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Robin Cutshaw [010221 06:07] wrote: > > OK, I set softupdates on the disk/partition that the build source/target > is on. It made no difference in timing. I then created a memory disk, > set softupdates on it, and mounted it as /tmp. AMAZINGLY, the build > went from 2:50 to 0:40, now much faster than the Linux system. I'm > going to do the ram disk thing on Linux and see if it makes a difference. What about just making sure that /tmp and /usr/tmp and /var/tmp are all softupdates enabled? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 9:37:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CF33037B67D for ; Wed, 21 Feb 2001 09:37:51 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1LHbBW97836; Wed, 21 Feb 2001 10:37:15 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102211737.f1LHbBW97836@harmony.village.org> To: "Jacques A. Vidrine" Subject: Re: portability sanity check Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 21 Feb 2001 11:08:31 CST." <20010221110831.A93816@hamlet.nectar.com> References: <20010221110831.A93816@hamlet.nectar.com> <20010221102516.B93525@hamlet.nectar.com> <20010221094228.A93221@hamlet.nectar.com> <200102211553.f1LFrvs07412@billy-club.village.org> <20010221102516.B93525@hamlet.nectar.com> <200102211656.f1LGu8W97533@harmony.village.org> Date: Wed, 21 Feb 2001 10:37:11 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010221110831.A93816@hamlet.nectar.com> "Jacques A. Vidrine" writes: : When you say ``resort to C macros,'' do you mean macros to hide the : `type punning', or do you have something else in mind? I had the queue macros in mind. Hiding the type punning behind a macro helps make sure it is used right, but even that can be a little dubious. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 9:47:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from num1sun.intercore.com (num1sun.intercore.com [199.181.243.1]) by hub.freebsd.org (Postfix) with ESMTP id 4690D37B491 for ; Wed, 21 Feb 2001 09:47:14 -0800 (PST) (envelope-from robin@num1sun.intercore.com) Received: (from robin@localhost) by num1sun.intercore.com (8.11.2/8.11.2) id f1LHfor11794; Wed, 21 Feb 2001 12:41:50 -0500 (EST) Date: Wed, 21 Feb 2001 12:41:49 -0500 From: Robin Cutshaw To: Robin Cutshaw Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux Message-ID: <20010221124149.A11784@intercore.com> References: <20010219134043.A8347@intercore.com> <200102192021.f1JKLQr61572@mobile.wemm.org> <20010221090207.A11473@intercore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010221090207.A11473@intercore.com>; from robin@XFree86.Org on Wed, Feb 21, 2001 at 09:02:07AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 21, 2001 at 09:02:07AM -0500, Robin Cutshaw wrote: > > > Have you tuned the FreeBSD kernel? It still ships with a worst-case > > configuration so that it runs optimally on i386 cpus. :-( Copy GENERIC > > to something else and remove all but 'cpu i686', rebuild and install. > > Also, get rid of 'sl', and 'ppp' from the kernel config as that messes > > up certain things (interrupt masks). Ideally, do a proper cleanup and > > configure it for your specific hardware (ie: remove all the other ethernet > > drivers, etc). > > > OK, one problem that I introduced. I was running a niced seti during the runs on both the Linux and FreeBSD box. It looks like the "niceness" on FreeBSD is problematic. New numbers without seti: Linux - 39 minutes FreeBSD no tweaks - 43 minutes FreeBSD memory tmp - 38 minutes Looks like the systems are pretty close. I just need to remember to kill seti on FreeBSD before compiling. :-) Now if I can figure out the eepro100 problem, I can do this SMP. Robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-713-4000 robin@XFree86.Org XFree86 coreteam/board member "Time is just one damn thing after another" -- PBS/Nova ---- -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 10:37:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by hub.freebsd.org (Postfix) with ESMTP id A5A2937B4EC for ; Wed, 21 Feb 2001 10:37:16 -0800 (PST) (envelope-from wayne@staff.msen.com) Received: (from wayne@localhost) by manor.msen.com (8.9.3/8.9.3) id NAA54755 for hackers@freebsd.org; Wed, 21 Feb 2001 13:37:15 -0500 (EST) (envelope-from wayne) Date: Wed, 21 Feb 2001 13:37:15 -0500 From: "Michael R. Wayne" To: hackers@freebsd.org Subject: Interface alias accounting Message-ID: <20010221133714.E5814@staff.msen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Back on Nov 7, 2000, Josef Karthauser answered my query regarding per alias accounting, suggesting that the solution was in current and would MFC after 4.2 was released. 4.2 was released, any idea when this might show up into stable? /\/\ \/\/ > On Wed, May 17, 2000 at 05:39:15PM -0400, Michael R. Wayne wrote: > > On Wed, May 17, 2000 at 01:50:13PM -0700, D. W. Piper wrote: > > > Hi folks, > > > > > > I'm trying to find out how to get IP accounting information for web > > > hosting where multiple IPs are aliased to the same interface. I seem to > > > recall seeing something about it a few weeks ago, but I've searched the > > > archives, and can't seem to find the information I'm looking for. If I > > > recall correctly, it involved compiling in some kernel option or other. > > > Can anybody help out? > > > > BSD/OS does this per interface right on the box, FreeBSD seems not > > to. We've been trying for several months to get a straight answer > > regarding FreeBSD, nobody seems to know whether it's a bug, oversight > > or what. > > This is in current now. I'm going to MFC it after the 4.2 release. > > Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 10:37:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 4EAA237B503 for ; Wed, 21 Feb 2001 10:37:18 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1LIb3f26667; Wed, 21 Feb 2001 10:37:04 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102211837.f1LIb3f26667@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Gordon Tetlow Cc: scanner@jurai.net, Dan Phoenix , freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO--qmail vs postfix competition In-Reply-To: Date: Wed, 21 Feb 2001 10:37:03 -0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gordon Tetlow wrote: > On Tue, 20 Feb 2001 scanner@jurai.net wrote: > > > Aha. That explains it. You use HW raid. I wondered why you were > > only doing 4 million mails for *30* boxes. Dan, is doing 500K, on a > > completely idle box (cpu/ram/I/O wise), with vinum, Postfix, and RAID-0. > > Have you seen brad knowles papers on vinum vs HW raid? It's erm > > enlightening to say the least :) Id be happy to dig up the URL if you are > > interested. I personally will be using Vinum from now on. The performance > > is very impressive. > > Well, as I said, these boxes are rather bored. I don't think the load > reaches above 0.05. Most of the time is delivering mail trying to > negotiate with destination hosts. I don't think that the mailers are IO > bound, but I haven't really looked to find out to tell you the truth. Once > the mailers are set up we treat them as black boxes. They just work. > > Also, the 500K number, is that per day? The 4 million was in 4 hours, not > a day. Another bored box: mx1.freebsd.org$ grep 'status=sent' /var/log/mail | wc -l 331877 It is 8 hours since the last rollover. Unfortunately, it spends most of its time waiting for something to do and looking at broken mail servers. It delivers most of its mail in a few seconds. We see it peaking at delivering several hundred envelopes per second shortly after getting a large mailing list to digest. Here's a quick histogram of what those 8 hours look like: mx1.freebsd.org$ sh hist.sh zero 1292 1292 0.36577 0.36577 one 4983 6275 1.41071 1.77648 two 7680 13955 2.17424 3.95072 three 10741 24696 3.04082 6.99154 five 30853 55549 8.73461 15.7261 seven 37626 93175 10.6521 26.3782 ten 48169 141344 13.6368 40.0151 fifteen 66877 208221 18.9332 58.9482 twenty 44244 252465 12.5257 71.4739 thirty 48059 300524 13.6057 85.0796 fourtyfive 23626 324150 6.68862 91.7682 sixty 6902 331052 1.95398 93.7222 ninety 7082 338134 2.00494 95.7271 twomin 2336 340470 0.66133 96.3884 threemin 1521 341991 0.43060 96.819 rest 11236 353227 3.18096 100 total 353227 First field: number of seconds. Second is number of deliveries in that interval, third is percentage of total that this represents, and last is an accumulated percentage. This is a 24 hour run for yesterday (1am -> 1am): > sh hist.sh zero 3186 3186 0.29641 0.29641 one 13724 16910 1.27684 1.57325 two 19948 36858 1.8559 3.42915 three 29557 66415 2.74989 6.17904 five 87973 154388 8.18473 14.3638 seven 104690 259078 9.74003 24.1038 ten 144142 403220 13.4105 37.5143 fifteen 208335 611555 19.3828 56.8971 twenty 134030 745585 12.4697 69.3669 thirty 148163 893748 13.7846 83.1515 fourtyfive 74129 967877 6.89673 90.0482 sixty 34204 1002081 3.18223 93.2305 ninety 28955 1031036 2.69388 95.9243 twomin 7146 1038182 0.66484 96.5892 threemin 4297 1042479 0.39977 96.989 rest 32364 1074843 3.01104 100 total 1074843 Some random samples of mail servers in the 5 to 20 second range show most of this delay is due to remote sendmail response time, the ident lookup, etc. I'm pretty pleased to see that 83% of mail is delivered in less than 30 seconds and that 90% is out by 45 seconds. The 'zero' count is because there are a couple of other well connected postfix servers nearby that have a handful of subscribers :-) The machine is only non-trivially busy for a small percentage of its time, it could easily deliver 10 or 20 times that much mail before it was really under load. That is easily 10 to 20 million per day for one box. This is a p3-800 w/ one ide disk. We're in the process of switching it to SCSI because of IDE drive problems. The postfix spool will probably be mirrored for safety. Incidently, the spool is mostly write-only as the entire spool fits cached in memory. mx1.freebsd.org$ mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- .... F40BC6E323E 2021 Wed Feb 21 02:42:14 owner-cvs-all@FreeBSD.ORG (connect to mx1.mainstreet.net[207.5.0.50]: Operation timed out) john@mj.com (connect to foobar.nisse.dk[24.232.51.205]: Operation timed out) r@nisse.dk (connect to osfmail.isc.rit.edu[129.21.2.241]: read timeout) maf8113@osfmail.isc.rit.edu (connect to mx.mainstreet.net[207.5.0.45]: Operation timed out) alexm@securify.com .... (connect to mailhub.state.me.us[141.114.122.227]: No route to host) darren@bmv.state.me.us (connect to mail.is-one.net[210.75.223.43]: read timeout) col@is-one.net (conversation with mbox.iyard.org[140.117.11.95] timed out while sending RCPT TO) kimkara@iyard.org (conversation with relay.orsk.ru[193.233.163.2] timed out while sending RCPT TO) dm@orsk.ru -- 104395 Kbytes in 3639 Requests. The queue (104MB on disk) fits comfortably in memory right now. postfix itself is very light on memory demands. Some other postfix tuning stats: - parallel outbound smtp sender processes: 500 - various qmgr params changed to keep the queue state in memory (ie: deal with something like 100,000 recipients and/or envelopes) - We use bulk_mailer to inject mail on hub.freebsd.org from majordomo and avoid the -outgoing aliases. bulk_mailer was hacked to not split the envelopes unless it got to 100,000 recipients and to not sort the addresses. - hub uses mx1 as a mail exploder, leaving hub to the mailing list management, archiving and searching roles and mx1 solely to delivery. We have seen it pump something like 2000 seperate messages in 3 seconds flat to mx1. The only real problems we've had have been DNS related and disk media errors on the cursed IBM DTLA drives. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 10:45:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id B4C5F37B503 for ; Wed, 21 Feb 2001 10:44:54 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1LIigf26743; Wed, 21 Feb 2001 10:44:42 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102211844.f1LIigf26743@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robin Cutshaw Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux In-Reply-To: <20010221090207.A11473@intercore.com> Date: Wed, 21 Feb 2001 10:44:42 -0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robin Cutshaw wrote: > On Mon, Feb 19, 2001 at 12:21:26PM -0800, Peter Wemm wrote: > > > > > > Any ideas as to why it would take almost three times longer to build > > > on FreeBSD? > > > > This is probably a silly question, but you did recompile the kernel for > > SMP, right? > > > > Actually, I was using the stock GENERIC UP kernel. I wanted to get a > baseline. OK, but this would have been a good thing to tell us to start with. :-) > > Have you tuned the FreeBSD kernel? It still ships with a worst-case > > configuration so that it runs optimally on i386 cpus. :-( Copy GENERIC > > to something else and remove all but 'cpu i686', rebuild and install. > > Also, get rid of 'sl', and 'ppp' from the kernel config as that messes > > up certain things (interrupt masks). Ideally, do a proper cleanup and > > configure it for your specific hardware (ie: remove all the other ethernet > > drivers, etc). > > > > There's a problem here. I tried to configure an SMP kernel but when it > booted the fxp0 (Compaq dual eepro100 adapter) got timeout errors and > wouldn't work. I went back and did the config/make on the GENERIC > kernel and booted it. Same thing. The stock GENERIC kernel that came > with the dist works just fine. Any ideas? > > One other problem I've seen with the Compaq 8500 system. FreeBSD doesn't > see the pci adapter on the secondary bus. I had to move the ethernet > adapter to the primary bus for it to work. Perhaps the output of 'pciconf -l' and mptable(8) would be useful. dmesg also, after a verbose boot (boot -v at the loader). > > A couple of possibilities.. If you want to compare the two side by side, > > try mounting the freebsd filesystems in async mode, just like linux does by > > default. In particular, make sure you get /tmp, /var/tmp and wherever your > > build is. > > > > OK, I set softupdates on the disk/partition that the build source/target > is on. It made no difference in timing. I then created a memory disk, > set softupdates on it, and mounted it as /tmp. AMAZINGLY, the build > went from 2:50 to 0:40, now much faster than the Linux system. I'm > going to do the ram disk thing on Linux and see if it makes a difference. Are you using the gcc -pipe option for the build? You should. Second, did you try a softupdates fs mounted on /tmp itself? I've found that it makes about the same difference as a ramdisk. gcc's -pipe largely makes that irrelevant though. > Once I figure out the fxp0 problem from above, I'll do a parallel build > and see what speedups occur. > > Thanks! > Robin > -- > ---- > Robin Cutshaw internet: robin@interlabs.com robin@intercore.com > Internet Labs, Inc. BellNet: 404-713-4000 robin@XFree86.Org > XFree86 coreteam/board member > > "Time is just one damn thing after another" -- PBS/Nova > ---- > -- > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 11:24:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id F2DB637B67D for ; Wed, 21 Feb 2001 11:23:44 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1LJNWl24375; Wed, 21 Feb 2001 11:23:32 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Feb 2001 11:23:32 -0800 (PST) From: Matt Dillon Message-Id: <200102211923.f1LJNWl24375@earth.backplane.com> To: "Jacques A. Vidrine" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: portability sanity check References: <20010221094228.A93221@hamlet.nectar.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Is the following portable and safe? : :Given n different structure declarations, where each structure begins :with the same member type, can any instance of any of the structures :be cast to the (pointer) type of the first member? : :e.g. : : struct foo { : const char *s; : ... : }; : : struct bar { : const char *s; : ... : }; : : int gefahr(struct foo *Foo, struct bar *Bar) { : return strcmp((const char *s)Foo, (const char *s)Bar); : } : :Likewise if the first member were a more complex data type, but :nevertheless the same between the different structures. : :It seems safe to me, but I can't explain why :-) : :Cheers, Probably safe, but not a good idea. Why not simply pass blah->s to the routine instead? One trick I use, when a subroutine needs the first N headers of a structure, is create an embedded 'header' structure: struct base { a b c } struct fubar1 { struct base base; x y z } struct fubar2 { struct base base; h i j } struct fubar3 { ... } callsomesubroutine(&fubar2->base); The calling direction is not the problem. It's the return value that is usually a problem. For example, a doubly-linked list function might look like this: void * getNextNode(Node *previousNode) { return(previousNode->next); } struct fubar { Node node; ... } struct fubar *fu; for (fu = getHeadOfList(&List); fu; fu = getNextNode(&fu->node)) { } There are ways around this, at least if the contents of a list is uniform. FreeBSD's kernel's /usr/src/sys/sys/queue.h implements macros for all of its list functions that actually create special node structures with previous and next pointers of exactly the proper type for however they are used. I generally use the 'void *' return value trick myself, to make the code more readable at the cost of a slight loss in type checking. But I only use it for return values... arguments are still required to be the proper exact type. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 15:12:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id BE6E437B401 for ; Wed, 21 Feb 2001 15:12:24 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 21 Feb 2001 23:12:15 +0000 (GMT) Date: Wed, 21 Feb 2001 23:12:10 +0000 From: David Malone To: Alfred Perlstein Cc: Robin Cutshaw , Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux Message-ID: <20010221231210.A68244@walton.maths.tcd.ie> References: <20010219134043.A8347@intercore.com> <200102192021.f1JKLQr61572@mobile.wemm.org> <20010221090207.A11473@intercore.com> <20010221093617.I6641@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010221093617.I6641@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Feb 21, 2001 at 09:36:18AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 21, 2001 at 09:36:18AM -0800, Alfred Perlstein wrote: > * Robin Cutshaw [010221 06:07] wrote: > > > > OK, I set softupdates on the disk/partition that the build source/target > > is on. It made no difference in timing. I then created a memory disk, > > set softupdates on it, and mounted it as /tmp. AMAZINGLY, the build > > went from 2:50 to 0:40, now much faster than the Linux system. I'm > > going to do the ram disk thing on Linux and see if it makes a difference. > > What about just making sure that /tmp and /usr/tmp and /var/tmp are > all softupdates enabled? Or adding -pipe to CFLAGS. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 16:59:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by hub.freebsd.org (Postfix) with SMTP id 46B6137B491 for ; Wed, 21 Feb 2001 16:59:55 -0800 (PST) (envelope-from jhs@jhs.muc.de) Received: (qmail 1741 invoked from network); 22 Feb 2001 00:59:52 -0000 Received: from jhs.muc.de (193.149.49.84) by slarti.muc.de with SMTP; 22 Feb 2001 00:59:52 -0000 Received: from park.jhs.private (localhost [127.0.0.1]) by jhs.muc.de (8.11.0/8.11.0) with ESMTP id f1LNqi944274; Wed, 21 Feb 2001 23:52:44 GMT (envelope-from jhs@park.jhs.private) Message-Id: <200102212352.f1LNqi944274@jhs.muc.de> To: Sergey Babkin Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Creating BSD bootable CD In-Reply-To: Message from Sergey Babkin of "Tue, 20 Feb 2001 19:31:05 EST." <3A930C49.BE0EE66B@bellatlantic.net> Date: Thu, 22 Feb 2001 00:52:44 +0100 From: "Julian Stacey Jhs@jhs.muc.de" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sergey Babkin wrote: > As far as I remember, there is not much special. Just create a > bootable floppy image and give it as option -b to mkhybrid. > (I strongly recommend mkhybrid over mkisofs because it tends to make > defective filesystems in fewer cases). I hadn't heard of mkhybrid, so investigated: it's been merged into mkisofs: ports/sysutils/mkisofs/work/mkisofs-1.13/ChangeLog.mkhybrid: Mon May 1 14:51:00 BST 2000 James Pearson Version 1.13a01 mkhybrid has now been merged with, and is now part of mkisofs ports/sysutils/mkisofs/work/mkisofs-1.13/mkisofs/README.mkhybrid: mkhybrid v1.13 has now merged with, and is a part of mkisofs v1.13 Within a 4.2 CVS tree: ports/sysutils/mkhybrid is just an Attic structure cvs -R export -r HEAD mkhybrid cannot find module mkhybrid now features in ports/sysutils/mkisofs/ cvs -R export -r HEAD mkisofs ./pkg-plist:bin/mkhybrid man mkhybrid is an empty dummy (just a .so) Executables share same inode: 262201 -r-xr-xr-x 2 root wheel 374564 Feb 22 00:22 /usr/local/bin/mkhybrid 262201 -r-xr-xr-x 2 root wheel 374564 Feb 22 00:22 /usr/local/bin/mkisofs Julian - Julian Stacey Unix Consultant - Munich Germany http://bim.bsn.com/~jhs/ Considering Linux ? Try FreeBSD with 4500 packages ! Ihr Rauchen => mein allergischer Kopfschmerz ! Kau/Schnupftabak probieren ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 17:49:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id 05F5637B4EC for ; Wed, 21 Feb 2001 17:49:36 -0800 (PST) (envelope-from scanner@jurai.net) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id UAA03378; Wed, 21 Feb 2001 20:42:56 -0500 (EST) Date: Wed, 21 Feb 2001 20:42:56 -0500 (EST) From: To: Laurence Brockman Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: qmail IO--qmail vs postfix competition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://www.shub-internet.org/brad/FreeBSD/vinum.html Sorry for the delay. It slipped my mind. :-) ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 17:58:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bizville.com (bizville.com [161.58.227.153]) by hub.freebsd.org (Postfix) with ESMTP id EF5AD37B503 for ; Wed, 21 Feb 2001 17:58:35 -0800 (PST) (envelope-from seiterva@bizville.com) Received: (seiterva@localhost) by bizville.com (8.8.8) id SAA83577; Wed, 21 Feb 2001 18:58:44 -0700 (MST) Date: Wed, 21 Feb 2001 18:58:44 -0700 (MST) Message-Id: <200102220158.SAA83577@bizville.com> To: hackers@FreeBSD.ORG Subject: Îáðàùàþñü ê Âàì ñ ïðîñüáîé ïîìî÷ü ìíå â ïðèîáðåòåíèè ëåêàðñòâà From: lepeshkinan@aport2000.ru MIME-Version: 1.0 Content-Type: multipart/mixed; boundary = b100874abd8002f940b205e2960911ca4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a MIME encoded message. --b100874abd8002f940b205e2960911ca4 Content-Type: text/html ; charset="windows-1251" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCg0KPGh0bWw+DQo8aGVhZD4NCgk8dGl0bGU+zuHw4Png/vH8IOogwuDsIPEg7/Du8fzh 7ukg7+7s7vf8IOzt5SDiIO/w6O7h8OXy5e3o6CDr5erg8PHy4uA8L3RpdGxlPg0KPC9oZWFkPg0K DQo8Ym9keT4NCjxkaXYgYWxpZ249IkNFTlRFUiI+PGZvbnQgc2l6ZT0iKzEiPjxpPjxiPtPi4Obg 5ez75SDj7vHv7uTgITwvYj48L2k+PC9mb250Pjxicj48L2Rpdj4NCg0KPHA+zuHw4Png/vH8IOog wuDsIPEg7/Du8fzh7ukg7+7s7vf8IOzt5SDiIO/w6O7h8OXy5e3o6CDr5erg8PHy4uAuIMXx6+gg 4fsg/fLuIO3lIOH76yDi7u/w7vEg5ujn7egg6CDx7OXw8ugsIP8g4fsg7ejq7uPk4CDt5SDw5fjo 6+Dx/CDu4fDg8ujy/PH/IOogwuDsLiDN7iD98u7yIO/w5e/g8ODyIOTr/yDs5e3/IC0g7+7x6+Xk 7f//IOLu5+zu5u3u8fL8IPHu9fDg7ejy/CDm6Oft/C4g3yAg6O3i4Ovo5CDv5fDi7ukg4/Dz7+/7 IC0g8yDs5e3/IPDg6iwgIO/l8OXt5fHr4CDu7+Xw4Pbo/iDiIO7t6u725e3y8OUsIOgg8eXp9+Dx IO7h7eDw8+bl7fsg7OXy4PHy4Of7IOIg6u7x8uguIMXk6O3x8uLl7e376SDv8OXv4PDg8iwg6u7y 7vD76SDs7ubl8iDv7uzu9/wgLSD98u4gQXJlZGlhLiDO7SDt5SDi6uv+9+XtIOIg8e/o8e7qIOHl 8e/r4PLt+/Ug6+Xq4PDx8uIuDQrfIO7h8OD54Ovg8fwg4iDK7uzo8uXyIOfk8ODi7u718ODt5e3o /yDjLiDK7vDu6+XiIOgg4iDu7eru9uXt8vAuIM/w5eTx5eTg8uXr/CDx6uDn4OssIPfy7iDx8OXk 8fLiIO3l8iDk4OblIO3gIOTl8uXpLCDgIO4g7+Xt8eju7eXw4PUg6CDj7uLu8Ojy/CDt5ffl4+4u PC9wPg0KPHA+z+Xt8ej/IOzg6+Xt/Org/ywg8O7k8fLi5e3t6Oru4iDzIOzl7f8g7eXyLiDRIO/u 7O75/P4g5PDz5+XpLCDn7eDq7uz79SDoIOTu4fD79SDr/uTl6SDz5ODr7vH8IPHu4fDg8vwg5OXt 5eMg7eAg7uTo7SDs5fH/9iAoNiDy+/H/9yDw8+Hr5ekpIOgg7eD34PL8IOrz8PEg6+X35e3o/ywg 8i7qLiDu8urr4OT74uDy/CDh7uv8+OUg7eXr/Of/LiDN7iDt8+bt+yDl+eUg5OXt/OPoLCDv7v3y 7uzzIO7h8OD54P7x/CDqIMLg7CDxIO/w7vH84e7pIO4g7+7s7vnoLiDS4Oog6uDqIOTl6+4g6uDx 4OXy8f8g5ujn7egsIPLuLCDs7ubl8iDh+/L8LCDC+yDo5/v55fLlIOLu5+zu5u3u8fL8IO/u7O73 /CDk4OblIO3l5+3g6u7s7uzzIPfl6+7i5erzLjwvcD4NCjxwPt8sIOru7eX37e4sIO/u7ejs4P4s IPfy7iDt4Ozt7uPuIOvl4/flIO7q4Ofg8vwg7+7s7vn8IOHu6/zt7uzzIPDl4eXt6vMsIOAg7eUg 7+Xt8eju7eXw8y4g0eXp9+DxIOz7IPPm5SDt6Oru7PMg7eUg7fPm7fssIO3uIOz7IPLu5uUg6/7k 6Cwg7Psg4vH+IObo5+38IPDg4e7y4OvoIOgg7eUg5PPs4OvoLCD38u4g6iDx8uDw7vHy6CDu6uDm 5ezx/yDiIPLg6u7pIPHo8vPg9ujoLCD38u4g4+7x8+Tg8PHy4u4g7vLq4Obl8vH/IO3g7CDv7uzu 4+Dy/CDS5e/l8Pwg7vHy4OXy8f8g7eDk5f/y/PH/IPLu6/zq7iDt4CDk7uHw+/Ug6/7k5ekuPC9w Pg0KPHA+x+Dw4O3l5SDh6+Dj7uTg8P4g5+Ag6/7h8/4g7+7s7vn8LiDF8evoIML7IOfg9e7y6PLl IPHi/+fg8vzx/yDx7iDs7e7pIOgg7+7r8/fo8vwg4e7r5eUg7+7k8O7h7fP+IOjt9O7w7OD26P4g 7uHuIOzt5SDo6+gg7uEg6PHy7vDo6CDh7uvl5+3oLCDy7iDs7ukg8uXr5fTu7TogPGZvbnQgc2l6 ZT0iKzIiPjxiPjUxMS05NC0xNjwvYj48L2ZvbnQ+PC9wPg0KPGJyPg0K0ODx9+Xy7fvpIPH35fI6 IMru8O7r5eLx6u7lIM7RwSC5IDI1NzAvMDk1IMjNzTc3MDcwODM4OTMg8C7xLiC5IDMwMzAxODEw NDQwMDAwNjA0MDE3IOIg0fDl5O3l8PPx8eru7CDh4O3q5SDx4eXw4eDt6uAg0O7x8ejoIOMuIMzu 8eri4CDq7vDw5fHv7u3k5e3y8ero6SDx9+XyIDMwMTAxODEwOTAwMDAwMDAwMzIzIMPQytYgw9Mg 1sEg0NQgIO/uIMzu8eru4vHq7ukg7uHr4PHy6CDBzcoguTA0NDY1MjMyMyAg8ffl8iC5IDQyMzAx LjgxMC42LjQwMTcuMTUxMjg0Mi48YnI+DQoNCjxwPsIg4evo5uDp+OXlIOLw5ez/IP8g4fPk8yDv 8O717uTo8vwg6vPw8SDu4evz9+Xt6P8g4iDu7eru9uXt8vDlLiDP7v3y7uzzIOXx6+ggwvsg7eUg 8ezu5uXy5SDx4v/n4PL88f8g8e4g7O3u6SDv7iDy5evl9O7t8ywg7vLv8ODi/PLlLCDv7ubg6/Pp 8fLgLCDo7fTu8Ozg9uj+IOzu6Owg5+3g6u7s++wg7eAgICAgICAgICAgICAgPGEgaHJlZj0ibWFp bHRvOmxlcGVzaGtpbmFAYXBvcnQyMDAwLnJ1Ij5sZXBlc2hraW5hQGFwb3J0MjAwMC5ydTwvYT4u PC9wPg0KPHA+0SDh6+Dj7uTg8O3u8fL8/iDL5e/l+Oro7eAgzeXr6+ggyOLg7e7i7eAuPC9wPg0K DQoNCg0KDQo8L2JvZHk+DQo8L2h0bWw+DQo= --b100874abd8002f940b205e2960911ca4-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 21 18:37:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 85F7437B491 for ; Wed, 21 Feb 2001 18:37:44 -0800 (PST) (envelope-from murray@osd.bsdi.com) Received: from localhost (murray@localhost) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f1M2YL872613; Wed, 21 Feb 2001 18:34:21 -0800 (PST) (envelope-from murray@osd.bsdi.com) Date: Wed, 21 Feb 2001 18:34:21 -0800 (PST) From: Murray Stokely To: "Julian Stacey Jhs@jhs.muc.de" Cc: Sergey Babkin , Subject: Re: Creating BSD bootable CD In-Reply-To: <200102212352.f1LNqi944274@jhs.muc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Feb 2001, Julian Stacey Jhs@jhs.muc.de wrote: % I hadn't heard of mkhybrid, so investigated: it's been merged into mkisofs: I still prefer old versions of mkhybrid over the new merged mkisofs for some tricky environments. The new mkisofs will coredump with very large hybrid discs for HFS / Joliet / RR. For making FreeBSD discs however, mkisofs will do just fine. - Murray To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 0: 5:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id DFAFE37B4EC; Thu, 22 Feb 2001 00:05:12 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 3DCF23E0C; Thu, 22 Feb 2001 00:05:12 -0800 (PST) To: freebsd-hackers@freebsd.org Cc: phk@freebsd.org Subject: Listing configured md(4) devices Date: Thu, 22 Feb 2001 00:05:12 -0800 From: Dima Dorfman Message-Id: <20010222080512.3DCF23E0C@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello phk and -hackers With md(4)'s great autounit feature, it's becoming harder to keep track of md(4) devices. Without autounit, you pretty much knew what was what since you had to specify the unit number; with autounit, things like `make release` configure an arbitrary unit without telling you what it is, or even letting you change it (which isn't really necessary). jhb recently suggested that a way to get a list of active md(4) devices and the way they were configured (size, type, etc.) would be a nice remedy to the problem describe above (see "doFS.sh should obey MDDEVICE if available" on -current a few weeks back). I've come up with a relatively short patch to implement this. It adds a new ioctl, MDIOCQUERY, to get information on a configured md(4) device (it returns a filled in md_ioctl structure modulo md_file, which, I think, can't be obtained without explicitly storing the path during cofiguration (i.e., you can't derive a path from a vnode)), and uses the 'kern.disks' sysctl to find out which devices are currently configured. With it, `mdconfig -l` will list all devices and their configurations, and `mdconfig -d -u ` will print information on the device specified. Comments? Suggestions? Thanks Dima Dorfman dima@unixfreak.org Index: sys/dev/md/md.c =================================================================== RCS file: /st/src/FreeBSD/src/sys/dev/md/md.c,v retrieving revision 1.23 diff -u -r1.23 md.c --- sys/dev/md/md.c 2001/01/28 20:55:55 1.23 +++ sys/dev/md/md.c 2001/02/21 08:27:08 @@ -829,6 +829,30 @@ default: return (EOPNOTSUPP); } + case MDIOCQUERY: + sc = mdfind(mdio->md_unit); + if (sc == NULL) + return (ENOENT); + mdio->md_type = sc->type; + mdio->md_options = sc->flags; + switch (sc->type) { + case MD_MALLOC: + mdio->md_size = sc->nsect; + break; + case MD_PRELOAD: + mdio->md_size = sc->nsect; + (u_char *)(uintptr_t)mdio->md_base = sc->pl_ptr; + break; + case MD_SWAP: + mdio->md_size = sc->nsect * (PAGE_SIZE / DEV_BSIZE); + break; + case MD_VNODE: + mdio->md_size = sc->nsect; + /* XXX fill this in */ + mdio->md_file = NULL; + break; + } + return (0); default: return (ENOIOCTL); }; Index: sys/sys/mdioctl.h =================================================================== RCS file: /st/src/FreeBSD/src/sys/sys/mdioctl.h,v retrieving revision 1.7 diff -u -r1.7 mdioctl.h --- sys/sys/mdioctl.h 2001/01/01 23:08:26 1.7 +++ sys/sys/mdioctl.h 2001/02/21 08:27:08 @@ -75,6 +75,7 @@ #define MDIOCATTACH _IOWR('m', 0, struct md_ioctl) /* attach disk */ #define MDIOCDETACH _IOWR('m', 1, struct md_ioctl) /* detach disk */ +#define MDIOCQUERY _IOWR('m', 2, struct md_ioctl) /* query status */ #define MD_CLUSTER 0x01 /* Don't cluster */ #define MD_RESERVE 0x02 /* Pre-reserve swap */ Index: sbin/mdconfig/mdconfig.c =================================================================== RCS file: /st/src/FreeBSD/src/sbin/mdconfig/mdconfig.c,v retrieving revision 1.6 diff -u -r1.6 mdconfig.c --- sbin/mdconfig/mdconfig.c 2001/01/31 08:41:18 1.6 +++ sbin/mdconfig/mdconfig.c 2001/02/21 08:27:08 @@ -19,7 +19,12 @@ #include #include #include +#include +int intcmp(const void *, const void *); +int list(void); +int query(const int); + struct md_ioctl mdio; enum {UNSET, ATTACH, DETACH} action = UNSET; @@ -30,6 +35,7 @@ fprintf(stderr, "Usage:\n"); fprintf(stderr, "\tmdconfig -a -t type [-o [no]option]... [ -f file] [-s size] [-u unit]\n"); fprintf(stderr, "\tmdconfig -d -u unit\n"); + fprintf(stderr, "\tmdconfig -l [-u unit]\n"); fprintf(stderr, "\t\ttype = {malloc, preload, vnode, swap}\n"); fprintf(stderr, "\t\toption = {cluster, compress, reserve, autounit}\n"); fprintf(stderr, "\t\tsize = %%d (512 byte blocks), %%dk (kB), %%dm (MB) or %%dg (GB)\n"); @@ -41,10 +47,10 @@ { int ch, fd, i; char *p; - int cmdline = 0; + int cmdline = 0, haveunit = 0; for (;;) { - ch = getopt(argc, argv, "ab:df:o:s:t:u:"); + ch = getopt(argc, argv, "ab:df:lo:s:t:u:"); if (ch == -1) break; switch (ch) { @@ -86,6 +92,11 @@ usage(); mdio.md_file = optarg; break; + case 'l': + if (cmdline != 0) + usage(); + cmdline = 4; + break; case 'o': if (cmdline != 2) usage(); @@ -124,7 +135,7 @@ errx(1, "Unknown suffix on -s argument"); break; case 'u': - if (cmdline != 2 && cmdline != 3) + if (cmdline != 2 && cmdline != 3 && cmdline != 4) usage(); if (!strncmp(optarg, "/dev/", 5)) optarg += 5; @@ -133,12 +144,30 @@ mdio.md_unit = strtoul(optarg, NULL, 0); mdio.md_unit = strtoul(optarg, NULL, 0); mdio.md_options &= ~MD_AUTOUNIT; + haveunit = 1; break; default: usage(); } } + switch (cmdline) + { + case 0: + usage(); + /* NOTREACHED */ + case 1: + case 2: + case 3: + break; + case 4: + if (haveunit) + return (query(mdio.md_unit)); + else + return (list()); + break; + } + fd = open("/dev/mdctl", O_RDWR, 0); if (fd < 0) err(1, "open(/dev/mdctl)"); @@ -156,3 +185,75 @@ return (0); } +int +intcmp(const void *a, const void *b) +{ + + return (*(int *)a - *(int *)b); +} + +int +list(void) +{ + char *disklist, *p, *p2; + int dll; /* disklist length */ + int mds[512], *mdsp, mdsc, i; + + if (sysctlbyname("kern.disks", NULL, &dll, NULL, NULL) == -1) + err(1, "sysctlbyname: kern.disks"); + if ( (disklist = malloc(dll)) == NULL) + err(1, "malloc"); + if (sysctlbyname("kern.disks", disklist, &dll, NULL, NULL) == -1) + err(1, "sysctlbyname: kern.disks"); + + for (p = disklist, mdsp = mds, mdsc = 0; + (p2 = strsep(&p, " ")) != NULL;) { + if (strncmp(p2, "md", 2) != 0) + continue; + p2 += 2; + *mdsp = strtoul(p2, NULL, 10); + mdsc++; + if (++mdsp >= &mds[sizeof(mds)]) + break; + } + qsort(mds, mdsc, sizeof(int), intcmp); + for (i = 0; i < mdsc; i++) + query(mds[i]); + + free(disklist); + return (0); +} + +int +query(const int unit) +{ + int fd; + + mdio.md_unit = unit; + if ( (fd = open("/dev/mdctl", O_RDWR)) < 0) + err(1, "open(/dev/mdctl)"); + if (ioctl(fd, MDIOCQUERY, &mdio) < 0) + err(1, "ioctl(/dev/mdctl)"); + close(fd); + + switch (mdio.md_type) { + case MD_MALLOC: + (void)printf("md%d\tmalloc\t%d KBytes\n", + mdio.md_unit, mdio.md_size / 2); + break; + case MD_PRELOAD: + (void)printf("md%d\tpreload\t%d KBytes\n", + mdio.md_unit, mdio.md_size / 2); + break; + case MD_SWAP: + (void)printf("md%d\tswap\t%d KBytes\n", + mdio.md_unit, mdio.md_size / 2); + break; + case MD_VNODE: + (void)printf("md%d\tvnode\t%d KBytes\n", + mdio.md_unit, mdio.md_size / 2); + break; + } + + return (0); +} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 0:41:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netcetera.ch (netcetera-139.netcetera.ch [193.192.248.139]) by hub.freebsd.org (Postfix) with ESMTP id C71E437B491 for ; Thu, 22 Feb 2001 00:41:50 -0800 (PST) (envelope-from jason@netcetera.ch) Received: from disco.netcetera.ch (disco [193.192.248.144]) by (8.9.3/8.7.3) with ESMTP id JAA08403; Thu, 22 Feb 2001 09:41:32 +0100 (MET) From: Jason Brazile Received: by disco.netcetera.ch (8.9.3) id JAA03371; Thu, 22 Feb 2001 09:41:29 +0100 (MET) Date: Thu, 22 Feb 2001 09:41:29 +0100 (MET) Message-Id: <200102220841.JAA03371@disco.netcetera.ch> To: imp@harmony.village.org Cc: freebsd-hackers@freebsd.org Subject: Re: make bug? (dependency names with '$') Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > This does sound like a bug in our make :-(. A quick update: This bug does not occur with NetBSD make. I spent a couple of hours diffing the sources (there are a lot more differences than I expected) to see if there was any one small patch that would make things work for FreeBSD, but I wasn't successful. There are many patches in NetBSD make that deal specifically with '$', but apparently just adding these is not sufficient. I would need to get below this superficial view to see what's going on. There is a person with login name "will" who made a CVS log entry that says: Assume MAINTAINER. I will be taking the job of merging NetBSD/OpenBSD improvements (including :C & :L, among others). After that, I'll be coming up with other ways to improve make(1). If he is still the make maintainer for FreeBSD, can someone give me a full email address for him? Thanks, Jason ------------------------------------------------------------------------ Jason Brazile jason.brazile@netcetera.ch Netcetera AG, 8040 Zuerich phone +41 1 247 70 70 fax +41 1 247 70 75 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 0:49:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by hub.freebsd.org (Postfix) with ESMTP id EDCDB37B491 for ; Thu, 22 Feb 2001 00:49:24 -0800 (PST) (envelope-from k@numeri.campus.luth.se) Received: from numeri.campus.luth.se (localhost [127.0.0.1]) by numeri.campus.luth.se (8.11.1/8.11.1) with ESMTP id f1M8o1P81698; Thu, 22 Feb 2001 09:50:01 +0100 (CET) (envelope-from k@numeri.campus.luth.se) Message-Id: <200102220850.f1M8o1P81698@numeri.campus.luth.se> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jason Brazile Cc: imp@harmony.village.org, freebsd-hackers@FreeBSD.ORG Subject: Re: make bug? (dependency names with '$') In-Reply-To: Your message of "Thu, 22 Feb 2001 09:41:29 +0100." <200102220841.JAA03371@disco.netcetera.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 2001 09:50:01 +0100 From: Johan Karlsson Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At Thu, 22 Feb 2001 09:41:29 +0100, Jason Brazile wrote: > There is a person with login name "will" who made a CVS log entry that > says: > Assume MAINTAINER. I will be taking the job of merging > NetBSD/OpenBSD improvements (including :C & :L, among others). > After that, I'll be coming up with other ways to improve > make(1). > > If he is still the make maintainer for FreeBSD, can someone give me a > full email address for him? Try 'will@freebsd.org' :-) /Johan K To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 1:21:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 542D537B401 for ; Thu, 22 Feb 2001 01:21:22 -0800 (PST) (envelope-from K.J.Koster@kpn.com) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01K0EOEQTZF8000B79@research.kpn.com> for freebsd-hackers@FreeBSD.ORG; Thu, 22 Feb 2001 10:21:20 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Feb 2001 10:21:19 +0100 Content-return: allowed Date: Thu, 22 Feb 2001 10:21:09 +0100 From: "Koster, K.J." Subject: RE: make bug? (dependency names with '$') To: 'Jason Brazile' Cc: freebsd-hackers@FreeBSD.ORG Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7C48@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear All, > > This bug does not occur with NetBSD make. I spent a couple of hours > diffing the sources (there are a lot more differences than I expected) > There was some talk on the OpenPackages list about differences in the makes of the three BSD's. I've only followed the discussion with half an eye, but it would be nice for them too to see the makes converge, or at least iron out differences here and there. http://openpackages.org/pipermail/op-tech/ Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 1:40:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netcetera.ch (netcetera-139.netcetera.ch [193.192.248.139]) by hub.freebsd.org (Postfix) with ESMTP id A29C637B4EC for ; Thu, 22 Feb 2001 01:40:11 -0800 (PST) (envelope-from jason@netcetera.ch) Received: from disco.netcetera.ch (disco [193.192.248.144]) by (8.9.3/8.7.3) with ESMTP id KAA13432; Thu, 22 Feb 2001 10:40:10 +0100 (MET) From: Jason Brazile Received: by disco.netcetera.ch (8.9.3) id KAA03413; Thu, 22 Feb 2001 10:40:09 +0100 (MET) Date: Thu, 22 Feb 2001 10:40:09 +0100 (MET) Message-Id: <200102220940.KAA03413@disco.netcetera.ch> To: K.J.Koster@kpn.com Cc: freebsd-hackers@freebsd.org Subject: RE: make bug? (dependency names with '$') Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kees Jan wrote: > Jason Brazile wrote: > > This bug does not occur with NetBSD make. I spent a couple of hours > > diffing the sources (there are a lot more differences than I expected) > > There was some talk on the OpenPackages list about differences in the makes > of the three BSD's. I've only followed the discussion with half an eye, but > it would be nice for them too to see the makes converge, or at least iron > out differences here and there. > > http://openpackages.org/pipermail/op-tech/ Thanks for the pointer. That is a very interesting site. For those who haven't heard of it, it is an effort to unify the various BSD (NetBSD, FreeBSD, OpenBSD, BSDi, Darwin) 3rd party software packaging so that all BSDs can use the same system. As a side effect of their wanting to remove effort duplication, they are trying to also unify the various flavors of BSD make. Jason ------------------------------------------------------------------------ Jason Brazile jason.brazile@netcetera.ch Netcetera AG, 8040 Zuerich phone +41 1 247 70 70 fax +41 1 247 70 75 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 5: 8:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from samar.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id A0ACB37B65D for ; Thu, 22 Feb 2001 05:08:36 -0800 (PST) (envelope-from madhavis@sasken.com) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id SAA05239 for ; Thu, 22 Feb 2001 18:38:30 +0530 (IST) Received: from pcs111.sasi.com ([10.0.36.111]) by samar.sasi.com; Thu, 22 Feb 2001 18:38:29 +0000 (IST) Received: from localhost (madhavis@localhost) by pcs111.sasi.com (8.9.3/8.9.3) with ESMTP id SAA04089 for ; Thu, 22 Feb 2001 18:38:32 +0530 X-Authentication-Warning: pcs111.sasi.com: madhavis owned process doing -bs Date: Thu, 22 Feb 2001 18:38:32 +0530 (IST) From: Madhavi Suram X-Sender: madhavis@pcs111.sasi.com To: freebsd-hackers@FreeBSD.ORG Subject: warning in free(): Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I am running a C program in user space on FreeBSD 3.3 release. I got a warning like this: testing in free(): warning: modified (chunk-) pointer. testing is the name of the executable I am running. Could anyone tell me what this warning means? What may be the effect of this code when I shift it to kernel with due modifications? I have put this code in kernel and when this gets executed, I get a panic immediately or some time later. This happens even if I don't execute any command after this code. When the kernel reboots, it reports file system inconsistencies and goes into single user mode. When I do 'fsck' and reboot it, it gets rebooted to multi-user mode. I am totally lost. Any help in this regard will be appreciated. thanks and regards Madhavi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 5:13:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 371BE37B503 for ; Thu, 22 Feb 2001 05:13:12 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1MDD2c04118; Thu, 22 Feb 2001 05:13:02 -0800 (PST) Date: Thu, 22 Feb 2001 05:13:02 -0800 From: Alfred Perlstein To: Madhavi Suram Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: warning in free(): Message-ID: <20010222051302.E29126@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from madhavis@sasken.com on Thu, Feb 22, 2001 at 06:38:32PM +0530 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Madhavi Suram [010222 05:09] wrote: > > Hi > > I am running a C program in user space on FreeBSD 3.3 release. I got a > warning like this: > > testing in free(): warning: modified (chunk-) pointer. > > testing is the name of the executable I am running. > > Could anyone tell me what this warning means? What may be the effect of > this code when I shift it to kernel with due modifications? It means you've most likely corrupted your malloc pool, meaning you've written past/before the edge of an allocation you've done. To fix it start being mor careful with pointers and checking array bounds. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 5:15:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fxp0.halvsten.ip.cybercity.dk [212.242.40.114]) by hub.freebsd.org (Postfix) with ESMTP id C91E137B491 for ; Thu, 22 Feb 2001 05:15:49 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1MDFj502868; Thu, 22 Feb 2001 14:15:45 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Madhavi Suram Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: warning in free(): In-Reply-To: Your message of "Thu, 22 Feb 2001 18:38:32 +0530." Date: Thu, 22 Feb 2001 14:15:45 +0100 Message-ID: <2866.982847745@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Madhavi S uram writes: > >Hi > >I am running a C program in user space on FreeBSD 3.3 release. I got a >warning like this: > > testing in free(): warning: modified (chunk-) pointer. > >testing is the name of the executable I am running. > >Could anyone tell me what this warning means? What may be the effect of >this code when I shift it to kernel with due modifications? It means that you do something like this: ... p = malloc(n); /* N <=2048 */ p += m; free(p); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 5:19:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cyclone.eis.ru (www.for.spb.ru [195.201.69.16]) by hub.freebsd.org (Postfix) with SMTP id CF10237B401 for ; Thu, 22 Feb 2001 05:19:51 -0800 (PST) (envelope-from diwil@eis.ru) Received: (qmail 53266 invoked from network); 22 Feb 2001 13:25:57 -0000 Received: from unknown (HELO runnet-gw.marketsite.ru) (195.201.69.80) by for.spb.ru with SMTP; 22 Feb 2001 13:25:57 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010222051302.E29126@fw.wintelcom.net> Date: Thu, 22 Feb 2001 16:16:54 +0300 (MSK) Reply-To: diwil@eis.ru From: Dmitry Dicky To: freebsd-hackers@FreeBSD.ORG Subject: Re: warning in free(): Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Also, if you do something like: void *ptr = malloc(size); ... ptr++; free() will complain about it. Make sure you are not modifying ptr after it has been malloc()ed. On 22-Feb-01 Alfred Perlstein wrote: > * Madhavi Suram [010222 05:09] wrote: >> >> Hi >> >> I am running a C program in user space on FreeBSD 3.3 release. I got a >> warning like this: >> >> testing in free(): warning: modified (chunk-) pointer. >> >> testing is the name of the executable I am running. >> >> Could anyone tell me what this warning means? What may be the effect >> of >> this code when I shift it to kernel with due modifications? > > It means you've most likely corrupted your malloc pool, meaning you've > written past/before the edge of an allocation you've done. > > To fix it start being mor careful with pointers and checking array > bounds. > > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- ********************************************************************* ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44 _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia (il),-'' (li),' ((!.-' +7 (812) 3148860, 5585314 ********************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 7:35:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from attila.stevens-tech.edu (attila.stevens-tech.edu [155.246.14.11]) by hub.freebsd.org (Postfix) with ESMTP id 3502937B6A0 for ; Thu, 22 Feb 2001 07:35:16 -0800 (PST) (envelope-from jmcknigh@stevens-tech.edu) Received: from glitch2 (jmcknigh-1.u04.stevens-tech.edu [155.246.203.37]) by attila.stevens-tech.edu (SGI-8.9.3/8.9.3/7) with SMTP id KAA21476 for ; Thu, 22 Feb 2001 10:35:15 -0500 (EST) From: "Justin McKnight" To: "FreeBSD-newbies" Subject: Compaq e500, 3com cardbus card help Date: Thu, 22 Feb 2001 10:32:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I cant figure out to get freebsd 4.2 to recognize and enable my 3com cardbus card? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 7:38: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bumper.jellybaby.net (bumper.jellybaby.net [194.159.247.1]) by hub.freebsd.org (Postfix) with ESMTP id 6126137B4EC for ; Thu, 22 Feb 2001 07:37:55 -0800 (PST) (envelope-from simond@bumper.jellybaby.net) Received: (from simond@localhost) by bumper.jellybaby.net (8.9.2/8.9.2) id PAA99111; Thu, 22 Feb 2001 15:37:44 GMT (envelope-from simond) Date: Thu, 22 Feb 2001 15:37:43 +0000 From: simond@irrelevant.org To: Justin McKnight Cc: FreeBSD-newbies Subject: Re: Compaq e500, 3com cardbus card help Message-ID: <20010222153743.C87266@irrelevant.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jmcknigh@stevens-tech.edu on Thu, Feb 22, 2001 at 10:32:13AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 22, 2001 at 10:32:13AM -0500, Justin McKnight wrote: > I cant figure out to get freebsd 4.2 to recognize > and enable my 3com cardbus card? FreeBSD currently doesn't support cardbus cards. -- Simon Dick simond@irrelevant.org "Why do I get this urge to go bowling everytime I see Tux?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 7:45:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id D222837B4EC for ; Thu, 22 Feb 2001 07:45:28 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Thu, 22 Feb 2001 16:43:22 +0100 (MET) Message-Id: <4.3.0.20010222164121.0594c510@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 22 Feb 2001 16:45:42 +0100 To: diwil@eis.ru, freebsd-hackers@FreeBSD.ORG From: mouss Subject: Re: warning in free(): In-Reply-To: References: <20010222051302.E29126@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Now having free() write to stdout/stderr isn't necessarily a good thing for daemons. If the message goes through a socket, it'll be hard to debug, which was the original intent. I suggest having some way so that when a program becomes a daemon, it can set some "silent-libc" or "libc messages go to logs" instead of using stdout/stderr. Wouldn't it not be cool if err() and warn() had the capability of using syslog instead of a file or std* when needed. err_set_file allows one to use a file instead. How about allowing the use of syslog? At 16:16 22/02/01 +0300, Dmitry Dicky wrote: >Also, if you do something like: > > void *ptr = malloc(size); > >... > ptr++; > >free() will complain about it. >Make sure you are not modifying ptr after it has been malloc()ed. > > >On 22-Feb-01 Alfred Perlstein wrote: > > * Madhavi Suram [010222 05:09] wrote: > >> > >> Hi > >> > >> I am running a C program in user space on FreeBSD 3.3 release. I got a > >> warning like this: > >> > >> testing in free(): warning: modified (chunk-) pointer. > >> > >> testing is the name of the executable I am running. > >> > >> Could anyone tell me what this warning means? What may be the effect > >> of > >> this code when I shift it to kernel with due modifications? > > > > It means you've most likely corrupted your malloc pool, meaning you've > > written past/before the edge of an allocation you've done. > > > > To fix it start being mor careful with pointers and checking array > > bounds. > > > > > > -- > > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > >-- >********************************************************************* > ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ > `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys > (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44 > _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia > (il),-'' (li),' ((!.-' +7 (812) 3148860, 5585314 >********************************************************************* > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 7:54:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 8503237B4EC for ; Thu, 22 Feb 2001 07:54:46 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (i077-134.nv.iinet.net.au [203.59.77.134]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id XAA00219; Thu, 22 Feb 2001 23:54:28 +0800 Message-ID: <3A953617.CD81D643@elischer.org> Date: Thu, 22 Feb 2001 07:53:59 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Robin Cutshaw Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Build timings - FreeBSD 4.2 vs. Linux References: <20010219134043.A8347@intercore.com> <200102192021.f1JKLQr61572@mobile.wemm.org> <20010221090207.A11473@intercore.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robin Cutshaw wrote: > > On Mon, Feb 19, 2001 at 12:21:26PM -0800, Peter Wemm wrote: > > > > > > Any ideas as to why it would take almost three times longer to build > > > on FreeBSD? > > > > This is probably a silly question, but you did recompile the kernel for > > SMP, right? > > > > Actually, I was using the stock GENERIC UP kernel. I wanted to get a > baseline. > > > Have you tuned the FreeBSD kernel? It still ships with a worst-case > > configuration so that it runs optimally on i386 cpus. :-( Copy GENERIC > > to something else and remove all but 'cpu i686', rebuild and install. > > Also, get rid of 'sl', and 'ppp' from the kernel config as that messes > > up certain things (interrupt masks). Ideally, do a proper cleanup and > > configure it for your specific hardware (ie: remove all the other ethernet > > drivers, etc). > > > > There's a problem here. I tried to configure an SMP kernel but when it > booted the fxp0 (Compaq dual eepro100 adapter) got timeout errors and > wouldn't work. I went back and did the config/make on the GENERIC > kernel and booted it. Same thing. The stock GENERIC kernel that came > with the dist works just fine. Any ideas? > > One other problem I've seen with the Compaq 8500 system. FreeBSD doesn't > see the pci adapter on the secondary bus. I had to move the ethernet > adapter to the primary bus for it to work. > > > > > A couple of possibilities.. If you want to compare the two side by side, > > try mounting the freebsd filesystems in async mode, just like linux does by > > default. In particular, make sure you get /tmp, /var/tmp and wherever your > > build is. > > > > OK, I set softupdates on the disk/partition that the build source/target > is on. It made no difference in timing. I then created a memory disk, > set softupdates on it, and mounted it as /tmp. soft updates is pointless on a ram disk. but it makes a huge difference if /tmp is on disk. > AMAZINGLY, the build > went from 2:50 to 0:40, now much faster than the Linux system. I'm > going to do the ram disk thing on Linux and see if it makes a difference. turn soft updtes off again on it.. it is just wasting CPU cycles. > > Once I figure out the fxp0 problem from above, I'll do a parallel build > and see what speedups occur. > > Thanks! > Robin > -- > ---- > Robin Cutshaw internet: robin@interlabs.com robin@intercore.com > Internet Labs, Inc. BellNet: 404-713-4000 robin@XFree86.Org > XFree86 coreteam/board member > > "Time is just one damn thing after another" -- PBS/Nova > ---- > -- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 8:43:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.193.193.101]) by hub.freebsd.org (Postfix) with ESMTP id 3FFC537B503 for ; Thu, 22 Feb 2001 08:43:46 -0800 (PST) (envelope-from diman@asd-g.com) Received: from core.is.kiev.ua (p187.is.kiev.ua [62.244.5.187] (may be forged)) by sivka.carrier.kiev.ua (8/Kilkenny_is_better) with ESMTP id SPA92270; Thu, 22 Feb 2001 18:39:02 +0200 (EET) (envelope-from diman@asd-g.com) Received: from ergo.local ([10.203.1.10]) by core.is.kiev.ua (8.11.1/ASDG-2.3-NR) with ESMTP id f1MGd0d81077; Thu, 22 Feb 2001 18:39:00 +0200 (EET) (envelope-from diman@asd-g.com) Date: Thu, 22 Feb 2001 18:37:55 +0200 (EET) From: diman X-Sender: diman@portal.none.ua To: mouss Cc: diwil@eis.ru, freebsd-hackers@FreeBSD.ORG Subject: Re: warning in free(): In-Reply-To: <4.3.0.20010222164121.0594c510@pop.free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Feb 2001, mouss wrote: > Now having free() write to stdout/stderr isn't necessarily a good thing > for daemons. If the message goes through a socket, it'll be hard to > debug, which was the original intent. > > I suggest having some way so that when a program becomes a daemon, > it can set some "silent-libc" or "libc messages go to logs" instead of > using stdout/stderr. > > Wouldn't it not be cool if err() and warn() had the capability of using syslog > instead of a file or std* when needed. err_set_file allows one to use a file > instead. How about allowing the use of syslog? Open AF_UNIX socket to syslogd and then use err_set_file() to redirect all err/warn messages to syslogd instead of stdin/stdout. That should help you debug daemons. Best Regards To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 9:15:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id A23DE37B503 for ; Thu, 22 Feb 2001 09:15:17 -0800 (PST) (envelope-from culverk@wam.umd.edu) Received: from rac3.wam.umd.edu (IDENT:root@rac3.wam.umd.edu [128.8.10.143]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id MAA11684; Thu, 22 Feb 2001 12:15:08 -0500 (EST) Received: from rac3.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac3.wam.umd.edu (8.9.3/8.9.3) with SMTP id MAA05027; Thu, 22 Feb 2001 12:15:08 -0500 (EST) Received: from localhost (culverk@localhost) by rac3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id MAA05023; Thu, 22 Feb 2001 12:15:08 -0500 (EST) X-Authentication-Warning: rac3.wam.umd.edu: culverk owned process doing -bs Date: Thu, 22 Feb 2001 12:15:08 -0500 (EST) From: Kenneth Wayne Culver To: simond@irrelevant.org Cc: Justin McKnight , FreeBSD-newbies Subject: Re: Compaq e500, 3com cardbus card help In-Reply-To: <20010222153743.C87266@irrelevant.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FreeBSD supports cardbus in -CURRENT, but I wouldn't expect it to ever support cardbus in 4.x. If you are daring you can get -CURRENT, but from what I hear right now, it's not working very well. ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Thu, 22 Feb 2001 simond@irrelevant.org wrote: > On Thu, Feb 22, 2001 at 10:32:13AM -0500, Justin McKnight wrote: > > I cant figure out to get freebsd 4.2 to recognize > > and enable my 3com cardbus card? > > FreeBSD currently doesn't support cardbus cards. > > -- > Simon Dick simond@irrelevant.org > "Why do I get this urge to go bowling everytime I see Tux?" > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 10:40:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from link.mirror.org (link.mirror.org [216.38.7.35]) by hub.freebsd.org (Postfix) with ESMTP id A512F37B491 for ; Thu, 22 Feb 2001 10:40:20 -0800 (PST) (envelope-from sgt@netcom.no) Received: from hal (1-d11-1.svg1.netcom.no [212.45.183.2]) by link.mirror.org (8.7.5/8.7.3) with ESMTP id NAA14478 for ; Thu, 22 Feb 2001 13:38:46 -0500 Date: Thu, 22 Feb 2001 19:40:16 +0100 (CET) From: Torbjorn Kristoffersen X-Sender: To: FreeBSD-Hackers Subject: IOmega ZIP problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). Whenever I copy a large file from the zip drive (for example /dev/da0s1), the "cp" process eats 98% of the system resources. What's behind all this? Is there a way to fix it? 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp A 'renice' won't help. -- Thanks in advance, Torbjorn Kristoffersen sgt@netcom.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 10:55:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id E064237B491 for ; Thu, 22 Feb 2001 10:55:44 -0800 (PST) (envelope-from usebsd@free.fr) Received: by smtp.nettoll.com; Thu, 22 Feb 2001 19:52:34 +0100 (MET) Message-Id: <4.3.0.20010222194459.0242d850@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 22 Feb 2001 19:54:54 +0100 To: diman From: mouss Subject: Re: warning in free(): Cc: diwil@eis.ru, freebsd-hackers@FreeBSD.ORG In-Reply-To: References: <4.3.0.20010222164121.0594c510@pop.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 18:37 22/02/01 +0200, diman wrote: >Open AF_UNIX socket to syslogd and then use err_set_file() >to redirect all err/warn messages to syslogd instead of >stdin/stdout. That should help you debug daemons. I agree, but one of the nice things about syslog interface is that it hides all the socket/device stuff. so getting back to the socket api is somewhat unsatisfactory. Also, I think having this directly in err() and warn() and friends would be more elegant. and this doesn't seem hard to do. something like using a function pointer to use fprintf or syslog, and an additionnal void* to use either err_file or syslog priority. Does this sound ok or is it an unuseful complication of code? cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 11:19:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 52F0237B401 for ; Thu, 22 Feb 2001 11:19:22 -0800 (PST) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 7FFD559520; Thu, 22 Feb 2001 13:19:33 -0600 (CST) Date: Thu, 22 Feb 2001 13:19:33 -0600 From: "Michael C . Wu" To: Torbjorn Kristoffersen Cc: FreeBSD-Hackers Subject: Re: IOmega ZIP problem Message-ID: <20010222131933.C20955@peorth.iteration.net> Reply-To: "Michael C . Wu" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sgt@netcom.no on Thu, Feb 22, 2001 at 07:40:16PM +0100 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). | Whenever I copy a large file from the zip drive (for example /dev/da0s1), | the "cp" process eats 98% of the system resources. What's behind all this? | Is there a way to fix it? | | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp | | A 'renice' won't help. That's natural with "parallel". No way around it. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 11:31:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 96F4437B65D; Thu, 22 Feb 2001 11:31:32 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1MJVTh50321; Thu, 22 Feb 2001 14:31:30 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 22 Feb 2001 14:31:29 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dima Dorfman Cc: freebsd-hackers@freebsd.org, phk@freebsd.org Subject: Re: Listing configured md(4) devices In-Reply-To: <20010222080512.3DCF23E0C@bazooka.unixfreak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The only comments I really had on this were: 1) Your comment about vnode->name mapping is correct, there is no way to turn a vnode pointer into an absolute path meaningful to the caller. There are countless reasons why believing this is possible is a bad idea, and we keep having to hit people with sticks to remind them that this is the case. :-) 2) I'm not sure I like the strncmp(.., "md", 2) stuff, as that means that it would also match any other device name that might begin with md, which potentially might not be provided by the md driver. This is currently (I suspect) hypothetical as we don't have any other drivers beginning with md, but it would be nice not to preclude that in the future. Restricting all possible disk device names to two letters, of which the second is always d, is not a scalable approach. That said, writing an easy matching function without that assumption probably isn't all that easy, either. Don't know what the right answer is, so I'm just saying I'm not sure I like it, not saying, change it. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 22 Feb 2001, Dima Dorfman wrote: > Hello phk and -hackers > > With md(4)'s great autounit feature, it's becoming harder to keep > track of md(4) devices. Without autounit, you pretty much knew what > was what since you had to specify the unit number; with autounit, > things like `make release` configure an arbitrary unit without telling > you what it is, or even letting you change it (which isn't really > necessary). > > jhb recently suggested that a way to get a list of active md(4) > devices and the way they were configured (size, type, etc.) would be a > nice remedy to the problem describe above (see "doFS.sh should obey > MDDEVICE if available" on -current a few weeks back). > > I've come up with a relatively short patch to implement this. It adds > a new ioctl, MDIOCQUERY, to get information on a configured md(4) > device (it returns a filled in md_ioctl structure modulo md_file, > which, I think, can't be obtained without explicitly storing the path > during cofiguration (i.e., you can't derive a path from a vnode)), and > uses the 'kern.disks' sysctl to find out which devices are currently > configured. With it, `mdconfig -l` will list all devices and their > configurations, and `mdconfig -d -u ` will print information on the > device specified. > > Comments? Suggestions? > > Thanks > > Dima Dorfman > dima@unixfreak.org > > > Index: sys/dev/md/md.c > =================================================================== > RCS file: /st/src/FreeBSD/src/sys/dev/md/md.c,v > retrieving revision 1.23 > diff -u -r1.23 md.c > --- sys/dev/md/md.c 2001/01/28 20:55:55 1.23 > +++ sys/dev/md/md.c 2001/02/21 08:27:08 > @@ -829,6 +829,30 @@ > default: > return (EOPNOTSUPP); > } > + case MDIOCQUERY: > + sc = mdfind(mdio->md_unit); > + if (sc == NULL) > + return (ENOENT); > + mdio->md_type = sc->type; > + mdio->md_options = sc->flags; > + switch (sc->type) { > + case MD_MALLOC: > + mdio->md_size = sc->nsect; > + break; > + case MD_PRELOAD: > + mdio->md_size = sc->nsect; > + (u_char *)(uintptr_t)mdio->md_base = sc->pl_ptr; > + break; > + case MD_SWAP: > + mdio->md_size = sc->nsect * (PAGE_SIZE / DEV_BSIZE); > + break; > + case MD_VNODE: > + mdio->md_size = sc->nsect; > + /* XXX fill this in */ > + mdio->md_file = NULL; > + break; > + } > + return (0); > default: > return (ENOIOCTL); > }; > Index: sys/sys/mdioctl.h > =================================================================== > RCS file: /st/src/FreeBSD/src/sys/sys/mdioctl.h,v > retrieving revision 1.7 > diff -u -r1.7 mdioctl.h > --- sys/sys/mdioctl.h 2001/01/01 23:08:26 1.7 > +++ sys/sys/mdioctl.h 2001/02/21 08:27:08 > @@ -75,6 +75,7 @@ > > #define MDIOCATTACH _IOWR('m', 0, struct md_ioctl) /* attach disk */ > #define MDIOCDETACH _IOWR('m', 1, struct md_ioctl) /* detach disk */ > +#define MDIOCQUERY _IOWR('m', 2, struct md_ioctl) /* query status */ > > #define MD_CLUSTER 0x01 /* Don't cluster */ > #define MD_RESERVE 0x02 /* Pre-reserve swap */ > Index: sbin/mdconfig/mdconfig.c > =================================================================== > RCS file: /st/src/FreeBSD/src/sbin/mdconfig/mdconfig.c,v > retrieving revision 1.6 > diff -u -r1.6 mdconfig.c > --- sbin/mdconfig/mdconfig.c 2001/01/31 08:41:18 1.6 > +++ sbin/mdconfig/mdconfig.c 2001/02/21 08:27:08 > @@ -19,7 +19,12 @@ > #include > #include > #include > +#include > > +int intcmp(const void *, const void *); > +int list(void); > +int query(const int); > + > struct md_ioctl mdio; > > enum {UNSET, ATTACH, DETACH} action = UNSET; > @@ -30,6 +35,7 @@ > fprintf(stderr, "Usage:\n"); > fprintf(stderr, "\tmdconfig -a -t type [-o [no]option]... [ -f file] [-s size] [-u unit]\n"); > fprintf(stderr, "\tmdconfig -d -u unit\n"); > + fprintf(stderr, "\tmdconfig -l [-u unit]\n"); > fprintf(stderr, "\t\ttype = {malloc, preload, vnode, swap}\n"); > fprintf(stderr, "\t\toption = {cluster, compress, reserve, autounit}\n"); > fprintf(stderr, "\t\tsize = %%d (512 byte blocks), %%dk (kB), %%dm (MB) or %%dg (GB)\n"); > @@ -41,10 +47,10 @@ > { > int ch, fd, i; > char *p; > - int cmdline = 0; > + int cmdline = 0, haveunit = 0; > > for (;;) { > - ch = getopt(argc, argv, "ab:df:o:s:t:u:"); > + ch = getopt(argc, argv, "ab:df:lo:s:t:u:"); > if (ch == -1) > break; > switch (ch) { > @@ -86,6 +92,11 @@ > usage(); > mdio.md_file = optarg; > break; > + case 'l': > + if (cmdline != 0) > + usage(); > + cmdline = 4; > + break; > case 'o': > if (cmdline != 2) > usage(); > @@ -124,7 +135,7 @@ > errx(1, "Unknown suffix on -s argument"); > break; > case 'u': > - if (cmdline != 2 && cmdline != 3) > + if (cmdline != 2 && cmdline != 3 && cmdline != 4) > usage(); > if (!strncmp(optarg, "/dev/", 5)) > optarg += 5; > @@ -133,12 +144,30 @@ > mdio.md_unit = strtoul(optarg, NULL, 0); > mdio.md_unit = strtoul(optarg, NULL, 0); > mdio.md_options &= ~MD_AUTOUNIT; > + haveunit = 1; > break; > default: > usage(); > } > } > > + switch (cmdline) > + { > + case 0: > + usage(); > + /* NOTREACHED */ > + case 1: > + case 2: > + case 3: > + break; > + case 4: > + if (haveunit) > + return (query(mdio.md_unit)); > + else > + return (list()); > + break; > + } > + > fd = open("/dev/mdctl", O_RDWR, 0); > if (fd < 0) > err(1, "open(/dev/mdctl)"); > @@ -156,3 +185,75 @@ > return (0); > } > > +int > +intcmp(const void *a, const void *b) > +{ > + > + return (*(int *)a - *(int *)b); > +} > + > +int > +list(void) > +{ > + char *disklist, *p, *p2; > + int dll; /* disklist length */ > + int mds[512], *mdsp, mdsc, i; > + > + if (sysctlbyname("kern.disks", NULL, &dll, NULL, NULL) == -1) > + err(1, "sysctlbyname: kern.disks"); > + if ( (disklist = malloc(dll)) == NULL) > + err(1, "malloc"); > + if (sysctlbyname("kern.disks", disklist, &dll, NULL, NULL) == -1) > + err(1, "sysctlbyname: kern.disks"); > + > + for (p = disklist, mdsp = mds, mdsc = 0; > + (p2 = strsep(&p, " ")) != NULL;) { > + if (strncmp(p2, "md", 2) != 0) > + continue; > + p2 += 2; > + *mdsp = strtoul(p2, NULL, 10); > + mdsc++; > + if (++mdsp >= &mds[sizeof(mds)]) > + break; > + } > + qsort(mds, mdsc, sizeof(int), intcmp); > + for (i = 0; i < mdsc; i++) > + query(mds[i]); > + > + free(disklist); > + return (0); > +} > + > +int > +query(const int unit) > +{ > + int fd; > + > + mdio.md_unit = unit; > + if ( (fd = open("/dev/mdctl", O_RDWR)) < 0) > + err(1, "open(/dev/mdctl)"); > + if (ioctl(fd, MDIOCQUERY, &mdio) < 0) > + err(1, "ioctl(/dev/mdctl)"); > + close(fd); > + > + switch (mdio.md_type) { > + case MD_MALLOC: > + (void)printf("md%d\tmalloc\t%d KBytes\n", > + mdio.md_unit, mdio.md_size / 2); > + break; > + case MD_PRELOAD: > + (void)printf("md%d\tpreload\t%d KBytes\n", > + mdio.md_unit, mdio.md_size / 2); > + break; > + case MD_SWAP: > + (void)printf("md%d\tswap\t%d KBytes\n", > + mdio.md_unit, mdio.md_size / 2); > + break; > + case MD_VNODE: > + (void)printf("md%d\tvnode\t%d KBytes\n", > + mdio.md_unit, mdio.md_size / 2); > + break; > + } > + > + return (0); > +} > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 12:32:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from herbelot.dyndns.org (s014.dhcp212-24.cybercable.fr [212.198.24.14]) by hub.freebsd.org (Postfix) with ESMTP id 64CFD37B4EC for ; Thu, 22 Feb 2001 12:32:48 -0800 (PST) (envelope-from thierry.herbelot@free.fr) Received: from free.fr (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id VAA18150 for ; Thu, 22 Feb 2001 21:32:42 +0100 (CET) (envelope-from thierry.herbelot@free.fr) Message-ID: <3A95776A.1E76A7B@free.fr> Date: Thu, 22 Feb 2001 21:32:42 +0100 From: Thierry Herbelot X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: detecting a closing socket from a Lex/Yacc interpreter ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I'm currently writing a small interpreter for a client/server application. the Lex and Yacc files seem to be OK, as the tests are running fine (as long as there is only one client, and the client dos not close its socket ...) I still have one problem : the server has a single thread : the process accept()s a connection, then processes the commands (with yyparse()), and after the current client disconnects, gets back to listening to the socket, and so on. the problem is that the yyparse() function does not return when the socket is closed. I've had a look at the sources of ftpd, where yacc is used, but from what I've seen, the yylex() function has been hand written (which I would like not to do) I've added a <> target in the lex file, but it does not seem to detect the socket close() taker for any solution, TfH -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 13:18:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cx420564-b.tucson1.az.home.com (cx420564-b.tucson1.az.home.com [24.21.112.225]) by hub.freebsd.org (Postfix) with ESMTP id D2F7837B401 for ; Thu, 22 Feb 2001 13:18:34 -0800 (PST) (envelope-from fracture@cx420564-b.tucson1.az.home.com) Received: (from fracture@localhost) by cx420564-b.tucson1.az.home.com (8.11.1/8.11.1) id f1MEACi09466; Thu, 22 Feb 2001 14:10:12 GMT (envelope-from fracture) Date: Thu, 22 Feb 2001 14:09:11 +0000 From: Jordan DeLong To: Thierry Herbelot Cc: hackers@FreeBSD.ORG Subject: Re: detecting a closing socket from a Lex/Yacc interpreter ? Message-ID: <20010222140911.A9405@cx420564-b.tucson1.az.home.com> References: <3A95776A.1E76A7B@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A95776A.1E76A7B@free.fr>; from thierry.herbelot@free.fr on Thu, Feb 22, 2001 at 09:32:42PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm assuming right now you are just setting yyin to the fd for the socket. What you're gonna want to do is define the macro YY_INPUT (see the man page for details) so that it calls recv on your socket. and then if it errors you can have YY_INPUT return as an EOF and your <> rule will work fine. On Thu, Feb 22, 2001 at 09:32:42PM +0100, Thierry Herbelot wrote: > Hello, > > I'm currently writing a small interpreter for a client/server > application. > > the Lex and Yacc files seem to be OK, as the tests are running fine (as > long as there is only one client, and the client dos not close its > socket ...) > > I still have one problem : the server has a single thread : the process > accept()s a connection, then processes the commands (with yyparse()), > and after the current client disconnects, gets back to listening to the > socket, and so on. > > the problem is that the yyparse() function does not return when the > socket is closed. I've had a look at the sources of ftpd, where yacc is > used, but from what I've seen, the yylex() function has been hand > written (which I would like not to do) > > I've added a <> target in the lex file, but it does not seem to > detect the socket close() > > taker for any solution, > > TfH > -- > Thierry Herbelot > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 13:56:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id 57D6837B401 for ; Thu, 22 Feb 2001 13:56:07 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f1MLtbc09056 for ; Thu, 22 Feb 2001 13:55:37 -0800 (PST) Received: from louie.fa.disney.com by pain.corp.disney.com with ESMTP for freebsd-hackers@freebsd.org; Thu, 22 Feb 2001 13:56:42 -0800 Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by louie.fa.disney.com (8.9.2/8.9.2) with ESMTP id NAA24483 for ; Thu, 22 Feb 2001 13:56:04 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) Received: from snoopy.fan.fa.disney.com by mercury.fan.fa.disney.com for freebsd-hackers@freebsd.org; Thu, 22 Feb 2001 13:56:04 -0800 From: Jim Pirzyk Organization: Walt Disney Feature Animation To: freebsd-hackers@freebsd.org Subject: gdb and debugging Linux binaries Date: Thu, 22 Feb 2001 13:55:07 -0800 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01022213560407.44596@snoopy.fan.fa.disney.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a question on how to debug Linux binaries. I have a core file from the linux binary, but if I use the FreeBSD gdb, it cannot find the shared libraries in /compat/linux/.... If I use the /compat/linux/ /usr/bin/gdb, it says the core file is in the wrong format: Couldn't fetch registers from core file: File in wrong format Couldn't fetch register set 2 from core file: File in wrong format So what is the correct procedure for debugging Linux binaries? - JimP -- --- @(#) $Id: dot.signature,v 1.9 2000/07/10 16:43:05 pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------------------------------- _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 14:10:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 3DFC637B401 for ; Thu, 22 Feb 2001 14:10:16 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1MMAG505154; Thu, 22 Feb 2001 23:10:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: mouss Cc: diwil@eis.ru, freebsd-hackers@FreeBSD.ORG Subject: Re: warning in free(): In-Reply-To: Your message of "Thu, 22 Feb 2001 16:45:42 +0100." <4.3.0.20010222164121.0594c510@pop.free.fr> Date: Thu, 22 Feb 2001 23:10:16 +0100 Message-ID: <5152.982879816@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <4.3.0.20010222164121.0594c510@pop.free.fr>, mouss writes: >Now having free() write to stdout/stderr isn't necessarily a good thing >for daemons. If the message goes through a socket, it'll be hard to >debug, which was the original intent. > >I suggest having some way so that when a program becomes a daemon, >it can set some "silent-libc" or "libc messages go to logs" instead of >using stdout/stderr. Since some time ago, there is an API to control how the messages from malloc is output, look for "malloc_message" in malloc(3). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 14:50:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from out.newmail.net (out.newmail.net [212.150.54.158]) by hub.freebsd.org (Postfix) with SMTP id AA4BB37B4EC; Thu, 22 Feb 2001 14:50:19 -0800 (PST) (envelope-from idobarnea@NewMail.Net) Received: from newmail.net ([10.10.1.75]) by out.newmail.net ; Thu, 22 Feb 2001 20:49:42 +0200 From: idobarnea@NewMail.Net Reply-To: idobarnea@NewMail.Net To: Ruslan Ermilov , idobarnea@NewMail.Net, bmilekic@FreeBSD.org, mouss , hackers@FreeBSD.org Date: Thu, 22 Feb 2001 20:44:41 Gmt +0200 Subject: Re: Bug in creating ICMP error messages in FreeBSD4.2 Message-id: <3a957a39.178.0@NewMail.Net> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >[redirected to -net] > >On Wed, Feb 21, 2001 at 09:50:58AM +0000, idobarnea@NewMail.Net wrote: >> >On Mon, Feb 19, 2001 at 08:26:56PM +0100, mouss wrote: >> > > At 14:25 19/02/01 +0200, idobarnea@NewMail.Net wrote: >> > > > Hi, >> > > > I encountered the following problem in the 4.2 version. >> > > > In ip_forward, the following lines intend to save the mbuf in >> > > > case we want to send ICMP error later: >> > > > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); >> > > > if (mcopy && (mcopy->m_flags & M_EXT)) >> > > > m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); >> > > > >> > > > Later on, before sending the ICMP packet we do: >> > > > if (mcopy->m_flags & M_EXT) >> > > > m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); >> > > > >> > > > The problem as I understand it is that the m_copydata and m_copyback, >> > > > actually do nothing (It just copies from mcopy to itself). >> >You are right, the code does nothing, though it was supposed to >preserve the byte order of IP header fields in case ip_output() >modifies them. The idea was to save the standard IP header in >some area in mbuf that is unused for M_EXT mbufs, but obviously >mtod() place is wrong, it points to the external data for M_EXT >mbuf. Could you please try this patch: > >Index: ip_input.c >=================================================================== >RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v >retrieving revision 1.130.2.12 >diff -u -p -r1.130.2.12 ip_input.c >--- ip_input.c 2001/02/01 20:25:09 1.130.2.12 >+++ ip_input.c 2001/02/21 16:48:10 >@@ -1513,7 +1513,8 @@ ip_forward(m, srcrt) > */ > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); > if (mcopy && (mcopy->m_flags & M_EXT)) >- m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); >+ m_copydata(mcopy, 0, sizeof(struct ip), >+ (caddr_t)(&mcopy->m_ext + 1)); > > #ifdef IPSTEALTH > if (!ipstealth) { >@@ -1661,7 +1662,8 @@ ip_forward(m, srcrt) > return; > } > if (mcopy->m_flags & M_EXT) >- m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); >+ m_copyback(mcopy, 0, sizeof(struct ip), >+ (caddr_t)(&mcopy->m_ext + 1)); > icmp_error(mcopy, type, code, dest, destifp); > } > >And if that does not work, this (more clear but slower) one: > >Index: ip_input.c >=================================================================== >RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v >retrieving revision 1.130.2.13 >diff -u -p -r1.130.2.13 ip_input.c >--- ip_input.c 2001/02/07 01:03:13 1.130.2.13 >+++ ip_input.c 2001/02/21 16:10:35 >@@ -1510,9 +1510,17 @@ ip_forward(m, srcrt) > * we need to generate an ICMP message to the src. > */ > mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); >- if (mcopy && (mcopy->m_flags & M_EXT)) >- m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); > >+ /* >+ * Make sure the copy is read-write. >+ */ >+ if (mcopy && (mcopy->m_flags & M_EXT)) { >+ struct mbuf *mtemp = mcopy; >+ >+ mcopy = m_dup(mtemp, M_DONTWAIT); >+ m_freem(mtemp); >+ } >+ > #ifdef IPSTEALTH > if (!ipstealth) { > #endif >@@ -1658,8 +1666,6 @@ ip_forward(m, srcrt) > m_freem(mcopy); > return; > } >- if (mcopy->m_flags & M_EXT) >- m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); > icmp_error(mcopy, type, code, dest, destifp); > } > > >Cheers, >-- >Ruslan Ermilov Oracle Developer/DBA, >ru@sunbay.com Sunbay Software AG, >ru@FreeBSD.org FreeBSD committer, >+380.652.512.251 Simferopol, Ukraine > >http://www.FreeBSD.org The Power To Serve >http://www.oracle.com Enabling The Information Age The first one works (I guess the second one also). Its nice trick. If you could just add a line or two of remarks it would be great. something like: /* saving ip header for future use because ip_output might change it */ Thanks, Ido _________________________________________ Get Your Free Virus Protection Tool at http://www.VCatch.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 16:43: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id DB40337B491; Thu, 22 Feb 2001 16:43:01 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id F09643E09; Thu, 22 Feb 2001 16:43:00 -0800 (PST) To: Robert Watson Cc: Dima Dorfman , freebsd-hackers@freebsd.org, phk@freebsd.org Subject: Re: Listing configured md(4) devices In-Reply-To: Message from Robert Watson of "Thu, 22 Feb 2001 14:31:29 EST." Date: Thu, 22 Feb 2001 16:43:00 -0800 From: Dima Dorfman Message-Id: <20010223004300.F09643E09@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 2) I'm not sure I like the strncmp(.., "md", 2) stuff, as that means that > it would also match any other device name that might begin with md, which > potentially might not be provided by the md driver. This is currently (I > suspect) hypothetical as we don't have any other drivers beginning with > md, but it would be nice not to preclude that in the future. Restricting > all possible disk device names to two letters, of which the second is > always d, is not a scalable approach. That said, writing an easy matching > function without that assumption probably isn't all that easy, either. Assuming that a device name must consist of letters (which I suspect is the case), it's fairly trivial; just check that what follows 'md' is a number. Here's a patch against what I sent in previously to do that. The original with this included can be found at http://www.unixfreak.org/~dima/home/md-list3.diff. Thanks again Dima Dorfman dima@unixfreak.org --- mdconfig.c.o2 Thu Feb 21 05:27:00 2001 +++ mdconfig.c Thu Feb 22 16:32:34 2001 @@ -195,7 +195,7 @@ int list(void) { - char *disklist, *p, *p2; + char *disklist, *p, *p2, *p3; int dll; /* disklist length */ int mds[512], *mdsp, mdsc, i; @@ -211,7 +211,9 @@ if (strncmp(p2, "md", 2) != 0) continue; p2 += 2; - *mdsp = strtoul(p2, NULL, 10); + *mdsp = strtoul(p2, &p3, 10); + if (p2 == p3) + continue; mdsc++; if (++mdsp >= &mds[sizeof(mds)]) break; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 18:44:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C2EDE37B491 for ; Thu, 22 Feb 2001 18:44:09 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id VAA07413; Thu, 22 Feb 2001 21:43:56 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.2/8.9.1) id f1N2hQp83947; Thu, 22 Feb 2001 21:43:26 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14997.52814.482681.843693@grasshopper.cs.duke.edu> Date: Thu, 22 Feb 2001 21:43:26 -0500 (EST) To: freebsd-hackers@freebsd.org Cc: perky@python.or.kr Subject: Wake on Lan X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can somebody clue me in on how Wake On Lan is supposed to work? Does it require any support at all from the OS, or is it totally a BIOS thing? I've built the wake-on-lan program submitted via http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23151 and, although it seems to work to bring W2K box out of suspend mode, what I'd really like to do is to be able to "shutdown -p now" a box and then boot it up remotely. Is this even supposed to be possible? I've tried to power on the following types of machines without success: Dell Optiplex GX110 (i810) (onboard 3c905C) Dell PowerEdge 4400 (onboard fxp) SuperMicro 370DER (oboard fxp) In all cases, I've enabled the PME or "remote wakeup" in the bios. Does FreeBSD need to do something on the way down to make this work? Thanks, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 22: 9:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 76ABF37B401 for ; Thu, 22 Feb 2001 22:09:26 -0800 (PST) (envelope-from fmela0@sm.socccd.cc.ca.us) Received: from sm.socccd.cc.ca.us (pool0482.cvx4-bradley.dialup.earthlink.net [209.178.147.227]) by scaup.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id WAA07244 for ; Thu, 22 Feb 2001 22:09:21 -0800 (PST) Message-ID: <3A95FF54.5D48E0A1@sm.socccd.cc.ca.us> Date: Thu, 22 Feb 2001 22:12:36 -0800 From: Farooq Mela Reply-To: fmela0@sm.socccd.cc.ca.us X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Setting memory allocators for library functions. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Usually when I write programs, I have functions such as the following: void * xmalloc(size_t size) { void *p; if ((p=malloc(size))==NULL) { fprintf(stderr, "out of memory\n"); exit(1); } return(p); } void * xrealloc(void *ptr, size_t size) { void *p; if ((p=realloc(ptr,size))==NULL) { fprintf(stderr, "out of memory\n"); exit(1); } return(p); } And then I use these instead of malloc and realloc throughout the program, and never have to worry about return values. Sometimes these functions also have additional cleanup they perform. Anyway, there are certain libc functions which also use malloc, such as getaddrinfo, vasprintf, etc. These may fail with errno = ENOMEM. In general, it is annoying to have to check the return values for these functions too. Would it not be convenient to set the memory allocator used by certain functions inside libc? I.E, be able to write: set_allocator(xmalloc); set_reallocator(xrealloc); From then on, one would never have to worry about the functions running out of memory. I know that wrappers for functions which allocate memory can also be written, but I feel that my proposal would is in general a more convenient solution. How do you guys feel about this? -Farooq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 22:27:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 8D88237B491 for ; Thu, 22 Feb 2001 22:27:48 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1N6Rk618467 for ; Fri, 23 Feb 2001 00:27:46 -0600 (CST) Message-Id: <200102230627.f1N6Rk618467@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Thu, 22 Feb 2001 22:12:36 PST." <3A95FF54.5D48E0A1@sm.socccd.cc.ca.us> Date: Fri, 23 Feb 2001 00:27:46 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A95FF54.5D48E0A1@sm.socccd.cc.ca.us>, Farooq Mela writes: >How do you guys feel about this? It is a mistake to believe that you "don't have to worry about running out of memory". You should always check, every time, and exit as gracefully as you can. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 22:43:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from attila.stevens-tech.edu (attila.stevens-tech.edu [155.246.14.11]) by hub.freebsd.org (Postfix) with ESMTP id 2820937B401 for ; Thu, 22 Feb 2001 22:43:53 -0800 (PST) (envelope-from jmcknigh@stevens-tech.edu) Received: from glitch2 (jmcknigh-1.u04.stevens-tech.edu [155.246.203.37]) by attila.stevens-tech.edu (SGI-8.9.3/8.9.3/7) with SMTP id BAA79798 for ; Fri, 23 Feb 2001 01:43:51 -0500 (EST) From: "Justin McKnight" To: "FreeBSD-newbies" Subject: Windows 2000 pro & FreeBSD Date: Fri, 23 Feb 2001 01:40:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG i need help dual booting win200 and freebsd4.2. Win200 is already installed casue i wanted to use its bootmanager for loading each OS. I know win2k and load openbsd so figure i wont have any trouble dual booting with freebsd. Now I cant find any documentation on dual booting win2k and freebsd. I need help! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 23:20:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id C053C37B401 for ; Thu, 22 Feb 2001 23:20:36 -0800 (PST) (envelope-from fmela0@sm.socccd.cc.ca.us) Received: from sm.socccd.cc.ca.us (pool0451.cvx15-bradley.dialup.earthlink.net [209.179.45.196]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA13406; Thu, 22 Feb 2001 23:20:32 -0800 (PST) Message-ID: <3A961004.723691C9@sm.socccd.cc.ca.us> Date: Thu, 22 Feb 2001 23:23:48 -0800 From: Farooq Mela Reply-To: fmela0@sm.socccd.cc.ca.us X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Seebach Cc: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. References: <200102230627.f1N6Rk618467@guild.plethora.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Seebach wrote: > It is a mistake to believe that you "don't have to worry about running > out of memory". You should always check, every time, and exit as gracefully > as you can. > > -s Of course I realize that allocating memory can fail. That is why I use xmalloc and friends - so that I can avoid having to check for failure each time I want to allocate memory. I don't believe you understand what I am proposing. Consider the following inside libc: void *(*libc_malloc)(size_t)=malloc; void *(*libc_calloc)(size_t, size_t)=calloc; void *(*libc_realloc)(void *, size_t)=realloc; void set_allocator(void *(*func)(size_t)) { libc_malloc=func; } /* Same type of functions for calloc and realloc.. */ Now, consider some other function that is part of libc, such as getaddrinfo. Say it does the following: /* code ... */ foo=malloc(128); if (foo==NULL) { /* do clean-up.. */ errno=ENOMEM; return(NULL); } This would be replaced by: foo=(*libc_malloc)(128); if (foo=NULL) { /* do clean-up */ errno=ENOMEM; return(NULL); } It will still have to check for the allocation failing. But if this were to be done, an application which installs its own allocators will not have to worry about anything inside libc running out of memory, and will not have to handle that error condition. Furthermore, inside the user-defined allocator (xmalloc etc), other types of cleanup can be handled if the real malloc() returns NULL. (Atexit can only do so much.) Hope this clears it up. -Farooq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 23:28:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id E8D9037B491 for ; Thu, 22 Feb 2001 23:28:34 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1N7SW619041; Fri, 23 Feb 2001 01:28:32 -0600 (CST) Message-Id: <200102230728.f1N7SW619041@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: fmela0@sm.socccd.cc.ca.us Cc: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Thu, 22 Feb 2001 23:23:48 PST." <3A961004.723691C9@sm.socccd.cc.ca.us> Date: Fri, 23 Feb 2001 01:28:32 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A961004.723691C9@sm.socccd.cc.ca.us>, Farooq Mela writes: >Of course I realize that allocating memory can fail. That is why I use >xmalloc and friends - so that I can avoid having to check for failure >each time I want to allocate memory. That's the problem. You still *NEED* to check. You can't just exit; you have to figure out what you have open, and close it. You have to figure out what files you may have been halfway through writing, and make sure that you aren't about to leave a critical file half-written, with the only copy of the rest of the data somewhere in memory. It is very, very, rarely correct to say "oops, no memory, I will quit immediately without saving any work". Imagine a word processor with this behavior. No attempt to save your file, no nothing, it just suddenly closes all windows and dies. There are very few programs where it is acceptable to abort just because you ran out of memory. >I don't believe you understand what >I am proposing. I do, lots of programs do it. It's a bad idea. You really still do have to check, because in almost all cases, there will be stuff you should do on your way down, beyond just "exit". >It will still have to check for the allocation failing. But if this were >to be done, an application which installs its own allocators will not >have to worry about anything inside libc running out of memory, and will >not have to handle that error condition. Of course it will! It can't guarantee that the memory is available, and it can't guarantee that it cleans up properly, because "proper cleanup" may vary from one place to another. >Furthermore, inside the >user-defined allocator (xmalloc etc), other types of cleanup can be >handled if the real malloc() returns NULL. (Atexit can only do so much.) Exactly. Atexit *can't do enough*. Each individual place where you do something that *could* fail must be checked, and the failure handled correctly *for that place*. You can't short-cut this; if you do, your code will inevitably fail in the most inconvenient possible way, because computers are ornery. Yes, it's a lot of work checking for every single error that could occur, and handling it in a graceful fashion. However, it is *MUCH* better for, say, gethostbyname to set errno to ENOMEM and return a null pointer, than for gethostbyname to ritually suicide the entire program. The allocator which spews an error and dies is almost always an incorrect allocator. There may be counterexamples, but they're rare, and since all of the relevant library functions can probably fail *FOR OTHER REASONS*, you still have to check all the return values and handle them yourself. Even if you can prove that getaddrinfo can never fail because malloc failed, it can still fail for other reasons. You still have to check for it failing. "Fixing" the allocator doesn't remove the need to check the return of every function that can fail. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 23:41:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 209FE37B503 for ; Thu, 22 Feb 2001 23:41:40 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 2786 invoked by uid 1000); 23 Feb 2001 07:39:43 -0000 Date: Fri, 23 Feb 2001 09:39:43 +0200 From: Peter Pentchev To: Torbjorn Kristoffersen Cc: "Michael C . Wu" , FreeBSD-Hackers Subject: Re: IOmega ZIP problem Message-ID: <20010223093943.A1899@ringworld.oblivion.bg> Mail-Followup-To: Torbjorn Kristoffersen , "Michael C . Wu" , FreeBSD-Hackers References: <20010222131933.C20955@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010222131933.C20955@peorth.iteration.net>; from keichii@iteration.net on Thu, Feb 22, 2001 at 01:19:33PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > | the "cp" process eats 98% of the system resources. What's behind all this? > | Is there a way to fix it? > | > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > | > | A 'renice' won't help. > > > That's natural with "parallel". No way around it. To clarify a bit, parallel port hardware depends on the system processor doing all the data transfers, every single byte, and spending even more time checking if it's time for the next byte to go. There's no DMA, there's not even a controller you can tell 'here's a 512-byte block, let it fly'. There's no way around it indeed. G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 22 23:52:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 838B637B401 for ; Thu, 22 Feb 2001 23:52:09 -0800 (PST) (envelope-from fmela0@sm.socccd.cc.ca.us) Received: from sm.socccd.cc.ca.us (pool0451.cvx15-bradley.dialup.earthlink.net [209.179.45.196]) by gull.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA28552 for ; Thu, 22 Feb 2001 23:52:07 -0800 (PST) Message-ID: <3A96176A.CFE695F@sm.socccd.cc.ca.us> Date: Thu, 22 Feb 2001 23:55:22 -0800 From: Farooq Mela Reply-To: fmela0@sm.socccd.cc.ca.us X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102230728.f1N7SW619041@guild.plethora.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Seebach wrote: > > In message <3A961004.723691C9@sm.socccd.cc.ca.us>, Farooq Mela writes: > >Of course I realize that allocating memory can fail. That is why I use > >xmalloc and friends - so that I can avoid having to check for failure > >each time I want to allocate memory. > > That's the problem. You still *NEED* to check. You can't just exit; you > have to figure out what you have open, and close it. You have to figure > out what files you may have been halfway through writing, and make sure that > you aren't about to leave a critical file half-written, with the only copy > of the rest of the data somewhere in memory. > > It is very, very, rarely correct to say "oops, no memory, I will quit > immediately without saving any work". > This is not what I am arguing. I gave a simple example of an xmalloc function which does just print an error and exit. However, I've written many large applications using this sort of scheme where when allocation fails, all sorts of cleanup is performed before the process exits (cleaning up & restoring terminal mode, gracefully closing files / sockets / etc, syslogging the event, etc). It is hardly ever a simple exit as soon as allocation fails. [snip] > There are very few programs where it is acceptable to abort just because > you ran out of memory. > > >I don't believe you understand what > >I am proposing. > > I do, lots of programs do it. It's a bad idea. You really still do have > to check, because in almost all cases, there will be stuff you should do > on your way down, beyond just "exit". > > >It will still have to check for the allocation failing. But if this were > >to be done, an application which installs its own allocators will not > >have to worry about anything inside libc running out of memory, and will > >not have to handle that error condition. > > Of course it will! It can't guarantee that the memory is available, and > it can't guarantee that it cleans up properly, because "proper cleanup" may > vary from one place to another. What I mean here is that the *application* will not have to handle that error condition. It will be handled by the the malloc wrapper(s). > > >Furthermore, inside the > >user-defined allocator (xmalloc etc), other types of cleanup can be > >handled if the real malloc() returns NULL. (Atexit can only do so much.) > > Exactly. Atexit *can't do enough*. > > Each individual place where you do something that *could* fail must be > checked, and the failure handled correctly *for that place*. > > You can't short-cut this; if you do, your code will inevitably fail in > the most inconvenient possible way, because computers are ornery. > > Yes, it's a lot of work checking for every single error that could occur, > and handling it in a graceful fashion. However, it is *MUCH* better > for, say, gethostbyname to set errno to ENOMEM and return a null pointer, > than for gethostbyname to ritually suicide the entire program. > > The allocator which spews an error and dies is almost always an incorrect > allocator. There may be counterexamples, but they're rare, and since all > of the relevant library functions can probably fail *FOR OTHER REASONS*, > you still have to check all the return values and handle them yourself. Yes, but you would not have to write code which checks for ENOMEM. I will bet that the error handling code you write for getcwd giving ENOENT is very different from the code which handles ENOMEM from getcwd. I never write programs in which I must check the return value of each and every call to malloc/realloc/etc. It would be a lot of repetitive code. That is exactly why I use malloc wrappers, which then do all the required cleanup if allocation fails. It is actually a very effective system if done correctly, and makes life easier for me at least ;-). I would rather not have to check the return value from something like memory allocation, which is done very often in programs, and in todays VM systems, doesnt fail until all swap space is consumed. > > Even if you can prove that getaddrinfo can never fail because malloc failed, > it can still fail for other reasons. You still have to check for it failing. > "Fixing" the allocator doesn't remove the need to check the return of every > function that can fail. Indeed. Getaddrinfo is an example of a function that can fail for other reasons. But something such as asprintf or getcwd, etc, it is annoying to have to write code which will perform the cleanup that a malloc wrapper would otherwise execute. I just believe it would be a convenience to programmers if this system could be implemented. If someone prefers not to use it, and check each return value, that is fine; they are not required to use it. -Farooq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 0:14:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3]) by hub.freebsd.org (Postfix) with ESMTP id 0A2B037B4EC for ; Fri, 23 Feb 2001 00:14:40 -0800 (PST) (envelope-from janb@cs.utep.edu) Received: from gecko (gecko [129.108.5.51]) by cs.utep.edu (8.11.2/8.11.2) with ESMTP id f1N8ETr03065; Fri, 23 Feb 2001 01:14:29 -0700 (MST) Date: Fri, 23 Feb 2001 01:14:31 -0700 (MST) From: X-Sender: To: Justin McKnight Cc: FreeBSD-newbies Subject: Re: Windows 2000 pro & FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The trick is to get the windows 2000 bootloader load the boot0 program like it would DOS. Pretend you have Dos on your hard disk and instead of linking the boot option to command.com, link it to the boot0. This means, of course, that you have to copy the boot0 file to your Windows partition. Works like a charm on my machine. Jan On Fri, 23 Feb 2001, Justin McKnight wrote: > i need help dual booting win200 and freebsd4.2. Win200 is already installed > casue i wanted to use its bootmanager for loading each OS. I know win2k and > load openbsd so figure i wont have any trouble dual booting with freebsd. > Now I cant find any documentation on dual booting win2k and freebsd. I need > help! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 0:16: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1CC9337B4EC for ; Fri, 23 Feb 2001 00:16:03 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1N8G2R12947; Fri, 23 Feb 2001 00:16:02 -0800 (PST) Date: Fri, 23 Feb 2001 00:16:02 -0800 From: Alfred Perlstein To: Farooq Mela Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <20010223001602.E8663@fw.wintelcom.net> References: <200102230728.f1N7SW619041@guild.plethora.net> <3A96176A.CFE695F@sm.socccd.cc.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A96176A.CFE695F@sm.socccd.cc.ca.us>; from fmela0@sm.socccd.cc.ca.us on Thu, Feb 22, 2001 at 11:55:22PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Farooq Mela [010222 23:52] wrote: > > This is not what I am arguing. I gave a simple example of an xmalloc > function which does just print an error and exit. However, I've written > many large applications using this sort of scheme where when allocation > fails, all sorts of cleanup is performed before the process exits > (cleaning up & restoring terminal mode, gracefully closing files / > sockets / etc, syslogging the event, etc). It is hardly ever a simple > exit as soon as allocation fails. Here's exactly what's wrong with your idea: Some internal libc function that _can_ gracefully handle an out of memory return will not be able to do so if your malloc wrappers wrest control out from under them. Honestly, any code is somewhat flawed if it doesn't take extra care not to have sections where an abrupt shutdown can cause a lot of damage or inability to recover on restart. However... Some internal libc functions may attempt an allocation while in the midst of doing something evil to your program such as fiddling with signal masks or timers, if you get your "out of memory" callback and the libc function hasn't had time to restore your normal program context, you're going to have a world of pain to deal with. I can't provide any specific examples of this potentially happening, but I can imagine it being a problem, especially deep within something like the userland thread library or other complex library. If you need to deal with asprintf problems, then make an xasprinf that does the callback in your context, not from deep within libc. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 0:17:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8D44E37B65D for ; Fri, 23 Feb 2001 00:17:39 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1N8HHW79205; Fri, 23 Feb 2001 01:17:18 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102230817.f1N8HHW79205@harmony.village.org> To: simond@irrelevant.org Subject: Re: Compaq e500, 3com cardbus card help Cc: Justin McKnight , FreeBSD-newbies In-reply-to: Your message of "Thu, 22 Feb 2001 15:37:43 GMT." <20010222153743.C87266@irrelevant.org> References: <20010222153743.C87266@irrelevant.org> Date: Fri, 23 Feb 2001 01:17:17 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010222153743.C87266@irrelevant.org> simond@irrelevant.org writes: : On Thu, Feb 22, 2001 at 10:32:13AM -0500, Justin McKnight wrote: : > I cant figure out to get freebsd 4.2 to recognize : > and enable my 3com cardbus card? : : FreeBSD currently doesn't support cardbus cards. FreeBSD -stable doesn't support cardbus cards. -current should recognize the 3com cards with the NEWCARD kernels. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 0:23: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 64E8E37B491 for ; Fri, 23 Feb 2001 00:22:59 -0800 (PST) (envelope-from fmela0@sm.socccd.cc.ca.us) Received: from sm.socccd.cc.ca.us (pool0451.cvx15-bradley.dialup.earthlink.net [209.179.45.196]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA11167; Fri, 23 Feb 2001 00:22:56 -0800 (PST) Message-ID: <3A961EA4.D8EA89B5@sm.socccd.cc.ca.us> Date: Fri, 23 Feb 2001 00:26:12 -0800 From: Farooq Mela Reply-To: fmela0@sm.socccd.cc.ca.us X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102230728.f1N7SW619041@guild.plethora.net> <3A96176A.CFE695F@sm.socccd.cc.ca.us> <20010223001602.E8663@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > * Farooq Mela [010222 23:52] wrote: > > > > This is not what I am arguing. I gave a simple example of an xmalloc > > function which does just print an error and exit. However, I've written > > many large applications using this sort of scheme where when allocation > > fails, all sorts of cleanup is performed before the process exits > > (cleaning up & restoring terminal mode, gracefully closing files / > > sockets / etc, syslogging the event, etc). It is hardly ever a simple > > exit as soon as allocation fails. > > Here's exactly what's wrong with your idea: > > Some internal libc function that _can_ gracefully handle an out > of memory return will not be able to do so if your malloc wrappers > wrest control out from under them. > > Honestly, any code is somewhat flawed if it doesn't take extra care > not to have sections where an abrupt shutdown can cause a lot of > damage or inability to recover on restart. However... > > Some internal libc functions may attempt an allocation while in the > midst of doing something evil to your program such as fiddling with > signal masks or timers, if you get your "out of memory" callback > and the libc function hasn't had time to restore your normal program > context, you're going to have a world of pain to deal with. > > I can't provide any specific examples of this potentially happening, > but I can imagine it being a problem, especially deep within something > like the userland thread library or other complex library. > > If you need to deal with asprintf problems, then make an xasprinf > that does the callback in your context, not from deep within libc. I agree. Some instances of malloc failure can be / must be dealt with gracefully in libc. I am not saying that ALL usages of malloc would be replaced with calling the user-settable allocator. Only those that are not modifying, as you mentioned, the process' signal disposition and other such attributes, and *certainly* not from within the thread library. Anyway, doesnt seem like this idea is about to fly. I guess I'll shut up now. :-) -Farooq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 0:33:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E14CB37B491; Fri, 23 Feb 2001 00:33:15 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1N8XFB13423; Fri, 23 Feb 2001 00:33:15 -0800 (PST) Date: Fri, 23 Feb 2001 00:33:15 -0800 From: Alfred Perlstein To: Farooq Mela Cc: freebsd-hackers@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <20010223003315.G8663@fw.wintelcom.net> References: <200102230728.f1N7SW619041@guild.plethora.net> <3A96176A.CFE695F@sm.socccd.cc.ca.us> <20010223001602.E8663@fw.wintelcom.net> <3A961EA4.D8EA89B5@sm.socccd.cc.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A961EA4.D8EA89B5@sm.socccd.cc.ca.us>; from fmela0@sm.socccd.cc.ca.us on Fri, Feb 23, 2001 at 12:26:12AM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Farooq Mela [010223 00:22] wrote: > Alfred Perlstein wrote: > > > > * Farooq Mela [010222 23:52] wrote: > > > > > > This is not what I am arguing. I gave a simple example of an xmalloc > > > function which does just print an error and exit. However, I've written > > > many large applications using this sort of scheme where when allocation > > > fails, all sorts of cleanup is performed before the process exits > > > (cleaning up & restoring terminal mode, gracefully closing files / > > > sockets / etc, syslogging the event, etc). It is hardly ever a simple > > > exit as soon as allocation fails. > > > > Here's exactly what's wrong with your idea: > > > > Some internal libc function that _can_ gracefully handle an out > > of memory return will not be able to do so if your malloc wrappers > > wrest control out from under them. > > > > Honestly, any code is somewhat flawed if it doesn't take extra care > > not to have sections where an abrupt shutdown can cause a lot of > > damage or inability to recover on restart. However... > > > > Some internal libc functions may attempt an allocation while in the > > midst of doing something evil to your program such as fiddling with > > signal masks or timers, if you get your "out of memory" callback > > and the libc function hasn't had time to restore your normal program > > context, you're going to have a world of pain to deal with. > > > > I can't provide any specific examples of this potentially happening, > > but I can imagine it being a problem, especially deep within something > > like the userland thread library or other complex library. > > > > If you need to deal with asprintf problems, then make an xasprinf > > that does the callback in your context, not from deep within libc. > > I agree. Some instances of malloc failure can be / must be dealt with > gracefully in libc. I am not saying that ALL usages of malloc would be > replaced with calling the user-settable allocator. Only those that are > not modifying, as you mentioned, the process' signal disposition and > other such attributes, and *certainly* not from within the thread > library. > > Anyway, doesnt seem like this idea is about to fly. I guess I'll shut up > now. :-) Well, while looking at actually doing what you're saying, phk malloc will call a function (from the manpage): void (*_malloc_message)(char *p1, char *p2, char *p3, char *p4) you can set _malloc_message = your callback. the only problem is that the failure codes don't seem to be enumerated, they seem to be strings, if there was a way to test: /* * this is untested */ void (*saved_malloc_callback)(char *p1, char *p2, char *p3, char *p4); void my_malloc_callback(char *p1, char *p2, char *p3, char *p4) { if (p1 == malloc_out_of_memory_str) { /* do out of memory handling */ } else { saved_malloc_callback(p1, p2, p3, p4); } } int main (void) { saved_malloc_callback = _malloc_message; _malloc_message = my_malloc_callback; more_main(); } or something, you could then hijack _malloc_message for your callback. Of course this would be highly FreeBSD specific, but so would the modification you wanted in the first place. Poul-Henning, is there any way to do a valid test to determine that the '_malloc_message' callback parameter means "out of memory"? I'm pretty sure that we should discourage anyone wanting to abuse the interface by doing this, but it does seem sort of interesting. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 2:38: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-57.dsl.lsan03.pacbell.net [63.207.60.57]) by hub.freebsd.org (Postfix) with ESMTP id 8B9A037B401 for ; Fri, 23 Feb 2001 02:38:06 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 271EC66F83; Fri, 23 Feb 2001 02:38:06 -0800 (PST) Date: Fri, 23 Feb 2001 02:38:06 -0800 From: Kris Kennaway To: Justin McKnight Cc: FreeBSD-newbies Subject: Re: Windows 2000 pro & FreeBSD Message-ID: <20010223023805.A26743@mollari.cthul.hu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jmcknigh@stevens-tech.edu on Fri, Feb 23, 2001 at 01:40:47AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 23, 2001 at 01:40:47AM -0500, Justin McKnight wrote: > To: FreeBSD-newbies ^^^^^^^^^^^^^^^ ^^^^^^^ Something is wrong with this picture. Kris --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lj2NWry0BWjoQKURAtPSAKDFr9SPSfAdk9SkHvIHQ+38kEVuiACg2M5B BDKfXRsh2sfOXcMfLrE6eV8= =e4nF -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 3:13:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fjord.dignus.com (sdsl-64-244-29-38.dsl.rdu.megapath.net [64.244.29.38]) by hub.freebsd.org (Postfix) with ESMTP id 46CA437B491 for ; Fri, 23 Feb 2001 03:13:11 -0800 (PST) (envelope-from rivers@dignus.com) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by fjord.dignus.com (8.11.1/8.11.1) with ESMTP id f1NBEZn41491; Fri, 23 Feb 2001 06:14:35 -0500 (EST) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.9.3/8.6.9) id GAA03225; Fri, 23 Feb 2001 06:14:42 -0500 (EST) Date: Fri, 23 Feb 2001 06:14:42 -0500 (EST) From: Thomas David Rivers Message-Id: <200102231114.GAA03225@lakes.dignus.com> To: fmela0@sm.socccd.cc.ca.us, freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-Reply-To: <3A95FF54.5D48E0A1@sm.socccd.cc.ca.us> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Farooq Mela wrote: > > Hi, > > Usually when I write programs, I have functions such as the following: > > void * > xmalloc(size_t size) > { > > } > > void * > xrealloc(void *ptr, size_t size) > { > > } > > And then I use these instead of malloc and realloc throughout the > program, and never have to worry about return values. Sometimes these > functions also have additional cleanup they perform. Anyway, there are > certain libc functions which also use malloc, such as getaddrinfo, > vasprintf, etc. These may fail with errno = ENOMEM. In general, it is > annoying to have to check the return values for these functions too. > Would it not be convenient to set the memory allocator used by certain > functions inside libc? I.E, be able to write: > > set_allocator(xmalloc); > set_reallocator(xrealloc); > > >From then on, one would never have to worry about the functions running > out of memory. I know that wrappers for functions which allocate memory > can also be written, but I feel that my proposal would is in general a > more convenient solution. > > How do you guys feel about this? > > -Farooq This would have probably been an outstanding idea when the C standard was being put together... (and, who knows, somethine similar may very well have been proposed.) But, let me point out that adding such a feature to the FreeBSD library doesn't mean you can dispense with your checks and/or wrapping functions. As soon as your code needs to run on another platform, you'll need those checks... Such is the way of the world - when you have a standard, that's all you can expect from other systems... - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 4:40:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id E6D2937B401 for ; Fri, 23 Feb 2001 04:40:18 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1NCbjK03604; Fri, 23 Feb 2001 07:37:45 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102231237.f1NCbjK03604@hda.hda.com> Subject: Re: Wake on Lan In-Reply-To: <14997.52814.482681.843693@grasshopper.cs.duke.edu> from Andrew Gallatin at "Feb 22, 2001 09:43:26 pm" To: Andrew Gallatin Date: Fri, 23 Feb 2001 07:37:44 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG, perky@python.or.kr X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Can somebody clue me in on how Wake On Lan is supposed to work? > Does it require any support at all from the OS, or is it totally a > BIOS thing? I don't know how "Wake On Lan" is supposed to work, but the "Sony Vaio Slimtop" I have comes out of suspend mode when I ping it. I've had it idle for half an hour so I don't know of any other events that wake it up. You'd have to be sure nothing was going to talk to it and you'd need an ARP entry for once the arp cache timed out to use this in any way. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 5:30:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by hub.freebsd.org (Postfix) with ESMTP id 186D137B67D for ; Fri, 23 Feb 2001 05:30:45 -0800 (PST) (envelope-from pmarquis@pobox.com) Received: from 146-115-120-232.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([146.115.120.232] helo=pobox.com) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14WIJ1-00068d-00 ; Fri, 23 Feb 2001 08:30:43 -0500 Message-ID: <3A966636.A9B5E860@pobox.com> Date: Fri, 23 Feb 2001 08:31:34 -0500 From: Paul Marquis X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Justin McKnight Cc: FreeBSD-hackers Subject: Re: Windows 2000 pro & FreeBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Check out BootPart: http://www.winimage.com/bootpart.htm I used it to copy the boot sector of my FreeBSD partition and add it to the NT boot manager menu. It does all the work for you. Justin McKnight wrote: > i need help dual booting win200 and freebsd4.2. Win200 is > already installed casue i wanted to use its bootmanager for > loading each OS. I know win2k and load openbsd so figure > i wont have any trouble dual booting with freebsd. > Now I cant find any documentation on dual booting win2k > and freebsd. I need help! -- Paul Marquis pmarquis@pobox.com I believe five out of four people have trouble with fractions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 6:29:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 81B7A37B4EC for ; Fri, 23 Feb 2001 06:29:34 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA15139; Fri, 23 Feb 2001 09:29:33 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.2/8.9.1) id f1NET3e85189; Fri, 23 Feb 2001 09:29:03 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14998.29615.599981.926187@grasshopper.cs.duke.edu> Date: Fri, 23 Feb 2001 09:29:03 -0500 (EST) To: Peter Dufault Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Wake on Lan In-Reply-To: <200102231237.f1NCbjK03604@hda.hda.com> References: <14997.52814.482681.843693@grasshopper.cs.duke.edu> <200102231237.f1NCbjK03604@hda.hda.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Dufault writes: > > > > Can somebody clue me in on how Wake On Lan is supposed to work? > > Does it require any support at all from the OS, or is it totally a > > BIOS thing? > > I don't know how "Wake On Lan" is supposed to work, but the "Sony Vaio > Slimtop" I have comes out of suspend mode when I ping it. I've had > it idle for half an hour so I don't know of any other events that > wake it up. > > You'd have to be sure nothing was going to talk to it and you'd need > an ARP entry for once the arp cache timed out to use this in any way. It sounds like your Sony is doing something rather non-standard, and which is not what I'm talking about. I'm talking about the AMD "magic packet" protocol which sends a packet that looks like this (to wake up a machine with MAC 01:23:45:67:89:ab): 09:25:36.230235 1234567.89:ab:01:23:45:67.89ab > ffffffff.ff:ff:01:23:45:67.89ab: ipx-#89ab 65505 ffff ffff ffff ffff ffff ffff 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 89ab 0123 4567 Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 6:49:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sydney.worldwide.lemis.com (bos-30-c-178.bos.dsl.cerfnet.com [209.187.126.178]) by hub.freebsd.org (Postfix) with ESMTP id D4F0337B4EC for ; Fri, 23 Feb 2001 06:49:24 -0800 (PST) (envelope-from grog@sydney.worldwide.lemis.com) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.11.1/8.9.3) id f1M84v002657; Thu, 22 Feb 2001 03:04:57 -0500 (EST) (envelope-from grog) Date: Thu, 22 Feb 2001 03:04:57 -0500 From: Greg Lehey To: Jim Pirzyk Cc: freebsd-hackers@FreeBSD.org Subject: Re: gdb and debugging Linux binaries Message-ID: <20010222030457.A2624@sydney.worldwide.lemis.com> References: <01022213560407.44596@snoopy.fan.fa.disney.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <01022213560407.44596@snoopy.fan.fa.disney.com>; from Jim.Pirzyk@disney.com on Thu, Feb 22, 2001 at 01:55:07PM -0800 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 22 February 2001 at 13:55:07 -0800, Jim Pirzyk wrote: > > I have a question on how to debug Linux binaries. I have a core > file from the linux binary, but if I use the FreeBSD gdb, it cannot > find the shared libraries in /compat/linux/.... If I use the /compat/linux/ > /usr/bin/gdb, it says the core file is in the wrong format: > > Couldn't fetch registers from core file: File in wrong format > Couldn't fetch register set 2 from core file: File in wrong format > > So what is the correct procedure for debugging Linux binaries? Have you tried the Linux gdb? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 7:27:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.193.193.101]) by hub.freebsd.org (Postfix) with ESMTP id E5A9237B4EC for ; Fri, 23 Feb 2001 07:27:41 -0800 (PST) (envelope-from diman@asd-g.com) Received: from core.is.kiev.ua (p187.is.kiev.ua [62.244.5.187] (may be forged)) by sivka.carrier.kiev.ua (8/Kilkenny_is_better) with ESMTP id RHY33327; Fri, 23 Feb 2001 17:20:40 +0200 (EET) (envelope-from diman@asd-g.com) Received: from ergo.local ([10.203.1.10]) by core.is.kiev.ua (8.11.1/ASDG-2.3-NR) with ESMTP id f1NFKYd87447; Fri, 23 Feb 2001 17:20:36 +0200 (EET) (envelope-from diman@asd-g.com) Date: Fri, 23 Feb 2001 17:19:27 +0200 (EET) From: diman X-Sender: diman@portal.none.ua To: mouss Cc: diwil@eis.ru, freebsd-hackers@FreeBSD.ORG Subject: Re: warning in free(): In-Reply-To: <4.3.0.20010222194459.0242d850@pop.free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Feb 2001, mouss wrote: > At 18:37 22/02/01 +0200, diman wrote: > > >Open AF_UNIX socket to syslogd and then use err_set_file() > >to redirect all err/warn messages to syslogd instead of > >stdin/stdout. That should help you debug daemons. > > I agree, but one of the nice things about syslog interface is that it hides > all the socket/device stuff. so getting back to the socket api is > somewhat unsatisfactory. Yes, it's a bit dirty workaround. But openlog() returns void. Returning pointer to a structure from wich I can obtain file descriptor has more sense for several reasons. It would be nice to be able get current LogFile, LogTag, LogStat and LogFacility from openlog(). > > Also, I think having this directly in err() and warn() and friends would be > more elegant. and this doesn't seem hard to do. something like using > a function pointer to use fprintf or syslog, and an additionnal void* to use > either err_file or syslog priority. > > Does this sound ok or is it an unuseful complication of code? I see a sense in your words. Linking a daemon with a libs wich will break control connection by diagnostic messages is not a dream. Having that messages on the console and in the log file is helpful under debug time. There are some points: 1. If daemon want syslog, it should use syslog(). 2. If daemon want warn and exit, it should use warnx. 3. If it doesn't want stderr, it should use err_set_file. *4. If daemon doesn't want libc talking to remote end and breaking a control connection or daemon doesn't want remote end to know about internal fault, it should be able to redirect libc output. *5. Daemon feels good to syslog above libc messages *6. To do 5 it would be nice to have ERR_TO_SYSLOG reserved integer for the err_set_file(void* vfp). So, err_set_file ( ERR_TO_SYSLOG ) ; will say libc to use LogFile and current syslog context to write all err/warn messages instead of stderr. *7. Approach described above doesn't break any current app/daemons and nothing have to be rewritten because ERR_TO_SYSLOG is 0xfffffffa (for example). Approach is trivial to implement. 8. Not linked well to the speach but openlog() should not return void but pointer to the struct with LogFile, LogTag, LogStat and LogFacility fields. That is my view of the subject. Best Regards, diman. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 7:51:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from eth.net (mailserver2.ddsl.net [202.9.145.19]) by hub.freebsd.org (Postfix) with ESMTP id B846437B401 for ; Fri, 23 Feb 2001 07:51:23 -0800 (PST) (envelope-from lvimala@eth.net) Received: from turing ([202.9.172.215]) by eth.net with Microsoft SMTPSVC(5.5.1877.357.35); Fri, 23 Feb 2001 21:17:23 +0530 From: V.Krishna Kumar Reply-To: lvimala@eth.net Date: Sat, 24 Feb 2001 02:55:37 +0530 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Message-Id: <01022402553700.00685@turing> Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 10:33:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from link.mirror.org (link.mirror.org [216.38.7.35]) by hub.freebsd.org (Postfix) with ESMTP id BD75437B401 for ; Fri, 23 Feb 2001 10:33:37 -0800 (PST) (envelope-from sgt@netcom.no) Received: from hal (5-d09-1.svg1.netcom.no [212.45.182.134]) by link.mirror.org (8.7.5/8.7.3) with ESMTP id NAA20573 for ; Fri, 23 Feb 2001 13:32:00 -0500 Date: Fri, 23 Feb 2001 19:33:30 +0100 (CET) From: Torbjorn Kristoffersen X-Sender: To: FreeBSD-Hackers Subject: Re: IOmega ZIP problem In-Reply-To: <20010223093943.A1899@ringworld.oblivion.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 23 Feb 2001, Peter Pentchev wrote: > On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > > | the "cp" process eats 98% of the system resources. What's behind all this? > > | Is there a way to fix it? > > | > > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > > | > > | A 'renice' won't help. > > > > > > That's natural with "parallel". No way around it. > > To clarify a bit, parallel port hardware depends on the system processor > doing all the data transfers, every single byte, and spending even more > time checking if it's time for the next byte to go. There's no DMA, there's > not even a controller you can tell 'here's a 512-byte block, let it fly'. > > There's no way around it indeed. > > G'luck, > Peter So there doesn't exists any controllers (ISA/PCI) that can do the serialization of parallel data, and pass it to a serial interface (or UART), so we can use DMA and move Serial Data Units instead of single bytes? (Probably a feather-brained question..) Cheers, Torbjorn Kristoffersen sgt@netcom.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 12:17:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by hub.freebsd.org (Postfix) with ESMTP id 6365937B67D for ; Fri, 23 Feb 2001 12:17:33 -0800 (PST) (envelope-from jandrese@mitre.org) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA06048 for ; Fri, 23 Feb 2001 15:17:31 -0500 (EST) Received: from mailsrv2.mitre.org (mailsrv2.mitre.org [129.83.221.17]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA24639 for ; Fri, 23 Feb 2001 15:17:30 -0500 (EST) Received: from mitre.org ([128.29.145.140]) by mailsrv2.mitre.org (Netscape Messaging Server 4.15) with ESMTP id G988D500.T40; Fri, 23 Feb 2001 15:17:29 -0500 Message-ID: <3A96C577.C0FC12C1@mitre.org> Date: Fri, 23 Feb 2001 15:17:59 -0500 From: "Andresen,Jason R." X-Mailer: Mozilla 4.75 [en]C-20000818M (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Torbjorn Kristoffersen Cc: FreeBSD-Hackers Subject: Re: IOmega ZIP problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Torbjorn Kristoffersen wrote: > > On Fri, 23 Feb 2001, Peter Pentchev wrote: > > > On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > > > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > > > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > > > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > > > | the "cp" process eats 98% of the system resources. What's behind all this? > > > | Is there a way to fix it? > > > | > > > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > > > | > > > | A 'renice' won't help. > > > > > > > > > That's natural with "parallel". No way around it. > > > > To clarify a bit, parallel port hardware depends on the system processor > > doing all the data transfers, every single byte, and spending even more > > time checking if it's time for the next byte to go. There's no DMA, there's > > not even a controller you can tell 'here's a 512-byte block, let it fly'. > > > > There's no way around it indeed. > > > > G'luck, > > Peter > > So there doesn't exists any controllers (ISA/PCI) that can do the > serialization of parallel data, and pass it to a serial interface (or > UART), so we can use DMA and move Serial Data Units instead of > single bytes? Not that I'm aware of, although someone could build one fairly easily. Of course if you are going to go to all the trouble to build a specialty card, you might as well just go out and buy a zip drive with a interface. Granted zip drives tend to only use the most minimal subset of whatever protocol they're speaking (ATAPI-floppy device and SCSI-I), but they do work, and are reasonably fast (for zip drives). -- _ _ _ ___ ____ ___ ______________________________________ / \/ \ | ||_ _|| _ \|___| | Jason Andresen -- jandrese@mitre.org / /\/\ \ | | | | | |/ /|_|_ | Views expressed may not reflect those /_/ \_\|_| |_| |_|\_\|___| | of the Mitre Corporation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 12:23:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 5EFC537B503 for ; Fri, 23 Feb 2001 12:23:50 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA23426 for ; Fri, 23 Feb 2001 15:23:49 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.2/8.9.1) id f1NKNJX86964; Fri, 23 Feb 2001 15:23:19 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14998.50870.963179.287484@grasshopper.cs.duke.edu> Date: Fri, 23 Feb 2001 15:23:18 -0500 (EST) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Wake on Lan In-Reply-To: <200102231237.f1NCbjK03604@hda.hda.com> References: <14997.52814.482681.843693@grasshopper.cs.duke.edu> <200102231237.f1NCbjK03604@hda.hda.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To follow up on myself, it seems to work on older Asus P2B-LS motherboards (onboard fxp). But only after you shutdown FreeBSD via 'shutdown -p now'. I don't suppose anybody knows which machines support this well? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 12:32:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 3DA9237B491 for ; Fri, 23 Feb 2001 12:32:27 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 1650818C91; Fri, 23 Feb 2001 14:32:26 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1NKWQm41652; Fri, 23 Feb 2001 14:32:26 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 23 Feb 2001 14:32:26 -0600 From: "Jacques A. Vidrine" To: Poul-Henning Kamp Cc: Warner Losh , freebsd-hackers@FreeBSD.ORG Subject: Re: portability sanity check Message-ID: <20010223143225.F41493@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Poul-Henning Kamp , Warner Losh , freebsd-hackers@FreeBSD.ORG References: <20010221102200.A93525@hamlet.nectar.com> <2210.982772911@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2210.982772911@critter>; from phk@critter.freebsd.dk on Wed, Feb 21, 2001 at 05:28:31PM +0100 X-Url: http://www.nectar.com/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 21, 2001 at 05:28:31PM +0100, Poul-Henning Kamp wrote: > >Type-safety is a cruch for the weak-minded. ^^^^^ > As an old assembler programmer I couldn't agree more, but in a project > like FreeBSD we have to realize that not everybody is that. Heh, I was just cleaning out these message from my inbox, and I discovered that spell-checkers are a crutch for the weak-minded, too :-) Thanks for everyone's feedback. I decided that I'm quite happy to use type-punning for more-or-less primitive types when building comparison functions and the like. For more complex stuff, it seems simplest/clearest to use a `void *' for internal data, a la db. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 12:37:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sandman.sandgate.com (sandman.sandgate.com [38.161.139.2]) by hub.freebsd.org (Postfix) with ESMTP id E659437B65D for ; Fri, 23 Feb 2001 12:37:39 -0800 (PST) (envelope-from wainer@sandgate.com) Received: from vectra (sandman.sandgate.com [38.161.139.2]) by sandman.sandgate.com (8.11.1/8.11.1) with SMTP id f1NKbYQ14452 for ; Fri, 23 Feb 2001 15:37:35 -0500 (EST) From: "Sue Wainer" To: Subject: RE: Memory Alloation from kernel loadable driver Date: Fri, 23 Feb 2001 15:37:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C09DAE.8AE15F30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C09DAE.8AE15F30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I have a pci driver which is loaded using kldload. It is allocating a no. of pages by calling vm_page_alloc_contig. This convention is used by other pci drivers, though not necessarily loadable ones. On machines without much memory, or ones with more memory but having done compilations prior to kldloading, contigmalloc1 gets stuck in a continuous loop looping from the first "goto again1." There is a comment above configmalloc1 which might imply that this contiguous allocation does not work after initialization. For locked-down memory, what allocation routines should loadable drivers be calling? Is there any source of documentation of memory allocation which could be of value? Thanks. Sue Wainer wainer@sandgate.com ------=_NextPart_000_0007_01C09DAE.8AE15F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
I have a pci = driver which is=20 loaded using kldload. It is allocating a no. of pages by calling=20 vm_page_alloc_contig.
This convention = is used by=20 other pci drivers, though not necessarily loadable = ones.
 
On machines = without much=20 memory, or ones with more memory but having done compilations prior to = kldloading,
contigmalloc1 = gets stuck in a=20 continuous loop looping from the first "goto again1." There is a=20 comment
above = configmalloc1 which=20 might imply that this contiguous allocation does not work after=20 initialization.
 
For locked-down = memory, what=20 allocation routines should loadable drivers be calling? Is = there any=20 source of
documentation of = memory=20 allocation which could be of value?
 
Thanks.
 
Sue=20 Wainer
wainer@sandgate.com <= /FONT>
 
 
= ------=_NextPart_000_0007_01C09DAE.8AE15F30-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 12:59:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 6E2EB37B491 for ; Fri, 23 Feb 2001 12:59:25 -0800 (PST) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 07C6F14A6; Fri, 23 Feb 2001 12:59:24 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id MAA09234; Fri, 23 Feb 2001 12:59:19 -0800 (PST) Message-ID: <3A96CF27.B2B624BD@cup.hp.com> Date: Fri, 23 Feb 2001 12:59:19 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: Jim Pirzyk , freebsd-hackers@FreeBSD.ORG Subject: Re: gdb and debugging Linux binaries References: <01022213560407.44596@snoopy.fan.fa.disney.com> <20010222030457.A2624@sydney.worldwide.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > On Thursday, 22 February 2001 at 13:55:07 -0800, Jim Pirzyk wrote: > > > > I have a question on how to debug Linux binaries. I have a core > > file from the linux binary, but if I use the FreeBSD gdb, it cannot > > find the shared libraries in /compat/linux/.... If I use the /compat/linux/ > > /usr/bin/gdb, it says the core file is in the wrong format: > > > > Couldn't fetch registers from core file: File in wrong format > > Couldn't fetch register set 2 from core file: File in wrong format > > > > So what is the correct procedure for debugging Linux binaries? > > Have you tried the Linux gdb? IIRC, the Linux gdb doesn't grok our core files. I started an implementation for our Linuxulator to dump Linux compatible core files so that you could use the Linux gdb. I guess I lost what I had back then. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 13:39:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (user-uinjtfm.biz.mindspring.com [165.121.245.246]) by hub.freebsd.org (Postfix) with ESMTP id 4F3C637B65D for ; Fri, 23 Feb 2001 13:39:42 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f1NLfMK00758; Fri, 23 Feb 2001 13:41:26 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102232141.f1NLfMK00758@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Andrew Gallatin Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Wake on Lan In-reply-to: Your message of "Fri, 23 Feb 2001 15:23:18 EST." <14998.50870.963179.287484@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Feb 2001 13:41:22 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > To follow up on myself, it seems to work on older Asus P2B-LS > motherboards (onboard fxp). But only after you shutdown FreeBSD via > 'shutdown -p now'. I don't suppose anybody knows which machines > support this well? The machine *should* support WOL from a cold power-on. However, I do get the impression that some adapters require some parting initialisation as well. You might want to check that eg. you've enabled it in the BIOS and plugged the cable in the right place. Apart from that, I can't really offer any help. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 14: 3: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with ESMTP id 0906437B4EC for ; Fri, 23 Feb 2001 14:03:04 -0800 (PST) (envelope-from drew@chopper.Poohsticks.ORG) Received: from chopper.Poohsticks.ORG (drew@localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.10.1/8.10.1) with ESMTP id f1NM33n05731 for ; Fri, 23 Feb 2001 15:03:03 -0700 Message-Id: <200102232203.f1NM33n05731@chopper.Poohsticks.ORG> To: freebsd-hackers@FreeBSD.ORG Subject: Re: gdb and debugging Linux binaries In-reply-to: Your message of "Fri, 23 Feb 2001 12:59:19 PST." <3A96CF27.B2B624BD@cup.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5727.982965782.1@chopper.Poohsticks.ORG> Date: Fri, 23 Feb 2001 15:03:02 -0700 From: Drew Eckhardt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You may be able to force gdb to pick up the right files using the add-symbol-file command. Or the sharedlibrary command. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 14:30:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from perec.uol.com.br (perec.uol.com.br [200.231.206.204]) by hub.freebsd.org (Postfix) with ESMTP id C1C9A37B491 for ; Fri, 23 Feb 2001 14:30:17 -0800 (PST) (envelope-from obelix@lcmi.ufsc.br) Received: from jazz.lcmi.ufsc.br (200-191-104-159-as.acessonet.com.br [200.191.104.159]) by perec.uol.com.br (8.9.1/8.9.1) with ESMTP id TAA21711; Fri, 23 Feb 2001 19:30:49 -0300 (BRT) Received: (from obelix@localhost) by jazz.lcmi.ufsc.br (8.9.3/8.9.3) id TAA01351; Fri, 23 Feb 2001 19:25:01 -0300 Date: Fri, 23 Feb 2001 19:25:01 -0300 From: Rafael Rodrigues Obelheiro To: Peter Pentchev Cc: Torbjorn Kristoffersen , "Michael C . Wu" , FreeBSD-Hackers Subject: Re: IOmega ZIP problem Message-ID: <20010223192501.G199@lcmi.ufsc.br> References: <20010222131933.C20955@peorth.iteration.net> <20010223093943.A1899@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010223093943.A1899@ringworld.oblivion.bg>; from roam@orbitel.bg on Fri, Feb 23, 2001 at 09:39:43AM +0200 X-PGP-Key: http://www.lcmi.ufsc.br/~obelix/obelix.asc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 09:39:43AM +0200, Peter Pentchev wrote: > On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > > | the "cp" process eats 98% of the system resources. What's behind all this? > > | Is there a way to fix it? > > | > > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > > | > > | A 'renice' won't help. > > > > > > That's natural with "parallel". No way around it. > > To clarify a bit, parallel port hardware depends on the system processor > doing all the data transfers, every single byte, and spending even more > time checking if it's time for the next byte to go. There's no DMA, there's > not even a controller you can tell 'here's a 512-byte block, let it fly'. > > There's no way around it indeed. AFAIK, ZIP drives support parallel ports in EPP mode (uncertain about ECP), which is much faster than conventional (either nibble or bidirectional) modes. According to imm(4), FreeBSD supports EPP mode for ZIP drives. You might want to check if you can enable EPP in your BIOS. Regards, -- Rafael Rodrigues Obelheiro obelix@lcmi.ufsc.br Florianopolis, SC, Brasil To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 15:58:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id DF0D037B503 for ; Fri, 23 Feb 2001 15:58:19 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-117-25.nnj.dialup.bellatlantic.net [151.198.117.25]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id SAA27641; Fri, 23 Feb 2001 18:58:13 -0500 (EST) Message-ID: <3A96F914.E91EC98B@bellatlantic.net> Date: Fri, 23 Feb 2001 18:58:12 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Murray Stokely Cc: "Julian Stacey Jhs@jhs.muc.de" , freebsd-hackers@FreeBSD.ORG Subject: Re: Creating BSD bootable CD References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Murray Stokely wrote: > > On Thu, 22 Feb 2001, Julian Stacey Jhs@jhs.muc.de wrote: > % I hadn't heard of mkhybrid, so investigated: it's been merged into mkisofs: > > I still prefer old versions of mkhybrid over the new merged mkisofs > for some tricky environments. The new mkisofs will coredump with very > large hybrid discs for HFS / Joliet / RR. For making FreeBSD discs > however, mkisofs will do just fine. I think that the corruptions in the filesystems created by mkisofs were caused by the "exclude directories" option. That was the sole reason why I switched to mkhybrid. Last time I used it about a year ago. Maybe they have fixed it by now. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 18:55:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ffnet.com (w200.z208176006.sjc-ca.dsl.cnc.net [208.176.6.200]) by hub.freebsd.org (Postfix) with ESMTP id B6CE337B4EC for ; Fri, 23 Feb 2001 18:55:34 -0800 (PST) (envelope-from solan@ffnet.com) Received: from ffnet.com (noriega.ffnet.com [172.16.248.252]) by ffnet.com (8.8.8/8.8.8) with ESMTP id SAA00606 for ; Fri, 23 Feb 2001 18:55:34 -0800 (PST) (envelope-from solan@ffnet.com) Message-ID: <3A9722A5.D305A67@ffnet.com> Date: Fri, 23 Feb 2001 18:55:34 -0800 From: Michael Solan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" Subject: dummynet as modules Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi there, How do I compile a a kernel without ipfw, and a ipfw.ko module with dummynet support? I have to add some features to the dummynet code, so instead of rebooting every 5 mins I figured kldloading it would save me some time. I tried several combinations like 'options DUMMYNET' but no 'options IPFIREWALL', even defined DUMMYNET in the modules/ipfw/Makefile but it all resulted in undefined symbols when either building or kldloading... Any ideas? Michael Solan -- New to FreeBSD and less confused than a hamster on FreeBase -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 19: 0:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id DCDA137B401 for ; Fri, 23 Feb 2001 19:00:51 -0800 (PST) (envelope-from rizzo@iguana.aciri.org) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f1O30oA07888; Fri, 23 Feb 2001 19:00:50 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102240300.f1O30oA07888@iguana.aciri.org> Subject: Re: dummynet as modules In-Reply-To: <3A9722A5.D305A67@ffnet.com> from Michael Solan at "Feb 23, 2001 6:55:34 pm" To: solan@ffnet.com (Michael Solan) Date: Fri, 23 Feb 2001 19:00:50 -0800 (PST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > How do I compile a a kernel without ipfw, and a ipfw.ko module with > dummynet support? not sure how well is this supported -- i guess you should look at the makefile for the ipfw module to make sure it includes dummynet. But: > I have to add some features to the dummynet code, so instead of > rebooting every 5 mins I figured kldloading it would save me some time. yes it can be convenient, but if you are testing, chances are that you will be making mistakes which can result in crashes or leaks etc, so a separate test box (or a vmware system) will be convenient anyways... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 20: 5:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 4BD5637B401 for ; Fri, 23 Feb 2001 20:05:12 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.11.1/8.9.3) with ESMTP id f1O454G10922; Sat, 24 Feb 2001 14:35:04 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010222030457.A2624@sydney.worldwide.lemis.com> Date: Sat, 24 Feb 2001 14:35:03 +1030 (CST) From: "Daniel O'Connor" To: Greg Lehey Subject: Re: gdb and debugging Linux binaries Cc: freebsd-hackers@FreeBSD.org, Jim Pirzyk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Feb-01 Greg Lehey wrote: > > /compat/linux/ > > /usr/bin/gdb, it says the core file is in the wrong format: > > > > Couldn't fetch registers from core file: File in wrong format > > Couldn't fetch register set 2 from core file: File in wrong format > > > > So what is the correct procedure for debugging Linux binaries? > > Have you tried the Linux gdb? He said he did. The problem is the binary is in linux format but the coredump is in FreeBSD format.. You can still attach to processes etc though I think. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 23 22:23:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from herbelot.dyndns.org (s014.dhcp212-24.cybercable.fr [212.198.24.14]) by hub.freebsd.org (Postfix) with ESMTP id 1344237B401 for ; Fri, 23 Feb 2001 22:23:55 -0800 (PST) (envelope-from thierry.herbelot@free.fr) Received: from free.fr (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id HAA22278; Sat, 24 Feb 2001 07:23:28 +0100 (CET) (envelope-from thierry.herbelot@free.fr) Message-ID: <3A97535F.A9250B77@free.fr> Date: Sat, 24 Feb 2001 07:23:27 +0100 From: Thierry Herbelot X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jordan DeLong Cc: hackers@FreeBSD.ORG Subject: Re: detecting a closing socket from a Lex/Yacc interpreter ? References: <3A95776A.1E76A7B@free.fr> <20010222140911.A9405@cx420564-b.tucson1.az.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan DeLong wrote: > > I'm assuming right now you are just setting yyin to the fd for the socket. > What you're gonna want to do is define the macro YY_INPUT (see the man page for > details) so that it calls recv on your socket. and then if it errors you can > have YY_INPUT return as an EOF and your <> rule will work fine. > indeed, taking the very simple YY_INPUT code from the man page of lex did the trick (+ remembering to close the fd's associated to the socket ...) Thanks -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 7:33:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 10A5F37B401 for ; Sat, 24 Feb 2001 07:33:28 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA55953; Sat, 24 Feb 2001 16:33:24 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Kenneth Wayne Culver Cc: simond@irrelevant.org, Justin McKnight , FreeBSD-newbies Subject: Re: Compaq e500, 3com cardbus card help References: From: Dag-Erling Smorgrav Date: 24 Feb 2001 16:33:23 +0100 In-Reply-To: Kenneth Wayne Culver's message of "Thu, 22 Feb 2001 12:15:08 -0500 (EST)" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth Wayne Culver writes: > FreeBSD supports cardbus in -CURRENT, but I wouldn't expect it to ever > support cardbus in 4.x. If you are daring you can get -CURRENT, but from > what I hear right now, it's not working very well. It works just fine, thank you very much, but it takes some hand-holding. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 7:40:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4A74037B65D for ; Sat, 24 Feb 2001 07:40:43 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA55975; Sat, 24 Feb 2001 16:40:34 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102230627.f1N6Rk618467@guild.plethora.net> From: Dag-Erling Smorgrav Date: 24 Feb 2001 16:40:33 +0100 In-Reply-To: seebs@plethora.net's message of "Fri, 23 Feb 2001 00:27:46 -0600" Message-ID: Lines: 16 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG seebs@plethora.net (Peter Seebach) writes: > In message <3A95FF54.5D48E0A1@sm.socccd.cc.ca.us>, Farooq Mela writes: > > How do you guys feel about this? > It is a mistake to believe that you "don't have to worry about running > out of memory". You should always check, every time, and exit as gracefully > as you can. This is all academic since FreeBSD does memory overcommit, so unless you run out of address space for your process before you run out of actual memory and/or swap (not likely, but quite possible) malloc() will never return NULL and you won't know a thing until you dirty one page too many and segfault. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 8:22:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 05DDB37B491; Sat, 24 Feb 2001 08:22:15 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1OGMQM08077; Sat, 24 Feb 2001 17:22:26 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Dima Dorfman Cc: Robert Watson , freebsd-hackers@freebsd.org Subject: Re: Listing configured md(4) devices In-Reply-To: Your message of "Thu, 22 Feb 2001 16:43:00 PST." <20010223004300.F09643E09@bazooka.unixfreak.org> Date: Sat, 24 Feb 2001 17:22:26 +0100 Message-ID: <8075.983031746@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010223004300.F09643E09@bazooka.unixfreak.org>, Dima Dorfman write s: >> 2) I'm not sure I like the strncmp(.., "md", 2) stuff, as that means that >> it would also match any other device name that might begin with md, which >> potentially might not be provided by the md driver. This is currently (I >> suspect) hypothetical as we don't have any other drivers beginning with >> md, but it would be nice not to preclude that in the future. Restricting >> all possible disk device names to two letters, of which the second is >> always d, is not a scalable approach. That said, writing an easy matching >> function without that assumption probably isn't all that easy, either. > >Assuming that a device name must consist of letters (which I suspect >is the case), it's fairly trivial; just check that what follows 'md' >is a number. > >Here's a patch against what I sent in previously to do that. The >original with this included can be found at >http://www.unixfreak.org/~dima/home/md-list3.diff. Hi Dima, This is great work. The "md" problem should really be solved by adding #define MD_NAME "md" to and using this in both the driver and the mdconfig program. Can I get you to incorporate that in your patch ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 8:44: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 185DA37B491 for ; Sat, 24 Feb 2001 08:44:00 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1OGhw616627 for ; Sat, 24 Feb 2001 10:43:59 -0600 (CST) Message-Id: <200102241643.f1OGhw616627@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "24 Feb 2001 16:40:33 +0100." Date: Sat, 24 Feb 2001 10:43:58 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >This is all academic since FreeBSD does memory overcommit, so unless >you run out of address space for your process before you run out of >actual memory and/or swap (not likely, but quite possible) malloc() >will never return NULL and you won't know a thing until you dirty one >page too many and segfault. Is there any hope that, some day, a setting could be provided where a program could request that malloc *NOT* overcommit? There are programs which would rather know in advance, and clean up, than be killed abruptly. (To be pedantic, this is a conformance issue. If the memory isn't actually allocated, malloc shouldn't be returning a non-null pointer.) -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 11: 4:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kweetal.tue.nl (kweetal.tue.nl [131.155.2.7]) by hub.freebsd.org (Postfix) with ESMTP id A101337B401 for ; Sat, 24 Feb 2001 11:04:51 -0800 (PST) (envelope-from marcov@toad.stack.nl) Received: from hermes.tue.nl (hermes.tue.nl [131.155.2.46]) by kweetal.tue.nl (8.11.0/8.11.0) with ESMTP id f1OJ4nZ25777 for ; Sat, 24 Feb 2001 20:04:49 +0100 (MET) Received: from deathstar (t-27-68.athome.tue.nl [131.155.228.68]) by hermes.tue.nl (Postfix) with ESMTP id 123142E802 for ; Sat, 24 Feb 2001 20:04:49 +0100 (CET) From: "Marco van de Voort" To: freebsd-hackers@freebsd.org Date: Sat, 24 Feb 2001 20:04:50 +0100 Subject: good book or other source about socket programming Message-ID: <3A9813E2.1618.8F6F17@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm searching for a good book (or site/tutorial) about Unix socket programming, preferably FreeBSD specific. Any hints? Marco van de Voort (MarcoV@Stack.nl or marco@freepascal.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 11:17:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by hub.freebsd.org (Postfix) with ESMTP id 3C9B037B401 for ; Sat, 24 Feb 2001 11:17:20 -0800 (PST) (envelope-from alex@big.endian.de) Received: from fwd00.sul.t-online.com by mailout04.sul.t-online.com with smtp id 14WkBz-00018r-00; Sat, 24 Feb 2001 20:17:19 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.158.39.71]) by fmrl00.sul.t-online.com with esmtp id 14WkBk-0g7mWOC; Sat, 24 Feb 2001 20:17:04 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 7CB30AB44; Sat, 24 Feb 2001 20:18:31 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id BFACA14A3B; Sat, 24 Feb 2001 20:17:03 +0100 (CET) Date: Sat, 24 Feb 2001 20:17:03 +0100 To: Marco van de Voort Cc: freebsd-hackers@freebsd.org Subject: Re: good book or other source about socket programming Message-ID: <20010224201703.A28069@cichlids.cichlids.com> References: <3A9813E2.1618.8F6F17@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A9813E2.1618.8F6F17@localhost>; from marcov@stack.nl on Sat, Feb 24, 2001 at 08:04:50PM +0100 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Marco van de Voort (marcov@stack.nl): > I'm searching for a good book (or site/tutorial) about Unix socket > programming, preferably FreeBSD specific. Socket programming shouldn't be FreeBSD specific. Unix Network Programming Vol.1 by W. Richard Stevens is a good choice. After that you probably want to read some kqueue documents, which is FreeBSD specific, but shall be quite fast (faster than select/poll) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 11:30:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id 937AF37B65D for ; Sat, 24 Feb 2001 11:30:31 -0800 (PST) (envelope-from reichert@natto.numachi.com) Received: (qmail 20229 invoked by uid 3001); 24 Feb 2001 19:30:29 -0000 Received: from natto.numachi.com (198.175.254.216) by numachi.numachi.com with SMTP; 24 Feb 2001 19:30:29 -0000 Received: (qmail 496 invoked by uid 1001); 24 Feb 2001 19:30:29 -0000 Date: Sat, 24 Feb 2001 14:30:29 -0500 From: Brian Reichert To: Alexander Langer Cc: Marco van de Voort , freebsd-hackers@freebsd.org Subject: Re: good book or other source about socket programming Message-ID: <20010224143029.B368@numachi.com> References: <3A9813E2.1618.8F6F17@localhost> <20010224201703.A28069@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010224201703.A28069@cichlids.cichlids.com>; from alex@big.endian.de on Sat, Feb 24, 2001 at 08:17:03PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 24, 2001 at 08:17:03PM +0100, Alexander Langer wrote: > Thus spake Marco van de Voort (marcov@stack.nl): > After that you probably want to read some kqueue documents, which is > FreeBSD specific, but shall be quite fast (faster than select/poll) Other than the manpage, what documents about kqueue are there? (never even noticed this facility, until your message pointed it out...) > Alex > > -- > cat: /home/alex/.sig: No such file or directory > -- Brian 'you Bastard' Reichert 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 11:44:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by hub.freebsd.org (Postfix) with ESMTP id B833537B491 for ; Sat, 24 Feb 2001 11:44:13 -0800 (PST) (envelope-from alex@big.endian.de) Received: from fwd03.sul.t-online.com by mailout06.sul.t-online.com with smtp id 14Wkbv-0008CR-04; Sat, 24 Feb 2001 20:44:07 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.158.39.71]) by fmrl03.sul.t-online.com with esmtp id 14Wkbm-0iqLVAC; Sat, 24 Feb 2001 20:43:58 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 0C406AB44; Sat, 24 Feb 2001 20:45:25 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 0711C14A3B; Sat, 24 Feb 2001 20:43:57 +0100 (CET) Date: Sat, 24 Feb 2001 20:43:57 +0100 From: Alexander Langer To: Brian Reichert Cc: Marco van de Voort , freebsd-hackers@freebsd.org Subject: Re: good book or other source about socket programming Message-ID: <20010224204357.B28428@cichlids.cichlids.com> References: <3A9813E2.1618.8F6F17@localhost> <20010224201703.A28069@cichlids.cichlids.com> <20010224143029.B368@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010224143029.B368@numachi.com>; from reichert@numachi.com on Sat, Feb 24, 2001 at 02:30:29PM -0500 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Brian Reichert (reichert@numachi.com): > Other than the manpage, what documents about kqueue are there? I read this: http://www.flugsvamp.com/~jlemon/fbsd/internals.txt http://people.freebsd.org/~jlemon/ has a slideshow on kqueue. http://www.flugsvamp.com/~jlemon/fbsd/ has also some small examples. I also once had a simple kqueue echo server, but I deleted it :-) You can probably find its location in the mailing list archives. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 11:52:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E664B37B491 for ; Sat, 24 Feb 2001 11:52:17 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1OJqGh86168 for ; Sat, 24 Feb 2001 14:52:16 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 24 Feb 2001 14:52:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-hackers@FreeBSD.org Subject: patches to remove setgid kmem from systat (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm preparing to commit these changes in the next few days; when committing the last set of changes to top, there were some comments about sysctl namespace allocation, and so I'm looking for a bit more code review this time around since I'm not sure it got all the coverage it needed (other than security checks) on freebsd-audit. My current plan is to commit this on Wednesday. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services ---------- Forwarded message ---------- Date: Wed, 7 Feb 2001 01:25:20 +0100 From: Thomas Moestl To: freebsd-audit@freebsd.org Subject: patches to remove setgid kmem from systat Hi, here is a second set of patches (partly dependent on those previously posted for top), this time to remove setgid kmem from systat. Most data needed for systat -vmstat was already exported; I needed to add three sysctls, hw.nintr, hw.intrnames and hw.intrcnt. Those export the number of interrups, a list of zero-terminated interrupt names and a list if interrupt counters. I did not split the lists into various sysctls because I wanted to keep the old structures in the kernel (other programs might still use it), and doing it with the existing structures would be kind of a hassle. I think that is OK, though. For this, I had to add an include file for i386 and change one for alpha and ia64; I do not expect problems, but it would be good if someone could do a test-compile on one of these archs. systat -netstat uses only information that is currently exported via sysctl. For a large number of sockets, the new code might be slow, so the kvm code is still used if we have the privileges to access the relevant devices. For normal use, I think it is OK to remove setgid. The new patches are at: - for systat: http://www.tu-bs.de/~y0015675/systat.diff - for the kernel: http://www.tu-bs.de/~y0015675/sysctl2.diff The top changes are at: - for top: http://www.tu-bs.de/~y0015675/top.diff - for libkvm: http://www.tu-bs.de/~y0015675/libkvm.diff - for the kernel: http://www.tu-bs.de/~y0015675/sysctl.diff (those have been updated since my last post to remove some compile-time warnings, most of which weren't my fault ;-) Could these patches please reviewed and committed if OK? - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:29: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7C0C237B401 for ; Sat, 24 Feb 2001 12:28:59 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id VAA56875; Sat, 24 Feb 2001 21:28:50 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102241643.f1OGhw616627@guild.plethora.net> From: Dag-Erling Smorgrav Date: 24 Feb 2001 21:28:49 +0100 In-Reply-To: seebs@plethora.net's message of "Sat, 24 Feb 2001 10:43:58 -0600" Message-ID: Lines: 65 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG seebs@plethora.net (Peter Seebach) writes: > Is there any hope that, some day, a setting could be provided where a program > could request that malloc *NOT* overcommit? There are programs which would > rather know in advance, and clean up, than be killed abruptly. Malloc() does not overcommit - the kernel does. Malloc() doesn't know and doesn't care. I imagine you could add a compile-time option that forces obreak() (why do we still use brk()/sbrk()?) to prefault the newly allocated address space. Or you could write a malloc() implementation that only uses mmap(), and add a flag value that makes mmap() prefault pages, and fail if there isn't enough memory available. None of these solutions are portable, however; the portable way around memory overcommit is to write a malloc() wrapper that installs a SIGSEGV handler, then tries to dirty the newly allocated memory, and fails gracefully if this causes a segfault. Untested code: #include #include #include #include #include static sigjmp_buf sigenv; static void sigsegv(int sig) { siglongjmp(sigenv, -1); } void * mymalloc(size_t size) { sig_t saved_sig; void *p; if ((p = malloc(size)) == NULL) return NULL; if (sigsetjmp(env) == -1) { free(p); errno = ENOMEM; return NULL; } saved_sig = signal(SIGSEGV, sigsegv); bzero(p, size); signal(SIGSEGV, saved_sig); return p; } This probably won't work in threaded applications. > (To be pedantic, this is a conformance issue. If the memory isn't actually > allocated, malloc shouldn't be returning a non-null pointer.) Address space is allocated, but initially unmapped. Actual pages aren't faulted in until they're dirtied. Sometimes malloc() will give you a chunk of memory that's already mapped and you'll be fine, but sometimes (when allocating beyond what was previously used) it won't. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:31:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cdc.net (server1.cdc.net [207.244.0.12]) by hub.freebsd.org (Postfix) with SMTP id 4085937B491 for ; Sat, 24 Feb 2001 12:31:54 -0800 (PST) (envelope-from mwade@cdc.net) Received: (qmail 24747 invoked from network); 24 Feb 2001 20:30:19 -0000 Received: from unknown (HELO net-ninja.com) (207.244.6.200) by server1.cdc.net with SMTP; 24 Feb 2001 20:30:19 -0000 Received: by net-ninja.com (Postfix, from userid 1000) id C06006E8D0; Sat, 24 Feb 2001 15:30:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by net-ninja.com (Postfix) with ESMTP id A95EE176020; Sat, 24 Feb 2001 15:30:15 -0500 (EST) Date: Sat, 24 Feb 2001 15:30:15 -0500 (EST) From: Mike Wade X-Sender: mwade@net-ninja.com To: Brian Reichert Cc: freebsd-hackers@freebsd.org Subject: Re: good book or other source about socket programming In-Reply-To: <20010224143029.B368@numachi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 24 Feb 2001, Brian Reichert wrote: > On Sat, Feb 24, 2001 at 08:17:03PM +0100, Alexander Langer wrote: > > Thus spake Marco van de Voort (marcov@stack.nl): > > After that you probably want to read some kqueue documents, which is > > FreeBSD specific, but shall be quite fast (faster than select/poll) > > Other than the manpage, what documents about kqueue are there? > > (never even noticed this facility, until your message pointed it out...) This link will be of some help for kqueue (and other I/O methods): http://www.kegel.com/c10k.html Also Ronald F. Guilmette's example kqueue echo server: http://www.monkeys.com/kqueue/echo.c --- Mike Wade (mwade@cdc.net) Chief Technical Officer CDC Internet, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:36: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CB6FB37B491 for ; Sat, 24 Feb 2001 12:35:58 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id VAA56906; Sat, 24 Feb 2001 21:35:53 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102241643.f1OGhw616627@guild.plethora.net> From: Dag-Erling Smorgrav Date: 24 Feb 2001 21:35:52 +0100 In-Reply-To: Dag-Erling Smorgrav's message of "24 Feb 2001 21:28:49 +0100" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > if (sigsetjmp(env) == -1) { Blah, this should be if (sigsetjmp(env, 1) == -1) { DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:37:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id C624137B503 for ; Sat, 24 Feb 2001 12:37:52 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1OKbd618343; Sat, 24 Feb 2001 14:37:39 -0600 (CST) Message-Id: <200102242037.f1OKbd618343@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: Dag-Erling Smorgrav Cc: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "24 Feb 2001 21:28:49 +0100." Date: Sat, 24 Feb 2001 14:37:39 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >Malloc() does not overcommit - the kernel does. Malloc() doesn't know >and doesn't care. But it could still probably force the behavior. >None of these solutions are portable, however; Well, no, but the sole available definition of "portable" says that it is "portable" to assume that all the memory malloc can return is really available. >memory overcommit is to write a malloc() wrapper that installs a >SIGSEGV handler, then tries to dirty the newly allocated memory, and >fails gracefully if this causes a segfault. Ugh. Why not just have a flag for memory requests that requires the memory not to be overcommitted, and set it in "conforming mode"? The kernel *could* have memory which must not be overcommitted. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:41: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id D9BE737B401 for ; Sat, 24 Feb 2001 12:41:00 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:5a3mYTaj8+EByv49pbP7sjofnoJfd3FyZCmsKBFmMczJTZY+D/RAGW5qBeoImicL@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.2/8.11.2/peace) with ESMTP/inet6 id f1OKccO02954; Sun, 25 Feb 2001 05:38:38 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 25 Feb 2001 05:38:34 +0900 (JST) Message-Id: <20010225.053834.41684938.ume@mahoroba.org> To: marcov@stack.nl Cc: freebsd-hackers@freebsd.org Subject: Re: good book or other source about socket programming From: Hajimu UMEMOTO In-Reply-To: <3A9813E2.1618.8F6F17@localhost> References: <3A9813E2.1618.8F6F17@localhost> X-Mailer: xcite1.38> Mew version 1.95b97 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Sat, 24 Feb 2001 20:04:50 +0100 >>>>> "Marco van de Voort" said: marcov> I'm searching for a good book (or site/tutorial) about Unix socket marcov> programming, preferably FreeBSD specific. I recommend address family independent socket programming. http://playground.iijlab.net/material/itojun-afisp-presen/ -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:42:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id B6A2B37B491 for ; Sat, 24 Feb 2001 12:42:26 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1OKgSM09404; Sat, 24 Feb 2001 21:42:28 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: seebs@plethora.net (Peter Seebach) Cc: Dag-Erling Smorgrav , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. In-Reply-To: Your message of "Sat, 24 Feb 2001 14:37:39 CST." <200102242037.f1OKbd618343@guild.plethora.net> Date: Sat, 24 Feb 2001 21:42:28 +0100 Message-ID: <9402.983047348@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102242037.f1OKbd618343@guild.plethora.net>, Peter Seebach writes : >In message , Dag-Erling Smorgrav writes: >>Malloc() does not overcommit - the kernel does. Malloc() doesn't know >>and doesn't care. > >But it could still probably force the behavior. > >>None of these solutions are portable, however; > >Well, no, but the sole available definition of "portable" says that it is >"portable" to assume that all the memory malloc can return is really >available. No, this is not a guarantee. We also don't guarantee that you can read a file just because you managed to open it (disk errors, nfs servers going away, forced unmounts). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:43:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5FAC437B401 for ; Sat, 24 Feb 2001 12:43:09 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id VAA56959; Sat, 24 Feb 2001 21:43:01 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. References: <200102242037.f1OKbd618343@guild.plethora.net> From: Dag-Erling Smorgrav Date: 24 Feb 2001 21:43:01 +0100 In-Reply-To: seebs@plethora.net's message of "Sat, 24 Feb 2001 14:37:39 -0600" Message-ID: Lines: 28 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG seebs@plethora.net (Peter Seebach) writes: > In message , Dag-Erling Smorgrav writes: > >Malloc() does not overcommit - the kernel does. Malloc() doesn't know > >and doesn't care. > But it could still probably force the behavior. Barring kernel changes, not easily, and only for single-threaded programs. > > None of these solutions are portable, however; > Well, no, but the sole available definition of "portable" says that it is > "portable" to assume that all the memory malloc can return is really > available. Show me a modern OS (excluding real-time and/or embedded OSes) that makes this guarantee. > > memory overcommit is to write a malloc() wrapper that installs a > > SIGSEGV handler, then tries to dirty the newly allocated memory, and > > fails gracefully if this causes a segfault. > Ugh. Why not just have a flag for memory requests that requires the memory > not to be overcommitted, and set it in "conforming mode"? Read the paragraph that precedes the one you're quoting. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:43:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 902DA37B67D for ; Sat, 24 Feb 2001 12:43:48 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1OKhl618691 for ; Sat, 24 Feb 2001 14:43:47 -0600 (CST) Message-Id: <200102242043.f1OKhl618691@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sat, 24 Feb 2001 21:42:28 +0100." <9402.983047348@critter> Date: Sat, 24 Feb 2001 14:43:47 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <9402.983047348@critter>, Poul-Henning Kamp writes: >>Well, no, but the sole available definition of "portable" says that it is >>"portable" to assume that all the memory malloc can return is really >>available. >No, this is not a guarantee. Yes, it is. If the memory isn't available, malloc returns NULL. >We also don't guarantee that you can read a file just because you >managed to open it (disk errors, nfs servers going away, forced >unmounts). Sure. And all the IO functions have return codes. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:48:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 14B0437B401 for ; Sat, 24 Feb 2001 12:48:22 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1OKmRM09471; Sat, 24 Feb 2001 21:48:27 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. In-Reply-To: Your message of "Sat, 24 Feb 2001 14:43:47 CST." <200102242043.f1OKhl618691@guild.plethora.net> Date: Sat, 24 Feb 2001 21:48:27 +0100 Message-ID: <9469.983047707@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102242043.f1OKhl618691@guild.plethora.net>, Peter Seebach writes : >In message <9402.983047348@critter>, Poul-Henning Kamp writes: >>>Well, no, but the sole available definition of "portable" says that it is >>>"portable" to assume that all the memory malloc can return is really >>>available. > >>No, this is not a guarantee. > >Yes, it is. If the memory isn't available, malloc returns NULL. The guarantee is "If malloc returns NULL there is no memory you can use". That doesn't mean that just because != NULL is returned that memory will in fact be available. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 12:57:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 488D137B401 for ; Sat, 24 Feb 2001 12:57:05 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1OKus618979 for ; Sat, 24 Feb 2001 14:56:57 -0600 (CST) Message-Id: <200102242056.f1OKus618979@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sat, 24 Feb 2001 21:48:27 +0100." <9469.983047707@critter> Date: Sat, 24 Feb 2001 14:56:54 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <9469.983047707@critter>, Poul-Henning Kamp writes: >The guarantee is "If malloc returns NULL there is no memory you can use". No, it's "if the memory is not available, malloc returns NULL". >That doesn't mean that just because != NULL is returned that memory >will in fact be available. Sure, and access to stdin can segfault too. If we want a decent quality of implementation for C, malloc can't lie. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 13: 3: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 5383D37B491 for ; Sat, 24 Feb 2001 13:03:01 -0800 (PST) (envelope-from gjb@gbch.net) Received: (qmail 33212 invoked by uid 1001); 25 Feb 2001 07:02:58 +1000 User-Agent: GJB-Post 2.13 17-Feb-2001 X-Operating-System: FreeBSD 4.1-RELEASE i386 Message-Id: Date: Sun, 25 Feb 2001 07:02:58 +1000 From: Greg Black To: Poul-Henning Kamp Cc: seebs@plethora.net (Peter Seebach), freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <9469.983047707@critter> In-reply-to: <9469.983047707@critter> of Sat, 24 Feb 2001 21:48:27 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message <200102242043.f1OKhl618691@guild.plethora.net>, Peter Seebach writes > : > >In message <9402.983047348@critter>, Poul-Henning Kamp writes: > >>>Well, no, but the sole available definition of "portable" says that it is > >>>"portable" to assume that all the memory malloc can return is really > >>>available. > > > >>No, this is not a guarantee. > > > >Yes, it is. If the memory isn't available, malloc returns NULL. > > The guarantee is "If malloc returns NULL there is no memory you can use". > > That doesn't mean that just because != NULL is returned that memory > will in fact be available. If the intended behaviour of malloc is that it returns a pointer to memory that is allocated but which may not be available when accessed, the man page needs to be corrected to make this defect in the implementation clear. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 13: 5: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id EA52B37B503 for ; Sat, 24 Feb 2001 13:05:06 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1OL5CM09633; Sat, 24 Feb 2001 22:05:12 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. In-Reply-To: Your message of "Sat, 24 Feb 2001 14:56:54 CST." <200102242056.f1OKus618979@guild.plethora.net> Date: Sat, 24 Feb 2001 22:05:12 +0100 Message-ID: <9631.983048712@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102242056.f1OKus618979@guild.plethora.net>, Peter Seebach writes : >In message <9469.983047707@critter>, Poul-Henning Kamp writes: >>The guarantee is "If malloc returns NULL there is no memory you can use". > >No, it's "if the memory is not available, malloc returns NULL". No it is not and it never was. See RFC748 for why you cannot possibly be right. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 13: 8:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 9F12B37B401 for ; Sat, 24 Feb 2001 13:08:05 -0800 (PST) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [204.138.45.2]) by sabre.velocet.net (Postfix) with ESMTP id 86531137F19 for ; Sat, 24 Feb 2001 16:08:04 -0500 (EST) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.11.2/8.9.3) id f1OL84206066; Sat, 24 Feb 2001 16:08:04 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15000.8884.6165.759008@trooper.velocet.net> Date: Sat, 24 Feb 2001 16:08:04 -0500 (EST) To: freebsd-hackers@freebsd.org Subject: Large MFS on NFS-swap? X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We have an application which is precompiled, for linux, and stupid. It uses (at times large) scratch files. We want to run this on our diskless machines (CPU farm) to cut the per-cpu cost of the computation ($200/drive starts getting significant at a few hundred machines). Anyways, I've tried: [1:26:2025]root@spitfire:/usr/u/dgilbert> mount_mfs -T test -s 2097152 -o nosuid,nodev /dev/null /mnt [1:27:2026]root@spitfire:/usr/u/dgilbert> df -k Filesystem 1K-blocks Used Avail Capacity Mounted on 192.168.255.49:/raid/clients/4 124545452 87451588 27130228 76% / procfs 4 4 0 100% /proc mfs:57939 507755 1 467134 0% /mnt [1:28:2027]root@spitfire:/usr/u/dgilbert> tail -5 /etc/disktab test|test disk|\ :ty=removable:dt=SCSI:se#512:nt#1:ns#31:nc#18600:ts#1:rm#4800:\ :pc#20971520:oc#0:\ :pa#20971520:oa#0:ta=4.2BSD:ba#4096:fa#512: The goal is to have about 2 gig of filesystem available for these (admittedly stupid) scratch files. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 13:17:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 61CF237B491 for ; Sat, 24 Feb 2001 13:17:33 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1OLHR619234 for ; Sat, 24 Feb 2001 15:17:29 -0600 (CST) Message-Id: <200102242117.f1OLHR619234@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sat, 24 Feb 2001 22:05:12 +0100." <9631.983048712@critter> Date: Sat, 24 Feb 2001 15:17:27 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <9631.983048712@critter>, Poul-Henning Kamp writes: >No it is not and it never was. The C committee believes it is. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 13:27:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 007BE37B491 for ; Sat, 24 Feb 2001 13:27:08 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1OLR5M09822; Sat, 24 Feb 2001 22:27:05 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. In-Reply-To: Your message of "Sat, 24 Feb 2001 15:17:27 CST." <200102242117.f1OLHR619234@guild.plethora.net> Date: Sat, 24 Feb 2001 22:27:04 +0100 Message-ID: <9820.983050024@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102242117.f1OLHR619234@guild.plethora.net>, Peter Seebach writes : >In message <9631.983048712@critter>, Poul-Henning Kamp writes: >>No it is not and it never was. > >The C committee believes it is. The C committee doesn't deal with operating systems or the real world for that matter. They only interest them selves with a programming language. I think there is a language thing you don't understand here. If a car is advertised as "up to 18 km/l" that means that they will guarantee that you will never ever see it doing better. It doesn't mean that you will ever see that level of performance. Like wise malloc(3) will never return a pointer which it _knows_ you cannot use, but it may not have the information that enables it to determine that you cannot use it and thus unknowingly pass the pointer to you, even though you cannot use it. EOS from here. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 13:28:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 3337037B65D for ; Sat, 24 Feb 2001 13:28:09 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1OLS2619633 for ; Sat, 24 Feb 2001 15:28:03 -0600 (CST) Message-Id: <200102242128.f1OLS2619633@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sat, 24 Feb 2001 22:27:04 +0100." <9820.983050024@critter> Date: Sat, 24 Feb 2001 15:28:02 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <9820.983050024@critter>, Poul-Henning Kamp writes: >I think there is a language thing you don't understand here. No, I just disagree. It is useful for the OS to provide a hook for memory which is *known to work* - and that is the environment C specifies. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 13:31: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 3E92537B4EC for ; Sat, 24 Feb 2001 13:31:06 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1OLV7M09879; Sat, 24 Feb 2001 22:31:09 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. In-Reply-To: Your message of "Sat, 24 Feb 2001 15:28:02 CST." <200102242128.f1OLS2619633@guild.plethora.net> Date: Sat, 24 Feb 2001 22:31:07 +0100 Message-ID: <9877.983050267@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102242128.f1OLS2619633@guild.plethora.net>, Peter Seebach writes : >In message <9820.983050024@critter>, Poul-Henning Kamp writes: >>I think there is a language thing you don't understand here. > >No, I just disagree. It is useful for the OS to provide a hook for >memory which is *known to work* - and that is the environment C specifies. And just how will the OS know that a particular memory chip will not generate an uncorrectable ECC error ? Did you read the RFC I pointed you at ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 13:58:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 883BA37B491 for ; Sat, 24 Feb 2001 13:58:40 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1OLwd619758 for ; Sat, 24 Feb 2001 15:58:39 -0600 (CST) Message-Id: <200102242158.f1OLwd619758@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sat, 24 Feb 2001 22:31:07 +0100." <9877.983050267@critter> Date: Sat, 24 Feb 2001 15:58:39 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <9877.983050267@critter>, Poul-Henning Kamp writes: >And just how will the OS know that a particular memory chip will not >generate an uncorrectable ECC error ? It can't, but that's no reason for the OS to *add* reasons for failures. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 14:14:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DBB5D37B491 for ; Sat, 24 Feb 2001 14:14:31 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA57287; Sat, 24 Feb 2001 23:14:27 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102242158.f1OLwd619758@guild.plethora.net> From: Dag-Erling Smorgrav Date: 24 Feb 2001 23:14:27 +0100 In-Reply-To: seebs@plethora.net's message of "Sat, 24 Feb 2001 15:58:39 -0600" Message-ID: Lines: 15 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG seebs@plethora.net (Peter Seebach) writes: > In message <9877.983050267@critter>, Poul-Henning Kamp writes: > > And just how will the OS know that a particular memory chip will not > > generate an uncorrectable ECC error ? > It can't, but that's no reason for the OS to *add* reasons for failures. It doesn't (and I'm very close to using expletives here). On the contrary, it tries to always satisfy the application's requests and hopes for the best. It's quite possible that memory isn't available when you call malloc(), but becomes available before you actually get to dirty the pages that were allocated. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 14:49:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from uucp.nl.uu.net (uucp.nl.uu.net [193.79.237.146]) by hub.freebsd.org (Postfix) with ESMTP id 1EBF637B491 for ; Sat, 24 Feb 2001 14:49:28 -0800 (PST) (envelope-from arjan@jak.nl) Received: from jaknl by athos.nl.uu.net with UUCP id ; Sat, 24 Feb 2001 23:49:17 +0100 Received: from jak.nl ([192.168.0.30]) by jak.nl (8.8.8/8.8.8) with ESMTP id XAA00569; Sat, 24 Feb 2001 23:59:28 +0100 (CET) (envelope-from arjan@jak.nl) Message-ID: <3A983A49.324E2794@jak.nl> Date: Sat, 24 Feb 2001 23:48:41 +0100 From: Arjan Knepper Organization: JAK++ Software Development B.V. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Langer Cc: Marco van de Voort , freebsd-hackers@freebsd.org Subject: Re: good book or other source about socket programming References: <3A9813E2.1618.8F6F17@localhost> <20010224201703.A28069@cichlids.cichlids.com> Content-Type: multipart/mixed; boundary="------------1927BF50B507C3D90D5130E5" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------1927BF50B507C3D90D5130E5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alexander Langer wrote: > Thus spake Marco van de Voort (marcov@stack.nl): > > > I'm searching for a good book (or site/tutorial) about Unix socket > > programming, preferably FreeBSD specific. > > Socket programming shouldn't be FreeBSD specific. > Unix Network Programming Vol.1 by W. Richard Stevens is a good choice. I agree. Make sure you get the second edition. You may also want to get Volume 2 (about IPC) > After that you probably want to read some kqueue documents, which is > FreeBSD specific, but shall be quite fast (faster than select/poll) > > Alex > > -- > cat: /home/alex/.sig: No such file or directory > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message --------------1927BF50B507C3D90D5130E5 Content-Type: text/x-vcard; charset=us-ascii; name="arjan.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Arjan Knepper Content-Disposition: attachment; filename="arjan.vcf" begin:vcard n:Knepper;Arjan tel;fax:+31-(0)10-243-7314 tel;work:+31-(0)10-243-7362 x-mozilla-html:FALSE url:http://www.jak.nl org:JAK++ Software Development B.V. adr:;;Stoveer 247;Rotterdam;;3032 GB;Netherlands version:2.1 email;internet:arjan@jak.nl x-mozilla-cpt:;-7904 fn:Arjan Knepper end:vcard --------------1927BF50B507C3D90D5130E5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 15: 3:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 1792637B491 for ; Sat, 24 Feb 2001 15:03:20 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1ON3E620236 for ; Sat, 24 Feb 2001 17:03:16 -0600 (CST) Message-Id: <200102242303.f1ON3E620236@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "24 Feb 2001 23:14:27 +0100." Date: Sat, 24 Feb 2001 17:03:12 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >It doesn't (and I'm very close to using expletives here). On the >contrary, it tries to always satisfy the application's requests and >hopes for the best. Yes, but it could provide a stronger guarantee than it does. >It's quite possible that memory isn't available >when you call malloc(), but becomes available before you actually get >to dirty the pages that were allocated. Sure. And for many applications, that's a win. For some, though, the *CHANCE* of overcommitting killing the process is a serious problem, and the application would be better off if it could warn the user that insufficient memory is available, and perhaps more should be provided. It would be a useful option. I'm not saying it's the *only* useful option, or even always the best. However, it should be trivial enough to provide this option, and it *does* serve a useful purpose. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 16:43: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 54F8F37B401; Sat, 24 Feb 2001 16:42:58 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 0F01E3E09; Sat, 24 Feb 2001 16:42:58 -0800 (PST) To: Poul-Henning Kamp Cc: Dima Dorfman , Robert Watson , freebsd-hackers@freebsd.org Subject: Re: Listing configured md(4) devices In-Reply-To: Message from Poul-Henning Kamp of "Sat, 24 Feb 2001 17:22:26 +0100." <8075.983031746@critter> Date: Sat, 24 Feb 2001 16:42:58 -0800 From: Dima Dorfman Message-Id: <20010225004258.0F01E3E09@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The "md" problem should really be solved by adding > #define MD_NAME "md" > to and using this in both the driver and the mdconfig > program. > > Can I get you to incorporate that in your patch ? Certainly! The updated patch is at http://www.unixfreak.org/~dima/home/md-list4.diff (it's getting a little big, so I thought I'd not attach it here). The changes include, - "md" (and variants thereof) -> MD_NAME, - "mdctl" (and variants thereof) -> MDCTL_NAME (for consistency), and - update the mdconfig(8) manual page to mention the -l option. Thanks Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 18:19:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id 8404237B503 for ; Sat, 24 Feb 2001 18:19:11 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f1P2Ifc03494 for ; Sat, 24 Feb 2001 18:18:41 -0800 (PST) Received: from louie.fa.disney.com by pain.corp.disney.com with ESMTP for freebsd-hackers@FreeBSD.org; Sat, 24 Feb 2001 18:19:47 -0800 Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by louie.fa.disney.com (8.9.2/8.9.2) with ESMTP id SAA07818 for ; Sat, 24 Feb 2001 18:19:09 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) From: Jim.Pirzyk@disney.com Received: by fanimap.fan.fa.disney.com; Sat, 24 Feb 2001 18:19:08 -0800 Message-Id: Date: Sat, 24 Feb 2001 18:19:08 -0800 Subject: Re: gdb and debugging Linux binaries To: "Daniel O'Connor" Cc: freebsd-hackers@FreeBSD.org, Jim Pirzyk MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 22-Feb-01 Greg Lehey wrote: > > > /compat/linux/ > > > /usr/bin/gdb, it says the core file is in the wrong format: > > > > > > Couldn't fetch registers from core file: File in wrong format > > > Couldn't fetch register set 2 from core file: File in wrong format > > > > > > So what is the correct procedure for debugging Linux binaries? > > > > Have you tried the Linux gdb? > > He said he did. > The problem is the binary is in linux format but the coredump is in FreeBSD > format.. yes the crux of the problem, so does anyone have patches to the kernel so that linux binaries dump in linux core file format? > > You can still attach to processes etc though I think. If I can keep the program running. The program has its own signal handlers and I cannot stop it before it crashes - JimP To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 18:28:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 580FE37B401 for ; Sat, 24 Feb 2001 18:28:06 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.11.1/8.9.3) with ESMTP id f1P2RxG24415; Sun, 25 Feb 2001 12:57:59 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 25 Feb 2001 12:57:58 +1030 (CST) From: "Daniel O'Connor" To: Jim.Pirzyk@disney.com Subject: Re: gdb and debugging Linux binaries Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 25-Feb-01 Jim.Pirzyk@disney.com wrote: > yes the crux of the problem, so does anyone have patches > to the kernel so that linux binaries dump in linux core > file format? Not that I know of :( > > You can still attach to processes etc though I think. > If I can keep the program running. The program has its > own signal handlers and I cannot stop it before it crashes Ahh.. Recompile it? Or is it binary only? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 18:48:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id 7B63C37B491 for ; Sat, 24 Feb 2001 18:48:09 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f1P2ldc07802 for ; Sat, 24 Feb 2001 18:47:39 -0800 (PST) Received: from louie.fa.disney.com by pain.corp.disney.com with ESMTP for freebsd-hackers@FreeBSD.org; Sat, 24 Feb 2001 18:48:45 -0800 Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by louie.fa.disney.com (8.9.2/8.9.2) with ESMTP id SAA10609 for ; Sat, 24 Feb 2001 18:48:07 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) From: Jim.Pirzyk@disney.com Received: by fanimap.fan.fa.disney.com; Sat, 24 Feb 2001 18:48:07 -0800 Message-Id: Date: Sat, 24 Feb 2001 18:48:07 -0800 Subject: Re: gdb and debugging Linux binaries To: "Daniel O'Connor" Cc: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Ahh.. Recompile it? Or is it binary only? Yep binary only. - JimP To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 19:25:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 81EC537B401 for ; Sat, 24 Feb 2001 19:25:42 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA54126; Sat, 24 Feb 2001 22:22:23 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010215154913.P97929@moose.bri.hp.com> References: <20010215154913.P97929@moose.bri.hp.com> Date: Sat, 24 Feb 2001 22:22:22 -0500 To: Steve Roome , hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: bin/22124, a patch to pciconf Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:49 PM +0000 2/15/01, Steve Roome wrote: >Is there any chance someone could take a look at the patch >I supplied for pciconf and perhaps let me have some feedback >on it? > >It's just to clean up the output a little and add the ability >to identify better any non supported chipsets. I thought that >this would be helpful when trying to install FreeBSD and not >knowing which devices were which. > >I'm sure someone will tell me they don't like the way it's >done and I could put the data in tables instead of switch >statements, but whatever, just wondered if there was a chance >of some feedback on it? Were there any replies to this? The PR looks plausibly helpful to me, but I don't do any work in the pciconf area to say if it should be done some other way. I do like the idea of having the option of printing out info as "real words" (when known), instead of just a bunch of numbers that the user is supposed to understand the significance of... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 19:29:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 0CA4C37B401 for ; Sat, 24 Feb 2001 19:29:54 -0800 (PST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f1P3TJO08769 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 25 Feb 2001 04:29:43 +0100 (MET) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0:0:0:104::5]) by cicely7.cicely.de (8.11.2/8.11.2) with ESMTP id f1P3TYd51053; Sun, 25 Feb 2001 04:29:35 +0100 (CET) (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.1/8.11.1) id f1P3TYY00532; Sun, 25 Feb 2001 04:29:34 +0100 (CET) (envelope-from ticso) Date: Sun, 25 Feb 2001 04:29:33 +0100 From: Bernd Walter To: David Gilbert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Large MFS on NFS-swap? Message-ID: <20010225042933.A508@cicely5.cicely.de> References: <15000.8884.6165.759008@trooper.velocet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <15000.8884.6165.759008@trooper.velocet.net>; from dgilbert@velocet.ca on Sat, Feb 24, 2001 at 04:08:04PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 24, 2001 at 04:08:04PM -0500, David Gilbert wrote: > We have an application which is precompiled, for linux, and stupid. > It uses (at times large) scratch files. We want to run this on our > diskless machines (CPU farm) to cut the per-cpu cost of the > computation ($200/drive starts getting significant at a few hundred > machines). > > Anyways, I've tried: > > [1:26:2025]root@spitfire:/usr/u/dgilbert> mount_mfs -T test -s 2097152 -o nosuid,nodev /dev/null /mnt > [1:27:2026]root@spitfire:/usr/u/dgilbert> df -k > Filesystem 1K-blocks Used Avail Capacity Mounted on > 192.168.255.49:/raid/clients/4 124545452 87451588 27130228 76% / > procfs 4 4 0 100% /proc > mfs:57939 507755 1 467134 0% /mnt > [1:28:2027]root@spitfire:/usr/u/dgilbert> tail -5 /etc/disktab > test|test disk|\ > :ty=removable:dt=SCSI:se#512:nt#1:ns#31:nc#18600:ts#1:rm#4800:\ > :pc#20971520:oc#0:\ > :pa#20971520:oa#0:ta=4.2BSD:ba#4096:fa#512: > > The goal is to have about 2 gig of filesystem available for these > (admittedly stupid) scratch files. You have to raise MAXDSIZE and DFLDSIZ in your kernel config. You may also want to try MD instead of MFS. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 19:59:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 7B22D37B503 for ; Sat, 24 Feb 2001 19:59:51 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 2780 invoked by uid 666); 25 Feb 2001 04:11:13 -0000 Received: from i080-119.nv.iinet.net.au (HELO elischer.org) (203.59.80.119) by mail.m.iinet.net.au with SMTP; 25 Feb 2001 04:11:13 -0000 Message-ID: <3A988312.2E238F48@elischer.org> Date: Sat, 24 Feb 2001 19:59:14 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Peter Seebach Cc: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. References: <200102241643.f1OGhw616627@guild.plethora.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Seebach wrote: > > In message , Dag-Erling Smorgrav writes: > >This is all academic since FreeBSD does memory overcommit, so unless > >you run out of address space for your process before you run out of > >actual memory and/or swap (not likely, but quite possible) malloc() > >will never return NULL and you won't know a thing until you dirty one > >page too many and segfault. > > Is there any hope that, some day, a setting could be provided where a program > could request that malloc *NOT* overcommit? There are programs which would > rather know in advance, and clean up, than be killed abruptly. > to not be caught by surprise, simply touch every page after you allocate it. > (To be pedantic, this is a conformance issue. If the memory isn't actually > allocated, malloc shouldn't be returning a non-null pointer.) > > -s > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 20:53: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id D9A6E37B491 for ; Sat, 24 Feb 2001 20:53:06 -0800 (PST) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [204.138.45.2]) by sabre.velocet.net (Postfix) with ESMTP id D417B137F0C; Sat, 24 Feb 2001 23:53:05 -0500 (EST) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.11.2/8.9.3) id f1P4r4a63291; Sat, 24 Feb 2001 23:53:04 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15000.36784.766360.340198@trooper.velocet.net> Date: Sat, 24 Feb 2001 23:53:04 -0500 (EST) To: Bernd Walter Cc: David Gilbert , freebsd-hackers@FreeBSD.ORG Subject: Re: Large MFS on NFS-swap? In-Reply-To: <20010225042933.A508@cicely5.cicely.de> References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Bernd" == Bernd Walter writes: Bernd> You have to raise MAXDSIZE and DFLDSIZ in your kernel config. Bernd> You may also want to try MD instead of MFS. Well... I was reading about md and the man page seemed to imply that it was _very_ dependant on what malloc(9) could do ... and it hinted (or it may be me drawing this conclusion) that md was limited to the size of pysical memory. In this particular case, 99% of the time, the program is writing files that fit into memory. 1% of the time, it writes huge files ... and I'm aware that the mfs filesystem is probably going to perform worse when you write to MFS and then swap ... ... but over all, the other 99% of the time should be a _big_ win. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 22:30:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id B421737B503 for ; Sat, 24 Feb 2001 22:30:56 -0800 (PST) (envelope-from culverk@wam.umd.edu) Received: from rac3.wam.umd.edu (IDENT:root@rac3.wam.umd.edu [128.8.10.143]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id BAA20387; Sun, 25 Feb 2001 01:30:46 -0500 (EST) Received: from rac3.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac3.wam.umd.edu (8.9.3/8.9.3) with SMTP id BAA10857; Sun, 25 Feb 2001 01:30:45 -0500 (EST) Received: from localhost (culverk@localhost) by rac3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id BAA10853; Sun, 25 Feb 2001 01:30:45 -0500 (EST) X-Authentication-Warning: rac3.wam.umd.edu: culverk owned process doing -bs Date: Sun, 25 Feb 2001 01:30:45 -0500 (EST) From: Kenneth Wayne Culver To: Dag-Erling Smorgrav Cc: simond@irrelevant.org, Justin McKnight , FreeBSD-newbies Subject: Re: Compaq e500, 3com cardbus card help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Must not be cardbus then. ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On 24 Feb 2001, Dag-Erling Smorgrav wrote: > Kenneth Wayne Culver writes: > > FreeBSD supports cardbus in -CURRENT, but I wouldn't expect it to ever > > support cardbus in 4.x. If you are daring you can get -CURRENT, but from > > what I hear right now, it's not working very well. > > It works just fine, thank you very much, but it takes some > hand-holding. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 22:45:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id BF71037B491 for ; Sat, 24 Feb 2001 22:45:09 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1P6iuL12016; Sat, 24 Feb 2001 22:44:56 -0800 (PST) (envelope-from dillon) Date: Sat, 24 Feb 2001 22:44:56 -0800 (PST) From: Matt Dillon Message-Id: <200102250644.f1P6iuL12016@earth.backplane.com> To: Bernd Walter Cc: David Gilbert , freebsd-hackers@FreeBSD.ORG Subject: Re: Large MFS on NFS-swap? References: <15000.8884.6165.759008@trooper.velocet.net> <20010225042933.A508@cicely5.cicely.de> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Sat, Feb 24, 2001 at 04:08:04PM -0500, David Gilbert wrote: :> We have an application which is precompiled, for linux, and stupid. :> It uses (at times large) scratch files. We want to run this on our :> diskless machines (CPU farm) to cut the per-cpu cost of the :> computation ($200/drive starts getting significant at a few hundred :> machines). :> :> Anyways, I've tried: :> :> [1:26:2025]root@spitfire:/usr/u/dgilbert> mount_mfs -T test -s 2097152 -o nosuid,nodev /dev/null /mnt Use the vn device to create a swap-backed filesystem. 'man vnconfig'. (In current VN functionality has been merged into MD and MD in swap-backed mode should be used instead ). If you turn softupdates on on the VN based filesystem, it should work quite nicely for small files and yet still be able to handle the very large files (assuming you have sufficient swap). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 23:45:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id DF8D137B401 for ; Sat, 24 Feb 2001 23:45:29 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1P7jPd02969; Sun, 25 Feb 2001 00:45:26 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102250745.f1P7jPd02969@harmony.village.org> To: seebs@plethora.net (Peter Seebach) Subject: Re: Setting memory allocators for library functions. Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 24 Feb 2001 15:17:27 CST." <200102242117.f1OLHR619234@guild.plethora.net> References: <200102242117.f1OLHR619234@guild.plethora.net> Date: Sun, 25 Feb 2001 00:45:25 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102242117.f1OLHR619234@guild.plethora.net> Peter Seebach writes: : In message <9631.983048712@critter>, Poul-Henning Kamp writes: : >No it is not and it never was. : : The C committee believes it is. I do not believe you. Such a "believe" does not appear to be embodied in the C-99 standard. The standard (well draft standard) says: 7.20.3.3 The malloc function Synopsis [#1] #include void *malloc(size_t size); Description [#2] The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate. Returns [#3] The malloc function returns either a null pointer or a pointer to the allocated space. Notice that no guarantees about the ability to use all the space, or that it is somehow guaranteed to be there. It just says that that space is allocated. Nothing more and nothing less. I defy you to quote me someting from the standard that is contrary to my position. I searched through the standard extensively to see if "allocates space" is defined and couldn't find anything other than 'the poitner can be used to access the space allocated.' There appear to be no guarantees that you can always use all of the memory that you've allocated, the performance characterstics of accessing said memory or anything else. Do not read too much into the above words. They mean exactly what they say. FreeBSD is in compliance. The space is indeed allocated to the process address space. System resource issues might get in the way of being able to use that, but that's true of anything you allocate. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 24 23:57:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id B1F2E37B401 for ; Sat, 24 Feb 2001 23:57:28 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1P7vR625246 for ; Sun, 25 Feb 2001 01:57:27 -0600 (CST) Message-Id: <200102250757.f1P7vR625246@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "Sun, 25 Feb 2001 00:45:25 MST." <200102250745.f1P7jPd02969@harmony.village.org> Date: Sun, 25 Feb 2001 01:57:27 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102250745.f1P7jPd02969@harmony.village.org>, Warner Losh writes: >I do not believe you. Such a "believe" does not appear to be embodied >in the C-99 standard. It's somewhat debated, but it has come up in discussions, and the consensus is that, if malloc returns a pointer, the memory has to be usable. >Notice that no guarantees about the ability to use all the space, or >that it is somehow guaranteed to be there. That's what space *is*. Space is something that can store values. If it can't actually store values, it's not space. >space is allocated. Nothing more and nothing less. I defy you to >quote me someting from the standard that is contrary to my position. Heh. >I searched through the standard extensively to see if "allocates >space" is defined and couldn't find anything other than 'the poitner >can be used to access the space allocated.' EXACTLY! If it can't actually be used, then something has gone horribly wrong. >There appear to be no >guarantees that you can always use all of the memory that you've >allocated, the performance characterstics of accessing said memory or >anything else. Performance characteristics are not at issue; I don't think anyone on the committee would complain about an implementation which provided "committed" space by backing it all to disk, all the time. >Do not read too much into the above words. They mean exactly what >they say. FreeBSD is in compliance. Assuming I make the Copenhagen meeting, I'll bring this up again as a DR or something. This gets debated every few years, and the consensus seems to be that malloc *MUST* return a valid pointer to space which can actually be used. >The space is indeed allocated to >the process address space. System resource issues might get in the >way of being able to use that, but that's true of anything you >allocate. That's not what "allocate" means. A resource which is *allocated* is one you actually have access to. Basically, if your interpretation had been intended, the committee would have put in words to the effect of "access to an allocated object invokes undefined behavior". It doesn't. Therefore, the following code: #include int main(void) { unsigned char *p; if (200000000 < SIZE_MAX) { p = malloc(200000000) if (p) { size_t i; for (i = 0; i < 200000000; ++i) { p[i] = i % 5; } } } return 0; } *MUST* succeed and return 0. The program does not invoke undefined behavior; therefore, the compiler is obliged to ensure that it succeeds. It's fine for malloc to fail; it's not fine for the loop to segfault. This is probably one of the single most-unimplemented features in the spec, but it really wouldn't be that hard to provide as an option. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message