From owner-freebsd-hackers Sun Mar 3 0: 2:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by hub.freebsd.org (Postfix) with ESMTP id F038137B416 for ; Sun, 3 Mar 2002 00:02:19 -0800 (PST) Received: from [172.19.20.61] (helo=mrvdomng0.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 16hQwl-0000rY-00 for hackers@freebsd.org; Sun, 3 Mar 2002 09:02:19 +0100 Received: from [217.81.185.237] (helo=sandy) by mrvdomng0.kundenserver.de with esmtp (Exim 3.22 #2) id 16hQwk-0004cp-00 for hackers@FreeBSD.org; Sun, 03 Mar 2002 09:02:18 +0100 Date: Sun, 3 Mar 2002 09:02:23 +0100 From: Developer X-Mailer: The Bat! (v1.49) Personal Reply-To: Developer X-Priority: 3 (Normal) Message-ID: <4432146921.20020303090223@poweros.de> To: hackers Subject: Re: Hello,developer,introduction on ADSL In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello hackers, Friday, March 01, 2002, 12:51:46 PM, you wrote: no mail in .html format please. cant read ist -- Best regards, Developer mailto:Developer@poweros.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 2: 6:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id 4258437B419 for ; Sun, 3 Mar 2002 02:06:56 -0800 (PST) Received: (from mwlucas@localhost) by blackhelicopters.org (8.11.6/8.11.6) id g23A6sH85617; Sun, 3 Mar 2002 05:06:54 -0500 (EST) (envelope-from mwlucas) Date: Sun, 3 Mar 2002 05:06:54 -0500 From: Michael Lucas To: cjclark@alum.mit.edu Cc: hackers@FreeBSD.ORG Subject: Re: crash partition Message-ID: <20020303050654.A85605@blackhelicopters.org> References: <20020302152858.A83208@blackhelicopters.org> <20020302153847.K66092@blossom.cjclark.org> <20020302204518.A84076@blackhelicopters.org> <20020302182009.N66092@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020302182009.N66092@blossom.cjclark.org>; from crist.clark@attbi.com on Sat, Mar 02, 2002 at 06:20:09PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Mar 02, 2002 at 06:20:09PM -0800, Crist J. Clark wrote: > Make a separate swap partition for each since you are going to be > using the disk space anyway if you go with another setup. Hmmm... yes, suppose you're right. Thanks for directing me to the obvious. -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 2:54: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by hub.freebsd.org (Postfix) with ESMTP id B0FF337B402 for ; Sun, 3 Mar 2002 02:54:02 -0800 (PST) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.6/8.11.6) id g23Arww90619; Sun, 3 Mar 2002 10:53:58 GMT (envelope-from rb) Message-Id: <4.3.2.7.2.20020303104801.00bfb300@gid.co.uk> X-Sender: rbmail@gid.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 03 Mar 2002 10:53:56 +0000 To: Luigi Rizzo From: Bob Bishop Subject: Re: Multicast problem with sis interface? Cc: "George V. Neville-Neil" , Leo Bicknell , Doug Ambrisko , hackers@FreeBSD.ORG In-Reply-To: <20020301104705.A36640@iguana.icir.org> References: <20020301184123.GA5908@ussenterprise.ufp.org> <200203010557.VAA1802420@meer.meer.net> <4.3.2.7.2.20020222165515.00c14850@gid.co.uk> <200203010557.VAA1802420@meer.meer.net> <4.3.2.7.2.20020301112956.00c5b550@gid.co.uk> <20020301035623.A32974@iguana.icir.org> <20020301184123.GA5908@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, The padding thing is a red herring - sorry about that. The real problem seems to be the interface's filtering, because setting the interface promiscuous makes the problem go away. See kern/35511 for details and a workaround. I imagine the proper fix is a 2 minute job for someone who understands the chipset. -- Bob Bishop +44 (0)118 977 4017 rb@gid.co.uk fax +44 (0)118 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 7:19:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ip68-14-62-49.no.no.cox.net (ip68-14-62-49.no.no.cox.net [68.14.62.49]) by hub.freebsd.org (Postfix) with ESMTP id 8468B37B402 for ; Sun, 3 Mar 2002 07:19:39 -0800 (PST) Received: (from conrads@localhost) by ip68-14-62-49.no.no.cox.net (8.11.6/8.11.6) id g23FJd926309 for freebsd-hackers@freebsd.org; Sun, 3 Mar 2002 09:19:39 -0600 (CST) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 03 Mar 2002 09:19:38 -0600 (CST) Reply-To: conrads@cox.net Organization: A Rag-Tag Band of Drug-crazed Hippies From: Conrad Sabatier To: freebsd-hackers@freebsd.org Subject: A few questions about a few includes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Am I just completely stupid, or do we have a few things that could use a little cleaning up in /usr/include as well as in the man page for kvm_*? System: FreeBSD 4.5-STABLE 1) The man page for the kvm_* functions lists the following #include dependencies: #include #include #include However, kvm.h contains some declarations that also require and (namely, struct kinfo_proc and struct proc). Otherwise, one might encounter warnings/errors re: incomplete types. 2) If compiling with the -pedantic switch, one might see something like this: In file included from main.c:151: /usr/include/sys/proc.h:108: warning: ANSI C forbids zero-size array `ar_args' In : /* * pargs, used to hold a copy of the command line, if it had a sane * length */ struct pargs { u_int ar_ref; /* Reference count */ u_int ar_length; /* Length */ u_char ar_args[0]; /* Arguments */ }; This does indeed seem to make little or no sense. Could someone explain this? Is ar_args supposed to be a pointer or what? 3) Furthermore, on including , one then sees this: In file included from /usr/include/sys/user.h:40, from main.c:153: /usr/include/machine/pcb.h:90: warning: struct has no members In : /* * The pcb is augmented with machine-dependent additional data for * core dumps. For the i386: ??? */ struct md_coredump { }; Nowhere under /usr/include is a more complete definition of md_coredump to be found. This looks awfully "kludgy" to me. I do hope someone can shed some light here. Thanks. -- Conrad Sabatier First Rule of History: History doesn't repeat itself -- historians merely repeat each other. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 9:28:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from damnhippie.dyndns.org (12-253-177-2.client.attbi.com [12.253.177.2]) by hub.freebsd.org (Postfix) with ESMTP id 25D1B37B432 for ; Sun, 3 Mar 2002 09:27:17 -0800 (PST) Received: from [172.22.42.2] (peace.hippie.lan [172.22.42.2]) by damnhippie.dyndns.org (8.11.6/8.11.6) with ESMTP id g23HRG852615 for ; Sun, 3 Mar 2002 10:27:16 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Sun, 03 Mar 2002 10:27:17 -0700 Subject: Re: A few questions about a few includes From: Ian To: freebsd-hackers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > In : > > /* > * pargs, used to hold a copy of the command line, if it had a sane > * length > */ > struct pargs { > u_int ar_ref; /* Reference count */ > u_int ar_length; /* Length */ > u_char ar_args[0]; /* Arguments */ > }; > > This does indeed seem to make little or no sense. Could someone explain > this? Is ar_args supposed to be a pointer or what? This is a common technique for defining a structure which is some descriptive information about an array of objects is followed by an open-ended array of those objects. (In this case the "objects" are characters.) The ar_args member of the structure gives a name to that location in the structure without reserving any space (and thus when the technique is used, there can only ever be one [0] member and it must be at the end of the structure). You access the open-ended array of objects just as you would any other array embedded within a structure, E.G. instance->ar_args[n]. Not all compilers support defining zero-length arrays like this. And that's a pity; it's an incredibly useful technique, and the alternatives to it are not nearly as elegant and generally involve ugly recasting of pointers. -- Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 10: 0:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by hub.freebsd.org (Postfix) with ESMTP id 64C9B37B41A for ; Sun, 3 Mar 2002 10:00:33 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g23I0W415833 for ; Sun, 3 Mar 2002 19:00:32 +0100 (CET) Received: from falcon.midgard.homeip.net (h217n1fls20o913.telia.com [212.181.162.217]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id TAA14278 for ; Sun, 3 Mar 2002 19:00:30 +0100 (CET) Received: (qmail 56081 invoked by uid 1001); 3 Mar 2002 18:00:30 -0000 Date: Sun, 3 Mar 2002 19:00:30 +0100 From: Erik Trulsson To: Ian Cc: freebsd-hackers Subject: Re: A few questions about a few includes Message-ID: <20020303180029.GA56041@student.uu.se> Mail-Followup-To: Ian , freebsd-hackers References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote: > > > > In : > > > > /* > > * pargs, used to hold a copy of the command line, if it had a sane > > * length > > */ > > struct pargs { > > u_int ar_ref; /* Reference count */ > > u_int ar_length; /* Length */ > > u_char ar_args[0]; /* Arguments */ > > }; > > > > This does indeed seem to make little or no sense. Could someone explain > > this? Is ar_args supposed to be a pointer or what? > > This is a common technique for defining a structure which is some > descriptive information about an array of objects is followed by an > open-ended array of those objects. (In this case the "objects" are > characters.) The ar_args member of the structure gives a name to that > location in the structure without reserving any space (and thus when the > technique is used, there can only ever be one [0] member and it must be at > the end of the structure). You access the open-ended array of objects just > as you would any other array embedded within a structure, E.G. > instance->ar_args[n]. > > Not all compilers support defining zero-length arrays like this. And that's > a pity; it's an incredibly useful technique, and the alternatives to it are > not nearly as elegant and generally involve ugly recasting of pointers. For those compilers that don't support zero-length arrays one can still use the same trick but with a one-element array at the end of the struct. One just has to remember to that element into account when allocating memory for the structure. Slightly uglier, but not much. It might be worth mentioning that this trick is not actually allowed according to the C standard and in principle invokes undefined behaviour. OTOH, AFAIK the trick does work on all existing compilers, so while it is not standard-conforming it is quite portable. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 10:53:41 2002 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 9052A37B400; Sun, 3 Mar 2002 10:53:00 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g23IqrD53976; Sun, 3 Mar 2002 13:52:54 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 3 Mar 2002 13:52:53 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: developers@FreeBSD.org, hackers@FreeBSD.org Subject: December 2001, January 2002 Bi-Monthly FreeBSD Status Report Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Attached below, please find the text version of the bi-monthloy status report. It's actually been up on the web for a few days. Apologies for any delays :-). It's worth noting that report submission has dropped off a bit for this report, and I hope for better on the next report, for which I'll begin to collect entries in about three weeks. December 2001 - January 2002 Status Report Introduction This bi-monthly report covers development activities on the FreeBSD Project for December 2001 and January 2002. A variety of accomplishments have been made over the last couple of months, including strong progress relating to the KSE project, which brings Scheduler Activations to the FreeBSD kernel, as well as less visible infrastructure projects such as improvements to the mount interface, PAM integration work, and translation efforts. Shortly following the deadline for this status report, the BSD Conference and FreeBSD Developer Summit were held, and will be covered in the next bi-monthly report at the end of March. Plans are already under way for the USENIX Annual Technical Conference in Monterey, CA, later this year, and all and sundry are encouraged to attend to get further insight in FreeBSD development. Robert Watson * "GEOM" - generalized block storage manipulation * Bluetooth stack for FreeBSD (Netgraph implementation) * FreeBSD C99 & POSIX Conformance Project * FreeBSD in Bulgarian * FreeBSD Java Project * jp.FreeBSD.org daily SNAPSHOTs project * jpman project * KAME * KSE Status Report * Netgraph ATM * New mount(2) API * Pluggable Authentication Modules * Revised {mode,log}page support for camcontrol * SMPng * TrustedBSD ACLs * TrustedBSD Audit * TrustedBSD MAC Implementation * USB stack maintenance "GEOM" - generalized block storage manipulation URL: http://www.freebsd.org/~phk/Geom/ Contact: Poul-Henning Kamp This project is now finally underway, thanks to DARPA and NAI getting a sponsorship lined up. The infrastructure code and data structures are currently taking form inside a userland simulation harness. Basic MBR and BSD methods have been written and device attach/taste/dettach algorithms been implemented and validated. ---------------------------------------------------------------------- Bluetooth stack for FreeBSD (Netgraph implementation) Contact: Maksim Yevmenkin The project is making progress. The goal is to design and implement Host Controller Interface (HCI) and Link Layer Control and Adaptation Protocol (L2CAP) layers using Netgraph framework. More distant goal is to write support for Service Discovery Protocol (SDP) and RFCOMM protocol (Serial port emulation over Bluetooth link) . All information was obtained from Bluetooth Specification Book v1.1. Project status: In progress. 1) Design: mostly complete, there are some minor issues to be resolved. 2) Implementation: Kernel - HCI and L2CAP Netgraph nodes have been implemented; 3) User space (API, library, utilities) - in progress. 4) Testing: In progress. I do not have real Bluetooth hardware at this point, so i wrote some tools that allow me to test the code. Some of them will be used as foundation for future user space utilities. Issues: 1) Bluetooth hardware; I do not have real Bluetooth hardware, so if people can donate hardware/specs it would be great. I promise to write all required drivers and make them available. I also promise to return hardware/specs on first request. 2) Project name; I would like to see the name that reflects the following: it is a Bluetooth stack, implementation is for FreeBSD and implementation is based on Netgraph framework ---------------------------------------------------------------------- FreeBSD C99 & POSIX Conformance Project URL: http://people.FreeBSD.org/~mike/c99/ Contact: Mike Barcroft Contact: FreeBSD-Standards Mailing List A significant amount of progress was made in December and January, particularly in the area of utility conformance. Several utilities were updated to conform to SUSv3, they include: at(1), mailx(1), pwd(1), split(1), and uudecode(1). Several patches have been submitted to increase conformance in other utilities, they include: fold(1), patch(1), m4(1), nice(1), pr(1), renice(1), wc(1), and xargs(1). These are in the process of being reviewed and committed. Two new utilities have been written, specifically pathchk(1) and tabs(1). These are also being reviewed and will be committed shortly. A patch which implements most of the requirements of scanf(3) is being reviewed and is expected to be committed shortly. This will allow us to MFC a number of new functions and headers. Additionally, work has started on wide string and complex number support. ---------------------------------------------------------------------- FreeBSD in Bulgarian URL: http://www.FreeBSD-bg.ringlet.net/ URL: http://people.FreeBSD.org/~roam/bg/ Contact: Peter Pentchev The FreeBSD in Bulgarian project aims to bring a more comfortable working environment to Bulgarian users of the FreeBSD OS. This includes, but is not limited to, font, keymap and locale support, translation of the FreeBSD documentation into Bulgarian, local user groups and various forms of on-line help channels and discussion forums to help Bulgarians adopt and use FreeBSD. A guide for using FreeBSD with Bulgarian settings has been put up on the project's website. The CVS repository will be made public shortly, linked to on the URL's above. An independent project for making FreeBSD easier to use by Bulgarians has appeared, . It also hosts a mailing list for discussions of FreeBSD in Bulgarian, stable@FreeBSD-bg.org. For more information about the mailing list, send an e-mail with "help" in the message body to majordomo@FreeBSD-bg.org. ---------------------------------------------------------------------- FreeBSD Java Project URL: http://www.freebsd.org/java Contact: Greg Lewis The past two months have been an exciting time in the FreeBSD Java Project with the signing of a license between the FreeBSD Foundation and Sun allowing us access to updated JDK source code and the Java Compatibility Kit (JCK). This license will also allow the project to release a binary version of both the JDK and JRE once JCK testing is complete. Work on this testing is under way with the project hopeful of being able to make a binary release in the not too distant future. In lieu of the binary release which was hoped for with FreeBSD 4.5 the project will release an updated source patchset this weekend. This patchset will feature further work on the FreeBSD "native" threads subsystem from Bill Huey. Also, thanks to hard work by Joe Kelsey and Fuyuhiko Maruyama, the patchset will for the first time feature a working Java browser plugin! ---------------------------------------------------------------------- jp.FreeBSD.org daily SNAPSHOTs project URL: http://snapshots.jp.FreeBSD.org/ URL: http://www.jp.FreeBSD.org/snapshots/notes.html Contact: Makoto Matsushita I've update OS of buildboxes to the latest FreeBSD 5-current and 4-stable. Everything goes fine. From January 2002, I've started a webzine, SNAPSHOTS Notes (only Japanese version is available). SNAPSHOTs Notes pickups tips and information especially for the people living with FreeBSD 5-current/4-stable. Article or idea for SNAPSHOTs notes are always welcome (you don't need to write in Japanese :-). ---------------------------------------------------------------------- jpman project URL: http://www.jp.FreeBSD.org/man-jp/ Contact: Kazuo Horikawa For 4.5-RELEASE, port ja-man-doc-4.5.tgz is in sync with base system except for OpenSSH pages (OpenSSH 2.3 based instead of 2.9) and perl5 pages (jpman project do not maintain). Section 3 updating has 55% finished. OKAZAKI Tetsurou has incorporated changes on base system's groff into port japanese/groff. MORI Kouji has fixed two bugs of port japanese/man. ---------------------------------------------------------------------- KAME URL: http://www.kame.net/ Contact: KAME core team The KAME project is currently focusing on the scoped addressing architecture, the advanced API implementation, NATPT and the mobile ipv6 implementation. Though these stuffs are not stable enough to be merge into the FreeBSD tree, you can get and try them from the above URL. ---------------------------------------------------------------------- KSE Status Report URL: http://www.freebsd.org/~julian/ URL: http://www.freebsd.org/~jasone/kse/ Contact: Julian Elischer The KSE project (an attempt to support scalable thread in FreeBSD using kernel support), has reached What I call "milestone 3". At this milestone it is possible to run a multithreaded program on a single CPU but with full concurrancy of threads on that CPU. In other words the kernel supports the fact that one thread can block by allowing another thread to run in its place. A test program that demonstrates this is available at the above website. Milestone 4 will be to allow threads from the same program to run on multiple CPUS but may require more input from the SMPNG project. I am at the moment (Feb 6) getting ready to commit a first set of changes for milestone 3, that have no real effect but serve to drastically reduce the complexity of the remaining diff so that others can read it mor eeasily. After changes to libkvm to support this diff have been added it should be possible to run 'ps' and look at multiple threads in a treaded process. I will be demonstrating KSE/M3 at BSDcon. ---------------------------------------------------------------------- Netgraph ATM URL: ftp://ftp.fokus.gmd.de/pub/cc/cats/usr/harti/ngatm/ Contact: Harti Brandt The Netgraph ATM package has been split into a number of smaller packages: bsnmp is a general-purpose SNMP daemon with support for loadable modules. Two modules come with it: one implementing the standard network-interface and IP related parts of MIB-2 and one for interfacing other modules to the NetGraph sub-system. ngatmbase contains the drivers for the ATM hardware, the ng_atm netgraph type and a few test tools. This package allows one to use ATM PVCs. It should be possible, for example, to do PPP over ATM with this package. Both bsnmp and ngatmbase are available in version 1.0 under the link above. Two other modules will be released in february: ngatmsig containing the UNI-4.0 signalling stack as netgraph nodes and ngatmip containing CLIP and LANE-2.0. ---------------------------------------------------------------------- New mount(2) API Contact: Poul-Henning Kamp Contact: Maxime Henrion Now that the patch has been mailed to the freebsd-arch@freebsd.org mailing list, and that there were no objections, the commit will happen soon. Poul is currently testing it in his own tree. After it has been committed, it will be time to modify the filesystems in the tree to use VFS_NMOUNT instead of VFS_MOUNT. Mount(8) will also need some modifications. Some new manpages -- nmount(2) and kernel_vmount(9) -- are being created in the meantime. ---------------------------------------------------------------------- Pluggable Authentication Modules URL: http://openpam.sourceforge.net/ Contact: Mark Murray Contact: Dag-Erling Smo/rgrav OpenPAM, a new library intended to replace Linux-PAM in FreeBSD, has been written and is undergoing integration testing. It is available for download from the URL listed above. In addition to this, a couple of new modules have been written (pam_lastlog(8), pam_login_access(8)), and the pam_unix(8) module has been extended to perform most of the tasks normally performed by login(1), which is now fully PAMified. The PAM FDP article has been put on hold until OpenPAM replaces Linux-PAM in CVS, to avoid wasting effort on soon-to-be obsolete documentation. ---------------------------------------------------------------------- Revised {mode,log}page support for camcontrol Contact: Kelly Yancey Extending camcontrol's page definition file format to include both modepage and logpage definitions; adding support to camcontrol to query and reset log page parameters. Consideration is being made to possibly include support for diagnostic and vital product data pages, but that is outside the current project scope. New page definition file format includes capability to conditionally include page definitions based on SCSI INQUIRY results allowing vendor-specific pages to be described also. Approximately 90% complete. ---------------------------------------------------------------------- SMPng URL: http://www.FreeBSD.org/smp/ Contact: smp@FreeBSD.org Alfred Perlstein commited file descriptor locking code which was definetly a good push towards trying to lock down some important pieces of global data. Peter Wemm has made progress on pmap cleanups for x86 SMP TLB shootdowns. Matt Dillon and John Baldwin have made progress on getting patches done for moving accesses to ucred's out from under Giant's protection. John Baldwin has also made some commits in order to get the alpha port's SMP working. Matt Dillon has plans for hunting down fileops locking issues in order to continue his previous Giant pushdown work. ---------------------------------------------------------------------- TrustedBSD ACLs URL: http://www.fxp.org/jedgar/ACL/ Contact: Chris Faulhaber Patches for cp(1), ls(1), and mv(1) to bring in POSIX.1e-compliant Access Control List support have been updated to patch against builds of -CURRENT. Other system utilities are currently being evaluated for ACL support including install(1) (patch available) and mtree(8). Work is in progress to verify the native getfacl(1), setfacl(1), and other utilities build and work correctly on other ACL-enabled systems (e.g. Linux w/ACL patches) and to help verify POSIX-compliance of the continuing TrustedBSD work along with other systems. Finally, experimental Perl and PHP modules are available allowing limited access to native ACLs for languages other than C. ---------------------------------------------------------------------- TrustedBSD Audit URL: http://www.TrustedBSD.org/ Contact: trustedbsd-discuss Robert Watson created the TrustedBSD audit perforce tree, which is a branch from the TrustedBSD base tree, in order to start pushing development efforts towards using a revision control system. Andrew Reiter started to merge in some framework related code for generation of audit records, enqueueing writes, and handling data writing. There is a great deal of work to be done with updates and discussion on the trustedbsd-discuss@TrustedBSD.org mailing list. ---------------------------------------------------------------------- TrustedBSD MAC Implementation URL: http://www.TrustedBSD.org/ Contact: Robert Watson Substantial progress has been made towards a working MAC implementation. The focus over the last two months has been moving from a hard-coded series of MAC policies to a more flexible implementation. A pluggable policy framework has been created (and is still under development), supporting Biba, MLS, TE, a "BSD Extended" model, and a sample mac_none module. Some modules must be compiled in or loaded prior to boot; others may be introduced at run-time. Support for networking has improved, with improved handling of IP fragmentation in IPv4, support for various pseudo-interfaces such as if_tun and if_tap, improved integration into userland, NFS-related fixes, moving the VFS enforcement out of individual filesystems, support for a 'multilevel' mount flag, support for explicit labeling in procfs and devfs, addition of an 'extattrctl lsattr' argument to list EAs on a filesystem, support for label ranges in the Biba and MAC policies, and much more. Targets for the next two months include more universal enforcement of VFS-related calls, improved support for alternative ABIs, improved flexibility of in-kernel subject and object labels, support for IPv6 and IPsec, and improved support for NFS serving. Development continues in the FreeBSD Perforce repository, which may be accessed using cvsup. ---------------------------------------------------------------------- USB stack maintenance Contact: Josef Karthauser I've been working to integrate recent improvements in the NetBSD usb stack to FreeBSD -current. Both NetBSD and OpenBSD currently share the same source, as FreeBSD did too at once point before it diverged. The goal is to get back to that state, but there are many improvements on both sides that need to be merged before this is complete. I'm currently looking for someone to help maintain usb in -stable. Please let me know if you're interested. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 11:16:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by hub.freebsd.org (Postfix) with ESMTP id 4674E37B400 for ; Sun, 3 Mar 2002 11:16:44 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Sun, 3 Mar 2002 11:11:23 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 6D87EBA03; Sun, 3 Mar 2002 11:05:01 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: conrads@cox.net, freebsd-hackers@FreeBSD.ORG Subject: Re: A few questions about a few includes Date: Sun, 3 Mar 2002 11:05:00 -0500 X-Mailer: KMail [version 1.3] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020303160501.6D87EBA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday 03 March 2002 10:19 am, Conrad Sabatier wrote: > Am I just completely stupid, or do we have a few things that could use a > little cleaning up in /usr/include as well as in the man page for kvm_*? > > System: FreeBSD 4.5-STABLE > > 2) If compiling with the -pedantic switch, one might see something like > this: > > In file included from main.c:151: > /usr/include/sys/proc.h:108: warning: ANSI C forbids zero-size array > `ar_args' > > In : > > /* > * pargs, used to hold a copy of the command line, if it had a sane > * length > */ > struct pargs { > u_int ar_ref; /* Reference count */ > u_int ar_length; /* Length */ > u_char ar_args[0]; /* Arguments */ > }; > > This does indeed seem to make little or no sense. Could someone explain > this? Is ar_args supposed to be a pointer or what? I can explain this one; it's a moderately-common C programming technique. This strucuture will be allocated dynamically. I could be declared like struct pargs { ... u_char *ar_args; } and allocated like pargs = malloc(sizeof(struct pargs)); pargs->ar_args = malloc(args_size); but it's a lot more efficient to declare it as above and allocate it as pargs = malloc(sizeof(struct pargs) + args_+size); since pointers & arrays are equivalent, except that array data is at the location of the name rather than having a pointer to the data at that location, a [0] array has exactly the right semantics for this. You can declare a [1] array for this to make ANSI happy, but then you have to subtract in the allocation and besides that the [0] is "self-documenting" for those who are familir with the technique--after all, there isn't anything *else* you can do with a [0]-sized array. > 3) Furthermore, on including , one then sees this: > > In file included from /usr/include/sys/user.h:40, > from main.c:153: > /usr/include/machine/pcb.h:90: warning: struct has no members > > In : > > /* > * The pcb is augmented with machine-dependent additional data for > * core dumps. For the i386: ??? > */ > struct md_coredump { > }; > > Nowhere under /usr/include is a more complete definition of md_coredump to > be found. This looks awfully "kludgy" to me. A little guesswork here, but this seems pretty self-explanatory to me, too. The md_coredump{} is a structure that includes the *extra* information (beyond what's already in the portable structure) for coredumps on a given architecture. In the case of the 386, there is no useful extra information, so the structure is empty, but since there's a structure someplace that has an instance of struct md_coredump, it must be declared. Since there's no useful content, it is declared as being empty. Seems pretty elegant to me. If I'm off-base here, somebody please jump in! > > I do hope someone can shed some light here. Thanks. [Your point #1 seems valid to me, though.] -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 13:41:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from www.kozubik.com (www.kozubik.com [198.78.70.162]) by hub.freebsd.org (Postfix) with ESMTP id 3D7A437B405 for ; Sun, 3 Mar 2002 13:41:39 -0800 (PST) Received: from localhost (john@localhost) by www.kozubik.com (8.11.0/8.11.0) with ESMTP id g23LMZO85199 for ; Sun, 3 Mar 2002 13:22:35 -0800 (PST) (envelope-from john@kozubik.com) Date: Sun, 3 Mar 2002 13:22:35 -0800 (PST) From: John Kozubik X-Sender: john@www To: freebsd-hackers@freebsd.org Subject: periodic firewire max-out question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I still do not yet own 63 firewire devices, and so, once again, I am wondering if anyone here has ever actually connected 128 devices to a firewire host adaptor and had operational success... (or heard reports of it being successfully done in the wild ?) Comments welcome. thanks. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 17:27:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by hub.freebsd.org (Postfix) with ESMTP id 5F82F37B416 for ; Sun, 3 Mar 2002 17:27:03 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Sun, 3 Mar 2002 20:25:41 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id A1681BA05; Sun, 3 Mar 2002 20:20:20 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Erik Trulsson , Ian Subject: Re: A few questions about a few includes Date: Sun, 3 Mar 2002 20:20:20 -0500 X-Mailer: KMail [version 1.3] Cc: freebsd-hackers References: <20020303180029.GA56041@student.uu.se> In-Reply-To: <20020303180029.GA56041@student.uu.se> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020304012020.A1681BA05@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday 03 March 2002 01:00 pm, Erik Trulsson wrote: > On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote: > > > In : > > > > > > /* > > > * pargs, used to hold a copy of the command line, if it had a sane > > > * length > > > */ > > > struct pargs { > > > u_int ar_ref; /* Reference count */ > > > u_int ar_length; /* Length */ > > > u_char ar_args[0]; /* Arguments */ > > > }; > > It might be worth mentioning that this trick is not actually allowed > according to the C standard and in principle invokes undefined > behaviour. OTOH, AFAIK the trick does work on all existing compilers, > so while it is not standard-conforming it is quite portable. I can't even imagine how one *would* write a compiler where this would fail--does anybody know the putative risk that led ANSI to "ban" this (IMHO) perfectly-reasonable bahvior? -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 18:11:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id A0DA337B400 for ; Sun, 3 Mar 2002 18:11:53 -0800 (PST) Received: from pool0165.cvx40-bradley.dialup.earthlink.net ([216.244.42.165] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16hhx2-0002UO-00; Sun, 03 Mar 2002 18:11:44 -0800 Message-ID: <3C82D7D1.F9AD882C@mindspring.com> Date: Sun, 03 Mar 2002 18:11:29 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Brian T.Schellenberger" Cc: Erik Trulsson , Ian , freebsd-hackers Subject: Re: A few questions about a few includes References: <20020303180029.GA56041@student.uu.se> <20020304012020.A1681BA05@i8k.babbleon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Brian T.Schellenberger" wrote: > I can't even imagine how one *would* write a compiler where this would > fail--does anybody know the putative risk that led ANSI to "ban" this (IMHO) > perfectly-reasonable bahvior? Order of structure elements is undefined. Zero length arrays are undefined. Also, packing is undefined. You can basically get arouns all of this by declaring the array to be 1 byte, e.g.: struct pargs { u_int ar_ref; /* Reference count */ u_int ar_length; /* Length */ u_char ar_args[1]; /* Arguments */ }; And then sizing the allocation unit relatively, e.g., dont use: sizeof(struct pargs) + byte_count use instead: (int)&((struct pargs *)0)->ar_args + byte_count; To get the size of the elements up to but not including the one byte declared, regardless of alignment or packing. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 18:34:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.143.238.93]) by hub.freebsd.org (Postfix) with SMTP id 9F8C237B400 for ; Sun, 3 Mar 2002 18:34:38 -0800 (PST) Received: (qmail 55691 invoked by uid 1001); 4 Mar 2002 12:34:36 +1000 X-Posted-By: GJB-Post 2.23 27-Nov-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Uptime: 53 days, 18:54 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Mon, 04 Mar 2002 12:34:36 +1000 From: Greg Black To: Terry Lambert Cc: "Brian T.Schellenberger" , Erik Trulsson , Ian , freebsd-hackers Subject: Re: A few questions about a few includes References: <20020303180029.GA56041@student.uu.se> <20020304012020.A1681BA05@i8k.babbleon.org> <3C82D7D1.F9AD882C@mindspring.com> In-reply-to: <3C82D7D1.F9AD882C@mindspring.com> of Sun, 03 Mar 2002 18:11:29 PST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: | Order of structure elements is undefined. Zero length arrays | are undefined. Also, packing is undefined. Close, but no cigar. The /order/ is defined in C89 (Section 6.5.2.1) with the following words: Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 3 21:20:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ip68-14-62-49.no.no.cox.net (ip68-14-62-49.no.no.cox.net [68.14.62.49]) by hub.freebsd.org (Postfix) with ESMTP id D106B37B402 for ; Sun, 3 Mar 2002 21:20:15 -0800 (PST) Received: (from conrads@localhost) by ip68-14-62-49.no.no.cox.net (8.11.6/8.11.6) id g245KFe02242 for freebsd-hackers@FreeBSD.ORG; Sun, 3 Mar 2002 23:20:15 -0600 (CST) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020303160501.6D87EBA03@i8k.babbleon.org> Date: Sun, 03 Mar 2002 23:20:15 -0600 (CST) Reply-To: conrads@cox.net Organization: A Rag-Tag Band of Drug-crazed Hippies From: Conrad Sabatier To: freebsd-hackers@FreeBSD.ORG Subject: Re: A few questions about a few includes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks for all the very interesting followups, folks. I learned something today! I really must start reading this list more often. :-) -- Conrad Sabatier Bennett's Laws of Horticulture: (1) Houses are for people to live in. (2) Gardens are for plants to live in. (3) There is no such thing as a houseplant. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 1:18:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail5.sh163.net (mail5.sh163.net [202.96.194.136]) by hub.freebsd.org (Postfix) with SMTP id 7F6D137B404 for ; Mon, 4 Mar 2002 01:18:25 -0800 (PST) Received: (Rockmail 26808 invoked from network); 4 Mar 2002 09:18:18 -0000 Received: from unknown (HELO relay) ([61.165.69.9]) (envelope-sender ) by mail5.sh163.net (Rockmail) with SMTP for ; 4 Mar 2002 09:18:18 -0000 Reply-To: zmzl@sh163.net From: zmzl@sh163.net To: 尊敬的客户@FreeBSD.ORG Subject: 2002中国（上海）国际给排水水处理展览会 Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312_CHARSET" Date: Mon, 4 Mar 2002 17:22:31 +0800 Message-Id: <20020304091825.7F6D137B404@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 第三届 2002中国（上海）国际给排水水处理展览会 2002中国（上海）国际环保技术设备展览会 尊敬的各相关单位： 您好！ 由建设部信息中心、中国环境科学学会、上海市净水技术学会、东浩集 团上海外服国际展览广告公司等单位主办，上海中贸展览服务有限公司承办 的"2002中国（上海）国际给排水水处理展览会及2002中国（上海）国际环 保技术设备展览会"将于2002年5月15日-17日在上海世贸商城隆重举办，作 为建设、环保主管部门全力支持与主办的"上海国际环保水展"已成功举办两 届，以其规模大、专业水准高、参展厂商多、展出产品新而在业界影响深远、 声誉卓著。 中国入世，全球聚焦最具潜力的中国市场，本届展会现已吸引了来自美 国、韩国、日本、德国、意大利、法国、加拿大及中国台湾地区等国家与地 区385家厂商参展，展出面积近9000平米，同时主办机构还将邀请相关行业 权威人士及知名企业举办专题报告会和技术交流会。届时国内外环保、水行 业专业买家云集申城。 本次展会将成为行业产品竞技的舞台，传递市场信息和交流先进技术的 窗口，良机难得，切莫错失！ 欢迎各相关单位参观、参展！我们期待您的参与及支持！ 上海中贸展览服务有限公司 Http:www.zhongmao.com.cn E-mail:zmzl@sh163.net 联系电话：021-54641713 参展、参观回执 我单位有兴趣参展2002上海国际环保水展，请寄/传真详细资料 我单位有兴趣参观2002上海国际环保水展，请寄参观券 张 单位名称： 业务范围： 详细地址： 联系人： 邮 编： 电 话： 传 真： E-mail： To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 1:29:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 789C537B400 for ; Mon, 4 Mar 2002 01:29:29 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g249TIe28441; Mon, 4 Mar 2002 10:29:19 +0100 (MET) Date: Mon, 4 Mar 2002 10:29:18 +0100 (CET) From: Harti Brandt To: Erik Trulsson Cc: Ian , freebsd-hackers Subject: Re: A few questions about a few includes In-Reply-To: <20020303180029.GA56041@student.uu.se> Message-ID: <20020304102750.O74223-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 3 Mar 2002, Erik Trulsson wrote: ET>On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote: ET>> > ET>> > In : ET>> > ET>> > /* ET>> > * pargs, used to hold a copy of the command line, if it had a sane ET>> > * length ET>> > */ ET>> > struct pargs { ET>> > u_int ar_ref; /* Reference count */ ET>> > u_int ar_length; /* Length */ ET>> > u_char ar_args[0]; /* Arguments */ ET>> > }; ET>> > ET>> > This does indeed seem to make little or no sense. Could someone explain ET>> > this? Is ar_args supposed to be a pointer or what? ET>> ET>> This is a common technique for defining a structure which is some ET>> descriptive information about an array of objects is followed by an ET>> open-ended array of those objects. (In this case the "objects" are ET>> characters.) The ar_args member of the structure gives a name to that ET>> location in the structure without reserving any space (and thus when the ET>> technique is used, there can only ever be one [0] member and it must be at ET>> the end of the structure). You access the open-ended array of objects just ET>> as you would any other array embedded within a structure, E.G. ET>> instance->ar_args[n]. ET>> ET>> Not all compilers support defining zero-length arrays like this. And that's ET>> a pity; it's an incredibly useful technique, and the alternatives to it are ET>> not nearly as elegant and generally involve ugly recasting of pointers. ET> ET>For those compilers that don't support zero-length arrays one can still ET>use the same trick but with a one-element array at the end of the ET>struct. One just has to remember to that element into account when ET>allocating memory for the structure. Slightly uglier, but not much. ET> ET>It might be worth mentioning that this trick is not actually allowed ET>according to the C standard and in principle invokes undefined ET>behaviour. OTOH, AFAIK the trick does work on all existing compilers, ET>so while it is not standard-conforming it is quite portable. My ISO-C draft copy allows in section 6.7.2.1 paragraph 2 the last member of a structure to be an incomplete array type and paragraph 16 shows an example. Was this removed from the final standard? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 1:54:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from vagabond.auriga.ru (vagabond.auriga.ru [80.240.102.246]) by hub.freebsd.org (Postfix) with ESMTP id C6A4137B404 for ; Mon, 4 Mar 2002 01:54:24 -0800 (PST) Received: from localhost (localhost [[UNIX: localhost]]) by vagabond.auriga.ru (8.11.2/8.11.2) id g249sLQ11692 for freebsd-hackers@freebsd.org; Mon, 4 Mar 2002 12:54:21 +0300 Content-Type: Multipart/Mixed; charset="koi8-r"; boundary="------------Boundary-00=_KU0GGJHC0Z4D9XOU7K33" From: "Alexey V. Neyman" To: freebsd-hackers@freebsd.org Subject: please review the manpage Date: Mon, 4 Mar 2002 12:54:20 +0300 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02030412542008.22942@vagabond.auriga.ru> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --------------Boundary-00=_KU0GGJHC0Z4D9XOU7K33 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Hello there! Excuse me if this is a wrong list for such submissions. A suggested manpage for EVENTHANDLER(9) is attached. It should be referenced from boot(9) instead of non-existent at_shutdown(9). at_shutdown(9) was retired even before 4.0-R, however, it's still referenced from boot(9) in -stable. By the way, is there any reason for at_fork/at_exec function not to be retired in favor of EVENTHANDLER_XXX macros? Regards, Alexey. -- <-------------------------> ) May the Sun and Water ( Regards, Alexey V. Neyman ) always fall upon you! ( mailto:alex.neyman@auriga.ru <-------------------------> --------------Boundary-00=_KU0GGJHC0Z4D9XOU7K33 Content-Type: application/x-troff; charset="koi8-r"; name="EVENTHANDLER.9" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="EVENTHANDLER.9" .\" Copyright (c) 2002 .\" The Regents of the University of California. All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" This product includes software developed by the University of .\" California, Berkeley and its contributors. .\" 4. Neither the name of the University nor the names of its contributors .\" may be used to endorse or promote products derived from this software .\" without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" $FreeBSD$ .\" .Dd March 1, 2002 .Os .Dt EVENTHANDLER 9 .Sh NAME .Nm EVENTHANDLER_DECLARE , .Nm EVENTHANDLER_INVOKE , .Nm EVENTHANDLER_REGISTER , .Nm EVENTHANDLER_DEREGISTER , .Nm EVENTHANDLER_FAST_DECLARE , .Nm EVENTHANDLER_FAST_DEFINE , .Nm EVENTHANDLER_FAST_REGISTER , .Nm EVENTHANDLER_FAST_DEREGISTER , .Nm EVENTHANDLER_FAST_INVOKE .Nd manage event callout queues .Sh SYNOPSIS .In sys/eventhandler.h .Fn EVENTHANDLER_DECLARE "name" "type" .Fn EVENTHANDLER_REGISTER "name" "func" "arg" "priority" .Fn EVENTHANDLER_DEREGISTER "name" "tag" .Fn EVENTHANDLER_INVOKE "name" "args..." .Fn EVENTHANDLER_FAST_DECLARE "name" "type" .Fn EVENTHANDLER_FAST_DEFINE "name" "type" .Fn EVENTHANDLER_FAST_REGISTER "name" "func" "arg" "priority" .Fn EVENTHANDLER_FAST_DEREGISTER "name" "tag" .Fn EVENTHANDLER_FAST_INVOKE "name" "args..." .Sh DESCRIPTION These macros setup and execute callout queues for miscellaneous events in the kernel. They all accept the .Fa name argument, which serves as a unique identifier of the queue. .Pp The .Fn EVENTHANDLER_DECLARE macro declares a queue with given name and given type of the callout function. The queues are allocated dynamically upon the first insertion with the .Fn EVENTHANDLER_REGISTER macro. .Pp The .Fn EVENTHANDLER_REGISTER macro inserts a new item in the specified list. If the list does not exist, it is created. This macro evaluates to eventhandler_tag value, which can be later used to remove the handler from the queue with the .Fn EVENTHANDLER_DEREGISTER macro. .Dv NULL value is returned upon failure. The .Fa arg parameter will always be passed as a first argument to callout function. The .Fa priority argument defines the order of handler invocations. .Pp The .Fn EVENTHANDLER_DEREGISTER macro removes a handler from the queue, using the value returned by the .Fn EVENTHANDLER_REGISTER macro. If .Dv NULL is passed as a second argument, all handlers will be removed from the specified queue. .Pp The .Fn EVENTHANDLER_INVOKE macro calls each handler in the queue. The first argument to the callout function is the argument specified with the .Fn EVENTHANDLER_REGISTER macro, subsequent arguments are passed through .Fn EVENTHANDLER_INVOKE invocation. The handlers will be executed in order of increasing priority. .Pp The .Fn EVENTHANDLER_FAST_XXX macros are similar to their equivalents, but the queues are allocated statically. Thus the queue must be defined somewhere with the .Fn EVENTHANDLER_FAST_DEFINE macro. This macro takes the same arguments as the .Fn EVENTHANDLER_FAST_DECLARE macro. .Pp Generally, .Fn EVENTHANDLER_XXX macros are preferred over .Fn EVENTHANDLER_FAST_XXX ones. .Sh EXAMPLES .Bd -literal typedef void (*myhandler_fun)(void *, int); eventhandler_tag et; void myfunc(void *a, int b) {} EVENTHANDLER_DECLARE(myqueue, myhandler_fun); et = EVENTHANDLER_REGISTER(myqueue, myfunction, NULL, 0); EVENTHANDLER_INVOKE(myqueue, 14); EVENTHANDLER_DEREGISTER(myqueue, et); .Ed .Sh AUTHORS .An -nosplit This manual page was written by .An Alexey Neyman Aq alex.neyman@auriga.ru . --------------Boundary-00=_KU0GGJHC0Z4D9XOU7K33-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 2:42:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by hub.freebsd.org (Postfix) with ESMTP id 0CDB737B404 for ; Mon, 4 Mar 2002 02:42:02 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailf.telia.com (8.11.6/8.11.6) with ESMTP id g24Ag0114390 for ; Mon, 4 Mar 2002 11:42:00 +0100 (CET) Received: from falcon.midgard.homeip.net (h217n1fls20o913.telia.com [212.181.162.217]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id LAA00599 for ; Mon, 4 Mar 2002 11:42:00 +0100 (CET) Received: (qmail 63438 invoked by uid 1001); 4 Mar 2002 10:41:58 -0000 Date: Mon, 4 Mar 2002 11:41:58 +0100 From: Erik Trulsson To: Harti Brandt Cc: Ian , freebsd-hackers Subject: Re: A few questions about a few includes Message-ID: <20020304104158.GB63341@student.uu.se> Mail-Followup-To: Harti Brandt , Ian , freebsd-hackers References: <20020303180029.GA56041@student.uu.se> <20020304102750.O74223-100000@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020304102750.O74223-100000@beagle.fokus.gmd.de> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 04, 2002 at 10:29:18AM +0100, Harti Brandt wrote: > On Sun, 3 Mar 2002, Erik Trulsson wrote: > > ET>On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote: > ET>> > > ET>> > In : > ET>> > > ET>> > /* > ET>> > * pargs, used to hold a copy of the command line, if it had a sane > ET>> > * length > ET>> > */ > ET>> > struct pargs { > ET>> > u_int ar_ref; /* Reference count */ > ET>> > u_int ar_length; /* Length */ > ET>> > u_char ar_args[0]; /* Arguments */ > ET>> > }; > ET>> > > ET>> > This does indeed seem to make little or no sense. Could someone explain > ET>> > this? Is ar_args supposed to be a pointer or what? > ET>> > ET>> This is a common technique for defining a structure which is some > ET>> descriptive information about an array of objects is followed by an > ET>> open-ended array of those objects. (In this case the "objects" are > ET>> characters.) The ar_args member of the structure gives a name to that > ET>> location in the structure without reserving any space (and thus when the > ET>> technique is used, there can only ever be one [0] member and it must be at > ET>> the end of the structure). You access the open-ended array of objects just > ET>> as you would any other array embedded within a structure, E.G. > ET>> instance->ar_args[n]. > ET>> > ET>> Not all compilers support defining zero-length arrays like this. And that's > ET>> a pity; it's an incredibly useful technique, and the alternatives to it are > ET>> not nearly as elegant and generally involve ugly recasting of pointers. > ET> > ET>For those compilers that don't support zero-length arrays one can still > ET>use the same trick but with a one-element array at the end of the > ET>struct. One just has to remember to that element into account when > ET>allocating memory for the structure. Slightly uglier, but not much. > ET> > ET>It might be worth mentioning that this trick is not actually allowed > ET>according to the C standard and in principle invokes undefined > ET>behaviour. OTOH, AFAIK the trick does work on all existing compilers, > ET>so while it is not standard-conforming it is quite portable. > > My ISO-C draft copy allows in section 6.7.2.1 paragraph 2 the last member > of a structure to be an incomplete array type and paragraph 16 shows an > example. Was this removed from the final standard? I think it is still there (and my draft copy says the same thing). I was thinking about the original C89 standard which does not allow it (and does not allow incomplete array types in structs). Guess I should have said which standard I was referring to. > > harti > -- > harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private > brandt@fokus.fhg.de > -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 5:11:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B3A737B417; Mon, 4 Mar 2002 05:11:35 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Mon, 4 Mar 2002 08:11:34 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 9A2CDBA03; Mon, 4 Mar 2002 08:06:08 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Aleksander Rozman - Andy , freebsd-hackers@FreeBSD.ORG Subject: Re: How to write code in FreeBSD Date: Mon, 4 Mar 2002 08:06:08 -0500 X-Mailer: KMail [version 1.3] Cc: freebsd-questions@FreeBSD.ORG References: <5.0.2.1.0.20020302125303.02c1ca90@164.8.8.5> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020304130608.9A2CDBA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday 02 March 2002 09:41 am, Brian T. Schellenberger wrote: > On Saturday 02 March 2002 06:57 am, Aleksander Rozman - Andy wrote: > > Hi ! > > > > I was wondering if there are any guidelines how to write code in FreeBSD. > > I have taken a look at several code of FreeBSD but each is written > > differently? Problem is I don't know which is preferred way. > > > > Reason I am asking this is that I am trying to add some code to kernel. > > Compile is OK, no error, no warning, but on link all variables defined > > with extern are marked as : undefined reference to 'variable', variable > > is extern and .h file which has it defined is included... Where can be > > the problem?? Another problem is that I get multiple definition > > error...how can I get over this. I got Andy to send his original code, and I believe that I've diagnosed the root of the problem: The code was assuming that KERNEL was defined when building the kernel (I gather that KERNEL is defined when building a Linux kernel), but under FreeBSD, it seems, KERNEL is *not* defined, but _KERNEL is defined instead. (Though I'm not sure whether it's defined under the same circumstances.) Even so I'm not sure that his code is perfectly correct ANSI C, technically speaking, since it then appears that it would wind up with multiple copies of the variables defined, but I'm pretty darn sure that gcc & ld tolerate this just fine--the proximate cause of the difficulty lay in expecting KERNEL to be defined and having an #ifdef KERNEL check in the 'h' file that caused the definitions to never to be read. -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 8:36:49 2002 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 5B93537B4A4 for ; Mon, 4 Mar 2002 08:36:36 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g24GaZi70986; Mon, 4 Mar 2002 09:36:35 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g24GaXL69008; Mon, 4 Mar 2002 09:36:33 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 04 Mar 2002 09:35:29 -0700 (MST) Message-Id: <20020304.093529.35706437.imp@village.org> To: ertr1013@student.uu.se Cc: brandt@fokus.gmd.de, freebsd@damnhippie.dyndns.org, freebsd-hackers@FreeBSD.ORG Subject: Re: A few questions about a few includes From: "M. Warner Losh" In-Reply-To: <20020304104158.GB63341@student.uu.se> References: <20020303180029.GA56041@student.uu.se> <20020304102750.O74223-100000@beagle.fokus.gmd.de> <20020304104158.GB63341@student.uu.se> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020304104158.GB63341@student.uu.se> Erik Trulsson writes: : I think it is still there (and my draft copy says the same thing). : I was thinking about the original C89 standard which does not allow it : (and does not allow incomplete array types in structs). Guess I should : have said which standard I was referring to. struct foo { char array[0]; }; appears to be in C-99 but not C-89. If you have the draft, so far the only thing I've noticed that is different between the draft and the final standard is that there's 10-15 more footnotes in the final standard than were in the final draft. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 8:44: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 71AE037B416 for ; Mon, 4 Mar 2002 08:43:54 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g24GhlR17567; Mon, 4 Mar 2002 17:43:47 +0100 (MET) Date: Mon, 4 Mar 2002 17:43:47 +0100 (CET) From: Harti Brandt To: "M. Warner Losh" Cc: ertr1013@student.uu.se, , Subject: Re: A few questions about a few includes In-Reply-To: <20020304.093529.35706437.imp@village.org> Message-ID: <20020304174200.X74223-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, M. Warner Losh wrote: MWL>In message: <20020304104158.GB63341@student.uu.se> MWL> Erik Trulsson writes: MWL>: I think it is still there (and my draft copy says the same thing). MWL>: I was thinking about the original C89 standard which does not allow it MWL>: (and does not allow incomplete array types in structs). Guess I should MWL>: have said which standard I was referring to. MWL> MWL>struct foo { MWL> char array[0]; MWL>}; MWL> MWL>appears to be in C-99 but not C-89. If you have the draft, so far MWL>the only thing I've noticed that is different between the draft MWL>and the final standard is that there's 10-15 more footnotes in the MWL>final standard than were in the final draft. MWL> MWL>Warner This should be struct foo { char array[]; }; according to C-99, on which gcc2 barfs. Don't know, whether gcc3 can handle this. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 9:11:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail2.tdb.uu.se (mail2.tdb.uu.se [130.238.18.35]) by hub.freebsd.org (Postfix) with ESMTP id CBAE737B405 for ; Mon, 4 Mar 2002 09:11:32 -0800 (PST) Received: from rackarberget.it.uu.se (rackarberget.it.uu.se [130.238.18.38]) by mail2.tdb.uu.se (8.12.1/8.12.1/STUD_1.2) with ESMTP id g24HBITN013737; Mon, 4 Mar 2002 18:11:18 +0100 (MET) Received: (from ertr1013@localhost) by rackarberget.it.uu.se (8.11.6/8.11.6/STUD_NULL_1.2) id g24HBHR02811; Mon, 4 Mar 2002 18:11:17 +0100 (MET) Date: Mon, 4 Mar 2002 18:11:17 +0100 From: Erik Trulsson To: "M. Warner Losh" Cc: brandt@fokus.gmd.de, freebsd@damnhippie.dyndns.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Re: A few questions about a few includes Message-ID: <20020304181117.A594@student.uu.se> References: <20020303180029.GA56041@student.uu.se> <20020304102750.O74223-100000@beagle.fokus.gmd.de> <20020304104158.GB63341@student.uu.se> <20020304.093529.35706437.imp@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: <20020304.093529.35706437.imp@village.org>; from imp@village.org on Mon, Mar 04, 2002 at 09:35:29AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 04, 2002 at 09:35:29AM -0700, M. Warner Losh wrote: > In message: <20020304104158.GB63341@student.uu.se> > Erik Trulsson writes: > : I think it is still there (and my draft copy says the same thing). > : I was thinking about the original C89 standard which does not allow it > : (and does not allow incomplete array types in structs). Guess I should > : have said which standard I was referring to. > > struct foo { > char array[0]; > }; > > appears to be in C-99 but not C-89. If you have the draft, so far the > only thing I've noticed that is different between the draft and the > final standard is that there's 10-15 more footnotes in the final > standard than were in the final draft. > > Warner Are you sure that is in C99? What is allowed in C99 (but wasn't in C89) is struct foo { int b; char array[]; }; Note that you must have a 'normal' field before the incomplete array. I don't think char array[0]; is allowed in either of C89 or C99. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 9:21:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by hub.freebsd.org (Postfix) with ESMTP id 2B29A37B41A for ; Mon, 4 Mar 2002 09:21:48 -0800 (PST) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.11.6/8.11.6) with ESMTP id g24HLlo30303 for ; Mon, 4 Mar 2002 12:21:47 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38886) id <0GSG00D01LJ5NA@lmco.com> for freebsd-hackers@freebsd.org; Mon, 4 Mar 2002 09:21:05 -0800 (PST) Received: from BSDWIN2KKOROUSH ([129.197.23.48]) by lmco.com (PMDF V5.2-33 #38886) with SMTP id <0GSG00B0JLJ1JJ@lmco.com> for freebsd-hackers@freebsd.org; Mon, 04 Mar 2002 09:21:01 -0800 (PST) Date: Mon, 04 Mar 2002 09:20:49 -0800 From: Koroush Saraf Subject: Routing question, Routed using one interface (more info) To: freebsd-hackers@freebsd.org Message-id: <009501c1c3a0$ee1d3600$3017c581@BSDWIN2KKOROUSH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I'm making a new post to attach the network diagram in order to clarify my > question. (fixed point font please) > > I have several bsd4.3 computers each with one NIC on a shared LAN as below: > > +-------------+ > |10.1.1.1/24 | > | +--+ > | | | > +-------------+ | > | > +-------------+ | > |10.1.1.2/24 | | > |10.2.2.2/24 +--+ > | | | > +-------------+ | > | > +-------------+ | > |10.2.2.3/24 | | > |10.3.3.3/24 +--+ > | | | > +-------------+ | > | > +-------------+ | > |10.3.3.4/24 | | > | +--+ > | | > +-------------+ > > Now I like to turn on Routed, and have the approperiate routes discovered. > Then from the 10.1.1.1 computer I like to be able to run traceroute to the > 10.3.3.4 computer and see the following: > 10.1.1.1 <-> 10.1.1.2 <->10.2.2.3<->10.3.3.4 > currently I've tried this, but the routing is not being discovered and the > routing table remains unchanged. There are no default routes either. > Can you tell me if this is possible? and if so what I need to do to get it > to work? > > > > > Hi All, > > I like to know why when I turn on ROUTED on my machines they don't > discover > > the attached subnets to the link. The scenario is below: > > > > I' have several bsd computers each with one network card. All the > computers > > sit on a shared Ethernet. I like to perform some routing simulations > > comparing ospf and rip. So I have setup the computers so that each NIC > has > > several IP address aliases assigned. When I turn on ROUTED I see a few > > hello packets exchanged and very so often I see an IGMP multicast for the > > router discovery protocol. However, the routing tables remain as they > were > > before I turnon ROUTED. So basically the aliased NIC IP addresses are not > > being advertised. Can you tell me how I can make routing work through > these > > aliased addresses? > > Also I have addressed my computers in the 10.x.x.x range which is the > > private IP address range and not internet routable. Does ROUTED care > about > > the range of addresses in use or all IP addresses are using in the routing > > table as valid routable addresses. Just wanted to make sure this wasn't > my > > problem. > > Thanks in advance for taking the time to suggest solution, > > ~Koroush Saraf > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" 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 Mar 4 9:50:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from adsl-208-201-233-144.sonic.net (adsl-208-201-233-144.sonic.net [208.201.233.144]) by hub.freebsd.org (Postfix) with ESMTP id DF84E37B405 for ; Mon, 4 Mar 2002 09:50:46 -0800 (PST) Received: from localhost (merlin@localhost) by now (8.11.2/8.11.2) with ESMTP id g24HokO21712 for ; Mon, 4 Mar 2002 09:50:46 -0800 Date: Mon, 4 Mar 2002 09:50:46 -0800 (PST) From: James To: hackers@FreeBSD.ORG Subject: Re: periodic firewire max-out question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: John Kozubik > > I still do not yet own 63 firewire devices, and so, once again, I am > wondering if anyone here has ever actually connected 128 devices to a Huh? How did you get from 63 devices to 128? I don't know of any multi-bus 1394 adapters on the consumer market. Adapters have multiple ports but all are on the same bus. I'd be curious to find one that actually has more than one bus. -James To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 10: 4:18 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from damnhippie.dyndns.org (12-253-177-2.client.attbi.com [12.253.177.2]) by hub.freebsd.org (Postfix) with ESMTP id 2DDAF37B417 for ; Mon, 4 Mar 2002 10:04:11 -0800 (PST) Received: from [172.22.42.2] (peace.hippie.lan [172.22.42.2]) by damnhippie.dyndns.org (8.11.6/8.11.6) with ESMTP id g24I4A870828 for ; Mon, 4 Mar 2002 11:04:10 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Mon, 04 Mar 2002 11:04:11 -0700 Subject: Re: A few questions about a few includes From: Ian To: freebsd-hackers Message-ID: In-Reply-To: <20020304103250.GA63341@student.uu.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>> Zero length arrays >>> are undefined. >> >> Well, yes, but the quesiton is *why* they are undefined. >> They are undefined only because ANSI says that they are. >> But why did they say so? > > They didn't really. They just didn't say that zero-length arrays are > allowed. (This might be changed in C99, I am not sure.) > > The reason this was not allowed was probably because it was too > difficult to phrase the standard in such a manner that reasonable uses > were allowed, while still not requiring the compiler to handle the > unreasonable cases. Actually in the original standard, zero-length arrays aren't undefined, they're specifically prohibited. Two sections of the standard can be intrepreted as forbidding them... 6.1.2.5 describes an array as "...a continguously allocated non-empty set of objects...". 6.5.4.2 says "The expression delimited by [ and ] (which specifies the size of an array) shall be an integral constant expression that has a value greater than zero." I used to moderate the c_language conference on BIX back in the days when the original ANSI standard was being codified. We used to have endless arguments and discussions about things such as this and the rationale for them, but I don't remember any discussion of this particular issue. (But it was so long ago now it almost seems like another lifetime. I haven't thought about BIX in ages.) -- Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 12:32:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from be-well.ilk.org (lowellg.ne.mediaone.net [24.147.188.158]) by hub.freebsd.org (Postfix) with ESMTP id 1991A37B402 for ; Mon, 4 Mar 2002 12:32:50 -0800 (PST) Received: (from lowell@localhost) by be-well.ilk.org (8.11.6/8.11.4) id g24KWmb02577; Mon, 4 Mar 2002 15:32:48 -0500 (EST) (envelope-from lowell@world.std.com) X-Authentication-Warning: be-well.ilk.org: lowell set sender to lowell@world.std.com using -f To: freebsd-hackers@freebsd.org Subject: Re: A few questions about a few includes References: <20020303180029.GA56041@student.uu.se> <20020304102750.O74223-100000@beagle.fokus.gmd.de> <20020304104158.GB63341@student.uu.se> <20020304.093529.35706437.imp@village.org> <20020304181117.A594@student.uu.se> From: Lowell Gilbert Date: 04 Mar 2002 15:32:48 -0500 In-Reply-To: <20020304181117.A594@student.uu.se> Message-ID: <44lmd82hvz.fsf@lowellg.ne.mediaone.net> Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Erik Trulsson writes: > On Mon, Mar 04, 2002 at 09:35:29AM -0700, M. Warner Losh wrote: > > In message: <20020304104158.GB63341@student.uu.se> > > Erik Trulsson writes: > > : I think it is still there (and my draft copy says the same thing). > > : I was thinking about the original C89 standard which does not allow it > > : (and does not allow incomplete array types in structs). Guess I should > > : have said which standard I was referring to. > > > > struct foo { > > char array[0]; > > }; > > > > appears to be in C-99 but not C-89. If you have the draft, so far the > > only thing I've noticed that is different between the draft and the > > final standard is that there's 10-15 more footnotes in the final > > standard than were in the final draft. > > > > Warner > > Are you sure that is in C99? > What is allowed in C99 (but wasn't in C89) is > > struct foo > { > int b; > char array[]; > }; > > Note that you must have a 'normal' field before the incomplete array. > > I don't think > char array[0]; > is allowed in either of C89 or C99. Correct on all counts. I'll cite the letter of the law from C99 if anybody really cares. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 12:36: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from be-well.ilk.org (lowellg.ne.mediaone.net [24.147.188.158]) by hub.freebsd.org (Postfix) with ESMTP id 3C11837B400 for ; Mon, 4 Mar 2002 12:35:59 -0800 (PST) Received: (from lowell@localhost) by be-well.ilk.org (8.11.6/8.11.4) id g24KZwq02583; Mon, 4 Mar 2002 15:35:58 -0500 (EST) (envelope-from lowell@world.std.com) X-Authentication-Warning: be-well.ilk.org: lowell set sender to lowell@world.std.com using -f To: freebsd-hackers@freebsd.org Subject: Re: A few questions about a few includes References: <20020304174200.X74223-100000@beagle.fokus.gmd.de> From: Lowell Gilbert Date: 04 Mar 2002 15:35:58 -0500 In-Reply-To: <20020304174200.X74223-100000@beagle.fokus.gmd.de> Message-ID: <44henw2hqp.fsf@lowellg.ne.mediaone.net> Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Harti Brandt writes: > This should be > > struct foo { > char array[]; > }; > > according to C-99, on which gcc2 barfs. Don't know, whether gcc3 can > handle this. C-99 requires a fully specified type before the unspecified array (and requires said array to be the last element in the structure). So this example is *not* valid in C99, but the following would be: struct foo { int bar; char array[]; }; [Which makes sense; it forces a structure to have a non-zero size.] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 13:12:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.spc.org (insomnia.spc.org [195.224.94.183]) by hub.freebsd.org (Postfix) with SMTP id EF57637B416 for ; Mon, 4 Mar 2002 13:12:48 -0800 (PST) Received: (qmail 31922 invoked by uid 1031); 4 Mar 2002 21:01:47 -0000 Date: Mon, 4 Mar 2002 21:01:46 +0000 From: Bruce M Simpson To: freebsd-hackers@freebsd.org Subject: Intel 820 RNG Message-ID: <20020304210146.B4574@spc.org> Mail-Followup-To: Bruce M Simpson , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG All, Apologies if this has been discussed before. The new Intel i820 motherboard chipset is due to ship with an on-board Random Number Generator (RNG)... are there any plans for us to support this, or does support already exist? thanks BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 13:54: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from energyhq.homeip.net (213-97-200-73.uc.nombres.ttd.es [213.97.200.73]) by hub.freebsd.org (Postfix) with ESMTP id B48A237B416 for ; Mon, 4 Mar 2002 13:53:55 -0800 (PST) Received: by energyhq.homeip.net (Postfix, from userid 1001) id 8A5613FC32; Mon, 4 Mar 2002 22:53:57 +0100 (CET) Date: Mon, 4 Mar 2002 22:53:57 +0100 From: Miguel Mendez To: freebsd-hackers@freebsd.org Subject: fish [continued] Message-ID: <20020304225357.A86369@energyhq.homeip.net> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi again, hackers, First of all, thanks a lot to those who gave me feedback about this little project. I've gathered ideas from several people and will implement them in the future. I specially liked Michael Lucas' idea about a drop down menu of possible values. Currently the parser is finished for the FreeBSD version, the NetBSD one still needs some minor fixes, and I hope to finish the callbacks of GTK frontend by tomorrow or wednesday, depending on how much spare time I can get. Haven't still started with the ncurses UI, that will be the next step. And once I have a first working prototype, my next idea is to move to the concept of groups: network interfaces, firewall, peripheals, you get the idea. I've setup a page were people interested can download the latest version and have a look at a pair of screenshots if they feel curious as what does it look like: http://energyhq.homeip.net/brain.html Still waiting for someone to come up with a cool name tho :) Cheers, --=20 Miguel Mendez - flynn@energyhq.homeip.net GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8g+z0nLctrNyFFPERAp2tAKDAJ9Eutgwozt6/hWaD0gqgmRzwHACeMR/5 f+PZkxek+TBbtTKh8cELZEg= =n1gl -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 14: 2:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id 642C637B405 for ; Mon, 4 Mar 2002 14:02:16 -0800 (PST) Received: (qmail 74240 invoked by uid 3130); 4 Mar 2002 22:01:08 -0000 Date: Mon, 4 Mar 2002 17:01:08 -0500 From: Garrett Rooney To: Miguel Mendez Cc: freebsd-hackers@freebsd.org Subject: Re: fish [continued] Message-ID: <20020304220106.GI38232@electricjellyfish.net> References: <20020304225357.A86369@energyhq.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020304225357.A86369@energyhq.homeip.net> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 04, 2002 at 10:53:57PM +0100, Miguel Mendez wrote: > I've setup a page were people interested can download the latest version > and have a look at a pair of screenshots if they feel curious as what > does it look like: http://energyhq.homeip.net/brain.html one comment from the quick look at the screenshots. why bother having the "'s around the strings? it would make more sense to me to just tack quotes on at the end when you're writing out the rc.conf file. other than that it looks cool though ;-) keep up the good work. > Still waiting for someone to come up with a cool name tho :) wish i could help... i'm terrible at naming programs... -garrett -- garrett rooney Unix was not designed to stop you from rooneg@electricjellyfish.net doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 14:32: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ubergeeks.com (lorax.ubergeeks.com [209.145.65.55]) by hub.freebsd.org (Postfix) with ESMTP id 1CA7737B402 for ; Mon, 4 Mar 2002 14:32:02 -0800 (PST) Received: from localhost (adrian@localhost) by mail.ubergeeks.com (8.11.6/8.11.6) with ESMTP id g24MVxd53134; Mon, 4 Mar 2002 17:31:59 -0500 (EST) (envelope-from adrian@ubergeeks.com) Date: Mon, 4 Mar 2002 17:31:59 -0500 (EST) From: Adrian Filipi-Martin Reply-To: Adrian Filipi-Martin To: Bruce M Simpson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Intel 820 RNG In-Reply-To: <20020304210146.B4574@spc.org> Message-ID: <20020304171519.G52330-100000@lorax.ubergeeks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Bruce M Simpson wrote: > All, > > Apologies if this has been discussed before. The new Intel i820 motherboard > chipset is due to ship with an on-board Random Number Generator (RNG)... are > there any plans for us to support this, or does support already exist? > > thanks > BMS I haven't had time to keep up with this, so please bear with me. Is the i820 actually a new chipset that includes the RNG? We've been having trouble getting boards that have the RNG capabilities, and I have been told by the person doing the research that Intel seemed to be dropping this feature from the newer chipsets. If not, then I'm most pleased to be corrected and would like some references that I can throw at someone until they find us the proper motherboards again for our product. But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. We want to clean them up a little and submit them as a PR, but have not had time to. If you're interested I can send you the patches and you can give them a try. Adrian -- [ adrian@ubergeeks.com ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 14:40:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 83B3237B402 for ; Mon, 4 Mar 2002 14:40:22 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g24MeAV49462; Mon, 4 Mar 2002 22:40:10 GMT (envelope-from mark@grimreaper.grondar.za) Received: from grimreaper (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.2/8.12.2) with ESMTP id g24MbwRV068230; Mon, 4 Mar 2002 22:37:58 GMT (envelope-from mark@grimreaper.grondar.za) Message-Id: <200203042237.g24MbwRV068230@grimreaper.grondar.org> To: Adrian Filipi-Martin Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Intel 820 RNG References: <20020304171519.G52330-100000@lorax.ubergeeks.com> In-Reply-To: <20020304171519.G52330-100000@lorax.ubergeeks.com> ; from Adrian Filipi-Martin "Mon, 04 Mar 2002 17:31:59 EST." Date: Mon, 04 Mar 2002 22:37:57 +0000 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > But, back to the topic. We have taken the OpenBSD driver for the > RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to > FreeBSD-4.4. We made some enhancements to get more of the available random > data bandwidth. > > We want to clean them up a little and submit them as a PR, but have > not had time to. If you're interested I can send you the patches and you > can give them a try. Hi. Please send me what you have. Thanks! M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 14:59:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from usenix.org (voyager.usenix.org [131.106.3.1]) by hub.freebsd.org (Postfix) with ESMTP id 4674137B400 for ; Mon, 4 Mar 2002 14:59:08 -0800 (PST) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated (0 bits)) by usenix.org (Switch-2.1.3/Switch-2.1.0) with ESMTP id g24MwvJ24292 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Mon, 4 Mar 2002 14:59:03 -0800 (PST) Message-ID: <22f201c1c3d0$2dd87960$52557f42@errno.com> From: "Sam Leffler (at Usenix)" To: "Adrian Filipi-Martin" , "Bruce M Simpson" Cc: References: <20020304171519.G52330-100000@lorax.ubergeeks.com> Subject: Re: Intel 820 RNG Date: Mon, 4 Mar 2002 14:58:57 -0800 Organization: Usenix Association 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-DCC-Usenix-Metrics: voyager 1010; Body=3 Fuz1=3 Fuz2=3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > But, back to the topic. We have taken the OpenBSD driver for the > RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to > FreeBSD-4.4. We made some enhancements to get more of the available random > data bandwidth. > I ported the openbsd crypto stuff to -stable for the purpose of making the soekris vpn1211 card usable (Hifn 7951). As part of this I tied the RNG on the Hifn to /dev/random; all that was required was to add a call to inject the data as entropy (or so I believed). Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 15:37:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id F099537B416 for ; Mon, 4 Mar 2002 15:37:22 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020304233722.WQWG2626.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Mon, 4 Mar 2002 23:37:22 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g24NbMs96032 for ; Mon, 4 Mar 2002 15:37:22 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 438123BAC; Mon, 4 Mar 2002 15:37:22 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mark Murray Cc: Adrian Filipi-Martin , freebsd-hackers@FreeBSD.ORG Subject: Re: Intel 820 RNG In-Reply-To: <200203042237.g24MbwRV068230@grimreaper.grondar.org> Date: Mon, 04 Mar 2002 15:37:22 -0800 From: Peter Wemm Message-Id: <20020304233722.438123BAC@overcee.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mark Murray wrote: > > But, back to the topic. We have taken the OpenBSD driver for the > > RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to > > FreeBSD-4.4. We made some enhancements to get more of the available random > > data bandwidth. > > > > We want to clean them up a little and submit them as a PR, but have > > not had time to. If you're interested I can send you the patches and you > > can give them a try. > > Hi. > > Please send me what you have. I thought it was an add-on to the firmware hub rather than the 820 chipset proper. The firmware hubs seems to be just about everywhere these days on intel chipset motherboards.. 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 Mar 4 15:52:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 7897C37B400 for ; Mon, 4 Mar 2002 15:52:21 -0800 (PST) Received: from pool0418.cvx40-bradley.dialup.earthlink.net ([216.244.43.163] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16i2FD-0000qU-00; Mon, 04 Mar 2002 15:51:56 -0800 Message-ID: <3C840862.53658404@mindspring.com> Date: Mon, 04 Mar 2002 15:50:58 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Adrian Filipi-Martin , freebsd-hackers@FreeBSD.ORG Subject: Re: Intel 820 RNG References: <20020304171519.G52330-100000@lorax.ubergeeks.com> <200203042237.g24MbwRV068230@grimreaper.grondar.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mark Murray wrote: > > But, back to the topic. We have taken the OpenBSD driver for the > > RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to > > FreeBSD-4.4. We made some enhancements to get more of the available random > > data bandwidth. > > > > We want to clean them up a little and submit them as a PR, but have > > not had time to. If you're interested I can send you the patches and you > > can give them a try. > > Hi. > > Please send me what you have. Agreed. Anything that stops the "harvesting entropy" from sitting in the interrupt processing path for the most important interrupts on the box can only be a good thing. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 16:48: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sigbus.com (c-24-126-148-218.we.client2.attbi.com [24.126.148.218]) by hub.freebsd.org (Postfix) with ESMTP id 7091B37B400; Mon, 4 Mar 2002 16:48:03 -0800 (PST) Received: (from henrich@localhost) by sigbus.com (8.11.1/8.11.1) id g250lv008503; Mon, 4 Mar 2002 16:47:57 -0800 (PST) (envelope-from henrich) Date: Mon, 4 Mar 2002 16:47:57 -0800 From: Charles Henrich To: freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org Subject: Realtime video capture/divx encoding (brooktree) beta testers required Message-ID: <20020304164757.B8269@sigbus.com> Mail-Followup-To: freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F X-GPG-Fingerprint: EA4C AB9B 0C38 17C0 AB3F 11DE 41F6 5883 41E7 4F49 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Im looking for a few beta testers with Brooktree based capture cards to test out my modifications to mencoder and the brooktree device to enable realtime video playback and capture to divx (or any format really). Anyone interested with some technology background please drop me a line! -Crh Charles Henrich henrich@msu.edu http://www.sigbus.com:81/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 17: 2:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail3.uts.ohio-state.edu (mail3.uts.ohio-state.edu [128.146.214.32]) by hub.freebsd.org (Postfix) with ESMTP id 0707937B417; Mon, 4 Mar 2002 17:02:28 -0800 (PST) Received: from there (rbar-66-240.resnet.ohio-state.edu [164.107.66.240]) by mail3.uts.ohio-state.edu (8.9.3/8.9.3) with SMTP id UAA18553; Mon, 4 Mar 2002 20:02:24 -0500 (EST) Message-Id: <200203050102.UAA18553@mail3.uts.ohio-state.edu> Content-Type: text/plain; charset="iso-8859-1" From: Anish Mistry To: Charles Henrich , freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org Subject: Re: Realtime video capture/divx encoding (brooktree) beta testers required Date: Mon, 4 Mar 2002 20:06:22 -0500 X-Mailer: KMail [version 1.3.2] References: <20020304164757.B8269@sigbus.com> In-Reply-To: <20020304164757.B8269@sigbus.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday 04 March 2002 07:47 pm, Charles Henrich wrote: > Im looking for a few beta testers with Brooktree based capture cards to= test > out my modifications to mencoder and the brooktree device to enable rea= ltime > video playback and capture to divx (or any format really). Anyone=20 interested > with some technology background please drop me a line! >=20 > -Crh >=20 > Charles Henrich henrich@msu.ed= u >=20 > http://www.sigbus.com:81/~henrich >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-multimedia" in the body of the message >=20 >=20 I'd be interested, just tell me what I need to do to get your modificatio= ns=20 working. --=20 Anish Mistry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 18:14:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from www.kozubik.com (www.kozubik.com [198.78.70.162]) by hub.freebsd.org (Postfix) with ESMTP id 927E237B405; Mon, 4 Mar 2002 18:14:38 -0800 (PST) Received: from localhost (john@localhost) by www.kozubik.com (8.11.0/8.11.0) with ESMTP id g251tC593459; Mon, 4 Mar 2002 17:55:12 -0800 (PST) (envelope-from john@kozubik.com) Date: Mon, 4 Mar 2002 17:55:12 -0800 (PST) From: John Kozubik X-Sender: john@www To: James Cc: hackers@FreeBSD.ORG, freebsd-firewire@FreeBSD.ORG Subject: Re: periodic firewire max-out question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG typo. 63 is the number I intended in both cases. I am basically just inquiring as to the practical problems one might face when actually maxing out the spec, with 63 devices in one adaptor. You are correct - none of those multi-port adaptors actually have two buses. I am not sure if anyone has plans on a multi-bus adaptor. Since posting this question, I have received quite a bit of anecdotal evidence that suggests that actually having 63 devices on the chain at once is _very_ difficult. Most people report running into problems at around 20-30 devices. Power is also an issue, if the devices are bus-powered as opposed to wall-powered. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com On Mon, 4 Mar 2002, James wrote: > > From: John Kozubik > > > > I still do not yet own 63 firewire devices, and so, once again, I am > > wondering if anyone here has ever actually connected 128 devices to a > > Huh? How did you get from 63 devices to 128? > > I don't know of any multi-bus 1394 adapters on the consumer > market. Adapters have multiple ports but all are on the same bus. I'd be > curious to find one that actually has more than one bus. > > -James > > > > 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 Mar 4 18:55:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ns2.alphaque.com (ns2.alphaque.com [202.185.254.11]) by hub.freebsd.org (Postfix) with SMTP id EB0B137B417 for ; Mon, 4 Mar 2002 18:55:22 -0800 (PST) Received: (qmail 30045 invoked by uid 0); 5 Mar 2002 02:55:17 -0000 Received: from ns2.alphaque.com (HELO prophet.alphaque.com) (202.185.254.11) by ns2.alphaque.com with SMTP; 5 Mar 2002 02:55:17 -0000 Received: from localhost (1b0wdn0zjy8bukzr@localhost [127.0.0.1]) by prophet.alphaque.com (8.11.6/8.11.6) with ESMTP id g252n5m04266; Tue, 5 Mar 2002 10:49:05 +0800 (MYT) (envelope-from dinesh@alphaque.com) Date: Tue, 5 Mar 2002 10:49:04 +0800 (MYT) From: Dinesh Nair To: Garrett Rooney Cc: Miguel Mendez , freebsd-hackers@freebsd.org Subject: Re: fish [continued] In-Reply-To: <20020304220106.GI38232@electricjellyfish.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Garrett Rooney wrote: > one comment from the quick look at the screenshots. why bother having > the "'s around the strings? it would make more sense to me to just perhaps the quotes would show up otherwise hidden spaces ? Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 19: 1:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sleet.ispgateway.de (sleet.ispgateway.de [62.67.200.125]) by hub.freebsd.org (Postfix) with SMTP id 9CD0537B402 for ; Mon, 4 Mar 2002 19:01:31 -0800 (PST) Received: (qmail 10533 invoked from network); 5 Mar 2002 03:01:29 -0000 Received: from unknown (HELO max) (132451@[80.141.115.86]) (envelope-sender ) by sleet.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 5 Mar 2002 03:01:29 -0000 From: =?iso-8859-1?Q?Max_David_Kr=FCper?= To: "Thomas Hurst" Cc: Subject: AW: httpd in malloc(): warning: recursive call (FreeBSD error??) Date: Tue, 5 Mar 2002 04:02:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020302132955.GA9708@voi.aagh.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG we moved the rewrite into the httpd.conf, this was the solution, works very well now! Thanks a lot for that Information guys! Ciao, Max -----Urspr黱gliche Nachricht----- Von: owner-freebsd-hackers@FreeBSD.ORG [mailto:owner-freebsd-hackers@FreeBSD.ORG]Im Auftrag von Thomas Hurst Gesendet: Samstag, 2. M鋜z 2002 14:30 An: freebsd-hackers@freebsd.org Betreff: Re: httpd in malloc(): warning: recursive call (FreeBSD error??) * Max David Kr黳er (m.krueper@linuxwork.de) wrote: > I have a FreeBSD 4.5-STABLE box running, when i start apache first > all works fine, but after like 3 minutes in the logfile i see this > messages: > > httpd in free(): warning: chunk is already free > httpd in free(): warning: recursive call > httpd in malloc(): warning: recursive call > httpd in malloc(): warning: recursive call > [Fri Mar 1 19:49:16 2002] [alert] [client 195.93.64.xx] > /usr/local/httpd/htdocs/qm-dev/.htaccess: RewriteRule: cannot compile > regular expression 'F([0-9]+)(.htm(l)?)?' I've had lots of fun nuking Apache using mod_rewrite. It's can be fragile at times; the solution is usually to rewrite the regex. It's also a good idea to put it in httpd.conf on a production server, since .htaccess support is conciderably slower and more of a hack then anything. Also keep in mind with php embedded in the server, bugs in that and it's extensions (some of which are dodgy at the best of times, like XSLT) can show up as Apache errors. Try disabling it and seeing if it still happens (after mod_rewrite :) -- Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/ - No problem is so formidable that you can't just walk away from it. 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 Mar 4 20: 4: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from w2xo.pgh.pa.us (18.gibs5.xdsl.nauticom.net [209.195.184.19]) by hub.freebsd.org (Postfix) with ESMTP id D190237B416 for ; Mon, 4 Mar 2002 20:03:55 -0800 (PST) Received: from there (dhcp14.int [192.168.5.14]) by w2xo.pgh.pa.us (8.11.6/8.11.3) with SMTP id g2543sk18761 for ; Tue, 5 Mar 2002 04:03:55 GMT (envelope-from durham@jcdurham.com) Message-Id: <200203050403.g2543sk18761@w2xo.pgh.pa.us> Content-Type: text/plain; charset="iso-8859-1" From: Jim Durham Reply-To: durham@jcdurham.com To: freebsd-hackers@freebsd.org Subject: 3.3 to 4.5 remote upgrade possible? Date: Mon, 4 Mar 2002 23:03:47 -0500 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am trying to remotely upgrade a 3.3-RELEASE box to 4.5-RELEASE. I upgraded the source tree with cvsup. I followed the instructions and the notes in UPGRADING, but I can't get the make buildword to complete without unresolved references. I then de-cvsup'd (to coin a phrase) to 3.5-RELEASE sources and did a buildworld and installworld, which went fine. I left the 3.3 kernel running, figuring the libs would turn the trick, but maybe this is not a "good thing" ? Trying to build 4.5 sources with the 3.5 libs installed showed no improvement. So, I decided to transfer the /usr/obj tree from a 4.5 box to the remote. machine. I then built a kernel and transferred the build directory to the remote box. Just being a cautious sort, I tried running a binary from the obj tree. It failed with a BRANDELF warning. Is this because I did not run 'mergemaster' after installing the 3.5 world? Is this "Mission Impossible"? I have no one at the site that can do this. If I say "make installworld" is the whole thing going to come to a grinding halt? -Jim Durham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 20:53:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from speedracer.speedtoys.com (mail.speedtoys.com [66.80.10.170]) by hub.freebsd.org (Postfix) with ESMTP id 12A6837B405 for ; Mon, 4 Mar 2002 20:53:19 -0800 (PST) Received: from localhost (gemohler@localhost) by speedracer.speedtoys.com (8.11.6/8.11.1) with ESMTP id g254tY300800 for ; Mon, 4 Mar 2002 20:55:41 -0800 (PST) Date: Mon, 4 Mar 2002 20:55:34 -0800 (PST) From: Geoff Mohler X-Sender: gemohler@speedracer.speedtoys.com To: freebsd-hackers@FreeBSD.ORG Subject: 4.5-RELEASE upgrade..didnt?? In-Reply-To: <200203050403.g2543sk18761@w2xo.pgh.pa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok..dumb question alert. (fair warning) I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded as well. Went in, and did a make on my config file from 4.3..and rebooted (made sure the new kernel was in / as well). Uname reports a 4.3 system..etc..etc..etc. What'd I miss? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 22:49: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp1.wanadoo.nl (smtp1.wanadoo.nl [194.134.35.136]) by hub.freebsd.org (Postfix) with ESMTP id 4268C37B405; Mon, 4 Mar 2002 22:49:04 -0800 (PST) Received: from ams-gw.sohara.org (i1288.vwr.wanadoo.nl [194.134.213.14]) by smtp1.wanadoo.nl (8.11.3/8.11.3) with SMTP id g256mm019733; Tue, 5 Mar 2002 07:48:48 +0100 (MET) Date: Tue, 5 Mar 2002 07:48:43 +0100 From: "Steve O'Hara-Smith" To: Charles Henrich Cc: freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org Subject: Re: Realtime video capture/divx encoding (brooktree) beta testers required Message-Id: <20020305074843.4e94b069.steve@sohara.org> In-Reply-To: <20020304164757.B8269@sigbus.com> References: <20020304164757.B8269@sigbus.com> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i386-portbld-freebsd4.5) X-Face: %]+HVL}K`P8>+8ZcY-WGHP6j@&mxMo9JH6_WdgIgUGH)JX/usO0%jy7T~IVgqjumD^OBqX,Kv^-GM6mlw(fI^$"QRKyZ$?xx/ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002 16:47:57 -0800 Charles Henrich wrote: CH> Im looking for a few beta testers with Brooktree based capture cards to test CH> out my modifications to mencoder and the brooktree device to enable realtime CH> video playback and capture to divx (or any format really). Anyone interested CH> with some technology background please drop me a line! Send it on - I'm still having no luck getting my ffmpeg grab from brooktree to sync properly (otherwise it works fine, AFAICT the bad sync is inherent in ffmpeg) - does your code sync properly ? PS: I am more interested in mpeg1 than DivX because with mpeg1 the stream can be watched as it is being made. -- C:>WIN | Directable Mirrors The computer obeys and wins. |A Better Way To Focus The Sun You lose and Bill collects. | licenses available - see: | http://www.sohara.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 4 23:46:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id C93EA37B400; Mon, 4 Mar 2002 23:46:10 -0800 (PST) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g257iiH03924; Mon, 4 Mar 2002 23:44:44 -0800 (PST) (envelope-from root@utility.clubscholarship.com) Date: Mon, 4 Mar 2002 23:44:44 -0800 (PST) From: Patrick Thomas To: Cc: Subject: cannot get more than 32 PTYs in 4.4-RELEASE Message-ID: <20020304233607.E3757-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In my kernel, I have: maxusers 128 pseudo-device pty 128 In my /dev directory, I have used `sh MAKEDEV` to make all 256 /dev/pty files. They are all there, and all have correct major/minor numbers. I know I won't be using all 256 of them, but I just made them all anyway. In /etc/ptys, I didn't change anything, because all 256 pty entries are ALREADY in there: # Pseudo Terminals ttyp0 none network ttyp1 none network ... ttySu none network ttySv none network So those are all there. I have used `sysctl -a | grep maxuser` to verify that maxusers is indeed 128. BUT - if I log on via ssh and start screen, and start 31 new screen windows, then nobody else can log on to the system - I cannot create any more screen windows AND nobody else can ssh in - the machine has run out of ptys. I use `fstat` to inquire, and I am maxed out at exactly 32 ptys. SO THE question is, why am I stuck at 32 ptys ? I have done it all - everything that is in any doc or news post, and everything I was told to do here and on -hackers, and yet I am still stuck at 32 !!! Please tell me the secret lore for getting more than 32 ptys in 4.4-RELEASE. thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 1:14:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from draco.over-yonder.net (draco.over-yonder.net [198.78.58.61]) by hub.freebsd.org (Postfix) with ESMTP id 5391837B400 for ; Tue, 5 Mar 2002 01:14:49 -0800 (PST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 10853FC4; Tue, 5 Mar 2002 03:14:49 -0600 (CST) Date: Tue, 5 Mar 2002 03:14:49 -0600 From: "Matthew D. Fuller" To: Jim Durham Cc: freebsd-hackers@freebsd.org Subject: Re: 3.3 to 4.5 remote upgrade possible? Message-ID: <20020305031449.G3880@over-yonder.net> References: <200203050403.g2543sk18761@w2xo.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5-fullermd.1i In-Reply-To: <200203050403.g2543sk18761@w2xo.pgh.pa.us>; from durham@jcdurham.com on Mon, Mar 04, 2002 at 11:03:47PM -0500 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 04, 2002 at 11:03:47PM -0500 I heard the voice of Jim Durham, and lo! it spake thus: > > Is this "Mission Impossible"? I have no one at the site that can do this. > > If I say "make installworld" is the whole thing going to come to a > grinding halt? When I did a 2.2.8-STABLE to 4.3-STABLE upgrade, I ended having to do it in one broken-up step. First (and the only sane way, IMO) is to do the buildworld on a 4.x system; get all those lib conflicts and crap out of the picture. Then I installed the 4.x kernel, did the necessary frobbing (installing loader, re-disklabel -B'ing, sd->da renames in /var with mknod, etc), booted up the 4.x kernel, THEN did the installworld, mergemaster, reboot. Some issues I found: - Some apps (portmap in particular) caused no end of trouble when the 2.2 app ran under the 4 kernel. Like, kernel-panic type trouble. - Device renamings are a bitch. In theory, a 3->4 upgrade should be easier than this, since you don't I think need to do any device renaming, which solves a bunch of my problems right off. I'd still be pretty leery about doing it remotely, though. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 1:56: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from f1node03.rhrz.uni-bonn.de (node03-gb.rhrz.uni-bonn.de [131.220.15.202]) by hub.freebsd.org (Postfix) with ESMTP id 49C1237B405; Tue, 5 Mar 2002 01:55:59 -0800 (PST) Received: from [131.220.244.110] (ascend-tk-p110.dialin.uni-bonn.de [131.220.244.110]) by f1node03.rhrz.uni-bonn.de (8.9.3/8.9.3) with ESMTP id KAA80650; Tue, 5 Mar 2002 10:55:44 +0100 Date: Tue, 5 Mar 2002 10:55:44 +0100 X-Sender: uzs106@mailin.uni-bonn.de Message-Id: In-Reply-To: <20020305074843.4e94b069.steve@sohara.org> References: <20020304164757.B8269@sigbus.com> <20020304164757.B8269@sigbus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Steve O'Hara-Smith" , Charles Henrich From: Heiko Recktenwald Subject: Re: Realtime video capture/divx encoding (brooktree) beta testers required Cc: freebsd-hackers@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:48 Uhr +0100 05.03.2002, Steve O'Hara-Smith wrote: > PS: I am more interested in mpeg1 than DivX because with mpeg1 the >stream can be watched as it is being made. Would it help to "hint" it on the fly like it is done with mpeg4ip ? H. Btw, mpeg4ip did not compile here, 4.4 R, saw it on Linux. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 2: 2:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id 9900337B400; Tue, 5 Mar 2002 02:00:48 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id MAA13740; Tue, 5 Mar 2002 12:00:38 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h34.229.dialup.iptcom.net [212.9.229.34]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id MAA16763; Tue, 5 Mar 2002 12:00:30 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id g259xwB02794; Tue, 5 Mar 2002 11:59:58 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C84974D.37F683BD@FreeBSD.org> Date: Tue, 05 Mar 2002 12:00:45 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Extending loader(8) for loading kerels/modules split across several disks Content-Type: multipart/mixed; boundary="------------C69442EE275E6B52E76568F1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------C69442EE275E6B52E76568F1 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi folks, Please review attached patch, which adds long overdue feature to our loader(8), allowing it to load sequence of files as a single object. This should allow us to lift 1.44M limit on compressed kernel for the installation diskette. Please note, that to use this feature to load gzip-compressed objects you need to split the object first and then compress each piece individually, not compress first and then split already compressed file. Therefore tight fitting of each piece to the 1.44M limit could be a little tricky, but not impossible. Other way around is to use kgzip(8) utility to compress kernel and then split it into pieces 1.44M each. If there are no objections I would like to commit it ASAP, so that our RE team is able to use this feature in the forthcoming 5.0-DP1 release. Any feedback is appreciated. -Maxim --------------C69442EE275E6B52E76568F1 Content-Type: text/plain; charset=koi8-r; name="loader-multifiles.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="loader-multifiles.diff" Index: src/lib/libstand/close.c =================================================================== RCS file: /home/ncvs/src/lib/libstand/close.c,v retrieving revision 1.3 diff -d -u -r1.3 close.c --- src/lib/libstand/close.c 30 Sep 2001 22:28:00 -0000 1.3 +++ src/lib/libstand/close.c 5 Mar 2002 09:22:00 -0000 @@ -88,6 +88,7 @@ if (f->f_devdata != NULL) devclose(f); f->f_flags = 0; + f->f_udata = NULL; if (err1) { errno = err1; return (-1); Index: src/lib/libstand/open.c =================================================================== RCS file: /home/ncvs/src/lib/libstand/open.c,v retrieving revision 1.6 diff -d -u -r1.6 open.c --- src/lib/libstand/open.c 30 Sep 2001 22:28:01 -0000 1.6 +++ src/lib/libstand/open.c 5 Mar 2002 09:22:00 -0000 @@ -108,6 +108,7 @@ f->f_ops = (struct fs_ops *)0; f->f_offset = 0; f->f_devdata = NULL; + f->f_udata = NULL; file = (char *)0; error = devopen(f, fname, &file); if (error || Index: src/lib/libstand/stand.h =================================================================== RCS file: /home/ncvs/src/lib/libstand/stand.h,v retrieving revision 1.28 diff -d -u -r1.28 stand.h --- src/lib/libstand/stand.h 18 Feb 2002 20:35:19 -0000 1.28 +++ src/lib/libstand/stand.h 5 Mar 2002 09:22:00 -0000 @@ -164,6 +164,7 @@ char *f_rabuf; /* readahead buffer pointer */ size_t f_ralen; /* valid data in readahead buffer */ off_t f_raoffset; /* consumer offset in readahead buffer */ + void *f_udata; /* user data */ #define SOPEN_RASIZE 512 }; Index: src/sys/boot/alpha/libalpha/alpha_copy.c =================================================================== RCS file: /home/ncvs/src/sys/boot/alpha/libalpha/alpha_copy.c,v retrieving revision 1.5 diff -d -u -r1.5 alpha_copy.c --- src/sys/boot/alpha/libalpha/alpha_copy.c 3 Aug 2000 09:49:44 -0000 1.5 +++ src/sys/boot/alpha/libalpha/alpha_copy.c 5 Mar 2002 09:22:00 -0000 @@ -33,6 +33,7 @@ #include #include "libalpha.h" +#include "sread.h" ssize_t alpha_copyin(const void *src, vm_offset_t dest, const size_t len) @@ -51,7 +52,7 @@ ssize_t alpha_readin(const int fd, vm_offset_t dest, const size_t len) { - return(read(fd, (void *) dest, len)); + return(sread(fd, (void *) dest, len)); } Index: src/sys/boot/common/Makefile.inc =================================================================== RCS file: /home/ncvs/src/sys/boot/common/Makefile.inc,v retrieving revision 1.12 diff -d -u -r1.12 Makefile.inc --- src/sys/boot/common/Makefile.inc 27 Mar 2001 11:59:21 -0000 1.12 +++ src/sys/boot/common/Makefile.inc 5 Mar 2002 09:22:00 -0000 @@ -2,7 +2,7 @@ SRCS+= bcache.c boot.c commands.c console.c devopen.c interp.c SRCS+= interp_backslash.c interp_parse.c load_aout.c load_elf.c ls.c misc.c -SRCS+= module.c panic.c +SRCS+= module.c panic.c sread.c .if defined(LOADER_NET_SUPPORT) SRCS+= dev_net.c Index: src/sys/boot/common/boot.c =================================================================== RCS file: /home/ncvs/src/sys/boot/common/boot.c,v retrieving revision 1.28 diff -d -u -r1.28 boot.c --- src/sys/boot/common/boot.c 11 Sep 2001 01:09:19 -0000 1.28 +++ src/sys/boot/common/boot.c 5 Mar 2002 09:22:00 -0000 @@ -65,7 +65,7 @@ } /* find/load the kernel module */ - if (mod_loadkld(argv[1], argc - 2, argv + 2) != 0) + if (mod_loadkld(1, argv + 1, argc - 2, argv + 2) != 0) return(CMD_ERROR); /* we have consumed all arguments */ argc = 1; @@ -340,11 +340,11 @@ static int loadakernel(int try, int argc, char* argv[]) { - char *cp; + char *filesv[1]; - for (try = 0; (cp = getbootfile(try)) != NULL; try++) - if (mod_loadkld(cp, argc - 1, argv + 1) != 0) - printf("can't load '%s'\n", cp); + for (try = 0; (filesv[0] = getbootfile(try)) != NULL; try++) + if (mod_loadkld(1, filesv, argc - 1, argv + 1) != 0) + printf("can't load '%s'\n", filesv[0]); else return 1; return 0; Index: src/sys/boot/common/bootstrap.h =================================================================== RCS file: /home/ncvs/src/sys/boot/common/bootstrap.h,v retrieving revision 1.35 diff -d -u -r1.35 bootstrap.h --- src/sys/boot/common/bootstrap.h 25 Feb 2002 04:31:25 -0000 1.35 +++ src/sys/boot/common/bootstrap.h 5 Mar 2002 09:22:00 -0000 @@ -210,7 +210,7 @@ struct file_format { /* Load function must return EFTYPE if it can't handle the module supplied */ - int (* l_load)(char *filename, vm_offset_t dest, struct preloaded_file **result); + int (* l_load)(int filesc, char *filesv[], vm_offset_t dest, struct preloaded_file **result); /* Only a loader that will load a kernel (first module) should have an exec handler */ int (* l_exec)(struct preloaded_file *mp); }; @@ -218,9 +218,8 @@ extern struct file_format *file_formats[]; /* supplied by consumer */ extern struct preloaded_file *preloaded_files; -int mod_load(char *name, struct mod_depend *verinfo, int argc, char *argv[]); -int mod_loadobj(char *type, char *name); -int mod_loadkld(const char *name, int argc, char *argv[]); +int mod_load(int filesc, char *filesv[], struct mod_depend *verinfo, int argc, char *argv[]); +int mod_loadkld(int filesc, char *filesv[], int argc, char *argv[]); struct preloaded_file *file_alloc(void); struct preloaded_file *file_findfile(char *name, char *type); @@ -232,10 +231,10 @@ /* MI module loaders */ -int aout_loadfile(char *filename, vm_offset_t dest, struct preloaded_file **result); +int aout_loadfile(int filesc, char *filesv[], vm_offset_t dest, struct preloaded_file **result); vm_offset_t aout_findsym(char *name, struct preloaded_file *fp); -int elf_loadfile(char *filename, vm_offset_t dest, struct preloaded_file **result); +int elf_loadfile(int filesc, char *filesv[], vm_offset_t dest, struct preloaded_file **result); /* * Support for commands Index: src/sys/boot/common/load_aout.c =================================================================== RCS file: /home/ncvs/src/sys/boot/common/load_aout.c,v retrieving revision 1.20 diff -d -u -r1.20 load_aout.c --- src/sys/boot/common/load_aout.c 11 Sep 2001 01:09:19 -0000 1.20 +++ src/sys/boot/common/load_aout.c 5 Mar 2002 09:22:06 -0000 @@ -39,6 +39,7 @@ #include #include "bootstrap.h" +#include "sread.h" static int aout_loadimage(struct preloaded_file *fp, int fd, vm_offset_t loadaddr, struct exec *ehdr, int kernel); @@ -56,7 +57,7 @@ * will be saved in (result). */ int -aout_loadfile(char *filename, vm_offset_t dest, struct preloaded_file **result) +aout_loadfile(int filesc, char *filesv[], vm_offset_t dest, struct preloaded_file **result) { struct preloaded_file *fp, *kfp; struct exec ehdr; @@ -70,11 +71,11 @@ /* * Open the image, read and validate the a.out header */ - if (filename == NULL) /* can't handle nameless */ + if (filesv[0] == NULL) /* can't handle nameless */ return(EFTYPE); - if ((fd = open(filename, O_RDONLY)) == -1) + if ((fd = sopen(filesc, filesv, O_RDONLY)) == -1) return(errno); - if (read(fd, &ehdr, sizeof(ehdr)) != sizeof(ehdr)) { + if (sread(fd, &ehdr, sizeof(ehdr)) != sizeof(ehdr)) { err = EFTYPE; /* could be EIO, but may be small file */ goto oerr; } @@ -132,8 +133,8 @@ */ fp = file_alloc(); if (kernel) - setenv("kernelname", filename, 1); - fp->f_name = strdup(filename); + setenv("kernelname", filesv[0], 1); + fp->f_name = strdup(filesv[0]); fp->f_type = strdup(kernel ? aout_kerneltype : aout_moduletype); /* Page-align the load address */ @@ -145,7 +146,7 @@ } fp->f_addr = addr; /* save the aligned load address */ if (kernel) - printf("%s at %p\n", filename, (void *) addr); + printf("%s at %p\n", filesv[0], (void *) addr); fp->f_size = aout_loadimage(fp, fd, addr, &ehdr, kernel); if (fp->f_size == 0) @@ -170,7 +171,7 @@ oerr: file_discard(fp); out: - close(fd); + sclose(fd); return(err); } @@ -191,7 +192,7 @@ vm_offset_t ssym, esym; addr = loadaddr; - lseek(fd, (off_t)N_TXTOFF(*ehdr), SEEK_SET); + slseek(fd, (off_t)N_TXTOFF(*ehdr), SEEK_SET); /* text segment */ printf(" text=0x%lx ", ehdr->a_text); @@ -232,7 +233,7 @@ addr += ehdr->a_syms; /* string table */ - read(fd, &ss, sizeof(ss)); + sread(fd, &ss, sizeof(ss)); archsw.arch_copyin(&ss, addr, sizeof(ss)); addr += sizeof(ss); ss -= sizeof(ss); Index: src/sys/boot/common/load_elf.c =================================================================== RCS file: /home/ncvs/src/sys/boot/common/load_elf.c,v retrieving revision 1.21 diff -d -u -r1.21 load_elf.c --- src/sys/boot/common/load_elf.c 11 Sep 2001 01:09:19 -0000 1.21 +++ src/sys/boot/common/load_elf.c 5 Mar 2002 09:22:06 -0000 @@ -40,6 +40,7 @@ #include #include "bootstrap.h" +#include "sread.h" #define COPYOUT(s,d,l) archsw.arch_copyout((vm_offset_t)(s), d, l) @@ -76,7 +77,7 @@ * will be saved in (result). */ int -elf_loadfile(char *filename, vm_offset_t dest, struct preloaded_file **result) +elf_loadfile(int filesc, char *filesv[], vm_offset_t dest, struct preloaded_file **result) { struct preloaded_file *fp, *kfp; struct elf_file ef; @@ -91,16 +92,16 @@ /* * Open the image, read and validate the ELF header */ - if (filename == NULL) /* can't handle nameless */ + if (filesv[0] == NULL) /* can't handle nameless */ return(EFTYPE); - if ((ef.fd = open(filename, O_RDONLY)) == -1) + if ((ef.fd = sopen(filesc, filesv, O_RDONLY)) == -1) return(errno); ef.firstpage = malloc(PAGE_SIZE); if (ef.firstpage == NULL) { - close(ef.fd); + sclose(ef.fd); return(ENOMEM); } - bytes_read = read(ef.fd, ef.firstpage, PAGE_SIZE); + bytes_read = sread(ef.fd, ef.firstpage, PAGE_SIZE); ef.firstlen = (size_t)bytes_read; if (bytes_read < 0 || ef.firstlen <= sizeof(Elf_Ehdr)) { err = EFTYPE; /* could be EIO, but may be small file */ @@ -181,15 +182,15 @@ goto out; } if (ef.kernel) - setenv("kernelname", filename, 1); - fp->f_name = strdup(filename); + setenv("kernelname", filesv[0], 1); + fp->f_name = strdup(filesv[0]); fp->f_type = strdup(ef.kernel ? elf_kerneltype : elf_moduletype); #ifdef ELF_VERBOSE if (ef.kernel) - printf("%s entry at %p\n", filename, (void *) dest); + printf("%s entry at %p\n", filesv[0], (void *) dest); #else - printf("%s ", filename); + printf("%s ", filesv[0]); #endif fp->f_size = elf_loadimage(fp, &ef, dest); @@ -211,7 +212,7 @@ out: if (ef.firstpage) free(ef.firstpage); - close(ef.fd); + sclose(ef.fd); return(err); } @@ -289,7 +290,7 @@ phdr[i].p_vaddr + off, fpcopy); } if (phdr[i].p_filesz > fpcopy) { - if (lseek(ef->fd, (off_t)(phdr[i].p_offset + fpcopy), + if (slseek(ef->fd, (off_t)(phdr[i].p_offset + fpcopy), SEEK_SET) == -1) { printf("\nelf_loadexec: cannot seek\n"); goto out; @@ -348,11 +349,11 @@ shdr = malloc(chunk); if (shdr == NULL) goto nosyms; - if (lseek(ef->fd, (off_t)ehdr->e_shoff, SEEK_SET) == -1) { + if (slseek(ef->fd, (off_t)ehdr->e_shoff, SEEK_SET) == -1) { printf("\nelf_loadimage: cannot lseek() to section headers"); goto nosyms; } - result = read(ef->fd, shdr, chunk); + result = sread(ef->fd, shdr, chunk); if (result < 0 || (size_t)result != chunk) { printf("\nelf_loadimage: read section headers failed"); goto nosyms; @@ -418,7 +419,7 @@ printf("0x%lx+0x%lx", (long)sizeof(size), size); #endif - if (lseek(ef->fd, (off_t)shdr[i].sh_offset, SEEK_SET) == -1) { + if (slseek(ef->fd, (off_t)shdr[i].sh_offset, SEEK_SET) == -1) { printf("\nelf_loadimage: could not seek for symbols - skipped!"); lastaddr = ssym; ssym = 0; Index: src/sys/boot/common/loader.8 =================================================================== RCS file: /home/ncvs/src/sys/boot/common/loader.8,v retrieving revision 1.40 diff -d -u -r1.40 loader.8 --- src/sys/boot/common/loader.8 21 Feb 2002 05:15:51 -0000 1.40 +++ src/sys/boot/common/loader.8 5 Mar 2002 09:22:06 -0000 @@ -189,11 +189,21 @@ .Pp .It Ic load Xo .Op Fl t Ar type -.Ar file Cm ... +.Op Fl n Ar N +.Ar file1 +.Op Ar ... fileN +.Cm ... .Xc Loads a kernel, kernel loadable module (kld), or a file of opaque contents tagged as being of the type .Ar type . +If +.Fl n +is specified it loads number of files as a single object joining +them together and prompting for user's confirmation when one of +the files could not be found. +This allows loading a large file from a limited-size media (such +as floppy disks) by splitting the file into smaller pieces. Kernel and modules can be either in a.out or elf format. Any arguments passed after the name of the file to be loaded will be passed as arguments to that file. Index: src/sys/boot/common/module.c =================================================================== RCS file: /home/ncvs/src/sys/boot/common/module.c,v retrieving revision 1.22 diff -d -u -r1.22 module.c --- src/sys/boot/common/module.c 16 Nov 2001 21:08:40 -0000 1.22 +++ src/sys/boot/common/module.c 5 Mar 2002 09:22:11 -0000 @@ -38,6 +38,7 @@ #include #include "bootstrap.h" +#include "sread.h" #define MDIR_REMOVED 0x0001 #define MDIR_NOHINTS 0x0002 @@ -50,8 +51,8 @@ STAILQ_ENTRY(moduledir) d_link; }; -static int file_load(char *filename, vm_offset_t dest, struct preloaded_file **result); -static int file_loadraw(char *type, char *name); +static int file_load(int filesc, char *filesv[], vm_offset_t dest, struct preloaded_file **result); +static int file_loadraw(char *type, int filesc, char *filesv[]); static int file_load_dependencies(struct preloaded_file *base_mod); static char * file_search(const char *name, char **extlist); static struct kernel_module * file_findmodule(struct preloaded_file *fp, char *modname, struct mod_depend *verinfo); @@ -79,15 +80,15 @@ /* - * load an object, either a disk file or code module. + * load an object, either a disk file(s) or code module. * * To load a file, the syntax is: * - * load -t + * load -t [-n N] ... * * code modules are loaded as: * - * load + * load [-n N] ... */ COMMAND_SET(load, "load", "load a kernel or module", command_load); @@ -96,9 +97,10 @@ command_load(int argc, char *argv[]) { char *typestr; - int dofile, dokld, ch, error; + int dofile, dokld, ch, error, filesc; dokld = dofile = 0; + filesc = 1; optind = 1; optreset = 1; typestr = NULL; @@ -106,11 +108,14 @@ command_errmsg = "no filename specified"; return(CMD_ERROR); } - while ((ch = getopt(argc, argv, "kt:")) != -1) { + while ((ch = getopt(argc, argv, "kn:t:")) != -1) { switch(ch) { case 'k': dokld = 1; break; + case 'n': + filesc = (int)strtol(optarg, (char **)NULL, 10); + break; case 't': typestr = optarg; dofile = 1; @@ -121,34 +126,38 @@ return(CMD_OK); } } - argv += (optind - 1); - argc -= (optind - 1); + argv += optind; + argc -= optind; + if ((filesc <= 0) || (argc < filesc)) { + command_errmsg = "number of slices is missed or invalid"; + return(CMD_ERROR); + } /* * Request to load a raw file? */ if (dofile) { - if ((argc != 2) || (typestr == NULL) || (*typestr == 0)) { + if ((argc != filesc) || (typestr == NULL) || (*typestr == 0)) { command_errmsg = "invalid load type"; return(CMD_ERROR); } - return(file_loadraw(typestr, argv[1])); + return(file_loadraw(typestr, filesc, argv)); } /* * Do we have explicit KLD load ? */ - if (dokld || file_havepath(argv[1])) { - error = mod_loadkld(argv[1], argc - 2, argv + 2); + if (dokld || file_havepath(argv[0]) || (filesc > 1)) { + error = mod_loadkld(filesc, argv, argc - filesc, argv + filesc); if (error == EEXIST) - sprintf(command_errbuf, "warning: KLD '%s' already loaded", argv[1]); + sprintf(command_errbuf, "warning: KLD '%s' already loaded", argv[0]); return (error == 0 ? CMD_OK : CMD_ERROR); } /* * Looks like a request for a module. */ - error = mod_load(argv[1], NULL, argc - 2, argv + 2); + error = mod_load(filesc, argv, NULL, argc - filesc, argv + filesc); if (error == EEXIST) - sprintf(command_errbuf, "warning: module '%s' already loaded", argv[1]); + sprintf(command_errbuf, "warning: module '%s' already loaded", argv[0]); return (error == 0 ? CMD_OK : CMD_ERROR); } @@ -229,7 +238,7 @@ * File level interface, functions file_* */ int -file_load(char *filename, vm_offset_t dest, struct preloaded_file **result) +file_load(int filesc, char *filesv[], vm_offset_t dest, struct preloaded_file **result) { struct preloaded_file *fp; int error; @@ -237,7 +246,7 @@ error = EFTYPE; for (i = 0, fp = NULL; file_formats[i] && fp == NULL; i++) { - error = (file_formats[i]->l_load)(filename, loadaddr, &fp); + error = (file_formats[i]->l_load)(filesc, filesv, loadaddr, &fp); if (error == 0) { fp->f_loader = i; /* remember the loader */ *result = fp; @@ -247,7 +256,7 @@ continue; /* Unknown to this handler? */ if (error) { sprintf(command_errbuf, "can't load file '%s': %s", - filename, strerror(error)); + filesv[0], strerror(error)); break; } } @@ -261,6 +270,7 @@ struct mod_depend *verinfo; struct kernel_module *mp; char *dmodname; + char *filesv[1]; int error; md = file_findmetadata(base_file, MODINFOMD_DEPLIST); @@ -272,7 +282,8 @@ dmodname = (char *)(verinfo + 1); if (file_findmodule(NULL, dmodname, verinfo) == NULL) { printf("loading required module '%s'\n", dmodname); - error = mod_load(dmodname, verinfo, 0, NULL); + filesv[0] = dmodname; + error = mod_load(1, filesv, verinfo, 0, NULL); if (error) break; /* @@ -305,7 +316,7 @@ * no arguments or anything. */ int -file_loadraw(char *type, char *name) +file_loadraw(char *type, int filesc, char *filesv[]) { struct preloaded_file *fp; char *cp; @@ -319,16 +330,16 @@ } /* locate the file on the load path */ - cp = file_search(name, NULL); + cp = file_search(filesv[0], NULL); if (cp == NULL) { - sprintf(command_errbuf, "can't find '%s'", name); + sprintf(command_errbuf, "can't find '%s'", filesv[0]); return(CMD_ERROR); } - name = cp; + filesv[0] = cp; - if ((fd = open(name, O_RDONLY)) < 0) { - sprintf(command_errbuf, "can't open '%s': %s", name, strerror(errno)); - free(name); + if ((fd = sopen(filesc, filesv, O_RDONLY)) < 0) { + sprintf(command_errbuf, "can't open '%s': %s", filesv[0], strerror(errno)); + free(filesv[0]); return(CMD_ERROR); } @@ -339,9 +350,9 @@ if (got == 0) /* end of file */ break; if (got < 0) { /* error */ - sprintf(command_errbuf, "error reading '%s': %s", name, strerror(errno)); - free(name); - close(fd); + sprintf(command_errbuf, "error reading '%s': %s", filesv[0], strerror(errno)); + free(filesv[0]); + sclose(fd); return(CMD_ERROR); } laddr += got; @@ -349,7 +360,7 @@ /* Looks OK so far; create & populate control structure */ fp = file_alloc(); - fp->f_name = name; + fp->f_name = filesv[0]; fp->f_type = strdup(type); fp->f_args = NULL; fp->f_metadata = NULL; @@ -362,7 +373,7 @@ /* Add to the list of loaded files */ file_insert_tail(fp); - close(fd); + sclose(fd); return(CMD_OK); } @@ -372,18 +383,18 @@ * If module is already loaded just assign new argc/argv. */ int -mod_load(char *modname, struct mod_depend *verinfo, int argc, char *argv[]) +mod_load(int filesc, char *filesv[], struct mod_depend *verinfo, int argc, char *argv[]) { struct kernel_module *mp; int err; char *filename; - if (file_havepath(modname)) { - printf("Warning: mod_load() called instead of mod_loadkld() for module '%s'\n", modname); - return (mod_loadkld(modname, argc, argv)); + if (file_havepath(filesv[0])) { + printf("Warning: mod_load() called instead of mod_loadkld() for module '%s'\n", filesv[0]); + return (mod_loadkld(filesc, filesv, argc, argv)); } /* see if module is already loaded */ - mp = file_findmodule(NULL, modname, verinfo); + mp = file_findmodule(NULL, filesv[0], verinfo); if (mp) { #ifdef moduleargs if (mp->m_args) @@ -394,12 +405,12 @@ return (0); } /* locate file with the module on the search path */ - filename = mod_searchmodule(modname, verinfo); + filename = mod_searchmodule(filesv[0], verinfo); if (filename == NULL) { - sprintf(command_errbuf, "can't find '%s'", modname); + sprintf(command_errbuf, "can't find '%s'", filesv[0]); return (ENOENT); } - err = mod_loadkld(filename, argc, argv); + err = mod_loadkld(filesc, filesv, argc, argv); return (err); } @@ -408,7 +419,7 @@ * search path. */ int -mod_loadkld(const char *kldname, int argc, char *argv[]) +mod_loadkld(int filesc, char *filesv[], int argc, char *argv[]) { struct preloaded_file *fp, *last_file; int err; @@ -417,9 +428,9 @@ /* * Get fully qualified KLD name */ - filename = file_search(kldname, kld_ext_list); + filename = file_search(filesv[0], kld_ext_list); if (filename == NULL) { - sprintf(command_errbuf, "can't find '%s'", kldname); + sprintf(command_errbuf, "can't find '%s'", filesv[0]); return (ENOENT); } /* @@ -437,7 +448,8 @@ ; do { - err = file_load(filename, loadaddr, &fp); + filesv[0] = filename; + err = file_load(filesc, filesv, loadaddr, &fp); if (err) break; fp->f_args = unargv(argc, argv); Index: src/sys/boot/common/sread.c =================================================================== RCS file: src/sys/boot/common/sread.c diff -N src/sys/boot/common/sread.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/sys/boot/common/sread.c 5 Mar 2002 09:22:11 -0000 @@ -0,0 +1,227 @@ +/*- + * Copyright (c) 2002 Maxim Sobolev + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/* + * sfiles.c - API for reading sequence of files as if they were a single big + * file. Modeled after standard open()/read()/lseek()/close(). + * Useful for bootstraping a system from a limited-size media, such + * as floppy disks, when one of the files required for + * bootstrapping doesn't fit onto the single media. + * + * API is backward-compatible with file descriptors created using + * ordinary open() - they could with used with s-functions without + * any problems. Please note, however, that the descriptors opened + * with sopen() can't be used with non s-functions. + * + * Please note that for obvious reasons slseek() doesn't support + * SEEK_END and seeking backwards is limited to one slice only. + */ + +#include + +#define NTRIES (3) +#define SLSEEK_BUF (512) + +struct sfiles { + char **filesv; /* Filenames */ + int filesc; /* Number of files */ + int mode; /* sopen() mode */ + int curfile; /* Current file number */ + off_t cur_pos; /* Current offset from the beginning of the sequence */ + off_t file_pos; /* Current offset from the beginning of the slice */ +}; + +int +sopen(int filesc, char *const filesv[], int mode) +{ + int i, fd; + struct sfiles *sfiles; + + if ((fd = open(filesv[0], mode)) == -1) + return (-1); + + /* + * Don't need any extra processing if there is only one file. In this case + * files[fd].f_udata is NULL (ensured by the open()). + */ + if (filesc == 1) + return (fd); + + /* Create and populate sfiles instance */ + sfiles = malloc(sizeof(*sfiles)); + sfiles->filesv = malloc(filesc * sizeof(char *)); + for (i = 0; i < filesc; i++) + sfiles->filesv[i] = strdup(filesv[i]); + sfiles->filesc = filesc; + sfiles->mode = mode; + sfiles->curfile = 0; + sfiles->cur_pos = 0; + sfiles->file_pos = 0; + + (struct sfiles *)files[fd].f_udata = sfiles; + + return (fd); +} + +int +sclose(int fd) +{ + int i; + struct sfiles *sfiles; + + sfiles = (struct sfiles *)files[fd].f_udata; + if (sfiles != NULL) { + /* Destroy sfiles instance */ + for (i = 0; i < sfiles->filesc; i++) + free(sfiles->filesv[i]); + free(sfiles->filesv); + free(sfiles); + files[fd].f_udata = NULL; + } + + return (close(fd)); +} + +int +sread(int fd, void *buf, size_t nbytes) +{ + int i, fd1, nread, totread; + struct sfiles *sfiles; + struct open_file tmp; + + sfiles = (struct sfiles *)files[fd].f_udata; + if (sfiles == NULL) + return (read(fd, buf, nbytes)); + totread = 0; + do { + nread = read(fd, buf, nbytes - totread); + + /* Error */ + if (nread == -1) + return (-1); + + sfiles->cur_pos += nread; + sfiles->file_pos += nread; + totread += nread; + buf += nread; + + /* EOF */ + if ((nread == 0) || (nread < (nbytes - totread))) { + /* Last slice? */ + if (sfiles->curfile == (sfiles->filesc - 1)) + return (nread); + /* Close previous slice */ + if (close(fd) != 0) + return (-1); + sfiles->curfile++; + for (i = 0;; i++) { + fd1 = open(sfiles->filesv[sfiles->curfile], sfiles->mode); + if (fd1 >= 0) + break; + if ((fd1 == -1 && errno != ENOENT) || i == NTRIES) + return (-1); + printf("\nInsert media that contains `%s' and press any key...", \ + sfiles->filesv[sfiles->curfile]); + getchar();putchar('\n'); + } + (struct sfiles *)files[fd1].f_udata = sfiles; + sfiles->file_pos = 0; + if (fd1 != fd) { + tmp = files[fd]; + files[fd] = files[fd1]; + files[fd1] = tmp; + } + } + } while (totread < nbytes); + + return (totread); +} + +off_t +slseek(int fd, off_t offset, int where) +{ + int nread; + struct sfiles *sfiles; + off_t new_pos, seek_by; + + sfiles = (struct sfiles *)files[fd].f_udata; + if (sfiles == NULL) + return (lseek(fd, offset, where)); + + seek_by = 0; + switch (where) { + case SEEK_SET: + seek_by = offset - sfiles->cur_pos; + break; + + case SEEK_CUR: + seek_by = offset; + break; + + case SEEK_END: + panic("slseek(): SEEK_END not supported"); + break; + } + + if (seek_by > 0) { + /* + * Seek forward - implemented using sread(), because otherwise we'll be + * unable to detect that we have crossed slice boundary and hence unable + * to do a long seek crossing that boundary. + */ + void *tmp; + + tmp = malloc(SLSEEK_BUF); + if (tmp == NULL) + return (-1); + + nread = 0; + for (; seek_by > 0; seek_by -= nread) { + nread = sread(fd, tmp, min(seek_by, SLSEEK_BUF)); + if (nread <= 0) + /* Error or EOF */ + break; + } + free(tmp); + if (nread == -1) + return (-1); + } + + if (seek_by != 0) { + /* Seek backward or seek past the boundary of the last slice */ + if (sfiles->file_pos + seek_by < 0) + panic("slseek(): can't seek past the beginning of the slice"); + new_pos = lseek(fd, seek_by, SEEK_CUR); + if (new_pos < 0) + return (-1); + sfiles->cur_pos += new_pos - sfiles->file_pos; + sfiles->file_pos = new_pos; + } + + return (sfiles->cur_pos); +} Index: src/sys/boot/common/sread.h =================================================================== RCS file: src/sys/boot/common/sread.h diff -N src/sys/boot/common/sread.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/sys/boot/common/sread.h 5 Mar 2002 09:22:11 -0000 @@ -0,0 +1,32 @@ +/*- + * Copyright (c) 2002 Maxim Sobolev + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +extern int sopen(int, char * const *, int); +extern int sclose(int); +extern int sread(int, void *, size_t); +extern off_t slseek(int, off_t, int); Index: src/sys/boot/efi/libefi/copy.c =================================================================== RCS file: /home/ncvs/src/sys/boot/efi/libefi/copy.c,v retrieving revision 1.3 diff -d -u -r1.3 copy.c --- src/sys/boot/efi/libefi/copy.c 14 Sep 2001 08:26:00 -0000 1.3 +++ src/sys/boot/efi/libefi/copy.c 5 Mar 2002 09:22:11 -0000 @@ -38,6 +38,8 @@ #include #include +#include "sread.h" + int efi_copyin(void *src, vm_offset_t dest, size_t len) { @@ -65,5 +67,5 @@ BS->AllocatePages(AllocateAddress, EfiRuntimeServicesData, len >> 12, &p); #endif - return (read(fd, (void*) p, len)); + return (sread(fd, (void*) p, len)); } Index: src/sys/boot/i386/libi386/i386_copy.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/libi386/i386_copy.c,v retrieving revision 1.9 diff -d -u -r1.9 i386_copy.c --- src/sys/boot/i386/libi386/i386_copy.c 3 Aug 2000 09:14:01 -0000 1.9 +++ src/sys/boot/i386/libi386/i386_copy.c 5 Mar 2002 09:22:11 -0000 @@ -35,6 +35,7 @@ #include "libi386.h" #include "btxv86.h" +#include "sread.h" #define READIN_BUF (16 * 1024) @@ -80,7 +81,7 @@ for (resid = len; resid > 0; resid -= got, dest += got) { get = min(chunk, resid); - got = read(fd, buf, get); + got = sread(fd, buf, get); if (got <= 0) break; bcopy(buf, PTOV(dest), (size_t)got); Index: src/sys/boot/i386/libi386/i386_module.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/libi386/i386_module.c,v retrieving revision 1.5 diff -d -u -r1.5 i386_module.c --- src/sys/boot/i386/libi386/i386_module.c 11 Sep 2001 01:09:23 -0000 1.5 +++ src/sys/boot/i386/libi386/i386_module.c 5 Mar 2002 09:22:11 -0000 @@ -44,13 +44,14 @@ i386_autoload(void) { int error; + char *filesv[1] = {"acpi"}; /* XXX use PnP to locate stuff here */ /* autoload ACPI support */ /* XXX should be in 4th keyed off acpi_load */ if ((getenv("acpi_load") && !getenv("hint.acpi.0.disable"))) { - error = mod_load("acpi", NULL, 0, NULL); + error = mod_load(1, filesv, NULL, 0, NULL); if (error != 0) printf("ACPI autoload failed - %s\n", strerror(error)); } Index: src/sys/boot/ia64/libski/copy.c =================================================================== RCS file: /home/ncvs/src/sys/boot/ia64/libski/copy.c,v retrieving revision 1.1 diff -d -u -r1.1 copy.c --- src/sys/boot/ia64/libski/copy.c 12 Sep 2001 08:34:26 -0000 1.1 +++ src/sys/boot/ia64/libski/copy.c 5 Mar 2002 09:22:11 -0000 @@ -38,6 +38,8 @@ #include +#include "sread.h" + int ski_copyin(void *src, vm_offset_t dest, size_t len) { @@ -55,5 +57,5 @@ int ski_readin(int fd, vm_offset_t dest, size_t len) { - return (read(fd, (void*) IA64_RR_MASK(dest), len)); + return (sread(fd, (void*) IA64_RR_MASK(dest), len)); } Index: src/sys/boot/ofw/libofw/ofw_copy.c =================================================================== RCS file: /home/ncvs/src/sys/boot/ofw/libofw/ofw_copy.c,v retrieving revision 1.10 diff -d -u -r1.10 ofw_copy.c --- src/sys/boot/ofw/libofw/ofw_copy.c 7 Oct 2001 13:27:27 -0000 1.10 +++ src/sys/boot/ofw/libofw/ofw_copy.c 5 Mar 2002 09:22:11 -0000 @@ -33,6 +33,7 @@ #include #include "libofw.h" +#include "sread.h" #define READIN_BUF (4 * 1024) @@ -69,7 +70,7 @@ for (resid = len; resid > 0; resid -= got, p += got) { get = min(chunk, resid); - got = read(fd, buf, get); + got = sread(fd, buf, get); if (got <= 0) { printf("ofw_readin: read failed\n"); Index: src/sys/boot/sparc64/loader/main.c =================================================================== RCS file: /home/ncvs/src/sys/boot/sparc64/loader/main.c,v retrieving revision 1.6 diff -d -u -r1.6 main.c --- src/sys/boot/sparc64/loader/main.c 1 Mar 2002 06:17:28 -0000 1.6 +++ src/sys/boot/sparc64/loader/main.c 5 Mar 2002 09:22:11 -0000 @@ -37,6 +37,7 @@ #include "bootstrap.h" #include "libofw.h" #include "dev_net.h" +#include "sread.h" enum { HEAPVA = 0x800000, @@ -193,7 +194,7 @@ sparc64_readin(const int fd, vm_offset_t va, const size_t len) { mmu_mapin(va, len); - return read(fd, (void *)va, len); + return sread(fd, (void *)va, len); } static ssize_t --------------C69442EE275E6B52E76568F1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 4:25:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by hub.freebsd.org (Postfix) with ESMTP id 1505937B405 for ; Tue, 5 Mar 2002 04:22:48 -0800 (PST) Received: from yahoo.com ([64.229.184.12]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020305122140.IUYH2871.tomts8-srv.bellnexxia.net@yahoo.com> for ; Tue, 5 Mar 2002 07:21:40 -0500 Message-ID: <002c01c1c260$bf91b1d0$0cb8e540@sympatico.ca> Reply-To: "Dr Guihua Li" From: "Dr Guihua Li" To: freebsd-hackers@freebsd.org Subject: Invitation letter from the Organisation Committee of the First World Congress of Future Science and Culture Date: Sat, 2 Mar 2002 22:08:52 -0500 Organization: Organisation Committee of First World Congress of Future Science and Culture MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01C1C236.D6894F30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C1C236.D6894F30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0029_01C1C236.D6894F30" ------=_NextPart_001_0029_01C1C236.D6894F30 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Sir/Madam, = =20 =20 Many of us who came to work in the sciences or similar areas did so = because we wanted to explore the unknown and gain more knowledge and = ultimately make this world a better place. It is undoubtedly true that = modern science has brought immense benefits to humanity but also = encountered many unsolved questions and problems including environmental = pollution.=20 =20 Perhaps it is now time for a different approach: Falun Dafa takes a = holistic view of life and the universe. It builds on the insights of = modern science and combines them with the insights from ancient Chinese = science and culture. We, scientists who understand Falun Dafa, invite = you to participate in the First World Congress of Future Science and = Culture that will be held at Cambridge on March 9th and 10th of 2002. = This congress will see state of the art research in this field and serve = as a forum for discussing how these new ideas could exert a profound = influence on the future science and culture of humankind. =20 Renowned specialists and professors in diverse academic disciplines from = many different parts of the world will be participating. A schedule for = March 9th is attached. On March 10 we will be holding an informal = discussion session at which participants at the conference can raise = issues with the speakers.=20 =20 We do hope that you will be able to find the time to attend. Please let = us know if you have any questions. =20 Yours sincerely, =20 =20 =20 Dr Guihua Li Organisation Committee of First World Congress of Future Science and = Culture fsc_congress@hotmail.com http://www.fsc-congress.org ------=_NextPart_001_0029_01C1C236.D6894F30 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Sir/Madam,               &nbs= p;        =20            &nbs= p;        =20            &nbs= p; =20

 

Many=20 of us who came to work in the sciences or similar areas did so because = we wanted=20 to explore the unknown and gain more knowledge and ultimately make this = world a=20 better place.  It is = undoubtedly=20 true that modern science has brought immense benefits to humanity but = also=20 encountered many unsolved questions and problems including environmental = pollution.

 

Perhaps it is now time for a different = approach:  Falun Dafa takes a holistic = view of life=20 and the universe. It builds on the insights of modern science and = combines them=20 with the insights from ancient Chinese science and culture. We, = scientists who=20 understand Falun Dafa, invite you to participate in the First World = Congress of=20 Future Science and Culture that will be held at Cambridge on March=20 9th and 10th of 2002. This congress will see state = of the=20 art research in this field and serve as a forum for discussing how these = new=20 ideas could exert a profound influence on the future science and culture = of=20 humankind.

 

Renowned specialists and professors in diverse = academic=20 disciplines from many different parts of the world will be = participating.  A schedule for March 9th is = attached. On=20 March 10 we will be holding an informal discussion session at which = participants=20 at the conference can raise issues with the speakers.=20

 

We do hope that = you will be=20 able to find the time to attend.=20 Please let us know if you have any = questions.

 

Yours sincerely,

 

 


 

Dr Guihua Li

Organisation Committee of First World Congress = of Future=20 Science and Culture

fsc_congress@hotmail.com

http://www.fsc-congress.org

------=_NextPart_001_0029_01C1C236.D6894F30-- ------=_NextPart_000_0028_01C1C236.D6894F30 Content-Type: application/msword; name="Invitation-Peter2.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Invitation-Peter2.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAWgAAAAAAAAAA EAAAXQAAAAEAAAD+////AAAAAFkAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWyAJBAAA+BK/AAAAAAAAEAAAAAAABAAASiMAAA4AYmpiauIA4gAAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIkIAAIBqAQCAagEAwhMAAAAAAAAeAAAAAAAAAAAAAAAAAAAABQAAAGQAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAANoDAAAAAAAA2gMAANoD AAAAAAAA2gMAAAAAAAAKBQAAAAAAAAoFAAAAAAAACgUAABQAAAAAAAAAAAAAAB4FAAAAAAAABhIA AAAAAAAGEgAAAAAAAAYSAAA4AAAAPhIAACQAAABiEgAAPAAAAB4FAAAAAAAAtTMAALQBAACqEgAA OgAAAOQSAAAoAAAADBMAAAAAAAAMEwAAAAAAANgTAAAAAAAAQBcAAAAAAABAFwAAAAAAAEAXAAAA AAAApDIAAAIAAACmMgAAAAAAAKYyAAAAAAAApjIAAAAAAACmMgAAAAAAAKYyAAAAAAAApjIAACQA AABpNQAAIAIAAIk3AABiAAAAyjIAAKUAAAAAAAAAAAAAAAAAAAAAAAAACgUAAAAAAABAFwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAaFwAABAAAAB4XAAAiAAAAQBcAAAAAAABAFwAAAAAAAMoyAAAAAAAA JBsAAAAAAADaAwAAAAAAANoDAAAAAAAADBMAAAAAAAAAAAAAAAAAANgTAABCAwAAbzMAABYAAAAk GwAAAAAAACQbAAAAAAAAJBsAAAAAAABAFwAA7AIAANoDAACGAAAADBMAAAAAAACWBAAAUgAAANgT AAAAAAAApDIAAAAAAAAAAAAAAAAAACQbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQBcAAAAAAACkMgAAAAAAACQbAAAmBAAAJBsAAAAAAABKHwAA xgAAACAxAACQAAAAYAQAADYAAADoBAAAIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2DEAAAAAAAAMEwAAzAAAAJ4SAAAMAAAAEF5I95K/ wQEeBQAA6AwAAAYSAAAAAAAALBoAAL4AAACwMQAAFAAAAAAAAAAAAAAA2DEAAMwAAACFMwAAMAAA ALUzAAAAAAAAxDEAABQAAADrNwAAAAAAAOoaAAA6AAAA6zcAAAAAAADYMQAAAAAAACQbAAAAAAAA HgUAAAAAAAAeBQAAAAAAANoDAAAAAAAA2gMAAAAAAADaAwAAAAAAANoDAAAAAAAAAgDZAAAADQ0N CQkJCQkJCQkJMjYgRmVicnVhcnkgMjAwMg0NoA1EZWFyIFNpci9NYWRhbSwgCQkJCQkJCQkJDaAN TWFueSBvZiB1cyB3aG8gY2FtZSB0byB3b3JrIGluIHRoZSBzY2llbmNlcyBvciBzaW1pbGFyIGFy ZWFzIGRpZCBzbyBiZWNhdXNlIHdlIHdhbnRlZCB0byBleHBsb3JlIHRoZSB1bmtub3duIGFuZCBn YWluIG1vcmUga25vd2xlZGdlIGFuZCB1bHRpbWF0ZWx5IG1ha2UgdGhpcyB3b3JsZCBhIGJldHRl ciBwbGFjZS4gIEl0IGlzIHVuZG91YnRlZGx5IHRydWUgdGhhdCBtb2Rlcm4gc2NpZW5jZSBoYXMg YnJvdWdodCBpbW1lbnNlIGJlbmVmaXRzIHRvIGh1bWFuaXR5IGJ1dCBhbHNvIGVuY291bnRlcmVk IG1hbnkgdW5zb2x2ZWQgcXVlc3Rpb25zIGFuZCBwcm9ibGVtcyBpbmNsdWRpbmcgZW52aXJvbm1l bnRhbCBwb2xsdXRpb24uIA2gDVBlcmhhcHMgaXQgaXMgbm93IHRpbWUgZm9yIGEgZGlmZmVyZW50 IGFwcHJvYWNoOiAgRmFsdW4gRGFmYSB0YWtlcyBhIGhvbGlzdGljIHZpZXcgb2YgbGlmZSBhbmQg dGhlIHVuaXZlcnNlLiBJdCBidWlsZHMgb24gdGhlIGluc2lnaHRzIG9mIG1vZGVybiBzY2llbmNl IGFuZCBjb21iaW5lcyB0aGVtIHdpdGggdGhlIGluc2lnaHRzIGZyb20gYW5jaWVudCBDaGluZXNl IHNjaWVuY2UgYW5kIGN1bHR1cmUuIFdlLCBzY2llbnRpc3RzIHdobyB1bmRlcnN0YW5kIEZhbHVu IERhZmEsIGludml0ZSB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIEZpcnN0IFdvcmxkIENvbmdy ZXNzIG9mIEZ1dHVyZSBTY2llbmNlIGFuZCBDdWx0dXJlIHRoYXQgd2lsbCBiZSBoZWxkIGF0IENh bWJyaWRnZSBvbiBNYXJjaCA5dGggYW5kIDEwdGggb2YgMjAwMi4gVGhpcyBjb25ncmVzcyB3aWxs IHNlZSBzdGF0ZSBvZiB0aGUgYXJ0IHJlc2VhcmNoIGluIHRoaXMgZmllbGQgYW5kIHNlcnZlIGFz IGEgZm9ydW0gZm9yIGRpc2N1c3NpbmcgaG93IHRoZXNlIG5ldyBpZGVhcyBjb3VsZCBleGVydCBh IHByb2ZvdW5kIGluZmx1ZW5jZSBvbiB0aGUgZnV0dXJlIHNjaWVuY2UgYW5kIGN1bHR1cmUgb2Yg aHVtYW5raW5kLg0NUmVub3duZWQgc3BlY2lhbGlzdHMgYW5kIHByb2Zlc3NvcnMgaW4gZGl2ZXJz ZSBhY2FkZW1pYyBkaXNjaXBsaW5lcyBmcm9tIG1hbnkgZGlmZmVyZW50IHBhcnRzIG9mIHRoZSB3 b3JsZCB3aWxsIGJlIHBhcnRpY2lwYXRpbmcuICBBIHNjaGVkdWxlIGZvciBNYXJjaCA5dGggaXMg YXR0YWNoZWQuIE9uIE1hcmNoIDEwIHdlIHdpbGwgYmUgaG9sZGluZyBhbiBpbmZvcm1hbCBkaXNj dXNzaW9uIHNlc3Npb24gYXQgd2hpY2ggcGFydGljaXBhbnRzIGF0IHRoZSBjb25mZXJlbmNlIGNh biByYWlzZSBpc3N1ZXMgd2l0aCB0aGUgc3BlYWtlcnMuIA0NV2UgZG8gaG9wZSB0aGF0IHlvdSB3 aWxsIGJlIGFibGUgdG8gZmluZCB0aGUgdGltZSB0byBhdHRlbmQuIFBsZWFzZSBsZXQgdXMga25v dyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zLg2gDVlvdXJzIHNpbmNlcmVseSwNDQ0LIA1EciBH dWlodWEgTGkNT3JnYW5pc2F0aW9uIENvbW1pdHRlZSBvZiBGaXJzdCBXb3JsZCBDb25ncgBlAHMA cwAgAG8AZgAgAEYAdQB0AHUAcgBlACAAUwBjAGkAZQBuAGMAZQAgAGEAbgBkACAAQwB1AGwAdAB1 AHIAZQANABMAIABIAFkAUABFAFIATABJAE4ASwAgACIAbQBhAGkAbAB0AG8AOgBmAHMAYwBfAGMA bwBuAGcAcgBlAHMAcwBAAGgAbwB0AG0AYQBpAGwALgBjAG8AbQANACIAIAABABQAZgBzAGMAXwBj AG8AbgBnAHIAZQBzAHMAQABoAG8AdABtAGEAaQBsAC4AYwBvAG0ADQAVABMAIABIAFkAUABFAFIA TABJAE4ASwAgACIAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGYAcwBjAC0AYwBvAG4AZwByAGUAcwBz AC4AbwByAGcAIgAgAAEAFABoAHQAdABwADoALwAvAHcAdwB3AC4AZgBzAGMALQBjAG8AbgBnAHIA ZQBzAHMALgBvAHIAZwAVAA0ACwANAAwADQANAA0AQwBvAG4AZwByAGUAcwBzACAAUwBjAGgAZQBk AHUAbABlAA0ADQBNAGEAcgBjAGgAIAA5ACwAIAAyADAAMAAyAA0ADQA5ABr/MAAwACAAYQBtACAA CQBPAHAAZQBuAGkAbgBnACAAUgBlAG0AYQByAGsAcwANAA0AQgBpAG8AbABvAGcAeQAgAGEAbgBk ACAATQBlAGQAaQBjAGkAbgBlAA0ADQBDAGgAYQBpAHIAOgAgAEQAaQBhAG4AbgBhACAAUgBvAGIA ZQByAHQAcwAsACAAUABoAC4ARAAuACwAIABVAG4AaQB2AC4AIABvAGYAIABUAGUAeABhAHMAIABN AC4AIABEAC4AIABBAG4AZABlAHIAcwBvAG4AIABDAGEAbgBjAGUAcgAgAEMAZQBuAHQAZQByACwA IABIAG8AdQBzAHQAbwBuACwAIABVAFMAQQANAA0AOQAa/zEANQAgAGEAbQAgAAkATABpAGwAaQAg AEYAZQBuAGcALAAgAE0ARAAsACAARABlAHAAYQByAHQAbQBlAG4AdAAgAG8AZgAgAE0AZQBkAGkA YwBpAG4AZQAsACAAQgBhAHkAbABvAHIAIABDAG8AbABsAGUAZwBlACAAbwBmACAATQBlAGQAaQBj AGkAbgBlACwAIABIAG8AdQBzAHQAbwBuACwAIABUAGUAeABhAHMALAAgAFUAUwBBACAAIAAgABwg RwBlAG4AbwBtAGUALQB3AGkAZABlACAAcAByAG8AZgBpAGwAZQBzACAAbwBmACAAZwBlAG4AZQAg AGUAeABwAHIAZQBzAHMAaQBvAG4AIABpAG4AIABuAGUAdQB0AHIAbwBwAGgAaQBsAHMAIABmAHIA bwBtACAARgBhAGwAdQBuACAARwBvAG4AZwAgAHAAcgBhAGMAdABpAHQAaQBvAG4AZQByAHMAIABh AG4AZAAgAG4AbwByAG0AYQBsACAAaABlAGEAbAB0AGgAeQAgAGMAbwBuAHQAcgBvAGwAcwAdIA0A DQA5ABr/NQAwACAAYQBtACAACQBXAGkAbABsAGkAYQBtACAARgByAGEAbgBrAGwAaQBuACAATQBj AEMAbwB5ACwAIABNAC4ARAAuACwAIABIAG8AbQBlAG8AcABhAHQAaABpAGMAIABwAGgAeQBzAGkA YwBpAGEAbgAsACAAHCBNAGUAZABpAGMAYQBsACAAUAByAGEAYwB0AGkAYwBlACAAaQBuACAAdABo AGUAIABOAGUAdwAgAEUAcgBhAB0gDQANADEAMAAa/zEAMAAgAGEAbQAJAE0AYQBpACAASABlACwA IABNAEQALAAgAFAAaABEACwAIABEAGUAcABhAHIAdABtAGUAbgB0ACAAbwBmACAAUwB1AHIAZwBl AHIAeQAsACAATgBlAHcAIABKAGUAcgBzAGUAeQAgAE0AZQBkAGkAYwBhAGwAIABTAGMAaABvAG8A bAAsACAATgBlAHcAYQByAGsALAAgAE4ASgAsACAAVQBTAEEALAAgACAAHCBIAGUAYQBsAHQAaAAg AHMAdQByAHYAZQB5ACAAbwBmACAARgBhAGwAdQBuACAARwBvAG4AZwAgAHAAcgBhAGMAdABpAHQA aQBvAG4AZQByAHMAHSAgAA0ADQAxADAAGv8gADMAMAAgAGEAbQAJAFgAaQBhAG8AZABvAG4AZwAg AFMAaABhAG8ALAAgAE0ARAAsACAAHCBXAGUAcwB0AGUAcgBuACAATQBlAGQAaQBjAGkAbgBlACwA IABDAGgAaQBuAGUAcwBlACAATQBlAGQAaQBjAGkAbgBlACwAIABBAGMAdQBwAHUAbgBjAHQAdQBy AGUALAAgAFEAaQBnAG8AbgBnACAAYQBuAGQAIABDAHUAbAB0AGkAdgBhAHQAaQBvAG4AIABQAHIA YQBjAHQAaQBjAGUAHSANAA0AMQAwABr/NQAwACAAYQBtAAkAQgByAGUAYQBrAA0ADQBOAGUAdwAg AEMAbwBuAGMAZQBwAHQAcwAgAGkAbgAgAFMAYwBpAGUAbgBjAGUADQANAEMAaABhAGkAcgA6ACAA UwBoAGkAeQB1ACAAWgBoAG8AdQAsACAAUABoAC4ARAAsACAAVQBuAGkAdgBlAHIAcwBpAHQAeQAg AG8AZgAgAFAAZQBuAG4AcwB5AGwAdgBhAG4AaQBhACwAIABQAGgAaQBsAGEAZABlAGwAcABoAGkA YQAsACAAVQBTAEEADQANADEAMQAa/zAAMAAgAGEAbQAJAEQAYQBuAGkAZQBsACAASAB1AGEAbgBn AAz/HCBTAGMAaQBlAG4AYwBlABkgcwAgAFcAYQB5ACAATwB1AHQAHSANAA0AMQAxABr/MgAwACAA YQBtAAkAUwBoAGkAeQB1ACAAWgBoAG8AdQAsACAAUABoAC4ARAAuACwAIABVAG4AaQB2AGUAcgBz AGkAdAB5ACAAbwBmACAAUABlAG4AbgBzAHkAbAB2AGEAbgBpAGEALAAgAFAAaABpAGwAYQBkAGUA bABwAGgAaQBhACwAIABVAFMAQQAsACAAHCAgAFAAcgBvAHAAaABlAGMAeQAsACAAVABpAG0AZQAg AGEAbgBkACAAUwBwAGEAYwBlAB0gDQANADEAMQAa/zQAMAAgAGEAbQAJAE4AYQB0AGEAbAB5ACAA VABlAHAAbABpAHQAcwBrAHkALAAgAFAAaAAuAEQALgAsACAATgB1AGMAbABlAGEAcgAgAE0AZQBk AGkAYwBpAG4AZQAgAFQAZQBjAGgAbgBvAGwAbwBnAGkAcwB0ACwAIABSAGUAdAAuACAAHCBCAHIA ZQBhAGsAaQBuAGcAIABUAGgAcgBvAHUAZwBoACAAdABoAGUAIABDAG8AbgB2AGUAbgB0AGkAbwBu AGEAbAAgAFMAYwBpAGUAbgB0AGkAZgBpAGMAIABQAGEAcgBhAGQAaQBnAG0AHSANAA0AMQAyADoA MAAwACAAbgBvAG8AbgAJAEQAcgAuACAAUgBhAGkAbQB1AG4AZAAgAEsAaQByAG4AZQByACwAIAAc IEYAYQBsAHUAbgAgAEQAYQBmAGEAIABhAG4AZAAgAE0AbwBkAGUAcgBuACAAUwBjAGkAZQBuAGMA ZQAdIA0ADQANAA0ADQANAA0AMQAyADoAMgAwACAAcABtAC0AMgA6ADAAMAAgAHAAbQAgAAkAIABM AHUAbgBjAGgAIABCAHIAZQBhAGsADQANAFMAbwBjAGkAYQBsACAAYQBuAGQAIABFAG4AdgBpAHIA bwBuAG0AZQBuAHQAYQBsACAAUwBjAGkAZQBuAGMAZQAgAA0ADQBDAGgAYQBpAHIAOgAgAEoAaQBu AGgAdQBhACAAWgBoAGEAbgBnACwAIABQAGgALgBEAC4ALAAgAFAAcgBvAGYAZQBzAHMAbwByACAA bwBmACAATgBlAHcAcwAgAGEAbgBkACAATQBlAGQAaQBhACwAIABUAGEAaQB3AGEAbgAgAFUAbgBp AHYAZQByAHMAaQB0AHkADQANADIAGv8wADAAIABwAG0ACQBEAHIALgAgAEgAdQBpAGwAaQBuACAA VwB1AAz/UAByAG8AZgBlAHMAcwBvAHIAIABvAGYAIABFAGMAbwBuAG8AbQBpAGMAcwAsACAAQwBo AGkAbgBlAHMAZQAgAEUAYwBvAG4AbwBtAGkAYwBzACAAUgBlAHMAZQBhAHIAYwBoACAASQBuAHMA dABpAHQAdQB0AGUALAAgAFQAYQBpAHcAYQBuACwAIAAcIFQAaABlACAASwBlAHkAIAB0AG8AIABD AG8AbgBzAHQAYQBuAHQAIABHAHIAbwB3AHQAaAAgAG8AZgAgAEUAYwBvAG4AbwBtAHkAIABMAGkA ZQBzACAAaQBuACAAdABoAGUAIABSAGUAbgBhAGkAcwBzAGEAbgBjAGUAIABvAGYAIABNAG8AcgBh AGwAaQB0AHkAHSANAA0AMgAa/zIAMAAgAHAAbQAJAFkAYQBoAHUAaQAgAEMAYQBpACwAIABQAGgA LgBEAC4AIABDAGEAbgBkAGkAZABhAHQAZQAsACAARABlAHAAYQByAHQAbQBlAG4AdAAgAG8AZgAg AFMAcABhAHQAaQBhAGwAIABQAGwAYQBuAG4AaQBuAGcALAAgAFUAbgBpAHYAZQByAHMAaQB0AHkA IABvAGYAIABEAG8AcgB0AG0AdQBuAGQALAAgAEcAZQByAG0AYQBuAHkALAAgABwgVABoAGUAIABM AGkAdgBpAG4AZwAgAFMAcABhAGMAZQAgAG8AZgAgAEgAdQBtAGEAbgAgAEIAZQBpAG4AZwBzACAA EyAgAFUAbgBpAHEAdQBlACAAQwBvAG4AYwBlAHAAdABzACAAaQBuACAAVAByAGEAZABpAHQAaQBv AG4AYQBsACAAQwBoAGkAbgBlAHMAZQAgAEMAaQB0AGkAZQBzACAAYQBuAGQAIABUAG8AdwBuAHMA GSAgAEQAZQBzAGkAZwBuAHMAHSAgAA0ADQAyABr/NAAwACAAcABtAAkARgBlAG4AZwB5AGkAIABH AGEAbwAsACAAUABoAC4ARAAgAEMAYQBuAGQAaQBkAGEAdABlACwAIABUAG8AawB5AG8AIABJAG4A ZAB1AHMAdAByAGkAYQBsACAAVQBuAGkAdgBlAHIAcwBpAHQAeQAsACAAHCBBACAATgBlAHcAIABB AHAAcAByAG8AYQBjAGgAIAB0AG8AIABFAG4AdgBpAHIAbwBuAG0AZQBuAHQAIABQAHIAbwB0AGUA YwB0AGkAbwBuAC0AIABJAG0AcAByAG8AdgBpAG4AZwAgAHQAaABlACAATQBvAHIAYQBsACAAUwB0 AGEAbgBkAGEAcgBkAB0gIAANAA0AMwAa/zAAMAAgAHAAbQAJAEsAZQBhAG4AIABXAG8AbgBnACwA IABEAGkAcgBlAGMAdABvAHIAIABvAGYAIABaAFMAUgAgAEMAbwBuAHMAdQBsAHQAaQBuAGcAIABG AGkAcgBtACwAIABBAHUAcwB0AHIAYQBsAGkAYQAsACAAQwBoAGkAbgBhABkgcwAgAEUAYwBvAG4A bwBtAGkAYwAgAGEAbgBkACAAUwBvAGMAaQBhAGwAIABSAGUAbgBhAGkAcwBzAGEAbgBjAGUAOgAg AEYAYQBsAHUAbgAgAEcAbwBuAGcAIABhAG4AZAAgAHQAaABlACAAcgBpAHMAZQAgAG8AZgAgAFQA cgB1AHQAaAAtAEMAbwBtAHAAYQBzAHMAaQBvAG4ALQAgAEYAbwByAGIAZQBhAHIAYQBuAGMAZQAN AA0AMwAa/zIAMAAgAHAAbQAJAEIAcgBlAGEAawANAA0AQQByAHQAcwAgAGEAbgBkACAAQwB1AGwA dAB1AHIAZQBzAA0ADQBDAGgAYQBpAHIAIABEAGEAbgBhACAAQwBoAGUAbgBnACwAIABQAGgALgBE AA0ADQAzABr/MwAwACAAcABtAAkAQwBoAHUAbgBtAGEAbgAgAEcAYQBvAAz/UAByAG8AZgBlAHMA cwBvAHIAIABvAGYAIABDAGgAZQBtAGkAYwBhAGwAIABFAG4AZwBpAG4AZQBlAHIAaQBuAGcALAAg AFQAcwBpAG4AZwBoAHUAYQAgAFUAbgBpAHYAZQByAHMAaQB0AHkALAAgAEIAZQBpAGoAaQBuAGcA LAAgAEMAaABpAG4AYQAsACAAHCBFAGQAdQBjAGEAdABpAG8AbgAgAGkAbgAgAEYAdQB0AHUAcgBl AB0gKABDAGgAaQBuAGUAcwBlACwAIABjAGEAbgAgAGIAZQAgAHIAZQBwAGwAYQBjAGUAZAAgAGkA ZgAgAHQAaABlAHIAZQAgAGkAcwAgAGEAIABiAGUAdAB0AGUAcgAgAG8AbgBlACkADQANADMAGv81 ADAAIABwAG0ACQAgAEwAbwByAHIAYQBpAG4AZQAgAEsAYQBiAGEAYwBpAG4AcwBrAGkALAAgAE0A LgAgAFMALgAsACAASABvAGwAaQBzAHQAaQBjACAASABlAGEAbAB0AGgAIABQAHIAYQBjAHQAaQB0 AGkAbwBuAGUAcgAsACAAHCBLAGEAcgBtAGEAGSBzACAAUgBvAGwAZQAgAGkAbgAgAEkAbABsAG4A ZQBzAHMAIABhAG4AZAAgAEMAbwBuAHQAZQBtAHAAbwByAGEAcgB5ACAAUABhAHIAYQBkAGkAZwBt AHMAIABmAG8AcgAgAEEAdAB0AGEAaQBuAGkAbgBnACAATwBwAHQAaQBtAHUAbQAgAEgAZQBhAGwA dABoAB0gDQANADQAGv8xADAAIABwAG0ACQBDAHUAaQB5AGkAbgBnACAAWgBoAGEAbgBnAAz/QQBy AHQAaQBzAHQALAAgAEEAdQBzAHQAcgBhAGwAaQBhACwAIAAcIEEAcgB0ACAAbwBmACAAQwBoAGkA bgBlAHMAZQAgAFAAYQBpAG4AdABpAG4AZwAgAGEAbgBkACAAQwB1AGwAdABpAHYAYQB0AGkAbwBu AB0gDQANADQAIAA6ACAAMwAwACAAcABtAAkAQwBsAG8AcwBpAG4AZwAgAFIAZQBtAGEAcgBrAHMA DQAMAA0ADQANAA0ADQAxAHMAdAAgAFcAbwByAGwAZAAgAEMAbwBuAGcAcgBlAHMAcwAgAG8AZgAg AEYAdQB0AHUAcgBlACAAUwBjAGkAZQBuAGMAZQAgAGEAbgBkACAAQwB1AGwAdAB1AHIAZQANACAA DQBSAGUAZwBpAHMAdAByAGEAdABpAG8AbgAgAEYAbwByAG0ADQAoAFQAaABlAHIAZQAgAGkAcwAg AG4AbwAgAHIAZQBnAGkAcwB0AHIAYQB0AGkAbwBuACAAZgBlAGUAIABmAG8AcgAgAHQAaABlACAA YwBvAG4AZgBlAHIAZQBuAGMAZQAgAGIAdQB0ACAAYQBsAGwAIABwAGFydGljaXBhbnRzIGFyZSBy ZXNwb25zaWJsZSBmb3IgdGhlaXIgb3duIHRyYXZlbCwgbG9kZ2luZywgYW5kIGluY2lkZW50YWwg ZXhwZW5zZXMuKQ0gDVRvcCBvZiBGb3JtIDENE1BSSVZBVEUBFUZpcnN0IE5hbWUHTGFzdCBuYW1l B1RpdGxlIChNci4sIE1zLiwgRHIuLCBQcm9mKSAHBwcHBwcNWW91ciBhZmZpbGlhdGlvbiAob3B0 aW9uYWwpOg0LDRNQUklWQVRFARVDaXR5B1Byb3ZpbmNlB0NvdW50cnkgBwcTUFJJVkFURQEVBwcH Bw1FbWFpbDoNUGhvbmUgKE9wdGlvbmFsKToNRmF4IChPcHRpb25hbCk6DVBvc3RhbCBhZGRyZXNz IChPcHRpb25hbCk6DQ0NSWYgeW91IG5lZWQgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgY29uZmVyZW5jZSwgcGxlYXNlIHdyaXRlIGRvd24geW91ciByZXF1ZXN0IGFuZCBzZW5kIGl0 IGFsb25nIHdpdGggdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIHRvOiANDUZpcnN0IFdvcmxkIENvbmdy ZXNzIG9mIEZ1dHVyZSBTY2llbmNlIGFuZCBDdWx0dXJlDTEgTWFnZGFsZW5lIENsb3NlLCBMb25n c3RhbnRvbiwgQ2FtYnJpZGdlIENCNCA1RUcsIFVuaXRlZCBLaW5nZG9tDQ1BbHRlcm5hdGl2ZWx5 LCB5b3UgY2FuIHJlZ2lzdGVyIGJ5IHNlbmRpbmcgYW4gZW1haWwgdG86IBMgSFlQRVJMSU5LICJt YWlsdG86ZnNjX2NvbmdyZXNzQGhvdG1haWwuY29tIiABFGZzY19jb25ncmVzc0Bob3RtYWlsLmNv bRUuDQ0IDQ0TUEFHRSAgFDEVDQ0NE1BBR0UgIBQxFQ0NDQ0NDQ0NDUZpcnN0IFdvcmxkIENvbmdy ZXNzIG9mIEZ1dHVyZSBTY2llbmNlIGFuZCBDdWx0dXJlDU1hcmNoIDktMTAsIDIwMDIsIENhbWJy aWRnZSwgVW5pdGVkIEtpbmdkb20NDQENDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAQQAAAIEAAADBAAAPAQAAKMF AAAzBwAANQcAADwHAAA+BwAAgQkAAMYJAADHCQAARgoAAEgKAACeCgAAoAoAAKQKAACmCgAAqAoA ANgKAADaCgAA3goAADALAAAyCwAANAsAAGoLAABsCwAAcAsAAHILAAB6CwAAngsAAKALAAC8CwAA vgsAAMALAADCCwAA8AsAAPILAAAcDAAA0gwAANQMAAB+DgAAgA4AADwPAAD06uTh2uHW4dbh0crR v8rRyrG/qKG/ypO/qL/K4QCQAIkAh32HAIcAdQB1AAAAAAAAAAAAAAAPUEoEAG1ICQhvKAFzSAkI EjUIgVBKBABtSAkIbygBc0gJCAADNQiBDUIqAENKGABwaAAAAP8EUEoDAAAbAgiBA2rpAAAABggB Q0oUAE9KAgBRSgIAVQgBDDBKDwBDShYAUEoEAAAQMEoPAENKFABPSgIAUUoCAAAbAgiBA2oAAAAA BggBQ0oUAE9KAgBRSgIAVQgBFQNqAAAAAENKFABPSgIAUUoCAFUIAQxDShQAT0oCAFFKAgAACENK FgBQSgQAAAdDShYASCoBDENKFgBPSgAAUUoAAAAEQ0oWAAALNQiBT0oDAFFKAwATNQiBT0oDAFFK AwBtSAkIc0gJCBY1CIFPSgMAUUoDAG1ICQhvKAFzSAkILAAEAAABBAAAAgQAAAMEAAAdBAAAHgQA ACAEAAA6BAAAPAQAAKMFAAClBQAAEAgAABEIAABFCQAARgkAALEJAACzCQAAxAkAAMUJAADGCQAA yQkAANYJAABGCgAAoAoAANoKAABuCwAAcgsAAHYLAAB4CwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABEQAAAQAAAAQAAAMkAWEkAQAcAAQAAMIiAADgIgAA5SIAAEkjAAD+/v7+ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQR4CwAAegsAAJ4LAACgCwAAvAsAAL4LAADw CwAA8gsAABwMAAAeDAAAzgwAANAMAAB6DgAAfA4AADwPAAA+DwAAVBAAAFYQAAA2EQAAOBEAAFYR AABYEQAAiBEAAIoRAAAYEgAAGhIAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADz AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA6QAAAAAA AAAAAAAAAPMAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAANsAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAAPhKAFEYRg+jckADgkAEgkAF6EoAVghGD6AAkAAA+EoAURhGD6XoSg BWCEYPoGAAA3JAA4JABIJAAAAQEAAAECAAABAAAAGTwPAABCDwAARA8AAFAPAABWEAAAWhAAAFwQ AACEEAAAiBAAAJAQAAA8EQAAPhEAAFgRAACKEQAAHhIAACASAABEEgAARhIAAFYSAABYEgAAdBIA AHYSAABEEwAARhMAAFITAAC8FAAAzBQAANAUAADcFAAA4BQAAAgVAABIFQAA6BUAAOoVAAAQFgAA EhYAAJwWAAA6FwAAPBcAAEYYAABIGAAA1BgAANYYAAD6GAAAUhkAAOwZAADuGQAAMBsAADIbAABM GwAAchsAAHwbAAB+GwAAnhsAAKAbAACkGwAAphsAAMgbAADKGwAAWhwAAPAcAADyHAAAAB0AABYe AAAYHgAAHB4AAB4eAABEHgAARh4AAGweAAD2HgAA/h4AAAIfAABkHwAAZh8AAGgfAAD67foA+u36 5N367frW+u367frd+u367foA+t363frW+u367d367frd+u363frt+u361vrW+tb67frt3frt+gDR +u367d36AMrGwr8AAAAEQ0oWAAAHNQiBQ0oWAAc1CIFDShwADENKFgBtSAkIc0gJCAAJQioCcGgA AP8ADDUIgUIqAXBoAAAAAAANQioBUEoEAHBoAAAAABBCKgFQSgQAbygBcGgAAAAAABhCKgFQSgQA bUgJCG8oAXBoAAAAAHNICQgACUIqAXBoAAAAAABLGhIAAG4SAABwEgAAPhMAAEATAAA8FAAAPhQA ALwUAAC+FAAAwBQAAMIUAADEFAAAxhQAAMgUAAAGFQAACBUAAEwVAABOFQAA5BUAAOYVAAA2FwAA OBcAANAYAADSGAAA6BkAAOoZAAAsGwAALhsAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA6wAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADrAAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAOAAAPhKAFEYRg+jck ADgkAEgkAF6EoAVghGD6BgAANyQAOCQASCQAABsuGwAAShsAAEwbAABwGwAAchsAAKAbAACiGwAA 7BwAAO4cAAAYHgAAGh4AAMAeAADCHgAA9h4AAPoeAAD8HgAA/h4AAAAfAAACHwAAZB8AAGgfAACM HwAAVSAAAFcgAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAA AAAAANsAAAAAAAAAAAAAAADWAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADS AAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARcAAAEE AAAEAAADJAFhJAEAAQAADgAAD4RkBRGEnPo3JAA4JABIJABehGQFYISc+g4AAA+EoAURhGD6NyQA OCQASCQAXoSgBWCEYPoGAAA3JAA4JABIJAAAF2gfAACgHwAAxh8AAFUgAABWIAAAVyAAAGUgAABm IAAAbSAAAG4gAABvIAAAoiAAAKMgAADGIAAAxyAAAM4gAADPIAAA0CAAAOggAADpIAAA8CAAAPEg AADyIAAAyCEAAD4iAAB1IgAAdiIAAHciAACkIgAApSIAAKYiAAC+IgAAvyIAAMEiAADCIgAAwyIA AMUiAADGIgAAzCIAAM0iAADOIgAAzyIAANAiAADSIgAA0yIAANkiAADaIgAA2yIAANwiAADdIgAA 5SIAABgjAABFIwAAAP0A+fbv5uLY5vbi9ubizub25uLE5vbCAMK7wrG7rbvC9qIAm5ibkJuYAJuY m5CbmACHAAAAAAAAABA1CIFCKg9DShwAcGiAgIAAAA8wShQAbUgABG5IAAR1CAEEMEoUAAANA2oA AAAAMEoUAFUIARQDagAAAABVCAFtSAAEbkgABHUIAQAHMEoPADUIgRICCIEDarYGAAAGCAE1CIFV CAEADANqAAAAADUIgVUIAQADNQiBEwIIgQNqFAUAAAYIAUNKFgBVCAETAgiBA2pyAwAABggBQ0oW AFUIARMCCIEDatABAAAGCAFDShYAVQgBBwIIgUNKFgAQAgiBA2oAAAAAQ0oWAFUIAQAMQ0oWAE9K AABRSgAAAARDShYAAAc1CIFDShYABENKGAA0VyAAAGUgAAB6IAAAhCAAAKEgAACiIAAAoyAAAKQg AAClIAAApiAAAKcgAADEIAAAxiAAANUgAADeIAAA5yAAAOggAADzIAAA9CAAAPkAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAACkEAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAApAAAAAAAAAAAAAAAAKIAAAAAAAAA AAAAAACiAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAKQ4AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAE8AABYkARckAUlmAQAAAAjWRgADCAArCkATJh6ABiMKAAAAAAAAAAAAAAAA AAAAAIAGFQkAAAAAAAAAAAAAAAAAAAAAgAbmCgAAAAAAAAAAAAAAAAAAAAAU9gEAABrWDAAAAP8A AAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA/2H2AxAA BgAAFiQBSWYBAAAAAAUWABOkZAAUpGQAABL0IAAA9SAAAPYgAAD3IAAA/iAAABAhAAAgIQAAOyEA ADwhAAA9IQAAxyEAAMghAAD7IQAAPSIAAD4iAADBIgAAwiIAAMQiAADFIgAA+QAAAAAAAAAAAAAA AKoAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAACoAAAA AAAAAAAAAAAAqAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAqAAAAAAAAAAA AAAAAKgAAAAAAAAAAAAAAACiAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAKIAAAAAAAAAAAAAAACi AAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABEgAGEgANxgYC4BDAIQAAAQAATwAAFiQBFyQBSWYBAAAACNZGAAMIACsKQBMmHoAGIwoA AAAAAAAAAAAAAAAAAAAAgAYVCQAAAAAAAAAAAAAAAAAAAACABuYKAAAAAAAAAAAAAAAAAAAAABT2 AQAAGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAA AP8AAAD/YfYDEAAGAAAWJAFJZgEAAAAAEsUiAADQIgAA0SIAANIiAADdIgAA3iIAAN8iAADgIgAA 4SIAAOIiAADjIgAA5CIAAOUiAAAYIwAARCMAAEUjAABHIwAASCMAAEkjAABKIwAA9gAAAAAAAAAA AAAAAPAAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADu AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAA AAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOQAAAAAAAAAAAAA AADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA3gAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAYSAA3GBgLgEMAhAAAEAQADJAFhJAEABAAAAyQBYSQBAAEAAAAFEwAOhGgB XYRoAQAIEwAYhPj/GYQBABsmYCMkAgATRSMAAEYjAABJIwAASiMAAPcA9AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE Q0oWAAAPA2qdBwAANQiBPioBVQgBAAMgADGQaAEfsNAvILDgPSGwCAcisAgHI5CgBSSQoAUlsAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAOkAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAA ABoAAABmAHMAYwBfAGMAbwBuAGcAcgBlAHMAcwBAAGgAbwB0AG0AYQBpAGwALgBjAG8AbQANAAAA 4Mnqefm6zhGMggCqAEupC0AAAABtAGEAaQBsAHQAbwA6AGYAcwBjAF8AYwBvAG4AZwByAGUAcwBz AEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAAAA5wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA AAAXAAAAHAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBmAHMAYwAtAGMAbwBuAGcAcgBlAHMAcwAu AG8AcgBnAAAA4Mnqefm6zhGMggCqAEupCzoAAABoAHQAdABwADoALwAvAHcAdwB3AC4AZgBzAGMA LQBjAG8AbgBnAHIAZQBzAHMALgBvAHIAZwAvAAAAogEAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgMAGgIAAAAAAU4BAAAA AAAAAAIAAgACAAEAAAAAAPAeAQAAABoAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAwiQOAAMlDgAbAAAAKyUOABwAAAAjCgAAIwoAAIwAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAcAQAAFQkAABUJAACMAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAIAAOYK AADmCgAAjAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsBAACoJQ4AHAMAACMKAAAjCgAA1AYA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwEAAAVCQAAFQkAANQGAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAcBQAA5goAAOYKAADUBgAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKIBAABEAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAgIDABoCAAAAAAFOAQAAAAAAAAACAAIAAgABAAAAAADwHgEAAAAaAQAAAAAAAAAAAAAAAAAA AAAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPwmDgAfJw4AGwIAAD0nDgAcBgAAIwoAACMK AACMAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAcAABUJAAAVCQAAjAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABwIAADmCgAA5goAAIwAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAwAA sCcOABwJAAAjCgAAIwoAANQGAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcCgAAFQkAABUJAADU BgAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAsAAOYKAADmCgAA1AYAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACiAQAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAwAaAgAAAAABTgEAAAAAAAAAAgACAAIAAQAAAAAA8B4B AAAAGgEAAAAAAAAAAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAD8Jg4AHycO ABsCAAA9Jw4AHAYAACMKAAAjCgAAjAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwHAAAVCQAA FQkAAIwAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcCAAA5goAAOYKAACMAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAGwMAALAnDgAcCQAAIwoAACMKAADUBgAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAHAoAABUJAAAVCQAA1AYAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwLAADmCgAA5goA ANQGAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEup CwIAAAAXAAAAGQAAAGYAcwBjAF8AYwBvAG4AZwByAGUAcwBzAEAAaABvAHQAbQBhAGkAbAAuAGMA bwBtAAAA4Mnqefm6zhGMggCqAEupC0AAAABtAGEAaQBsAHQAbwA6AGYAcwBjAF8AYwBvAG4AZwBy AGUAcwBzAEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAAAAuwwAAEQAZACAAD4AAAAAAAAAAAAAAAAA AAAAAIAHogNpA2kDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwVAAAALIECvAI AAAAAQQAAAAKAABjAAvwMAAAAARBAQAAAAXBDAAAAAYBAgAAAIEBEQAAEL8BAAAQAP8BAAAIAGwA bwBnAG8AMQAAAAAAEPAEAAAAAAAAwmIAB/ATDAAABgaGdSvcXhwaajwGQxOK+Yt1/wDvCwAAAQAA AOEHAAAAAKkCAG4e8OcLAACGdSvcXhwaajwGQxOK+Yt1/4lQTkcNChoKAAAADUlIRFIAAACAAAAA PggDAAAA1CDj/AAAAwBQTFRFAAAAMwAAZgAAmQAAzAAA/wAAADMAMzMAZjMAmTMAzDMA/zMAAGYA M2YAZmYAmWYAzGYA/2YAAJkAM5kAZpkAmZkAzJkA/5kAAMwAM8wAZswAmcwAzMwA/8wAAP8AM/8A Zv8Amf8AzP8A//8AAAAzMwAzZgAzmQAzzAAz/wAzADMzMzMzZjMzmTMzzDMz/zMzAGYzM2YzZmYz mWYzzGYz/2YzAJkzM5kzZpkzmZkzzJkz/5kzAMwzM8wzZswzmcwzzMwz/8wzAP8zM/8zZv8zmf8z zP8z//8zAABmMwBmZgBmmQBmzABm/wBmADNmMzNmZjNmmTNmzDNm/zNmAGZmM2ZmZmZmmWZmzGZm /2ZmAJlmM5lmZplmmZlmzJlm/5lmAMxmM8xmZsxmmcxmzMxm/8xmAP9mM/9mZv9mmf9mzP9m//9m AACZMwCZZgCZmQCZzACZ/wCZADOZMzOZZjOZmTOZzDOZ/zOZAGaZM2aZZmaZmWaZzGaZ/2aZAJmZ M5mZZpmZmZmZzJmZ/5mZAMyZM8yZZsyZmcyZzMyZ/8yZAP+ZM/+ZZv+Zmf+ZzP+Z//+ZAADMMwDM ZgDMmQDMzADM/wDMADPMMzPMZjPMmTPMzDPM/zPMAGbMM2bMZmbMmWbMzGbM/2bMAJnMM5nMZpnM mZnMzJnM/5nMAMzMM8zMZszMmczMzMzM/8zMAP/MM//MZv/Mmf/MzP/M///MAAD/MwD/ZgD/mQD/ zAD//wD/ADP/MzP/ZjP/mTP/zDP//zP/AGb/M2b/Zmb/mWb/zGb//2b/AJn/M5n/Zpn/mZn/zJn/ /5n/AMz/M8z/Zsz/mcz/zMz//8z/AP//M///Zv//mf//zP//////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3jnFswAAAAFiS0dE 15CyWj8AAAiESURBVHiczZk9b+JYF8dHClNRpQkNNE+Dmx03W+02IAHTeIo4xeCG0UjLY4+2D8Xa W/hCgSjmMywjxUSaW1lKpACPggZRZJpQ+es855zra18bQ5jsy+zlJY65vud3/ufFl+RF9J3Hi2de t338+rBOHg+P2+0/B/C4Xi9vC8Zy/fAMim8E2D4ktm9uFzficbOAXxKIvxHg8SExvlgs5nKs5vMF Phbxh9/GcDyA9B18BqN39zA29Izf5vcAshBSrI+PxbEAsfM3YPte2NzgUww6Jo671VwwLI9FOA7g IRZ+viLX0eh082l6DY/hpxm8z+D3jVACI4IMX77+ZQDS/OpuFRu/Ho5Gk/9ObDkm9mg0HM2mqAZG YyUQjlHhaYDtMnZeuD6djSbvbdtpOW0cH+i93XIc27Eno+G1gLhbUU4ekY5PApD7mPNofgq+g3G0 3el0GvCodRqv8WenA+cc0GI4EsG4o0A8nQpPAKTuC+Undgt87jSa1UatUq3IAceNJmCAIqADyYDJ cIwIhwEehXkSfzoa2g56Xq3VKpXTcrn8Eh/0Vi6fnlYAqFkFBqdlj4afEGGOCF/+BMCa5BfiD0dk vlFtVsB04SifVmpnjdedNqoAGXm/uSMRDobhEMA6Mb/5fQLmIeq1ymlsTWcW4xye8GLM0hMGiEYH GSgX7qlBPj4PYBnLv9l8GjpOC7SvVMh33WIF0zkTEGVICcwGqIkZIiDBgUTYD5DID4WH7jcqFeE5 378as2QoGiTCDCtyfpBgL8AXNL+i5Ju02p1mlcwX+p5liBGqTRDBHmJXQIK9ebAPYI19HxvfdGK3 2xB7FN864LyCgKGAXAARPmAmYEHuz4M9AJh/ZH82QvVrmHp6xnwoXsoPBQFVgGxEguE11eNeDYoB 0P8Fph+WPiQfuq+Kn5rNHsnBrUQEm1JxvljefgPAQ2yfwi/k17PmE7thjkQVoUwiOO+R4G5xuzwa YEu3PgAYUvqdZtzPuRzmBEgZRCaQBkPMg8Xt+lgArD/0/9p2oPjQvox+mLzCyFNkD3NMNEQYUAMq x/lNYTEWACxl/aP/tUom+8LEaugNAqFXBi5UNGBEUGu0RUMoTsRdAEwAtH/93mlD8yml4Q+l/GRj 4HoAZrxhbo4uTBBYGgWoRijGgjTYAcAb4Gq+uZ9OwD51H656mK7veV7gXnjem4EUyB2E8ac7USCC eVEa7ACIAGw2I7vVaSr2YwdT9wIcAwjEFROCsIDFyZBGQRA0oB+IYtztR3kAEQBqAKL+1e6jrAz6 BsFVEHiIcRW5IEdwtU0mJRMt7MuQBg6VwuLmf08BiA64maL9n8tK/Qnfw7Cu1TVNMzQjuOIB53/w Ledbb+AGfLvlsg5SUK5jP6BExKa82KmEHMBaBGA6sqEAoACtxH78ZpimZ5oXhmeygI8D7vPoM+cg /9eLS89LrScIgqDagaZMlZDPwyzANm6Bw0mbEkDpf5RfsGzJdV3P1UqejzsR2I+EIQ+9PwLX0y5l MwrVYuQyDSZYCTt5mAXAe/Ad3oFa7eZZLgHkMOuez5imXQTj3sfxL7/2+x/HASTgpWcYpquIJQeL 08BGAmhHhwBIAKyAXACEU3FoTQ2Sz4AGMO7j49f+R8b8wGOXhmFo9Vc4L3tvioPQnohmkM2CDMBD nAHUgsuZG5A63Isrpplds0/m+/1fgMBl7sB8gwTbKMr0Q9mPsCWjBLksyABgCQgBXlfKmRuwqgAQ mAE3PQ8I+h2MQb/HIAcM7VIzfOUemQyLKgEkGO4WggogBZi0qAXkBEgXPdGMV5oBafCu3zsp/QhC jF3fM0yoED+dqRDIPBT9MPtNQQVYowBQAvaHRi3fglJV355AHzBNc+Ca2kmpbho/jftd5g8wBlfK dHVYL0uiFDELsmmoAsge4PwnV4LxqhSCt/VSXTNMz33nD0AH89z7qfdu7FpQnL/xZF7WfiKBI3qB GgMFALswNMFrKIGzSnYLprYXv35i/GC4XT4eXxqvzAsGjQkao1YvvY3knFzXTgrBoUpcqK1AAUgi 0G5iCu4IEEnPAOGkdFKv++zcMMY933K7l6apmerE3KBCaFbb9nU+BgqAEECkoNoDpEfqTeaz7+N2 xO+N/XG37vpd85wnE3cFiCLaIjY6zpDSUIlBCrAVXZBS8DQfgXTtzMqu7/dYr6vsmCK1XJVBaVgr iEEKgEWITQD3QQURKNhyQVN0fbd3bn5W5uQbcTxkM5r8Tnv0IgCRArgRqhXVQCQbjFriptl16+65 Yj4skJ8GxuCsCa1gs4EtehHAUqQA1MDPxREgG7ke5/9mdv10z1TovBi6aAUOAMC+JN2dpgCiC4zs D9U9KRCl+sp+i2Mr8/6gAJAE2stKs9GyZ9lOoAKgAsN9KZDzMsyAFH45yg5KgjPYns6wEAsAHulG BFshvA/oF4fsqzJkvpPstR5hMyyVMAtt2pmlWfic/xcUfBcLD1s/MJ73D4s0DlH4pO9/B8AuzncF +FPjXwDAdBhxL+HFf3+zkr9N6VbBhMJhUS+FS+W1XGdF6yOAxXB/H8FLt8QBPpWlmCUJmVytaMPO lQs5AXBdt+DyeHHGdLazPgIwAADXcC6+wCL8ilaFMnCScVyL5kQoWASOwSHOYHiC/nxG88Ed+JhU Fexoi6ZyWpHFx2J9K1bAigHETJqASyGxCAGsBmc4TrPwNBeqoEOM5nGah2LiEz+zBACPAydmI24M INdHAI5a5QAsoQwCWHQMZ8gXiwSLZ6GW4oRwF61zFrspFUi8VgGYXD8B0C2SF+DBXwSAF4ulxTMW RUf4Z0kAvEjOI3ViALpEZIJO6tGajC6Xx/F1L0A5oR8oiCpGyEXnuBCAfnLMP3jHJ6NJkZjO6HMe ySU4/Qk9Ysq1YgYTp3lyHH/23fvA/wFDaXstvvCcBwAAAABJRU5ErkJgggAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAUABgACgABAGkADwADAAAAAwAAAAAAPAAAQPH/AgA8AAwABgBOAG8AcgBtAGEA bAAAAAIAAAAcAENKGABfSAEEYUoYAG1ICQRuSAQIc0gJBHRIBAhAAAFAAQACAEAADAAJAEgAZQBh AGQAaQBuAGcAIAAxAAAACAABAAYkAUAmABMANQiBQioPQ0oSAFwIgXBomZmZAAA2AAJAAQACADYA DAAJAEgAZQBhAGQAaQBuAGcAIAAyAAAACAACAAYkAUAmAQoANQiBUEoAAHUIADQAAwABAAIANAAM AAkASABlAGEAZABpAG4AZwAgADMAAAAIAAMABiQBQCYCBwA1CIFDShYAADYABEABAAIANgAMAAkA SABlAGEAZABpAG4AZwAgADQAAAAOAAQAAyQBBiQBQCYDYSQBAwA1CIEAAAAAAAAAAAAAADwAQUDy /6EAPAAMARYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAA AAAAAAAAAAAuAFVAogDxAC4ADAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAADAA+KgFCKgJwaAAA/wBE AEMAAQACAUQADAAQAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAAAAKABAAEYTQAmCE 0AIIAE9KAwBRSgMAegD+TwEAEgF6AAwACgBIAFQATQBMACAAhJhIUTxoD18WUwAANwARAA3GMgAQ lAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAABwAQ0oUAE9K BQBQSgUAUUoFAF5KBQBhShQAdEgJBCwAH0ABACIBLAAMAAYASABlAGEAZABlAHIAAAANABIADcYI AALgEMAhAQIAAAAsACBAAQAyASwADAAGAEYAbwBvAHQAZQByAAAADQATAA3GCAAC4BDAIQECAAAA JgApQKIAQQEmAAwACwBQAGEAZwBlACAATgB1AG0AYgBlAHIAAAAAAFIA/g/x/wIAUgAOAAYAegAt AJd6U0+VXuiQAAAOABUAAyQBJGQCAwEAYSQBJgA8CIFDShAAT0oCAFBKAABRSgIAX0gBBGgIAG1I CQRzSAkEdEgJBFIA/k/x/wIAUgAOAAYAegAtAJd6U092mOiQAAAOABYAAyQBJmQCAwEAYSQBJgA8 CIFDShAAT0oCAFBKAABRSgIAX0gBBGgIAG1ICQRzSAkEdEgJBC4AQkABAHIBLgAMAAkAQgBvAGQA eQAgAFQAZQB4AHQAAAACABcABwA1CIFDShYAAAAAAAABAAAAAgAAAAMAAAAEAAAAShQAAP////8A AAAAAQD/////AAAAAAAAAAAAAAAAAQAAAAEA/////wAAAAAAAAAAAQAAAAIAAAABAP////8AAAAA AAAAAAIAAAADAAAAAQD/////AAAAAAAAAAADAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAC AAAAAwAAAAQAAAAHAAAAAAAAAAAIAQAAAAAIAgAAAAAIAwAAAAAI//8AAAAAAAAAAGAAAABjAAAA ShQAAAEAAAAAAAAAAAD/////CgQAAAAAAAABAAAAAAAAAAAA/////wkEAAAAAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAABgAAAAYwAAAGYAAAAAAAAAAAgBAAAAAAj//wAAAAAAAAAAShQAAAUA AEIAAAAA/////wAAAAABAAAAAgAAAAMAAAAdAAAAHgAAACAAAAA6AAAAPAAAAKMBAAClAQAAEAQA ABEEAABFBQAARgUAALEFAACzBQAAxAUAAMUFAADGBQAAyQUAANYFAAAjBgAAUAYAAG0GAAC3BgAA uQYAALsGAAD4BgAA+QYAAA4HAAAPBwAAZwcAAGgHAAA9CAAAPggAAJ4IAACfCAAAKgkAACsJAACb CQAAnAkAAKsJAACsCQAAxAkAAMUJAAAMCgAADQoAADcKAAA4CgAAnwoAAKAKAAAeCwAAHwsAAF4L AABfCwAAYAsAAGELAABiCwAAYwsAAGQLAACDCwAAhAsAAKYLAACnCwAA8gsAAPMLAACbDAAAnAwA AGgNAABpDQAA9A0AAPUNAACWDgAAlw4AAKUOAACmDgAAuA4AALkOAADQDgAA0Q4AAHYPAAB3DwAA DBAAAA0QAABgEAAAYRAAAHsQAAB9EAAAfhAAAH8QAACAEAAAgRAAALIQAAC0EAAAxhAAAFURAABX EQAAZREAAHoRAACEEQAAoREAAKIRAACjEQAApBEAAKURAACmEQAApxEAAMQRAADGEQAA1REAAN4R AADnEQAA6BEAAPMRAAD0EQAA9REAAPYRAAD3EQAA/hEAABASAAAgEgAAOxIAADwSAAA9EgAAxxIA AMgSAAD7EgAAPRMAAD4TAADBEwAAwhMAAMQTAADFEwAA0BMAANETAADSEwAA3RMAAN4TAADgEwAA 4RMAAOITAADjEwAA5BMAAOUTAAAYFAAARBQAAEUUAABHFAAASBQAAEsUAACYAAAAAAAAAAAAAAAA gAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAA AICYAAAAAAAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaAAAAADAAAAAAAAAAgAAAAICY AAAAAAAAAAAAAAAAgAAAAICYAAAAEQAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAA AAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAA AAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAA AAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAA gAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAA AICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgKIGAACYAAAA AAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAA AAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAA AAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAA gKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIG AACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACY AAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAA AAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAA AAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAA AAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAA gKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIG AACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACY AAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAADAAAAAAAAAAgAAAAICYQAAA AAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAAAAA AAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAA AAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAA gKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIG AACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACY QAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAA AAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAA AAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAA AAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAAA4AAAABAAAAAAAAAAAgKIGAACYAAAAFwAAAAAAAAAA gIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAAFgAAAAAAAAAAgIYQAACpAAAAAAAAAAAAAAAAgIYQ AACpAAAAAAAAAAAAAAAAgIYQAACpAAAAAAAAAAAAAAAAgIYQAACcAAAAAAAAAAAAAAAAgAAAAICp AAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICZAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgIYQAACYAAAAAAAA AAAAAAAAgIYQAACpAAAAAAAAAAAAAAAAgIYQAACpAAAAAAAAAAAAAAAAgIYQAACpAAAAAAAAAAAA AAAAgIYQAACcAAAAAAAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAA gAAAAICpAAAAADAAAAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAAAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACY AAAAAAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAA AAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAAEgAAAAAAAAAAgIYQAACYAAAAEgAA AAAAAAAAgIYQAACYAAAAEgAAAAAAAAAAgAAAAICYAAAAEgAAAAAAAAAAgAAAAICYAAAAEjAAAAAA AAAAgAAAAICYAAAAEgAAAAAAAAAAgAAAAICYQAAAAAAAAAAAAAAAgAAAAICYQAAAEwAAAAAAAAAA gAAAAICYQAAAEwAAAAAAAAAAgAAAAICYQAAAAAAAAAAAAAAAgAAAAICaQAAAEzAAAAAAAAAAgAAA AICYQAAAEzAAAAAAAAAAgAAAAIAKAAAAAAAAAAAAAAAAAAAAAACYAAAAAAAAAAAAAAAAgAAAAICY AAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAA AAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAIAIAAAAAQAAAAAAAAAAgAAAAICYAAAAAAAA AAAAAAAAgDMAAACYAAAAAAAAAAAAAAAAgDMAAACYAAAAAAAAAAAAAAAAgDMAAACaAAAAAAAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAQAAAAHQAAAB0AAAAd AAAAIAAAAAAEAAA8DwAAaB8AAEUjAABKIwAAFQAAABkAAAAcAAAAIAAAAAAEAAB4CwAAGhIAAC4b AABXIAAA9CAAAMUiAABKIwAAFgAAABgAAAAaAAAAGwAAAB0AAAAeAAAAHwAAAAAEAABJIwAAFwAA ACMGAABTBgAAbQYAAG4GAACZBgAAtQYAAHYTAAClEwAAvhMAAEoUAAATWBT/FYATWBT/FYATWBT/ FYQDAAAACgAAAAwAAAAQAAAAFwAAABkAAAAgAAAAEyF0/5WAEyF0/5WACgAAAP//////////AAAA AAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAP////////// AAAAAAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAP////// ////AAAAAAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAP// ////////AAAAAAAAAAAAAAAADwAA8EAAAAAAAAbwIAAAAAIMAAADAAAAIQAAAAIAAAABAAAADAAA AAIAAAAWAAAAQAAe8RAAAAD/////lpaWAICAgAD3AAAQAA8AAvCSAAAAIAAI8AgAAAABAAAAFQgA AA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAA DwAE8EIAAAASAArwCAAAAAEIAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/ AwEAAQAAABHwBAAAAAEAAAABDwAC8FYCAAAQAAjwCAAAAAYAAAALBAAADwAD8D4CAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAAPwBgIAAA8ABPBoAAAA AQAJ8BAAAAAIBwAAhAMAAHwpAAC8BwAAAgAK8AgAAAAHBAAAAQIAABMAC/AGAAAAiAMAAAAAMwAi 8RIAAACQAwIAAACSAwIAAAC/AwAAAIAAABDwBAAAAAAAAAAAABHwBAAAAAEAAAAPAAPwJgEAAA8A BPBaAAAAAQAJ8BAAAAC8BwAAhAMAAMgoAAC8BwAAAgAK8AgAAAAIBAAAAwIAABMAC/AGAAAAiAMA AAAAAAAP8BAAAAC8BwAAhAMAAMgoAAC8BwAAAAAR8AQAAAABAAAADwAE8FoAAACiDArwCAAAAAkE AAACCgAAMwAL8BIAAACAAAAAAgC/AQAAEAD/AQAACAAAAA/wEAAAALwHAACEAwAAdw8AAE4HAAAA ABHwBAAAAAEAAAAAAA3wBAAAAAAAAgAPAATwWgAAAKIMCvAIAAAACgQAAAIKAAAzAAvwEgAAAIAA AAABAL8BAAAQAP8BAAAIAAAAD/AQAAAAxA4AADgEAADIKAAAvAcAAAAAEfAEAAAAAQAAAAAADfAE AAAAAAABAA8ABPBgAAAAQgEK8AgAAAALBAAAAgoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAA wAGWlpYAywFqSgAA/wEYABgAAAAP8BAAAAAIBwAAvAcAAHwpAAC8BwAAAAAR8AQAAAABAAAAShQA AAAAAAAgAAAABwQAAAAAAAC0AAAAdCIAAOwEAAB0AAAAAAAAAAAA1wEAANwBAADdAQAA4QEAAKoC AACvAgAAsAIAALQCAADMBQAA0gUAANYFAADiBQAA4AYAAOEGAABpBwAAagcAAHEHAAB1BwAAdgcA AHoHAAD2BwAAAQgAAAcIAAAMCAAAPwgAAEAIAAChCAAAoggAAA8JAAAUCQAALQkAAC4JAAA1CQAA PQkAAD4JAABCCQAAngkAAJ8JAADMCQAA0QkAANIJAADWCQAA2AkAANwJAAAPCgAAEAoAACIKAAAj CgAAOgoAADsKAABBCgAARgoAAEcKAABLCgAAogoAAKMKAACpCgAArwoAALAKAAC5CgAALgsAADUL AAA2CwAAPAsAAD8LAABECwAARQsAAEkLAACuCwAAtAsAAPQLAAD1CwAA/wsAAAUMAAAIDAAACQwA AJ0MAACeDAAApAwAAKkMAACqDAAArQwAAGoNAABrDQAAcQ0AAHcNAAB4DQAAew0AAH0NAACBDQAA 9g0AAPcNAAD9DQAAAQ4AAF0OAABiDgAAmA4AAJkOAADLDgAAzw4AANIOAADTDgAA2Q4AAOAOAADh DgAA5A4AAOUOAAAIDwAAEA8AAHgPAAB5DwAAiQ8AAJMPAAAOEAAADxAAABUQAAAcEAAAIhAAACMQ AADCEwAA3xMAAOATAADlEwAASxQAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABQAHAAUABwAc AAcAHAAHABwABwAcAAcABQAHAAUABwAcAAcABQAHABwABwAcAAcABQAHABwABwAcAAcAHAAHAAUA BwAFAAcABQAHABwABwAcAAcABQAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAFAAcAHAAH AAUABwAFAAcAHAAHABwABwAFAAcAHAAHABwABwAcAAcABQAHABwABwAcAAcABQAHABwABwAFAAcA HAAHABwABQAHABwABwAFAAcAHAAHAAUABwAcAAcABQAHAAcAAgAHAAcAAAAAAOMDAADmAwAA5AYA AOYGAABjBwAAZgcAAG0HAABvBwAAQwgAAEUIAAClCAAApwgAAKIJAACkCQAACAoAAAsKAAATCgAA FQoAAD4KAABACgAApgoAAKgKAAB4DQAAew0AAGEQAABkEAAAwhMAAN8TAADgEwAA5RMAAEsUAAAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAHAAIA BwAHAAAAAAAeAAAAHgAAACgAAAAuAAAAwRMAAMITAADSEwAA3BMAAEsUAAADAAQAAwAEAAMABwAC AAcAAgD//xQAAAABAC4AAAAGAGwAYQB6AGwAaQBzAAAAAQAuADoAQwA6AFwAUAByAG8AZwByAGEA bQAgAEYAaQBsAGUAcwBcAEEATwBMACAANwAuADAAYQBcAGQAbwB3AG4AbABvAGEAZABcAEkAbgB2 AGkAdABhAHQAaQBvAG4ARgBTAEMAQwBmAGkAbgBhAGwALgBkAG8AYwABAC4AVwBDADoAXABXAEkA TgBEAE8AVwBTAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBz AG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8A ZgAgAEkAbgB2AGkAdABhAHQAaQBvAG4ARgBTAEMAQwBmAGkAbgBhAGwALgBhAHMAZAABAC4AOgBD ADoAXABQAHIAbwBnAHIAYQBtACAARgBpAGwAZQBzAFwAQQBPAEwAIAA3AC4AMABhAFwAZABvAHcA bgBsAG8AYQBkAFwASQBuAHYAaQB0AGEAdABpAG8AbgBGAFMAQwBDAGYAaQBuAGEAbAAuAGQAbwBj AAEALgA6AEMAOgBcAFAAcgBvAGcAcgBhAG0AIABGAGkAbABlAHMAXABBAE8ATAAgADcALgAwAGEA XABkAG8AdwBuAGwAbwBhAGQAXABJAG4AdgBpAHQAYQB0AGkAbwBuAEYAUwBDAEMAZgBpAG4AYQBs AC4AZABvAGMAAQAuADoAQwA6AFwAUAByAG8AZwByAGEAbQAgAEYAaQBsAGUAcwBcAEEATwBMACAA NwAuADAAYQBcAGQAbwB3AG4AbABvAGEAZABcAEkAbgB2AGkAdABhAHQAaQBvAG4ARgBTAEMAQwBm AGkAbgBhAGwALgBkAG8AYwAGAHQAaQBuAGEAZAB1ACIARAA6AFwAQQBBAEEALQBEAE8AQwBcAEkA bgB2AGkAdABhAHQAaQBvAG4ARgBTAEMAQwBmAGkAbgBhAGwALgBkAG8AYwAHAG0AagBrAHgAdABz AGwATgBcAFwAVQBLAC0AQQBDAC0AVQBNAEkAUwBUAC0ARgBTADUAXABWAE8ATAAyAFwAVQBTAEUA UgBTAFwAQwBFAFwATQBKAEsAUABJAFoAVwBYAFwARgB1AHQAdQByAGUAIABjAG8AbgBnAHIAZQBz AHMAXABJAG4AdgBpAHQAYQB0AGkAbwBuAC0AUABlAHQAZQByADIALgBkAG8AYwAMAGQAZQBmAGEA dQBsAHQAIAB1AHMAZQByACgAUAA6AFwARgB1AHQAdQByAGUAIABjAG8AbgBnAHIAZQBzAHMAXABJ AG4AdgBpAHQAYQB0AGkAbwBuAC0AUABlAHQAZQByADIALgBkAG8AYwAHAMNrwyGsIpTo/w//D/8P /w//D/8P/w//D/8PAAAmE/0slEdCDv8P/w//D/8P/w//D/8P/w//DxAAXn89Mnq1xj7/D/8P/w// D/8P/w//D/8P/w8AAK9TIEfyPPpW/w//D/8P/w//D/8P/w//D/8PEABFUNFPgJFkbv8P/w//D/8P /w//D/8P/w//DwAAr0JbVZRHQg7/D/8P/w//D/8P/w//D/8P/w8QAKB6gF/y6Ppg/w//D/8P/w// D/8P/w//D/8PAAAMAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4SUAhGEbP0VxgUAAZQCBl6E lAJghGz9bygAAwAAAC4AMAABAAAAFgABAwAAAAAAAAAAAAAAAAAAAAADGAAAD4RkBRGEbP0VxgUA AWQFBl6EZAVghGz9bygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAADGAAAD4RwCBGE MP0VxgUAAXAIBl6EcAhghDD9bygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAA AxgAAA+EQAsRhDD9FcYFAAFACwZehEALYIQw/W8oAAcAAAAuAAEALgACAC4AAwABAAAAAAABAwUH CQAAAAAAAAAAAAAAAAADGAAAD4R4DxGEyPsVxgUAAXgPBl6EeA9ghMj7bygACQAAAC4AAQAuAAIA LgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4RIEhGEyPsVxgUAAUgSBl6ESBJg hMj7bygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxgA AA+EgBYRhGD6FcYFAAGAFgZehIAWYIRg+m8oAA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAB AAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4RQGRGEYPoVxgUAAVAZBl6EUBlghGD6bygADwAA AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAADGAAA D4SIHRGE+PgVxgUAAYgdBl6EiB1ghPj4bygAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4A BwAuAAgAAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY /k9KAQBRSgEAbygAAQC38AEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhKAFEYSY/hXGBQAB oAUGXoSgBWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RwCBGETP8VxgUA AXAIBl6EcAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+FcYF AAFACwZehEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY/hXG BQABEA4GXoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGETP8V xgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+ FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY /hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGE TP8VxgUAAVAZBl6EUBlghEz/AgAIAC4ACQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIR hDD9FcYFAAHQAgZehNACYIQw/W8oAAEAAAAeAAAAAAABAwAAAAAAAAAAAAAAAAAAAAADGAAAD4TQ AhGEMP0VxgUAAdACBl6E0AJghDD9bygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAD GAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAA AAAAAAAAAAAAAxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAAcAAAAuAAEALgACAC4AAwAB AAAAAAABAwUHCQAAAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7bygACQAA AC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUA ATgEBl6EOARghMj7bygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAA AAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAA0AAAAuAAEALgACAC4AAwAuAAQA LgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVg hGD6bygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAA AAAAAAADGAAAD4QIBxGE+PgVxgUAAQgHBl6ECAdghPj4bygAEQAAAC4AAQAuAAIALgADAC4ABAAu AAUALgAGAC4ABwAuAAgAAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E0AIRhJj+FcYFAAHQ AgZehNACYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhKAF EYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgUAUUoF AG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBg hJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EsBMRhJj+FcYF AAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oGAFFKBgBvKAABAKfwDQAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAAxgAAA+ElAIRhGz9FcYFAAGUAgZehJQCYIRs/W8oAAMAAAAuADAAAQAA ABYAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EZAURhGz9FcYFAAFkBQZehGQFYIRs/W8oAAMAAAAu AAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+EcAgRhDD9FcYFAAFwCAZehHAIYIQw/W8o AAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMYAAAPhEALEYQw/RXGBQABQAsG XoRAC2CEMP1vKAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAAxgAAA+E eA8RhMj7FcYFAAF4DwZehHgPYITI+28oAAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkL AAAAAAAAAAAAAAAAAxgAAA+ESBIRhMj7FcYFAAFIEgZehEgSYITI+28oAAsAAAAuAAEALgACAC4A AwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMYAAAPhIAWEYRg+hXGBQABgBYGXoSA FmCEYPpvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAA AAAAAxgAAA+EUBkRhGD6FcYFAAFQGQZehFAZYIRg+m8oAA8AAAAuAAEALgACAC4AAwAuAAQALgAF AC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+EiB0RhPj4FcYFAAGIHQZehIgd YIT4+G8oABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAAEAEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP4CAAAALgABAAAABJABAAAAAAAA AAAAaAEAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAAAAKSAQAAAAAA AAAAAGgBAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAkAEAAAAA AAAAAABoAQAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgABAAAABJABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKSAQAA AAAAAAAAAGgBAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAkAEA AAAAAAAAAABoAQAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABJAB AAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKS AQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAoAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAADAAAALgAw AAEAAAAWAAEDAAAAAAAAAAAAAAAAAAAAAAMYAAAPhKAFEYQw/RXGBQABoAUGXoSgBWCEMP1vKAAD AAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhHAIEYQw/RXGBQABcAgGXoRwCGCE MP1vKAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAAAD4RACxGEMP0VxgUA AUALBl6EQAtghDD9bygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMY AAAPhHgPEYTI+xXGBQABeA8GXoR4D2CEyPtvKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAED BQcJCwAAAAAAAAAAAAAAAAMYAAAPhEgSEYTI+xXGBQABSBIGXoRIEmCEyPtvKAALAAAALgABAC4A AgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAAAD4SAFhGEYPoVxgUAAYAW Bl6EgBZghGD6bygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAA AAAAAAAAAAMYAAAPhFAZEYRg+hXGBQABUBkGXoRQGWCEYPpvKAAPAAAALgABAC4AAgAuAAMALgAE AC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhIgdEYT4+BXGBQABiB0G XoSIHWCE+PhvKAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAHAAAAr0JbVQAA AAAAAAAAAAAAACYT/SwAAAAAAAAAAAAAAACvUyBHAAAAAAAAAAAAAAAAXn89MgAAAAAAAAAAAAAA AKB6gF8AAAAAAAAAAAAAAADDa8MhAAAAAAAAAAAAAAAARVDRTwAAAAAAAAAAAAAAAP////////// /////////////////////////////wcAAAAAAAAAAAAAAAAAAAAAAP//BwAAAAAAAAAAAAAAAAAA AAAAAAAAAFcRAABlEQAAehEAAIQRAAChEQAAohEAAKMRAACkEQAApREAAKYRAADEEQAAxhEAANUR AADeEQAA5xEAAOgRAADzEQAA9BEAAPURAAD2EQAAwhMAAN8TAADgEwAA5RMAAEsUAAABAAAAAQAA AAgAAAACAQAAAgEAAAIBAACeAQABAgEAAAIBAAACAQAAlgEAAQEAAAAIAAAAAgEAAAIBAAACAQAA ngEAAQIBAAACAQAAAgEAAJYBAAEAAAAAAQAAAAEAAAABAAAA/0ABgAEAiAEAAIgBAACczXQAAQAB AIgBAAAAAAAAiAEAAAAAAAACoAAAAAAAAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAABKFAAAUAAACABAAABQAAAKAAAAAFAAAAwAAAAAUAAADgAAAABQAAAQ AAAAAFAAABIAAAAAUAAAFAAAAABQAAAWAAAAAFAAABgAAAAAUAAAGgAAAABQAAAcAAAAAFAAAB4A AAAAUAAAQABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA //8AAAIA//8AAAAA//8AAAIA//8AAAAABwAAAEcWkAEAAAICBgMFBAUCAwSHOgAgAAAAAAAAAAAA AAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSH OgAgAAAAAAAAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA7BpABhgcCAQYAAwEBAQEBAwAAAAAA DggQAAAAAAAAAAEABAAAAAAAUwBpAG0AUwB1AG4AAACLW1NPAABFNZABhggCAQYJAwEBAQEBAQAA AAAADggQAAAAAAAAAAAABAAAAAAATQBTACAAUwBvAG4AZwAAAFMAaQBtAFMAdQBuAAAAPzWQAQAA AgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAA ADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcA cwAAACIABABxCIgYAPDQAgAAaAEAAAAA3tpiZl7bYmbz1WJGAwACAAAA2wIAAEoQAAABAAgAAAAE AAMQIgAAAL8BAAD3CQAAAQAFAAAAFQAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAIB6AFtAC0AIGBMjAAABAAGQBkAAAAGQAAAAEUAAC2CwAAAAAAANVTDLUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA 8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAABwD0gdF5ZltMdQxU wU4a/wAAAAAAAAkAUwBoAHUAIABHAHUAaQBjAGUADABkAGUAZgBhAHUAbAB0ACAAdQBzAGUAcgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAA AAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMA AADAAAAABAAAAMwAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAADAEAAAkAAAAkAQAAEgAA ADABAAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4AAAB8AQAADwAAAIQBAAAQAAAA jAEAABMAAACUAQAAAgAAAOn9AAAeAAAAFgAAAOiHtOenkeWtpueVjOWQjOS7ge+8mgBlAB4AAAAB AAAAAIe05x4AAAAKAAAAU2h1IEd1aWNlAJWMHgAAAAEAAAAAaHUgHgAAAAEAAAAAaHUgHgAAAAsA AABOb3JtYWwuZG90AIweAAAADQAAAGRlZmF1bHQgdXNlcgCQjOQeAAAAAgAAADMAZmEeAAAAEwAA AE1pY3Jvc29mdCBXb3JkIDkuMAC8QAAAAACMhkcAAAAAQAAAAADKEnEgv8EBQAAAAADsQheCv8EB QAAAAAC8y9qSv8EBAwAAAAEAAAADAAAA2wIAAAMAAABKEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAAC AAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuVAEAABABAAAMAAAAAQAAAGgA AAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAAoAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAA ABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAADyAAAAAgAAAOn9AAAeAAAAFgAAAENvbXBhcSBD b21wdXRlciBDb3JwLgAgAAMAAAAiAAAAAwAAAAgAAAADAAAAARQAAAMAAAAyEQkACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAABYAAADoh7Tnp5HlrabnlYzlkIzku4HvvJoA DBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAA5AEAAAMAAAAAAAAAIAAAAAEAAAA4AAAAAgAA AEAAAAABAAAAAgAAAAwAAABfUElEX0hMSU5LUwACAAAA6f0AAEEAAACcAQAAGAAAAAMAAAAKAAEA AwAAAAYAAAADAAAAAAAAAAMAAAAFAAAAHwAAACAAAABtAGEAaQBsAHQAbwA6AGYAcwBjAF8AYwBv AG4AZwByAGUAcwBzAEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAABgA UQADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBm AHMAYwAtAGMAbwBuAGcAcgBlAHMAcwAuAG8AcgBnAC8AAAAAAB8AAAABAAAAAAAAAAMAAAAKAAEA AwAAAAAAAAADAAAAAAAAAAMAAAAFAAAAHwAAACAAAABtAGEAaQBsAHQAbwA6AGYAcwBjAF8AYwBv AG4AZwByAGUAcwBzAEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAAAsA AAADAAAARSMAAAMAAAABBAAAAwAAAAEAAAAfAAAABgAAAGwAbwBnAG8AMQAAAB8AAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJ AAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcA AAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA/v///yMAAAAkAAAAJQAA ACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAD+////LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAA NAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABC AAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA/v///0oAAABLAAAATAAAAE0AAABOAAAATwAAAFAA AAD+////UgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAP7////9////WwAAAFwAAABqAAAA/v// /18AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAA/v////7///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAA AAAAAEYAAAAAAAAAAAAAAADw8Uz3kr/BAV4AAABAFwAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAAAFgUAAAAAAAAMQBUAGEA YgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA4AAgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtAAAA 6zcAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAGgACAQYAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAiQgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBv AG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRAAAAABAAAAAAAABNAGEAYwBy AG8AcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DgABAAIAAAAOAAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkENC95K/wQEQXkj3kr/BAQAAAAAA AAAAAAAAAFYAQgBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIAAEB//////////8JAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQQ0L3kr/B AXDXRveSv8EBAAAAAAAAAAAAAAAAZABpAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtgIAAAAAAABUAGgAaQBzAEQAbwBjAHUAbQBlAG4A dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQgAAAAKAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAB0BgAAAAAAAF8AVgBCAEEA XwBQAFIATwBKAEUAQwBUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAAAHEL AAAAAAAAUABSAE8ASgBFAEMAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABAAAgEHAAAADAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABTAAAAZwEAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAA/v///wwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAD+////JgAA ACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA NQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABD AAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEA AABSAAAA/v///1QAAABVAAAAVgAAAFcAAABYAAAA/v////7////+////XAAAAP7///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////wGysoABAAQAAAABADAqAgKQCQBwFAZIAwCCAgBk5AQEAAcAHABQ cm9qZWN0BVEAKAAAQAIUBgIUPa0CCgcCbAEUCAYSCQISgEwtVTwCAAwCShI8AgoWAAFyc3RkEG9s ZT4CGXMAdAAAZABvAGwAZVAADQBoACVeAAMqAFxHezAwMDIwsDQzMC0ACAQEQwAKAwIOARIwMDQ2 fSMAMi4wIzAjQzoAXFdJTkRPV1MAXFN5c3RlbTMAMlxTdGRPbGUAMi5UbGIjT0wARSBBdXRvbWGw dGlvbgBgAAIWAm4ATVNGb3Jtcz4EAA4ACU0AUwBGAQBGcgBtAHMALzQAfIAJcoABAUc4OQBCNDA1 MzEtNgAzNUQtMTFEMiAtQjg0QwBHQTAAQzlBMEUwMEMDGUcENC5UV0QjTQBpY3Jvc29mdIogAj4g AGIgT2IBsgAgTGlicmFyeeMAOgABMACMgAKBVwKIADkzN0JEMzUtKDEzRIJANoBAOTIBlUBURU1Q XFdvQHJkOC4wXIU+RQJYpz7hLkUNj+AAGhCFLgJgjE1EC7TBhBYAD0AkVIBlbXBsYXRlRIYYPgAe AQVAcG0AcAVAcmHAdGUAUAByFYBSakAFY8ADDgAghcAICcAAKlxDToBcBGFsCgPDp5o4AYIAw4dP ZmZpY8SHiE8AZkAAaQBjwBEoDQCQwA+GwhBHe0AyREY4RDBAYDUAQkZBLTEwMUKgLUJERTWBQ0HA hho0wAIyCGTAKmdyYQBtIEZpbGVzXAtHYAMbXIQBTVNPOWA3LkRMTMhogwYgi4BREmkPAssBABPC AQiIKBnCtVRoaXMARG9jdW1lbnSiGk4EMgAYQDFUwLuKaQCaRMBJYwB1AJ0oZQBuwEocwAYAAKpI QgExQtLjAN8eQgJFAQUsQhqKKCJCCCsFQgEQQgEAAAAAAAAAAAAAARYBAAC2AP//AQEAAAAA//// /wAAAAD///////8AADq9NwndE9YRuJIAoMmg4AwpvTcJ3RPWEbiSAKDJoOAMAAAAAAAAAAAAAAAA AAAAAAAAEAAAAAMAAAAFAAAABwAAAP//////////AQEIAAAA/////3gAAADeAAAAcwUAAAkCAAD/ ////AAAAAAEAAACIKIooAAD//6MAAACIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//8AAI8FAADWAAAA1gAAAOMFAAAAAP////8AAAAA3wD//wAAAAAMAP////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// UAAAAAIAUyL/////AAABAFMQ/////wAAAQBTIv////8AAAAAAjwQAP//AAAAAAI8FAD//wAAAAAC PBgA//8AAAAAAjwcAP//AAAAAAI8/////wAA//8BAQAAAAABADoAMQBUAGUAbQBwAGwAYQB0AGUA UAByAG8AagBlAGMAdAAuAFQAaABpAHMARABvAGMAdQBtAGUAbgB0AAAAAAAAAN8IAAAAMAAAAAEB 6AIAAAKB/v///////////ygAAAAAAP//AAAAAAAAAAD//////////wAAAAAdAAAAJAAAAGgBAACg AAAAKoAdAiAAAAA4AIQDMAAAAAMAAAA4AARAAAAAAP//////////AAAAAB0ADAAAAAAAKoAfAiAA AABAAJADYAAAAAMAAQBAAARAAQAAAP//////////uAkAAB0ADAAAAAAAKoAhAiAAAABIAJwDkAAA AAMAAgBIAARAAgAAAP//////////qAwAAGgBAAAQAAAA/////zgAAABoAAAAwAAAAAKD/v////// CAD//wABAAAAAP///////wAAAAD//////////yAAAAAdABAAJAAAAIKgEAL//////v///zABAAAC AP///v///wAAAAD//////////yAAAAAdABAAJAAAAAKD/v//////CAD//2ABAAAAAP///////wAA AAD//////////yAAAAAdABAAJAAAAP/////gAAAABgAAAP//////////gAAAAOACAADIAAAAKoAr AiAAAABcAMADgAEAAAMABwBcAARABwAAAP//////////AAABgB0ADAAAAAAAKoAtAiAAAABkAMwD sAEAAAMACABkAARACAAAAP//////////+AAAAB0ADAAAAAAAKoAvAiAAAABsANgD4AEAAAMACQBs AARACQAAAP//////////KAEAAOACAAA4AAAAuAEAAOgBAAD///////////////////////////// //84AAAAaAAAAJgAAADIAAAA+AAAACgBAAACg/7//////wgA//94AgAAAAD///////8AAAAA//// //////8EAAAAHQAQACQAAACCoBAC//////7///+oAgAAAgD///7///8AAAAA//////////8AAAAA HQAQACQAAAACg/7//////wgA///YAgAAAAD///////8AAAAA//////////8AAAAAHQAQACQAAAD/ ////GAEAAAAAAAAAAAEAAAAAAAAA////////////////AAAAAP////////////////////8AAAAA //////////8IAQAAOAEAAAAAAAAAAAAAWAAEAAAAAACoA4QD//////////////////////////// /wgABQD/////TUUAAP///////wAAAAD//wAAAAD//wEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7KAQAAAP////8BAQgAAAD/ ////eAAAAAGNsABBdHRyaWJ1dABlIFZCX05hbQBlID0gIlRoaQBzRG9jdW1lbhB0Ig0KCoxCYXMB AowxVGVtcGxhAHRlUHJvamVjBHQuGWhDcmVhdAhhYmwBckZhbHMCZQyoUHJlZGVjJGxhAAZJZACB VHICdQ0iRXhwb3NlgxQcBYtEZXJpdhUkAEN1c3RvbWl6AwSHA2MAAAAAAAAAAAAAAADMYV4AAAEA /wkEAAAJBAAA5AQBAAAAAAAAAAAAAQAGAAIAFgEqAFwARwB7ADAAMAAwADIAMAA0AEUARgAtADAA MAAwADAALQAwADAAMAAwAC0AQwAwADAAMAAtADAAMAAwADAAMAAwADAAMAAwADAANAA2AH0AIwAz AC4AMAAjADkAIwBDADoAXABQAHIAbwBnAHIAYQBtACAARgBpAGwAZQBzAFwAQwBvAG0AbQBvAG4A IABGAGkAbABlAHMAXABNAGkAYwByAG8AcwBvAGYAdAAgAFMAaABhAHIAZQBkAFwAVgBCAEEAXABW AEIAQQAzADMAMgAuAGQAbABsACMAVgBpAHMAdQBhAGwAIABCAGEAcwBpAGMAIABGAG8AcgAgAEEA cABwAGwAaQBjAGEAdABpAG8AbgBzAAAAAAAAAAAAAAAAABABKgBcAEcAewAwADAAMAAyADAAOQAw ADUALQAwADAAMAAwAC0AMAAwADAAMAAtAEMAMAAwADAALQAwADAAMAAwADAAMAAwADAAMAAwADQA NgB9ACMAOAAuADAAIwA0ADAAOQAjAEMAOgBcAFAAcgBvAGcAcgBhAG0AIABGAGkAbABlAHMAXABN AGkAYwByAG8AcwBvAGYAdAAgAE8AZgBmAGkAYwBlAFwATwBmAGYAaQBjAGUAXABNAFMAVwBPAFIA RAA4AC4ATwBMAEIAIwBNAGkAYwByAG8AcwBvAGYAdAAgAFcAbwByAGQAIAA4AC4AMAAgAE8AYgBq AGUAYwB0ACAATABpAGIAcgBhAHIAeQAAAAAAAAAAAAAAAAC8ACoAXABHAHsAMAAwADAAMgAwADQA MwAwAC0AMAAwADAAMAAtADAAMAAwADAALQBDADAAMAAwAC0AMAAwADAAMAAwADAAMAAwADAAMAA0 ADYAfQAjADIALgAwACMAMAAjAEMAOgBcAFcASQBOAEQATwBXAFMAXABTAHkAcwB0AGUAbQAzADIA XABTAHQAZABPAGwAZQAyAC4AVABsAGIAIwBPAEwARQAgAEEAdQB0AG8AbQBhAHQAaQBvAG4AAAAA AAAAAAAAAAAA5AAqAFwARwB7ADgAOQBCADQAMAA1ADMAMQAtADYAMwA1AEQALQAxADEARAAyAC0A QgA4ADQAQwAtADAAMABBADAAQwA5AEEAMABFADAAMABDAH0AIwAyAC4AMAAjADAAIwBDADoAXABX AEkATgBEAE8AVwBTAFwAUwB5AHMAdABlAG0AMwAyAFwATQBTAEYAbwByAG0AcwAuAFQAVwBEACMA TQBpAGMAcgBvAHMAbwBmAHQAIABGAG8AcgBtAHMAIAAyAC4AMAAgAE8AYgBqAGUAYwB0ACAATABp AGIAcgBhAHIAeQAAAAAAAAAAAAAAAQDcACoAXABHAHsAMAA5ADMANwBCAEQAMwA1AC0AMQAzAEQA RAAtADEAMQBEADYALQBCADgAOQAyAC0AMAAwAEEAMABDADkAQQAwAEUAMAAwAEMAfQAjADIALgAw ACMAMAAjAEMAOgBcAFQARQBNAFAAXABXAG8AcgBkADgALgAwAFwATQBTAEYAbwByAG0AcwAuAEUA WABEACMATQBpAGMAcgBvAHMAbwBmAHQAIABGAG8AcgBtAHMAIAAyAC4AMAAgAE8AYgBqAGUAYwB0 ACAATABpAGIAcgBhAHIAeQAAAAAAAAAAAAAAAgAAAOEuRQ2P4BoQhS4CYIxNC7QAABIAKgBcAEMA TgBvAHIAbQBhAGwAEgAqAFwAQwBOAG8AcgBtAGEAbADDp5o4AQAAAAAAAAAMASoAXABHAHsAMgBE AEYAOABEADAANABDAC0ANQBCAEYAQQAtADEAMAAxAEIALQBCAEQARQA1AC0AMAAwAEEAQQAwADAA NAA0AEQARQA1ADIAfQAjADIALgAwACMAMAAjAEMAOgBcAFAAcgBvAGcAcgBhAG0AIABGAGkAbABl AHMAXABNAGkAYwByAG8AcwBvAGYAdAAgAE8AZgBmAGkAYwBlAFwATwBmAGYAaQBjAGUAXABNAFMA TwA5ADcALgBEAEwATAAjAE0AaQBjAHIAbwBzAG8AZgB0ACAATwBmAGYAaQBjAGUAIAA4AC4AMAAg AE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIAeQAAAAAAAAAAAAAAAAABAAIAAwAEAgAABgIBAAgC AAAYAv///////wAAAAD//wAATC1VPAIA//////////////////////////////////////////// //////////////8AAP///////////////////////wEAAAAAAAAAAAAAAAAAAAAAAAAAiCgBABgA VABoAGkAcwBEAG8AYwB1AG0AZQBuAHQACgAxNzNjNTUzZGQyAwAqRAERAv//iigAAAAAAAAAAgAA AOMFAAD///////8BASACAAD//////////////////////////wACAAD///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////yi9NwndE9YRuJIAoMmg4Az/////AQAAAP////9gAAAAgAAAAAAAFwEY AP8AhCcAAAQEV29yZLVrEAADBFZCQffiEAAFBFdpbjE2wX4QAAUEV2luMzIHfxAAAwRNYWOzshAA KwRJbnZpdGF0aW9ubGV0dGVyX0NoaW5lc2VfZmluYWxfd2l0aCBoZWFkZXIyQ+IQAAYEc3Rkb2xl k2AQAAcATVNGb3Jtc0MPEAAMBFRoaXNEb2N1bWVudDyeEAAJgAAA/wMEAF9FdmFsdWF0ZRjZEAAP AFRlbXBsYXRlUHJvamVjdIFFEAAGhAgA/wMEAE9mZmljZRV1EAAHBFByb2plY3QtrhAACIQIAP8D AQBEb2N1bWVudGrTEAAJBEhUTUxUZXh0McpbEAAJBEhUTUxUZXh0MstbEAAJBEhUTUxUZXh0M8xb EAAJBEhUTUxUZXh0NM1bEAAJBEhUTUxUZXh0Nc5bEAAJBEhUTUxUZXh0Ns9bEAAJBEhUTUxUZXh0 N9BbEAAJBEhUTUxUZXh0ONFbEAAJBEhUTUxUZXh0OdJbEAAKBEhUTUxUZXh0MTAvQRAAAv//AQFg AAAAAAIBAP//AgIAAP//////////////////////////////////DAICAP//DgIDAP//EQIAAAgA ////////FAIEAP//FgIFAP//GAL/////////////////////////////CAAQAAAAAQASAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASUQ9InswOTM3QkQzQy0xM0RELTExRDYtQjg5 Mi0wMEEwQzlBMEUwMEN9Ig0KRG9jdW1lbnQ9VGhpc0RvY3VtZW50LyZIMDAwMDAwMDANCk5hbWU9 IlByb2plY3QiDQpIZWxwQ29udGV4dElEPSIwIg0KQ01HPSJGQ0ZFMzIzMEQyMjhENjI4RDYyOEQ2 MjhENiINCkRQQj0iRjhGQTM2QzkzN0M5MzdDOSINCkdDPSJGNEY2M0EzOENBMzVDQjM1Q0JDQSIN Cg0KW0hvc3QgRXh0ZW5kZXIgSW5mb10NCiZIMDAwMDAwMDE9ezM4MzJENjQwLUNGOTAtMTFDRi04 RTQzLTAwQTBDOTExMDA1QX07VkJFOyZIMDAwMDAwMDANCiZIMDAwMDAwMDI9ezAwMDIwOUYyLTAw MDAtMDAwMC1DMDAwLTAwMDAwMDAwMDA0Nn07V29yZDguMDsmSDAwMDAwMDAwDQoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQABAAAAGtESVcZczxGNZwCqAL3OHQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRoaXNEb2N1bWVudABUAGgAaQBzAEQAbwBjAHUAbQBlAG4A dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABG GAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1l bnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFAAUgBPAEoARQBDAFQAbABrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAUAAIB/////w0AAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAWQAAAB4AAAAAAAAAUABSAE8ASgBFAEMAVAB3AG0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABaAAAAKQAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf////8PAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFsAAABqAAAAAAAAAE8AYgBqAGUA YwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW AAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAADw8Uz3kr/BAfDxTPeSv8EBAAAAAAAA AAAAAAAA ------=_NextPart_000_0028_01C1C236.D6894F30-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 5:51: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from saruman.xwin.net (saruman.xwin.net [205.219.158.250]) by hub.freebsd.org (Postfix) with ESMTP id 6253C37B402; Tue, 5 Mar 2002 05:50:52 -0800 (PST) Received: from localhost (dp@localhost) by saruman.xwin.net (8.11.4/8.11.4) with ESMTP id g25Dq9q06906; Tue, 5 Mar 2002 07:52:09 -0600 Date: Tue, 5 Mar 2002 07:52:09 -0600 (CST) From: Paul Halliday X-X-Sender: To: Patrick Thomas Cc: , Subject: Re: cannot get more than 32 PTYs in 4.4-RELEASE In-Reply-To: <20020304233607.E3757-100000@utility.clubscholarship.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Patrick Thomas wrote: > > In my kernel, I have: > > maxusers 128 > > pseudo-device pty 128 > Not sure if the above steps are actually required. Actually, neither matter. I duplicated your steps anyway, and was greeted with the same messages. However, > In my /dev directory, I have used `sh MAKEDEV` to make all 256 /dev/pty > files. They are all there, and all have correct major/minor numbers. I > know I won't be using all 256 of them, but I just made them all anyway. I believe the above steps are wrong, looking at /dev/MAKEDEV: pty*) class=`expr $i : 'pty\(.*\)'` case $class in 0) offset=0 name=p;; 1) offset=32 name=q;; 2) offset=64 name=r;; 3) offset=96 name=s;; interestingly enough the command "./MAKEDEV pty3" will create (as indicated) heh.. I was assuming too much, something is screwy here. *confused* it actually only created 64 terminals. Added the line: 4) offset=192 name=t;; ~# ./MAKEDEV pty4 && kill -HUP 1 interesting, now I have 96, but can only use 64. Reboot.. Anyone care to take over? > > In /etc/ptys, I didn't change anything, because all 256 pty entries are > ALREADY in there: > > # Pseudo Terminals > ttyp0 none network > ttyp1 none network > ... > ttySu none network > ttySv none network > > So those are all there. > > I have used `sysctl -a | grep maxuser` to verify that maxusers is indeed > 128. > > BUT - if I log on via ssh and start screen, and start 31 new screen > windows, then nobody else can log on to the system - I cannot create any > more screen windows AND nobody else can ssh in - the machine has run out > of ptys. > > I use `fstat` to inquire, and I am maxed out at exactly 32 ptys. > > SO THE question is, why am I stuck at 32 ptys ? I have done it all - > everything that is in any doc or news post, and everything I was told to > do here and on -hackers, and yet I am still stuck at 32 !!! > > Please tell me the secret lore for getting more than 32 ptys in > 4.4-RELEASE. > > > thanks, > > PT > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Paul H. ___________________ http://dp.penix.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 6: 7:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id D273F37B405 for ; Tue, 5 Mar 2002 06:07:16 -0800 (PST) Received: (from vel@localhost) by bugz.infotecs.ru (8.11.6/8.11.4) id g25E7Cd67446 for freebsd-hackers@freebsd.org; Tue, 5 Mar 2002 17:07:12 +0300 (MSK) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200203051407.g25E7Cd67446@bugz.infotecs.ru> Subject: C vs C++ To: freebsd-hackers@freebsd.org Date: Tue, 5 Mar 2002 17:07:12 +0300 (MSK) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. I apologize for the offtopic whenever it happens, but this issue really pisses me off now. Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 6:19:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ica.net (icamail.ica.net [209.151.129.144]) by hub.freebsd.org (Postfix) with ESMTP id EF36A37B405 for ; Tue, 5 Mar 2002 06:18:58 -0800 (PST) Received: from tom.ica.net (unverified [209.151.130.21]) by mail.ica.net (Vircom SMTPRS 5.0.193) with SMTP id for ; Tue, 5 Mar 2002 09:20:13 -0500 Message-ID: From: "ICA Canada Online" To: "freebsd-hackers@freebsd.org" Date: Tue, 05 Mar 2002 09:20:14 -0500 Reply-To: "ICA Canada Online" X-Priority: 1 X-Mailer: PMMail 2000 Professional (2.20.2200) For Windows 2000 (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Help! serious problem. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. Here's the kernel panic message: Mar 5 03:04:03 predator /kernel: Mar 5 03:04:03 predator /kernel: Mar 5 03:04:03 predator /kernel: Fatal trap 12: page fault while in kernel mode Mar 5 03:04:03 predator /kernel: fault virtual address = 0x0 Mar 5 03:04:03 predator /kernel: fault code = supervisor read, page not present Mar 5 03:04:03 predator /kernel: instruction pointer = 0x8:0x0 Mar 5 03:04:03 predator /kernel: stack pointer = 0x10:0xe75d5ea8 Mar 5 03:04:03 predator /kernel: frame pointer = 0x10:0xe75d5ebc Mar 5 03:04:03 predator /kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Mar 5 03:04:03 predator /kernel: = DPL 0, pres 1, def32 1, gran 1 Mar 5 03:04:03 predator /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Mar 5 03:04:03 predator /kernel: current process = 4326 (ipfw) Mar 5 03:04:03 predator /kernel: interrupt mask = none Mar 5 03:04:03 predator /kernel: trap number = 12 Mar 5 03:04:03 predator /kernel: panic: page fault Mar 5 03:04:03 predator /kernel: Any ideas? Thanks! -------------------------------------------------- ICA Canada Online 2601 Matheson Blvd. E. Unit #29 Mississauga, Ontario L4W 5A8 (905) 624-8566 http://www.ica.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 6:37:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id BA1AF37B400; Tue, 5 Mar 2002 06:37:38 -0800 (PST) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g25EbNP16628; Tue, 5 Mar 2002 23:37:23 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: , In-Reply-To: References: <20020304233607.E3757-100000@utility.clubscholarship.com> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 10 From: Makoto Matsushita To: dp@penix.org Subject: Re: cannot get more than 32 PTYs in 4.4-RELEASE Date: Tue, 05 Mar 2002 23:37:13 +0900 Message-Id: <20020305233713L.matusita@jp.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG dp> *confused* Read , "I'm always running out of xterms because I have too many pseduo-ttys open. How can I increase my number of ptys?" article at DaemonNews. You may find an example to create more ptys with MAKEDEV. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 6:52:56 2002 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 0EC0A37B400 for ; Tue, 5 Mar 2002 06:52:54 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 5 Mar 2002 14:52:53 +0000 (GMT) Date: Tue, 5 Mar 2002 14:52:52 +0000 From: David Malone To: ICA Canada Online Cc: "freebsd-hackers@freebsd.org" Subject: Re: Help! serious problem. Message-ID: <20020305145252.GA62341@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 09:20:14AM -0500, ICA Canada Online wrote: > Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. You are probably using an out of date kernel module. Use "ls -l /modules" to check the modules were all installed at the same time as the kernel. If you are uing the trafcount module from ports then you will need to recompile that also. (You should be able to use kldstat to check which modules are loaded.) David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 6:55:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by hub.freebsd.org (Postfix) with ESMTP id E27E437B41A for ; Tue, 5 Mar 2002 06:55:33 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g25EtWH22522 for ; Tue, 5 Mar 2002 15:55:32 +0100 (CET) Received: from falcon.midgard.homeip.net (h217n1fls20o913.telia.com [212.181.162.217]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id PAA02657 for ; Tue, 5 Mar 2002 15:55:32 +0100 (CET) Received: (qmail 74036 invoked by uid 1001); 5 Mar 2002 14:55:31 -0000 Date: Tue, 5 Mar 2002 15:55:31 +0100 From: Erik Trulsson To: "Eugene L. Vorokov" Cc: freebsd-hackers@freebsd.org Subject: Re: C vs C++ Message-ID: <20020305145531.GA73995@student.uu.se> Mail-Followup-To: "Eugene L. Vorokov" , freebsd-hackers@freebsd.org References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203051407.g25E7Cd67446@bugz.infotecs.ru> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 05:07:12PM +0300, Eugene L. Vorokov wrote: > Hello, > > I have a small problem. I work for software development company and > write daemons and console tools for Unix. My boss wants everything > to be written in C++, because he thinks C++ is cool. I prefer C > for such tasks, but I cannot really put good arguments of why and > where C++ can be worse than C. I know many of you prefer C too. > Can you please explain some disadvantages of C++ comparing to C ? > Is it slower, does it produce less effective code, why is it like > that, etc ... or please direct me to some articles where this can > be explained. Properly used there are not really any disadvantages of C++ over C. Since C is (almost) a subset of C++, most C programs will work just the same when compiled as C++. Proper use of the various extra features of C++ can make programs easier to write and make them more maintainable but this requires that the programmer actually know how to use them. The main difference between C++ and C is the support for object-oriented programming. One can of course write in an object-oriented manner in almost any programming language, including C, but it is easier in languages that has direct support for it, like C++. Now, not all problems are well-suited for being solved with an object-oriented approach so in those cases the extra features of C++ won't be of much help. I suspect that for the type programs you are writing using C++ wouldn't really have any advantage over C, but it won't have any disadvantage either. Does your boss insist on you actually writing your programs in idiomatic C++ or would he be satisfied if you wrote them using a subset of C++ which is very close to C. (if the latter your programs would still look almost the same as before, while technically being written in C++.) Using something just because 'it is cool' is just about the worst reason there is of doing anything (closely followed by 'we have always done it this way' which seems to be your reason :-) .) > > I apologize for the offtopic whenever it happens, but this issue > really pisses me off now. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 7:13:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 9BD9737B402 for ; Tue, 5 Mar 2002 07:13:38 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g25FDQR19875; Tue, 5 Mar 2002 16:13:27 +0100 (MET) Date: Tue, 5 Mar 2002 16:13:26 +0100 (CET) From: Harti Brandt To: "Eugene L. Vorokov" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <200203051407.g25E7Cd67446@bugz.infotecs.ru> Message-ID: <20020305155850.R83273-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, Eugene L. Vorokov wrote: ELV>I have a small problem. I work for software development company and ELV>write daemons and console tools for Unix. My boss wants everything ELV>to be written in C++, because he thinks C++ is cool. I prefer C ELV>for such tasks, but I cannot really put good arguments of why and ELV>where C++ can be worse than C. I know many of you prefer C too. ELV>Can you please explain some disadvantages of C++ comparing to C ? ELV>Is it slower, does it produce less effective code, why is it like ELV>that, etc ... or please direct me to some articles where this can ELV>be explained. ELV> ELV>I apologize for the offtopic whenever it happens, but this issue ELV>really pisses me off now. Well there are (at least) two reasons, why I wouldn't use C++ for the type of program I suppose you are writing: 1. The machine model used by C more or less maps directly into the machines used by most computers. By looking at a statement you can more or less guess what the compiler will do. In C++ this is not the case for (at least) two features: exceptions and virtual methods. Both of these features have an overhead, that cannot be estimated in advance. You can of course not use these features. 2. C++ turns out to be harder to read except it is extremly good written. This stems from several features of the language: a) operator overloading. Seeing a '+' doesn't mean that something is added. It may even actuall be a subtraction. It may be an assignment (a once popular GUI library used '+' to add dialog elements to the window on the left side of the '+'). b) function overloading. In C it is simple to lookup a function when you find it called in a program. In C++ you have first to lookup the argument types. If these are objects, you have also to find out the entire inheritance hierarchy. Then you have a quite complicated ruleset to find out, what function is really called. c) hidden function calls all over the places. You never know, whether a statement does something simple or call a lot of functions. 'a = b' can invoke dozens of constructors and other functions you are not aware of. Also there were rumours that C++ is less efficient because the resulting object code tends to consist of many small functions scattered all over the address space calling each other. This may badly hit cache performance. Well, the main problem with this type of question is that the choice of language depends on the problem you try to solve. For number crunching Fortran may still be the language of choice, for GUI programming surely it is C++ (or objc or java, you name it), for inetd it is probably C. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 7:24:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id F3C1D37B402 for ; Tue, 5 Mar 2002 07:24:30 -0800 (PST) Received: (qmail 3580 invoked from network); 5 Mar 2002 15:24:26 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 15:24:26 -0000 Date: Tue, 5 Mar 2002 10:24:26 -0500 (EST) From: Kenneth Culver To: Geoff Mohler Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 4.5-RELEASE upgrade..didnt?? In-Reply-To: Message-ID: <20020305102402.L3576-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG did u do a config -r on your kernel config file? if not it might not pick up some of the new stuff. Ken On Mon, 4 Mar 2002, Geoff Mohler wrote: > Ok..dumb question alert. (fair warning) > > I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded > as well. > > Went in, and did a make on my config file from 4.3..and rebooted (made > sure the new kernel was in / as well). > > Uname reports a 4.3 system..etc..etc..etc. > > What'd I miss? > > > 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 Mar 5 7:24:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id E00C137B405; Tue, 5 Mar 2002 07:24:27 -0800 (PST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id g25FONF45980; Tue, 5 Mar 2002 10:24:23 -0500 (EST) (envelope-from bicknell) Date: Tue, 5 Mar 2002 10:24:23 -0500 From: Leo Bicknell To: Paul Halliday Cc: Patrick Thomas , freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: cannot get more than 32 PTYs in 4.4-RELEASE Message-ID: <20020305152423.GA45816@ussenterprise.ufp.org> Mail-Followup-To: Paul Halliday , Patrick Thomas , freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG References: <20020304233607.E3757-100000@utility.clubscholarship.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In a message written on Tue, Mar 05, 2002 at 07:52:09AM -0600, Paul Halliday wrote: > pty*) > class=`expr $i : 'pty\(.*\)'` > case $class in > 0) offset=0 name=p;; > 1) offset=32 name=q;; > 2) offset=64 name=r;; > 3) offset=96 name=s;; > > interestingly enough the command "./MAKEDEV pty3" will create (as > indicated) heh.. I was assuming too much, something is screwy here. > > *confused* > > it actually only created 64 terminals. Added the line: > > 4) offset=192 name=t;; > > ~# ./MAKEDEV pty4 && kill -HUP 1 > > interesting, now I have 96, but can only use 64. Reboot.. I think if you look at a more recent MAKEDEV, you'll find your answer: pty*) class=`expr $i : 'pty\(.*\)'` case $class in 0) offset=0 name=p;; 1) offset=32 name=q;; 2) offset=64 name=r;; 3) offset=96 name=s;; # Note that xterm (at least) only look at p-s. 4) offset=128 name=P;; 5) offset=160 name=Q;; 6) offset=192 name=R;; 7) offset=224 name=S;; # This still leaves [tuTU]. So: sh MAKEDEV pty0 # 0-31 sh MAKEDEV pty1 # 32-63 sh MAKEDEV pty2 # 64-95 sh MAKEDEV pty3 # 96-127 sh MAKEDEV pty4 # 128-159 xterm won't recognize by default sh MAKEDEV pty5 # 160-191 xterm won't recognize by default sh MAKEDEV pty6 # 192-223 xterm won't recognize by default sh MAKEDEV pty7 # 224-255 xterm won't recognize by default It's fairly trival to patch xterm to look for additional letters. It may have made it in the XFree source already. *shrug* -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 7:34:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id BC8AE37B400 for ; Tue, 5 Mar 2002 07:34:19 -0800 (PST) Received: (qmail 3638 invoked from network); 5 Mar 2002 15:34:15 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 15:34:15 -0000 Date: Tue, 5 Mar 2002 10:34:15 -0500 (EST) From: Kenneth Culver To: "Eugene L. Vorokov" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <200203051407.g25E7Cd67446@bugz.infotecs.ru> Message-ID: <20020305102829.A3576-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I have a small problem. I work for software development company and > write daemons and console tools for Unix. My boss wants everything to be > written in C++, because he thinks C++ is cool. I prefer C for such > tasks, but I cannot really put good arguments of why and where C++ can > be worse than C. I know many of you prefer C too. Can you please explain > some disadvantages of C++ comparing to C ? Is it slower, does it produce > less effective code, why is it like that, etc ... or please direct me to > some articles where this can be explained. My main problem with C++ is that it adds a lot of overhead, and it's slow. Also, it drives me nuts when people code in C++ and write all kinds of classes when using classes for certain things just doesn't make sense, and makes the code much more convoluted. Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 7:54:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 950E837B416 for ; Tue, 5 Mar 2002 07:52:23 -0800 (PST) Received: (qmail 25636 invoked from network); 5 Mar 2002 15:52:13 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.137.49]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Mar 2002 15:52:13 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g25Fq0G57090; Tue, 5 Mar 2002 10:52:00 -0500 (EST) (envelope-from jhb@FreeBSD.org) 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: <3C84974D.37F683BD@FreeBSD.org> Date: Tue, 05 Mar 2002 10:51:48 -0500 (EST) From: John Baldwin To: Maxim Sobolev Subject: RE: Extending loader(8) for loading kerels/modules split across Cc: re@FreeBSD.org, audit@FreeBSD.org, hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 05-Mar-02 Maxim Sobolev wrote: > Hi folks, > > Please review attached patch, which adds long overdue feature to our > loader(8), allowing it to load sequence of files as a single object. > This should allow us to lift 1.44M limit on compressed kernel for the > installation diskette. Please note, that to use this feature to load > gzip-compressed objects you need to split the object first and then > compress each piece individually, not compress first and then split > already compressed file. Therefore tight fitting of each piece to the > 1.44M limit could be a little tricky, but not impossible. Other way > around is to use kgzip(8) utility to compress kernel and then split it > into pieces 1.44M each. > > If there are no objections I would like to commit it ASAP, so that our > RE team is able to use this feature in the forthcoming 5.0-DP1 > release. > > Any feedback is appreciated. Looks good to me I guess. :) Do you have an example loader.conf that can be used on the floppies to demonstrate it? > -Maxim -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 8:20:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by hub.freebsd.org (Postfix) with ESMTP id 1159637B416 for ; Tue, 5 Mar 2002 08:20:54 -0800 (PST) Received: from [193.170.124.123] (helo=klumpert) by smtp.web.de with smtp (WEB.DE(Exim) 4.29 #47) id 16iHgJ-0006cR-00 for freebsd-hackers@FreeBSD.ORG; Tue, 05 Mar 2002 17:20:51 +0100 Message-ID: <001701c1c461$a5b21db0$df02110a@klumpert> From: "Martin Ankerl" To: References: <20020305102829.A3576-100000@alpha.yumyumyum.org> Subject: Re: C vs C++ Date: Tue, 5 Mar 2002 17:20:14 +0100 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > My main problem with C++ is that it adds a lot of overhead, and it's slow. Well written C++ code can be very fast, have a look at http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html and http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html and http://www.oonumerics.org/blitz/ Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 8:28: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (law2-f145.hotmail.com [216.32.181.145]) by hub.freebsd.org (Postfix) with ESMTP id 9B10537B405 for ; Tue, 5 Mar 2002 08:28:05 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Mar 2002 08:28:05 -0800 Received: from 63.67.30.193 by lw2fd.hotmail.msn.com with HTTP; Tue, 05 Mar 2002 16:28:05 GMT X-Originating-IP: [63.67.30.193] From: "Kenneth Mays" To: vel@bugz.infotecs.ru, freebsd-hackers@freebsd.org Subject: Re: C vs C++ Date: Tue, 05 Mar 2002 11:28:05 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Mar 2002 16:28:05.0530 (UTC) FILETIME=[BA58B7A0:01C1C462] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Honestly, there are differences but both are tools to get the job done. Why you use both are really up to you since it depends if your shop wants object oriented programming for maintenance and troubleshooting. I had this happen when dealing with Ada vs. C++ vs. C. The programmers didn't want to use Ada because it wasn't cool or practical. Reality was that many of them didn't know how to program in Ada but had college knowledge on C and no training on object oriented programming. Same happened when C++ became popular. Fact is, managers may understand that the code in C++ is easier to read and maintain. There are reasons to use C++ because of the software engineering methodology and beliefs of its superioriy of C. If that real or not is up to you and the rest of the world. Ken Mays _________________________________________________________________ Join the world抯 largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 8:30:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from speedracer.speedtoys.com (mail.speedtoys.com [66.80.10.170]) by hub.freebsd.org (Postfix) with ESMTP id 0DEC037B402 for ; Tue, 5 Mar 2002 08:30:50 -0800 (PST) Received: from localhost (gemohler@localhost) by speedracer.speedtoys.com (8.11.6/8.11.1) with ESMTP id g25GXKK28149; Tue, 5 Mar 2002 08:33:20 -0800 (PST) Date: Tue, 5 Mar 2002 08:33:20 -0800 (PST) From: Geoff Mohler X-Sender: gemohler@speedracer.speedtoys.com To: Kenneth Culver Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 4.5-RELEASE upgrade..didnt?? In-Reply-To: <20020305102402.L3576-100000@alpha.yumyumyum.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG No, I didnt. Thanks! Will do that and report back. On Tue, 5 Mar 2002, Kenneth Culver wrote: > did u do a config -r on your kernel config file? if not it might not pick > up some of the new stuff. > > Ken > > On Mon, 4 Mar 2002, Geoff Mohler wrote: > > > Ok..dumb question alert. (fair warning) > > > > I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded > > as well. > > > > Went in, and did a make on my config file from 4.3..and rebooted (made > > sure the new kernel was in / as well). > > > > Uname reports a 4.3 system..etc..etc..etc. > > > > What'd I miss? > > > > > > 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 > --- Geoff Mohler To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 8:31:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 22A7037B400 for ; Tue, 5 Mar 2002 08:31:06 -0800 (PST) Received: (qmail 4021 invoked from network); 5 Mar 2002 16:31:01 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 16:31:01 -0000 Date: Tue, 5 Mar 2002 11:31:01 -0500 (EST) From: Kenneth Culver To: Martin Ankerl Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <001701c1c461$a5b21db0$df02110a@klumpert> Message-ID: <20020305113039.W3994-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The code itself may be fast, but programs written in c++ tend to link to a lot of shared libs, which in itself can be pretty slow. Ken On Tue, 5 Mar 2002, Martin Ankerl wrote: > > My main problem with C++ is that it adds a lot of overhead, and it's slow. > > Well written C++ code can be very fast, have a look at > http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html > and > http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html > and > http://www.oonumerics.org/blitz/ > > > Martin > > > > 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 Mar 5 8:37:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 1737237B400 for ; Tue, 5 Mar 2002 08:37:30 -0800 (PST) Received: from dhcp206.mis.earthlink.net ([207.217.66.246] helo=DROID) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 16iHwE-00010Q-00; Tue, 05 Mar 2002 08:37:18 -0800 Message-ID: <001201c1c464$06416fd0$f642d9cf@DROID> From: "Steve B." To: "Eugene L. Vorokov" , References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> Subject: Re: C vs C++ Date: Tue, 5 Mar 2002 08:37:21 -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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. Second is size, C will generate smaller executables. C++ to do its things adds overhead that increases the size of the object files. Steve B. ----- Original Message ----- From: "Eugene L. Vorokov" To: Sent: Tuesday, March 05, 2002 6:07 AM Subject: C vs C++ > Hello, > > I have a small problem. I work for software development company and > write daemons and console tools for Unix. My boss wants everything > to be written in C++, because he thinks C++ is cool. I prefer C > for such tasks, but I cannot really put good arguments of why and > where C++ can be worse than C. I know many of you prefer C too. > Can you please explain some disadvantages of C++ comparing to C ? > Is it slower, does it produce less effective code, why is it like > that, etc ... or please direct me to some articles where this can > be explained. > > I apologize for the offtopic whenever it happens, but this issue > really pisses me off now. > > Regards, > Eugene > > > 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 Mar 5 8:41:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from tepid.osl.fast.no (tepid.osl.fast.no [213.188.9.130]) by hub.freebsd.org (Postfix) with ESMTP id 02DF837B402 for ; Tue, 5 Mar 2002 08:41:04 -0800 (PST) Received: from raw.grenland.fast.no.fast.no (raw.grenland.fast.no [192.168.48.104]) by tepid.osl.fast.no (8.9.3/8.9.1) with ESMTP id RAA56607; Tue, 5 Mar 2002 17:40:51 +0100 (CET) (envelope-from Raymond.Wiker@fast.no) From: Raymond Wiker MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15492.62736.239246.919734@raw.grenland.fast.no> Date: Tue, 5 Mar 2002 17:40:48 +0100 To: Kenneth Culver Cc: Martin Ankerl , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <20020305113039.W3994-100000@alpha.yumyumyum.org> References: <001701c1c461$a5b21db0$df02110a@klumpert> <20020305113039.W3994-100000@alpha.yumyumyum.org> X-Mailer: VM 7.00 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kenneth Culver writes: > The code itself may be fast, but programs written in c++ tend to link to a > lot of shared libs, which in itself can be pretty slow. That's *not* unique to C++. On my machine, /usr/lib contains 73 shared libs, and these are mainly C libraries. If you want arguments against C++, try any of these: C++ programs use a *lot* of header files, and these do in general cause more work for the compiler than do the C header files. This boils down to noticeably longer compile times. C++ is a *much* larger language, with *much* more complicated semantics and behaviour. A large proportion of C++ programmers do not know the language well enough that they should be allowed to program in it. -- Raymond Wiker Mail: Raymond.Wiker@fast.no Senior Software Engineer Web: http://www.fast.no/ Fast Search & Transfer ASA Phone: +47 23 01 11 60 P.O. Box 1677 Vika Fax: +47 35 54 87 99 NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 Try FAST Search: http://alltheweb.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 8:48:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from speedracer.speedtoys.com (mail.speedtoys.com [66.80.10.170]) by hub.freebsd.org (Postfix) with ESMTP id 0EFBF37B402 for ; Tue, 5 Mar 2002 08:48:39 -0800 (PST) Received: from localhost (gemohler@localhost) by speedracer.speedtoys.com (8.11.6/8.11.1) with ESMTP id g25Gp1400428; Tue, 5 Mar 2002 08:51:07 -0800 (PST) Date: Tue, 5 Mar 2002 08:51:01 -0800 (PST) From: Geoff Mohler X-Sender: gemohler@speedracer.speedtoys.com To: Kenneth Culver Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 4.5-RELEASE upgrade..didnt?? In-Reply-To: <20020305102402.L3576-100000@alpha.yumyumyum.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG No, still have this from uname -a: 4.3-RELEASE FreeBSD 4.3-RELEASE #3: On Tue, 5 Mar 2002, Kenneth Culver wrote: > did u do a config -r on your kernel config file? if not it might not pick > up some of the new stuff. > > Ken > > On Mon, 4 Mar 2002, Geoff Mohler wrote: > > > Ok..dumb question alert. (fair warning) > > > > I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded > > as well. > > > > Went in, and did a make on my config file from 4.3..and rebooted (made > > sure the new kernel was in / as well). > > > > Uname reports a 4.3 system..etc..etc..etc. > > > > What'd I miss? > > > > > > 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 > --- Geoff Mohler To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 8:49:18 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by hub.freebsd.org (Postfix) with ESMTP id 94AB837B402 for ; Tue, 5 Mar 2002 08:49:12 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 11:48:07 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 530B5BA03; Tue, 5 Mar 2002 11:47:31 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: "Kenneth Mays" , vel@bugz.infotecs.ru, freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ Date: Tue, 5 Mar 2002 11:47:31 -0500 X-Mailer: KMail [version 1.3] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020305164731.530B5BA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 05 March 2002 11:28 am, Kenneth Mays wrote: > > Fact is, managers may understand that the code in C++ is easier to read and > maintain. This I must disagree with. Most of the time, I think that C++ is harder to read *and* maintain. Well-written C++ is probably easier to read and maintain, but it's harder to write C++ well, and just telling everybody to switch compilers won't help at all -- it's likely to obfuscate the code more. If you want the benefits you've got to re-train everybody to use C++ *well*, which doesn't seem to be what was being suggested in this case. Besides, it's not C++ that provides whatever questionable benefits it provides; it's OO methodology which can come in handy, and there are more elegant OO solutions than C++ around. > There are reasons to use C++ because of the software engineering > methodology and beliefs of its superioriy of C. If that real or not is up > to you and the rest of the world. > > Ken Mays > > > _________________________________________________________________ > Join the world抯 largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 8:49:37 2002 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 6B10937B400 for ; Tue, 5 Mar 2002 08:49:30 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g25GnPi77727; Tue, 5 Mar 2002 09:49:25 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g25GnNL76760; Tue, 5 Mar 2002 09:49:23 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Mar 2002 09:49:27 -0700 (MST) Message-Id: <20020305.094927.40858673.imp@village.org> To: culverk@alpha.yumyumyum.org Cc: vel@bugz.infotecs.ru, freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ From: "M. Warner Losh" In-Reply-To: <20020305102829.A3576-100000@alpha.yumyumyum.org> References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> <20020305102829.A3576-100000@alpha.yumyumyum.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020305102829.A3576-100000@alpha.yumyumyum.org> Kenneth Culver writes: : > I have a small problem. I work for software development company and : > write daemons and console tools for Unix. My boss wants everything to be : > written in C++, because he thinks C++ is cool. I prefer C for such : > tasks, but I cannot really put good arguments of why and where C++ can : > be worse than C. I know many of you prefer C too. Can you please explain : > some disadvantages of C++ comparing to C ? Is it slower, does it produce : > less effective code, why is it like that, etc ... or please direct me to : > some articles where this can be explained. : : My main problem with C++ is that it adds a lot of overhead, and it's slow. : Also, it drives me nuts when people code in C++ and write all kinds of : classes when using classes for certain things just doesn't make sense, and : makes the code much more convoluted. C++ doesn't add noticable overhead and isn't slow, unless you are a dumbass about how you write it. All languages give you plenty of ways to write speghetti fortran code :-). C++ gives you a number of ways to obfuscate. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 8:53:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dns.pacang.com (adsl-63-193-245-242.dsl.snfc21.pacbell.net [63.193.245.242]) by hub.freebsd.org (Postfix) with ESMTP id 0850F37B416 for ; Tue, 5 Mar 2002 08:53:11 -0800 (PST) Received: (from bservies@localhost) by dns.pacang.com (8.9.3/8.9.2) id IAA27191; Tue, 5 Mar 2002 08:52:53 -0800 Date: Tue, 5 Mar 2002 08:52:53 -0800 From: Byron Servies To: "Steve B." Cc: "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ Message-ID: <20020305085253.A27065@pacang.com> References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> <001201c1c464$06416fd0$f642d9cf@DROID> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001201c1c464$06416fd0$f642d9cf@DROID>; from steveb99@earthlink.net on Tue, Mar 05, 2002 at 08:37:21AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On March 05, 2002 at 08:37, Steve B. wrote: > I take a simplistic view after years of C++. > > C++ is good for large projects that need to be maintained into the future. > Then the advantages of OO starts to kick in. For small projects that won't > change much then C is the better choice IMO. My 2 cents, Design first. In my experience the language used is largely irrelevant until the skill set of the people implementing the project are taken into account. With a good design you can match the requirements of the project to the skills of the people. The language and approach (OO, procedural, data driven, etc.) will usually be obvious at that point. Naturally, political issues will come into play, too. Just remember the old saw: you can write bad fortran in any language. It is up to the implementer to structure the software for maintainability, regardless of the language used. Byron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 9: 9:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id B5AC137B400; Tue, 5 Mar 2002 09:09:02 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id TAA27722; Tue, 5 Mar 2002 19:08:57 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h73.227.dialup.iptcom.net [212.9.227.73]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id TAA24544; Tue, 5 Mar 2002 19:08:54 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id g25H7TB04366; Tue, 5 Mar 2002 19:07:29 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C84FB80.A609FD3E@FreeBSD.org> Date: Tue, 05 Mar 2002 19:08:16 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: John Baldwin Cc: re@FreeBSD.org, audit@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 05-Mar-02 Maxim Sobolev wrote: > > Hi folks, > > > > Please review attached patch, which adds long overdue feature to our > > loader(8), allowing it to load sequence of files as a single object. > > This should allow us to lift 1.44M limit on compressed kernel for the > > installation diskette. Please note, that to use this feature to load > > gzip-compressed objects you need to split the object first and then > > compress each piece individually, not compress first and then split > > already compressed file. Therefore tight fitting of each piece to the > > 1.44M limit could be a little tricky, but not impossible. Other way > > around is to use kgzip(8) utility to compress kernel and then split it > > into pieces 1.44M each. > > > > If there are no objections I would like to commit it ASAP, so that our > > RE team is able to use this feature in the forthcoming 5.0-DP1 > > release. > > > > Any feedback is appreciated. > > Looks good to me I guess. :) Do you have an example loader.conf that can be > used on the floppies to demonstrate it? You probably meant loader.rc? Very simple: load -n3 /kernel /kernel.1 /kernel.2 This will load kernel out of 3 pieces - they could be either /kernel, /kernel.1 and /kernel.2 or /kernel.gz, /kernel.1.gz and /kernel.2.gz or any combination of those. Just as an example I've split stock kern.flp image from 4.5-RELEASE into two images - they could be downloaded from http://people.freebsd.org/~sobomax/kern.flp.bz2 and http://people.freebsd.org/~sobomax/kern1.flp.bz2. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 9:36: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.nentec.de (gate2.nentec.de [194.25.215.66]) by hub.freebsd.org (Postfix) with ESMTP id CA4DC37B400 for ; Tue, 5 Mar 2002 09:35:57 -0800 (PST) Received: from nenny.nentec.de (root@nenny.nentec.de [153.92.64.1]) by gate.nentec.de (8.9.3/8.9.3) with ESMTP id SAA13641; Tue, 5 Mar 2002 18:35:40 +0100 Received: from andromeda (andromeda [153.92.64.34]) by nenny.nentec.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g25HZYh20898; Tue, 5 Mar 2002 18:35:34 +0100 Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020305.094927.40858673.imp@village.org> Date: Tue, 05 Mar 2002 18:35:37 +0100 (MET) Reply-To: Andy Sporner Organization: NENTEC Netywerktechnologie GmbH From: Andy Sporner To: "M. Warner Losh" Subject: Re: C vs C++ Cc: freebsd-hackers@FreeBSD.ORG, vel@bugz.infotecs.ru, culverk@alpha.yumyumyum.org X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > C++ doesn't add noticable overhead and isn't slow, unless you are a > dumbass about how you write it. All languages give you plenty of ways > to write speghetti fortran code :-). C++ gives you a number of ways > to obfuscate. > I hate to enter such a fray, but I can pass on my experience working with a group of engineers porting an application. This was about 6 years ago, so perhaps they cleared up the semantics of the problem I describe. We had a revenue management application which ran very well on an HP-9000/G70 (a dual process PA-RISC machine). We moved it to an 18 processor Sequent machine and it dominated the machine. After investigation we found that the application code was spending 95% of it's time in Memmove. After even more investigation there was an argument of interpretation on semantics. The HP compiler passed a pointer as a reference to an object and the Compiler from Edinburg was actually copying the object (which was not small by any means). Such problems would be easy to spot in a regular 'C' program because it would render a compiler error. The point made about having competant experience with C++ is very well noted and I think the strongest argument. So put simply, ask the boss if he want's to add risk to the project because there is perhaps a lack of adequate experience in C++. If the boss has his wits about him (???) he should take the path that would be less risky--DISPITE his own preferences (unless he want's to pay more for well trained engineers). Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 9:39:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 5F01B37B416 for ; Tue, 5 Mar 2002 09:39:17 -0800 (PST) Received: from pool0452.cvx40-bradley.dialup.earthlink.net ([216.244.43.197] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iItz-0005mg-00; Tue, 05 Mar 2002 09:39:03 -0800 Message-ID: <3C8502A8.66C174D7@mindspring.com> Date: Tue, 05 Mar 2002 09:38:48 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Eugene L. Vorokov" Cc: freebsd-hackers@freebsd.org Subject: Re: C vs C++ References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Eugene L. Vorokov" wrote: > I have a small problem. I work for software development company and > write daemons and console tools for Unix. My boss wants everything > to be written in C++, because he thinks C++ is cool. I prefer C > for such tasks, but I cannot really put good arguments of why and > where C++ can be worse than C. I know many of you prefer C too. > Can you please explain some disadvantages of C++ comparing to C ? > Is it slower, does it produce less effective code, why is it like > that, etc ... or please direct me to some articles where this can > be explained. > > I apologize for the offtopic whenever it happens, but this issue > really pisses me off now. One of the main disadvantages of C++ is that it requires self discipline, and object oriented programming is harder to learn. The other main disadvantage is that, if you use prototypes in your code, you can simply compile C programs with a C++ compiler, and call the code "C++". Another disadvantage is that you can reuse the code when you are done with it, so you can't get paid for writing the same code over and over again. Inheritance compounds this problem, since it means that you can't even rewrite mostly similar code over and over again, since you end up inheriting everything from the base class that was similar in the first place, and can only spend time writing the parts that are different. This makes it really hard to pad a contract properly, while allowing you to play "Quake" for hours on end. A really annoying thing about C++ is that you can't create an uninitialized object; this makes it a lot harder to get the good bugs. A really really annoying thing is private vs. public, and protected member data and functions. This makes it nearly impossible to call the wrong function from the middle of three routines up, or otherwise violate the API layering in such a way as to simplify your code considerably, even if it does break the abstration model. A good example of this is the Microsoft PAP/CHAP PPP authentication. Everyone knows that the layering violations they introduced are good things, simplifying their life immensely, at the paltry cost of all of your security. That's why the TCP-over-DNS hack works to get you free internet connectivity using the MSN 800 number without having to log in. Imagine if they had not violated the layering, and adhered to the silly "end to end" requirements the IETF normally imposes on standards on the Internet... why, there would be no free dialup Internet connectivity at Microsoft's expense today! What a poorer place this world would be! Exceptions are really a pain; they make it nearly impossible to obfuscate code with a huge number of: if( condition) { undo everything I did so far return failure; } statements. They also lead to things like single-entry, single-exit, which make it nigh impossible to hide things from ASSERTs about whether or not things are locked (sure, coders who are interested in working code instead of money can do single-entry, single-exit in C, using underhanded techniques like negative logic, but it's easy to convert such code so as to hide it's true function). Probably most unforgivably, they make you handle exceptional conditions away from the main code path, which leaves no room for order-of-magnitude improvements in gradual steps, as you remove things from the common case later, and look like a hero for doing the job you were paid to do in the first place. A royal pain is the fact that using pure virtual base classes, which can't be properly instnaced without having real member functions, means that you can't create e.g. file system modules with unimplemented members like you can with structs containing lists of function pointers, so that you can later reap the rewards of NULL pointer dereference related crashes. Probably the absolute worst, most unforgivable attribute if C++ is dynamic scoping, with automatic deconstruction; it means that if I simply declare an instance of an object as an auto variable on the stack, that when I leave the scope the object is automatically deconstructed. This is evil, in that it makes it impossible to be subtle about leaking memory: no matter how you try to hide your memory leaks, if you use this approach, they become glaringly obvious. Worse, intentional leaks using "new" with no corresponding "delete" stick out like a sore thumb, no matter how you try to hide them. About the only upside is that if you use pure virtual base classes, or templates, such that a single class instance needs to be constructed at runtime by the .init and then deconstructed by the .fini at the end of the run, you can't use the code in the kernel, because the startup doesn't call these initializers for you, like the crt0 code calls it for user space programs, so you can avoid using C++ in the kernel, if you gratuitously use these constructs, and don't tell anyone why they won't work in the kernel so that you can be told to avoid them. Sorry the news isn't brighter, but the crusade against C++ must go on! Remember! Ad nihilus per aspera! -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 9:41:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id B6DB437B416 for ; Tue, 5 Mar 2002 09:41:12 -0800 (PST) Received: from pool0452.cvx40-bradley.dialup.earthlink.net ([216.244.43.197] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iIw2-0001JB-00; Tue, 05 Mar 2002 09:41:10 -0800 Message-ID: <3C850327.6756F62F@mindspring.com> Date: Tue, 05 Mar 2002 09:40:55 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ICA Canada Online Cc: "freebsd-hackers@freebsd.org" Subject: Re: Help! serious problem. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ICA Canada Online wrote: > > Running FreeBSD 4.5 and it keeps rebooting around the same time > late during the night. > Here's the kernel panic message: [ ... ] > Any ideas? I don't see the output of the "ps" you typed at the debugger prompt to see what process was running at the time of the panic. At a guess: check your crontab. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 9:45: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 6CFA337B402 for ; Tue, 5 Mar 2002 09:44:57 -0800 (PST) Received: from pool0452.cvx40-bradley.dialup.earthlink.net ([216.244.43.197] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iIzZ-00072t-00; Tue, 05 Mar 2002 09:44:49 -0800 Message-ID: <3C850402.90DC1B54@mindspring.com> Date: Tue, 05 Mar 2002 09:44:34 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kenneth Culver Cc: "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ References: <20020305102829.A3576-100000@alpha.yumyumyum.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kenneth Culver wrote: > My main problem with C++ is that it adds a lot of overhead, and it's slow. > Also, it drives me nuts when people code in C++ and write all kinds of > classes when using classes for certain things just doesn't make sense, and > makes the code much more convoluted. This is a serious concern for console tools, which are interacting with humans, which are capable of providing commands much faster than a 1.5GHz processor can accept and dispose of them... sorry I missed this downside in my first response. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 9:46:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from scanner.secnap.net (scanner.secnap.net [216.241.67.74]) by hub.freebsd.org (Postfix) with ESMTP id 54F0C37B405 for ; Tue, 5 Mar 2002 09:46:11 -0800 (PST) Received: (from scheidell@localhost) by scanner.secnap.net (8.11.6/8.11.6) id g25Hjuh49009; Tue, 5 Mar 2002 12:45:56 -0500 (EST) (envelope-from scheidell) Message-Id: <200203051745.g25Hjuh49009@scanner.secnap.net> Subject: Re: Help! serious problem. In-Reply-To: <3C850327.6756F62F@mindspring.com> To: Terry Lambert Date: Tue, 5 Mar 2002 12:45:55 -0500 (EST) Cc: ICA Canada Online , "freebsd-hackers@freebsd.org" From: Michael Scheidell X-Loop: scheidell@secnap.net X-Mailer: ELM [version 2.4ME+ PL92 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > Running FreeBSD 4.5 and it keeps rebooting around the same time > > late during the night. had two similar problem's #1, client computer, 4:59pm every weekday, rebooted. Seems luser plugged their POSTAGE METER into same UPS as the computer 4:59pm, luser gets up and 'stamps' today's outgoing email! (massive surge, big magnets, negative neutrinos flying around) #2, 8:15am (and then 9:15am after DST change) lights in building turned on. T1 line from TELCO was shorted to house ground. House wiring was NOT grounded, so house wiring found ground through T1! (then again, check your cron also . turn on dumpdev. -- Michael Scheidell SECNAP Network Security, LLC (561) 368-9561 scheidell@secnap.net http://www.secnap.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 9:50:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 30E5C37B405 for ; Tue, 5 Mar 2002 09:50:11 -0800 (PST) Received: from pool0452.cvx40-bradley.dialup.earthlink.net ([216.244.43.197] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iJ4h-0007Xv-00; Tue, 05 Mar 2002 09:50:07 -0800 Message-ID: <3C850540.EA8EDE0F@mindspring.com> Date: Tue, 05 Mar 2002 09:49:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Steve B." Cc: "Eugene L. Vorokov" , freebsd-hackers@freebsd.org Subject: Re: C vs C++ References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> <001201c1c464$06416fd0$f642d9cf@DROID> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Steve B." wrote: > I take a simplistic view after years of C++. > > C++ is good for large projects that need to be maintained into the future. > Then the advantages of OO starts to kick in. For small projects that won't > change much then C is the better choice IMO. Wow. Forgot this disadvantage of C++, too. Yeah, it's difficult to write code that someone else couldn't come in and maintain after it was done. This means that the normal rules about "write important code and you have a job forever" no longer apply. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 10: 0:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 5BFDE37B41B for ; Tue, 5 Mar 2002 10:00:21 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305180021.TMWG1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 18:00:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA31677; Tue, 5 Mar 2002 09:56:51 -0800 (PST) Date: Tue, 5 Mar 2002 09:56:51 -0800 (PST) From: Julian Elischer To: ICA Canada Online Cc: "freebsd-hackers@freebsd.org" Subject: Re: Help! serious problem. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It actually did a jmp 0 (or call 0) do you have any out-of date modules loaded? maybe an out of date firewall module? (it happens when you are doing some firewall code) On Tue, 5 Mar 2002, ICA Canada Online wrote: > Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. > Here's the kernel panic message: > Mar 5 03:04:03 predator /kernel: > Mar 5 03:04:03 predator /kernel: > Mar 5 03:04:03 predator /kernel: Fatal trap 12: page fault while in kernel mode > Mar 5 03:04:03 predator /kernel: fault virtual address = 0x0 > Mar 5 03:04:03 predator /kernel: fault code = supervisor read, page not present > Mar 5 03:04:03 predator /kernel: instruction pointer = 0x8:0x0 > Mar 5 03:04:03 predator /kernel: stack pointer = 0x10:0xe75d5ea8 > Mar 5 03:04:03 predator /kernel: frame pointer = 0x10:0xe75d5ebc > Mar 5 03:04:03 predator /kernel: code segment = base 0x0, limit 0xfffff, type 0x1b > Mar 5 03:04:03 predator /kernel: = DPL 0, pres 1, def32 1, gran 1 > Mar 5 03:04:03 predator /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 > Mar 5 03:04:03 predator /kernel: current process = 4326 (ipfw) > Mar 5 03:04:03 predator /kernel: interrupt mask = none > Mar 5 03:04:03 predator /kernel: trap number = 12 > Mar 5 03:04:03 predator /kernel: panic: page fault > Mar 5 03:04:03 predator /kernel: > > Any ideas? > > Thanks! > > > -------------------------------------------------- > ICA Canada Online > 2601 Matheson Blvd. E. Unit #29 > Mississauga, Ontario > L4W 5A8 > (905) 624-8566 > http://www.ica.net > > > > 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 Mar 5 10: 7:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by hub.freebsd.org (Postfix) with ESMTP id ED2FC37B402 for ; Tue, 5 Mar 2002 10:07:50 -0800 (PST) Received: from laptop.6bone.nl (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g25I7m030016; Tue, 5 Mar 2002 19:07:48 +0100 Received: (nullmailer pid 9661 invoked by uid 1000); Tue, 05 Mar 2002 16:11:04 -0000 Date: Tue, 5 Mar 2002 17:11:04 +0100 From: Mark Santcroos To: Volker Sturm Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: RS232/V24 Driver Message-ID: <20020305171103.A4669@laptop.6bone.nl> References: <000101c1c247$a8071eb0$0100a8c0@volker> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drussell@saturn-tech.com on Sat, Mar 02, 2002 at 05:21:08PM -0700 X-Handles: MS6-6BONE, MS18417-RIPE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Mar 02, 2002 at 05:21:08PM -0700, Doug Russell wrote: > On Sun, 3 Mar 2002, Volker Sturm wrote: > > I want to write a driver for a device on the serial port. The problem is > > that I dont get any info on the protocol that is used for data > .. > > there already? If not, are there ways to analyze the protocol by a > > monitor or whatever technique appropriate? > > You might take a look at ports/comms/snooper Better try: http://www.gphoto.org/ because afaik this model is already supported :-) -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 10:15:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 2EF7B37B405 for ; Tue, 5 Mar 2002 10:15:12 -0800 (PST) Received: (qmail 4707 invoked from network); 5 Mar 2002 18:15:06 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 18:15:06 -0000 Date: Tue, 5 Mar 2002 13:15:06 -0500 (EST) From: Kenneth Culver To: Raymond Wiker Cc: Martin Ankerl , Subject: Re: C vs C++ In-Reply-To: <15492.62736.239246.919734@raw.grenland.fast.no> Message-ID: <20020305131439.J4700-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, that too, I guess I was just using KDE as an example of something being extremely slow due to a lot of libs being loaded. Ken On Tue, 5 Mar 2002, Raymond Wiker wrote: > Kenneth Culver writes: > > The code itself may be fast, but programs written in c++ tend to link to a > > lot of shared libs, which in itself can be pretty slow. > > That's *not* unique to C++. On my machine, /usr/lib contains > 73 shared libs, and these are mainly C libraries. > > If you want arguments against C++, try any of these: > > C++ programs use a *lot* of header files, and these do in > general cause more work for the compiler than do the C header > files. This boils down to noticeably longer compile times. > > C++ is a *much* larger language, with *much* more complicated > semantics and behaviour. A large proportion of C++ programmers do not > know the language well enough that they should be allowed to program > in it. > > -- > Raymond Wiker Mail: Raymond.Wiker@fast.no > Senior Software Engineer Web: http://www.fast.no/ > Fast Search & Transfer ASA Phone: +47 23 01 11 60 > P.O. Box 1677 Vika Fax: +47 35 54 87 99 > NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 > > Try FAST Search: http://alltheweb.com/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 10:16: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id A673437B404 for ; Tue, 5 Mar 2002 10:15:53 -0800 (PST) Received: (qmail 4717 invoked from network); 5 Mar 2002 18:15:49 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 18:15:49 -0000 Date: Tue, 5 Mar 2002 13:15:49 -0500 (EST) From: Kenneth Culver To: Geoff Mohler Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 4.5-RELEASE upgrade..didnt?? In-Reply-To: Message-ID: <20020305131528.G4700-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG How exactly did you upgrade? did you cvsup your sourcecode and then recompile from there? Ken On Tue, 5 Mar 2002, Geoff Mohler wrote: > No, still have this from uname -a: > > 4.3-RELEASE FreeBSD 4.3-RELEASE #3: > > On Tue, 5 Mar 2002, Kenneth Culver wrote: > > > did u do a config -r on your kernel config file? if not it might not pick > > up some of the new stuff. > > > > Ken > > > > On Mon, 4 Mar 2002, Geoff Mohler wrote: > > > > > Ok..dumb question alert. (fair warning) > > > > > > I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded > > > as well. > > > > > > Went in, and did a make on my config file from 4.3..and rebooted (made > > > sure the new kernel was in / as well). > > > > > > Uname reports a 4.3 system..etc..etc..etc. > > > > > > What'd I miss? > > > > > > > > > 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 > > > > --- > Geoff Mohler > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 10:17:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 490C637B400 for ; Tue, 5 Mar 2002 10:17:04 -0800 (PST) Received: (qmail 4734 invoked from network); 5 Mar 2002 18:16:59 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 18:16:59 -0000 Date: Tue, 5 Mar 2002 13:16:59 -0500 (EST) From: Kenneth Culver To: "M. Warner Losh" Cc: vel@bugz.infotecs.ru, Subject: Re: C vs C++ In-Reply-To: <20020305.094927.40858673.imp@village.org> Message-ID: <20020305131602.J4700-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think what I was trying to say is that a lot of C++ programmers will obfuscate their code by using features of the language that don't fit with what they were trying to accomplish. Ken On Tue, 5 Mar 2002, M. Warner Losh wrote: > In message: <20020305102829.A3576-100000@alpha.yumyumyum.org> > Kenneth Culver writes: > : > I have a small problem. I work for software development company and > : > write daemons and console tools for Unix. My boss wants everything to be > : > written in C++, because he thinks C++ is cool. I prefer C for such > : > tasks, but I cannot really put good arguments of why and where C++ can > : > be worse than C. I know many of you prefer C too. Can you please explain > : > some disadvantages of C++ comparing to C ? Is it slower, does it produce > : > less effective code, why is it like that, etc ... or please direct me to > : > some articles where this can be explained. > : > : My main problem with C++ is that it adds a lot of overhead, and it's slow. > : Also, it drives me nuts when people code in C++ and write all kinds of > : classes when using classes for certain things just doesn't make sense, and > : makes the code much more convoluted. > > C++ doesn't add noticable overhead and isn't slow, unless you are a > dumbass about how you write it. All languages give you plenty of ways > to write speghetti fortran code :-). C++ gives you a number of ways > to obfuscate. > > Warner > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 10:24:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 923AD37B402 for ; Tue, 5 Mar 2002 10:24:26 -0800 (PST) Received: (qmail 4790 invoked from network); 5 Mar 2002 18:24:21 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 18:24:21 -0000 Date: Tue, 5 Mar 2002 13:24:21 -0500 (EST) From: Kenneth Culver To: Terry Lambert Cc: "Eugene L. Vorokov" , Subject: Re: C vs C++ In-Reply-To: <3C850402.90DC1B54@mindspring.com> Message-ID: <20020305132147.B4700-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > This is a serious concern for console tools, which are interacting with > humans, which are capable of providing commands much faster than a > 1.5GHz processor can accept and dispose of them... sorry I missed this > downside in my first response. I'm not sure if you are being sarcastic or not, but if you are, it is definitely not appreciated. C code is generally easier to make more simple than C++. That said, gui code is probably better written in C++ since the whole idea of objects lends itself to that. However, daemons/console based progs don't really have any real reason to be written in C++ becuase that usually adds a lot of code that doesn't need to be there, such as using classes to do things that don't lend themselves to that. Geez... Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 10:25:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 01B2B37B405 for ; Tue, 5 Mar 2002 10:25:38 -0800 (PST) Received: (qmail 4808 invoked from network); 5 Mar 2002 18:25:32 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 18:25:32 -0000 Date: Tue, 5 Mar 2002 13:25:32 -0500 (EST) From: Kenneth Culver To: Terry Lambert Cc: "Steve B." , "Eugene L. Vorokov" , Subject: Re: C vs C++ In-Reply-To: <3C850540.EA8EDE0F@mindspring.com> Message-ID: <20020305132457.A4700-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Why are you being so sarcastic? Everyone here is assuming that it's harder to write C++ code, so you should only use it if necessary. It isn't necessary to use it for something like a daemon. Ken On Tue, 5 Mar 2002, Terry Lambert wrote: > "Steve B." wrote: > > I take a simplistic view after years of C++. > > > > C++ is good for large projects that need to be maintained into the future. > > Then the advantages of OO starts to kick in. For small projects that won't > > change much then C is the better choice IMO. > > Wow. Forgot this disadvantage of C++, too. > > Yeah, it's difficult to write code that someone else > couldn't come in and maintain after it was done. This > means that the normal rules about "write important code > and you have a job forever" no longer apply. 8-(. > > -- Terry > > 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 Mar 5 10:32:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B6AB37B400 for ; Tue, 5 Mar 2002 10:32:41 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 09:46:53 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id CB70BBA03; Tue, 5 Mar 2002 09:46:38 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ Date: Tue, 5 Mar 2002 09:46:38 -0500 X-Mailer: KMail [version 1.3] References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> In-Reply-To: <200203051407.g25E7Cd67446@bugz.infotecs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020305144638.CB70BBA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 05 March 2002 09:07 am, Eugene L. Vorokov wrote: > Hello, > > I have a small problem. I work for software development company and > write daemons and console tools for Unix. My boss wants everything > to be written in C++, because he thinks C++ is cool. I prefer C > for such tasks, but I cannot really put good arguments of why and > where C++ can be worse than C. I know many of you prefer C too. > Can you please explain some disadvantages of C++ comparing to C ? > Is it slower, does it produce less effective code, why is it like > that, etc ... or please direct me to some articles where this can > be explained. > > I apologize for the offtopic whenever it happens, but this issue > really pisses me off now. Since C++ is, with a few trifling exceptions, a superset of C, why not just write C code like you always have and compile with the C++ compiler to make him happy? Unless your boss is way more clueful than most (and I doubt it or he wouldn't want daemons written in C++, I don't think), he won't know the difference. If he wants oo programming and accessor functions for everything and design meetings where you roleplay the different objects and all that jazz, thet's a different matter, and it's worth fighting. But if he just wants you to compile with C++, I'd advise just giving in. The compiles will be a little slower and the warning messages will be more strict, but you won't have to change much of what you're doing, unless you're writing pretty "fast & loose" C code now. -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 11:14:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (law2-f74.hotmail.com [216.32.181.74]) by hub.freebsd.org (Postfix) with ESMTP id 9218D37B41F for ; Tue, 5 Mar 2002 11:14:25 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Mar 2002 11:14:25 -0800 Received: from 63.67.30.193 by lw2fd.hotmail.msn.com with HTTP; Tue, 05 Mar 2002 19:14:25 GMT X-Originating-IP: [63.67.30.193] From: "Kenneth Mays" To: freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ Date: Tue, 05 Mar 2002 14:14:25 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Mar 2002 19:14:25.0541 (UTC) FILETIME=[F6E58B50:01C1C479] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The quest continues... Just another blurb... The paradigm shift in all of this is what the theories and beliefs fabled around C++ have surmounted from debate after many years. C++ is an OO based language and falls under the reasoning of of use that other OO languages fall under. Not because its C++, but because it is an OO based language. I used the reasoning that managers think C++ is easier to read and maintain not because that is in fact, but that it is SUPPOSED to be by design and reason. Meaning, you are meant to learn how to write modular and reusable code based on the OO principles of software engineering. Not that you will, but that you can. C++ is nothing more than a tool but you are suppose to follow guidelines and rules that are suppose to make your code more readable, elegant, stylish (ha!), and maintainable as well as reusable. Now, you can take this rhetoric for what you will but that was some of the old beliefs. You can fight the cause by writing what needs to be written in C++, true C++, and showing code written in C only where it benefits but documented and written well (not "spaghetti-fied"). The gift of style and design is in the hands of the programmer (the toolmaster) and not really the code itself. That is the basics of software engineering over standard computer progamming. C++ vs. C can be a political debate filled with fluff. I think once you understand that a hammer is a hammer for a reason instead of a brick or stone being a hammer (which they can be in a sense), then you understand the purposes for C++ and/or C. Just make a TRUE analysis of factual information of WHY C++ was created in the first place and what are its true benefits over C (documented in many literary programming books, even "C++ for Dummies") or why is C is better in other areas than using C++ (ask a game programmer). Start there and let your thumbs be your guide. Ken M. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 11:34:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bogslab.ucdavis.edu (bogslab.ucdavis.edu [169.237.68.34]) by hub.freebsd.org (Postfix) with ESMTP id 4731637B404 for ; Tue, 5 Mar 2002 11:34:29 -0800 (PST) Received: from thistle.bogs.org (thistle.bogs.org [198.137.203.61]) by bogslab.ucdavis.edu (8.9.3/8.9.3) with ESMTP id LAA81681 for ; Tue, 5 Mar 2002 11:34:22 -0800 (PST) (envelope-from greg@bogslab.ucdavis.edu) Received: from thistle.bogs.org (localhost [127.0.0.1]) by thistle.bogs.org (8.11.3/8.11.3) with ESMTP id g25JXe975858 for ; Tue, 5 Mar 2002 11:33:41 -0800 (PST) (envelope-from greg@thistle.bogs.org) Message-Id: <200203051933.g25JXe975858@thistle.bogs.org> To: hackers@FreeBSD.ORG X-To: Michael Scheidell X-Sender: owner-freebsd-hackers@FreeBSD.ORG Subject: Re: Help! serious problem. In-reply-to: Your message of "Tue, 05 Mar 2002 12:45:55 EST." <200203051745.g25Hjuh49009@scanner.secnap.net> Reply-To: gkshenaut@ucdavis.edu Date: Tue, 05 Mar 2002 11:33:40 -0800 From: Greg Shenaut Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200203051745.g25Hjuh49009@scanner.secnap.net>, Michael Scheidell cleopede: >> > >> > Running FreeBSD 4.5 and it keeps rebooting around the same time >> > late during the night. > >had two similar problem's >#1, client computer, 4:59pm every weekday, rebooted. >Seems luser plugged their POSTAGE METER into same UPS as the computer >4:59pm, luser gets up and 'stamps' today's outgoing email! > (massive surge, big magnets, negative neutrinos flying around) > >#2, 8:15am (and then 9:15am after DST change) > lights in building turned on. > T1 line from TELCO was shorted to house ground. > House wiring was NOT grounded, so house wiring found ground through T1! Another one I've seen is that the building air conditioners all get turned off at the end of the workday, and it takes a certain amount of time before the room the computers is in gets so hot that the computers start getting flaky. Greg Shenaut To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 11:39:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ubergeeks.com (lorax.ubergeeks.com [209.145.65.55]) by hub.freebsd.org (Postfix) with ESMTP id 2682037B41B for ; Tue, 5 Mar 2002 11:38:34 -0800 (PST) Received: from localhost (adrian@localhost) by mail.ubergeeks.com (8.11.6/8.11.6) with ESMTP id g25JcBx55027; Tue, 5 Mar 2002 14:38:12 -0500 (EST) (envelope-from adrian@ubergeeks.com) Date: Tue, 5 Mar 2002 14:38:11 -0500 (EST) From: Adrian Filipi-Martin Reply-To: Adrian Filipi-Martin To: Terry Lambert Cc: Mark Murray , FreeBSD Hackers List , Subject: Re: Intel 820 RNG In-Reply-To: <3C840862.53658404@mindspring.com> Message-ID: <20020305135912.C52330-100000@lorax.ubergeeks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Terry Lambert wrote: > Mark Murray wrote: > > > But, back to the topic. We have taken the OpenBSD driver for the > > > RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to > > > FreeBSD-4.4. We made some enhancements to get more of the available random > > > data bandwidth. > > > > > > We want to clean them up a little and submit them as a PR, but have > > > not had time to. If you're interested I can send you the patches and you > > > can give them a try. > > > > Hi. > > > > Please send me what you have. > > Agreed. Anything that stops the "harvesting entropy" from > sitting in the interrupt processing path for the most > important interrupts on the box can only be a good thing. > > -- Terry I thought some one out there would be interested... Attached are our diffs relative to 4.4-RELEASE. They are mostly a direct port of the OpenBSD drivers and their integration into the stock random device entropy pool. We did make some enhancements that serve our needs, but may not be best for everyone. We actually need entropy in quantity since we could be doing a lot of crypto operations back to back and it can easily become our worst bottleneck. To this end, we have an entropy buffer in kernel memory that pulls large blocks of entropy from the RNG if it's going to read from it at all. The device puts out several orders of magnitude more entropy than the original drivers captured, and we needed as much as we could grab. Ideally we would not mix the entropy into the entropy pool and just use the high quality entropy from the buffer, but we decided to minimize divergence from the original sources and not switch to 100% hardware entropy. The drawback to our approach is that it can spend a lot of time in the kernel. To tune this behavior we added a few sysctl's. The start/stop script after the diff's tweaks a few of these settings after boot up. I cc'd Kaj Groner, who actually did the work for us. He's not on this list, so don't drop his address. I was more involved at the higher levels of what we needed to get done when we rebased our appliance from OpenBSD to FreeBSD last Summer. cheers, Adrian -- [ adrian@ubergeeks.com ] --- i386/isa/ic/i82802.h Wed Oct 17 12:44:23 2001 +++ i386/isa/ic/i82802.h Mon Oct 8 11:55:22 2001 @@ -0,0 +1,21 @@ +/* This is where the first 82802 firmware hub is found. */ +#define FWH_BASE 0xffb00000 + +/* This is the offset where the RNG is found. */ +#define RNG_OFFSET 0xc015f + +/* Number of RNG ports */ +#define RNG_SPAN 3 + +/* RNG registers */ +#define RNG_HWSTAT 0x00 +#define RNG_DATASTAT 0x01 +#define RNG_DATA 0x02 + +/* RNG hardware status register (RNG_HWSTAT) */ +#define RNG_PRESENT 0x40 +#define RNG_ENABLED 0x01 + +/* RNG data status register (RNG_DATASTAT) */ +#define RNG_READY 0x01 + --- kern/kern_random.c.orig Sun Oct 28 16:06:31 2001 +++ kern/kern_random.c Sun Oct 28 16:06:49 2001 @@ -224,20 +224,41 @@ /* Prevent overflow */ if (r->entropy_count > POOLBITS) r->entropy_count = POOLBITS; if (r->entropy_count >= 8) selwakeup(&random_state.rsel); } void +add_true_randomness(u_int32_t num) +{ + add_entropy_word(&random_state, num); + + random_state.entropy_count += sizeof (num) * 8; + + /* Prevent overflow */ + if (random_state.entropy_count > POOLBITS) + random_state.entropy_count = POOLBITS; + + if (random_state.entropy_count >= 8) + selwakeup(&random_state.rsel); +} + +u_int +get_entropy_deficit(void) +{ + return (POOLBITS - random_state.entropy_count); +} + +void add_keyboard_randomness(u_char scancode) { add_timer_randomness(&random_state, &keyboard_timer_state, scancode); } void add_interrupt_randomness(void *vsc) { int intr; struct random_softc *sc = vsc; --- pci/pcisupport.c 15 Aug 2001 04:04:59 -0000 1.154.2.7 +++ pci/pcisupport.c 22 Oct 2001 18:39:54 -0000 @@ -48,7 +48,15 @@ #include #include #include + +#include +#include +#include + +#include #include +#include +#include #include #include @@ -57,6 +65,8 @@ #include #include +#include + /*--------------------------------------------------------- ** ** Intel chipsets for 486 / Pentium processor @@ -669,6 +679,170 @@ return descr; } +#define RNG_RESERVE 0x10000 + +struct pcib_softc { + /* RNG stuff */ + struct { + int rid; + struct resource *res; + bus_space_tag_t bt; + bus_space_handle_t bh; + + struct callout_handle toh; + + u_int8_t reserve[RNG_RESERVE]; + int reserve_start, reserve_end; + } rng; +}; + +static void rng_poll_cb(void *arg); + +static void +rng_attach(device_t dev) { + struct pcib_softc *sc; + int ok = 1; + + sc = (struct pcib_softc *)device_get_softc(dev); + + switch (pci_get_devid(dev)) { + case 0x24188086: + case 0x244e8086: + /* This is the rng_probe() segment */ + + if (ok) { + bus_set_resource(dev, SYS_RES_MEMORY, 0, FWH_BASE + RNG_OFFSET, RNG_SPAN); + sc->rng.rid = 0; + sc->rng.res = bus_alloc_resource(dev, SYS_RES_MEMORY, &sc->rng.rid, + 0, ~0, 0, RF_ACTIVE); + + if (sc->rng.res != NULL) { + sc->rng.bt = rman_get_bustag(sc->rng.res); + sc->rng.bh = rman_get_bushandle(sc->rng.res); + } else { + ok = 0; + } + } + + if (ok) { + /* Check for RNG presence */ + u_int8_t hwstat = + bus_space_read_1(sc->rng.bt, sc->rng.bh, RNG_HWSTAT); + if ((hwstat & RNG_PRESENT) == 0) + ok = 0; + } + + if (ok) { + /* Enable RNG */ + u_int8_t hwstat = + bus_space_read_1(sc->rng.bt, sc->rng.bh, RNG_HWSTAT) | RNG_ENABLED; + bus_space_write_1(sc->rng.bt, sc->rng.bh, RNG_HWSTAT, hwstat); + + hwstat = bus_space_read_1(sc->rng.bt, sc->rng.bh, RNG_HWSTAT); + if ((hwstat & RNG_ENABLED) == 0) + ok = 0; + } + + if (ok) { + int i = 1000; + + while (--i) { + if (bus_space_read_1(sc->rng.bt, sc->rng.bh, RNG_DATASTAT) & RNG_READY) + break; + DELAY(10); + } + + if (bus_space_read_1(sc->rng.bt, sc->rng.bh, RNG_DATASTAT) & RNG_READY) { + printf("rng: initial byte was %02x\n", + bus_space_read_1(sc->rng.bt, sc->rng.bh, RNG_DATA)); + } else { + ok = 0; + } + } + + /* FIPS test here */ + + /* This is the rng_attach() segment */ + if (ok) { + /* One tick is a very coarse interval to poll this device with. + * Intel recommnds polling it every 4.5ms. When hz = 100, we are + * polling about 22 times less often than we could. Yay. + */ + sc->rng.toh = timeout(rng_poll_cb, sc, 1); + sc->rng.reserve_start = sc->rng.reserve_end = 0; + printf("rng: registered polling timeout\n"); + } + + if (!ok) { + if (sc->rng.res != NULL) + bus_release_resource(dev, SYS_RES_MEMORY, sc->rng.rid, sc->rng.res); + } + + break; + } +} + +SYSCTL_NODE(_hw, OID_AUTO, rng, CTLFLAG_RW, 0, "RNG stuff"); +static unsigned long rng_tries = 0; +SYSCTL_ULONG(_hw_rng, OID_AUTO, tries, CTLFLAG_RW, &rng_tries, 0, "RNG polling attempts"); +static unsigned long rng_hits = 0; +SYSCTL_ULONG(_hw_rng, OID_AUTO, hits, CTLFLAG_RW, &rng_hits, 0, "RNG polling hits"); +static unsigned long rng_full = 0; +SYSCTL_ULONG(_hw_rng, OID_AUTO, full, CTLFLAG_RW, &rng_full, 0, "RNG extra loops"); +static unsigned int rng_delay = 600; +SYSCTL_UINT(_hw_rng, OID_AUTO, delay, CTLFLAG_RW, &rng_delay, 0, "RNG busy polling interval"); +static unsigned int rng_loop = 1; +SYSCTL_UINT(_hw_rng, OID_AUTO, loops, CTLFLAG_RW, &rng_loop, 0, "RNG busy polling iterations per tick"); +static unsigned int rng_reserve = 0; +SYSCTL_UINT(_hw_rng, OID_AUTO, reserve, CTLFLAG_RD, &rng_reserve, 0, "RNG reserve bytes"); + +static void +rng_poll_cb(void *arg) { + struct pcib_softc *sc = (struct pcib_softc *)arg; + int loop = rng_loop; + int i; + + for (i = get_entropy_deficit() / (sizeof (u_int32_t) * 8); i; i--) { + u_int32_t *word; + int avail = sc->rng.reserve_end - sc->rng.reserve_start; + if (avail < 0) + avail += RNG_RESERVE; + + if (avail < sizeof (u_int32_t)) + break; + + word = (u_int32_t *)(sc->rng.reserve + sc->rng.reserve_start); + add_true_randomness(*word); + + rng_reserve -= sizeof (u_int32_t); + + sc->rng.reserve_start = + (sc->rng.reserve_start + sizeof (u_int32_t)) % RNG_RESERVE; + } + + while (loop--) { + if ((sc->rng.reserve_end + 1) % RNG_RESERVE == sc->rng.reserve_start) { + /* enough! */ + rng_full += loop + 1; + break; + } + + rng_tries++; + if (bus_space_read_1(sc->rng.bt, sc->rng.bh, RNG_DATASTAT) & RNG_READY) { + rng_hits++; + sc->rng.reserve[sc->rng.reserve_end] = + bus_space_read_1(sc->rng.bt, sc->rng.bh, RNG_DATA); + sc->rng.reserve_end = (sc->rng.reserve_end + 1) % RNG_RESERVE; + rng_reserve++; + } + + if (loop) + DELAY(rng_delay); + } + + sc->rng.toh = timeout(rng_poll_cb, sc, 1); +} + static const char* pcib_match(device_t dev) { @@ -763,6 +937,8 @@ chipset_attach(dev, device_get_unit(dev)); + rng_attach(dev); + secondary = pci_get_secondarybus(dev); if (secondary) { device_add_child(dev, "pci", secondary); @@ -847,7 +1023,7 @@ static driver_t pcib_driver = { "pcib", pcib_methods, - 1, + sizeof (struct pcib_softc), }; static devclass_t pcib_devclass; --- sys/random.h 2000/05/10 02:04:52 1.19.2.1 +++ sys/random.h 2001/10/09 15:01:19 @@ -69,6 +69,8 @@ /* Exported functions */ void rand_initialize(void); +void add_true_randomness(u_int32_t num); +u_int get_entropy_deficit(void); void add_keyboard_randomness(u_char scancode); inthand2_t add_interrupt_randomness; #ifdef notused #!/bin/sh # hwrng.sh: A script to tune the RNG driver to poll more aggressively. hwrngop() { if ! sysctl hw.rng >/dev/null 2>&1; then echo "${0##*/}: rng not found" >&2 exit 1 fi if [ $# -gt 0 ]; then sysctl "$@" fi } case "$1" in start) echo "Enabling aggressive RNG polling." hwrngop hw.rng.loops=10 ;; stop) echo "Disabling aggressive RNG polling." hwrngop hw.rng.loops=1 ;; status) hwrngop # check for presence echo -n "Aggressive RNG polling is " if [ "$(sysctl -n hw.rng.loops)" -gt 1 ]; then echo "enabled" else echo "disabled" fi ;; *) echo "usage: ${0##*/} [ start | stop | status ]" >&2 exit 1 ;; esac exit 0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 11:41:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ubergeeks.com (lorax.ubergeeks.com [209.145.65.55]) by hub.freebsd.org (Postfix) with ESMTP id 1837437B428 for ; Tue, 5 Mar 2002 11:40:58 -0800 (PST) Received: from localhost (adrian@localhost) by mail.ubergeeks.com (8.11.6/8.11.6) with ESMTP id g25JemA55039; Tue, 5 Mar 2002 14:40:48 -0500 (EST) (envelope-from adrian@ubergeeks.com) Date: Tue, 5 Mar 2002 14:40:48 -0500 (EST) From: Adrian Filipi-Martin Reply-To: Adrian Filipi-Martin To: "Sam Leffler (at Usenix)" Cc: Bruce M Simpson , Subject: Re: Intel 820 RNG In-Reply-To: <22f201c1c3d0$2dd87960$52557f42@errno.com> Message-ID: <20020305143822.F52330-100000@lorax.ubergeeks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Sam Leffler (at Usenix) wrote: > > But, back to the topic. We have taken the OpenBSD driver for the > > RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to > > FreeBSD-4.4. We made some enhancements to get more of the available > random > > data bandwidth. > > > > I ported the openbsd crypto stuff to -stable for the purpose of making the > soekris vpn1211 card usable (Hifn 7951). As part of this I tied the RNG on > the Hifn to /dev/random; all that was required was to add a call to inject > the data as entropy (or so I believed). Are your diff's available? We have a handful of idle powercrypt cards, which are Hifn's IIRC, idle here, and we have boxes without the i810 entropy device on their motherboards. This would be handy. Did you just dump the entropy into the existing entropy pool of the standard random(4) driver, or does it replace the driver with 100% hardware entropy? What kind of entropy bandwidth are you able to get? cheers, Adrian -- [ adrian@ubergeeks.com ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 11:53:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 4F7CD37B400 for ; Tue, 5 Mar 2002 11:53:32 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g25JrLcR119144; Tue, 5 Mar 2002 14:53:21 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200203051407.g25E7Cd67446@bugz.infotecs.ru> References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> Date: Tue, 5 Mar 2002 14:53:19 -0500 To: "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: C vs C++ Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 5:07 PM +0300 3/5/02, Eugene L. Vorokov wrote: >Hello, > >I have a small problem. I work for software development company and >write daemons and console tools for Unix. My boss wants everything >to be written in C++, because he thinks C++ is cool. I prefer C >for such tasks, but I cannot really put good arguments of why and >where C++ can be worse than C. I know many of you prefer C too. >Can you please explain some disadvantages of C++ comparing to C ? Anyone who thinks C++ is some kind of magic bullet because "it is cool" is just fooling themselves. You may be able to do some great stuff in C++, but only if you take the time to really learn the language, and it's pitfalls (so you know what to avoid). I prefer C over C++ because there is less there to "really learn". but this is probably one of those personal-preference things which is impossible for any one side to prove their position to any other side... -- 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 Tue Mar 5 12:11: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id C8F8B37B405 for ; Tue, 5 Mar 2002 12:10:44 -0800 (PST) Received: from dhcp206.mis.earthlink.net ([207.217.66.246] helo=DROID) by harrier.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16iLGc-0003KK-00 for freebsd-hackers@FreeBSD.ORG; Tue, 05 Mar 2002 12:10:34 -0800 Message-ID: <001701c1c481$d0d5eab0$f642d9cf@DROID> From: "Steve B." To: References: <20020305132457.A4700-100000@alpha.yumyumyum.org> Subject: Re: C vs C++ Date: Tue, 5 Mar 2002 12:10:37 -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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I wouldn't say C++ is THAT much harder to write, it does have a steeper initial learning curve than C. Most of that is due to needing to learn OOP at the same time. It is easier for C++ to come back and bite you than C if you don't spend enough time up front in design. IMO the biggest problem is people trying to treat C and C++ as one language. That is only good is you want to use C++ and as a better C compiler for the lint like features of C++ language. Steve B. ----- Original Message ----- From: "Kenneth Culver" To: "Terry Lambert" Cc: "Steve B." ; "Eugene L. Vorokov" ; Sent: Tuesday, March 05, 2002 10:25 AM Subject: Re: C vs C++ > Why are you being so sarcastic? Everyone here is assuming that it's harder > to write C++ code, so you should only use it if necessary. It isn't > necessary to use it for something like a daemon. > > Ken > > On Tue, 5 Mar 2002, Terry Lambert wrote: > > > "Steve B." wrote: > > > I take a simplistic view after years of C++. > > > > > > C++ is good for large projects that need to be maintained into the future. > > > Then the advantages of OO starts to kick in. For small projects that won't > > > change much then C is the better choice IMO. > > > > Wow. Forgot this disadvantage of C++, too. > > > > Yeah, it's difficult to write code that someone else > > couldn't come in and maintain after it was done. This > > means that the normal rules about "write important code > > and you have a job forever" no longer apply. 8-(. > > > > -- Terry > > > > 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 Tue Mar 5 12:14: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id E154E37B404 for ; Tue, 5 Mar 2002 12:13:53 -0800 (PST) Received: from hades.hell.gr (patr530-a183.otenet.gr [212.205.215.183]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g25KDoDg006808 for ; Tue, 5 Mar 2002 22:13:51 +0200 (EET) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g25KDo0O004988 for ; Tue, 5 Mar 2002 22:13:50 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g25KDoHG004987 for hackers@freebsd.org; Tue, 5 Mar 2002 22:13:50 +0200 (EET) (envelope-from keramida@freebsd.org) X-Authentication-Warning: hades.hell.gr: charon set sender to keramida@freebsd.org using -f Date: Tue, 5 Mar 2002 22:13:50 +0200 From: Giorgos Keramidas To: hackers@freebsd.org Subject: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020305201350.GC4820@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The following is the largest part of the audit trail of PR docs/28555. At the end of the audit trail, Dima Dorfman asked Mike Meyer to seek review and comments from a wider audience than -doc. Since this documentation PR has been open for quit some time now, I'm posting the patch the PR was about, hoping to get comments from our style(9) meisters, and everyone else that can help with this. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ --- Audit trail --- On 2001-06-30 21:26, Mike Meyer wrote: > The style(9) page says not to use ! for testing values unless the > value is a boolean. It also says to test pointers against NULL. This > leaves open the question of how other values that aren't booleans > should be tested. > > >How-To-Repeat: > > Read the man page to try and decide if you should write "if (x)" or > if (x != 0). > > >Fix: > > Apply the attached page to the style(9) man page. > > --- /usr/src/share/man/man9/style.9 Fri May 18 07:27:37 2001 > +++ style.9 Sat Jun 30 16:23:34 2001 > @@ -449,14 +449,37 @@ > !(p = f()) > .Ed > .Pp > -Don't use '!' for tests unless it's a boolean, e.g. use > +For tests, always compare the value to the appropriate 0 instead of > +checking it directly, unless the value is a boolean. > +For pointers, use: > +.Bd -literal > +if (p != NULL) > +.Ed > +.Pp > +not > +.PP > +.Bd -literal > +if (!p) > +.Ed > +.Pp > +For other values, use: > .Bd -literal > if (*p == '\e0') > .Ed > .Pp > not > .Bd -literal > -if (!*p) > +if (*p) > +.Ed > +.Pp > +unless the value is a boolean. In that case, use: > +.Bd -literal > +if (p) > +.Ed > +.Pp > +and > +.Bd -literal > +if (!p) > .Ed > .Pp > Routines returning void * should not have their return values cast On 2002-06-30 21:57, Dima Dorfman wrote: > I think it is quite clear on the subject. If it's not a boolean, > don't treat it like one; i.e., compare it against the value you're > looking for. '0' may not always be that value. > > Regardless, this does not belong as a PR, let alone in the docs/ > category. It belongs as a post on -hackers, asking what people think, > not as a change request. Since *developers* are expected to follow > style(9), it is the *developers* (i.e., -hackers@) that you should be > proposing the change to. On 2001-06-30 22:55, Mike Meyer wrote: > We both agree I'm not proposing a change in the style they have to > follow; I'm just proposing making something explicit instead of > implicit. As such, I'm not sure it warrants discussion. If the PR > belongs in another category, please feel free to move it to either > move it or suggest one for someone else to move it to. On 2001-06-02 23:13, Dima Dorfman wrote: > I'm not suggesting that you should get every developer's approval, but > I am suggesting that wider review than the -doc list would be nice, > esp. for a document that defines policy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 12:18:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id DB71E37B402 for ; Tue, 5 Mar 2002 12:18:10 -0800 (PST) Received: from pool0286.cvx22-bradley.dialup.earthlink.net ([209.179.199.31] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iLNj-0004RZ-00; Tue, 05 Mar 2002 12:17:55 -0800 Message-ID: <3C8527E1.1654879F@mindspring.com> Date: Tue, 05 Mar 2002 12:17:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kenneth Culver Cc: "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ References: <20020305132147.B4700-100000@alpha.yumyumyum.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kenneth Culver wrote: > > This is a serious concern for console tools, which are interacting with > > humans, which are capable of providing commands much faster than a > > 1.5GHz processor can accept and dispose of them... sorry I missed this > > downside in my first response. > > I'm not sure if you are being sarcastic or not, but if you are, it is > definitely not appreciated. C code is generally easier to make more simple > than C++. That said, gui code is probably better written in C++ since the > whole idea of objects lends itself to that. However, daemons/console based > progs don't really have any real reason to be written in C++ becuase that > usually adds a lot of code that doesn't need to be there, such as using > classes to do things that don't lend themselves to that. "A good programmer can write FORTRAN in any language." If you are getting "usually adds a lot of code that doesn't need to be there, such as using classes to do things that don't lend themselves to that", then you need to look at your programmers, not at the tools they are using. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 12:26:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 6592137B404 for ; Tue, 5 Mar 2002 12:26:26 -0800 (PST) Received: from pool0286.cvx22-bradley.dialup.earthlink.net ([209.179.199.31] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iLVt-0000kz-00; Tue, 05 Mar 2002 12:26:21 -0800 Message-ID: <3C8529DA.FA8ABCE@mindspring.com> Date: Tue, 05 Mar 2002 12:26:02 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kenneth Culver Cc: "Steve B." , "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ References: <20020305132457.A4700-100000@alpha.yumyumyum.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kenneth Culver wrote: > Why are you being so sarcastic? Everyone here is assuming that it's harder > to write C++ code, so you should only use it if necessary. It isn't > necessary to use it for something like a daemon. Because that underlying assumption is false, and I'm making fun of it. If you don't use C++ specific features, you're just writing C code anyway. It's not harder to write C++ code that uses the special features of the language; it may be harder for a programmer unfamiliar with the language, but it's not harder for everyone. It's harder for me to write code in languages with which I'm unfamiliar. Big deal. That's a problem with my familiarity, not with the language. There are a lot of benefits to the use of C++ that outweigh the downside, particularly if you are a company paying for something, and you want to invest the value in the code base instead of investing it in people who can walk out the door and sign with your competition tomorrow. Again... big deal. If it was something you'd do anyway, then they wouldn't be paying you to get you to do it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 12:42:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 4152237B402 for ; Tue, 5 Mar 2002 12:42:55 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g25KgrP12529 for ; Tue, 5 Mar 2002 15:42:53 -0500 (EST) Date: Tue, 5 Mar 2002 15:41:09 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: freebsd-hackers@freebsd.org Subject: A weird disk behaviour Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-----+----+----+----+----+----+----+----+----+----+---+------ | | | | | | | | | | | | .... +-----+----+----+----+----+----+----+----+----+----+---+------ Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 13: 0:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id E48F237B416; Tue, 5 Mar 2002 13:00:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305210015.SKCQ2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 21:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA32427; Tue, 5 Mar 2002 12:59:44 -0800 (PST) Date: Tue, 5 Mar 2002 12:59:43 -0800 (PST) From: Julian Elischer To: Giorgos Keramidas Cc: hackers@freebsd.org Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: <20020305201350.GC4820@hades.hell.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, Giorgos Keramidas wrote: > > > > Read the man page to try and decide if you should write "if (x)" or > > if (x != 0). > > > > >Fix: > > > > Apply the attached page to the style(9) man page. [...] the one that I stop to think about is: if (!(flags & FLAGSET)) or should that be if ((flags & FLAGSET) == 0) it depends on what you define as a Boolean. If FLAGSET has > 1 bit in it then it it still possibly a boolean? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 13: 0:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 4B15D37B402 for ; Tue, 5 Mar 2002 13:00:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305210016.SKDF2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 21:00:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA32421; Tue, 5 Mar 2002 12:55:30 -0800 (PST) Date: Tue, 5 Mar 2002 12:55:30 -0800 (PST) From: Julian Elischer To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: A weird disk behaviour In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG more writes fit in the disk's write cache? On Tue, 5 Mar 2002, Zhihui Zhang wrote: > > I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. > This situation is like this: > > +-----+----+----+----+----+----+----+----+----+----+---+------ > | | | | | | | | | | | | .... > +-----+----+----+----+----+----+----+----+----+----+---+------ > > Each block is of fixed size, say 8192 bytes. Now I have a user program > writing each contiguously laid out block sequentially using /dev/daxxx > interface. There are a lot of them, say 15000. I write the blocks in two > ways (the data used in writing are garbage): > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > (2) I still write these blocks sequentially, but for each block I only > write part of it. Exactly how many bytes are written inside each block is > determinted by a random number between 512 .. 8192 bytes (rounded up a > to multiple of 512 bytes). > > I find out the the performance of (2) is several times better than the > performance of (1). Can anyone explain to me why this is the case? > > Thanks for any suggestions or hints. > > -Zhihui > > > > 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 Mar 5 13: 5:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 5C67237B402 for ; Tue, 5 Mar 2002 13:05:06 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g25L4xP02875; Tue, 5 Mar 2002 16:04:59 -0500 (EST) Date: Tue, 5 Mar 2002 16:03:15 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Julian Elischer Cc: freebsd-hackers@freebsd.org Subject: Re: A weird disk behaviour In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, Julian Elischer wrote: > > more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. -Zhihui > On Tue, 5 Mar 2002, Zhihui Zhang wrote: > > > > > I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. > > This situation is like this: > > > > +-----+----+----+----+----+----+----+----+----+----+---+------ > > | | | | | | | | | | | | .... > > +-----+----+----+----+----+----+----+----+----+----+---+------ > > > > Each block is of fixed size, say 8192 bytes. Now I have a user program > > writing each contiguously laid out block sequentially using /dev/daxxx > > interface. There are a lot of them, say 15000. I write the blocks in two > > ways (the data used in writing are garbage): > > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > (2) I still write these blocks sequentially, but for each block I only > > write part of it. Exactly how many bytes are written inside each block is > > determinted by a random number between 512 .. 8192 bytes (rounded up a > > to multiple of 512 bytes). > > > > I find out the the performance of (2) is several times better than the > > performance of (1). Can anyone explain to me why this is the case? > > > > Thanks for any suggestions or hints. > > > > -Zhihui > > > > > > > > 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 Mar 5 13:21:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sigbus.com (c-24-126-148-218.we.mediaone.net [24.126.148.218]) by hub.freebsd.org (Postfix) with ESMTP id 2262337B423; Tue, 5 Mar 2002 13:21:07 -0800 (PST) Received: (from henrich@localhost) by sigbus.com (8.11.1/8.11.1) id g25LKxE18794; Tue, 5 Mar 2002 13:20:59 -0800 (PST) (envelope-from henrich) Date: Tue, 5 Mar 2002 13:20:59 -0800 From: Charles Henrich To: Heiko Recktenwald Cc: "Steve O'Hara-Smith" , freebsd-hackers@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG Subject: Re: Realtime video capture/divx encoding (brooktree) beta testers required Message-ID: <20020305132058.A18777@sigbus.com> Mail-Followup-To: Heiko Recktenwald , Steve O'Hara-Smith , freebsd-hackers@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG References: <20020304164757.B8269@sigbus.com> <20020304164757.B8269@sigbus.com> <20020305074843.4e94b069.steve@sohara.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from uzs106@ibm.rhrz.uni-bonn.de on Tue, Mar 05, 2002 at 10:55:44AM +0100 X-Operating-System: FreeBSD 4.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F X-GPG-Fingerprint: EA4C AB9B 0C38 17C0 AB3F 11DE 41F6 5883 41E7 4F49 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On the subject of Re: Realtime video capture/divx encoding (brooktree) beta testers required, Heiko Recktenwald stated: > At 7:48 Uhr +0100 05.03.2002, Steve O'Hara-Smith wrote: > > > PS: I am more interested in mpeg1 than DivX because with mpeg1 the > >stream can be watched as it is being made. > > Would it help to "hint" it on the fly like it is done with mpeg4ip ? I dont get it? You can play raw .avi streams without doing anything, just play it as its being created. -Crh Charles Henrich Eon Entertainment henrich@msu.edu http://www.sigbus.com:81/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 13:43:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 7449637B416 for ; Tue, 5 Mar 2002 13:43:28 -0800 (PST) Received: (qmail 5879 invoked from network); 5 Mar 2002 21:43:22 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 5 Mar 2002 21:43:22 -0000 Date: Tue, 5 Mar 2002 16:43:22 -0500 (EST) From: Kenneth Culver To: Terry Lambert Cc: "Steve B." , "Eugene L. Vorokov" , Subject: Re: C vs C++ In-Reply-To: <3C8529DA.FA8ABCE@mindspring.com> Message-ID: <20020305164151.T5854-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Because that underlying assumption is false, and I'm making > fun of it. > Well, that in itself is wrong. C++ code IS harder to write and write correctly and effeciently, as I would assume it is for any OO language. I'm not saying it can't be done, but generally speaking based on the Open source and commercial products I've seen, the ones that are written in C++ suffer from more bloat and run slower. Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 13:43:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by hub.freebsd.org (Postfix) with ESMTP id 21C6B37B41A for ; Tue, 5 Mar 2002 13:43:29 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 16:41:46 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 545FDBA03; Tue, 5 Mar 2002 16:41:27 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Terry Lambert , Kenneth Culver Subject: Re: C vs C++ Date: Tue, 5 Mar 2002 16:41:26 -0500 X-Mailer: KMail [version 1.3] Cc: "Steve B." , "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <3C8529DA.FA8ABCE@mindspring.com> In-Reply-To: <3C8529DA.FA8ABCE@mindspring.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020305214127.545FDBA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 05 March 2002 03:26 pm, Terry Lambert wrote: > Kenneth Culver wrote: > > Why are you being so sarcastic? Everyone here is assuming that it's > > harder to write C++ code, so you should only use it if necessary. It > > isn't necessary to use it for something like a daemon. > > Because that underlying assumption is false, and I'm making > fun of it. Reality check: How can you possibly contend that it is no more difficult to write code in a language which *so* much more massive? And one, I might add, which is intentionally UNdesigned. C++ is a language which I really liked until I really started to learn about it. -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 13:50:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 89E5D37B405 for ; Tue, 5 Mar 2002 13:50:14 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g25LnrV11878 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 5 Mar 2002 16:49:55 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020305225819.01c3a678@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Mar 2002 23:00:44 +0100 To: Zhihui Zhang , Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: A weird disk behaviour Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: >On Tue, 5 Mar 2002, Julian Elischer wrote: > > > > > more writes fit in the disk's write cache? > >For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * >4096 bytes in all (assuming the random number distributes evenly between 0 >and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc >-Zhihui > > > On Tue, 5 Mar 2002, Zhihui Zhang wrote: > > > > > > > > I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. > > > This situation is like this: > > > > > > +-----+----+----+----+----+----+----+----+----+----+---+------ > > > | | | | | | | | | | | | .... > > > +-----+----+----+----+----+----+----+----+----+----+---+------ > > > > > > Each block is of fixed size, say 8192 bytes. Now I have a user program > > > writing each contiguously laid out block sequentially using /dev/daxxx > > > interface. There are a lot of them, say 15000. I write the blocks in two > > > ways (the data used in writing are garbage): > > > > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > > > (2) I still write these blocks sequentially, but for each block I only > > > write part of it. Exactly how many bytes are written inside each > block is > > > determinted by a random number between 512 .. 8192 bytes (rounded up a > > > to multiple of 512 bytes). > > > > > > I find out the the performance of (2) is several times better than the > > > performance of (1). Can anyone explain to me why this is the case? > > > > > > Thanks for any suggestions or hints. > > > > > > -Zhihui > > > > > > > > > > > > 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 Tue Mar 5 13:57:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by hub.freebsd.org (Postfix) with ESMTP id BF1FD37B400 for ; Tue, 5 Mar 2002 13:57:06 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailg.telia.com (8.11.6/8.11.6) with ESMTP id g25Lv4H02869 for ; Tue, 5 Mar 2002 22:57:04 +0100 (CET) Received: from falcon.midgard.homeip.net (h217n1fls20o913.telia.com [212.181.162.217]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id WAA16673 for ; Tue, 5 Mar 2002 22:57:04 +0100 (CET) Received: (qmail 76756 invoked by uid 1001); 5 Mar 2002 21:57:03 -0000 Date: Tue, 5 Mar 2002 22:57:03 +0100 From: Erik Trulsson To: Kenneth Culver Cc: Terry Lambert , "Steve B." , "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ Message-ID: <20020305215702.GA76733@student.uu.se> Mail-Followup-To: Kenneth Culver , Terry Lambert , "Steve B." , "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG References: <3C8529DA.FA8ABCE@mindspring.com> <20020305164151.T5854-100000@alpha.yumyumyum.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020305164151.T5854-100000@alpha.yumyumyum.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 04:43:22PM -0500, Kenneth Culver wrote: > > Because that underlying assumption is false, and I'm making > > fun of it. > > > Well, that in itself is wrong. C++ code IS harder to write and write > correctly and effeciently, as I would assume it is for any OO language. > I'm not saying it can't be done, but generally speaking based on the Open > source and commercial products I've seen, the ones that are written in C++ > suffer from more bloat and run slower. But you don't need to write OO code just because you use C++. You can write code in C++ exactly the way you do it in C if you want. There is no advantage of C++ over C when used this way but no disadvantage either. I do agree that when the extra features of C++ are used this often results in bloated programs but this can at least in part be blamed on insufficiently skilled programmers. Note that C++ is not really an OO language. It is probably better to call it a language with support for object-oriented programming (as well as support for other programming styles.) -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 14: 6: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 9609537B400 for ; Tue, 5 Mar 2002 14:05:56 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g25M5CP20332; Tue, 5 Mar 2002 17:05:12 -0500 (EST) Date: Tue, 5 Mar 2002 17:03:28 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: "Rogier R. Mulhuijzen" Cc: Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <5.1.0.14.0.20020305225819.01c3a678@mail.drwilco.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: > At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: > > > >On Tue, 5 Mar 2002, Julian Elischer wrote: > > > > > > > > more writes fit in the disk's write cache? > > > >For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * > >4096 bytes in all (assuming the random number distributes evenly between 0 > >and 8192). So your suggestion does not make sense to me. > > How large is your buffercache? it might be that the 15000 * ~4096 roughly > matches with your cache, and 15000 * 8912 doesn't. > > Case (1) would require a lot more physical IO in that case than case (2) > would require. > > Doc > > > >-Zhihui > > > > > On Tue, 5 Mar 2002, Zhihui Zhang wrote: > > > > > > > > > > > I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. > > > > This situation is like this: > > > > > > > > +-----+----+----+----+----+----+----+----+----+----+---+------ > > > > | | | | | | | | | | | | .... > > > > +-----+----+----+----+----+----+----+----+----+----+---+------ > > > > > > > > Each block is of fixed size, say 8192 bytes. Now I have a user program > > > > writing each contiguously laid out block sequentially using /dev/daxxx > > > > interface. There are a lot of them, say 15000. I write the blocks in two > > > > ways (the data used in writing are garbage): > > > > > > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > > > > > (2) I still write these blocks sequentially, but for each block I only > > > > write part of it. Exactly how many bytes are written inside each > > block is > > > > determinted by a random number between 512 .. 8192 bytes (rounded up a > > > > to multiple of 512 bytes). > > > > > > > > I find out the the performance of (2) is several times better than the > > > > performance of (1). Can anyone explain to me why this is the case? > > > > > > > > Thanks for any suggestions or hints. > > > > > > > > -Zhihui > > > > > > > > > > > > > > > > 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 Tue Mar 5 14: 9:13 2002 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 8E36B37B402; Tue, 5 Mar 2002 14:08:58 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 88F055347; Tue, 5 Mar 2002 23:08:56 +0100 (CET) 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: Patrick Thomas Cc: , Subject: Re: Four misc. questions related to jail usage References: <20020226154918.D34815-100000@utility.clubscholarship.com> From: Dag-Erling Smorgrav Date: 05 Mar 2002 23:08:55 +0100 In-Reply-To: <20020226154918.D34815-100000@utility.clubscholarship.com> Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas writes: > 1. Does each jail need to have its own proc filesystem mounted? No, procfs is pretty much useless these days (except for truss). > 2. Does kern.maxproc scale in a linear fashion with maxusers ? The default value for kern.maxproc is 20 + 16 * maxusers. > 4. Why is it that some linux utilities, run inside a jail, get the > hostname of the host machine, and not the hostname of the jail itself? It's a bug. It was fixed recently (in the last few days) in -CURRENT. 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 Mar 5 14:23: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 4F9B637B402; Tue, 5 Mar 2002 14:22:56 -0800 (PST) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g25ML9e63423; Tue, 5 Mar 2002 14:21:09 -0800 (PST) (envelope-from root@utility.clubscholarship.com) Date: Tue, 5 Mar 2002 14:21:09 -0800 (PST) From: Patrick Thomas To: Leo Bicknell Cc: Paul Halliday , , Subject: Re: cannot get more than 32 PTYs in 4.4-RELEASE In-Reply-To: <20020305152423.GA45816@ussenterprise.ufp.org> Message-ID: <20020305142030.B63417-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok, see the point is, I have _already done this_ > sh MAKEDEV pty0 # 0-31 > sh MAKEDEV pty1 # 32-63 > sh MAKEDEV pty2 # 64-95 > sh MAKEDEV pty3 # 96-127 > sh MAKEDEV pty4 # 128-159 xterm won't recognize by default > sh MAKEDEV pty5 # 160-191 xterm won't recognize by default > sh MAKEDEV pty6 # 192-223 xterm won't recognize by default > sh MAKEDEV pty7 # 224-255 xterm won't recognize by default These are the exact commands I used with `sh MAKEDEV` to create my 256 pty /dev entries. So to recap, all 256 /dev files are there, all 256 entries are in /etc/ttys (and were there by default) and I have: maxusers 128 and pseudo-device pty 128 in my kernel. And when I create 32 screens with `screen`, nobody else can login by any method (ssh, telnet, etc.). (No more PTYs error, etc.) What am I missing here ? Please note that this is 4.4-RELEASE - this doesn't seem to be a problem in 4.5.... thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15: 3:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id AF52B37B405 for ; Tue, 5 Mar 2002 15:03:10 -0800 (PST) Received: from isi.edu (3cgk7web390doocu@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g25N30011282; Tue, 5 Mar 2002 15:03:00 -0800 (PST) Message-ID: <3C854EA4.5040306@isi.edu> Date: Tue, 05 Mar 2002 15:03:00 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020224 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Zhihui Zhang Cc: "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080100050401080908070407" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms080100050401080908070407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: > The machine has 128M memory. I am doing physical I/O one block at a time, > so there should be no memory copy. > > -Zhihui > > On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: > > >>At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: >> >> >> >>>On Tue, 5 Mar 2002, Julian Elischer wrote: >>> >>> >>>>more writes fit in the disk's write cache? >>>> >>>For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * >>>4096 bytes in all (assuming the random number distributes evenly between 0 >>>and 8192). So your suggestion does not make sense to me. >>> >>How large is your buffercache? it might be that the 15000 * ~4096 roughly >>matches with your cache, and 15000 * 8912 doesn't. >> >>Case (1) would require a lot more physical IO in that case than case (2) >>would require. >> >> Doc >> >> >> >>>-Zhihui >>> >>> >>>>On Tue, 5 Mar 2002, Zhihui Zhang wrote: >>>> >>>> >>>>>I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. >>>>>This situation is like this: >>>>> >>>>> +-----+----+----+----+----+----+----+----+----+----+---+------ >>>>> | | | | | | | | | | | | .... >>>>> +-----+----+----+----+----+----+----+----+----+----+---+------ >>>>> >>>>>Each block is of fixed size, say 8192 bytes. Now I have a user program >>>>>writing each contiguously laid out block sequentially using /dev/daxxx >>>>>interface. There are a lot of them, say 15000. I write the blocks in two >>>>>ways (the data used in writing are garbage): >>>>> >>>>>(1) Write each block fully and sequentially, ie. 8192 bytes. >>>>> >>>>>(2) I still write these blocks sequentially, but for each block I only >>>>>write part of it. Exactly how many bytes are written inside each >>>>> >>>block is >>> >>>>>determinted by a random number between 512 .. 8192 bytes (rounded up a >>>>>to multiple of 512 bytes). >>>>> >>>>>I find out the the performance of (2) is several times better than the >>>>>performance of (1). Can anyone explain to me why this is the case? >>>>> >>>>>Thanks for any suggestions or hints. >>>>> >>>>>-Zhihui >>>>> >>>>> >>>>> >>>>>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 > -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms080100050401080908070407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDMwNTIzMDMwMFowIwYJKoZIhvcNAQkEMRYEFFyar+SVdjSFeUT7YrQK6IjUM1hKMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYBa6zuSrlbCEfIL9G1xVed9aj1H97KKChWDfYcupsH7VnljgCRnoNLT9+dKqZBaePUU YvvTWhTmA0HBxWw4Cw4tfGMh57NvPScNKk4dKJ02U9BQLNWIC20Zr/HpyaH7LvEp5M4ffmia LGxK5Dxj8QClkvbajJZhiRlLOW9+eSdEIgAAAAAAAA== --------------ms080100050401080908070407-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:15:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 58F3A37B41C for ; Tue, 5 Mar 2002 15:14:26 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g25NBvP02446; Tue, 5 Mar 2002 18:11:57 -0500 (EST) Date: Tue, 5 Mar 2002 18:10:13 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Lars Eggert Cc: "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <3C854EA4.5040306@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, the core of my program is as follows (RANDOM(x) return a value between 0 and x): blocksize = 8192; write_size_low = 512; time(&time1); for (i = 0; i < write_count; i++) { write_size = write_size_low + RANDOM(write_size_high-write_size_low); write_size = roundup(write_size, DEV_BSIZE); if (testcase == 1) write_size = blocksize; write_block(rawfd, sectorno, buf, write_size); sectorno += blocksize / DEV_BSIZE; } time(&time2); If testcase is one, then the time elapsed (time2 - time1) is much less. -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: > I agree that it's probably caching at some level. You're only writing > about 120MB of data (and half that in your second case). Bump these to a > couple of GB and see what happens. > > Also, could you post your actual measurements? > > Lars > > > Zhihui Zhang wrote: > > The machine has 128M memory. I am doing physical I/O one block at a time, > > so there should be no memory copy. > > > > -Zhihui > > > > On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: > > > > > >>At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: > >> > >> > >> > >>>On Tue, 5 Mar 2002, Julian Elischer wrote: > >>> > >>> > >>>>more writes fit in the disk's write cache? > >>>> > >>>For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * > >>>4096 bytes in all (assuming the random number distributes evenly between 0 > >>>and 8192). So your suggestion does not make sense to me. > >>> > >>How large is your buffercache? it might be that the 15000 * ~4096 roughly > >>matches with your cache, and 15000 * 8912 doesn't. > >> > >>Case (1) would require a lot more physical IO in that case than case (2) > >>would require. > >> > >> Doc > >> > >> > >> > >>>-Zhihui > >>> > >>> > >>>>On Tue, 5 Mar 2002, Zhihui Zhang wrote: > >>>> > >>>> > >>>>>I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. > >>>>>This situation is like this: > >>>>> > >>>>> +-----+----+----+----+----+----+----+----+----+----+---+------ > >>>>> | | | | | | | | | | | | .... > >>>>> +-----+----+----+----+----+----+----+----+----+----+---+------ > >>>>> > >>>>>Each block is of fixed size, say 8192 bytes. Now I have a user program > >>>>>writing each contiguously laid out block sequentially using /dev/daxxx > >>>>>interface. There are a lot of them, say 15000. I write the blocks in two > >>>>>ways (the data used in writing are garbage): > >>>>> > >>>>>(1) Write each block fully and sequentially, ie. 8192 bytes. > >>>>> > >>>>>(2) I still write these blocks sequentially, but for each block I only > >>>>>write part of it. Exactly how many bytes are written inside each > >>>>> > >>>block is > >>> > >>>>>determinted by a random number between 512 .. 8192 bytes (rounded up a > >>>>>to multiple of 512 bytes). > >>>>> > >>>>>I find out the the performance of (2) is several times better than the > >>>>>performance of (1). Can anyone explain to me why this is the case? > >>>>> > >>>>>Thanks for any suggestions or hints. > >>>>> > >>>>>-Zhihui > >>>>> > >>>>> > >>>>> > >>>>>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 > > > > > > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:21:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 3807837B486 for ; Tue, 5 Mar 2002 15:19:24 -0800 (PST) Received: from isi.edu (u0gbnxykwwpm9bm0@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g25NJK021938; Tue, 5 Mar 2002 15:19:20 -0800 (PST) Message-ID: <3C855278.9040504@isi.edu> Date: Tue, 05 Mar 2002 15:19:20 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020224 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Zhihui Zhang Cc: "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040308070809020504010607" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms040308070809020504010607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Zhihui Zhang wrote: > Well, the core of my program is as follows (RANDOM(x) return a value > between 0 and x): > > blocksize = 8192; > write_size_low = 512; > > time(&time1); > for (i = 0; i < write_count; i++) { > write_size = write_size_low + > RANDOM(write_size_high-write_size_low); > write_size = roundup(write_size, DEV_BSIZE); > if (testcase == 1) > write_size = blocksize; > write_block(rawfd, sectorno, buf, write_size); > sectorno += blocksize / DEV_BSIZE; > } > time(&time2); > > If testcase is one, then the time elapsed (time2 - time1) is much less. How "much less" in milliseconds? Also, in your original mail, you said you had 15,000 of these 8K blocks, which is only 120MB or so. Use 150,000 or 1,500,000 and check your results then. Lars > -Zhihui > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > >>I agree that it's probably caching at some level. You're only writing >>about 120MB of data (and half that in your second case). Bump these to a >>couple of GB and see what happens. >> >>Also, could you post your actual measurements? >> >>Lars >> >> >>Zhihui Zhang wrote: >> >>>The machine has 128M memory. I am doing physical I/O one block at a time, >>>so there should be no memory copy. >>> >>>-Zhihui >>> >>>On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: >>> >>> >>> >>>>At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: >>>> >>>> >>>> >>>> >>>>>On Tue, 5 Mar 2002, Julian Elischer wrote: >>>>> >>>>> >>>>> >>>>>>more writes fit in the disk's write cache? >>>>>> >>>>>> >>>>>For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * >>>>>4096 bytes in all (assuming the random number distributes evenly between 0 >>>>>and 8192). So your suggestion does not make sense to me. >>>>> >>>>> >>>>How large is your buffercache? it might be that the 15000 * ~4096 roughly >>>>matches with your cache, and 15000 * 8912 doesn't. >>>> >>>>Case (1) would require a lot more physical IO in that case than case (2) >>>>would require. >>>> >>>> Doc >>>> >>>> >>>> >>>> >>>>>-Zhihui >>>>> >>>>> >>>>> >>>>>>On Tue, 5 Mar 2002, Zhihui Zhang wrote: >>>>>> >>>>>> >>>>>> >>>>>>>I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. >>>>>>>This situation is like this: >>>>>>> >>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ >>>>>>>| | | | | | | | | | | | .... >>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ >>>>>>> >>>>>>>Each block is of fixed size, say 8192 bytes. Now I have a user program >>>>>>>writing each contiguously laid out block sequentially using /dev/daxxx >>>>>>>interface. There are a lot of them, say 15000. I write the blocks in two >>>>>>>ways (the data used in writing are garbage): >>>>>>> >>>>>>>(1) Write each block fully and sequentially, ie. 8192 bytes. >>>>>>> >>>>>>>(2) I still write these blocks sequentially, but for each block I only >>>>>>>write part of it. Exactly how many bytes are written inside each >>>>>>> >>>>>>> >>>>>block is >>>>> >>>>> >>>>>>>determinted by a random number between 512 .. 8192 bytes (rounded up a >>>>>>>to multiple of 512 bytes). >>>>>>> >>>>>>>I find out the the performance of (2) is several times better than the >>>>>>>performance of (1). Can anyone explain to me why this is the case? >>>>>>> >>>>>>>Thanks for any suggestions or hints. >>>>>>> >>>>>>>-Zhihui >>>>>>> >>>>>>> >>>>>>> >>>>>>>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 >>> >>> >> >> >>-- >>Lars Eggert Information Sciences Institute >>http://www.isi.edu/larse/ University of Southern California >> >> > -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms040308070809020504010607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDMwNTIzMTkyMFowIwYJKoZIhvcNAQkEMRYEFDNiROpHHyPj3j2F/4yqv1TKDkgYMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCNmzwowVRhj8pRFsmXXLMm12hUcRvfVccoHzszwtX/ZRbKteXOUbalcAgLQVn+Ovxv 2o7gY4H4RlNFLIGR1wmhPgjosGd+t1BIcoVxl2n8nfxJpRGNTZSQt4eM0mfDPBYtIXhrHcos 3XQI+uU2Kn073UKzyHCYjA2zqim+tIjhLQAAAAAAAA== --------------ms040308070809020504010607-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:23: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 66A8337B629 for ; Tue, 5 Mar 2002 15:21:23 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g25NLFP07134; Tue, 5 Mar 2002 18:21:15 -0500 (EST) Date: Tue, 5 Mar 2002 18:19:31 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Lars Eggert Cc: "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <3C855278.9040504@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Several times slower! The point is that writing less data performs worse. So I call it weird. -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: > Zhihui Zhang wrote: > > Well, the core of my program is as follows (RANDOM(x) return a value > > between 0 and x): > > > > blocksize = 8192; > > write_size_low = 512; > > > > time(&time1); > > for (i = 0; i < write_count; i++) { > > write_size = write_size_low + > > RANDOM(write_size_high-write_size_low); > > write_size = roundup(write_size, DEV_BSIZE); > > if (testcase == 1) > > write_size = blocksize; > > write_block(rawfd, sectorno, buf, write_size); > > sectorno += blocksize / DEV_BSIZE; > > } > > time(&time2); > > > > If testcase is one, then the time elapsed (time2 - time1) is much less. > > How "much less" in milliseconds? > > Also, in your original mail, you said you had 15,000 of these 8K blocks, > which is only 120MB or so. Use 150,000 or 1,500,000 and check your > results then. > > Lars > > > > > -Zhihui > > > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > > > > >>I agree that it's probably caching at some level. You're only writing > >>about 120MB of data (and half that in your second case). Bump these to a > >>couple of GB and see what happens. > >> > >>Also, could you post your actual measurements? > >> > >>Lars > >> > >> > >>Zhihui Zhang wrote: > >> > >>>The machine has 128M memory. I am doing physical I/O one block at a time, > >>>so there should be no memory copy. > >>> > >>>-Zhihui > >>> > >>>On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: > >>> > >>> > >>> > >>>>At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>On Tue, 5 Mar 2002, Julian Elischer wrote: > >>>>> > >>>>> > >>>>> > >>>>>>more writes fit in the disk's write cache? > >>>>>> > >>>>>> > >>>>>For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * > >>>>>4096 bytes in all (assuming the random number distributes evenly between 0 > >>>>>and 8192). So your suggestion does not make sense to me. > >>>>> > >>>>> > >>>>How large is your buffercache? it might be that the 15000 * ~4096 roughly > >>>>matches with your cache, and 15000 * 8912 doesn't. > >>>> > >>>>Case (1) would require a lot more physical IO in that case than case (2) > >>>>would require. > >>>> > >>>> Doc > >>>> > >>>> > >>>> > >>>> > >>>>>-Zhihui > >>>>> > >>>>> > >>>>> > >>>>>>On Tue, 5 Mar 2002, Zhihui Zhang wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. > >>>>>>>This situation is like this: > >>>>>>> > >>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ > >>>>>>>| | | | | | | | | | | | .... > >>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ > >>>>>>> > >>>>>>>Each block is of fixed size, say 8192 bytes. Now I have a user program > >>>>>>>writing each contiguously laid out block sequentially using /dev/daxxx > >>>>>>>interface. There are a lot of them, say 15000. I write the blocks in two > >>>>>>>ways (the data used in writing are garbage): > >>>>>>> > >>>>>>>(1) Write each block fully and sequentially, ie. 8192 bytes. > >>>>>>> > >>>>>>>(2) I still write these blocks sequentially, but for each block I only > >>>>>>>write part of it. Exactly how many bytes are written inside each > >>>>>>> > >>>>>>> > >>>>>block is > >>>>> > >>>>> > >>>>>>>determinted by a random number between 512 .. 8192 bytes (rounded up a > >>>>>>>to multiple of 512 bytes). > >>>>>>> > >>>>>>>I find out the the performance of (2) is several times better than the > >>>>>>>performance of (1). Can anyone explain to me why this is the case? > >>>>>>> > >>>>>>>Thanks for any suggestions or hints. > >>>>>>> > >>>>>>>-Zhihui > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>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 > >>> > >>> > >> > >> > >>-- > >>Lars Eggert Information Sciences Institute > >>http://www.isi.edu/larse/ University of Southern California > >> > >> > > > > > > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:23: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 3582B37B634 for ; Tue, 5 Mar 2002 15:21:38 -0800 (PST) Received: from hades.hell.gr (patr530-a217.otenet.gr [212.205.215.217]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g25NLWDg003506; Wed, 6 Mar 2002 01:21:33 +0200 (EET) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g25NLd0O006431; Wed, 6 Mar 2002 01:21:39 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g25NCr7Y006048; Wed, 6 Mar 2002 01:12:53 +0200 (EET) (envelope-from keramida@freebsd.org) X-Authentication-Warning: hades.hell.gr: charon set sender to keramida@freebsd.org using -f Date: Wed, 6 Mar 2002 01:12:52 +0200 From: Giorgos Keramidas To: "Steve B." Cc: freebsd-hackers@freebsd.org Subject: Re: C vs C++ Message-ID: <20020305231252.GC5328@hades.hell.gr> References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <001701c1c481$d0d5eab0$f642d9cf@DROID> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001701c1c481$d0d5eab0$f642d9cf@DROID> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-03-05 12:10, Steve B. wrote: > I wouldn't say C++ is THAT much harder to write, it does have a steeper > initial learning curve than C. Most of that is due to needing to learn OOP > at the same time. A point which is made irrelevant if you want to make a comparison of the learning curves, by taking two persons who have no prior experience to programming, and teach procedural programming to one of them, while teaching object-oriented programming to the second. The steeper learning curve of C++ is indeed steeper, not because of some magic property of the object-oriented programming paradigm, but because there are a lot more things to learn, before a complete program can be written, IMHO. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:24:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 4F0EB37B637 for ; Tue, 5 Mar 2002 15:21:41 -0800 (PST) Received: from hades.hell.gr (patr530-a217.otenet.gr [212.205.215.217]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g25NLWDg003509; Wed, 6 Mar 2002 01:21:33 +0200 (EET) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g25NLd0Q006431; Wed, 6 Mar 2002 01:21:39 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g25N5aN2006018; Wed, 6 Mar 2002 01:05:36 +0200 (EET) (envelope-from keramida@freebsd.org) X-Authentication-Warning: hades.hell.gr: charon set sender to keramida@freebsd.org using -f Date: Wed, 6 Mar 2002 01:05:35 +0200 From: Giorgos Keramidas To: Kenneth Culver Cc: Terry Lambert , freebsd-hackers@freebsd.org Subject: Re: C vs C++ Message-ID: <20020305230535.GB5328@hades.hell.gr> References: <3C850540.EA8EDE0F@mindspring.com> <20020305132457.A4700-100000@alpha.yumyumyum.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020305132457.A4700-100000@alpha.yumyumyum.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ Top-posting edited off. Please, try to avoid top-posting. ] On 2002-03-05 13:25, Kenneth Culver wrote: > On Tue, 5 Mar 2002, Terry Lambert wrote: > > "Steve B." wrote: > > > I take a simplistic view after years of C++. > > > > > > C++ is good for large projects that need to be maintained into the future. > > > Then the advantages of OO starts to kick in. For small projects that won't > > > change much then C is the better choice IMO. > > > > Wow. Forgot this disadvantage of C++, too. > > > > Yeah, it's difficult to write code that someone else > > couldn't come in and maintain after it was done. This > > means that the normal rules about "write important code > > and you have a job forever" no longer apply. 8-(. > > Why are you being so sarcastic? Everyone here is assuming that it's harder > to write C++ code, so you should only use it if necessary. It isn't > necessary to use it for something like a daemon. Apart from the obvious reason that someone has to be the devil's advocate, otherwise the thread will die, and I won't have anything to download in my mailboxes... Terry is right, although he chose a humorous[1] way to list his arguments :-) Terry suggested in his post (yes, the same one you find sarcastic), that C++ code can be written in ways that will help maintaining it later on. The object oriented methodology of programming, is not necessarily bad, and the Evil That Should Die(TM). There are good things about it, and there are bad things about it too. [1] Let us not forget that sarcasm, is in fact a form of humour. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:26:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 4325737B402 for ; Tue, 5 Mar 2002 15:26:39 -0800 (PST) Received: from isi.edu (m7qbo0tn7en1czh1@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g25NQa026901; Tue, 5 Mar 2002 15:26:36 -0800 (PST) Message-ID: <3C85542B.5060100@isi.edu> Date: Tue, 05 Mar 2002 15:26:35 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020224 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Zhihui Zhang Cc: "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060700090007060508010205" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms060700090007060508010205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Zhihui Zhang wrote: > Several times slower! The point is that writing less data performs > worse. So I call it weird. Huh? You originally said: > (1) Write each block fully and sequentially, ie. 8192 bytes. > > (2) I still write these blocks sequentially, but for each block I only > write part of it. ... > I find out the the performance of (2) is several times better than the > performance of (1). Can anyone explain to me why this is the case? If (2) is better than (1), then writing *less* data is faster. Which is it, now? Lars > -Zhihui > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > >>Zhihui Zhang wrote: >> >>>Well, the core of my program is as follows (RANDOM(x) return a value >>>between 0 and x): >>> >>> blocksize = 8192; >>> write_size_low = 512; >>> >>> time(&time1); >>> for (i = 0; i < write_count; i++) { >>> write_size = write_size_low + >>> RANDOM(write_size_high-write_size_low); >>> write_size = roundup(write_size, DEV_BSIZE); >>> if (testcase == 1) >>> write_size = blocksize; >>> write_block(rawfd, sectorno, buf, write_size); >>> sectorno += blocksize / DEV_BSIZE; >>> } >>> time(&time2); >>> >>>If testcase is one, then the time elapsed (time2 - time1) is much less. >>> >>How "much less" in milliseconds? >> >>Also, in your original mail, you said you had 15,000 of these 8K blocks, >>which is only 120MB or so. Use 150,000 or 1,500,000 and check your >>results then. >> >>Lars >> >> >> >> >>>-Zhihui >>> >>>On Tue, 5 Mar 2002, Lars Eggert wrote: >>> >>> >>> >>>>I agree that it's probably caching at some level. You're only writing >>>>about 120MB of data (and half that in your second case). Bump these to a >>>>couple of GB and see what happens. >>>> >>>>Also, could you post your actual measurements? >>>> >>>>Lars >>>> >>>> >>>>Zhihui Zhang wrote: >>>> >>>> >>>>>The machine has 128M memory. I am doing physical I/O one block at a time, >>>>>so there should be no memory copy. >>>>> >>>>>-Zhihui >>>>> >>>>>On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>On Tue, 5 Mar 2002, Julian Elischer wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>more writes fit in the disk's write cache? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * >>>>>>>4096 bytes in all (assuming the random number distributes evenly between 0 >>>>>>>and 8192). So your suggestion does not make sense to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>How large is your buffercache? it might be that the 15000 * ~4096 roughly >>>>>>matches with your cache, and 15000 * 8912 doesn't. >>>>>> >>>>>>Case (1) would require a lot more physical IO in that case than case (2) >>>>>>would require. >>>>>> >>>>>> Doc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-Zhihui >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>On Tue, 5 Mar 2002, Zhihui Zhang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. >>>>>>>>>This situation is like this: >>>>>>>>> >>>>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ >>>>>>>>>| | | | | | | | | | | | .... >>>>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ >>>>>>>>> >>>>>>>>>Each block is of fixed size, say 8192 bytes. Now I have a user program >>>>>>>>>writing each contiguously laid out block sequentially using /dev/daxxx >>>>>>>>>interface. There are a lot of them, say 15000. I write the blocks in two >>>>>>>>>ways (the data used in writing are garbage): >>>>>>>>> >>>>>>>>>(1) Write each block fully and sequentially, ie. 8192 bytes. >>>>>>>>> >>>>>>>>>(2) I still write these blocks sequentially, but for each block I only >>>>>>>>>write part of it. Exactly how many bytes are written inside each >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>block is >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>determinted by a random number between 512 .. 8192 bytes (rounded up a >>>>>>>>>to multiple of 512 bytes). >>>>>>>>> >>>>>>>>>I find out the the performance of (2) is several times better than the >>>>>>>>>performance of (1). Can anyone explain to me why this is the case? >>>>>>>>> >>>>>>>>>Thanks for any suggestions or hints. >>>>>>>>> >>>>>>>>>-Zhihui >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>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 >>>>> >>>>> >>>>> >>>> >>>>-- >>>>Lars Eggert Information Sciences Institute >>>>http://www.isi.edu/larse/ University of Southern California >>>> >>>> >>>> >> >> >>-- >>Lars Eggert Information Sciences Institute >>http://www.isi.edu/larse/ University of Southern California >> >> -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms060700090007060508010205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDMwNTIzMjYzNVowIwYJKoZIhvcNAQkEMRYEFMWZOpDuO7PQ+bNpkucu/8Qm7b1MMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYDDwsUBbaGtoiPzexH/wwEOFloeHsS0YSU9VudcX1gBRzkiN4OFSlNyWsbAPjnnKbzI U85nznR2Cf2jVGXmMAy5dZCusDoA80iGuYFMQMkV6/8e/2F5UiKdkdRcRiNydf/0nY+wJhGd pb2l5TqKIZTZ+A5nAEWcIMS0T0vnkdsxiAAAAAAAAA== --------------ms060700090007060508010205-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:27:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 0DBD437B402 for ; Tue, 5 Mar 2002 15:27:49 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g25NRaV15221 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 5 Mar 2002 18:27:38 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020306003735.01c3aa18@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 00:38:27 +0100 To: Zhihui Zhang , Lars Eggert From: "Rogier R. Mulhuijzen" Subject: Re: A weird disk behaviour Cc: Julian Elischer , freebsd-hackers@FreeBSD.ORG In-Reply-To: References: <3C855278.9040504@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Wait a minute, you are saying that it takes longer to write the incomplete blocks? Doc At 18:19 5-3-2002 -0500, Zhihui Zhang wrote: >Several times slower! The point is that writing less data performs >worse. So I call it weird. > >-Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:35: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 3D66C37B404 for ; Tue, 5 Mar 2002 15:34:49 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g25NYcP14372; Tue, 5 Mar 2002 18:34:38 -0500 (EST) Date: Tue, 5 Mar 2002 18:32:54 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Lars Eggert Cc: "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <3C85542B.5060100@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I apologize for all who have followed this. I made a typo in the original email. What I observed is that writing LESS performs WORSE. Since all blocks are laid out contiguously and I write them sequentially, there should not be any seek problem. I have modified the kernel in kern_physio.c and find out that physio() is called by expected number of times. I even add some code to record the time elapsed there: t1 = time_second; BUF_STRATEGY(bp, 0); spl = splbio(); while ((bp->b_flags & B_DONE) == 0) tsleep((caddr_t)bp, PRIBIO, "physstr", 0); splx(spl); t2 = time_second; physio_time += t2 - t1; the physio_time (a sysctl variable) is close to the time reported by the user program. -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: > Zhihui Zhang wrote: > > Several times slower! The point is that writing less data performs > > worse. So I call it weird. > > Huh? You originally said: > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > (2) I still write these blocks sequentially, but for each block I only > > write part of it. > ... > > I find out the the performance of (2) is several times better than the > > performance of (1). Can anyone explain to me why this is the case? > > If (2) is better than (1), then writing *less* data is faster. Which is > it, now? > > Lars > > > > > -Zhihui > > > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > > > > >>Zhihui Zhang wrote: > >> > >>>Well, the core of my program is as follows (RANDOM(x) return a value > >>>between 0 and x): > >>> > >>> blocksize = 8192; > >>> write_size_low = 512; > >>> > >>> time(&time1); > >>> for (i = 0; i < write_count; i++) { > >>> write_size = write_size_low + > >>> RANDOM(write_size_high-write_size_low); > >>> write_size = roundup(write_size, DEV_BSIZE); > >>> if (testcase == 1) > >>> write_size = blocksize; > >>> write_block(rawfd, sectorno, buf, write_size); > >>> sectorno += blocksize / DEV_BSIZE; > >>> } > >>> time(&time2); > >>> > >>>If testcase is one, then the time elapsed (time2 - time1) is much less. > >>> > >>How "much less" in milliseconds? > >> > >>Also, in your original mail, you said you had 15,000 of these 8K blocks, > >>which is only 120MB or so. Use 150,000 or 1,500,000 and check your > >>results then. > >> > >>Lars > >> > >> > >> > >> > >>>-Zhihui > >>> > >>>On Tue, 5 Mar 2002, Lars Eggert wrote: > >>> > >>> > >>> > >>>>I agree that it's probably caching at some level. You're only writing > >>>>about 120MB of data (and half that in your second case). Bump these to a > >>>>couple of GB and see what happens. > >>>> > >>>>Also, could you post your actual measurements? > >>>> > >>>>Lars > >>>> > >>>> > >>>>Zhihui Zhang wrote: > >>>> > >>>> > >>>>>The machine has 128M memory. I am doing physical I/O one block at a time, > >>>>>so there should be no memory copy. > >>>>> > >>>>>-Zhihui > >>>>> > >>>>>On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>On Tue, 5 Mar 2002, Julian Elischer wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>more writes fit in the disk's write cache? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * > >>>>>>>4096 bytes in all (assuming the random number distributes evenly between 0 > >>>>>>>and 8192). So your suggestion does not make sense to me. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>How large is your buffercache? it might be that the 15000 * ~4096 roughly > >>>>>>matches with your cache, and 15000 * 8912 doesn't. > >>>>>> > >>>>>>Case (1) would require a lot more physical IO in that case than case (2) > >>>>>>would require. > >>>>>> > >>>>>> Doc > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>-Zhihui > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>On Tue, 5 Mar 2002, Zhihui Zhang wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. > >>>>>>>>>This situation is like this: > >>>>>>>>> > >>>>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ > >>>>>>>>>| | | | | | | | | | | | .... > >>>>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ > >>>>>>>>> > >>>>>>>>>Each block is of fixed size, say 8192 bytes. Now I have a user program > >>>>>>>>>writing each contiguously laid out block sequentially using /dev/daxxx > >>>>>>>>>interface. There are a lot of them, say 15000. I write the blocks in two > >>>>>>>>>ways (the data used in writing are garbage): > >>>>>>>>> > >>>>>>>>>(1) Write each block fully and sequentially, ie. 8192 bytes. > >>>>>>>>> > >>>>>>>>>(2) I still write these blocks sequentially, but for each block I only > >>>>>>>>>write part of it. Exactly how many bytes are written inside each > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>block is > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>determinted by a random number between 512 .. 8192 bytes (rounded up a > >>>>>>>>>to multiple of 512 bytes). > >>>>>>>>> > >>>>>>>>>I find out the the performance of (2) is several times better than the > >>>>>>>>>performance of (1). Can anyone explain to me why this is the case? > >>>>>>>>> > >>>>>>>>>Thanks for any suggestions or hints. > >>>>>>>>> > >>>>>>>>>-Zhihui > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>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 > >>>>> > >>>>> > >>>>> > >>>> > >>>>-- > >>>>Lars Eggert Information Sciences Institute > >>>>http://www.isi.edu/larse/ University of Southern California > >>>> > >>>> > >>>> > >> > >> > >>-- > >>Lars Eggert Information Sciences Institute > >>http://www.isi.edu/larse/ University of Southern California > >> > >> > > > > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:40:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 702D837B405 for ; Tue, 5 Mar 2002 15:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305234008.XUQV2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 23:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA33117; Tue, 5 Mar 2002 15:30:00 -0800 (PST) Date: Tue, 5 Mar 2002 15:29:59 -0800 (PST) From: Julian Elischer To: Lars Eggert Cc: Zhihui Zhang , "Rogier R. Mulhuijzen" , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <3C85542B.5060100@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, Lars Eggert wrote: > Zhihui Zhang wrote: > > Several times slower! The point is that writing less data performs > > worse. So I call it weird. > > Huh? You originally said: > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > (2) I still write these blocks sequentially, but for each block I only > > write part of it. > ... > > I find out the the performance of (2) is several times better than the > > performance of (1). Can anyone explain to me why this is the case? > > If (2) is better than (1), then writing *less* data is faster. Which is > it, now? > Um yeah that is what all my suggestions were based on.. > Lars > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:45:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id ED93C37B402 for ; Tue, 5 Mar 2002 15:45:32 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g25NjN776482; Tue, 5 Mar 2002 23:45:23 GMT (envelope-from mark@grimreaper.grondar.za) Received: from grimreaper (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.2/8.12.2) with ESMTP id g25NgTRV079032; Tue, 5 Mar 2002 23:42:29 GMT (envelope-from mark@grimreaper.grondar.za) Message-Id: <200203052342.g25NgTRV079032@grimreaper.grondar.org> To: Adrian Filipi-Martin Cc: FreeBSD Hackers List , kaj@ubergeeks.com Subject: Re: Intel 820 RNG References: <20020305135912.C52330-100000@lorax.ubergeeks.com> In-Reply-To: <20020305135912.C52330-100000@lorax.ubergeeks.com> ; from Adrian Filipi-Martin "Tue, 05 Mar 2002 14:38:11 EST." Date: Tue, 05 Mar 2002 23:42:29 +0000 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > We did make some enhancements that serve our needs, but may not be > best for everyone. We actually need entropy in quantity since we could be > doing a lot of crypto operations back to back and it can easily become our > worst bottleneck. Have you looked at the "Yarrow" algorithm? > To this end, we have an entropy buffer in kernel memory that pulls > large blocks of entropy from the RNG if it's going to read from it at all. > The device puts out several orders of magnitude more entropy than the > original drivers captured, and we needed as much as we could grab. > Ideally we would not mix the entropy into the entropy pool and just use the > high quality entropy from the buffer, but we decided to minimize divergence > from the original sources and not switch to 100% hardware entropy. In CURRENT, I have implemented Yarrow to achieve just this purpose. > The drawback to our approach is that it can spend a lot of time in > the kernel. To tune this behavior we added a few sysctl's. The start/stop > script after the diff's tweaks a few of these settings after boot up. Again, look at current. The RNG is _really_ fast. > I cc'd Kaj Groner, who actually did the work for us. He's not on > this list, so don't drop his address. I was more involved at the higher > levels of what we needed to get done when we rebased our appliance from > OpenBSD to FreeBSD last Summer. :-) You may be pleasantly surprised :-) M (Thanks for the sources!) -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 15:49:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id BA6D937B400 for ; Tue, 5 Mar 2002 15:49:35 -0800 (PST) Received: from hades.hell.gr (patr530-a217.otenet.gr [212.205.215.217]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g25NnSDg024641; Wed, 6 Mar 2002 01:49:29 +0200 (EET) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g25NnR0O006870; Wed, 6 Mar 2002 01:49:27 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g25NnRnn006869; Wed, 6 Mar 2002 01:49:27 +0200 (EET) (envelope-from keramida@freebsd.org) X-Authentication-Warning: hades.hell.gr: charon set sender to keramida@freebsd.org using -f Date: Wed, 6 Mar 2002 01:49:26 +0200 From: Giorgos Keramidas To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020305234926.GA6839@hades.hell.gr> References: <20020305201350.GC4820@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-03-05 12:59, Julian Elischer wrote: > > On Tue, 5 Mar 2002, Giorgos Keramidas wrote: > > > > > > Read the man page to try and decide if you should write "if (x)" or > > > if (x != 0). > > > > > > >Fix: > > > > > > Apply the attached page to the style(9) man page. > [...] > > the one that I stop to think about is: > > if (!(flags & FLAGSET)) > > or should that be > > if ((flags & FLAGSET) == 0) > > it depends on what you define as a Boolean. > > If FLAGSET has > 1 bit in it then it it still possibly a boolean? I was reading parts of the sys/netinet tree lately. Most of the places I have seen so far use the second style, even for flags that are stored in bitfields. Quoting ip_input.c: if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) == 0) { ipstat.ips_badaddr++; goto bad; } This is what I prefer too, but my own personal preference is probably based on what I've seen so far, which is (I have to admit) very limited. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16: 2:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id EF8CF37B400; Tue, 5 Mar 2002 16:02:52 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g2602rW38236; Tue, 5 Mar 2002 16:02:53 -0800 (PST) (envelope-from obrien) Date: Tue, 5 Mar 2002 15:58:50 -0800 From: "David O'Brien" To: Giorgos Keramidas Cc: hackers@freebsd.org Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020305155850.A38095@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20020305201350.GC4820@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020305201350.GC4820@hades.hell.gr>; from keramida@freebsd.org on Tue, Mar 05, 2002 at 10:13:50PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: > > -Don't use '!' for tests unless it's a boolean, e.g. use > > +For tests, always compare the value to the appropriate 0 instead of > > +checking it directly, unless the value is a boolean. > > +For pointers, use: > > +.Bd -literal > > +if (p != NULL) > > +.Ed > > +.Pp > > +not > > +.PP > > +.Bd -literal > > +if (!p) > > +.Ed > > +.Pp > > +For other values, use: > > .Bd -literal > > if (*p == '\e0') > > .Ed > > .Pp > > not > > .Bd -literal > > -if (!*p) > > +if (*p) > > +.Ed > > +.Pp > > +unless the value is a boolean. In that case, use: > > +.Bd -literal > > +if (p) > > +.Ed > > +.Pp > > +and > > +.Bd -literal > > +if (!p) Please show examples from /sys that back up this change. To state this explicitly, I think a significant number of /sys files should be following it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16: 8:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 8E0B537B400; Tue, 5 Mar 2002 16:08:10 -0800 (PST) Received: from hades.hell.gr (patr530-a217.otenet.gr [212.205.215.217]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g26087Dg008032; Wed, 6 Mar 2002 02:08:08 +0200 (EET) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g260870O007016; Wed, 6 Mar 2002 02:08:07 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g26087T9007015; Wed, 6 Mar 2002 02:08:07 +0200 (EET) (envelope-from keramida@freebsd.org) X-Authentication-Warning: hades.hell.gr: charon set sender to keramida@freebsd.org using -f Date: Wed, 6 Mar 2002 02:08:07 +0200 From: Giorgos Keramidas To: "David O'Brien" Cc: hackers@freebsd.org Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020306000806.GC6839@hades.hell.gr> References: <20020305201350.GC4820@hades.hell.gr> <20020305155850.A38095@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: application/pgp; x-action=sign; format=text Content-Disposition: inline; filename="msg.pgp" In-Reply-To: <20020305155850.A38095@dragon.nuxi.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2002-03-05 15:58, David O'Brien wrote: > On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: > > > -Don't use '!' for tests unless it's a boolean, e.g. use > > > +For tests, always compare the value to the appropriate 0 instead of > > > +checking it directly, unless the value is a boolean. ... > > Please show examples from /sys that back up this change. To state this > explicitly, I think a significant number of /sys files should be > following it. Actually I was asking for comments, but anyways. I will try to skim through the sources, and look for conditionals, to get the general feel of what is being used. I should note though, that I'm neither supporting or against this change. I'll see what I can do, and hopefully be able to post a followup sooner or later. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE8hV3m1g+UGjGGA7YRAnTFAJ9Ua0RAbgerbZmWfFAledzJ5xofCACfeiMe CbFAB4YXaf4r37+6Hn8Ye88= =uL9x -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:15:18 2002 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 31F1237B417; Tue, 5 Mar 2002 16:15:10 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA16204; Tue, 5 Mar 2002 17:15:07 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g260F6h27994; Tue, 5 Mar 2002 17:15:06 -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: <15493.24457.986109.726909@caddis.yogotech.com> Date: Tue, 5 Mar 2002 17:15:05 -0700 To: Kenneth Culver Cc: Terry Lambert , "Steve B." , "Eugene L. Vorokov" , Subject: Re: C vs C++ In-Reply-To: <20020305164151.T5854-100000@alpha.yumyumyum.org> References: <3C8529DA.FA8ABCE@mindspring.com> <20020305164151.T5854-100000@alpha.yumyumyum.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ moved to -chat ] > > Because that underlying assumption is false, and I'm making > > fun of it. > > Well, that in itself is wrong. C++ code IS harder to write and write > correctly and effeciently, as I would assume it is for any OO language. Not so. Having done C professionally for umpteen years, C++ for a little less than umpteen years, and Java for 4, I can say w/out reservation that C++ sucks. OOP programming doesn't *have* to be hard. C++ puts too many roadblocks in your way. It not just because Java is newer that it's displacing C++ as the primary development language. It's because C++ as a language is *NOT* well-designed (design my commitee). C is becoming more and more like C++ in this regard. (And before Terry starts whining about strongly typed languages, let me state that IMO strongly typed languages are a good thing, since they allow you to verify your code at *COMPILE* time, vs. at runtime.) I can get more done in a shorter period of time with Java than with C++. However, when speed is of the issues, the computer get more done in a shorter amount of time with C than I can with either Java/C++. My Java programs can often-times run *faster* than my own C++ programs, simply because Java (the language) makes it easier to produce a good design. I don't find the limitations to be limitations so much, and they tend to force me to do better design up front. Both are OOP languages, but C++ *feels* like a non-OOP language with some hooks to make it more OOP like. (I'd like to play with Smalltalk, but alas there's no market for it, and there's no time left in my day to work on what I need to get done, let alone for things like playing with ST.) C++ in it's simple form *can* be easier to maintain, but it rarely turns out that way. As programmers, it's difficult to not succumb to the temptation to use the latest/greatest feature of the language, since at the time it certainly *seems* like it would help things out in the long-term. :) Finally, well-written/optimized C++ code is an abomination to look at, and requires sacrificing small animals at alters whenever you need to modify it. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:20:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 42FF037B404 for ; Tue, 5 Mar 2002 16:20:44 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g260K9P11913; Tue, 5 Mar 2002 19:20:09 -0500 (EST) Date: Tue, 5 Mar 2002 19:18:24 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: "Brian T.Schellenberger" Cc: Julian Elischer , Lars Eggert , "Rogier R. Mulhuijzen" , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <20020305235404.9AE73BA03@i8k.babbleon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, Brian T.Schellenberger wrote: > On Tuesday 05 March 2002 06:29 pm, Julian Elischer wrote: > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > > Zhihui Zhang wrote: > > > > Several times slower! The point is that writing less data performs > > > > worse. So I call it weird. > > > > > > Huh? You originally said: > > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > > > > > (2) I still write these blocks sequentially, but for each block I only > > > > write part of it. > > > > > > ... > > > > > > > I find out the the performance of (2) is several times better than the > > > > performance of (1). Can anyone explain to me why this is the case? > > > > > > If (2) is better than (1), then writing *less* data is faster. Which is > > > it, now? > > > > Um yeah that is what all my suggestions were based on.. > > If, however, the later mail is right and the earlier mail is wrong, this > *would* be easily explained: Many disks have optimization for the case of > linear writes and seeking slows them down a *lot*. Why? Because it's very > common to do linear writes, and it make sense to optimize the common case. But the write in both cases are done sequentially. In the second case, I merely skip some sectors by writing less-than-full blocks. For example, I could write 3584, 5120, 7680, 7168, 8192 bytes in each successive 8192 byte blocks. But all these blocks are contiguous. Maybe the disk controller is not smart enough to figure out this is actually sequential. Only 8192, 8192, 8192, 8192 are regarded as sequential? -Zhihui > But it'll be easier for us all to explain away the results if you can tell us > what the results actually are :-) > > > > > > Lars > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) > Brian, the man from Babble-On . . . . bts@babbleon.org (personal) > ME --> http://www.babbleon.org > http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:27:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 2FC7237B400 for ; Tue, 5 Mar 2002 16:27:25 -0800 (PST) Received: (qmail 6718 invoked from network); 6 Mar 2002 00:27:18 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 6 Mar 2002 00:27:18 -0000 Date: Tue, 5 Mar 2002 19:27:18 -0500 (EST) From: Kenneth Culver To: Erik Trulsson Cc: Terry Lambert , "Steve B." , "Eugene L. Vorokov" , Subject: Re: C vs C++ In-Reply-To: <20020305215702.GA76733@student.uu.se> Message-ID: <20020305192548.Y6706-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I do agree that when the extra features of C++ are used this often > results in bloated programs but this can at least in part be blamed on > insufficiently skilled programmers. > > > Note that C++ is not really an OO language. It is probably better to > call it a language with support for object-oriented programming (as > well as support for other programming styles.) > I'll agree to that... :-D It's basically what I've been trying to say. That and if he's using gcc to compile, he might not get completely un-buggy code when he compiles c++ apps. Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:43: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id DB5F137B402; Tue, 5 Mar 2002 16:42:57 -0800 (PST) Date: Tue, 5 Mar 2002 16:42:57 -0800 From: David O'Brien To: "Matthew N. Dodd" Cc: Julian Elischer , dirkx@covalent.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Myson drivers for 4.x Message-ID: <20020305164257.A24565@hub.freebsd.org> Reply-To: obrien@freebsd.org References: <20020227025137.G21724-100000@sasami.jurai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020227025137.G21724-100000@sasami.jurai.net>; from winter@jurai.net on Wed, Feb 27, 2002 at 02:52:41AM -0500 X-Operating-System: FreeBSD 4.4-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Feb 27, 2002 at 02:52:41AM -0500, Matthew N. Dodd wrote: > On Tue, 26 Feb 2002, Julian Elischer wrote: > > I have been speaking with the author. > > he is adding a BSD copyright. > > also he says we can KNFify (style(9)ify?) as it doesn't have to remain > > compatible with anything else. > > It might be nice if it could be folded into the driver it was copied from, > if thats still possible. It would be nice, but other than admitting he has cards of this type; Bill Paul refused to answer if he is planning on supporting them. I think we need to commit the `my' driver as-is. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:44: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 1623837B400; Tue, 5 Mar 2002 16:44:03 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g260hwq38554; Tue, 5 Mar 2002 16:43:58 -0800 (PST) (envelope-from obrien) Date: Tue, 5 Mar 2002 16:40:54 -0800 From: "David O'Brien" To: Giorgos Keramidas Cc: hackers@freebsd.org Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020305164054.B38095@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20020305201350.GC4820@hades.hell.gr> <20020305155850.A38095@dragon.nuxi.com> <20020306000806.GC6839@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020306000806.GC6839@hades.hell.gr>; from keramida@freebsd.org on Wed, Mar 06, 2002 at 02:08:07AM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: > On 2002-03-05 15:58, David O'Brien wrote: > > On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: > > > > -Don't use '!' for tests unless it's a boolean, e.g. use > > > > +For tests, always compare the value to the appropriate 0 instead of > > > > +checking it directly, unless the value is a boolean. > ... > > > > Please show examples from /sys that back up this change. To state this > > explicitly, I think a significant number of /sys files should be > > following it. > > Actually I was asking for comments, but anyways. I was giving one. :-) style(9) documents the practices of /sys. Thus we should not arbitaryly add rules w/o them being backed up in code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:45:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 376F637B417; Tue, 5 Mar 2002 16:45:14 -0800 (PST) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g260hWC71212; Tue, 5 Mar 2002 16:43:32 -0800 (PST) (envelope-from root@utility.clubscholarship.com) Date: Tue, 5 Mar 2002 16:43:32 -0800 (PST) From: Patrick Thomas To: Dag-Erling Smorgrav Cc: , Subject: Re: Four misc. questions related to jail usage In-Reply-To: Message-ID: <20020305164246.Y71209-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Patrick Thomas writes: > > 1. Does each jail need to have its own proc filesystem mounted? > > No, procfs is pretty much useless these days (except for truss). In 4.5, won't `ps` (and perhaps other apps) not work for people in a jail if their jail does not have a proc file system mounted in their /proc ? --pt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:47:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6677837B400; Tue, 5 Mar 2002 16:47:05 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g260l4K29454; Tue, 5 Mar 2002 19:47:04 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200203060047.g260l4K29454@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Takanori Watanabe Cc: hackers@freebsd.org Subject: Re: unionfs and getcwd problem. In-Reply-To: Your message of "Mon, 25 Feb 2002 23:35:10 +0900." <200202251435.XAA91094@shidahara1.planet.sci.kobe-u.ac.jp> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Mar 2002 19:47:03 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Takanori Watanabe wrote: > Hi, I had trouble with unionfs when it calles getcwd(3) when > I mount some directory on the directry in same file system,like > mount -t union /usr/home/foo/bar /usr/src/sys/ . > > I investigate the problem by inserting debug print in getcwd.c. > Then I found issuing __getcwd(2) in getcwd(3) failed, and > climb up filesystem tree as the next way. But it failed when > it reaches to mount point. It seems that st_dev and st_ino > member returns the same number as the underlying filesystem > so it failed to recognize mount point. So I tried the patch as > follows taken from nullfs. Are there any problem with this patch? It looks fine to me. I know you definitely need to provide this behavior when doing a "wrapper" filesystem to behave like the system's stat() :) > Takanori Watanabe > > Public Key > Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A > > > --- union_vnops.c~ Tue Oct 2 00:01:37 2001 > +++ union_vnops.c Mon Feb 25 22:44:51 2002 > @@ -957,6 +957,8 @@ > union_newsize(ap->a_vp, VNOVAL, vap->va_size); > } > > + ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; > + > if ((vap != ap->a_vap) && (vap->va_type == VDIR)) > ap->a_vap->va_nlink += vap->va_nlink; > return (0); -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:55:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id C16F437B405 for ; Tue, 5 Mar 2002 16:55:47 -0800 (PST) Received: from pool0228.cvx40-bradley.dialup.earthlink.net ([216.244.42.228] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iPiC-0002Q6-00; Tue, 05 Mar 2002 16:55:21 -0800 Message-ID: <3C8568E0.76415D99@mindspring.com> Date: Tue, 05 Mar 2002 16:54:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Giorgos Keramidas Cc: "Steve B." , freebsd-hackers@freebsd.org Subject: Re: C vs C++ References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <001701c1c481$d0d5eab0$f642d9cf@DROID> <20020305231252.GC5328@hades.hell.gr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Giorgos Keramidas wrote: > The steeper learning curve of C++ is indeed steeper, not because of > some magic property of the object-oriented programming paradigm, but > because there are a lot more things to learn, before a complete > program can be written, IMHO. Uh... "Hello World" looks the same in ANSI C and C++, unless you insist on using I/O streams and "cout", which no one ever really does, unless they are writing a C++ book or trying to impress a student. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 16:59:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by hub.freebsd.org (Postfix) with ESMTP id E6F2937B416 for ; Tue, 5 Mar 2002 16:59:23 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 18:54:18 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 9AE73BA03; Tue, 5 Mar 2002 18:54:04 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Julian Elischer , Lars Eggert Subject: Re: A weird disk behaviour Date: Tue, 5 Mar 2002 18:54:04 -0500 X-Mailer: KMail [version 1.3] Cc: Zhihui Zhang , "Rogier R. Mulhuijzen" , freebsd-hackers@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020305235404.9AE73BA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 05 March 2002 06:29 pm, Julian Elischer wrote: > On Tue, 5 Mar 2002, Lars Eggert wrote: > > Zhihui Zhang wrote: > > > Several times slower! The point is that writing less data performs > > > worse. So I call it weird. > > > > Huh? You originally said: > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > > > (2) I still write these blocks sequentially, but for each block I only > > > write part of it. > > > > ... > > > > > I find out the the performance of (2) is several times better than the > > > performance of (1). Can anyone explain to me why this is the case? > > > > If (2) is better than (1), then writing *less* data is faster. Which is > > it, now? > > Um yeah that is what all my suggestions were based on.. If, however, the later mail is right and the earlier mail is wrong, this *would* be easily explained: Many disks have optimization for the case of linear writes and seeking slows them down a *lot*. Why? Because it's very common to do linear writes, and it make sense to optimize the common case. But it'll be easier for us all to explain away the results if you can tell us what the results actually are :-) > > > Lars > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 17:12: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 6D5B837B416 for ; Tue, 5 Mar 2002 17:12:04 -0800 (PST) Received: from pool0228.cvx40-bradley.dialup.earthlink.net ([216.244.42.228] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iPxF-0001jI-00; Tue, 05 Mar 2002 17:10:53 -0800 Message-ID: <3C856C7F.5005E30E@mindspring.com> Date: Tue, 05 Mar 2002 17:10:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Brian T.Schellenberger" Cc: Kenneth Culver , "Steve B." , "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <3C8529DA.FA8ABCE@mindspring.com> <20020305214127.545FDBA03@i8k.babbleon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Brian T.Schellenberger" wrote: > On Tuesday 05 March 2002 03:26 pm, Terry Lambert wrote: > > Kenneth Culver wrote: > > > Why are you being so sarcastic? Everyone here is assuming that it's > > > harder to write C++ code, so you should only use it if necessary. It > > > isn't necessary to use it for something like a daemon. > > > > Because that underlying assumption is false, and I'm making > > fun of it. > > Reality check: How can you possibly contend that it is no more difficult to > write code in a language which *so* much more massive? It's not "*so* much more massive". Hardly anyone who wants to write understandable code uses operator overloading, unless the are definiing a "String" or "ImaginaryNumber" class, and then it's incredibly clear-cut what's going on. The "private" vs. "public" is incredibly useful for data hiding, as well as namespace seperation. It means you can't spam values accidently, if you can't spam them on purpose. If you have a hard time with "default private", then use "struct" instead of "class" for declaring things, and the default will be "public" instead. The "protected" and "friend" features are seldom used; if you understand FORTRAN mutual recursion as a means of implementing recursion in FORTRAN, which doesn't support it by default, then you understand "friend" functions. Inheritance is logical, to anyone who has ever programmed in the FreeBSD networking stack or VM system, both of which use structure casts to implement inheritance, whether you want it or not. Multiple inheritance is like "protected"... for the most part, you can ignore it. > And one, I might add, which is intentionally UNdesigned. Yeah, and ANSI-C has prototypes because the compiler vendors were too damn lazy to change their object format to include a third field in the symbol table so that the problems that prototypes catch at compile time could be caught at link-time. The hidden reason for ANSI-C prototypes, of course, is, and always has been, "so that C code could be compiled with a C++ compiler, with the intent that the C++ language supercede the C language". So now, I expect you to vehemently protect the existance of ANSI-C prototypes at every future opportunity. C++ was designed, but the design was constrained by the C language, just as the design of ANSI-C was constrained by the C language. > C++ is a language which I really liked until I really started > to learn about it. Well, there's a "ringing" condemnation. Have you looked at the source code for libXt or libXm lately? Ah, the beauty of pure C code, applied to the Object Oriented programming model... Object oriented programming is not some mystery, it's a means of solving problems that are best modeled by abstracting implementation details complexity into objects, so that you can concentrate on writing the code, and not on the details of the implementation. It's also a way of enhancing code reusability, through the use of design patterns. Once you've written one binary search, you've written them all. If you understand functional decomposition, then you unsertand the most fundamental tenet of object oriented programming already. Can we all move on to something more useful, like criticizing Java? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 17:16:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 0C5AC37B402 for ; Tue, 5 Mar 2002 17:16:08 -0800 (PST) Received: from pool0228.cvx40-bradley.dialup.earthlink.net ([216.244.42.228] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iQ2E-0000l6-00; Tue, 05 Mar 2002 17:16:03 -0800 Message-ID: <3C856DB5.E5F14F62@mindspring.com> Date: Tue, 05 Mar 2002 17:15:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kenneth Culver Cc: "Steve B." , "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ References: <20020305164151.T5854-100000@alpha.yumyumyum.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kenneth Culver wrote: > > Because that underlying assumption is false, and I'm making > > fun of it. > > Well, that in itself is wrong. C++ code IS harder to write and write > correctly and effeciently, as I would assume it is for any OO language. C++ is not an O-O language. It is a language based on C that has O-O constructs which are lacking in C. It enables you to do O-O programming, but it doesn't constraing you to doing O-O programming. Just as Java doesn't constrain you (indeed, a number of Sun APIs break the O-O model by being able to instance unconstructed objects on which you have to post-call an initializer, which is incredibly broken). It's actually easier for humans to use an abstraction for complexity; if it weren't all rental cars would come with manual transmissions and two levers for steering. > I'm not saying it can't be done, but generally speaking based on the Open > source and commercial products I've seen, the ones that are written in C++ > suffer from more bloat and run slower. "A trout is a fish." "Therefore all fish are trout." I think you just failed set theory... ;^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 18: 6:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from midway.uchicago.edu (midway.uchicago.edu [128.135.12.12]) by hub.freebsd.org (Postfix) with ESMTP id 0F1FC37B405 for ; Tue, 5 Mar 2002 18:06:24 -0800 (PST) Received: from there (adsl-65-42-131-128.dsl.chcgil.ameritech.net [65.42.131.128]) by midway.uchicago.edu (8.11.6/8.11.6) with SMTP id g2626Ni00266; Tue, 5 Mar 2002 20:06:23 -0600 (CST) Message-Id: <200203060206.g2626Ni00266@midway.uchicago.edu> Content-Type: text/plain; charset="iso-8859-1" From: David Syphers Reply-To: charon@seektruth.org To: Terry Lambert Subject: Trout (was: C vs C++) Date: Tue, 5 Mar 2002 20:06:23 -0600 X-Mailer: KMail [version 1.3.2] Cc: freebsd-hackers@FreeBSD.ORG References: <20020305164151.T5854-100000@alpha.yumyumyum.org> <3C856DB5.E5F14F62@mindspring.com> In-Reply-To: <3C856DB5.E5F14F62@mindspring.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 05 March 2002 07:15 pm, Terry Lambert wrote: > Kenneth Culver wrote: > > I'm not saying it can't be done, but generally speaking based on the Open > > source and commercial products I've seen, the ones that are written in > > C++ suffer from more bloat and run slower. > > "A trout is a fish." > "Therefore all fish are trout." > > I think you just failed set theory... ;^). I couldn't pass this up... The original comment has nothing to do with set theory per se; it has to do with the validity of extrapolation of data. The reason I couldn't pass this up is because I've just been reading Newton's Principia, in which he addresses this very point (in his third rule of reasoning in philosophy). He would say that if all observed C++ programs are slower and have more bloat, then we should assume all possible C++ programs are slower and have more bloat. Not a question of mathematics. Whether or not the premise is true is an entirely different question, and one which I'll leave to the professional coders :) -David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 19:47:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 5EBD837B400 for ; Tue, 5 Mar 2002 19:47:12 -0800 (PST) Received: (qmail 7495 invoked from network); 6 Mar 2002 03:47:04 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 6 Mar 2002 03:47:04 -0000 Date: Tue, 5 Mar 2002 22:47:04 -0500 (EST) From: Kenneth Culver To: Terry Lambert Cc: "Steve B." , "Eugene L. Vorokov" , Subject: Re: C vs C++ In-Reply-To: <3C856DB5.E5F14F62@mindspring.com> Message-ID: <20020305224627.V7488-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > I'm not saying it can't be done, but generally speaking based on the Open > > source and commercial products I've seen, the ones that are written in C++ > > suffer from more bloat and run slower. > > "A trout is a fish." > "Therefore all fish are trout." > > I think you just failed set theory... ;^). Uhh, ok... Not that this had anything to do with set theory, although I see you were trying to be funny... Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 20:12:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by hub.freebsd.org (Postfix) with ESMTP id 6549C37B402 for ; Tue, 5 Mar 2002 20:12:29 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 21:51:02 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 2C1B5BA03; Tue, 5 Mar 2002 21:50:55 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Zhihui Zhang , Lars Eggert Subject: Re: A weird disk behaviour Date: Tue, 5 Mar 2002 21:50:54 -0500 X-Mailer: KMail [version 1.3] Cc: "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020306025055.2C1B5BA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 05 March 2002 06:32 pm, Zhihui Zhang wrote: > I apologize for all who have followed this. I made a typo in the original > email. What I observed is that writing LESS performs WORSE. Since all > blocks are laid out contiguously and I write them sequentially, there > should not be any seek problem. Hmmm . . . perhaps I misunderstood you, but I thought that you said that in the original mail that you were writing to the same number of disk blocks eiteher way but in some cases you were writing partial blocks and in some cases full blocks. How do you do that if you don't seek? If you aren't seeking, then you must be, in the slower case, writing partial blocks. Well, there is some size where the disk has physical blocks. On some disks, writes are always done in full physical blocks. To write a partial block, the block is read from disk, the data to be written is substituted and then the entire block is written. This would certainly be likely to be slower than writing a whole block. Does this possibly explain what you are seeing? Note that I have no clue whether this happens with many real disks, or even with any made in the last 20 years, but I have heard tell of such things. > I have modified the kernel in > kern_physio.c and find out that physio() is called by expected number of > times. I even add some code to record the time elapsed there: > > t1 = time_second; > > BUF_STRATEGY(bp, 0); > spl = splbio(); > while ((bp->b_flags & B_DONE) == 0) > tsleep((caddr_t)bp, PRIBIO, "physstr", 0); > splx(spl); > > t2 = time_second; > physio_time += t2 - t1; > > the physio_time (a sysctl variable) is close to the time reported by the > user program. > > -Zhihui > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > Zhihui Zhang wrote: > > > Several times slower! The point is that writing less data performs > > > worse. So I call it weird. > > > > Huh? You originally said: > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > > > (2) I still write these blocks sequentially, but for each block I only > > > write part of it. > > > > ... > > > > > I find out the the performance of (2) is several times better than the > > > performance of (1). Can anyone explain to me why this is the case? > > > > If (2) is better than (1), then writing *less* data is faster. Which is > > it, now? > > > > Lars > > > > > -Zhihui > > > > > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > >>Zhihui Zhang wrote: > > >>>Well, the core of my program is as follows (RANDOM(x) return a value > > >>>between 0 and x): > > >>> > > >>> blocksize = 8192; > > >>> write_size_low = 512; > > >>> > > >>> time(&time1); > > >>> for (i = 0; i < write_count; i++) { > > >>> write_size = write_size_low + > > >>> RANDOM(write_size_high-write_size_low); > > >>> write_size = roundup(write_size, DEV_BSIZE); > > >>> if (testcase == 1) > > >>> write_size = blocksize; > > >>> write_block(rawfd, sectorno, buf, write_size); > > >>> sectorno += blocksize / DEV_BSIZE; > > >>> } > > >>> time(&time2); > > >>> > > >>>If testcase is one, then the time elapsed (time2 - time1) is much > > >>> less. > > >> > > >>How "much less" in milliseconds? > > >> > > >>Also, in your original mail, you said you had 15,000 of these 8K > > >> blocks, which is only 120MB or so. Use 150,000 or 1,500,000 and check > > >> your results then. > > >> > > >>Lars > > >> > > >>>-Zhihui > > >>> > > >>>On Tue, 5 Mar 2002, Lars Eggert wrote: > > >>>>I agree that it's probably caching at some level. You're only writing > > >>>>about 120MB of data (and half that in your second case). Bump these > > >>>> to a couple of GB and see what happens. > > >>>> > > >>>>Also, could you post your actual measurements? > > >>>> > > >>>>Lars > > >>>> > > >>>>Zhihui Zhang wrote: > > >>>>>The machine has 128M memory. I am doing physical I/O one block at a > > >>>>> time, so there should be no memory copy. > > >>>>> > > >>>>>-Zhihui > > >>>>> > > >>>>>On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: > > >>>>>>At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: > > >>>>>>>On Tue, 5 Mar 2002, Julian Elischer wrote: > > >>>>>>>>more writes fit in the disk's write cache? > > >>>>>>> > > >>>>>>>For (1), it writes 15000 * 8192 bytes in all. For (2), it writes > > >>>>>>> 15000 * 4096 bytes in all (assuming the random number distributes > > >>>>>>> evenly between 0 and 8192). So your suggestion does not make > > >>>>>>> sense to me. > > >>>>>> > > >>>>>>How large is your buffercache? it might be that the 15000 * ~4096 > > >>>>>> roughly matches with your cache, and 15000 * 8912 doesn't. > > >>>>>> > > >>>>>>Case (1) would require a lot more physical IO in that case than > > >>>>>> case (2) would require. > > >>>>>> > > >>>>>> Doc > > >>>>>> > > >>>>>>>-Zhihui > > >>>>>>> > > >>>>>>>>On Tue, 5 Mar 2002, Zhihui Zhang wrote: > > >>>>>>>>>I am doing some raw I/O test on a seagate SCSI disk running > > >>>>>>>>> FreeBSD 4.5. This situation is like this: > > >>>>>>>>> > > >>>>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ > > >>>>>>>>> > > >>>>>>>>>| | | | | | | | | | | | .... > > >>>>>>>>> > > >>>>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ > > >>>>>>>>> > > >>>>>>>>>Each block is of fixed size, say 8192 bytes. Now I have a user > > >>>>>>>>> program writing each contiguously laid out block sequentially > > >>>>>>>>> using /dev/daxxx interface. There are a lot of them, say 15000. > > >>>>>>>>> I write the blocks in two ways (the data used in writing are > > >>>>>>>>> garbage): > > >>>>>>>>> > > >>>>>>>>>(1) Write each block fully and sequentially, ie. 8192 bytes. > > >>>>>>>>> > > >>>>>>>>>(2) I still write these blocks sequentially, but for each block > > >>>>>>>>> I only write part of it. Exactly how many bytes are written > > >>>>>>>>> inside each > > >>>>>>> > > >>>>>>>block is > > >>>>>>> > > >>>>>>>>>determinted by a random number between 512 .. 8192 bytes > > >>>>>>>>> (rounded up a to multiple of 512 bytes). > > >>>>>>>>> > > >>>>>>>>>I find out the the performance of (2) is several times better > > >>>>>>>>> than the performance of (1). Can anyone explain to me why this > > >>>>>>>>> is the case? > > >>>>>>>>> > > >>>>>>>>>Thanks for any suggestions or hints. > > >>>>>>>>> > > >>>>>>>>>-Zhihui > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>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 > > >>>> > > >>>>-- > > >>>>Lars Eggert Information Sciences > > >>>> Institute http://www.isi.edu/larse/ University of > > >>>> Southern California > > >> > > >>-- > > >>Lars Eggert Information Sciences > > >> Institute http://www.isi.edu/larse/ University of > > >> Southern California > > > > -- > > Lars Eggert Information Sciences Institute > > http://www.isi.edu/larse/ University of Southern California > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 20:39:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by hub.freebsd.org (Postfix) with ESMTP id BA82D37B416 for ; Tue, 5 Mar 2002 20:39:23 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 22:16:10 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id A86B4BA03; Tue, 5 Mar 2002 22:16:02 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Terry Lambert Subject: Re: C vs C++ Date: Tue, 5 Mar 2002 22:16:02 -0500 X-Mailer: KMail [version 1.3] Cc: Kenneth Culver , "Steve B." , "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <20020305214127.545FDBA03@i8k.babbleon.org> <3C856C7F.5005E30E@mindspring.com> In-Reply-To: <3C856C7F.5005E30E@mindspring.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020306031602.A86B4BA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 05 March 2002 08:10 pm, Terry Lambert wrote: | "Brian T.Schellenberger" wrote: | > On Tuesday 05 March 2002 03:26 pm, Terry Lambert wrote: | > > Kenneth Culver wrote: | > > > Why are you being so sarcastic? Everyone here is assuming that it's | > > > harder to write C++ code, so you should only use it if necessary. It | > > > isn't necessary to use it for something like a daemon. | > > | > > Because that underlying assumption is false, and I'm making | > > fun of it. | > | > Reality check: How can you possibly contend that it is no more difficult | > to write code in a language which *so* much more massive? | | It's not "*so* much more massive". Hardly anyone who wants | to write understandable code uses operator overloading, unless | the are definiing a "String" or "ImaginaryNumber" class, and | then it's incredibly clear-cut what's going on. | | The "private" vs. "public" is incredibly useful for data | hiding, as well as namespace seperation. It means you | can't spam values accidently, if you can't spam them on | purpose. | | If you have a hard time with "default private", then use | "struct" instead of "class" for declaring things, and the | default will be "public" instead. | | The "protected" and "friend" features are seldom used; if | you understand FORTRAN mutual recursion as a means of | implementing recursion in FORTRAN, which doesn't support | it by default, then you understand "friend" functions. | | Inheritance is logical, to anyone who has ever programmed | in the FreeBSD networking stack or VM system, both of which | use structure casts to implement inheritance, whether you | want it or not. | | Multiple inheritance is like "protected"... for the most | part, you can ignore it. In other words it *is* so much more massive but most of that is junk and can be safely ignored. We would be in agreement there but it still gets in the way of learning it. | > And one, I might add, which is intentionally UNdesigned. | | Yeah, and ANSI-C has prototypes because the compiler vendors | were too damn lazy to change their object format to include | a third field in the symbol table so that the problems that | prototypes catch at compile time could be caught at link-time. Have you ever *read* Stroustup's philosophy that a language should not have a philosophy? This is precisely what's wrong with C++, and what I mean by UNdesigned. It's deliberate! Stroustup considers it a virtue! I beg to differ. | The hidden reason for ANSI-C prototypes, of course, is, and | always has been, "so that C code could be compiled with a C++ | compiler, with the intent that the C++ language supercede the | C language". | | So now, I expect you to vehemently protect the existance of | ANSI-C prototypes at every future opportunity. Prototypes are a good idea, and they did come from C++. I never said that C++ was devoid of good ideas; I just think it has _too_many_ ideas. | C++ was designed, but the design was constrained by the C | language, just as the design of ANSI-C was constrained by | the C language. Mostly it was constrained by a lack of constraint. Upward compatibility is a problem, but needn't be deadly. I happen to do the majority of my programming in a C-based OO language, but it's not C++. Actually, it's proprietary but it's closely modeled on Objective C, which is a much better OO language IMHO. | > C++ is a language which I really liked until I really started | > to learn about it. | | Well, there's a "ringing" condemnation. | | Have you looked at the source code for libXt or libXm | lately? Ah, the beauty of pure C code, applied to the | Object Oriented programming model... I have, and it's not real pretty. But if bad code condemned C++ I think you'd have a lot more to answer for--indeed, I believe you've rejected precisely this logic in arguing against others. Ok, you're in love with C++ but it's *not* the be-all and end-all of programming languages. Actually I think it's a crock of unmentionability, but that's just me. | Object oriented programming is not some mystery, it's a means | of solving problems that are best modeled by abstracting | implementation details complexity into objects, so that you | can concentrate on writing the code, and not on the details | of the implementation. True . . . | It's also a way of enhancing code reusability, through the | use of design patterns. Once you've written one binary | search, you've written them all. True . . . | If you understand functional decomposition, then you | unsertand the most fundamental tenet of object oriented | programming already. I write in OO all the time, though I admit that I feel pretty feel to cheat where it makes the problem easier to solve & express. And I admit that sometimes I've cheated where it *didn't* in order to meet deadlines, and that I've almost always regretted. But OO != C++. | Can we all move on to something more useful, like criticizing | Java? Hmm . . . a little pot - kettle thing going on there, is there? | | -- Terry -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 20:41: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 8113E37B404 for ; Tue, 5 Mar 2002 20:41:01 -0800 (PST) Received: from davidwnt (davidwnt.viasoft.com.cn [192.168.1.239]) by mail.viasoft.com.cn (8.9.3/8.9.3) with SMTP id MAA09536 for ; Wed, 6 Mar 2002 12:51:01 +0800 Message-ID: <00e301c1c4c9$295966c0$ef01a8c0@davidwnt> From: "David Xu" To: Subject: please remove blank line Date: Wed, 6 Mar 2002 12:41:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG could anyone remove a blank line in /sys/kern/kern_sysctl.c ? in FreeBSD 4.5 STABLE, it's at line 151, function sysctl_ctx_init(). -- David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 21:26:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f187.law10.hotmail.com [64.4.15.187]) by hub.freebsd.org (Postfix) with ESMTP id 580EE37B400 for ; Tue, 5 Mar 2002 21:26:33 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Mar 2002 21:26:33 -0800 Received: from 195.219.78.37 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 06 Mar 2002 05:26:32 GMT X-Originating-IP: [195.219.78.37] From: "AHMAD MASOOD" To: freebsd-hackers@freebsd.org Subject: add me Date: Wed, 06 Mar 2002 05:26:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Mar 2002 05:26:33.0236 (UTC) FILETIME=[7A4F0D40:01C1C4CF] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG please add me too _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 21:39:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 914B437B417 for ; Tue, 5 Mar 2002 21:39:40 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g265dIP05315; Tue, 5 Mar 2002 21:39:18 -0800 (PST) (envelope-from obrien) Date: Tue, 5 Mar 2002 21:37:26 -0800 From: "David O'Brien" To: David Xu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: please remove blank line Message-ID: <20020305213726.A5255@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <00e301c1c4c9$295966c0$ef01a8c0@davidwnt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00e301c1c4c9$295966c0$ef01a8c0@davidwnt>; from davidx@viasoft.com.cn on Wed, Mar 06, 2002 at 12:41:20PM +0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 12:41:20PM +0800, David Xu wrote: > could anyone remove a blank line in /sys/kern/kern_sysctl.c ? > in FreeBSD 4.5 STABLE, it's at line 151, function sysctl_ctx_init(). Uh.. why? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 22: 2:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rylos.atmos.colostate.edu (rylos.atmos.colostate.edu [129.82.48.47]) by hub.freebsd.org (Postfix) with ESMTP id 97AEE37B402 for ; Tue, 5 Mar 2002 22:02:44 -0800 (PST) Received: from localhost (tarcieri@localhost) by rylos.atmos.colostate.edu (8.11.6/8.11.3) with ESMTP id g2663bp48042 for ; Tue, 5 Mar 2002 23:03:37 -0700 (MST) (envelope-from tarcieri@atmos.colostate.edu) X-Authentication-Warning: rylos.atmos.colostate.edu: tarcieri owned process doing -bs Date: Tue, 5 Mar 2002 23:03:36 -0700 (MST) From: Tony Arcieri To: freebsd-hackers@freebsd.org Subject: aio_read() oddness Message-ID: <20020305225908.U48034-100000@rylos.atmos.colostate.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm not currently subscribed to this list, so please cc replies to me. I was playing around with aio_read() and ran into some seemingly aberrant behavior, although not with aio_read() itself, but the resulting signal. Within struct aiocb I was setting: aio_sigevent.sigev_notify = SIGEV_SIGNAL; aio_sigevent.sigev_value.sigval_int = 42; iocb.aio_sigevent.sigev_signo = SIGUSR1; Then in the sigaction structure: sa_flags = SA_SIGINFO; Upon completion of the requested read, a signal is sent. Within the siginfo structure, si_signo is set properly. However, si_value.sigval_int is zero. Is this just not implemented completely yet or am I missing something? Tony Arcieri To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 22:36: 9 2002 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 7830D37B416; Tue, 5 Mar 2002 22:36:01 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g266a0i82121; Tue, 5 Mar 2002 23:36:00 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g266ZxL82219; Tue, 5 Mar 2002 23:35:59 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Mar 2002 23:35:52 -0700 (MST) Message-Id: <20020305.233552.104015606.imp@village.org> To: obrien@FreeBSD.ORG Cc: keramida@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. From: "M. Warner Losh" In-Reply-To: <20020305164054.B38095@dragon.nuxi.com> References: <20020305155850.A38095@dragon.nuxi.com> <20020306000806.GC6839@hades.hell.gr> <20020305164054.B38095@dragon.nuxi.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020305164054.B38095@dragon.nuxi.com> "David O'Brien" writes: : On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: : > On 2002-03-05 15:58, David O'Brien wrote: : > > On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: : > > > > -Don't use '!' for tests unless it's a boolean, e.g. use : > > > > +For tests, always compare the value to the appropriate 0 instead of : > > > > +checking it directly, unless the value is a boolean. : > ... : > > : > > Please show examples from /sys that back up this change. To state this : > > explicitly, I think a significant number of /sys files should be : > > following it. : > : > Actually I was asking for comments, but anyways. : : I was giving one. :-) : style(9) documents the practices of /sys. Thus we should not arbitaryly : add rules w/o them being backed up in code. I believe that sys/pccard, sys/dev/{pccard,pcic,pccbb,cardbus} tends to follow this rule. If you are looking for examples. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 23: 4:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id D76BB37B416 for ; Tue, 5 Mar 2002 23:04:24 -0800 (PST) Received: (qmail 68412 invoked by uid 100); 6 Mar 2002 07:04:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.49014.254461.125446@guru.mired.org> Date: Wed, 6 Mar 2002 01:04:22 -0600 To: "Steve B." , Joe Halpin Cc: "Eugene L. Vorokov" , , freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <001201c1c464$06416fd0$f642d9cf@DROID> References: <3C8529DA.FA8ABCE@mindspring.com> <20020305164151.T5854-100000@alpha.yumyumyum.org> <15493.24457.986109.726909@caddis.yogotech.com> <3C8573B2.35144B17@attbi.com> <200203051407.g25E7Cd67446@bugz.infotecs.ru> <001201c1c464$06416fd0$f642d9cf@DROID> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Geeze, spend a day at the doctors, and look what happens. The mst interesting thing to show up on -chat in the entire time I've been reading it. Language debates are such fun. Steve B. types: > I take a simplistic view after years of C++. > > C++ is good for large projects that need to be maintained into the future. > Then the advantages of OO starts to kick in. For small projects that won't > change much then C is the better choice IMO. But for large projects, the disadvantages of C++ kick in, so you don't really gain much. Almost every OO language design decision in C++ is wrong. So you get all the disadvantages of C, bundled with all the disadvantages of OO as well. > ----- Original Message ----- > From: "Eugene L. Vorokov" > > I have a small problem. I work for software development company and > > write daemons and console tools for Unix. My boss wants everything > > to be written in C++, because he thinks C++ is cool. I prefer C > > for such tasks, but I cannot really put good arguments of why and > > where C++ can be worse than C. I know many of you prefer C too. > > Can you please explain some disadvantages of C++ comparing to C ? > > Is it slower, does it produce less effective code, why is it like > > that, etc ... or please direct me to some articles where this can > > be explained. If he wants to wrinte in C++ because C++ is hot, then just write C and compile it with the C++ compiler. If he wants an O-O language, then shell out the bucks to get Eiffel and it's IDE from Meyer (I'd like to claim a relationship, but I doubt it), so you actually get the benefits of O-O. Joe Halpin types: > 1. C++ is a more difficult language than C because it does more stuff > than C. Ditto vs Java. No, it doesn't do more stuff than C, Neither does Java. See the Church-Turing thesis. Java and C++ are harder to learn because they have more *features* than C. That's a different thing, and doesn't necessarily make the language more powerful. One of my favorite languages is Scheme, where the general design principle was to make the language more powerful by removing things. I quit using it before they added macros, in part because I couldn't get the DECWRL Scheme->C compiler to compile with SAS C 6.0. Maybe I'll take another look. I use Python these days, which doesn't have macros - which are the most powerful programming construct in modern LISP. > For years I have been seeing this assertion on the net over and over. I > still don't see the expected result (ie, Java applications displacing > C/C++ applications). I see it happening, then the products vanish because they can't compete on a speed basis. VM's were a good idea when UCSD did it back in the mid 70s. I think the hardware is fast enough to support it now, but you've got to tie the parts together write. Python is succeeding in some strange places, because it's trivial to take a collection of subroutines that deal with a data structure they pass back and forth as arguments, and turn it into a Python object. Which means you get to play with those complex, compiled environments in an interpreted environment that could be used as a shell, if you were really crazy. In fact, that's one of the things most VM designs have that Java (and Perl) is missing - the REPL. When I have to write Java, I debug my classes by firing up JPython, then playing with the Java objects in the JPython REPL loop. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 23:19:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 84BF437B416 for ; Tue, 5 Mar 2002 23:19:32 -0800 (PST) Received: (qmail 68574 invoked by uid 100); 6 Mar 2002 07:19:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.49923.458997.98416@guru.mired.org> Date: Wed, 6 Mar 2002 01:19:31 -0600 To: obrien@freebsd.org Cc: Giorgos Keramidas , hackers@freebsd.org Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: <20020305164054.B38095@dragon.nuxi.com> References: <20020305201350.GC4820@hades.hell.gr> <20020305155850.A38095@dragon.nuxi.com> <20020306000806.GC6839@hades.hell.gr> <20020305164054.B38095@dragon.nuxi.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien types: > On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: > I was giving one. :-) > style(9) documents the practices of /sys. Thus we should not arbitaryly > add rules w/o them being backed up in code. As the original author of the PR, I'll point out that this chagne does *not* add rules. It clarifies the wording of a rule that's already there. If the rule is wrong, it should be removed. The reason I didn't post if for wider review was because it wasn't changing any rules. My thanks to Giorgos for moving this PR towards closure. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 23:34:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 149E537B405; Tue, 5 Mar 2002 23:34:26 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g267Y4Lv088753; Wed, 6 Mar 2002 08:34:09 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Mike Meyer" Cc: obrien@FreeBSD.ORG, Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: Your message of "Wed, 06 Mar 2002 01:19:31 CST." <15493.49923.458997.98416@guru.mired.org> Date: Wed, 06 Mar 2002 08:34:04 +0100 Message-ID: <88752.1015400044@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <15493.49923.458997.98416@guru.mired.org>, "Mike Meyer" writes: >David O'Brien types: >> On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: >> I was giving one. :-) >> style(9) documents the practices of /sys. Thus we should not arbitaryly >> add rules w/o them being backed up in code. > >As the original author of the PR, I'll point out that this chagne does >*not* add rules. It clarifies the wording of a rule that's already >there. If the rule is wrong, it should be removed. The reason I didn't >post if for wider review was because it wasn't changing any rules. My >thanks to Giorgos for moving this PR towards closure. I had a discussion with Eric Allman about this very thing recently where he advocated "everything inside if, while, for and so on should be true booleans". Now, IFF the C language had a type called "boolean" that would make a lot of sense. Unfortunately, it does not (at present ?) have a boolean type, and while one could simulate it with typedefs, there is no way to get the compiler to enforce the rule. I belive the overall purpose of style(9) is to make the code readable, and I happen to think that if (somerandomfunction(argthis, functionthat(something), onemore)) { chugchugchug(argthisa; } is just a tiny bit more readable than if ((somerandomfunction(argthis, functionthat(something), onemore) != 0) { chugchugchug(argthisa; } for instance. -- 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 Tue Mar 5 23:38:18 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 9004037B416 for ; Tue, 5 Mar 2002 23:38:08 -0800 (PST) Received: (qmail 68876 invoked by uid 100); 6 Mar 2002 07:38:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.51038.957711.450030@guru.mired.org> Date: Wed, 6 Mar 2002 01:38:06 -0600 To: Poul-Henning Kamp Cc: "Mike Meyer" , obrien@FreeBSD.ORG, Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: <88752.1015400044@critter.freebsd.dk> References: <15493.49923.458997.98416@guru.mired.org> <88752.1015400044@critter.freebsd.dk> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp types: > In message <15493.49923.458997.98416@guru.mired.org>, "Mike Meyer" writes: > >David O'Brien types: > >> On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: > Now, IFF the C language had a type called "boolean" that would make > a lot of sense. So you're advocating that the rule be dropped. > I belive the overall purpose of style(9) is to make the code readable, > and I happen to think that > > if (somerandomfunction(argthis, functionthat(something), onemore)) { > chugchugchug(argthisa; > } > > is just a tiny bit more readable than > > if ((somerandomfunction(argthis, functionthat(something), onemore) > != 0) { > chugchugchug(argthisa; > } I agree with you. Under the rules as they exist now, the first form would only be valid if somerandomfunctoin returned either 0 or . http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 5 23:42:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 2F66437B41A; Tue, 5 Mar 2002 23:42:37 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g267gMLv090229; Wed, 6 Mar 2002 08:42:22 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Mike Meyer" Cc: "Mike Meyer" , obrien@FreeBSD.ORG, Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: Your message of "Wed, 06 Mar 2002 01:38:06 CST." <15493.51038.957711.450030@guru.mired.org> Date: Wed, 06 Mar 2002 08:42:22 +0100 Message-ID: <90228.1015400542@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <15493.51038.957711.450030@guru.mired.org>, "Mike Meyer" writes: >Poul-Henning Kamp types: >> In message <15493.49923.458997.98416@guru.mired.org>, "Mike Meyer" writes: >> >David O'Brien types: >> >> On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: >> Now, IFF the C language had a type called "boolean" that would make >> a lot of sense. > >So you're advocating that the rule be dropped. I'm advocating that the rule focus on readability rather than trying to enforce a type which doesn't exist. Type-enforcement is a task for the compiler, not for a manpage. -- 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 Mar 6 0:51:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 3483337B402 for ; Wed, 6 Mar 2002 00:51:08 -0800 (PST) Received: (qmail 69611 invoked by uid 100); 6 Mar 2002 08:51:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.55418.457017.332630@guru.mired.org> Date: Wed, 6 Mar 2002 02:51:06 -0600 To: Poul-Henning Kamp Cc: "Mike Meyer" , "Mike Meyer" , obrien@FreeBSD.ORG, Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: <90228.1015400542@critter.freebsd.dk> References: <15493.51038.957711.450030@guru.mired.org> <90228.1015400542@critter.freebsd.dk> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp types: > In message <15493.51038.957711.450030@guru.mired.org>, "Mike Meyer" writes: > I'm advocating that the rule focus on readability rather than trying > to enforce a type which doesn't exist. Excellent idea. Can you provide verbiage and examples? Thanx, http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 0:56:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 2D2A337B405; Wed, 6 Mar 2002 00:56:35 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g268uTp07014; Wed, 6 Mar 2002 00:56:29 -0800 (PST) (envelope-from obrien) Date: Wed, 6 Mar 2002 00:52:25 -0800 From: "David O'Brien" To: Mike Meyer Cc: Giorgos Keramidas , hackers@freebsd.org Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020306005225.A6921@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20020305201350.GC4820@hades.hell.gr> <20020305155850.A38095@dragon.nuxi.com> <20020306000806.GC6839@hades.hell.gr> <20020305164054.B38095@dragon.nuxi.com> <15493.49923.458997.98416@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15493.49923.458997.98416@guru.mired.org>; from mwm-dated-1015831171.a21ab0@mired.org on Wed, Mar 06, 2002 at 01:19:31AM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 01:19:31AM -0600, Mike Meyer wrote: > David O'Brien types: > > On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Jeremiahs wrote: > > I was giving one. :-) > > style(9) documents the practices of /sys. Thus we should not arbitaryly > > add rules w/o them being backed up in code. > > As the original author of the PR, I'll point out that this chagne does > *not* add rules. It clarifies the wording of a rule that's already > there. If the rule is wrong, it should be removed. The reason I didn't > post if for wider review was because it wasn't changing any rules. My > thanks to Giorgos for moving this PR towards closure. I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is "if (!strcmp(a,b))" which when read is extremely wrong of that is actually happening. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 0:57:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 5D7A737B400; Wed, 6 Mar 2002 00:57:34 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g268vVE07022; Wed, 6 Mar 2002 00:57:31 -0800 (PST) (envelope-from obrien) Date: Wed, 6 Mar 2002 00:53:28 -0800 From: "David O'Brien" To: "M. Warner Losh" Cc: keramida@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020306005328.B6921@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020305155850.A38095@dragon.nuxi.com> <20020306000806.GC6839@hades.hell.gr> <20020305164054.B38095@dragon.nuxi.com> <20020305.233552.104015606.imp@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: <20020305.233552.104015606.imp@village.org>; from imp@village.org on Tue, Mar 05, 2002 at 11:35:52PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 11:35:52PM -0700, M. Warner Losh wrote: > : I was giving one. :-) > : style(9) documents the practices of /sys. Thus we should not arbitaryly > : add rules w/o them being backed up in code. > > I believe that sys/pccard, sys/dev/{pccard,pcic,pccbb,cardbus} tends > to follow this rule. If you are looking for examples. Older code than PCCARD. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 1:13:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 5D29237B400; Wed, 6 Mar 2002 01:13:51 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g269DYLv014190; Wed, 6 Mar 2002 10:13:35 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Mike Meyer" Cc: "Mike Meyer" , "Mike Meyer" , obrien@FreeBSD.ORG, Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: Your message of "Wed, 06 Mar 2002 02:51:06 CST." <15493.55418.457017.332630@guru.mired.org> Date: Wed, 06 Mar 2002 10:13:34 +0100 Message-ID: <14189.1015406014@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <15493.55418.457017.332630@guru.mired.org>, "Mike Meyer" writes: >Poul-Henning Kamp types: >> In message <15493.51038.957711.450030@guru.mired.org>, "Mike Meyer" writes: >> I'm advocating that the rule focus on readability rather than trying >> to enforce a type which doesn't exist. > >Excellent idea. Can you provide verbiage and examples? All you have to do is get rid of the word boolean, ie: change Do not use ! for tests unless it is a boolean, e.g. use to Do not use ! for tests unless it is an integer type, e.g. use And as far as I'm concerned the confusion is gone. -- 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 Mar 6 1:22:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8F81937B402 for ; Wed, 6 Mar 2002 01:21:50 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g269Lok19566; Wed, 6 Mar 2002 01:21:50 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 01:21:50 -0800 (PST) From: Matthew Dillon Message-Id: <200203060921.g269Lok19566@apollo.backplane.com> To: David Greenman , hackers@freebsd.org Subject: patch for review, mountlist vnode scan generalization (vnlru() related) (current) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The vnode recycle code is currently not able to recycle vnodes in an LRU fashion because we cannot move vnodes within the mount's vnodelist without causing a number of filesystems, including UFS, to lose track when scanning the mount's vnodelist and start doing loop-restarts, resulting in O(dirty_vnode_count^2) operation. For example, if the #if 0'd section in vlruvp() in vfs_subr.c were to be enabled, the filesystem syncing daemon would suddenly start eating insane amounts of cpu if a significant number of dirty vnodes exists (like rm -rf /usr/ports or cp -r or cvs checkout, etc...). This patch is intended to begin solving this problem. The main purpose of the patch is to generalize the vnode scan that virtually all filesystems do when they are sync'd (see *_sync() in [*/]*/*vfsops.c*). The patch defines a new API that does all the hard work of keeping track of the scan position and doing the vnode scan itself and makes callbacks to flush individual vnodes as appropriate. The patch implements this API and modifies UFS to use the new API to prove it out. As part of this API, a new vnode type called VMARKER has been added. This type allows us to initialize a dummy vnode and use it to mark our position in the mountlist. All other code that does not use the new API to scan the vnodes under the mount must ignore this dummy vnode in their scans. A sysctl, debug.vlruvp_enable, is provided to enable the previously #if 0'd section of vlruvp() (i.e. turn on LRU ordering for the vnode recycle code), for testing purposes. This defaults to off (0) since only UFS has been fixed. I've done some moderate testing on -current. I intend to commit this some time tomorrow unless there are hicups or someone has a bright idea. It will eventually get into -stable as well. The main thing I am looking for review-wise is that the existing ffs_sync() code is equivalent to the new ffs_sync()-using-new-API code. There should be no operational differences, it should simply be cut-up differently. i.e. this commit stage is not supposed to make any major operational changes to the codebase. -Matt Index: isofs/cd9660/cd9660_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vnops.c,v retrieving revision 1.73 diff -u -r1.73 cd9660_vnops.c --- isofs/cd9660/cd9660_vnops.c 12 Sep 2001 08:37:43 -0000 1.73 +++ isofs/cd9660/cd9660_vnops.c 6 Mar 2002 08:14:05 -0000 @@ -110,6 +110,7 @@ case VFIFO: case VNON: case VBAD: + case VMARKER: return (0); } } Index: kern/vfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.347 diff -u -r1.347 vfs_subr.c --- kern/vfs_subr.c 5 Mar 2002 19:45:45 -0000 1.347 +++ kern/vfs_subr.c 6 Mar 2002 08:46:03 -0000 @@ -335,6 +335,92 @@ } /* + * vfs_scan_init: Initialize a vfs_scan_info structure for use. + * + * The info structure is cleared and initialized for use. The caller + * may initialize additional fields after calling this function. + * + */ +void +vfs_scan_init(struct vfs_scan_info *info) +{ + bzero(info, sizeof(struct vfs_scan_info)); + info->vs_doloop = 1; +} + +/* + * vfs_scan_vnodes: Scan the vnodes under a mount point + * + * The caller passes the mount point, pre-initialized information + * structure, and two function callbacks. + * + * The fast function is called as an optimization, with the mountlist + * mutex still held. This function may not block or release the mutex. + * A negative return value will cause the scan code to skip the vnode + * (never call the slow function). This function may be NULL. + * + * The slow function is called if the fast function returns >= 0. This + * function will be called without the mountlist mutex held and is allowed + * to block. It may also be NULL. + * + * If either function wishes a rescan to occur after the current scan + * finishes, they should set vs_tryagain to 1. If either function wishes + * to abort the loop entirely, vs_doloop should be set <= 0 (and + * vs_tryagain should also be set to 0 if you had previously modified + * it). + */ +int +vfs_scan_vnodes(struct mount *mp, struct vfs_scan_info *info, vfs_vnfast_t fastfunc, vfs_vnslow_t slowfunc) +{ + struct vnode *vp; + struct vnode *nvp; + + info->vs_mount = mp; + info->vs_marker.v_mount = mp; + info->vs_marker.v_type = VMARKER; + + mtx_lock(&mntvnode_mtx); + info->vs_tryagain = 1; + while (info->vs_tryagain) { + info->vs_tryagain = 0; + for (vp = TAILQ_FIRST(&mp->mnt_nvnodelist); + vp != NULL && info->vs_doloop > 0; + vp = nvp) { + /* + * sanity check, skip markers + */ + KASSERT(vp->v_mount == mp, + ("vnode %p mount association changed", vp)); + nvp = TAILQ_NEXT(vp, v_nmntvnodes); + if (vp->v_type == VMARKER) + continue; + + /* + * non-blocking skip function + */ + if (fastfunc && fastfunc(info, vp) < 0) + continue; + + /* + * Use a marker to save/restore our scan position + * when calling the blocking function. + */ + TAILQ_INSERT_AFTER(&mp->mnt_nvnodelist, + vp, &info->vs_marker, v_nmntvnodes); + mtx_unlock(&mntvnode_mtx); + if (slowfunc) + slowfunc(info, vp); + mtx_lock(&mntvnode_mtx); + nvp = TAILQ_NEXT(&info->vs_marker, v_nmntvnodes); + TAILQ_REMOVE(&mp->mnt_nvnodelist, + &info->vs_marker, v_nmntvnodes); + } + } + mtx_unlock(&mntvnode_mtx); + return(info->vs_allerror); +} + +/* * Lookup a filesystem type, and if found allocate and initialize * a mount structure for it. * @@ -572,6 +658,17 @@ done = 0; mtx_lock(&mntvnode_mtx); while (count && (vp = TAILQ_FIRST(&mp->mnt_nvnodelist)) != NULL) { + /* + * Don't move any markers we find! + */ + if (vp->v_type == VMARKER) { + do { + vp = TAILQ_NEXT(vp, v_nmntvnodes); + } while (vp && vp->v_type == VMARKER); + if (vp == NULL) + break; + } + TAILQ_REMOVE(&mp->mnt_nvnodelist, vp, v_nmntvnodes); TAILQ_INSERT_TAIL(&mp->mnt_nvnodelist, vp, v_nmntvnodes); @@ -1902,6 +1999,11 @@ if (vp->v_mount != mp) goto loop; nvp = TAILQ_NEXT(vp, v_nmntvnodes); + /* + * temporary until we replace this with vfs_scan_vnodes XXX + */ + if (vp->v_type == VMARKER) + continue; mtx_unlock(&mntvnode_mtx); mtx_lock(&vp->v_interlock); Index: sys/vnode.h =================================================================== RCS file: /home/ncvs/src/sys/sys/vnode.h,v retrieving revision 1.171 diff -u -r1.171 vnode.h --- sys/vnode.h 18 Feb 2002 16:17:57 -0000 1.171 +++ sys/vnode.h 6 Mar 2002 08:24:16 -0000 @@ -57,9 +57,10 @@ */ /* - * Vnode types. VNON means no type. + * Vnode types. VNON means no type. VMARKER is a scan placemarker */ -enum vtype { VNON, VREG, VDIR, VBLK, VCHR, VLNK, VSOCK, VFIFO, VBAD }; +enum vtype { VNON, VREG, VDIR, VBLK, VCHR, VLNK, + VSOCK, VFIFO, VBAD, VMARKER }; /* * Vnode tag types. @@ -80,6 +81,7 @@ TAILQ_HEAD(buflists, buf); typedef int vop_t __P((void *)); + struct namecache; struct vpollinfo { @@ -386,6 +388,33 @@ caddr_t *vdesc_transports; }; +/* + * vfs_vnode_scan() support. + */ + +struct vfs_scan_info { + /* + * Integrated into scanning code + */ + int vs_allerror; + int vs_tryagain; + int vs_doloop; + struct vnode vs_marker; + struct mount *vs_mount; + + /* + * totally user-defined + */ + int vs_lockreq; + int vs_wait; + int vs_waitfor; + struct thread *vs_td; + struct ucred *vs_cred; +}; + +typedef int (*vfs_vnfast_t)(struct vfs_scan_info *info, struct vnode *vp); +typedef void (*vfs_vnslow_t)(struct vfs_scan_info *info, struct vnode *vp); + #ifdef _KERNEL /* * A list of all the operation descs. @@ -602,6 +631,8 @@ void vgone __P((struct vnode *vp)); void vgonel __P((struct vnode *vp, struct thread *td)); void vhold __P((struct vnode *)); +void vfs_scan_init __P((struct vfs_scan_info *info)); +int vfs_scan_vnodes __P((struct mount *mp, struct vfs_scan_info *info, vfs_vnfast_t fastfunc, vfs_vnslow_t slowfunc)); int vinvalbuf __P((struct vnode *vp, int save, struct ucred *cred, struct thread *td, int slpflag, int slptimeo)); int vtruncbuf __P((struct vnode *vp, struct ucred *cred, struct thread *td, Index: ufs/ffs/ffs_snapshot.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_snapshot.c,v retrieving revision 1.30 diff -u -r1.30 ffs_snapshot.c --- ufs/ffs/ffs_snapshot.c 27 Feb 2002 19:18:10 -0000 1.30 +++ ufs/ffs/ffs_snapshot.c 6 Mar 2002 08:36:50 -0000 @@ -376,6 +376,11 @@ if (xvp->v_mount != mp) goto loop; nvp = TAILQ_NEXT(xvp, v_nmntvnodes); + /* + * temporary until we replace this with vfs_scan_vnodes XXX + */ + if (xvp->v_type == VMARKER) + continue; mtx_unlock(&mntvnode_mtx); mtx_lock(&xvp->v_interlock); if (xvp->v_usecount == 0 || xvp->v_type == VNON || Index: ufs/ffs/ffs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.168 diff -u -r1.168 ffs_vfsops.c --- ufs/ffs/ffs_vfsops.c 27 Feb 2002 18:32:22 -0000 1.168 +++ ufs/ffs/ffs_vfsops.c 6 Mar 2002 08:38:21 -0000 @@ -491,6 +491,11 @@ goto loop; } nvp = TAILQ_NEXT(vp, v_nmntvnodes); + /* + * temporary until we replace this with vfs_scan_vnodes XXX + */ + if (vp->v_type == VMARKER) + continue; mtx_unlock(&mntvnode_mtx); /* * Step 4: invalidate all inactive vnodes. @@ -988,7 +993,51 @@ * initiate the writing of the super block if it has been modified. * * Note: we are always called with the filesystem marked `MPBUSY'. + * + * ffs_sync_ffast: non-blocking check for fsync candidate. The + * mountlist mutex will be held during this call. + * A negative return value indicates that the + * vnode may be skipped. + * + * ffs_sync_fslow: potentially blocking execute fsync on vnode. + * The mountlist mutex wil NOT be held. */ + +static int +ffs_sync_ffast(struct vfs_scan_info *info, struct vnode *vp) +{ + struct inode *ip; + + ip = VTOI(vp); + if (vp->v_type == VNON || ((ip->i_flag & + (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && + TAILQ_EMPTY(&vp->v_dirtyblkhd))) { + return(-1); + } + return(0); +} + +static void +ffs_sync_fslow(struct vfs_scan_info *info, struct vnode *vp) +{ + if (vp->v_type != VCHR) { + int error; + + if ((error = vget(vp, info->vs_lockreq, info->vs_td)) != 0) { + if (error == ENOENT) + info->vs_tryagain = 1; + } else { + if ((error = VOP_FSYNC(vp, info->vs_cred, info->vs_waitfor, info->vs_td)) != 0) { + info->vs_allerror = error; + } + VOP_UNLOCK(vp, 0, info->vs_td); + vrele(vp); + } + } else { + UFS_UPDATE(vp, info->vs_wait); + } +} + int ffs_sync(mp, waitfor, cred, td) struct mount *mp; @@ -996,71 +1045,38 @@ struct ucred *cred; struct thread *td; { - struct vnode *nvp, *vp, *devvp; - struct inode *ip; + struct vnode *devvp; struct ufsmount *ump = VFSTOUFS(mp); struct fs *fs; - int error, count, wait, lockreq, allerror = 0; + int error, count, allerror = 0; + struct vfs_scan_info info; fs = ump->um_fs; if (fs->fs_fmod != 0 && fs->fs_ronly != 0) { /* XXX */ printf("fs = %s\n", fs->fs_fsmnt); panic("ffs_sync: rofs mod"); } + /* - * Write back each (modified) inode. + * Setup to scan the vnodes in the mountlist */ - wait = 0; - lockreq = LK_EXCLUSIVE | LK_NOWAIT; + vfs_scan_init(&info); + info.vs_wait = 0; + info.vs_waitfor = waitfor; + info.vs_lockreq = LK_EXCLUSIVE | LK_NOWAIT; if (waitfor == MNT_WAIT) { - wait = 1; - lockreq = LK_EXCLUSIVE; + info.vs_wait = 1; + info.vs_lockreq = LK_EXCLUSIVE; } - mtx_lock(&mntvnode_mtx); + info.vs_td = td; + info.vs_cred = cred; + + /* + * Write back each (modified) inode. + */ loop: - for (vp = TAILQ_FIRST(&mp->mnt_nvnodelist); vp != NULL; vp = nvp) { - /* - * If the vnode that we are about to sync is no longer - * associated with this mount point, start over. - */ - if (vp->v_mount != mp) - goto loop; + allerror = vfs_scan_vnodes(mp, &info, ffs_sync_ffast, ffs_sync_fslow); - /* - * Depend on the mntvnode_slock to keep things stable enough - * for a quick test. Since there might be hundreds of - * thousands of vnodes, we cannot afford even a subroutine - * call unless there's a good chance that we have work to do. - */ - nvp = TAILQ_NEXT(vp, v_nmntvnodes); - ip = VTOI(vp); - if (vp->v_type == VNON || ((ip->i_flag & - (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && - TAILQ_EMPTY(&vp->v_dirtyblkhd))) { - continue; - } - if (vp->v_type != VCHR) { - mtx_unlock(&mntvnode_mtx); - if ((error = vget(vp, lockreq, td)) != 0) { - mtx_lock(&mntvnode_mtx); - if (error == ENOENT) - goto loop; - } else { - if ((error = VOP_FSYNC(vp, cred, waitfor, td)) != 0) - allerror = error; - VOP_UNLOCK(vp, 0, td); - vrele(vp); - mtx_lock(&mntvnode_mtx); - } - } else { - mtx_unlock(&mntvnode_mtx); - UFS_UPDATE(vp, wait); - mtx_lock(&mntvnode_mtx); - } - if (TAILQ_NEXT(vp, v_nmntvnodes) != nvp) - goto loop; - } - mtx_unlock(&mntvnode_mtx); /* * Force stale file system control information to be flushed. */ @@ -1068,10 +1084,8 @@ if ((error = softdep_flushworklist(ump->um_mountp, &count, td))) allerror = error; /* Flushed work items may create new vnodes to clean */ - if (count) { - mtx_lock(&mntvnode_mtx); + if (count) goto loop; - } } #ifdef QUOTA qsync(mp); @@ -1085,12 +1099,11 @@ if ((error = VOP_FSYNC(devvp, cred, waitfor, td)) != 0) allerror = error; VOP_UNLOCK(devvp, 0, td); - if (waitfor == MNT_WAIT) { - mtx_lock(&mntvnode_mtx); + if (waitfor == MNT_WAIT) goto loop; - } - } else + } else { mtx_unlock(&devvp->v_interlock); + } /* * Write back modified superblock. */ Index: ufs/ufs/ufs_quota.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_quota.c,v retrieving revision 1.51 diff -u -r1.51 ufs_quota.c --- ufs/ufs/ufs_quota.c 27 Feb 2002 18:32:22 -0000 1.51 +++ ufs/ufs/ufs_quota.c 6 Mar 2002 08:39:17 -0000 @@ -443,6 +443,11 @@ if (vp->v_mount != mp) goto again; nextvp = TAILQ_NEXT(vp, v_nmntvnodes); + /* + * temporary until we replace this with vfs_scan_vnodes XXX + */ + if (vp->v_type == VMARKER) + continue; mtx_unlock(&mntvnode_mtx); mtx_lock(&vp->v_interlock); @@ -499,6 +504,11 @@ if (vp->v_mount != mp) goto again; nextvp = TAILQ_NEXT(vp, v_nmntvnodes); + /* + * temporary until we replace this with vfs_scan_vnodes XXX + */ + if (vp->v_type == VMARKER) + continue; mtx_unlock(&mntvnode_mtx); mtx_lock(&vp->v_interlock); @@ -698,6 +708,12 @@ if (vp->v_mount != mp) goto again; nextvp = TAILQ_NEXT(vp, v_nmntvnodes); + /* + * temporary until we replace this with vfs_scan_vnodes XXX + */ + if (vp->v_type == VMARKER) + continue; + mtx_unlock(&mntvnode_mtx); mtx_lock(&vp->v_interlock); if (vp->v_type == VNON) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 1:36:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (Postfix) with ESMTP id 03B1E37B400 for ; Wed, 6 Mar 2002 01:36:11 -0800 (PST) Received: from there ([80.60.248.65]) by smtp04.wxs.nl (Netscape Messaging Server 4.15) with SMTP id GSJPC800.HPR; Wed, 6 Mar 2002 10:36:08 +0100 Content-Type: text/plain; charset="iso-8859-1" From: "Peter J. Blok" To: Tony Arcieri , freebsd-hackers@freebsd.org Subject: Re: aio_read() oddness Date: Wed, 6 Mar 2002 10:36:08 +0100 X-Mailer: KMail [version 1.3.2] References: <20020305225908.U48034-100000@rylos.atmos.colostate.edu> In-Reply-To: <20020305225908.U48034-100000@rylos.atmos.colostate.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020306093611.03B1E37B400@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday 06 March 2002 07:03, Tony Arcieri wrote: > I'm not currently subscribed to this list, so please cc replies to me. > > I was playing around with aio_read() and ran into some seemingly aberrant > behavior, although not with aio_read() itself, but the resulting signal. > Within struct aiocb I was setting: > > aio_sigevent.sigev_notify = SIGEV_SIGNAL; > aio_sigevent.sigev_value.sigval_int = 42; > iocb.aio_sigevent.sigev_signo = SIGUSR1; > > Then in the sigaction structure: > sa_flags = SA_SIGINFO; > > Upon completion of the requested read, a signal is sent. Within the > siginfo structure, si_signo is set properly. > > However, si_value.sigval_int is zero. Is this just not implemented > completely yet or am I missing something? I have a set of aio test tools and it indeed seems it is not implemenented. I am getting a zero value too. > > Tony Arcieri > > > 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 Mar 6 2:30:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 23E3237B417 for ; Wed, 6 Mar 2002 02:30:36 -0800 (PST) Received: (qmail 71009 invoked by uid 100); 6 Mar 2002 10:30:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.61384.557931.883967@guru.mired.org> Date: Wed, 6 Mar 2002 04:30:32 -0600 To: obrien@freebsd.org Cc: Mike Meyer , Giorgos Keramidas , hackers@freebsd.org Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: <20020306005225.A6921@dragon.nuxi.com> References: <20020305201350.GC4820@hades.hell.gr> <20020305155850.A38095@dragon.nuxi.com> <20020306000806.GC6839@hades.hell.gr> <20020305164054.B38095@dragon.nuxi.com> <15493.49923.458997.98416@guru.mired.org> <20020306005225.A6921@dragon.nuxi.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien types: > On Wed, Mar 06, 2002 at 01:19:31AM -0600, Mike Meyer wrote: > > David O'Brien types: > > As the original author of the PR, I'll point out that this chagne does > > *not* add rules. It clarifies the wording of a rule that's already > > there. If the rule is wrong, it should be removed. The reason I didn't > > post if for wider review was because it wasn't changing any rules. My > > thanks to Giorgos for moving this PR towards closure. > > I don't think it is clarifying a rule. I think it is in fact adding a > rule. You are extrapolating too much I think. All the rule is trying > to prevent is "if (!strcmp(a,b))" which when read is extremely wrong of > that is actually happening. Ok, I was attempting to clarify a rule, but misinterpreted. Which just reinforces the need for clarifing it. Being an old lisp hand, I'm used to functions that return a value or nil to indicate an error of some kind, and programs that just check the value are SOP. I'll grant that the change Paul suggested makes it clear - the programmer knows when the function is returning an int or not. But it's not clear that it achieves his intent. is char *p; if (p = somerandomfunction(with, args)) { } really less readable than: char *p; if ((p = somerandomfunction(with, args)) != NULL) { } http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 2:38: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 6E83337B416; Wed, 6 Mar 2002 02:37:58 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g26AbgLv030204; Wed, 6 Mar 2002 11:37:42 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Mike Meyer" Cc: obrien@FreeBSD.ORG, Mike Meyer , Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: Your message of "Wed, 06 Mar 2002 04:30:32 CST." <15493.61384.557931.883967@guru.mired.org> Date: Wed, 06 Mar 2002 11:37:42 +0100 Message-ID: <30203.1015411062@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <15493.61384.557931.883967@guru.mired.org>, "Mike Meyer" writes: >I'll grant that the change Paul suggested makes it clear - the >programmer knows when the function is returning an int or not. But >it's not clear that it achieves his intent. is > > char *p; > if (p = somerandomfunction(with, args)) { > } > >really less readable than: > > char *p; > if ((p = somerandomfunction(with, args)) != NULL) { > } Ahh, but here you hit one of my pet-peeves. I hate assignments inside conditionals. I prefer the above written as: char *p; p = somerandomfunction(with, args); if (p != NULL) { } Anyway, if you want it spelled out the way I would want it: 0. No assignments in if() 1. In conditions, pointers should be explicitly compared against NULL: if (foo == NULL) or if (foo != NULL) 2. In conditions, non-interger numeric types should be explicitly compared to zero if (float_t == 0.0) 3. Integers need not be explicitly compared to zero: if (foo & MASK) not if ((foo & MASK) != 0) -- 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 Mar 6 2:44:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 764C537B416 for ; Wed, 6 Mar 2002 02:44:46 -0800 (PST) Received: (qmail 71294 invoked by uid 100); 6 Mar 2002 10:44:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.62234.943657.776598@guru.mired.org> Date: Wed, 6 Mar 2002 04:44:42 -0600 To: Poul-Henning Kamp Cc: "Mike Meyer" , obrien@FreeBSD.ORG, Mike Meyer , Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: <30203.1015411062@critter.freebsd.dk> References: <15493.61384.557931.883967@guru.mired.org> <30203.1015411062@critter.freebsd.dk> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp types: > Ahh, but here you hit one of my pet-peeves. I hate assignments inside > conditionals. I prefer the above written as: > Anyway, if you want it spelled out the way I would want it: > > 0. No assignments in if() > > 1. In conditions, pointers should be explicitly compared against NULL: > > if (foo == NULL) > or > if (foo != NULL) > > 2. In conditions, non-interger numeric types should be explicitly compared > to zero > > if (float_t == 0.0) > > 3. Integers need not be explicitly compared to zero: > > if (foo & MASK) > not > if ((foo & MASK) != 0) I would like it spelled out. Since style(9) uses assignments in conditionals in it's examples, rule 0 probably won't fly. Rule 1 and 2 are redundant. Looking at the text in the page on -stable, I think the one-word change from boolean to "integer" would remove the ambiguity. Thank you, http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 3: 0:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id B0CD537B41A; Wed, 6 Mar 2002 03:00:38 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g26B0o070484; Wed, 6 Mar 2002 12:00:50 +0100 (CET) Date: Wed, 6 Mar 2002 12:02:16 +0100 (CET) From: Martin Blapp To: , , , Subject: Sun idlc broken with our libc_r [Please help] Message-ID: <20020306114738.V56721-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, Rev. 1.20 of src/lib/libc_r/uthread/uthread_join.c still breaks Openoffice build. During the build, the idl compiler from sun just hangs, and stays there in the endless loop. + while (_thread_run->join_status.thread == pthread) { + /* Schedule the next thread: */ + _thread_kern_sched_state(PS_JOIN, __FILE__, __LINE__); + } The same idlc code works fine in Solaris, Linux, and NetBSD (they do not have threads). So it is definitly a FreeBSD libc_r bug. I cannot finish and deliver a working Openoffice port if this does not get fixed for some part :-(( I'm very happy if you have more clues than I have. To build openoffice: cd /usr/ports/editors/openoffice and see the build hanging. Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 3:50:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id E267E37B400 for ; Wed, 6 Mar 2002 03:50:52 -0800 (PST) Received: from localhost ([127.0.0.1]) by vbook.express.ru with esmtp (Exim 3.33 #1) id 16iZwR-0000qn-00; Wed, 06 Mar 2002 14:50:43 +0300 Subject: Re: unionfs and getcwd problem. From: "Vladimir B. " Grebenschikov To: Takanori Watanabe Cc: hackers@freebsd.org In-Reply-To: <200202251435.XAA91094@shidahara1.planet.sci.kobe-u.ac.jp> References: <200202251435.XAA91094@shidahara1.planet.sci.kobe-u.ac.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 06 Mar 2002 14:50:43 +0300 Message-Id: <1015415443.3157.2.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 2002-02-25 at 17:35, Takanori Watanabe wrote: > Hi, I had trouble with unionfs when it calles getcwd(3) when > I mount some directory on the directry in same file system,like > mount -t union /usr/home/foo/bar /usr/src/sys/ . > > I investigate the problem by inserting debug print in getcwd.c. > Then I found issuing __getcwd(2) in getcwd(3) failed, and > climb up filesystem tree as the next way. But it failed when > it reaches to mount point. It seems that st_dev and st_ino > member returns the same number as the underlying filesystem > so it failed to recognize mount point. So I tried the patch as > follows taken from nullfs. Are there any problem with this patch? patch below will turn on caching on unionfs, and solve getcwd problem, patch against -CURRENT --- /usr/src/sys/fs/unionfs/union_vnops.c Sat Feb 23 13:54:45 2002 +++ union_vnops.c Wed Mar 6 14:44:59 2002 @@ -561,6 +561,9 @@ */ out: + if ((error == 0 || error == ENOENT) && saveflags & MAKEENTRY && cnp->cn_nameiop != CREATE) { + cache_enter(dvp, *ap->a_vpp, cnp); + } if (upperdvp) { if (upperdvp == uppervp || upperdvp == *ap->a_vpp) vrele(upperdvp); @@ -1931,7 +1934,8 @@ { &vop_lease_desc, (vop_t *) union_lease }, { &vop_link_desc, (vop_t *) union_link }, { &vop_lock_desc, (vop_t *) union_lock }, - { &vop_lookup_desc, (vop_t *) union_lookup }, + { &vop_cachedlookup_desc, (vop_t *) union_lookup }, + { &vop_lookup_desc, (vop_t *) vfs_cache_lookup }, { &vop_mkdir_desc, (vop_t *) union_mkdir }, { &vop_mknod_desc, (vop_t *) union_mknod }, { &vop_open_desc, (vop_t *) union_open > Takanori Watanabe -- TSB "Russian Express", Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 3:59: 2 2002 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 2144037B400; Wed, 6 Mar 2002 03:58:59 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 8E6315347; Wed, 6 Mar 2002 12:58:56 +0100 (CET) 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: Patrick Thomas Cc: , Subject: Re: Four misc. questions related to jail usage References: <20020305164246.Y71209-100000@utility.clubscholarship.com> From: Dag-Erling Smorgrav Date: 06 Mar 2002 12:58:55 +0100 In-Reply-To: <20020305164246.Y71209-100000@utility.clubscholarship.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas writes: > > No, procfs is pretty much useless these days (except for truss). > In 4.5, won't `ps` (and perhaps other apps) not work for people in a jail > if their jail does not have a proc file system mounted in their /proc ? Only 'ps -e'. Everything else will work just fine. 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 Wed Mar 6 4:19:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from breg.mc.mpls.visi.com (breg.mc.mpls.visi.com [208.42.156.101]) by hub.freebsd.org (Postfix) with ESMTP id 369C737B400 for ; Wed, 6 Mar 2002 04:19:16 -0800 (PST) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by breg.mc.mpls.visi.com (Postfix) with ESMTP id 543592D0523; Wed, 6 Mar 2002 06:19:15 -0600 (CST) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.6/8.11.6) id g26CJEJ61813; Wed, 6 Mar 2002 06:19:14 -0600 (CST) (envelope-from hawkeyd) Date: Wed, 6 Mar 2002 06:19:14 -0600 (CST) Message-Id: <200203061219.g26CJEJ61813@sheol.localdomain> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: hawkeyd@visi.com Organization: if (!FIFO) if (!LIFO) break; References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> In-Reply-To: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> From: hawkeyd@visi.com (D J Hawkey Jr) Subject: Re: C vs C++ X-Original-Newsgroups: sol.lists.freebsd.hackers To: bts@babbleon.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net>, bts@babbleon.org writes: > On Tuesday 05 March 2002 11:28 am, Kenneth Mays wrote: > > [SNIP] > > Besides, it's not C++ that provides whatever questionable benefits it > provides; it's OO methodology which can come in handy, and there are more > elegant OO solutions than C++ around. Hear, Hear! In my small, insignificant opinion, I thought the creators of C++ were cracked for taking a small, concise, procedural, and beautiful, language like C and obfuscating (read: "corrupting") it with all that overloading stuff. Most of the class stuff can be implemented in C, though perhaps not as "transparently". They should have left well enough alone, and advocated languages that were/are OOPL by concept as well as design. I'll go away now. Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 5: 5:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5398837B405; Wed, 6 Mar 2002 05:05:32 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g26D5UcD025543; Wed, 6 Mar 2002 08:05:30 -0500 (EST) Date: Wed, 6 Mar 2002 08:05:30 -0500 (EST) From: Daniel Eischen To: Martin Blapp Cc: deischen@freebsd.org, rittle@labs.mot.com, alfred@freebsd.org, hackers@freebsd.org Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: <20020306114738.V56721-100000@levais.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Martin Blapp wrote: > Hi all, > > Rev. 1.20 of src/lib/libc_r/uthread/uthread_join.c still breaks > Openoffice build. > > During the build, the idl compiler from sun just hangs, and stays > there in the endless loop. > > + while (_thread_run->join_status.thread == pthread) { > + /* Schedule the next thread: */ > + _thread_kern_sched_state(PS_JOIN, __FILE__, __LINE__); > + } This loop is correct, like I've said twice before. > The same idlc code works fine in Solaris, Linux, and NetBSD (they do > not have threads). > > So it is definitly a FreeBSD libc_r bug. Did you even try the patch I sent you to uthread_detach.c? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 5:49:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 287F737B400; Wed, 6 Mar 2002 05:49:34 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g26Dnk010067; Wed, 6 Mar 2002 14:49:46 +0100 (CET) Date: Wed, 6 Mar 2002 14:51:12 +0100 (CET) From: Martin Blapp To: Cc: , Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: Message-ID: <20020306145012.T56721-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, > This loop is correct, like I've said twice before. > Did you even try the patch I sent you to uthread_detach.c? I've not recieved any patch. Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 5:52: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by hub.freebsd.org (Postfix) with SMTP id 8E41F37B400 for ; Wed, 6 Mar 2002 05:51:58 -0800 (PST) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Wed Mar 6 05:51:52 2002 To: freebsd-hackers@freebsd.org Date: Wed, 06 Mar 2002 19:21:52 +0530 From: "Rajesh P Jain" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: rpjain_1977@eudoramail.com X-Mailer: MailCity Service Subject: BPF - Locally Generated Packet Reception X-Sender-Ip: 203.197.138.199 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, In the BPF - Berkeley Packet Filter, when a file descriptor is associated to an interface to send and receive packets, there is an ioctl parameter "BIOCSSEESENT", which is by default set to 1. Hence the packets both from "remote systems" and "locally generated" are received. If "locally generated" packets needs to be filtered, we can use the option "BIOCSSEESENT" and set the value to 0. But even after setting this value to 0 (using the ioctl call), the "locally generated" packets are received. Am I missing something ? Plese throw light on this issue. TIA Raj Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 5:53:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by hub.freebsd.org (Postfix) with SMTP id 796C737B419 for ; Wed, 6 Mar 2002 05:53:31 -0800 (PST) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Wed Mar 6 05:53:20 2002 To: freebsd-hackers@freebsd.org Date: Wed, 06 Mar 2002 19:23:20 +0530 From: "Rajesh P Jain" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: rpjain_1977@eudoramail.com X-Mailer: MailCity Service Subject: (No Subject) X-Sender-Ip: 203.197.138.199 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, In the BPF - Berkeley Packet Filter, when a file descriptor is associated to an interface to send and receive packets, there is an ioctl parameter "BIOCSSEESENT", which is by default set to 1. Hence the packets both from "remote systems" and "locally generated" are received. If "locally generated" packets needs to be filtered, we can use the option "BIOCSSEESENT" and set the value to 0. But even after setting this value to 0 (using the ioctl call), the "locally generated" packets are received. Am I missing something ? Plese throw light on this issue. TIA Raj Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 7:18:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8259137B404; Wed, 6 Mar 2002 07:18:38 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g26FIbmX011951; Wed, 6 Mar 2002 10:18:37 -0500 (EST) Date: Wed, 6 Mar 2002 10:18:37 -0500 (EST) From: Daniel Eischen To: Martin Blapp Cc: hackers@FreeBSD.ORG, rittle@labs.mot.com, alfred@FreeBSD.ORG Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: <20020306145012.T56721-100000@levais.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Martin Blapp wrote: > > Hi, > > > This loop is correct, like I've said twice before. > > Did you even try the patch I sent you to uthread_detach.c? > > I've not recieved any patch. Here it is again: Index: uthread/uthread_detach.c =================================================================== RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_detach.c,v retrieving revision 1.16 diff -u -r1.16 uthread_detach.c --- uthread/uthread_detach.c 20 May 2001 23:08:32 -0000 1.16 +++ uthread/uthread_detach.c 27 Feb 2002 04:57:39 -0000 @@ -67,6 +67,8 @@ /* Set the return value for the woken thread: */ joiner->error = ESRCH; + pthread->join_status.error = 0; + pthread->join_status.thread = NULL; /* * Disconnect the joiner from the thread being detached: -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 7:21:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id A346837B428 for ; Wed, 6 Mar 2002 07:21:04 -0800 (PST) Received: from hades.hell.gr (patr530-a100.otenet.gr [212.205.215.100]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g26FKquj026215; Wed, 6 Mar 2002 17:20:53 +0200 (EET) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g26FL20W010617; Wed, 6 Mar 2002 17:21:04 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g263KTX2008309; Wed, 6 Mar 2002 05:20:29 +0200 (EET) (envelope-from keramida@freebsd.org) X-Authentication-Warning: hades.hell.gr: charon set sender to keramida@freebsd.org using -f Date: Wed, 6 Mar 2002 05:20:29 +0200 From: Giorgos Keramidas To: Terry Lambert Cc: "Steve B." , freebsd-hackers@freebsd.org Subject: Re: C vs C++ Message-ID: <20020306032029.GA7926@hades.hell.gr> References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <001701c1c481$d0d5eab0$f642d9cf@DROID> <20020305231252.GC5328@hades.hell.gr> <3C8568E0.76415D99@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C8568E0.76415D99@mindspring.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-03-05 16:54, Terry Lambert wrote: > Giorgos Keramidas wrote: > > The steeper learning curve of C++ is indeed steeper, not because of > > some magic property of the object-oriented programming paradigm, but > > because there are a lot more things to learn, before a complete > > program can be written, IMHO. > > Uh... "Hello World" looks the same in ANSI C and C++, unless > you insist on using I/O streams and "cout", which no one ever > really does, unless they are writing a C++ book or trying to > impress a student. Well, to be frank, I've seen a few C++ coding style documents, that suggest avoiding altogether when writing in C++. The fact that parts of the C++ libraries already use the I/O stream classes, which have their own buffers, combined with the buffered I/O that does by default, can and usually does result in all hell being let loose. But then, I'm probably starting to go off topic here... Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 7:29:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id A7C1537B404 for ; Wed, 6 Mar 2002 07:29:34 -0800 (PST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g26FTC304484; Wed, 6 Mar 2002 07:29:12 -0800 (PST) Received: from orbit-fe.eng (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g26FT31Z011964; Wed, 6 Mar 2002 07:29:03 -0800 (PST) Received: from localhost (kmacy@localhost) by orbit-fe.eng (8.11.6+Sun/8.11.6) with ESMTP id g26FSlR17378; Wed, 6 Mar 2002 07:28:51 -0800 (PST) Date: Wed, 6 Mar 2002 07:28:47 -0800 (PST) From: Kip Macy To: "Peter J. Blok" Cc: Tony Arcieri , freebsd-hackers@FreeBSD.ORG Subject: Re: aio_read() oddness In-Reply-To: <20020306093611.03B1E37B400@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG FreeBSD does not support queued signals (part of RT Posix) which is required for this. -Kip ========================================================================= For RAIDANT status see: http://cranford.eng.netapp.com:8080/cgi-bin/ant4/index.cgi To submit RAIDANT test descriptions go to: http://web.netapp.com/engineering/projects/raidv2/testing/ Ontap on the web: http://web.netapp.com/engineering/projects/raidv2/testing/global/ On Wed, 6 Mar 2002, Peter J. Blok wrote: > On Wednesday 06 March 2002 07:03, Tony Arcieri wrote: > > I'm not currently subscribed to this list, so please cc replies to me. > > > > I was playing around with aio_read() and ran into some seemingly aberrant > > behavior, although not with aio_read() itself, but the resulting signal. > > Within struct aiocb I was setting: > > > > aio_sigevent.sigev_notify = SIGEV_SIGNAL; > > aio_sigevent.sigev_value.sigval_int = 42; > > iocb.aio_sigevent.sigev_signo = SIGUSR1; > > > > Then in the sigaction structure: > > sa_flags = SA_SIGINFO; > > > > Upon completion of the requested read, a signal is sent. Within the > > siginfo structure, si_signo is set properly. > > > > However, si_value.sigval_int is zero. Is this just not implemented > > completely yet or am I missing something? > I have a set of aio test tools and it indeed seems it is not implemenented. I > am getting a zero value too. > > > > Tony Arcieri > > > > > > 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 Mar 6 7:31:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from tepid.osl.fast.no (tepid.osl.fast.no [213.188.9.130]) by hub.freebsd.org (Postfix) with ESMTP id B425437B400 for ; Wed, 6 Mar 2002 07:31:18 -0800 (PST) Received: from raw.grenland.fast.no.fast.no (raw.grenland.fast.no [192.168.48.104]) by tepid.osl.fast.no (8.9.3/8.9.1) with ESMTP id QAA07124; Wed, 6 Mar 2002 16:31:05 +0100 (CET) (envelope-from Raymond.Wiker@fast.no) From: Raymond Wiker MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.13878.219807.949085@raw.grenland.fast.no> Date: Wed, 6 Mar 2002 16:31:02 +0100 To: Giorgos Keramidas Cc: Terry Lambert , "Steve B." , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <20020306032029.GA7926@hades.hell.gr> References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <001701c1c481$d0d5eab0$f642d9cf@DROID> <20020305231252.GC5328@hades.hell.gr> <3C8568E0.76415D99@mindspring.com> <20020306032029.GA7926@hades.hell.gr> X-Mailer: VM 7.00 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Giorgos Keramidas writes: > On 2002-03-05 16:54, Terry Lambert wrote: > > Giorgos Keramidas wrote: > > > The steeper learning curve of C++ is indeed steeper, not because of > > > some magic property of the object-oriented programming paradigm, but > > > because there are a lot more things to learn, before a complete > > > program can be written, IMHO. > > > > Uh... "Hello World" looks the same in ANSI C and C++, unless > > you insist on using I/O streams and "cout", which no one ever > > really does, unless they are writing a C++ book or trying to > > impress a student. > > Well, to be frank, I've seen a few C++ coding style documents, that suggest > avoiding altogether when writing in C++. The fact that parts of > the C++ libraries already use the I/O stream classes, which have their own > buffers, combined with the buffered I/O that does by default, > can and usually does result in all hell being let loose. I assume you mean ? Anyway, I *really* can't see any reason not to use , , and friends. I also cannot see any reason not to use exceptions, the standard containers, the string classes etc. Used properly, these make it possible to write code that is inherently safer than anything built around printf/scanf, char *, longjump, etc. Without these (and a few others) you may just as well stay with standard C. Then again, if you want to do object-oriented programming, C++ is probably not the right choice. If you want to use several different paradigms simulataneously in one language, C++ may be a better fit - although Common Lisp is a much better choice :-) //Raymond. -- Raymond Wiker Mail: Raymond.Wiker@fast.no Senior Software Engineer Web: http://www.fast.no/ Fast Search & Transfer ASA Phone: +47 23 01 11 60 P.O. Box 1677 Vika Fax: +47 35 54 87 99 NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 Try FAST Search: http://alltheweb.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 8:15:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id A05A637B416 for ; Wed, 6 Mar 2002 08:15:49 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g26GFaq19062; Wed, 6 Mar 2002 16:15:36 GMT (envelope-from mark@grimreaper.grondar.za) Received: from grimreaper (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.2/8.12.2) with ESMTP id g26GARRV092991; Wed, 6 Mar 2002 16:10:27 GMT (envelope-from mark@grimreaper.grondar.za) Message-Id: <200203061610.g26GARRV092991@grimreaper.grondar.org> To: Adrian Filipi-Martin Cc: FreeBSD Hackers List , kaj@ubergeeks.com Subject: Re: Intel 820 RNG References: <20020306102600.L56921-100000@lorax.ubergeeks.com> In-Reply-To: <20020306102600.L56921-100000@lorax.ubergeeks.com> ; from Adrian Filipi-Martin "Wed, 06 Mar 2002 10:30:27 EST." Date: Wed, 06 Mar 2002 16:10:26 +0000 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Again, look at current. The RNG is _really_ fast. > > I know. I know. I wish we could use it. Unfortunately this is > for an appliance type application and I just don't feel comfortably > shipping -CURRENT as product. I'm only just now making the effort to get > up to speed on -CURRENT so that we can be ready to use it later this year. Also - have you looked at STABLE's /dev/urandom? M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 8:33:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ip68-14-62-49.no.no.cox.net (ip68-14-62-49.no.no.cox.net [68.14.62.49]) by hub.freebsd.org (Postfix) with ESMTP id 3475437B400 for ; Wed, 6 Mar 2002 08:33:05 -0800 (PST) Received: (from conrads@localhost) by ip68-14-62-49.no.no.cox.net (8.11.6/8.11.6) id g26GX0s79009 for freebsd-hackers@FreeBSD.ORG; Wed, 6 Mar 2002 10:33:00 -0600 (CST) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200203061610.g26GARRV092991@grimreaper.grondar.org> Date: Wed, 06 Mar 2002 10:33:00 -0600 (CST) Reply-To: conrads@cox.net Organization: A Rag-Tag Band of Drug-crazed Hippies From: Conrad Sabatier To: FreeBSD Hackers List Subject: kqueue example code - suggestions? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Could anyone suggest a package I might look at to get an example of "real world" kqueue() processing that would be not too difficult to digest? I'm interested in converting an existing package from using poll() to kqueue(). Thanks. -- Conrad Sabatier Nothing takes the taste out of peanut butter quite like unrequited love. -- Charlie Brown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 8:37:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id BA0F437B419 for ; Wed, 6 Mar 2002 08:37:37 -0800 (PST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g26GbV308393; Wed, 6 Mar 2002 08:37:31 -0800 (PST) Received: from orbit-fe.eng (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g26GbUhY018018; Wed, 6 Mar 2002 08:37:30 -0800 (PST) Received: from localhost (kmacy@localhost) by orbit-fe.eng (8.11.6+Sun/8.11.6) with ESMTP id g26GbTH20071; Wed, 6 Mar 2002 08:37:29 -0800 (PST) Date: Wed, 6 Mar 2002 08:37:29 -0800 (PST) From: Kip Macy To: Conrad Sabatier Cc: FreeBSD Hackers List Subject: Re: kqueue example code - suggestions? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG thttpd ========================================================================= For RAIDANT status see: http://cranford.eng.netapp.com:8080/cgi-bin/ant4/index.cgi To submit RAIDANT test descriptions go to: http://web.netapp.com/engineering/projects/raidv2/testing/ Ontap on the web: http://web.netapp.com/engineering/projects/raidv2/testing/global/ On Wed, 6 Mar 2002, Conrad Sabatier wrote: > Could anyone suggest a package I might look at to get an example of "real > world" kqueue() processing that would be not too difficult to digest? I'm > interested in converting an existing package from using poll() to kqueue(). > > Thanks. > > -- > Conrad Sabatier > > Nothing takes the taste out of peanut butter quite like unrequited > love. > -- Charlie Brown > > > 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 Mar 6 8:38:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 791E437B419; Wed, 6 Mar 2002 08:38:45 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g26Gcq050702; Wed, 6 Mar 2002 17:38:52 +0100 (CET) Date: Wed, 6 Mar 2002 17:40:18 +0100 (CET) From: Martin Blapp To: Daniel Eischen Cc: , , , Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: Message-ID: <20020306171848.W56721-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Daniel, Unfortunatly the patch doesn't work ... ============= Building project udkapi ============= /usr/ports/editors/openoffice-work/work/oo_641c_src/udkapi/com/sun/star/lang mkout -- version: 1.3 idlc @/var/tmp/mk2H0dIj idlc: compile 'ArrayIndexOutOfBoundsException.idl' ... and there it hangs ... > Did you even try the patch I sent you to uthread_detach.c? > >Index: uthread/uthread_detach.c >=================================================================== >RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_detach.c,v >retrieving revision 1.16 >diff -u -r1.16 uthread_detach.c >--- uthread/uthread_detach.c 20 May 2001 23:08:32 -0000 1.16 >+++ uthread/uthread_detach.c 27 Feb 2002 04:57:39 -0000 >@@ -67,6 +67,8 @@ > > /* Set the return value for the woken thread: */ > joiner->error = ESRCH; >+ pthread->join_status.error = 0; >+ pthread->join_status.thread = NULL; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 8:45:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id BCAA937B404 for ; Wed, 6 Mar 2002 08:45:10 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g26Gj1m08865; Wed, 6 Mar 2002 11:45:01 -0500 (EST) Date: Wed, 6 Mar 2002 11:43:16 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: "Brian T.Schellenberger" Cc: Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <20020306025055.2C1B5BA03@i8k.babbleon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, Brian T.Schellenberger wrote: > On Tuesday 05 March 2002 06:32 pm, Zhihui Zhang wrote: > > I apologize for all who have followed this. I made a typo in the original > > email. What I observed is that writing LESS performs WORSE. Since all > > blocks are laid out contiguously and I write them sequentially, there > > should not be any seek problem. > > Hmmm . . . perhaps I misunderstood you, but I thought that you said that in > the original mail that you were writing to the same number of disk blocks > eiteher way but in some cases you were writing partial blocks and in some > cases full blocks. How do you do that if you don't seek? > > If you aren't seeking, then you must be, in the slower case, writing partial > blocks. Well, there is some size where the disk has physical blocks. On > some disks, writes are always done in full physical blocks. To write a > partial block, the block is read from disk, the data to be written is > substituted and then the entire block is written. This would certainly be > likely to be slower than writing a whole block. In the case of partial block writes, I move to the next block which is contiguous to the current block. So the start address of each write in both cases are exactly the same. The only difference is that one write full blocks, the other write partial blocks. I also do not read anything during the partial block write, and I think the disk controller should not do that either. -Zhihui > Does this possibly explain what you are seeing? > > Note that I have no clue whether this happens with many real disks, or even > with any made in the last 20 years, but I have heard tell of such things. > > > I have modified the kernel in > > kern_physio.c and find out that physio() is called by expected number of > > times. I even add some code to record the time elapsed there: > > > > t1 = time_second; > > > > BUF_STRATEGY(bp, 0); > > spl = splbio(); > > while ((bp->b_flags & B_DONE) == 0) > > tsleep((caddr_t)bp, PRIBIO, "physstr", 0); > > splx(spl); > > > > t2 = time_second; > > physio_time += t2 - t1; > > > > the physio_time (a sysctl variable) is close to the time reported by the > > user program. > > > > -Zhihui > > > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > > Zhihui Zhang wrote: > > > > Several times slower! The point is that writing less data performs > > > > worse. So I call it weird. > > > > > > Huh? You originally said: > > > > (1) Write each block fully and sequentially, ie. 8192 bytes. > > > > > > > > (2) I still write these blocks sequentially, but for each block I only > > > > write part of it. > > > > > > ... > > > > > > > I find out the the performance of (2) is several times better than the > > > > performance of (1). Can anyone explain to me why this is the case? > > > > > > If (2) is better than (1), then writing *less* data is faster. Which is > > > it, now? > > > > > > Lars > > > > > > > -Zhihui > > > > > > > > On Tue, 5 Mar 2002, Lars Eggert wrote: > > > >>Zhihui Zhang wrote: > > > >>>Well, the core of my program is as follows (RANDOM(x) return a value > > > >>>between 0 and x): > > > >>> > > > >>> blocksize = 8192; > > > >>> write_size_low = 512; > > > >>> > > > >>> time(&time1); > > > >>> for (i = 0; i < write_count; i++) { > > > >>> write_size = write_size_low + > > > >>> RANDOM(write_size_high-write_size_low); > > > >>> write_size = roundup(write_size, DEV_BSIZE); > > > >>> if (testcase == 1) > > > >>> write_size = blocksize; > > > >>> write_block(rawfd, sectorno, buf, write_size); > > > >>> sectorno += blocksize / DEV_BSIZE; > > > >>> } > > > >>> time(&time2); > > > >>> > > > >>>If testcase is one, then the time elapsed (time2 - time1) is much > > > >>> less. > > > >> > > > >>How "much less" in milliseconds? > > > >> > > > >>Also, in your original mail, you said you had 15,000 of these 8K > > > >> blocks, which is only 120MB or so. Use 150,000 or 1,500,000 and check > > > >> your results then. > > > >> > > > >>Lars > > > >> > > > >>>-Zhihui > > > >>> > > > >>>On Tue, 5 Mar 2002, Lars Eggert wrote: > > > >>>>I agree that it's probably caching at some level. You're only writing > > > >>>>about 120MB of data (and half that in your second case). Bump these > > > >>>> to a couple of GB and see what happens. > > > >>>> > > > >>>>Also, could you post your actual measurements? > > > >>>> > > > >>>>Lars > > > >>>> > > > >>>>Zhihui Zhang wrote: > > > >>>>>The machine has 128M memory. I am doing physical I/O one block at a > > > >>>>> time, so there should be no memory copy. > > > >>>>> > > > >>>>>-Zhihui > > > >>>>> > > > >>>>>On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: > > > >>>>>>At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: > > > >>>>>>>On Tue, 5 Mar 2002, Julian Elischer wrote: > > > >>>>>>>>more writes fit in the disk's write cache? > > > >>>>>>> > > > >>>>>>>For (1), it writes 15000 * 8192 bytes in all. For (2), it writes > > > >>>>>>> 15000 * 4096 bytes in all (assuming the random number distributes > > > >>>>>>> evenly between 0 and 8192). So your suggestion does not make > > > >>>>>>> sense to me. > > > >>>>>> > > > >>>>>>How large is your buffercache? it might be that the 15000 * ~4096 > > > >>>>>> roughly matches with your cache, and 15000 * 8912 doesn't. > > > >>>>>> > > > >>>>>>Case (1) would require a lot more physical IO in that case than > > > >>>>>> case (2) would require. > > > >>>>>> > > > >>>>>> Doc > > > >>>>>> > > > >>>>>>>-Zhihui > > > >>>>>>> > > > >>>>>>>>On Tue, 5 Mar 2002, Zhihui Zhang wrote: > > > >>>>>>>>>I am doing some raw I/O test on a seagate SCSI disk running > > > >>>>>>>>> FreeBSD 4.5. This situation is like this: > > > >>>>>>>>> > > > >>>>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ > > > >>>>>>>>> > > > >>>>>>>>>| | | | | | | | | | | | .... > > > >>>>>>>>> > > > >>>>>>>>>+-----+----+----+----+----+----+----+----+----+----+---+------ > > > >>>>>>>>> > > > >>>>>>>>>Each block is of fixed size, say 8192 bytes. Now I have a user > > > >>>>>>>>> program writing each contiguously laid out block sequentially > > > >>>>>>>>> using /dev/daxxx interface. There are a lot of them, say 15000. > > > >>>>>>>>> I write the blocks in two ways (the data used in writing are > > > >>>>>>>>> garbage): > > > >>>>>>>>> > > > >>>>>>>>>(1) Write each block fully and sequentially, ie. 8192 bytes. > > > >>>>>>>>> > > > >>>>>>>>>(2) I still write these blocks sequentially, but for each block > > > >>>>>>>>> I only write part of it. Exactly how many bytes are written > > > >>>>>>>>> inside each > > > >>>>>>> > > > >>>>>>>block is > > > >>>>>>> > > > >>>>>>>>>determinted by a random number between 512 .. 8192 bytes > > > >>>>>>>>> (rounded up a to multiple of 512 bytes). > > > >>>>>>>>> > > > >>>>>>>>>I find out the the performance of (2) is several times better > > > >>>>>>>>> than the performance of (1). Can anyone explain to me why this > > > >>>>>>>>> is the case? > > > >>>>>>>>> > > > >>>>>>>>>Thanks for any suggestions or hints. > > > >>>>>>>>> > > > >>>>>>>>>-Zhihui > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>>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 > > > >>>> > > > >>>>-- > > > >>>>Lars Eggert Information Sciences > > > >>>> Institute http://www.isi.edu/larse/ University of > > > >>>> Southern California > > > >> > > > >>-- > > > >>Lars Eggert Information Sciences > > > >> Institute http://www.isi.edu/larse/ University of > > > >> Southern California > > > > > > -- > > > Lars Eggert Information Sciences Institute > > > http://www.isi.edu/larse/ University of Southern California > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) > Brian, the man from Babble-On . . . . bts@babbleon.org (personal) > ME --> http://www.babbleon.org > http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org > > 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 Mar 6 8:46:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 5B7F437B400 for ; Wed, 6 Mar 2002 08:45:43 -0800 (PST) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.6/8.11.6) with ESMTP id g26GjYx8223707; Wed, 6 Mar 2002 19:45:35 +0300 (MSK) Date: Wed, 6 Mar 2002 19:45:34 +0300 (MSK) From: Maxim Konovalov To: Conrad Sabatier Cc: FreeBSD Hackers List Subject: Re: kqueue example code - suggestions? In-Reply-To: Message-ID: <20020306194446.M97532-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10:33-0600, Mar 6, 2002, Conrad Sabatier wrote: > Could anyone suggest a package I might look at to get an example of "real > world" kqueue() processing that would be not too difficult to digest? I'm > interested in converting an existing package from using poll() to kqueue(). /usr/src/usr.bin/tail/forward.c -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 8:51:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.openet-telecom.com (mail.openet-telecom.com [62.17.151.60]) by hub.freebsd.org (Postfix) with ESMTP id 5C7CB37B431 for ; Wed, 6 Mar 2002 08:51:10 -0800 (PST) Received: from gpo.openet-telecom.lan (unverified) by mail.openet-telecom.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 6 Mar 2002 16:59:47 +0000 Received: from openet-telecom.com (10.0.0.40) by gpo.openet-telecom.lan (NPlex 6.5.007) id 3C862B5E000003E9; Wed, 6 Mar 2002 16:47:06 +0000 Message-ID: <3C8648F5.1EC1E4EE@openet-telecom.com> Date: Wed, 06 Mar 2002 16:51:01 +0000 From: Peter Edwards X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Zhihui Zhang Cc: "Brian T.Schellenberger" , Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Zhihui Zhang wrote: > ... I also do not read anything during the partial block write, > and I think the disk controller should not do that either. If you do a partial block write, surely at some point the block must be read in order to preserve that segment of data you are _not_ overwriting? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 8:52:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 02F2137B400; Wed, 6 Mar 2002 08:52:49 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g26GqnQ5027132; Wed, 6 Mar 2002 11:52:49 -0500 (EST) Date: Wed, 6 Mar 2002 11:52:49 -0500 (EST) From: Daniel Eischen To: Martin Blapp Cc: deischen@freebsd.org, rittle@labs.mot.com, alfred@freebsd.org, hackers@freebsd.org Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: <20020306171848.W56721-100000@levais.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Martin Blapp wrote: > > Hi Daniel, > > Unfortunatly the patch doesn't work ... Try adding this patch also (keep other patch in): Index: uthread_cancel.c =================================================================== RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_cancel.c,v retrieving revision 1.11 diff -u -r1.11 uthread_cancel.c --- uthread_cancel.c 16 Dec 2001 13:26:44 -0000 1.11 +++ uthread_cancel.c 6 Mar 2002 16:57:18 -0000 @@ -70,6 +70,9 @@ if (pthread->join_status.thread != NULL) { pthread->join_status.thread->joiner = NULL; + pthread->join_status.thread = NULL; + pthread->join_status.ret = NULL; + pthread->join_status.error = 0; } pthread->cancelflags |= PTHREAD_CANCELLING; PTHREAD_NEW_STATE(pthread, PS_RUNNING); -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9: 0:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bogslab.ucdavis.edu (bogslab.ucdavis.edu [169.237.68.34]) by hub.freebsd.org (Postfix) with ESMTP id 3F38037B417 for ; Wed, 6 Mar 2002 09:00:01 -0800 (PST) Received: from thistle.bogs.org (thistle.bogs.org [198.137.203.61]) by bogslab.ucdavis.edu (8.9.3/8.9.3) with ESMTP id IAA06081 for ; Wed, 6 Mar 2002 08:59:55 -0800 (PST) (envelope-from greg@bogslab.ucdavis.edu) Received: from thistle.bogs.org (localhost [127.0.0.1]) by thistle.bogs.org (8.11.3/8.11.3) with ESMTP id g26GxI979195 for ; Wed, 6 Mar 2002 08:59:18 -0800 (PST) (envelope-from greg@thistle.bogs.org) Message-Id: <200203061659.g26GxI979195@thistle.bogs.org> To: hackers@FreeBSD.ORG X-To: "David O'Brien" X-Sender: owner-freebsd-hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-reply-to: Your message of "Wed, 06 Mar 2002 00:52:25 PST." <20020306005225.A6921@dragon.nuxi.com> Reply-To: gkshenaut@ucdavis.edu Date: Wed, 06 Mar 2002 08:59:18 -0800 From: Greg Shenaut Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020306005225.A6921@dragon.nuxi.com>, "David O'Brien" cleopede: >I don't think it is clarifying a rule. I think it is in fact adding a >rule. You are extrapolating too much I think. All the rule is trying >to prevent is "if (!strcmp(a,b))" which when read is extremely wrong of >that is actually happening. Too bad "strcmp" wasn't named "strdiff"--just think of all the hassle that would have prevented over the years... Greg Shenaut To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9: 0:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.vaxxine.com (alpha.vaxxine.com [209.5.212.5]) by hub.freebsd.org (Postfix) with ESMTP id 4966537B417 for ; Wed, 6 Mar 2002 09:00:25 -0800 (PST) Received: from there (ppp172.digi-t3.st-cath.niagara.net [209.5.215.172]) by alpha.vaxxine.com (8.9.2/8.9.3) with SMTP id MAA11066 for ; Wed, 6 Mar 2002 12:00:23 -0500 (EST) Message-Id: <200203061700.MAA11066@alpha.vaxxine.com> Content-Type: text/plain; charset="iso-8859-1" From: "Paul C. Boyle" To: freebsd-hackers@freebsd.org Subject: I need hack, I would like a clock like the xdaliclock but reads the time out in HEX. Date: Wed, 6 Mar 2002 12:01:30 -0500 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Does someone have this availale already. I am not a programer, but wish I could. There is a lot of neet things I would like to try. But I can't afford to take night classes as of this time If there is anyone out there that could mentor me in C or C++ ( I have minimal exposure to these.) I have looked a Python and found it a bit confusing not having to delare everything and aslo it has no unary opperator. Is there a Master Yoda sensing a disturbance in the force? Until then... So long, and thanks for all the fish! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9:10:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id EDF2337B402 for ; Wed, 6 Mar 2002 09:10:37 -0800 (PST) Received: (qmail 6141 invoked by uid 1000); 6 Mar 2002 17:10:55 -0000 Date: Wed, 6 Mar 2002 19:10:55 +0200 From: Peter Pentchev To: Zhihui Zhang Cc: "Brian T.Schellenberger" , Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour Message-ID: <20020306191055.F14052@straylight.oblivion.bg> Mail-Followup-To: Zhihui Zhang , "Brian T.Schellenberger" , Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG References: <20020306025055.2C1B5BA03@i8k.babbleon.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3oCie2+XPXTnK5a5" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zzhang@cs.binghamton.edu on Wed, Mar 06, 2002 at 11:43:16AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --3oCie2+XPXTnK5a5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2002 at 11:43:16AM -0500, Zhihui Zhang wrote: >=20 >=20 > On Tue, 5 Mar 2002, Brian T.Schellenberger wrote: >=20 > > On Tuesday 05 March 2002 06:32 pm, Zhihui Zhang wrote: > > > I apologize for all who have followed this. I made a typo in the orig= inal > > > email. What I observed is that writing LESS performs WORSE. Since all > > > blocks are laid out contiguously and I write them sequentially, there > > > should not be any seek problem. > >=20 > > Hmmm . . . perhaps I misunderstood you, but I thought that you said tha= t in=20 > > the original mail that you were writing to the same number of disk bloc= ks=20 > > eiteher way but in some cases you were writing partial blocks and in so= me=20 > > cases full blocks. How do you do that if you don't seek? > >=20 > > If you aren't seeking, then you must be, in the slower case, writing pa= rtial=20 > > blocks. Well, there is some size where the disk has physical blocks. = On=20 > > some disks, writes are always done in full physical blocks. To write a= =20 > > partial block, the block is read from disk, the data to be written is= =20 > > substituted and then the entire block is written. This would certainly= be=20 > > likely to be slower than writing a whole block. >=20 > In the case of partial block writes, I move to the next block which is > contiguous to the current block. So the start address of each write in > both cases are exactly the same. The only difference is that one write > full blocks, the other write partial blocks. I also do not read anything > during the partial block write, and I think the disk controller should not > do that either. If 'moving to the next block' means a seek, that is, if write_block() seeks forward, then maybe this part of an earlier message in the thread by Brian T.Schellenberger would be helpful: : If, however, the later mail is right and the earlier mail is wrong, this : *would* be easily explained: Many disks have optimization for the case of : linear writes and seeking slows them down a *lot*. Why? Because it's ve= ry : common to do linear writes, and it make sense to optimize the common case. Besides the linear optimization case, which would definitely slow down the seeking (second method), please do try to factor caching out of the equation, as several people suggested several times, by transferring much more data, like a couple of GB or at least twice as much as your physical memory, and post the results of that. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because "thit" is not a word. --3oCie2+XPXTnK5a5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyGTZ8ACgkQ7Ri2jRYZRVNKLwCfeSnMd8Ma/a3lFFCbVRgypT00 qQ0An2c7bjqz7dTKZ/gtWDTAb9NZl0fK =rcpX -----END PGP SIGNATURE----- --3oCie2+XPXTnK5a5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9:14:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 7281037B402 for ; Wed, 6 Mar 2002 09:14:51 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g26HETm03523; Wed, 6 Mar 2002 12:14:29 -0500 (EST) Date: Wed, 6 Mar 2002 12:12:44 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Peter Edwards Cc: "Brian T.Schellenberger" , Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <3C8648F5.1EC1E4EE@openet-telecom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Peter Edwards wrote: > Zhihui Zhang wrote: > > > > > ... I also do not read anything during the partial block write, > > and I think the disk controller should not do that either. > > If you do a partial block write, surely at some point the block must be read > in order to preserve that segment of data you are _not_ overwriting? First off, I am not writing through any file system. I access the raw device directly. Secondly, the bytes written are always a multiple of 512 bytes. If one sector is the I/O unit of a disk controller, why should it read anything to prevent overwritten? -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9:23:49 2002 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 2137137B405; Wed, 6 Mar 2002 09:23:39 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA26787; Wed, 6 Mar 2002 10:23:36 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g26HNZe34371; Wed, 6 Mar 2002 10:23:35 -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: <15494.20631.682803.383406@caddis.yogotech.com> Date: Wed, 6 Mar 2002 10:23:35 -0700 To: Raymond Wiker Cc: Giorgos Keramidas , Terry Lambert , "Steve B." , freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <15494.13878.219807.949085@raw.grenland.fast.no> References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <001701c1c481$d0d5eab0$f642d9cf@DROID> <20020305231252.GC5328@hades.hell.gr> <3C8568E0.76415D99@mindspring.com> <20020306032029.GA7926@hades.hell.gr> <15494.13878.219807.949085@raw.grenland.fast.no> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ Moving this thread over to -chat as well. We'll get them all over in time ] Raymond Wiker writes: > Giorgos Keramidas writes: > > Well, to be frank, I've seen a few C++ coding style documents, that suggest > > avoiding altogether when writing in C++. > > I assume you mean ? > Anyway, I *really* can't see any reason not to use , > , and friends. The fact that the programmer has no control over *how* the data is displayed, and relies on the person who wrote the class to display the data is one good reason. iostreams gives all the control the the person who writes the class, so in order to print things out, you have to extend the class (which often means peeking into it's private data, a violation of layering), or doing all sort of kludges/hacks to get things working. > I also cannot see any reason not to use exceptions, the standard > containers, the string classes etc. Because exceptions are *still* not portable across multiple platforms. There are N different implementations of exceptions, 'standard containers', and all behave slightly different. IMO, this is probably the biggest single stumbling block for using C++ extended features. Very few people know how to use these features correctly, and since they were so unportable, they are essentially unused except by those folks who worked very hard at using them, and as such have a higher clue-factor than most. > Used properly, these make it possible to write code that is > inherently safer than anything built around printf/scanf, char *, > longjump, etc. Without these (and a few others) you may just as well > stay with standard C. Safer? The intracacies of printf/scanf are *well* known, so I wouldn't say that it's any more/less safe. At least with the above functions, you *know* ahead of time the issues, vs. some random implementation of a class you don't want to look at. Exceptions are great, but there are too many gotchas because the behavior is not standardizes well enough to depend on them. (And, if you're not careful, you can cause yourself *all* sorts of problems using them.) > Then again, if you want to do object-oriented programming, C++ > is probably not the right choice. If you want to use several different > paradigms simulataneously in one language, C++ may be a better fit - > although Common Lisp is a much better choice :-) Except that it's *obnoxiously* hard to deploy it. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9:24:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id B13DC37B41D for ; Wed, 6 Mar 2002 09:24:00 -0800 (PST) Received: (qmail 33437 invoked by uid 1000); 6 Mar 2002 17:24:18 -0000 Date: Wed, 6 Mar 2002 19:24:18 +0200 From: Peter Pentchev To: Zhihui Zhang Cc: Peter Edwards , "Brian T.Schellenberger" , Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour Message-ID: <20020306192418.G14052@straylight.oblivion.bg> Mail-Followup-To: Zhihui Zhang , Peter Edwards , "Brian T.Schellenberger" , Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG References: <3C8648F5.1EC1E4EE@openet-telecom.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3xoW37o/FfUZJwQG" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zzhang@cs.binghamton.edu on Wed, Mar 06, 2002 at 12:12:44PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --3xoW37o/FfUZJwQG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2002 at 12:12:44PM -0500, Zhihui Zhang wrote: >=20 >=20 > On Wed, 6 Mar 2002, Peter Edwards wrote: >=20 > > Zhihui Zhang wrote: > >=20 > > > >=20 > > > ... I also do not read anything during the partial block write, > > > and I think the disk controller should not do that either. > >=20 > > If you do a partial block write, surely at some point the block must be= read > > in order to preserve that segment of data you are _not_ overwriting? >=20 > First off, I am not writing through any file system. I access the raw > device directly. Secondly, the bytes written are always a multiple of 512 > bytes. If one sector is the I/O unit of a disk controller, why should it > read anything to prevent overwritten? I think Peter was referring to the (more common IMHO) case when one sector was not quite the I/O unit of the disk controller, especially WRT caching. That is, the disk controller does not actually do a physical disk write for each and every sector, but only in larger blocks. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 =2Esiht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI --3xoW37o/FfUZJwQG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyGUMIACgkQ7Ri2jRYZRVMpvgCfetzSzLefMKrFMNMqWED630PU 2AIAn1dIfEazaUS8X57y3hd/R869gNTE =KZRh -----END PGP SIGNATURE----- --3xoW37o/FfUZJwQG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9:24:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.vaxxine.com (alpha.vaxxine.com [209.5.212.5]) by hub.freebsd.org (Postfix) with ESMTP id A56E137B421 for ; Wed, 6 Mar 2002 09:24:43 -0800 (PST) Received: from there (ppp172.digi-t3.st-cath.niagara.net [209.5.215.172]) by alpha.vaxxine.com (8.9.2/8.9.3) with SMTP id MAA15454 for ; Wed, 6 Mar 2002 12:24:42 -0500 (EST) Message-Id: <200203061724.MAA15454@alpha.vaxxine.com> Content-Type: text/plain; charset="iso-8859-1" From: "Paul C. Boyle" To: hackers@freebsd.org Subject: I need hack, I would like a clock like the xdaliclock but reads the time out in HEX. Date: Wed, 6 Mar 2002 12:25:48 -0500 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Does someone have this availale already. I am not a programer, but wish I could. There is a lot of neet things I would like to try. But I can't afford to take night classes as of this time If there is anyone out there that could mentor me in C or C++ ( I have minimal exposure to these.) I have looked a Python and found it a bit confusing not having to delare everything and aslo it has no unary opperator. Is there a Master Yoda sensing a disturbance in the force? Until then... So long, and thanks for all the fish! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9:26:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from damnhippie.dyndns.org (12-253-177-2.client.attbi.com [12.253.177.2]) by hub.freebsd.org (Postfix) with ESMTP id 200EE37B442 for ; Wed, 6 Mar 2002 09:26:02 -0800 (PST) Received: from [172.22.42.2] (peace.hippie.lan [172.22.42.2]) by damnhippie.dyndns.org (8.11.6/8.11.6) with ESMTP id g26HQ2804836; Wed, 6 Mar 2002 10:26:02 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Wed, 06 Mar 2002 10:26:04 -0700 Subject: Re: A weird disk behaviour From: Ian To: Cc: Zhihui Zhang Message-ID: In-Reply-To: <3C8648F5.1EC1E4EE@openet-telecom.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Zhihui Zhang wrote: > > > >> ... I also do not read anything during the partial block write, >> and I think the disk controller should not do that either. > > If you do a partial block write, surely at some point the block must be read > in order to preserve that segment of data you are _not_ overwriting? This was *exactly* my experience in FreeBSD 3.2, which was the last time I looked into this in detail. The performance of writing full blocks instead of partitial blocks was at least an order of magnitude better. (By "blocks" here I mean the size the filesystem was formatted with, the -b parameter to newfs.) I found that a filesystem formatted as -b8192 -f8192 performed so much faster than the usual -b8192 -f1024 that it was well worth taking the hit in wasted allocation space for small files. When I instrumented code in various places to try to track down why there was such a huge difference when fragsize != blocksize I found that the killer was repeated read-modify-write cycles, especially on filesystem metadata. Creating a file and writing a few bytes to it could result in dozens of blocks read then written, and some of the blocks got re-read several times in the process. It was always a mystery to me why the same sectors would get read over and over again (isn't that what buffer and filesystem caches are for?) But I know for certain the physical reads were happening because the instrumentation for that was in a custom raid driver of our own. But, FreeBSD 3.2 is ancient history now, I have no idea whether filesystem performance is still this bad (and surely softupdates would ameliorate this problem anyway). Also, this may not be relevant to Zhilhui Zang's situation because filesystem behavior is probably different than working directly with the /dev/daxxxx device. (Or maybe not, I guess there must be an implied blocksize from an incore disklabel or something.) It would be interesting to see if formatting a filesystem with blocksize == fragsize still makes a big difference in performance these days, but I remember all the instrumentation I had to do to prove the read-modify-write was happening last time being a BIG hassle, and nobody is paying me to do it anymore. :-) -- Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9:28:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 05B8937B4B5; Wed, 6 Mar 2002 09:27:34 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g26HRj059147; Wed, 6 Mar 2002 18:27:45 +0100 (CET) Date: Wed, 6 Mar 2002 18:29:11 +0100 (CET) From: Martin Blapp To: Daniel Eischen Cc: , , , Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: Message-ID: <20020306182829.D56721-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG and here is the output generated in /var/tmp -DSUPD=641 -DUPD=641 -I. -I.. -I../../../.. -I../../../../inc -I../../../../unxfbsd.pro/idl -I../../../../unxfbsd.pro/inc -I/usr/ports/editors/openoffice-work/work/oo_641c_src/solver/641/unxfbsd.pro/idl -I/usr/ports/editors/openoffice-work/work/oo_641c_src/solver/641/unxfbsd.pro/inc -O../../../../unxfbsd.pro/ucr/com/sun/star/lang ArrayIndexOutOfBoundsException.idl ClassNotFoundException.idl DisposedException.idl EventObject.idl IllegalAccessException.idl etc ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 9:53:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 6CFA137B402 for ; Wed, 6 Mar 2002 09:53:36 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g26HrYm03883; Wed, 6 Mar 2002 12:53:34 -0500 (EST) Date: Wed, 6 Mar 2002 12:51:48 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Ian Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Ian wrote: > > > > Zhihui Zhang wrote: > > > > > > > >> ... I also do not read anything during the partial block write, > >> and I think the disk controller should not do that either. > > > > If you do a partial block write, surely at some point the block must be read > > in order to preserve that segment of data you are _not_ overwriting? > > This was *exactly* my experience in FreeBSD 3.2, which was the last time I > looked into this in detail. The performance of writing full blocks instead > of partitial blocks was at least an order of magnitude better. (By "blocks" > here I mean the size the filesystem was formatted with, the -b parameter to > newfs.) I found that a filesystem formatted as -b8192 -f8192 performed so > much faster than the usual -b8192 -f1024 that it was well worth taking the > hit in wasted allocation space for small files. > > When I instrumented code in various places to try to track down why there > was such a huge difference when fragsize != blocksize I found that the > killer was repeated read-modify-write cycles, especially on filesystem > metadata. Creating a file and writing a few bytes to it could result in > dozens of blocks read then written, and some of the blocks got re-read > several times in the process. It was always a mystery to me why the same > sectors would get read over and over again (isn't that what buffer and > filesystem caches are for?) But I know for certain the physical reads were > happening because the instrumentation for that was in a custom raid driver > of our own. Could you tell me where is your custom raid driver? I mean, is it part of the operating system or inside the disk controller? > But, FreeBSD 3.2 is ancient history now, I have no idea whether filesystem > performance is still this bad (and surely softupdates would ameliorate this > problem anyway). Also, this may not be relevant to Zhilhui Zang's situation > because filesystem behavior is probably different than working directly with > the /dev/daxxxx device. (Or maybe not, I guess there must be an implied > blocksize from an incore disklabel or something.) I feel that the slowness of the file system is due to its sort of out-of-date on-disk structures. Many modern file systems are use B+tree nowadays. Softupdate helps a lot, but it can not solve the problem completely. > It would be interesting to see if formatting a filesystem with blocksize == > fragsize still makes a big difference in performance these days, but I > remember all the instrumentation I had to do to prove the read-modify-write > was happening last time being a BIG hassle, and nobody is paying me to do it > anymore. :-) > > > -- Ian > > > > 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 Mar 6 9:56:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 3B29B37B400 for ; Wed, 6 Mar 2002 09:56:50 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g26HuXm06314; Wed, 6 Mar 2002 12:56:33 -0500 (EST) Date: Wed, 6 Mar 2002 12:54:48 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Peter Pentchev Cc: Peter Edwards , "Brian T.Schellenberger" , Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: <20020306192418.G14052@straylight.oblivion.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Peter Pentchev wrote: > On Wed, Mar 06, 2002 at 12:12:44PM -0500, Zhihui Zhang wrote: > > > > > > On Wed, 6 Mar 2002, Peter Edwards wrote: > > > > > Zhihui Zhang wrote: > > > > > > > > > > > > > ... I also do not read anything during the partial block write, > > > > and I think the disk controller should not do that either. > > > > > > If you do a partial block write, surely at some point the block must be read > > > in order to preserve that segment of data you are _not_ overwriting? > > > > First off, I am not writing through any file system. I access the raw > > device directly. Secondly, the bytes written are always a multiple of 512 > > bytes. If one sector is the I/O unit of a disk controller, why should it > > read anything to prevent overwritten? > > I think Peter was referring to the (more common IMHO) case when one sector > was not quite the I/O unit of the disk controller, especially WRT caching. > That is, the disk controller does not actually do a physical disk write > for each and every sector, but only in larger blocks. This makes sense. So you are saying that the read-modify-write cycle actually happens within the disk controller? If so, I would love to know the unit of the disk controller I/O to avoid it! -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 10:10: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 4C73437B416; Wed, 6 Mar 2002 10:09:55 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g26IA5065156; Wed, 6 Mar 2002 19:10:05 +0100 (CET) Date: Wed, 6 Mar 2002 19:11:31 +0100 (CET) From: Martin Blapp To: Daniel Eischen Cc: , , , Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: Message-ID: <20020306191026.U56721-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi Daniel, > + pthread->join_status.thread = NULL; > + pthread->join_status.ret = NULL; > + pthread->join_status.error = 0; it still hangs :-( How should a detach routine in the client code look like ? Does the client have to catch a signal or something ? Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 10:13:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 1111D37B400; Wed, 6 Mar 2002 10:13:36 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g26ID8Y01371; Wed, 6 Mar 2002 10:13:08 -0800 (PST) (envelope-from obrien) Date: Wed, 6 Mar 2002 10:09:18 -0800 From: "David O'Brien" To: Poul-Henning Kamp Cc: Mike Meyer , Mike Meyer , Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020306100918.A1093@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <15493.61384.557931.883967@guru.mired.org> <30203.1015411062@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <30203.1015411062@critter.freebsd.dk>; from phk@critter.freebsd.dk on Wed, Mar 06, 2002 at 11:37:42AM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 11:37:42AM +0100, Poul-Henning Kamp wrote: > Ahh, but here you hit one of my pet-peeves. I hate assignments inside > conditionals. I prefer the above written as: It does not matter. Style(9) does not [intentionally] avoid PHK's pet peeves. It documents the style used by the CSRG with some modernizations. All this "IMO" does not matter as much as showing actual code examples from /sys. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 10:40:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 2C2F437B404 for ; Wed, 6 Mar 2002 10:40:00 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g26IdwOJ037134; Wed, 6 Mar 2002 13:39:58 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <15493.62234.943657.776598@guru.mired.org> References: <15493.61384.557931.883967@guru.mired.org> <30203.1015411062@critter.freebsd.dk> <15493.62234.943657.776598@guru.mired.org> Date: Wed, 6 Mar 2002 13:39:56 -0500 To: "Mike Meyer" , Poul-Henning Kamp From: Garance A Drosihn Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: >I don't think it is clarifying a rule. I think it is in fact adding >a rule. You are extrapolating too much I think. All the rule is >trying to prevent is "if (!strcmp(a,b))" which when read is extremely >wrong of that is actually happening. In a later message (not directly replying to the above), At 4:44 AM -0600 3/6/02, Mike Meyer wrote: >Looking at the text in the page on -stable, I think the one-word >change from boolean to "integer" would remove the ambiguity. If we change boolean to integer, then the proposed rule will not prevent "if (!strcmp(a,b))" , because strcmp() *does* return an integer value. Or am I missing something here? -- 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 Wed Mar 6 10:40:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 7B4BC37B419 for ; Wed, 6 Mar 2002 10:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020306184010.LUEM1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 6 Mar 2002 18:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA37336; Wed, 6 Mar 2002 10:39:17 -0800 (PST) Date: Wed, 6 Mar 2002 10:39:16 -0800 (PST) From: Julian Elischer To: David Xu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: please remove blank line In-Reply-To: <00e301c1c4c9$295966c0$ef01a8c0@davidwnt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The coding style guide for freebsd says that a blank line shalll be above the code and below teh variable declarations.. most peopple take this to read that the blank line still appears if there are no variables. I'm sorry if this offends your personal style, but a group has to have SME style guide and we all use this one when writing for FreeBSD even if we have our own syles for different code.. otherwise it would get unreadable. On Wed, 6 Mar 2002, David Xu wrote: > could anyone remove a blank line in /sys/kern/kern_sysctl.c ? > in FreeBSD 4.5 STABLE, it's at line 151, function sysctl_ctx_init(). > > -- > David Xu > > > > > > 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 Mar 6 10:49:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6515337B402; Wed, 6 Mar 2002 10:49:17 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g26InFWH013437; Wed, 6 Mar 2002 13:49:15 -0500 (EST) Date: Wed, 6 Mar 2002 13:49:15 -0500 (EST) From: Daniel Eischen To: Martin Blapp Cc: deischen@freebsd.org, rittle@labs.mot.com, alfred@freebsd.org, hackers@freebsd.org Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: <20020306191026.U56721-100000@levais.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Martin Blapp wrote: > hi Daniel, > > > + pthread->join_status.thread = NULL; > > + pthread->join_status.ret = NULL; > > + pthread->join_status.error = 0; > > it still hangs :-( Actually, the patch I gave you to uthread_detach was wrong. Here is the correct one (apply by hand if you have to). Index: uthread_detach.c =================================================================== RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_detach.c,v retrieving revision 1.16 diff -u -r1.16 uthread_detach.c --- uthread_detach.c 2001/05/20 23:08:32 1.16 +++ uthread_detach.c 2002/03/06 19:00:17 @@ -66,7 +66,9 @@ PTHREAD_NEW_STATE(joiner, PS_RUNNING); /* Set the return value for the woken thread: */ - joiner->error = ESRCH; + joiner->join_status.error = ESRCH; + joiner->join_status.ret = NULL; + joiner->join_status.thread = NULL; /* * Disconnect the joiner from the thread being detached: > > How should a detach routine in the client code look like ? Does the client have > to catch a signal or something ? No, there is no signal. BTW, if the code is expecting a signal to interrupt a join operation, it is wrong. A thread that is in a join can catch a signal, but if it returns from the signal handler normally (without longjmp'ing out of it) then it resumes the join operation. That is why there is a loop in uthread_join.c. It is to allow the thread to execute a signal handler and when it returns it will resume the join operation. Removing the loop breaks signal handling. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 10:50:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id A85C437B400 for ; Wed, 6 Mar 2002 10:50:11 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g26InqLv026425; Wed, 6 Mar 2002 19:49:56 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: "Mike Meyer" , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: Your message of "Wed, 06 Mar 2002 13:39:56 EST." Date: Wed, 06 Mar 2002 19:49:52 +0100 Message-ID: <26424.1015440592@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >In one message, > At 12:52 AM -0800 3/6/02, David O'Brien wrote: >>I don't think it is clarifying a rule. I think it is in fact adding >>a rule. You are extrapolating too much I think. All the rule is >>trying to prevent is "if (!strcmp(a,b))" which when read is extremely >>wrong of that is actually happening. > >In a later message (not directly replying to the above), > At 4:44 AM -0600 3/6/02, Mike Meyer wrote: >>Looking at the text in the page on -stable, I think the one-word >>change from boolean to "integer" would remove the ambiguity. > >If we change boolean to integer, then the proposed rule will not >prevent "if (!strcmp(a,b))" , because strcmp() *does* return an >integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? -- 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 Mar 6 11: 0:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 81AEC37B41A for ; Wed, 6 Mar 2002 11:00:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020306190017.IVZZ2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 6 Mar 2002 19:00:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA37417; Wed, 6 Mar 2002 10:54:33 -0800 (PST) Date: Wed, 6 Mar 2002 10:54:32 -0800 (PST) From: Julian Elischer To: Zhihui Zhang Cc: Peter Edwards , "Brian T.Schellenberger" , Lars Eggert , "Rogier R. Mulhuijzen" , freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG disks don't work in 512 byte blocks. they work inTRACKS these days.. if you ask for an entire track to be written, that is almost certainly quicker than if you ask for every 2ns block in that track to be written because the second option requires that it read the track first. ALso the seek may trigger code that asks the drive to start syncing to disk while it may hold off doing so if you do a sequential write. Just some ideas.. On Wed, 6 Mar 2002, Zhihui Zhang wrote: > > > On Wed, 6 Mar 2002, Peter Edwards wrote: > > > Zhihui Zhang wrote: > > > > > > > > > ... I also do not read anything during the partial block write, > > > and I think the disk controller should not do that either. > > > > If you do a partial block write, surely at some point the block must be read > > in order to preserve that segment of data you are _not_ overwriting? > > First off, I am not writing through any file system. I access the raw > device directly. Secondly, the bytes written are always a multiple of 512 > bytes. If one sector is the I/O unit of a disk controller, why should it > read anything to prevent overwritten? > > -Zhihui > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 11:13:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id E3FAF37B400; Wed, 6 Mar 2002 11:13:37 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g26JDm073406; Wed, 6 Mar 2002 20:13:48 +0100 (CET) Date: Wed, 6 Mar 2002 20:15:13 +0100 (CET) From: Martin Blapp To: Daniel Eischen Cc: , , , Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: Message-ID: <20020306201316.X56721-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks Daniel ! > + joiner->join_status.error = ESRCH; > + joiner->join_status.ret = NULL; > + joiner->join_status.thread = NULL; Oh wonder. It works no like a charm. :-)) Do you know in what case we can bump the osversion ? Is this one case we can do it so I could check the OSVERSION in the port ? Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 11:31:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EEA1F37B402; Wed, 6 Mar 2002 11:31:32 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g26JVWsG019284; Wed, 6 Mar 2002 14:31:32 -0500 (EST) Date: Wed, 6 Mar 2002 14:31:32 -0500 (EST) From: Daniel Eischen To: Martin Blapp Cc: deischen@freebsd.org, rittle@labs.mot.com, alfred@freebsd.org, hackers@freebsd.org Subject: Re: Sun idlc broken with our libc_r [Please help] In-Reply-To: <20020306201316.X56721-100000@levais.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Martin Blapp wrote: > > Thanks Daniel ! > > > + joiner->join_status.error = ESRCH; > > + joiner->join_status.ret = NULL; > > + joiner->join_status.thread = NULL; > > Oh wonder. It works no like a charm. :-)) OK, I just committed the fixes. > Do you know in what case we can bump the osversion ? Is this one case > we can do it so I could check the OSVERSION in the port ? I don't know enough about how and when OSVERSION is suppose to change to make that call. See if there is anything in the handbook about it. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 11:38:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 7E63837B402 for ; Wed, 6 Mar 2002 11:38:10 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g26JbkOJ108138; Wed, 6 Mar 2002 14:37:47 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <26424.1015440592@critter.freebsd.dk> References: <26424.1015440592@critter.freebsd.dk> Date: Wed, 6 Mar 2002 14:37:45 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Cc: "Mike Meyer" , hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: >Garance A Drosihn writes: > >In one message, >> At 12:52 AM -0800 3/6/02, David O'Brien wrote: >>>I don't think it is clarifying a rule. I think it is in fact adding >>>a rule. You are extrapolating too much I think. All the rule is >>>trying to prevent is "if (!strcmp(a,b))" which when read is extremely > >>wrong of that is actually happening. > > > >If we change boolean to integer, then the proposed rule will not >>prevent "if (!strcmp(a,b))" , because strcmp() *does* return an >>integer value. Or am I missing something here? > >Right, and since the integer is well defined, > if (!strcmp(a, b)) >is perfectly understandable so what is the problem ? Well, that's my question. David's comment implies that it is not good to do '!strcmp()', and I was wondering why it is not good... -- 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 Wed Mar 6 12: 9: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rylos.atmos.colostate.edu (rylos.atmos.colostate.edu [129.82.48.47]) by hub.freebsd.org (Postfix) with ESMTP id 118E937B404 for ; Wed, 6 Mar 2002 12:08:55 -0800 (PST) Received: from localhost (tarcieri@localhost) by rylos.atmos.colostate.edu (8.11.6/8.11.3) with ESMTP id g26K9kN49366 for ; Wed, 6 Mar 2002 13:09:46 -0700 (MST) (envelope-from tarcieri@atmos.colostate.edu) X-Authentication-Warning: rylos.atmos.colostate.edu: tarcieri owned process doing -bs Date: Wed, 6 Mar 2002 13:09:45 -0700 (MST) From: Tony Arcieri To: freebsd-hackers@freebsd.org Subject: Re: aio_read() oddness In-Reply-To: Message-ID: <20020306125926.Y49348-100000@rylos.atmos.colostate.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Note: Please cc replies to me as I'm not currently subscribed. Kip Macy wrote: > FreeBSD does not support queued signals (part of RT Posix) which is > required for this. > > -Kip I guess I'll have to take a look at kqueues then. On a similar note, I was wondering why FreeBSD declares the sigval union with the following members: int sigval_int; void *sigval_ptr; when other operating systems (namely Solaris and Irix) declare it with something like: int32_t sival_int; caddr32_t sival_ptr; The difference I'm refering to is the member names, sival versus sigval. (The above snippet is from Solaris's sys/siginfo.h) Is there some reason I don't know about for FreeBSD doing it differently? Tony Arcieri To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 12:12:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 4360B37B402 for ; Wed, 6 Mar 2002 12:12:17 -0800 (PST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g26KCA323500; Wed, 6 Mar 2002 12:12:11 -0800 (PST) Received: from orbit-fe.eng (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g26KC9A6012053; Wed, 6 Mar 2002 12:12:09 -0800 (PST) Received: from localhost (kmacy@localhost) by orbit-fe.eng (8.11.6+Sun/8.11.6) with ESMTP id g26KC8O05481; Wed, 6 Mar 2002 12:12:09 -0800 (PST) Date: Wed, 6 Mar 2002 12:12:08 -0800 (PST) From: Kip Macy To: Tony Arcieri Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: aio_read() oddness In-Reply-To: <20020306125926.Y49348-100000@rylos.atmos.colostate.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'd asked myself the same thing. In code that uses it I have to do an #ifdef FreeBSD. My guess was that it was because it is more conformant with the structure name and no one of consequence noticed because the underlying functionality is not really there. -Kip ========================================================================= For RAIDANT status see: http://cranford.eng.netapp.com:8080/cgi-bin/ant4/index.cgi To submit RAIDANT test descriptions go to: http://web.netapp.com/engineering/projects/raidv2/testing/ Ontap on the web: http://web.netapp.com/engineering/projects/raidv2/testing/global/ On Wed, 6 Mar 2002, Tony Arcieri wrote: > Note: Please cc replies to me as I'm not currently subscribed. > > Kip Macy wrote: > > > FreeBSD does not support queued signals (part of RT Posix) which is > > required for this. > > > > -Kip > > I guess I'll have to take a look at kqueues then. On a similar note, I > was wondering why FreeBSD declares the sigval union with the following > members: > > int sigval_int; > void *sigval_ptr; > > when other operating systems (namely Solaris and Irix) declare it with > something like: > > int32_t sival_int; > caddr32_t sival_ptr; > > The difference I'm refering to is the member names, sival versus sigval. > (The above snippet is from Solaris's sys/siginfo.h) > > Is there some reason I don't know about for FreeBSD doing it differently? > > Tony Arcieri > > > 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 Mar 6 12:14:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from damnhippie.dyndns.org (12-253-177-2.client.attbi.com [12.253.177.2]) by hub.freebsd.org (Postfix) with ESMTP id F1F1337B400 for ; Wed, 6 Mar 2002 12:14:47 -0800 (PST) Received: from [172.22.42.2] (peace.hippie.lan [172.22.42.2]) by damnhippie.dyndns.org (8.11.6/8.11.6) with ESMTP id g26KEk807148; Wed, 6 Mar 2002 13:14:46 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Wed, 06 Mar 2002 13:14:48 -0700 Subject: Re: A weird disk behaviour From: Ian To: Zhihui Zhang Cc: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >> >> When I instrumented code in various places to try to track down why there >> was such a huge difference when fragsize != blocksize I found that the >> killer was repeated read-modify-write cycles, especially on filesystem >> metadata. Creating a file and writing a few bytes to it could result in >> dozens of blocks read then written, and some of the blocks got re-read >> several times in the process. It was always a mystery to me why the same >> sectors would get read over and over again (isn't that what buffer and >> filesystem caches are for?) But I know for certain the physical reads were >> happening because the instrumentation for that was in a custom raid driver >> of our own. > > Could you tell me where is your custom raid driver? I mean, is it part of > the operating system or inside the disk controller? > It was custom hardware and software for an embedded system. We had a motherboard with 18 adaptec AIC 78xx chips on it, and our own software raid layer (modified freebsd kernel) that did special-purpose stuff (striping and error recovery using custom parity-generating hardware also on the mobo). I mentioned the raid driver only as a way of indicating that I was sure I was instrumenting real physical IO at the very lowest talk-to-the-drive layer, and I was seeing read-modify-write cycles at that layer that indicated the same sectors were being read over and over again (filesystem metadata sectors) during the higher-level operation of create-file, write 1 byte to file, close file. -- Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 13:15: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 19B2C37B416; Wed, 6 Mar 2002 13:15:02 -0800 (PST) Received: from attbi.com ([12.237.241.112]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020306211501.LBGH1214.rwcrmhc54.attbi.com@attbi.com>; Wed, 6 Mar 2002 21:15:01 +0000 Message-ID: <3C8686E6.F76B8B56@attbi.com> Date: Wed, 06 Mar 2002 15:15:18 -0600 From: Joe Halpin X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-hackers@freebsd.org, freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ References: <3C8529DA.FA8ABCE@mindspring.com> <20020305164151.T5854-100000@alpha.yumyumyum.org> <15493.24457.986109.726909@caddis.yogotech.com> <3C8573B2.35144B17@attbi.com> <200203051407.g25E7Cd67446@bugz.infotecs.ru> <001201c1c464$06416fd0$f642d9cf@DROID> <15493.49014.254461.125446@guru.mired.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Meyer wrote: > Joe Halpin types: > > 1. C++ is a more difficult language than C because it does more stuff > > than C. Ditto vs Java. > > No, it doesn't do more stuff than C, Neither does Java. See the > Church-Turing thesis. Java and C++ are harder to learn because they > have more *features* than C. Sorry, I thought "had more features" was something like "did more". For example, assembly language doesn't do anything Python can't, but Python does more (at least, per statement) than assembly language. I'm not sure I understand your point. Are you trying to say that all Turing complete languages are equally difficult? > > For years I have been seeing this assertion on the net over and over. I > > still don't see the expected result (ie, Java applications displacing > > C/C++ applications). > > I see it happening, then the products vanish because they can't > compete on a speed basis. VM's were a good idea when UCSD did it back > in the mid 70s. I think the hardware is fast enough to support it now, > but you've got to tie the parts together write. So are you agreeing with me? My experience is that most performance problems come about from the way something was coded, not the language it was coded in. Even in Java, you can do JNI functions if performance is really an issue. > Python is succeeding in some strange places, because it's trivial to > take a collection of subroutines that deal with a data structure they > pass back and forth as arguments, and turn it into a Python > object. Which means you get to play with those complex, compiled > environments in an interpreted environment that could be used as a > shell, if you were really crazy. Don't know anything about Python. How does this affect C vs C++? Or Java vs C++? or perfomance, or ... ? Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 13:54:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id DFF0637B400 for ; Wed, 6 Mar 2002 13:54:05 -0800 (PST) Received: (qmail 77298 invoked by uid 100); 6 Mar 2002 21:54:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.36857.673158.314313@guru.mired.org> Date: Wed, 6 Mar 2002 15:54:01 -0600 To: "Paul C. Boyle" Cc: freebsd-hackers@freebsd.org Subject: Re: I need hack, I would like a clock like the xdaliclock but reads the time out in HEX. In-Reply-To: <200203061700.MAA11066@alpha.vaxxine.com> References: <200203061700.MAA11066@alpha.vaxxine.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > minimal exposure to these.) I have looked a Python and found it a bit > confusing not having to delare everything and aslo it has no unary opperator. All languages have unary operators - at the very least negate, both loagical and arithmeatic. Most modern ones have a boolean negate as well. > Is there a Master Yoda sensing a disturbance in the force? Well, Python 2.0 has unary assignment operators if that's what you meant. Personally, I think python is the most readable thing I've found, and would gladly write you such a tool just to show off python, except I'm currently bedridden and can't get access ot a machine with an X server to test it on. If you still don't have one in two weeks, drop me a note about it, as I should be up and about by then. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 13:57:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by hub.freebsd.org (Postfix) with ESMTP id 9EC5E37B400 for ; Wed, 6 Mar 2002 13:57:14 -0800 (PST) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 56AF2A804; Thu, 7 Mar 2002 08:57:12 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 51FB85426; Thu, 7 Mar 2002 08:57:12 +1100 (EST) Date: Thu, 7 Mar 2002 08:57:12 +1100 (EST) From: Andrew To: Conrad Sabatier Cc: FreeBSD Hackers List Subject: Re: kqueue example code - suggestions? In-Reply-To: Message-ID: <20020307085517.W26785-100000@starbug.ugh.net.au> X-WonK: *wibble* MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Conrad Sabatier wrote: > Could anyone suggest a package I might look at to get an example of "real > world" kqueue() processing that would be not too difficult to digest? I'm > interested in converting an existing package from using poll() to kqueue(). misc/wait_on (not yet committed - ports/34414). Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 16:27:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-107-10.dsl.lsan03.pacbell.net [64.169.107.10]) by hub.freebsd.org (Postfix) with ESMTP id A147637B400; Wed, 6 Mar 2002 16:27:15 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 216F966C32; Wed, 6 Mar 2002 16:27:15 -0800 (PST) Date: Wed, 6 Mar 2002 16:27:14 -0800 From: Kris Kennaway To: Daniel Eischen Cc: Martin Blapp , deischen@freebsd.org, rittle@labs.mot.com, alfred@freebsd.org, hackers@freebsd.org Subject: Re: Sun idlc broken with our libc_r [Please help] Message-ID: <20020306162714.A3391@xor.obsecurity.org> References: <20020306201316.X56721-100000@levais.imp.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from eischen@pcnet1.pcnet.com on Wed, Mar 06, 2002 at 02:31:32PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2002 at 02:31:32PM -0500, Daniel Eischen wrote: > On Wed, 6 Mar 2002, Martin Blapp wrote: > >=20 > > Thanks Daniel ! > >=20 > > > + joiner->join_status.error =3D ESRCH; > > > + joiner->join_status.ret =3D NULL; > > > + joiner->join_status.thread =3D NULL; > >=20 > > Oh wonder. It works no like a charm. :-)) >=20 > OK, I just committed the fixes. >=20 > > Do you know in what case we can bump the osversion ? Is this one case > > we can do it so I could check the OSVERSION in the port ? >=20 > I don't know enough about how and when OSVERSION is suppose to change > to make that call. See if there is anything in the handbook about it. There's no harm in bumping OSVERSION frequently (but don't go overboard). If there's something out there which needs to differentiate between versions older and newer than a certain version of the OS, it's appropriate to bump OSVERSION. Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8hrPiWry0BWjoQKURAuLdAKDktvT2ZX8fRgYtNukY/0tzX/3aBgCgw2Cn sxauVl1DrY72EAaCMsi1g0M= =mPYk -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 16:50:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by hub.freebsd.org (Postfix) with ESMTP id 90E4637B416 for ; Wed, 6 Mar 2002 16:50:11 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 6 Mar 2002 19:50:05 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 3BB02BA03; Wed, 6 Mar 2002 19:50:04 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Zhihui Zhang Subject: Re: A weird disk behaviour Date: Wed, 6 Mar 2002 19:50:04 -0500 X-Mailer: KMail [version 1.3] Cc: Lars Eggert , "Rogier R. Mulhuijzen" , Julian Elischer , freebsd-hackers@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020307005004.3BB02BA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday 06 March 2002 11:43 am, Zhihui Zhang wrote: | In the case of partial block writes, I move to the next block which is | contiguous to the current block. So the start address of each write in | both cases are exactly the same. The only difference is that one write | full blocks, the other write partial blocks. I also do not read anything | during the partial block write, and I think the disk controller should not | do that either. I guess this was settled pretty well by later mail while I was off-line but, yes, that's exactly what I would suspect is happening. -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 17: 8:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 4FD5C37B400; Wed, 6 Mar 2002 17:08:14 -0800 (PST) Received: from pool0533.cvx21-bradley.dialup.earthlink.net ([209.179.194.23] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16imOD-00052s-00; Wed, 06 Mar 2002 17:08:13 -0800 Message-ID: <3C86BD6B.3ADCB4F0@mindspring.com> Date: Wed, 06 Mar 2002 17:07:55 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Cc: hackers@freebsd.org Subject: in_pcblookup_hash() called multiple times Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There are redundant calls to the in_pcblookup_hash() in the ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the ip_input path. Would it be useful to modify the (*pr_input) function pointer in the struct ipprotosw to take a fourth argument (perhaps it should be cast to a "void *" to keep it generalized?) to pass the pre-looked-up struct inpcb * to TCP, if the lookup has already been done? Profiling indicates that this is one of the most expensive calls in the code path, particularly when there are a lot of sockets open. Increasing the hash table size only works so far; at "a lot", the number of connections makes the lookup expensive anyway (it's a linear traversal of the collision chain for the bucket). Since there are reasons other than firewalling to do the lookup early, it seems that it would be useful to pass a pointer the a pointer that was non-NULL, if the lookup had already taken place. For example, moving the ipflow to use an overlay structure for the inpcb would mean that a single lookup was used for fast forwarding, firewalling, and inpcb identification for tcpcb retrieval for TCP. Note that I'm only talking about the packet input path here, at this time, so the firewall code isn't really generalizable (the inpcb is already known on output, except to the ip_fw code; it probably doesn't make sense to push knwledge of it into the ip_output path, at least without more thought). Right now, I'm just talking about a way ip_input could pass the already looked up input inpcb to tcp_input, udp_input, or udp_ctlinput -- all of which repeat the lookup operation. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 17:40:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 81C4437B416; Wed, 6 Mar 2002 17:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307014008.UBOB1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 01:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA38997; Wed, 6 Mar 2002 17:28:28 -0800 (PST) Date: Wed, 6 Mar 2002 17:28:27 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <3C86BD6B.3ADCB4F0@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG sounds good.. can you send us a patch to look at? On Wed, 6 Mar 2002, Terry Lambert wrote: > There are redundant calls to the in_pcblookup_hash() in the > ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the > ip_input path. > > Would it be useful to modify the (*pr_input) function pointer > in the struct ipprotosw to take a fourth argument (perhaps it > should be cast to a "void *" to keep it generalized?) to pass > the pre-looked-up struct inpcb * to TCP, if the lookup has > already been done? > > Profiling indicates that this is one of the most expensive > calls in the code path, particularly when there are a lot > of sockets open. Increasing the hash table size only works > so far; at "a lot", the number of connections makes the > lookup expensive anyway (it's a linear traversal of the > collision chain for the bucket). > > Since there are reasons other than firewalling to do the > lookup early, it seems that it would be useful to pass a > pointer the a pointer that was non-NULL, if the lookup had > already taken place. For example, moving the ipflow to > use an overlay structure for the inpcb would mean that a > single lookup was used for fast forwarding, firewalling, > and inpcb identification for tcpcb retrieval for TCP. > > Note that I'm only talking about the packet input path here, > at this time, so the firewall code isn't really generalizable > (the inpcb is already known on output, except to the ip_fw > code; it probably doesn't make sense to push knwledge of it > into the ip_output path, at least without more thought). > > Right now, I'm just talking about a way ip_input could pass > the already looked up input inpcb to tcp_input, udp_input, > or udp_ctlinput -- all of which repeat the lookup operation. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" 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 Mar 6 17:44:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from out016.verizon.net (out016pub.verizon.net [206.46.170.92]) by hub.freebsd.org (Postfix) with ESMTP id 4400C37B416 for ; Wed, 6 Mar 2002 17:44:07 -0800 (PST) Received: from bellatlantic.net ([138.89.156.175]) by out016.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020307014402.CHGB8955.out016.verizon.net@bellatlantic.net>; Wed, 6 Mar 2002 19:44:02 -0600 Message-ID: <3C86C5DC.6DCBB3E8@bellatlantic.net> Date: Wed, 06 Mar 2002 20:43:56 -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: Terry Lambert Cc: Kenneth Culver , "Steve B." , "Eugene L. Vorokov" , freebsd-hackers@FreeBSD.ORG Subject: Re: C vs C++ References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <3C8529DA.FA8ABCE@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Kenneth Culver wrote: > > Why are you being so sarcastic? Everyone here is assuming that it's harder > > to write C++ code, so you should only use it if necessary. It isn't > > necessary to use it for something like a daemon. > > Because that underlying assumption is false, and I'm making > fun of it. > > If you don't use C++ specific features, you're just writing > C code anyway. Not exactly. There are semantic differences even in the code looking just like C. > It's not harder to write C++ code that uses the special features > of the language; it may be harder for a programmer unfamiliar Yes, it is. To make things right with these features you need to write a few times more lines of code. This gives you a few times more opportunities to make mistakes and requires a few times more of testing. > There are a lot of benefits to the use of C++ that outweigh > the downside, particularly if you are a company paying for Sure, as long as your project grows big enough, the benefits start outweighing the troubles. > something, and you want to invest the value in the code base > instead of investing it in people who can walk out the door > and sign with your competition tomorrow. Makes no difference in this respect. You have the codebase anyway and you need people who understand it anyway too. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 18:27:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 625AD37B416 for ; Wed, 6 Mar 2002 18:27:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 54EA118AF for ; Wed, 6 Mar 2002 20:27:12 -0600 (CST) Received: from frosty.cs.rice.edu (frosty.cs.rice.edu [128.42.1.20]) by cs.rice.edu (Postfix) with ESMTP id 338F118B5 for ; Wed, 6 Mar 2002 20:27:06 -0600 (CST) Received: from localhost (hykim@localhost) by frosty.cs.rice.edu (8.9.3+Sun/8.9.0) with ESMTP id UAA11561 for ; Wed, 6 Mar 2002 20:26:54 -0600 (CST) X-Authentication-Warning: frosty.cs.rice.edu: hykim owned process doing -bs Date: Wed, 6 Mar 2002 20:26:54 -0600 (CST) From: Hyong-Youb Kim To: Subject: netgear GA622T problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have several machines with Netgear GA622T. They all run FreeBSD 4.5-REL and are connected via a Netgear gigabit switch. My problem is that the nge driver more often than not does not bring up the link. The cards are always detected but the link LED does not come up. I wonder if any one else has this problem. Thanks. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 19:13:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.22.195.2]) by hub.freebsd.org (Postfix) with ESMTP id 91FEA37B400 for ; Wed, 6 Mar 2002 19:13:42 -0800 (PST) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 16ioLd-0006fQ-00 (Debian); Thu, 07 Mar 2002 03:13:41 +0000 Date: Thu, 7 Mar 2002 03:13:41 +0000 From: Tony Finch To: freebsd-hackers@freebsd.org Subject: Re: A few questions about a few includes Message-ID: <20020307031341.C19669@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44henw2hqp.fsf@lowellg.ne.mediaone.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Lowell Gilbert wrote: > >C-99 requires a fully specified type before the unspecified array (and >requires said array to be the last element in the structure). So this >example is *not* valid in C99, but the following would be: > >struct foo { > int bar; > char array[]; >}; > >[Which makes sense; it forces a structure to have a non-zero size.] Although there has been some discussion in the committee about allowing zero-sized objects in C, the standard doesn't allow them. This is perhaps why it doesn't follow gcc's [0] syntax for variable length arrays at the end of structures. Tony. -- f.a.n.finch THAMES DOVER WIGHT PORTLAND PLYMOUTH: WEST OR SOUTHWEST 5 TO 7 DECREASING 4. DRIZZLE DYING OUT. MODERATE, OCCASIONALLY POOR, BECOMING GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 19:21:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 3AB9F37B400 for ; Wed, 6 Mar 2002 19:21:46 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g273LDn55342; Wed, 6 Mar 2002 19:21:13 -0800 (PST) (envelope-from obrien) Date: Wed, 6 Mar 2002 19:17:09 -0800 From: "David O'Brien" To: D J Hawkey Jr Cc: bts@babbleon.org, freebsd-hackers@freebsd.org Subject: Re: C vs C++ Message-ID: <20020306191709.A55297@dragon.nuxi.com> Reply-To: freebsd-hackers@freebsd.org References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203061219.g26CJEJ61813@sheol.localdomain>; from hawkeyd@visi.com on Wed, Mar 06, 2002 at 06:19:14AM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: > > They should have left well enough alone, and advocated languages that > were/are OOPL by concept as well as design. *sigh* IF you say that then you really aren't thinking at at all. Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T C. Got it? No one is willing to learn a new language. How much bitching do we get because CVSup is written in Modula-3? It is a type-safer language than C. It has some OO-like constructs and its threading model and GUI lib allow JDP to quickly create a really nice application. But all the benefits of Modula-3 are lost on the "I only do C" crowd that is demanding CVSup be rewritten. Thus to repeat -- C++ was built on C SO IT WOULD BE ACCEPTED. > I'll go away now. thank you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 19:27: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 35FB137B41E for ; Wed, 6 Mar 2002 19:26:54 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g273QbM55388; Wed, 6 Mar 2002 19:26:37 -0800 (PST) (envelope-from obrien) Date: Wed, 6 Mar 2002 19:22:34 -0800 From: "David O'Brien" To: Garance A Drosihn Cc: Poul-Henning Kamp , Mike Meyer , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020306192234.B55297@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <26424.1015440592@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Wed, Mar 06, 2002 at 02:37:45PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 02:37:45PM -0500, Garance A Drosihn wrote: > At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: > >Garance A Drosihn writes: > > >In one message, > >> At 12:52 AM -0800 3/6/02, David O'Brien wrote: > >>>I don't think it is clarifying a rule. I think it is in fact adding > >>>a rule. You are extrapolating too much I think. All the rule is > >>>trying to prevent is "if (!strcmp(a,b))" which when read is extremely > > >>wrong of that is actually happening. > > > > > >If we change boolean to integer, then the proposed rule will not > >>prevent "if (!strcmp(a,b))" , because strcmp() *does* return an > >>integer value. Or am I missing something here? > > > >Right, and since the integer is well defined, > > if (!strcmp(a, b)) > >is perfectly understandable so what is the problem ? > > Well, that's my question. David's comment implies that it is not > good to do '!strcmp()', and I was wondering why it is not good... Implies??? I thought I was quite explicit: to prevent is "if (!strcmp(a,b))" which when read is extremely wrong of that is actually happening. ! is pronounced "NOT". When read "if not string compare a with b then do X", is the opposite of the the logic of the expression does. Which is "if string compare a with b is equal then do X". ["if (strcmp(a,b) == 0)"] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 19:28: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mtbaker.tfm.com (mtbaker.tfm.com [192.231.224.2]) by hub.freebsd.org (Postfix) with ESMTP id 182BD37B400 for ; Wed, 6 Mar 2002 19:27:59 -0800 (PST) Received: (from db@localhost) by mtbaker.tfm.com (8.11.1/8.11.1) id g273Rs706065; Wed, 6 Mar 2002 19:27:54 -0800 (PST) From: Diane Bruce Message-Id: <200203070327.g273Rs706065@mtbaker.tfm.com> Subject: Re: C vs C++ In-Reply-To: <20020306191709.A55297@dragon.nuxi.com> "from David O'Brien at Mar 6, 2002 07:17:09 pm" To: freebsd-hackers@FreeBSD.ORG Date: Wed, 6 Mar 2002 19:27:54 -0800 (PST) Cc: D J Hawkey Jr , bts@babbleon.org X-Mailer: ELM [version 2.4ME+ PL78 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien says: > On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: ... >> application. But all the benefits of Modula-3 are lost on the "I only do > C" crowd that is demanding CVSup be rewritten. "If all you have is a hammer... everything looks like a nail." -- Diane Bruce, http://www.db.net/~db db@db.net --- I got bored with the last witty aphorism. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 19:38:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 43A2637B405 for ; Wed, 6 Mar 2002 19:38:54 -0800 (PST) Received: (qmail 81271 invoked by uid 100); 7 Mar 2002 03:38:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.57538.888210.658115@guru.mired.org> Date: Wed, 6 Mar 2002 21:38:42 -0600 To: freebsd-hackers@freebsd.org Cc: D J Hawkey Jr , bts@babbleon.org Subject: Re: C vs C++ In-Reply-To: <20020306191709.A55297@dragon.nuxi.com> References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien types: > On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: > > They should have left well enough alone, and advocated languages that > > were/are OOPL by concept as well as design. > *sigh* IF you say that then you really aren't thinking at at all. > Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T > C. Got it? No one is willing to learn a new language. Then they aren't hackers. I'm certainly willing to learn new language. I generally relish the opportunity. The trick is finding employers who are willing to let me do that, or tasks I want to do that the language in question is the proper tool. > Thus to repeat -- C++ was built on C SO IT WOULD BE ACCEPTED. That is true. C++ is as ugly as C, but has all the problems of Object Orient Languages. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 19:53:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from breg.mc.mpls.visi.com (breg.mc.mpls.visi.com [208.42.156.101]) by hub.freebsd.org (Postfix) with ESMTP id 23BF537B402 for ; Wed, 6 Mar 2002 19:53:07 -0800 (PST) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by breg.mc.mpls.visi.com (Postfix) with ESMTP id 118E62D0491; Wed, 6 Mar 2002 21:53:06 -0600 (CST) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.6/8.11.6) id g273r5Y64145; Wed, 6 Mar 2002 21:53:05 -0600 (CST) (envelope-from hawkeyd) Date: Wed, 6 Mar 2002 21:53:05 -0600 From: D J Hawkey Jr To: "David O'Brien" Cc: bts@babbleon.org, Diane Bruce , Mike Meyer , freebsd-hackers@freebsd.org Subject: Re: C vs C++ Message-ID: <20020306215305.A64016@sheol.localdomain> Reply-To: hawkeyd@visi.com References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020306191709.A55297@dragon.nuxi.com>; from devnull@NUXI.com on Wed, Mar 06, 2002 at 07:17:09PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mar 06, at 07:17 PM, David O'Brien wrote: > > On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: > > > > They should have left well enough alone, and advocated languages that > > were/are OOPL by concept as well as design. > > *sigh* IF you say that then you really aren't thinking at at all. > Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T > C. Got it? No one is willing to learn a new language. How much > bitching do we get because CVSup is written in Modula-3? It is a > type-safer language than C. It has some OO-like constructs and its > threading model and GUI lib allow JDP to quickly create a really nice > application. But all the benefits of Modula-3 are lost on the "I only do > C" crowd that is demanding CVSup be rewritten. First, you're ascribing me to a group I don't belong. While I don't know Eiffel, or Lisp, or Modula, Snobol, etc., I don't demean them, nor do I bitch about such-and-such being written with them (well, not publicly, anyway). Many's the time I've wanted to modify a program written in a language I didn't/don't know, and learned enough of it to re-write it in a language I do know, just to do the changes I wanted. Second, you're not addressing my comments at all. I maintain that the creators of C++ should have either created yet another OOPL, or advocated any of the existing ones. Taking a procedural language, particularly one as accepted and popular as C, and wreaking havoc on it (IMHO) to produce another, was a gross mis-step. > Thus to repeat -- C++ was built on C SO IT WOULD BE ACCEPTED. By whom? C programmers? If you're even half-right, their logic was flawed - the general concensus that I'm aware of is that most C folk think little of C++. I won't address the opinions of PHBs who didn't get much further than flow-charts, or the C++ folk who hadn't experience with C when they learned C++, if either of those groups are the people you're writing of. > > I'll go away now. > > thank you. Snideness doesn't get you anything but. Dave Don't mess with me, I'm not a zealot. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 19:56:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from breg.mc.mpls.visi.com (breg.mc.mpls.visi.com [208.42.156.101]) by hub.freebsd.org (Postfix) with ESMTP id DCA6337B402 for ; Wed, 6 Mar 2002 19:56:47 -0800 (PST) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by breg.mc.mpls.visi.com (Postfix) with ESMTP id 318262D0491 for ; Wed, 6 Mar 2002 21:56:47 -0600 (CST) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.6/8.11.6) id g273ukR64176; Wed, 6 Mar 2002 21:56:46 -0600 (CST) (envelope-from hawkeyd) Date: Wed, 6 Mar 2002 21:56:46 -0600 (CST) Message-Id: <200203070356.g273ukR64176@sheol.localdomain> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: hawkeyd@visi.com Organization: if (!FIFO) if (!LIFO) break; References: <200203061219.g26CJEJ61813_sheol.localdomain@ns.sol.net> <20020306191709.A55297_dragon.nuxi.com@ns.sol.net> In-Reply-To: <20020306191709.A55297_dragon.nuxi.com@ns.sol.net> From: hawkeyd@visi.com (D J Hawkey Jr) Subject: Re: C vs C++ X-Original-Newsgroups: sol.lists.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hey, devnull, if you're gonna perticipate, the least you could do is present a mailing address that accepts mail. *sheesh* Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 20:14:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.22.195.2]) by hub.freebsd.org (Postfix) with ESMTP id 9ACD437B400; Wed, 6 Mar 2002 20:14:16 -0800 (PST) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 16ipI9-0007zC-00 (Debian); Thu, 07 Mar 2002 04:14:09 +0000 Date: Thu, 7 Mar 2002 04:14:09 +0000 From: Tony Finch To: Poul-Henning Kamp Cc: Mike Meyer , obrien@FreeBSD.ORG, Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020307041409.B29816@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <88752.1015400044@critter.freebsd.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > >I had a discussion with Eric Allman about this very thing recently >where he advocated "everything inside if, while, for and so on should >be true booleans". > >Now, IFF the C language had a type called "boolean" that would make >a lot of sense. > >Unfortunately, it does not (at present ?) have a boolean type, and >while one could simulate it with typedefs, there is no way to get >the compiler to enforce the rule. C99 has a boolean type, but neither the comparison operators nor the logical operators nor the ! operator return a bool, and conditional contexts (like if, while, ?:) don't expect a bool. Pretty useless, really. Tony. -- f.a.n.finch ROCKALL: WEST BACKING SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 AT FIRST, DECREASING 5 FOR A TIME. OCCASIONAL RAIN. MODERATE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 20:17:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 09D4D37B416 for ; Wed, 6 Mar 2002 20:17:28 -0800 (PST) Received: from pool0003.cvx22-bradley.dialup.earthlink.net ([209.179.198.3] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16ipKn-00022s-00; Wed, 06 Mar 2002 20:16:53 -0800 Message-ID: <3C86E99E.DA1C68AD@mindspring.com> Date: Wed, 06 Mar 2002 20:16:30 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hawkeyd@visi.com Cc: David O'Brien , bts@babbleon.org, Diane Bruce , Mike Meyer , freebsd-hackers@freebsd.org Subject: Re: C vs C++ References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> <20020306215305.A64016@sheol.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG D J Hawkey Jr wrote: > Second, you're not addressing my comments at all. I maintain that the > creators of C++ should have either created yet another OOPL, or advocated > any of the existing ones. Taking a procedural language, particularly one > as accepted and popular as C, and wreaking havoc on it (IMHO) to produce > another, was a gross mis-step. I guess I won't wax nostalgic about the merits of RATFOR... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 20:23:30 2002 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 5696137B405 for ; Wed, 6 Mar 2002 20:23:27 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g2748tD34247; Wed, 6 Mar 2002 23:08:55 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 6 Mar 2002 23:08:55 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rajesh P Jain Cc: freebsd-hackers@freebsd.org Subject: Re: BPF - Locally Generated Packet Reception In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It could be that this fails for interfaces that perform hardware loopback, since it relies on the behavior of software loop. There may also be some other circumstances where this occurs. Basically, the BPF device can tell it's "locally sourced" because it has a NULL interface pointer associated with it. If the packet ends up with a none-NULL interface pointer for some reason, it will be considered a non-locally sourced packet. In practice, we've used this successfully on a variety of ethernet devices -- which interface type are you using? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Wed, 6 Mar 2002, Rajesh P Jain wrote: > Hi, > In the BPF - Berkeley Packet Filter, when a file descriptor is associated to an interface to send and receive packets, there is an ioctl parameter "BIOCSSEESENT", which is by default set to 1. Hence the packets both from "remote systems" and "locally generated" are received. > > If "locally generated" packets needs to be filtered, we can use the option "BIOCSSEESENT" and set the value to 0. > > But even after setting this value to 0 (using the ioctl call), the "locally generated" packets are received. > > Am I missing something ? Plese throw light on this issue. > > TIA > Raj > > > Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com > > 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 Mar 6 20:29:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.22.195.2]) by hub.freebsd.org (Postfix) with ESMTP id E4B5E37B404 for ; Wed, 6 Mar 2002 20:29:21 -0800 (PST) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 16ipWl-0008JO-00 (Debian); Thu, 07 Mar 2002 04:29:15 +0000 Date: Thu, 7 Mar 2002 04:29:15 +0000 From: Tony Finch To: Poul-Henning Kamp Cc: Garance A Drosihn , Mike Meyer , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020307042915.D29816@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <26424.1015440592@critter.freebsd.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > >Right, and since the integer is well defined, > if (!strcmp(a, b)) >is perfectly understandable so what is the problem ? If that is ok, then why is p = malloc(sizeof(*p)); if (!p) return ENOMEM; not ok, given that is even more well-defined? I am of the opinion that expressions in a conditional context (i.e. argument of ! && || ?: if while) should be boolean-valued (i.e. either 0 or 1 corresponding to false or true). If they aren't then an appropriate comparison should be done. Tony. -- f.a.n.finch FAEROES SOUTHEAST ICELAND: EASTERLY, BECOMING CYCLONIC THEN WESTERLY, 4 OR 5. SNOW OR SNOW SHOWERS. GOOD OCCASIONALLY POOR. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 20:34:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dns.pacang.com (adsl-63-193-245-242.dsl.snfc21.pacbell.net [63.193.245.242]) by hub.freebsd.org (Postfix) with ESMTP id 8A09337B400 for ; Wed, 6 Mar 2002 20:34:42 -0800 (PST) Received: (from bservies@localhost) by dns.pacang.com (8.9.3/8.9.2) id UAA16736; Wed, 6 Mar 2002 20:34:34 -0800 Date: Wed, 6 Mar 2002 20:34:34 -0800 From: Byron Servies To: freebsd-hackers@FreeBSD.ORG Cc: D J Hawkey Jr , bts@babbleon.org Subject: Re: C vs C++ Message-ID: <20020306203433.F15417@pacang.com> References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020306191709.A55297@dragon.nuxi.com>; from devnull@NUXI.com on Wed, Mar 06, 2002 at 07:17:09PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On March 06, 2002 at 19:17, David O'Brien wrote: > > *sigh* IF you say that then you really aren't thinking at at all. > Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T > C. Got it? No one is willing to learn a new language. How much > bitching do we get because CVSup is written in Modula-3? It is a My only problem with modula-3 was the lack of compiler support on "alternative" platforms. I couldn't figure out how to port the one I found (well, I figured it out: it was a _huge_ amount of work). Now, Oberon, there's a language! Byron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 20:37:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.vaxxine.com (alpha.vaxxine.com [209.5.212.5]) by hub.freebsd.org (Postfix) with ESMTP id 2217037B402 for ; Wed, 6 Mar 2002 20:37:14 -0800 (PST) Received: from there (ppp206.digi-t3.st-cath.niagara.net [209.5.215.206]) by alpha.vaxxine.com (8.9.2/8.9.3) with SMTP id XAA13463; Wed, 6 Mar 2002 23:37:00 -0500 (EST) Message-Id: <200203070437.XAA13463@alpha.vaxxine.com> Content-Type: text/plain; charset="iso-8859-1" From: "Paul C. Boyle" To: "Mike Meyer" Subject: Re: I need hack, I would like a clock like the xdaliclock but reads the time out in HE Date: Wed, 6 Mar 2002 23:38:07 -0500 X-Mailer: KMail [version 1.3] References: <200203061700.MAA11066@alpha.vaxxine.com> <15494.36857.673158.314313@guru.mired.org> In-Reply-To: <15494.36857.673158.314313@guru.mired.org> Cc: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thank you for the kind reply Mike. I have been shown the elitist attude by others at times, and man I tell you its can bring a buy down. On March 6, 2002 04:54 pm, you wrote: > > minimal exposure to these.) I have looked a Python and found it a bit > > confusing not having to delare everything and aslo it has no unary > > opperator. > > All languages have unary operators - at the very least negate, both > loagical and arithmeatic. Most modern ones have a boolean negate as > well. My comment was't meant to knock Python. I have read about Python and very much like what I have read. Just to tell you where I am coming from. I have taken a ten week night class in C++ 2 years ago. This was my first experience with programming. This just gave me the basics like , looping, functions, arrays, pointers as such. Since coming to Freebsd unix I found the majority of things is done in C. So I picked up the book Teach yourself C in 21 Days. Things are different here but they do make sense. Now looking at Python books things are a lot differently done. like how do you do a for loop as you would in C or C++. for ( x=0: x < 10 ; x ++ ) Is the ++ not the unary operator? What is the same thing in Python? Maybe Sams will put out a Teach Yourself Python in 21 Days. I'd like to learn Perl as well but good books for newbies are hard to find. > > > Is there a Master Yoda sensing a disturbance in the force? > > Well, Python 2.0 has unary assignment operators if that's what you > meant. Personally, I think python is the most readable thing I've > found, and would gladly write you such a tool just to show off python, > except I'm currently bedridden and can't get access ot a machine with > an X server to test it on. If you still don't have one in two weeks, > drop me a note about it, as I should be up and about by then. I would appriciate that so much. I would really like to learn a language that I could use to make things when I want. Like a clock that reads out in HEX. My day job, I drive transport truck. I could see writing a program for the palm pilot for other truck drivers to do their daily log book calculations. I will pray that you gett better real soon Mike. Take care. Paul... > > ; Wed, 6 Mar 2002 21:39:59 -0800 (PST) Received: (qmail 82806 invoked by uid 100); 7 Mar 2002 05:39:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.64812.598093.56688@guru.mired.org> Date: Wed, 6 Mar 2002 23:39:56 -0600 To: hawkeyd@visi.com Cc: "David O'Brien" , bts@babbleon.org, Diane Bruce , Mike Meyer , freebsd-hackers@freebsd.org Subject: Re: C vs C++ In-Reply-To: <20020306215305.A64016@sheol.localdomain> References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> <20020306215305.A64016@sheol.localdomain> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG D J Hawkey Jr types: > First, you're ascribing me to a group I don't belong. While I don't know > Eiffel, or Lisp, or Modula, Snobol, etc., I don't demean them, nor do I > bitch about such-and-such being written with them (well, not publicly, > anyway). Many's the time I've wanted to modify a program written in a > language I didn't/don't know, and learned enough of it to re-write it in > a language I do know, just to do the changes I wanted. Ack! That makes believe the comments about people not wanting to learn new languages. I would do it the other way around, and learn enough of the language it's written in to make the changes I wanted. In fact, I think that's a good way to learn a language, providing you have a stylisticly good example to start with. I'll leave the conclusions to be drawn about Linux from that to someone else. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 21:48:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.junkproof.net (mail.junkproof.net [206.55.70.12]) by hub.freebsd.org (Postfix) with ESMTP id 4070037B41A for ; Wed, 6 Mar 2002 21:48:25 -0800 (PST) Received: from mail (helo=mail.junkproof.net) by mail.junkproof.net with local-bsmtp (Exim 3.32 #1) id 16iqlH-000Ozx-00 for freebsd-hackers@freebsd.org; Wed, 06 Mar 2002 23:48:19 -0600 X-Filter-Status: mail.junkproof.net ok 656 Received: from bill.twwells.com ( [68.44.48.161] ) by mail.junkproof.net via tcp with submission id 3c86fc93-01767e; Wed, 6 Mar 2002 23:37:23 -0600 Received: from bill by bill.twwells.com with local (Exim 3.34 #1) id 16iqag-0002DA-00 for freebsd-hackers@freebsd.org; Thu, 07 Mar 2002 00:37:22 -0500 From: admin@twwells.com Subject: Re: RFC: style(9) isn't explicit about booleans for testing. References: <200203061659.g26GxI979195@thistle.bogs.org> To: freebsd-hackers@freebsd.org Message-Id: Date: Thu, 07 Mar 2002 00:37:22 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Try this text instead: In C, there is no boolean type but there are boolean concepts, contexts that express or test yes/no, good/bad, error/success, pointer initialized/not initialized, object created/not created, and so on. Where a conceptually boolean operand is expected and you have a value that is not conceptually boolean, use an operator (e.g., ==, !=) that translates the operand to something that is conceptually boolean. This applies to "if" expressions, the operand of !, function parameters that want a conceptually boolean value, and so on. This is actually a special case of a more general rule, which might be stated: saving a few keystrokes but violating the expectations of strangers reading your code is not a good way to write maintainable code. Ensure that the code and your intention are congruent *in the mind of your readers*. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 21:59:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 87F5137B41A; Wed, 6 Mar 2002 21:59:30 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g275x8Lv052205; Thu, 7 Mar 2002 06:59:09 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: obrien@FreeBSD.ORG Cc: Garance A Drosihn , Mike Meyer , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: Your message of "Wed, 06 Mar 2002 19:22:34 PST." <20020306192234.B55297@dragon.nuxi.com> Date: Thu, 07 Mar 2002 06:59:08 +0100 Message-ID: <52204.1015480748@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020306192234.B55297@dragon.nuxi.com>, "David O'Brien" writes: >Implies??? I thought I was quite explicit: > > to prevent is "if (!strcmp(a,b))" which when read is extremely wrong of > that is actually happening. > >! is pronounced "NOT". When read "if not string compare a with b then do X", >is the opposite of the the logic of the expression does. Which is >"if string compare a with b is equal then do X". ["if (strcmp(a,b) == 0)"] Well, we're clearly into "IMO" land here, so lets ignore 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 Mar 6 22: 1:18 2002 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 2397C37B400 for ; Wed, 6 Mar 2002 22:01:13 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g2761Bi89673; Wed, 6 Mar 2002 23:01:12 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g27616L90575; Wed, 6 Mar 2002 23:01:06 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 06 Mar 2002 23:00:59 -0700 (MST) Message-Id: <20020306.230059.128109706.imp@village.org> To: drosih@rpi.edu Cc: phk@critter.freebsd.dk, mwm-dated-1015843484.1eabc5@mired.org, hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. From: "M. Warner Losh" In-Reply-To: References: <26424.1015440592@critter.freebsd.dk> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Garance A Drosihn writes: : At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: : >Garance A Drosihn writes: : > >In one message, : >> At 12:52 AM -0800 3/6/02, David O'Brien wrote: : >>>I don't think it is clarifying a rule. I think it is in fact adding : >>>a rule. You are extrapolating too much I think. All the rule is : >>>trying to prevent is "if (!strcmp(a,b))" which when read is extremely : > >>wrong of that is actually happening. : > > : > >If we change boolean to integer, then the proposed rule will not : >>prevent "if (!strcmp(a,b))" , because strcmp() *does* return an : >>integer value. Or am I missing something here? : > : >Right, and since the integer is well defined, : > if (!strcmp(a, b)) : >is perfectly understandable so what is the problem ? : : Well, that's my question. David's comment implies that it is not : good to do '!strcmp()', and I was wondering why it is not good... if (strcmp()) is the problem with if (!strcmp()) Which one is right? The first one should mean "are the same" but really means "are different" and likewise for the second one. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 22:15: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8372D37B402 for ; Wed, 6 Mar 2002 22:15:06 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g276EnLv055381; Thu, 7 Mar 2002 07:14:50 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" Cc: drosih@rpi.edu, mwm-dated-1015843484.1eabc5@mired.org, hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. In-Reply-To: Your message of "Wed, 06 Mar 2002 23:00:59 MST." <20020306.230059.128109706.imp@village.org> Date: Thu, 07 Mar 2002 07:14:49 +0100 Message-ID: <55380.1015481689@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020306.230059.128109706.imp@village.org>, "M. Warner Losh" writes : >: Well, that's my question. David's comment implies that it is not >: good to do '!strcmp()', and I was wondering why it is not good... > > if (strcmp()) > >is the problem with > > if (!strcmp()) > >Which one is right? The first one should mean "are the same" but >really means "are different" and likewise for the second one. Guys, strcmp() has been defined that way for almost 30 years, get used to it, and don't demand obfuscation of every other if() in the kernel to try to hide the fact... -- 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 Mar 6 22:43:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by hub.freebsd.org (Postfix) with ESMTP id 01A9537B428 for ; Wed, 6 Mar 2002 22:43:23 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 7 Mar 2002 01:43:15 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 799C2BA03; Thu, 7 Mar 2002 01:43:06 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: "Paul C. Boyle" , "Mike Meyer" Subject: Re: I need hack, I would like a clock like the xdaliclock but reads the time out in HE Date: Thu, 7 Mar 2002 01:43:05 -0500 X-Mailer: KMail [version 1.3] Cc: freebsd-hackers@FreeBSD.ORG References: <200203061700.MAA11066@alpha.vaxxine.com> <15494.36857.673158.314313@guru.mired.org> <200203070437.XAA13463@alpha.vaxxine.com> In-Reply-To: <200203070437.XAA13463@alpha.vaxxine.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020307064306.799C2BA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday 06 March 2002 11:38 pm, Paul C. Boyle wrote: | Thank you for the kind reply Mike. | I have been shown the elitist attude by others at times, | and man I tell you its can bring a buy down. | | On March 6, 2002 04:54 pm, you wrote: | > > minimal exposure to these.) I have looked a Python and found it a bit | > > confusing not having to delare everything and aslo it has no unary | > > opperator. | > | > All languages have unary operators - at the very least negate, both | > loagical and arithmeatic. Most modern ones have a boolean negate as | > well. | | My comment was't meant to knock Python. I have read about Python and | very much like what I have read. | Just to tell you where I am coming from. I have taken a ten week night | class in C++ 2 years ago. This was my first experience with programming. | This just gave me the basics like , looping, functions, arrays, pointers as | such. Since coming to Freebsd unix I found the majority of things is done | in C. So I picked up the book Teach yourself C in 21 Days. Things are | different here but they do make sense. | Now looking at Python books things are a lot differently done. | like how do you do a for loop as you would in C or C++. | | for ( x=0: x < 10 ; x ++ ) | | Is the ++ not the unary operator? No, ++ is *a* unary operator, not *the* unary operator. -- is another. - is another. ! is another. ~ is another. There are a bunch: a unary operator is any operator that takes a single operand, just as a binary operator is an operator that takes two operaands. And a ternary operator is an operator that takes three operands. (There is "a" ternary operator, though; of commonly-used languages, C is unique in having a ternary operator, and it only has one of them: the ? : operator.) Python doesn't have pre- and post- inrement- and decrment? Well, neither do most languages--they are pretty much a quirky C construct created, I suspect because they correlated to PDP-11 machine instructions (addressing modes), which has since infiltrated a number of other languages. But the lack of same is hardly a big deal. It'll cost you just a few keystrokes. OTOH, I do rather like x += 1 -- I think it clarifies what's going on as compared to x = x + 1 . . . . -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 22:47: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by hub.freebsd.org (Postfix) with ESMTP id 3C9D637B405; Wed, 6 Mar 2002 22:47:01 -0800 (PST) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.11.6/8.11.6) with ESMTP id g276kxU28111; Thu, 7 Mar 2002 01:47:00 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38886) id <0GSL00D01C6BLE@lmco.com>; Wed, 6 Mar 2002 22:46:59 -0800 (PST) Received: from BSDWIN2KKOROUSH ([129.197.23.48]) by lmco.com (PMDF V5.2-33 #38886) with SMTP id <0GSL00BNRC66X4@lmco.com>; Wed, 06 Mar 2002 22:46:54 -0800 (PST) Date: Wed, 06 Mar 2002 22:46:50 -0800 From: Koroush Saraf Subject: RouteD is limited - how can I? To: freebsd-questions@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Message-id: <003801c1c5a3$dc283c10$3017c581@BSDWIN2KKOROUSH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200203061700.MAA11066@alpha.vaxxine.com> <15494.36857.673158.314313@guru.mired.org> <200203070437.XAA13463@alpha.vaxxine.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi All, With help from teh questions group I have managed to run RIPV2 on a single NIC computer using the following command routed -s ripv2 However, there are several aliased IP addresses on this interface and they are being advertized and found in the RIP table. Now I want to exclude one of the aliased addresses from being advertized. I have tried to put the following in my /etc/gateways file, net 0.0.0.0 gateway x.x.x.x metric 16 extern where x.x.x.x is the alias that I want to exclude, but it doesn't do the job. Can you guide me on how I can remove a network from the advertized list? thanks in advance ~koroush ps. please CC me on the reply To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 23:26:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 1DCC437B402; Wed, 6 Mar 2002 23:26:21 -0800 (PST) Date: Wed, 6 Mar 2002 23:26:21 -0800 From: David O'Brien To: Poul-Henning Kamp Cc: "M. Warner Losh" , drosih@rpi.edu, mwm-dated-1015843484.1eabc5@mired.org, hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing. Message-ID: <20020306232620.A10433@hub.freebsd.org> Reply-To: obrien@freebsd.org References: <20020306.230059.128109706.imp@village.org> <55380.1015481689@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <55380.1015481689@critter.freebsd.dk>; from phk@critter.freebsd.dk on Thu, Mar 07, 2002 at 07:14:49AM +0100 X-Operating-System: FreeBSD 4.4-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 07:14:49AM +0100, Poul-Henning Kamp wrote: > Guys, strcmp() has been defined that way for almost 30 years, get > used to it, and don't demand obfuscation of every other if() in > the kernel to try to hide the fact... We are not trying to hide anything. Style(9) says to don't do that, so we shouldn't. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Mar 6 23:37:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by hub.freebsd.org (Postfix) with ESMTP id 9B8AD37B41A for ; Wed, 6 Mar 2002 23:37:30 -0800 (PST) Received: from laptop.6bone.nl (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g277aK016470; Thu, 7 Mar 2002 08:36:20 +0100 Received: (nullmailer pid 22783 invoked by uid 1000); Thu, 07 Mar 2002 07:17:07 -0000 Date: Thu, 7 Mar 2002 08:17:06 +0100 From: Mark Santcroos To: Julian Elischer Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: please remove blank line Message-ID: <20020307081706.B4669@laptop.6bone.nl> References: <00e301c1c4c9$295966c0$ef01a8c0@davidwnt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Wed, Mar 06, 2002 at 10:39:16AM -0800 X-Handles: MS6-6BONE, MS18417-RIPE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 10:39:16AM -0800, Julian Elischer wrote: > The coding style guide for freebsd says that a blank line shalll be above > the code and below teh variable declarations.. > most peopple take this to read that the blank line still appears if there > are no variables. style(9): /* Insert an empty line if the function has no local variables. */ Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 0:45:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id CD3BF37B402 for ; Thu, 7 Mar 2002 00:45:31 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g278jJJ35896 for ; Thu, 7 Mar 2002 10:45:19 +0200 (EET) (envelope-from mitko@rila.bg) Date: Thu, 7 Mar 2002 10:45:18 +0200 From: Dimitar Peikov To: freebsd-hackers@freebsd.org Subject: Swapping performance Message-Id: <20020307104518.0f73740b.mitko@rila.bg> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Thu__7_Mar_2002_10:45:18_+0200_0829be00" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --Multipart_Thu__7_Mar_2002_10:45:18_+0200_0829be00 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I don't comment about 'bzero' performance, but when RAM is over, Linux is much faster. I have no idea what is the algorithm of swapping but it seems that the granularity of swapping pieces is the key or the importance of swapping memory blocks of certain task. Ooo I forgot to say that the both machines have the same hardware, IBM 300PL, 256 RAM and no other tasks running. I had to run these tests to choose the fastest platform for building our software indexes, which requires a lot of math and memory operations. --- with bzero --- Linux$ time ./malloc_test *# real 0m37.640s user 0m1.370s sys 0m2.950s Linux$ FreeBSD$ time ./malloc_test *# real 0m46.640s user 0m2.280s sys 0m2.550s FreeBSD$ --- without bzero --- Linux$ time ./malloc_test *# real 0m6.371s user 0m0.450s sys 0m1.510s Linux$ FreeBSD$ time ./malloc_test *# real 0m11.571s user 0m1.150s sys 0m1.830s FreeBSD$ -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com --Multipart_Thu__7_Mar_2002_10:45:18_+0200_0829be00 Content-Type: application/octet-stream; name="malloc_test.c" Content-Disposition: attachment; filename="malloc_test.c" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDxzdGRpby5o PgoKI2RlZmluZSBNQUxMT0NfU0laRSAxMDI0KjEwMjQqMjU2CgppbnQgbWFpbihpbnQgYXJnYywg Y2hhciAqKmFyZ3YpIHsKICBjaGFyICpwdHI7CiAgaW50IGksIGlfY291bnQ7CiAgaW50IGo7Cgog IHB0ciA9IChjaGFyICopIG1hbGxvYyhNQUxMT0NfU0laRSk7CiAgYnplcm8ocHRyLCBNQUxMT0Nf U0laRSk7CgogIGlfY291bnQgPSBNQUxMT0NfU0laRSAvIDE2OwogIGZwcmludGYoc3RkZXJyLCAi KiIpOwogIGZvciAoaSA9IDA7IGkgPCBpX2NvdW50OyBpICsrKSB7CiAgICAgIHB0cltpID4+IDRd ID0gcHRyWyhpID4+IDMpICsgMV0rKzsKICB9CiAgZnByaW50ZihzdGRlcnIsICIjIik7CiAgZm9y IChqID0gMDsgaiA8IGlfY291bnQ7IGogKyspIHsKICAgICAgcHRyW2ogPDwgNF0gPSBwdHJbKGog Pj4gMykgKyAxXSsrOwogIH0KCiAgZnJlZShwdHIpOwogIHJldHVybiAwOwp9Cg== --Multipart_Thu__7_Mar_2002_10:45:18_+0200_0829be00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 0:51: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id E303F37B404 for ; Thu, 7 Mar 2002 00:51:06 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id B11DDAE1D0; Thu, 7 Mar 2002 00:51:06 -0800 (PST) Date: Thu, 7 Mar 2002 00:51:06 -0800 From: Alfred Perlstein To: Dimitar Peikov Cc: freebsd-hackers@freebsd.org Subject: Re: Swapping performance Message-ID: <20020307085106.GB26621@elvis.mu.org> References: <20020307104518.0f73740b.mitko@rila.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020307104518.0f73740b.mitko@rila.bg> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Dimitar Peikov [020307 00:45] wrote: > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > don't comment about 'bzero' performance, but when RAM is over, Linux > is much faster. I have no idea what is the algorithm of swapping but it seems that the granularity of swapping pieces is the key or the importance of swapping memory blocks of certain task. Ooo I forgot to say that the both machines have the same hardware, IBM 300PL, 256 RAM and no other tasks running. I had to run these tests to choose the fastest platform for building our software indexes, which requires a lot of math and memory operations. > > --- with bzero --- > Linux$ time ./malloc_test Could you explain what "malloc_test" actually does and/or share the code? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 0:51:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from energyhq.homeip.net (213-97-200-73.uc.nombres.ttd.es [213.97.200.73]) by hub.freebsd.org (Postfix) with ESMTP id 8A5D337B417 for ; Thu, 7 Mar 2002 00:51:46 -0800 (PST) Received: by energyhq.homeip.net (Postfix, from userid 1001) id 511C03FC5B; Thu, 7 Mar 2002 09:51:41 +0100 (CET) Date: Thu, 7 Mar 2002 09:51:41 +0100 From: Miguel Mendez To: Mike Meyer Cc: freebsd-hackers@freebsd.org, D J Hawkey Jr , bts@babbleon.org Subject: Re: C vs C++ Message-ID: <20020307095141.A2889@energyhq.homeip.net> Mail-Followup-To: Mike Meyer , freebsd-hackers@freebsd.org, D J Hawkey Jr , bts@babbleon.org References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> <15494.57538.888210.658115@guru.mired.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15494.57538.888210.658115@guru.mired.org>; from mwm-dated-1015904323.d82925@mired.org on Wed, Mar 06, 2002 at 09:38:42PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote: > That is true. C++ is as ugly as C, but has all the problems of Object > Orient Languages. What are you smoking? :-) No language in this world fits OS development better than C. IMHO is one of the most beautiful languages ever created. It's simple, small and efficient. And it requires you to know what you are doing, but I consider that a feature. C resembles assembler on many of it's constructs. C++ on the other hand is a solution for a non existant problem. Sure, you can write good code in C++ (e.g. BeOS), but it usually leads to bloatware (cough MSFT cough) because programmers get really excited about all those cool (as in useless) features. Cheers, --=20 Miguel Mendez - flynn@energyhq.homeip.net GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8hyocnLctrNyFFPERAhw8AJ4i7KD0QDs/chVrGLVaJXg/4iEJPwCcDSr9 yWxUK9sSnvLwx2963B2Tzo4= =0bY/ -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 0:53:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gwdu60.gwdg.de (gwdu60.gwdg.de [134.76.98.60]) by hub.freebsd.org (Postfix) with ESMTP id F1DB737B402 for ; Thu, 7 Mar 2002 00:53:43 -0800 (PST) Received: from localhost (kheuer@localhost) by gwdu60.gwdg.de (8.11.6/8.11.6) with ESMTP id g278rf719675; Thu, 7 Mar 2002 09:53:41 +0100 (CET) (envelope-from kheuer@gwdg.de) X-Authentication-Warning: gwdu60.gwdg.de: kheuer owned process doing -bs Date: Thu, 7 Mar 2002 09:53:40 +0100 (CET) From: Konrad Heuer To: Dimitar Peikov Cc: freebsd-hackers@freebsd.org Subject: Re: Swapping performance In-Reply-To: <20020307104518.0f73740b.mitko@rila.bg> Message-ID: <20020307094856.K17236-100000@gwdu60.gwdg.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Dimitar Peikov wrote: > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > don't comment about 'bzero' performance, but when RAM is over, Linux > is much faster. I have no idea what is the algorithm of swapping but it s= eems that the granularity of swapping pieces is the key or the importance o= f swapping memory blocks of certain task. Ooo I forgot to say that the both= machines have the same hardware, IBM 300PL, 256 RAM and no other tasks run= ning. I had to run these tests to choose the fastest platform for building = our software indexes, which requires a lot of math and memory operations. > > --- with bzero --- > Linux$ time ./malloc_test > *# > real 0m37.640s > user 0m1.370s > sys 0m2.950s > Linux$ > > FreeBSD$ time ./malloc_test > *# > real 0m46.640s > user 0m2.280s > sys 0m2.550s > FreeBSD$ > > --- without bzero --- > Linux$ time ./malloc_test > *# > real 0m6.371s > user 0m0.450s > sys 0m1.510s > Linux$ > > FreeBSD$ time ./malloc_test > *# > real 0m11.571s > user 0m1.150s > sys 0m1.830s > FreeBSD$ Just to make sure: What about disk layout and paging space location? Both systems will behave best when paging space location is near to the "beginning" of the disks. My measurements in this area are some years old; at that time FreeBSD did a much better job when klow on free memory. Best regards Konrad Konrad Heuer Personal Bookmarks: Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=D6ttingen http://www.freebsd.org Am Fa=DFberg, D-37077 G=D6ttingen http://www.daemonnews.o= rg Deutschland (Germany) kheuer@gwdg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 1: 0:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 96E6B37B402; Thu, 7 Mar 2002 01:00:47 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g2790Ha04392; Thu, 7 Mar 2002 01:00:17 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203070900.g2790Ha04392@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Maxim Sobolev Cc: hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks In-reply-to: Your message of "Tue, 05 Mar 2002 12:00:45 +0200." <3C84974D.37F683BD@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 01:00:17 -0800 From: Michael Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Please review attached patch, which adds long overdue feature to our > loader(8), allowing it to load sequence of files as a single object. I don't like this. I would much rather see support for 'split' files implemented as a stacking filesystem layer like the gzip support, with the simple recognition of 'foo.gz.aa' as the first part of a split version of 'foo.gz', which in turn is recognised as a compressed version of 'foo'. Making all these changes to parts of the loader that should never know about split files is a bad idea; please don't do it. The "right" approach will be easier and cleaner. Regards, Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 1: 7: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 3704E37B405 for ; Thu, 7 Mar 2002 01:07:08 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 08A4FAE1D0; Thu, 7 Mar 2002 01:07:08 -0800 (PST) Date: Thu, 7 Mar 2002 01:07:08 -0800 From: Alfred Perlstein To: Dimitar Peikov Cc: freebsd-hackers@freebsd.org Subject: Re: Swapping performance Message-ID: <20020307090707.GC26621@elvis.mu.org> References: <20020307104518.0f73740b.mitko@rila.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020307104518.0f73740b.mitko@rila.bg> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Dimitar Peikov [020307 00:45] wrote: > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > don't comment about 'bzero' performance, but when RAM is over, Linux > is much faster. I have no idea what is the algorithm of swapping but it seems that the granularity of swapping pieces is the key or the importance of swapping memory blocks of certain task. Ooo I forgot to say that the both machines have the same hardware, IBM 300PL, 256 RAM and no other tasks running. I had to run these tests to choose the fastest platform for building our software indexes, which requires a lot of math and memory operations. Also, which version of FreeBSD? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 1:21:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id 02EB137B417; Thu, 7 Mar 2002 01:21:34 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id LAA93625; Thu, 7 Mar 2002 11:21:25 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h209.229.dialup.iptcom.net [212.9.229.209]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id LAA52776; Thu, 7 Mar 2002 11:21:21 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id g279KAB10343; Thu, 7 Mar 2002 11:20:10 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C8730FC.E88F85B4@FreeBSD.org> Date: Thu, 07 Mar 2002 11:21:00 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Michael Smith Cc: hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks References: <200203070900.g2790Ha04392@mass.dis.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > > Please review attached patch, which adds long overdue feature to our > > loader(8), allowing it to load sequence of files as a single object. > > I don't like this. I would much rather see support for 'split' files > implemented as a stacking filesystem layer like the gzip support, with > the simple recognition of 'foo.gz.aa' as the first part of a split > version of 'foo.gz', which in turn is recognised as a compressed version > of 'foo'. I am curious how in this case the layer is going to know how many parts the file contains? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 1:29: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 8622A37B426; Thu, 7 Mar 2002 01:28:48 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 52817AE1FC; Thu, 7 Mar 2002 01:28:48 -0800 (PST) Date: Thu, 7 Mar 2002 01:28:48 -0800 From: Bill Fumerola To: Terry Lambert Cc: net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020307092848.GX803@elvis.mu.org> Reply-To: Bill Fumerola References: <3C86BD6B.3ADCB4F0@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C86BD6B.3ADCB4F0@mindspring.com> User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020215 i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 05:07:55PM -0800, Terry Lambert wrote: > There are redundant calls to the in_pcblookup_hash() in the > ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the > ip_input path. in addition to what you're talking about, ipfw will repeat the hash lookup for every rule it goes through that has a uid or gid keyword. http://people.freebsd.org/~billf/bsdcon2000/presentation/graphics/countudpfromanytoanyuidbillf.png http://people.freebsd.org/~billf/bsdcon2000/presentation/graphics/counttcpfromanytoanyuidbillf.png 'old ipfw' = ipfw as of oct 2000 'new ipfw' = ipfw w/pcb cache + uid cache (as part of a compiled ruleset) in the compiled case, in_pcblookup_hash() is called the first time a uid needs compared. after that, uid lookups become a integer compare and not another call to in_pcblookup_hash(). gid lookups still use groupmember() each rule, but also don't have to do a pcb lookup each time. > Right now, I'm just talking about a way ip_input could pass > the already looked up input inpcb to tcp_input, udp_input, > or udp_ctlinput -- all of which repeat the lookup operation. my results are with a cached lookup just in the ipfw code, but if ip_input() did the lookup and passed it to both ipfw and the protocol handler that would be nice. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 1:31:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by hub.freebsd.org (Postfix) with ESMTP id B741837B400; Thu, 7 Mar 2002 01:31:43 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 7 Mar 2002 02:17:09 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id E26DBBA03; Thu, 7 Mar 2002 02:16:30 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Poul-Henning Kamp , obrien@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing -- an actual analysis of the code! Date: Thu, 7 Mar 2002 02:16:30 -0500 X-Mailer: KMail [version 1.3] Cc: Garance A Drosihn , Mike Meyer , hackers@FreeBSD.ORG References: <52204.1015480748@critter.freebsd.dk> In-Reply-To: <52204.1015480748@critter.freebsd.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020307071630.E26DBBA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday 07 March 2002 12:59 am, Poul-Henning Kamp wrote: | In message <20020306192234.B55297@dragon.nuxi.com>, "David O'Brien" writes: | >Implies??? I thought I was quite explicit: | > | > to prevent is "if (!strcmp(a,b))" which when read is extremely wrong | > of that is actually happening. | > | >! is pronounced "NOT". When read "if not string compare a with b then do | > X", is the opposite of the the logic of the expression does. Which is | > "if string compare a with b is equal then do X". ["if (strcmp(a,b) == | > 0)"] | | Well, we're clearly into "IMO" land here, so lets ignore that :-) No, we aren't, and let's not. Maybe your brain has gotten used to it, but to us ordinary mortals, even us ordinary mortals who've been slogging C code for time periods that can be measured in decades (yikes!), it is very tempting to read i f (!strcmp(a,b,l)) as "if the strings don't compare" which , in ordinary usage, means don't compare *equal*. But of course the C program is going to proceed to do exactly the opposite of that. Now, I personally find the constructions if (!p) do_thing_for_null_pointer; and if (p) do_thing_for_valid_pointer; quite readable and would prefer that an abstract Guide To Perfect Style blessed them since I find them quite readable as "if I don't have a pointer" and "if I do have a pointer". But *ALL* of this is beside the nominal point ANYWAY, which is to discuss the proper wording for the man(9) style guide which is supposed to document how things things are actually done in the kernel, not personal preference. =================================================================== So I just grepped the code (find /usr/src -type f -exec grep 'if.*strcmp' {} \;) and analyize the results. Overall, there are 1831 !strcmp test and 3363 strcmp.*==0 tests Within the kernel there are 84 !strcmp tests and 155 strcmp.*== 0 tests So 65% either way in favor of the proposed change in wording -- a 2:1 majority of the code votes FOR the proposed change. (This is subject to minor error given that it's all based on greps and statistics, but I did the analysis a few different ways using different plausible regular expressions to determine the two code paths, and all of analysis showed that it was at least 2:1 using the == / != 0 tests.) -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 1:41: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 747CB37B402; Thu, 7 Mar 2002 01:41:00 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g279eTa04750; Thu, 7 Mar 2002 01:40:30 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203070940.g279eTa04750@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Maxim Sobolev Cc: Michael Smith , hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks In-reply-to: Your message of "Thu, 07 Mar 2002 11:21:00 +0200." <3C8730FC.E88F85B4@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 01:40:29 -0800 From: Michael Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Please review attached patch, which adds long overdue feature to our > > > loader(8), allowing it to load sequence of files as a single object. > > > > I don't like this. I would much rather see support for 'split' files > > implemented as a stacking filesystem layer like the gzip support, with > > the simple recognition of 'foo.gz.aa' as the first part of a split > > version of 'foo.gz', which in turn is recognised as a compressed version > > of 'foo'. > > I am curious how in this case the layer is going to know how many > parts the file contains? The simple way to do it is to keep asking for more parts until there are no more. You can take the NetBSD approach of wrapping the file in a multipart tar archive. Or a more elegant method involves the use of a control file. eg. the splitfs code, when asked to open "foo" looks for "foo.split" which is a text file containing a list of filenames and media names, eg. foo.aa "Kernel floppy 1" foo.ab "Kernel floppy 2" foo.ac "Kernel and modules floppy" For each file segment, the process is: - try to open the file - prompt "please insert the disk labelled '" - try to open the file - return error At any rate, my key point is that the splitting should be invisible, and *definitely* not pushed up into the loader. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 2:57:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by hub.freebsd.org (Postfix) with ESMTP id C629537B41C for ; Thu, 7 Mar 2002 02:57:19 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 7 Mar 2002 10:57:06 +0000 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 16ivXN-0002dZ-00; Thu, 07 Mar 2002 10:54:17 +0000 Date: Thu, 7 Mar 2002 10:54:17 +0000 (GMT) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: freebsd-hackers@freebsd.org Cc: D J Hawkey Jr , bts Subject: Re: C vs C++ In-Reply-To: <20020306191709.A55297@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, David O'Brien wrote: > Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T > C. Got it? I thought it was, because you can't write an event loop without using (infinite) recursion :-) jan PS. This is all very amusing. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk "NOP" is a trivial implementation of an executable Z subset. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 3:23: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from brea.mc.mpls.visi.com (brea.mc.mpls.visi.com [208.42.156.100]) by hub.freebsd.org (Postfix) with ESMTP id 6EA3937B42B for ; Thu, 7 Mar 2002 03:22:30 -0800 (PST) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by brea.mc.mpls.visi.com (Postfix) with ESMTP id F0B422DDD0D; Thu, 7 Mar 2002 05:22:28 -0600 (CST) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.6/8.11.6) id g27BLSt65213; Thu, 7 Mar 2002 05:21:28 -0600 (CST) (envelope-from hawkeyd) Date: Thu, 7 Mar 2002 05:21:28 -0600 From: D J Hawkey Jr To: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: C vs C++ Message-ID: <20020307052128.A65180@sheol.localdomain> Reply-To: hawkeyd@visi.com References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> <20020306215305.A64016@sheol.localdomain> <15494.64812.598093.56688@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15494.64812.598093.56688@guru.mired.org>; from mwm@mired.org on Wed, Mar 06, 2002 at 11:39:56PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mar 06, at 11:39 PM, Mike Meyer wrote: > > D J Hawkey Jr types: > > First, you're ascribing me to a group I don't belong. While I don't know > > Eiffel, or Lisp, or Modula, Snobol, etc., I don't demean them, nor do I > > bitch about such-and-such being written with them (well, not publicly, > > anyway). Many's the time I've wanted to modify a program written in a > > language I didn't/don't know, and learned enough of it to re-write it in > > a language I do know, just to do the changes I wanted. > > Ack! That makes believe the comments about people not wanting to learn > new languages. I would do it the other way around, and learn enough of > the language it's written in to make the changes I wanted. Ordinarily, I'd agree, but sometimes the changes were just to get things to work! With time constraints in place, it was easier and faster to learn the language enough to get a grasp of the code's functionality and re-write it than to LEARN THE LANGUAGE and find the brokenness. In other cases, the boss wanted it in another language. And in some cases, _I_ wanted it in another language. > In fact, I > think that's a good way to learn a language, providing you have a > stylisticly good example to start with. And who'd judge that? > ; Thu, 7 Mar 2002 03:34:06 -0800 (PST) Received: (qmail 16517 invoked from network); 4 Mar 2002 08:28:32 -0000 Received: from unknown (HELO khromovv) (192.168.12.200) by 194.84.142.41 with SMTP; 4 Mar 2002 08:28:32 -0000 Message-ID: <009c01c1c356$93e13be0$c80ca8c0@khromovv> From: "Valery N. Khromov" To: Subject: Converting physical into virtual address Date: Mon, 4 Mar 2002 11:28:35 +0300 Organization: IC "Lukoil" MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'd like to develop a kernel module for FreeBSD, able to read & write directly to VGA text-mode screen buffer. I know that this buffer is located at 0xB8000 in physical address space. But in kernel I must address it using kernel virtual address space. Thus, the question is: how can I _correctly_ convert physical address into kernel virtual address? Now I use the following trick: 0xC0000000 + 0xB8000, but I want to use more correct method. :) thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 4: 0:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id DFB6A37B400; Thu, 7 Mar 2002 04:00:29 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307120029.MXCA1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 12:00:29 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id DAA41437; Thu, 7 Mar 2002 03:51:42 -0800 (PST) Date: Thu, 7 Mar 2002 03:51:41 -0800 (PST) From: Julian Elischer To: Bill Fumerola Cc: Terry Lambert , net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020307092848.GX803@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG what would be even nicer is if ipfw found the cached entry and passed it back to ip_input so it didn't need to :-) On Thu, 7 Mar 2002, Bill Fumerola wrote: > On Wed, Mar 06, 2002 at 05:07:55PM -0800, Terry Lambert wrote: > > > There are redundant calls to the in_pcblookup_hash() in the > > ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the > > ip_input path. > > in addition to what you're talking about, ipfw will repeat the hash > lookup for every rule it goes through that has a uid or gid keyword. > > http://people.freebsd.org/~billf/bsdcon2000/presentation/graphics/countudpfromanytoanyuidbillf.png > http://people.freebsd.org/~billf/bsdcon2000/presentation/graphics/counttcpfromanytoanyuidbillf.png > > 'old ipfw' = ipfw as of oct 2000 > 'new ipfw' = ipfw w/pcb cache + uid cache (as part of a compiled ruleset) > > in the compiled case, in_pcblookup_hash() is called the first time a uid > needs compared. after that, uid lookups become a integer compare and not > another call to in_pcblookup_hash(). gid lookups still use groupmember() > each rule, but also don't have to do a pcb lookup each time. > > > Right now, I'm just talking about a way ip_input could pass > > the already looked up input inpcb to tcp_input, udp_input, > > or udp_ctlinput -- all of which repeat the lookup operation. > > my results are with a cached lookup just in the ipfw code, but if > ip_input() did the lookup and passed it to both ipfw and the protocol > handler that would be nice. > > -- > - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org > > > > 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 Mar 7 4:10: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.nentec.de (gate2.nentec.de [194.25.215.66]) by hub.freebsd.org (Postfix) with ESMTP id DCF6B37B402 for ; Thu, 7 Mar 2002 04:09:55 -0800 (PST) Received: from nenny.nentec.de (root@nenny.nentec.de [153.92.64.1]) by gate.nentec.de (8.9.3/8.9.3) with ESMTP id NAA27912; Thu, 7 Mar 2002 13:09:55 +0100 Received: from andromeda (andromeda [153.92.64.34]) by nenny.nentec.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g27C9ph26282; Thu, 7 Mar 2002 13:09:52 +0100 Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <009c01c1c356$93e13be0$c80ca8c0@khromovv> Date: Thu, 07 Mar 2002 13:09:40 +0100 (MET) Reply-To: Andy Sporner Organization: NENTEC Netywerktechnologie GmbH From: Andy Sporner To: "Valery N. Khromov" Subject: RE: Converting physical into virtual address Cc: freebsd-hackers@FreeBSD.ORG X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04-Mar-02 Valery N. Khromov wrote: > I'd like to develop a kernel module for FreeBSD, able to read & write > directly to VGA text-mode screen buffer. I know that this buffer is located > at 0xB8000 in physical address space. But in kernel I must address it using > kernel virtual address space. > > Thus, the question is: how can I _correctly_ convert physical address into > kernel virtual address? > > Now I use the following trick: 0xC0000000 + 0xB8000, but I want to use more > correct method. :) > > thanks. > > > > 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 Mar 7 4:17:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id 943E537B404; Thu, 7 Mar 2002 04:17:21 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id OAA14827; Thu, 7 Mar 2002 14:17:16 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h74.228.dialup.iptcom.net [212.9.228.74]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id OAA52147; Thu, 7 Mar 2002 14:17:14 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id g27CGhB12330; Thu, 7 Mar 2002 14:16:43 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C875A5C.53949862@FreeBSD.org> Date: Thu, 07 Mar 2002 14:17:32 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Michael Smith Cc: hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks References: <200203070940.g279eTa04750@mass.dis.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > > > > Please review attached patch, which adds long overdue feature to our > > > > loader(8), allowing it to load sequence of files as a single object. > > > > > > I don't like this. I would much rather see support for 'split' files > > > implemented as a stacking filesystem layer like the gzip support, with > > > the simple recognition of 'foo.gz.aa' as the first part of a split > > > version of 'foo.gz', which in turn is recognised as a compressed version > > > of 'foo'. > > > > I am curious how in this case the layer is going to know how many > > parts the file contains? > > The simple way to do it is to keep asking for more parts until there are > no more. > > You can take the NetBSD approach of wrapping the file in a multipart tar > archive. > > Or a more elegant method involves the use of a control file. > > eg. the splitfs code, when asked to open "foo" looks for "foo.split" > which is a text file containing a list of filenames and media names, eg. > > foo.aa "Kernel floppy 1" > foo.ab "Kernel floppy 2" > foo.ac "Kernel and modules floppy" > > For each file segment, the process is: > > - try to open the file > - prompt "please insert the disk labelled '" > - try to open the file > - return error > > At any rate, my key point is that the splitting should be invisible, and > *definitely* not pushed up into the loader. Ok, sounds reasonably. I'll try to reimplement the feature this way. Thank you for suggestion. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 4:20:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from energyhq.homeip.net (213-97-200-73.uc.nombres.ttd.es [213.97.200.73]) by hub.freebsd.org (Postfix) with ESMTP id DF81D37B427 for ; Thu, 7 Mar 2002 04:20:06 -0800 (PST) Received: by energyhq.homeip.net (Postfix, from userid 1001) id B36363FC5A; Thu, 7 Mar 2002 13:20:07 +0100 (CET) Date: Thu, 7 Mar 2002 13:20:07 +0100 From: Miguel Mendez To: Andy Sporner Cc: "Valery N. Khromov" , freebsd-hackers@FreeBSD.ORG Subject: Re: Converting physical into virtual address Message-ID: <20020307132007.A3957@energyhq.homeip.net> Mail-Followup-To: Andy Sporner , "Valery N. Khromov" , freebsd-hackers@FreeBSD.ORG References: <009c01c1c356$93e13be0$c80ca8c0@khromovv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from sporner@nentec.de on Thu, Mar 07, 2002 at 01:09:40PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 07, 2002 at 01:09:40PM +0100, Andy Sporner wrote: Andy, what were you trying to say? Or is that the way the Linux kernel converts addresses? Cheers, --=20 Miguel Mendez - flynn@energyhq.homeip.net GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8h1r2nLctrNyFFPERApAeAJ0fUp3i6HAN+4An0kQkKAl6fAJE6ACfYI4c zgi5Y4hTkxvXTc/tmsQ4u4w= =Lmrp -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 4:20:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 4246537B425 for ; Thu, 7 Mar 2002 04:20:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307122009.JZRP2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 12:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id EAA41525; Thu, 7 Mar 2002 04:02:01 -0800 (PST) Date: Thu, 7 Mar 2002 04:01:58 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: Dimitar Peikov , freebsd-hackers@freebsd.org Subject: Re: Swapping performance In-Reply-To: <20020307090707.GC26621@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG he said -stable.. what are the malloc options on -stable? maybe we should make sure that they are null ln -s ">" /etc/malloc.conf (I hope that helps) :) On Thu, 7 Mar 2002, Alfred Perlstein wrote: > * Dimitar Peikov [020307 00:45] wrote: > > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > > don't comment about 'bzero' performance, but when RAM is over, Linux > > is much faster. I have no idea what is the algorithm of swapping but it seems that the granularity of swapping pieces is the key or the importance of swapping memory blocks of certain task. Ooo I forgot to say that the both machines have the same hardware, IBM 300PL, 256 RAM and no other tasks running. I had to run these tests to choose the fastest platform for building our software indexes, which requires a lot of math and memory operations. > > Also, which version of FreeBSD? > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ > > 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 Mar 7 4:28: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.nentec.de (gate2.nentec.de [194.25.215.66]) by hub.freebsd.org (Postfix) with ESMTP id 48A1737B427 for ; Thu, 7 Mar 2002 04:27:50 -0800 (PST) Received: from nenny.nentec.de (root@nenny.nentec.de [153.92.64.1]) by gate.nentec.de (8.9.3/8.9.3) with ESMTP id NAA28060; Thu, 7 Mar 2002 13:27:48 +0100 Received: from andromeda (andromeda [153.92.64.34]) by nenny.nentec.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g27CRjh27682; Thu, 7 Mar 2002 13:27:45 +0100 Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020307132007.A3957@energyhq.homeip.net> Date: Thu, 07 Mar 2002 13:27:33 +0100 (MET) Reply-To: Andy Sporner Organization: NENTEC Netywerktechnologie GmbH From: Andy Sporner To: Miguel Mendez Subject: Re: Converting physical into virtual address Cc: freebsd-hackers@FreeBSD.ORG, "Valery N. Khromov" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok :-) I am caught. I hit the send key by accident when I realized I had misread the question. > Andy, what were you trying to say? > > Or is that the way the Linux kernel converts addresses? > Probably! :-) Have you a name yet for 'fish?' Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 4:28:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id AD6E237B440 for ; Thu, 7 Mar 2002 04:28:43 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g27CRxJ44055; Thu, 7 Mar 2002 14:28:00 +0200 (EET) (envelope-from mitko@rila.bg) Date: Thu, 7 Mar 2002 14:27:59 +0200 From: Dimitar Peikov To: Julian Elischer , freebsd-hackers@freebsd.org Subject: Re: Swapping performance Message-Id: <20020307142759.0d95d467.mitko@rila.bg> In-Reply-To: References: <20020307090707.GC26621@elvis.mu.org> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002 04:01:58 -0800 (PST) Julian Elischer wrote: > he said -stable.. > > what are the malloc options on -stable? > > maybe we should make sure that they are null > > ln -s ">" /etc/malloc.conf > (I hope that helps) :) > I've tested it with : cc -O6 -o malloc_test malloc_test.c ln -s ">>" /etc/malloc.conf ln -s "<<" /etc/malloc.conf ln -s "HR>>" /etc/malloc.conf ln -s "HR<<" /etc/malloc.conf and no significant performance issue between the tests. There were some differences but not amazing one. > > On Thu, 7 Mar 2002, Alfred Perlstein wrote: > > > * Dimitar Peikov [020307 00:45] wrote: > > > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > > > don't comment about 'bzero' performance, but when RAM is over, Linux > > > is much faster. I have no idea what is the algorithm of swapping but > > > it seems that the granularity of swapping pieces is the key or the > > > importance of swapping memory blocks of certain task. Ooo I forgot to > > > say that the both machines have the same hardware, IBM 300PL, 256 RAM > > > and no other tasks running. I had to run these tests to choose the > > > fastest platform for building our software indexes, which requires a > > > lot of math and memory operations. > > > > Also, which version of FreeBSD? > > > > -- > > -Alfred Perlstein [alfred@freebsd.org] > > 'Instead of asking why a piece of software is using "1970s technology," > > start asking why software is ignoring 30 years of accumulated wisdom.' > > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 5:33:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id C2C0E37B405 for ; Thu, 7 Mar 2002 05:33:31 -0800 (PST) Received: by gw.nectar.cc (Postfix, from userid 1001) id 38C4B36; Thu, 7 Mar 2002 07:33:31 -0600 (CST) Date: Thu, 7 Mar 2002 07:33:31 -0600 From: "Jacques A. Vidrine" To: Mike Meyer Cc: freebsd-hackers@freebsd.org, D J Hawkey Jr , bts@babbleon.org Subject: Re: C vs C++ Message-ID: <20020307133331.GI36653@hellblazer.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , Mike Meyer , freebsd-hackers@freebsd.org, D J Hawkey Jr , bts@babbleon.org References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> <15494.57538.888210.658115@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15494.57538.888210.658115@guru.mired.org> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [This is probably -chat material ...] On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote: > That is true. C++ is as ugly as C, but has all the problems of Object > Orient Languages. I love this quote (from http://www.paulgraham.com/noop.html): Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 6: 9:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from primus.vsservices.com (primus.vsservices.com [63.66.136.75]) by hub.freebsd.org (Postfix) with ESMTP id 3DF3037B404 for ; Thu, 7 Mar 2002 06:09:10 -0800 (PST) Received: from prime.vsservices.com (conr-adsl-dhcp-26-38.txucom.net [209.34.26.38]) by primus.vsservices.com (8.11.3/8.11.3) with SMTP id g27E92k49817; Thu, 7 Mar 2002 08:09:03 -0600 (CST) (envelope-from gclarkii@vsservices.com) Date: Thu, 7 Mar 2002 08:09:06 -0600 From: GB Clark To: mitko@rila.bg Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance Message-Id: <20020307080906.367be8df.gclarkii@vsservices.com> In-Reply-To: <20020307142759.0d95d467.mitko@rila.bg> References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> X-Mailer: Sylpheed version 0.6.6 (GTK+ 1.2.10; i386-unknown-freebsd4.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002 14:27:59 +0200 Dimitar Peikov wrote: > On Thu, 7 Mar 2002 04:01:58 -0800 (PST) > Julian Elischer wrote: > > > he said -stable.. > > > > what are the malloc options on -stable? > > > > maybe we should make sure that they are null > > > > ln -s ">" /etc/malloc.conf > > (I hope that helps) :) > > > > I've tested it with : > > cc -O6 -o malloc_test malloc_test.c That -O6 does not look right from here. Do we support anything over -O2? And how about some source for malloc_test.c? The fact of running something at -O6 started some bells ringing. --SNIP-- GB -- GB Clark II | Roaming FreeBSD Admin gclarkii@VSServices.COM | General Geek CTHULU for President - Why choose the lesser of two evils? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 6:36: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ubergeeks.com (lorax.ubergeeks.com [209.145.65.55]) by hub.freebsd.org (Postfix) with ESMTP id D744837B405 for ; Thu, 7 Mar 2002 06:35:58 -0800 (PST) Received: from localhost (adrian@localhost) by mail.ubergeeks.com (8.11.6/8.11.6) with ESMTP id g26FURd56934; Wed, 6 Mar 2002 10:30:28 -0500 (EST) (envelope-from adrian@ubergeeks.com) Date: Wed, 6 Mar 2002 10:30:27 -0500 (EST) From: Adrian Filipi-Martin Reply-To: Adrian Filipi-Martin To: Mark Murray Cc: FreeBSD Hackers List , Subject: Re: Intel 820 RNG In-Reply-To: <200203052342.g25NgTRV079032@grimreaper.grondar.org> Message-ID: <20020306102600.L56921-100000@lorax.ubergeeks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, Mark Murray wrote: > > We did make some enhancements that serve our needs, but may not be > > best for everyone. We actually need entropy in quantity since we could be > > doing a lot of crypto operations back to back and it can easily become our > > worst bottleneck. > > Have you looked at the "Yarrow" algorithm? Yes. I actually grilled you a bit about this at BSDCon 2000. :-) AFAIK, it will never be back ported to 4-STABLE. Is there an option that's appeared for FreeBSD besides this in the last 18 months? > In CURRENT, I have implemented Yarrow to achieve just this purpose. > > > The drawback to our approach is that it can spend a lot of time in > > the kernel. To tune this behavior we added a few sysctl's. The start/stop > > script after the diff's tweaks a few of these settings after boot up. > > Again, look at current. The RNG is _really_ fast. I know. I know. I wish we could use it. Unfortunately this is for an appliance type application and I just don't feel comfortably shipping -CURRENT as product. I'm only just now making the effort to get up to speed on -CURRENT so that we can be ready to use it later this year. Adrian -- [ adrian@ubergeeks.com ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 6:47:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from straylight.ringlet.net (support.nanolink.com [217.75.134.33]) by hub.freebsd.org (Postfix) with SMTP id 431E737B400 for ; Thu, 7 Mar 2002 06:47:11 -0800 (PST) Received: (qmail 5181 invoked by uid 1000); 7 Mar 2002 14:47:24 -0000 Date: Thu, 7 Mar 2002 16:47:24 +0200 From: Peter Pentchev To: GB Clark Cc: mitko@rila.bg, freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance Message-ID: <20020307164724.D377@straylight.oblivion.bg> Mail-Followup-To: GB Clark , mitko@rila.bg, freebsd-hackers@FreeBSD.ORG References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020307080906.367be8df.gclarkii@vsservices.com>; from gclarkii@vsservices.com on Thu, Mar 07, 2002 at 08:09:06AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote: > On Thu, 7 Mar 2002 14:27:59 +0200 > Dimitar Peikov wrote: >=20 > > On Thu, 7 Mar 2002 04:01:58 -0800 (PST) > > Julian Elischer wrote: > >=20 > > > he said -stable.. > > >=20 > > > what are the malloc options on -stable? > > >=20 > > > maybe we should make sure that they are null=20 > > >=20 > > > ln -s ">" /etc/malloc.conf > > > (I hope that helps) :) > > >=20 > >=20 > > I've tested it with : > >=20 > > cc -O6 -o malloc_test malloc_test.c >=20 > That -O6 does not look right from here. Do we support anything over -O2? ISTR that -On is exactly the same for -O2 for n > 2; or is this stale info? Maybe GCC 3.x supports higher optimization levels; still, I don't think this would make any significant difference. Note to Dimitar: maybe compiling it with -static would make it just a little bit faster; then again, it may not. >=20 > And how about some source for malloc_test.c? The fact of running somethi= ng at -O6 > started some bells ringing. The source was attached to Dimitar's original post :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. --a2FkP9tdjPU2nyhF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyHfXwACgkQ7Ri2jRYZRVPTFwCfVfevfdLGDyueXKvaBTSOyIDL RX8AmwU8tARrHknSFlJMVc5Qy7Sr9JEJ =ycjT -----END PGP SIGNATURE----- --a2FkP9tdjPU2nyhF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 6:48:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id CA7C537B400 for ; Thu, 7 Mar 2002 06:48:40 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g27EmBJ45728; Thu, 7 Mar 2002 16:48:23 +0200 (EET) (envelope-from mitko@rila.bg) Date: Thu, 7 Mar 2002 16:48:11 +0200 From: Dimitar Peikov To: GB Clark Cc: freebsd-hackers@freebsd.org Subject: Re: Swapping performance Message-Id: <20020307164811.1501ca71.mitko@rila.bg> In-Reply-To: <20020307080906.367be8df.gclarkii@vsservices.com> References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002 08:09:06 -0600 GB Clark wrote: > On Thu, 7 Mar 2002 14:27:59 +0200 > Dimitar Peikov wrote: > > > On Thu, 7 Mar 2002 04:01:58 -0800 (PST) > > Julian Elischer wrote: > > > > > he said -stable.. > > > > > > what are the malloc options on -stable? > > > > > > maybe we should make sure that they are null > > > > > > ln -s ">" /etc/malloc.conf > > > (I hope that helps) :) > > > > > > > I've tested it with : > > > > cc -O6 -o malloc_test malloc_test.c > > That -O6 does not look right from here. Do we support anything over -O2? > I've checked -O6 more complicated sources and they work just amazing! This is a GCC problem, not an OS specific feature. (I've use this and on Linux, OpenBSD, Solaris SPARC/Intel). Even if I compile it using -O2 the result is the same. FreeBSD machine always finish late! At this time I can't compare with Solaris, but OpenBSD got near the same performance. > And how about some source for malloc_test.c? The fact of running > something at -O6 started some bells ringing. > > > --SNIP-- > > GB > > -- > GB Clark II | Roaming FreeBSD Admin > gclarkii@VSServices.COM | General Geek > CTHULU for President - Why choose the lesser of two evils? -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 6:49:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sandbox.sandstorm.net (user-v3qtgdr.biz.mindspring.com [199.174.193.187]) by hub.freebsd.org (Postfix) with ESMTP id C781037B42F for ; Thu, 7 Mar 2002 06:49:03 -0800 (PST) Received: from innsmouth.sandstorm.net (eight) [199.174.193.186] by sandbox.sandstorm.net with smtp (Exim 2.05 #2 (Debian)) id 16izCV-0004qF-00; Thu, 7 Mar 2002 09:48:59 -0500 Message-ID: <05fe01c1c5e6$6a02e890$2400010a@eight> From: "cjp" To: , References: <20020307104518.0f73740b.mitko@rila.bg> Subject: Re: Swapping performance Date: Thu, 7 Mar 2002 09:42:44 -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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a comparison of how fast Linux can do something STUPID versus how fast a real OS can do something intelligently. Your test is giving you misleading, and dangerous numbers. Do not go waving them around until you have actually looked at mallocs behavior on the different systems. Here's why: Linux implements a brain dead memory allocation scheme called memory overcommit. It will let you malloc as much memory as you want whether it is available as RAM or not and only bitch when you try to use the memory. Therefore, Linux malloc is much faster than any reasonable system, since all it is doing is handing out address space out of unallocated address space, not keeping track of how much memory there actually is. In order to handle the kruft that occurs, there is the out of memory killer, oom_killer. Which merrily goes through the list of processes, killing off the low priority processes until enough memory is free to satisfy what was most recently used. It's the loan shark repayment program, with OOMKiller performing the function of the deliquency reminder. On any of the BSD system, you actually get memory you can use, and all the overhead of assuring its existence at the time of allocation. Much more robust, less prone to abuse. Try it, you'll like it. If you want the nuts and bolts of it, read the source. ----- Original Message ----- From: "Dimitar Peikov" To: Sent: Thursday, March 07, 2002 3:45 AM Subject: Swapping performance > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > don't comment about 'bzero' performance, but when RAM is over, Linux > is much faster. I have no idea what is the algorithm of swapping but it seems that the granularity of swapping pieces is the key or the importance of swapping memory blocks of certain task. Ooo I forgot to say that the both machines have the same hardware, IBM 300PL, 256 RAM and no other tasks running. I had to run these tests to choose the fastest platform for building our software indexes, which requires a lot of math and memory operations. > > --- with bzero --- > Linux$ time ./malloc_test > *# > real 0m37.640s > user 0m1.370s > sys 0m2.950s > Linux$ > > FreeBSD$ time ./malloc_test > *# > real 0m46.640s > user 0m2.280s > sys 0m2.550s > FreeBSD$ > > --- without bzero --- > Linux$ time ./malloc_test > *# > real 0m6.371s > user 0m0.450s > sys 0m1.510s > Linux$ > > FreeBSD$ time ./malloc_test > *# > real 0m11.571s > user 0m1.150s > sys 0m1.830s > FreeBSD$ > > > > -- > Dimitar Peikov > Programmer Analyst > Globalization Group > "We Build e-Business" > > RILA Solutions > 27 Building, Acad.G.Bonchev Str. > 1113 Sofia, Bulgaria > > phone: (+359 2) 9797320 > phone: (+359 2) 9797300 > fax: (+359 2) 9733355 > http://www.rila.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 6:56:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 0255837B42B for ; Thu, 7 Mar 2002 06:56:14 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g27EtZR04033; Thu, 7 Mar 2002 15:55:35 +0100 (MET) Date: Thu, 7 Mar 2002 15:55:35 +0100 (CET) From: Harti Brandt To: cjp Cc: mitko@rila.bg, Subject: Re: Swapping performance In-Reply-To: <05fe01c1c5e6$6a02e890$2400010a@eight> Message-ID: <20020307155432.A99061-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, cjp wrote: You are probably misinformed, because FreeBSD also does overcommit of memory. If you look up the mail archives you will find long battles about the pros and cons of this. harti c>This is a comparison of how fast Linux can do something c>STUPID versus how fast a real OS can do something intelligently. Your c>test is giving you misleading, and dangerous numbers. Do not go waving them c>around until you have actually looked at mallocs behavior on the different c>systems. c> c>Here's why: c> c>Linux implements a brain dead memory allocation c>scheme called memory overcommit. It will let you malloc c>as much memory as you want whether it is available as RAM or not c>and only bitch when you try to use the memory. Therefore, c>Linux malloc is much faster than any reasonable system, since all it is doing is c>handing out address space out of unallocated address space, c>not keeping track of how much memory there actually is. c> c>In order to handle the kruft that occurs, there is the out of memory killer, c>oom_killer. c>Which merrily goes through the list of processes, killing off the low priority c>processes c>until enough memory is free to satisfy what was most recently used. It's the c>loan shark c>repayment program, with OOMKiller performing the function of the deliquency c>reminder. c> c>On any of the BSD system, you actually get memory you can use, and all the c>overhead c>of assuring its existence at the time of allocation. Much more robust, less c>prone to abuse. c> c>Try it, you'll like it. If you want the nuts and bolts of it, read the source. c> c> c>----- Original Message ----- c>From: "Dimitar Peikov" c>To: c>Sent: Thursday, March 07, 2002 3:45 AM c>Subject: Swapping performance c> c> c>> I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I c>> don't comment about 'bzero' performance, but when RAM is over, Linux c>> is much faster. I have no idea what is the algorithm of swapping but it seems c>that the granularity of swapping pieces is the key or the importance of swapping c>memory blocks of certain task. Ooo I forgot to say that the both machines have c>the same hardware, IBM 300PL, 256 RAM and no other tasks running. I had to run c>these tests to choose the fastest platform for building our software indexes, c>which requires a lot of math and memory operations. c>> c>> --- with bzero --- c>> Linux$ time ./malloc_test c>> *# c>> real 0m37.640s c>> user 0m1.370s c>> sys 0m2.950s c>> Linux$ c>> c>> FreeBSD$ time ./malloc_test c>> *# c>> real 0m46.640s c>> user 0m2.280s c>> sys 0m2.550s c>> FreeBSD$ c>> c>> --- without bzero --- c>> Linux$ time ./malloc_test c>> *# c>> real 0m6.371s c>> user 0m0.450s c>> sys 0m1.510s c>> Linux$ c>> c>> FreeBSD$ time ./malloc_test c>> *# c>> real 0m11.571s c>> user 0m1.150s c>> sys 0m1.830s c>> FreeBSD$ c>> c>> c>> c>> -- c>> Dimitar Peikov c>> Programmer Analyst c>> Globalization Group c>> "We Build e-Business" c>> c>> RILA Solutions c>> 27 Building, Acad.G.Bonchev Str. c>> 1113 Sofia, Bulgaria c>> c>> phone: (+359 2) 9797320 c>> phone: (+359 2) 9797300 c>> fax: (+359 2) 9733355 c>> http://www.rila.com c>> c> c> c>To Unsubscribe: send mail to majordomo@FreeBSD.org c>with "unsubscribe freebsd-hackers" in the body of the message c> -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 7:19:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id 8875F37B41A for ; Thu, 7 Mar 2002 07:18:46 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g27FGsJ46102 for ; Thu, 7 Mar 2002 17:16:55 +0200 (EET) (envelope-from mitko@rila.bg) Date: Thu, 7 Mar 2002 16:58:51 +0200 From: Dimitar Peikov (by way of Dimitar Peikov ) To: "cjp" Subject: Re: Swapping performance Message-Id: <20020307165851.79f391f3.mitko@rila.bg> In-Reply-To: <05fe01c1c5e6$6a02e890$2400010a@eight> References: <20020307104518.0f73740b.mitko@rila.bg> <05fe01c1c5e6$6a02e890$2400010a@eight> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002 09:42:44 -0500 "cjp" wrote: > This is a comparison of how fast Linux can do something > STUPID versus how fast a real OS can do something intelligently. Your > test is giving you misleading, and dangerous numbers. Do not go waving > them around until you have actually looked at mallocs behavior on the > different systems. In fact if I have to compute something really important for me (STUPID as you said) I would choose the fastest OS. I start this thread not to blame against *BSD architecture but the see if there is a way to fix this and to catch the right person who had more experience than me in this area! I have no idea to start anything that would be treated as blame against FreeBSD and against any of the developers who support it! Further more I prefer FreeBSD than Linux, but if I have to wait one day to calculate something on FreeBSD and to wait a few hours less using Linux I would run Linux or Solaris or whatever. If I don't like FreeBSD I would not post my letter, I don't like to loose my time with something that is STUPID! I don't know if your case is this! > > Here's why: > > Linux implements a brain dead memory allocation > scheme called memory overcommit. It will let you malloc > as much memory as you want whether it is available as RAM or not > and only bitch when you try to use the memory. Therefore, > Linux malloc is much faster than any reasonable system, since all it is > doing is handing out address space out of unallocated address space, > not keeping track of how much memory there actually is. > > In order to handle the kruft that occurs, there is the out of memory > killer, oom_killer. > Which merrily goes through the list of processes, killing off the low > priority processes > until enough memory is free to satisfy what was most recently used. It's > the loan shark > repayment program, with OOMKiller performing the function of the > deliquency reminder. > > On any of the BSD system, you actually get memory you can use, and all the > overhead > of assuring its existence at the time of allocation. Much more robust, > less prone to abuse. > > Try it, you'll like it. If you want the nuts and bolts of it, read the > source. > > > ----- Original Message ----- > From: "Dimitar Peikov" > To: > Sent: Thursday, March 07, 2002 3:45 AM > Subject: Swapping performance > > > > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > > don't comment about 'bzero' performance, but when RAM is over, Linux > > is much faster. I have no idea what is the algorithm of swapping but it > > seems that the granularity of swapping pieces is the key or the > > importance of swapping memory blocks of certain task. Ooo I forgot to > > say that the both machines have the same hardware, IBM 300PL, 256 RAM > > and no other tasks running. I had to run these tests to choose the > > fastest platform for building our software indexes, which requires a lot > > of math and memory operations. > > > > --- with bzero --- > > Linux$ time ./malloc_test > > *# > > real 0m37.640s > > user 0m1.370s > > sys 0m2.950s > > Linux$ > > > > FreeBSD$ time ./malloc_test > > *# > > real 0m46.640s > > user 0m2.280s > > sys 0m2.550s > > FreeBSD$ > > > > --- without bzero --- > > Linux$ time ./malloc_test > > *# > > real 0m6.371s > > user 0m0.450s > > sys 0m1.510s > > Linux$ > > > > FreeBSD$ time ./malloc_test > > *# > > real 0m11.571s > > user 0m1.150s > > sys 0m1.830s > > FreeBSD$ > > > > > > > > -- > > Dimitar Peikov > > Programmer Analyst > > Globalization Group > > "We Build e-Business" > > > > RILA Solutions > > 27 Building, Acad.G.Bonchev Str. > > 1113 Sofia, Bulgaria > > > > phone: (+359 2) 9797320 > > phone: (+359 2) 9797300 > > fax: (+359 2) 9733355 > > http://www.rila.com > > > -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 7:30:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by hub.freebsd.org (Postfix) with ESMTP id 4773037B493 for ; Thu, 7 Mar 2002 07:30:22 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g27FUF102065 for ; Thu, 7 Mar 2002 16:30:15 +0100 (CET) Received: from falcon.midgard.homeip.net (h217n1fls20o913.telia.com [212.181.162.217]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id QAA02624 for ; Thu, 7 Mar 2002 16:30:14 +0100 (CET) Received: (qmail 3113 invoked by uid 1001); 7 Mar 2002 15:30:13 -0000 Date: Thu, 7 Mar 2002 16:30:13 +0100 From: Erik Trulsson To: cjp Cc: mitko@rila.bg, freebsd-hackers@freebsd.org Subject: Re: Swapping performance Message-ID: <20020307153012.GA1942@student.uu.se> Mail-Followup-To: cjp , mitko@rila.bg, freebsd-hackers@freebsd.org References: <20020307104518.0f73740b.mitko@rila.bg> <05fe01c1c5e6$6a02e890$2400010a@eight> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05fe01c1c5e6$6a02e890$2400010a@eight> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 09:42:44AM -0500, cjp wrote: > This is a comparison of how fast Linux can do something > STUPID versus how fast a real OS can do something intelligently. Your > test is giving you misleading, and dangerous numbers. Do not go waving them > around until you have actually looked at mallocs behavior on the different > systems. > > Here's why: > > Linux implements a brain dead memory allocation > scheme called memory overcommit. It will let you malloc > as much memory as you want whether it is available as RAM or not > and only bitch when you try to use the memory. Therefore, > Linux malloc is much faster than any reasonable system, since all it is doing is > handing out address space out of unallocated address space, > not keeping track of how much memory there actually is. > > In order to handle the kruft that occurs, there is the out of memory killer, > oom_killer. > Which merrily goes through the list of processes, killing off the low priority > processes > until enough memory is free to satisfy what was most recently used. It's the > loan shark > repayment program, with OOMKiller performing the function of the deliquency > reminder. > > On any of the BSD system, you actually get memory you can use, and all the > overhead > of assuring its existence at the time of allocation. Much more robust, less > prone to abuse. > > Try it, you'll like it. If you want the nuts and bolts of it, read the source. Hate to disappoint you, but FreeBSD also overcommits memory. I believe most (or at least many) other Unix variants (including the other *BSD systems) also do that. Whether overcommit is brain-dead or a clever trick is a question which has been debated several times without any conclusive result. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 7:36:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by hub.freebsd.org (Postfix) with ESMTP id AE64337B4B5 for ; Thu, 7 Mar 2002 07:36:18 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailg.telia.com (8.11.6/8.11.6) with ESMTP id g27FaHq04534 for ; Thu, 7 Mar 2002 16:36:17 +0100 (CET) Received: from falcon.midgard.homeip.net (h217n1fls20o913.telia.com [212.181.162.217]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id QAA07393 for ; Thu, 7 Mar 2002 16:36:16 +0100 (CET) Received: (qmail 4173 invoked by uid 1001); 7 Mar 2002 15:36:15 -0000 Date: Thu, 7 Mar 2002 16:36:15 +0100 From: Erik Trulsson To: Peter Pentchev Cc: mitko@rila.bg, freebsd-hackers@FreeBSD.ORG, gclarkii@vsservices.com Subject: Re: Swapping performance Message-ID: <20020307153615.GB1942@student.uu.se> Mail-Followup-To: Peter Pentchev , mitko@rila.bg, freebsd-hackers@FreeBSD.ORG, gclarkii@vsservices.com References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> <20020307164724.D377@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020307164724.D377@straylight.oblivion.bg> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 04:47:24PM +0200, Peter Pentchev wrote: > On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote: > > On Thu, 7 Mar 2002 14:27:59 +0200 > > Dimitar Peikov wrote: > > > > > On Thu, 7 Mar 2002 04:01:58 -0800 (PST) > > > Julian Elischer wrote: > > > > > > > he said -stable.. > > > > > > > > what are the malloc options on -stable? > > > > > > > > maybe we should make sure that they are null > > > > > > > > ln -s ">" /etc/malloc.conf > > > > (I hope that helps) :) > > > > > > > > > > I've tested it with : > > > > > > cc -O6 -o malloc_test malloc_test.c > > > > That -O6 does not look right from here. Do we support anything over -O2? > > ISTR that -On is exactly the same for -O2 for n > 2; or is this stale info? > Maybe GCC 3.x supports higher optimization levels; still, I don't think > this would make any significant difference. n > 3 actually. The difference between -O2 and -O3 is that -O3 enables inlining of functions. This usually makes the generated code larger, and sometimes faster (and sometimes slower.) FreeBSD does not officially support anything above -O since there have been reports of bad code generated when compiling with -O2 or higher. (The difference in performance between -O and -O2 is usually fairly small anyway so it doesn't matter much.) -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 7:46:16 2002 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 3653837B4AC for ; Thu, 7 Mar 2002 07:45:38 -0800 (PST) Received: from fwd02.sul.t-online.de by mailout04.sul.t-online.com with smtp id 16j055-0000pc-03; Thu, 07 Mar 2002 16:45:23 +0100 Received: from spirit.corecode.ath.cx (320050403952-0001@[80.128.122.16]) by fmrl02.sul.t-online.com with esmtp id 16j04p-0NQjNQC; Thu, 7 Mar 2002 16:45:07 +0100 Received: from elevation.zuhause.stoert.net (elevation.zuhause.stoert.net [192.168.66.46]) by spirit.corecode.ath.cx (8.11.6/8.11.6) with ESMTP id g27FjCc77745; Thu, 7 Mar 2002 16:45:12 +0100 (CET) (envelope-from corecode@corecode.ath.cx) Received: (from corecode@localhost) by elevation.zuhause.stoert.net (8.11.6/8.11.6) id g27Fj3640012; Thu, 7 Mar 2002 16:45:03 +0100 (CET) (envelope-from corecode) Date: Thu, 7 Mar 2002 16:45:00 +0100 From: "Simon 'corecode' Schubert" To: Erik Trulsson Cc: roam@ringlet.net, mitko@rila.bg, freebsd-hackers@FreeBSD.ORG, gclarkii@vsservices.com Subject: Re: Swapping performance Message-Id: <20020307164500.5dd21d16.corecode@corecode.ath.cx> In-Reply-To: <20020307153615.GB1942@student.uu.se> References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> <20020307164724.D377@straylight.oblivion.bg> <20020307153615.GB1942@student.uu.se> X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.sWC1FNHO:W3Y?f" X-Sender: 320050403952-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=.sWC1FNHO:W3Y?f Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 7 Mar 2002 16:36:15 +0100 Erik Trulsson wrote: > > > > I've tested it with : > > > > > > > > cc -O6 -o malloc_test malloc_test.c > > > > > > That -O6 does not look right from here. Do we support anything over -O2? > > > > ISTR that -On is exactly the same for -O2 for n > 2; or is this stale info? > > Maybe GCC 3.x supports higher optimization levels; still, I don't think > > this would make any significant difference. > > n > 3 actually. The difference between -O2 and -O3 is that -O3 enables > inlining of functions. This usually makes the generated code larger, > and sometimes faster (and sometimes slower.) > > FreeBSD does not officially support anything above -O since there have > been reports of bad code generated when compiling with -O2 or higher. to everybody who doesn't believe that: it really generates bad code. i've been having severe problems with my tcp and udp stack lately (on a i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<< generated bad tcp and/or udp checksums (depending on ip). i didn't investigate any further, but believe me: not being able to access some dns servers is a pain in the ass. cheerz corecode -- /"\ http://corecode.ath.cx/ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --=.sWC1FNHO:W3Y?f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE8h4r/r5S+dk6z85oRAqExAJ9RDOG4j8RfeZ5H/y7s5MPc9HgJaQCaAoZ3 /DAvUSN4bc0xGOzvlMnFPB8= =rHGa -----END PGP SIGNATURE----- --=.sWC1FNHO:W3Y?f-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 8:12:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by hub.freebsd.org (Postfix) with ESMTP id 3D72237B402 for ; Thu, 7 Mar 2002 08:12:24 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 7 Mar 2002 16:12:14 +0000 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 16j0Sr-0000iq-00; Thu, 07 Mar 2002 16:09:57 +0000 Date: Thu, 7 Mar 2002 16:09:57 +0000 (GMT) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: freebsd-hackers@freebsd.org Subject: Bug? still looking, yet to knock up small test case. Suggestions solicited. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Something odd seems to be happening; I'd appreciate "look here" suggestions. I suspect mmapped pages aren't being flushed but gawd alone knows why. Situation: vmware2, with a "fake disk", files in the /external FS (/external/vmware1/nt1.*). FBSD-stable. Behaviour's been like this for quite some time (since around 4.3-release, I think) Symptoms: run vmware, launch NT in virtual machine, blah, blah. Suspend the virtual machine. Former behaviour went like this: reports "synchronising disk status" (or imilar) and flushes memory contents to disk. (Irritatingly, one time in 20, this still happens.) Behaviour these days: vmware suspends immediately, and exits normally. However, the contents of the nt1.* files _aren't_ flushed, and stay unflushed for an open-ended period of time (days, weeks). sync(2)s don't make any change on this; umounting the FS will take several minutes as the contents are flushed to disk. fsyncing the appropriate files causes them to be flushed. Shouldn't the file contents be getting written back out within some finite time period? The system's not under tremendous load (it's a desktop workstn most of the time). Note: this doesn't result in ultimately broken behaviour, because those pages are eventually flushed on orderly shutdown. I'm just curious as to why sync(2) isn't forcing this. Cheers, jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk Ceci n'est pas une pipe | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 8:28:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 4837C37B400 for ; Thu, 7 Mar 2002 08:28:19 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g27GSIw01336 for ; Thu, 7 Mar 2002 11:28:18 -0500 (EST) Date: Thu, 7 Mar 2002 11:26:32 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: freebsd-hackers@freebsd.org Subject: A question of VM page ownership Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is there any fundamental reason why a page can not be owned by more than one VM object? If that was the case, the bogus page stuff in vfs_bio.c could be made cleaner IMHO. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 8:43:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 11A7F37B420 for ; Thu, 7 Mar 2002 08:43:00 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id DAAE9AE1FC; Thu, 7 Mar 2002 08:42:59 -0800 (PST) Date: Thu, 7 Mar 2002 08:42:59 -0800 From: Alfred Perlstein To: Jan Grant Cc: freebsd-hackers@freebsd.org Subject: Re: Bug? still looking, yet to knock up small test case. Suggestions solicited. Message-ID: <20020307164259.GE26621@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Jan Grant [020307 08:12] wrote: > Something odd seems to be happening; I'd appreciate "look here" > suggestions. I suspect mmapped pages aren't being flushed but gawd alone > knows why. > > Situation: vmware2, with a "fake disk", files in the /external FS > (/external/vmware1/nt1.*). > > FBSD-stable. Behaviour's been like this for quite some time (since > around 4.3-release, I think) [snip] > Note: this doesn't result in ultimately broken behaviour, because those > pages are eventually flushed on orderly shutdown. I'm just curious as to > why sync(2) isn't forcing this. Afaik this is a "feature" of Linux that the emulator tries to emulate. From what I've _heard_ (not witnessed), Linux doesn't have the syncer flush mmap(2)'d data on a regular basis, so in FreeBSD we emulate this behaviour and you get the behaviour you've been seeing. Since, sync(2) schedules the syncer to sync out the buffers which are marked for ignore by the syncer you don't see anything being done. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 8:44:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 177CE37B41B for ; Thu, 7 Mar 2002 08:44:25 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id EFA79AE22C; Thu, 7 Mar 2002 08:44:24 -0800 (PST) Date: Thu, 7 Mar 2002 08:44:24 -0800 From: Alfred Perlstein To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: A question of VM page ownership Message-ID: <20020307164424.GF26621@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Zhihui Zhang [020307 08:28] wrote: > > Is there any fundamental reason why a page can not be owned by more than > one VM object? If that was the case, the bogus page stuff in vfs_bio.c > could be made cleaner IMHO. There is only enough linkage in the vm page to support it being associated with one object. see src/sys/vm/vm_page.h -Alfred Perlstein [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 Mar 7 8:57:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by hub.freebsd.org (Postfix) with ESMTP id 896BB37B400 for ; Thu, 7 Mar 2002 08:57:16 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 7 Mar 2002 16:57:08 +0000 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 16j1AI-0001i2-00; Thu, 07 Mar 2002 16:54:50 +0000 Date: Thu, 7 Mar 2002 16:54:50 +0000 (GMT) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: Alfred Perlstein Cc: freebsd-hackers@freebsd.org Subject: Re: Bug? still looking, yet to knock up small test case. Suggestions solicited. In-Reply-To: <20020307164259.GE26621@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Alfred Perlstein wrote: > * Jan Grant [020307 08:12] wrote: > > Something odd seems to be happening; I'd appreciate "look here" > > suggestions. I suspect mmapped pages aren't being flushed but gawd alone > > knows why. > > > > Situation: vmware2, with a "fake disk", files in the /external FS > > (/external/vmware1/nt1.*). > > > > FBSD-stable. Behaviour's been like this for quite some time (since > > around 4.3-release, I think) > [snip] > > Note: this doesn't result in ultimately broken behaviour, because those > > pages are eventually flushed on orderly shutdown. I'm just curious as to > > why sync(2) isn't forcing this. > > Afaik this is a "feature" of Linux that the emulator tries to emulate. > > From what I've _heard_ (not witnessed), Linux doesn't have the syncer > flush mmap(2)'d data on a regular basis, so in FreeBSD we emulate this > behaviour and you get the behaviour you've been seeing. > > Since, sync(2) schedules the syncer to sync out the buffers which > are marked for ignore by the syncer you don't see anything being > done. :) Heh, cheers, I'll check that now I know what I'm after. That would explain why I couldn't replicate this using "plain" FBSD though :-) -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk Generalisation is never appropriate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 9:30:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id CEBBF37B400 for ; Thu, 7 Mar 2002 09:29:49 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g27HTdw24970; Thu, 7 Mar 2002 12:29:39 -0500 (EST) Date: Thu, 7 Mar 2002 12:27:53 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Alfred Perlstein Cc: freebsd-hackers@freebsd.org Subject: Re: A question of VM page ownership In-Reply-To: <20020307164424.GF26621@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The mapping between data objects (one-to-one or one-to-many) seem to be the most troublesome stuff to deal with when introducing new data structures. But if there is never the need to lookup an object from a page, then maybe we can use a linkage structure like this: struct vm_page_linkage { TAILQ_ENTRY(vm_page_linkage) pageq; struct vm_page * page; } -Zhihui On Thu, 7 Mar 2002, Alfred Perlstein wrote: > * Zhihui Zhang [020307 08:28] wrote: > > > > Is there any fundamental reason why a page can not be owned by more than > > one VM object? If that was the case, the bogus page stuff in vfs_bio.c > > could be made cleaner IMHO. > > There is only enough linkage in the vm page to support it being associated > with one object. see src/sys/vm/vm_page.h > > -Alfred Perlstein [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 Mar 7 9:37:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d133.as21.nwbl0.wi.voyager.net [169.207.139.199]) by hub.freebsd.org (Postfix) with ESMTP id 9A73D37B417 for ; Thu, 7 Mar 2002 09:37:08 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g27BfcNu002847; Thu, 7 Mar 2002 11:41:38 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g27BfSx3002844; Thu, 7 Mar 2002 11:41:28 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 7 Mar 2002 11:41:28 +0000 (GMT) From: Mike Silbersack To: cjp Cc: mitko@rila.bg, Subject: Re: Swapping performance In-Reply-To: <05fe01c1c5e6$6a02e890$2400010a@eight> Message-ID: <20020307113735.M2778-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, cjp wrote: > In order to handle the kruft that occurs, there is the out of memory killer, > oom_killer. > Which merrily goes through the list of processes, killing off the low priority > processes > until enough memory is free to satisfy what was most recently used. It's the > loan shark > repayment program, with OOMKiller performing the function of the deliquency > reminder. FreeBSD overcommits and has a OOMKiller too. You just haven't noticed it because it's not triggered until you're out of swap space. The one thing that _does_ strike me as odd in this comparison is that Dimitar is using 2.4.17. If that's 2.4.17, I'm surprised that it's working ok, as everyone on the linux-kernel list seems to be applying either the -AA or -rmap patches. Of course, if that's SUSE's 2.4.17, I assume that the -AA patches are already applied. In any case, we can't make any useful comparisons until Dimitar posts the source to his test program. Dimitar, post the source for the test program! Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 9:50:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 0F78C37B429; Thu, 7 Mar 2002 09:50:31 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j22A-0005aJ-00; Thu, 07 Mar 2002 09:50:30 -0800 Message-ID: <3C87A856.E222EDD3@mindspring.com> Date: Thu, 07 Mar 2002 09:50:14 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: Michael Smith , hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks References: <200203070900.g2790Ha04392@mass.dis.org> <3C8730FC.E88F85B4@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > Michael Smith wrote: > > > Please review attached patch, which adds long overdue feature to our > > > loader(8), allowing it to load sequence of files as a single object. > > > > I don't like this. I would much rather see support for 'split' files > > implemented as a stacking filesystem layer like the gzip support, with > > the simple recognition of 'foo.gz.aa' as the first part of a split > > version of 'foo.gz', which in turn is recognised as a compressed version > > of 'foo'. > > I am curious how in this case the layer is going to know how many > parts the file contains? I'm curious how you're going to get the code to execute to do this layering, when it's spread across three floppy images. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 9:59:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from minions.com (adsl-63-192-211-186.dsl.snfc21.pacbell.net [63.192.211.186]) by hub.freebsd.org (Postfix) with ESMTP id D2F3937B404 for ; Thu, 7 Mar 2002 09:59:16 -0800 (PST) Received: from frond (IDENT:bifrost@frond [63.192.211.186]) by minions.com (8.11.6/8.11.6) with ESMTP id g27Hx6t37202; Thu, 7 Mar 2002 09:59:07 -0800 (PST) (envelope-from bifrost@minions.com) Date: Thu, 7 Mar 2002 09:59:06 -0800 (PST) From: Tom To: Dimitar Peikov Cc: cjp , Subject: Re: Swapping performance In-Reply-To: <20020307165851.79f391f3.mitko@rila.bg> Message-ID: <20020307095452.D18855-100000@frond.minions.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > This is a comparison of how fast Linux can do something > > STUPID versus how fast a real OS can do something intelligently. Your > > test is giving you misleading, and dangerous numbers. Do not go waving > > them around until you have actually looked at mallocs behavior on the > > different systems. > > In fact if I have to compute something really important for me (STUPID as > you said) I would choose the fastest OS. But when you lose that data, do you not get burnt by that same situation? I have written a 1GB file to a linux box, and then within 5 seconds of it finishing, yanked the power cord. When I booted it back up, the file was *JUST NOT THERE*, I tried it a few other times, and there were fragments that showed up. Under FreeBSD I tried the same test, The file was there, and it finished faster than Linux did. Why is this? Bad procedure to gain file system speed (from what I can tell). Which would you rather have? Fast Calculations, or the results of your data. Obviously its your choice :) > > Here's why: > > > > Linux implements a brain dead memory allocation > > scheme called memory overcommit. It will let you malloc > > as much memory as you want whether it is available as RAM or not > > and only bitch when you try to use the memory. Therefore, > > Linux malloc is much faster than any reasonable system, since all it is > > doing is handing out address space out of unallocated address space, > > not keeping track of how much memory there actually is. > > > > In order to handle the kruft that occurs, there is the out of memory > > killer, oom_killer. > > Which merrily goes through the list of processes, killing off the low > > priority processes > > until enough memory is free to satisfy what was most recently used. It's > > the loan shark > > repayment program, with OOMKiller performing the function of the > > deliquency reminder. > > > > On any of the BSD system, you actually get memory you can use, and all the > > overhead > > of assuring its existence at the time of allocation. Much more robust, > > less prone to abuse. > > > > Try it, you'll like it. If you want the nuts and bolts of it, read the > > source. > > > > > > ----- Original Message ----- > > From: "Dimitar Peikov" > > To: > > Sent: Thursday, March 07, 2002 3:45 AM > > Subject: Swapping performance > > > > > > > I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I > > > don't comment about 'bzero' performance, but when RAM is over, Linux > > > is much faster. I have no idea what is the algorithm of swapping but it > > > seems that the granularity of swapping pieces is the key or the > > > importance of swapping memory blocks of certain task. Ooo I forgot to > > > say that the both machines have the same hardware, IBM 300PL, 256 RAM > > > and no other tasks running. I had to run these tests to choose the > > > fastest platform for building our software indexes, which requires a lot > > > of math and memory operations. > > > > > > --- with bzero --- > > > Linux$ time ./malloc_test > > > *# > > > real 0m37.640s > > > user 0m1.370s > > > sys 0m2.950s > > > Linux$ > > > > > > FreeBSD$ time ./malloc_test > > > *# > > > real 0m46.640s > > > user 0m2.280s > > > sys 0m2.550s > > > FreeBSD$ > > > > > > --- without bzero --- > > > Linux$ time ./malloc_test > > > *# > > > real 0m6.371s > > > user 0m0.450s > > > sys 0m1.510s > > > Linux$ > > > > > > FreeBSD$ time ./malloc_test > > > *# > > > real 0m11.571s > > > user 0m1.150s > > > sys 0m1.830s > > > FreeBSD$ > > > > > > > > > > > > -- > > > Dimitar Peikov > > > Programmer Analyst > > > Globalization Group > > > "We Build e-Business" > > > > > > RILA Solutions > > > 27 Building, Acad.G.Bonchev Str. > > > 1113 Sofia, Bulgaria > > > > > > phone: (+359 2) 9797320 > > > phone: (+359 2) 9797300 > > > fax: (+359 2) 9733355 > > > http://www.rila.com --- Tom bifrost@minions.com "Where am I and why am I in this handbasket?" Beat up a Spammer today - http://spamhaus.org/ tistom et ha'peh ve tavi li birra... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:10:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d133.as21.nwbl0.wi.voyager.net [169.207.139.199]) by hub.freebsd.org (Postfix) with ESMTP id A9C6337B404 for ; Thu, 7 Mar 2002 10:10:41 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g27CF9Nu002991; Thu, 7 Mar 2002 12:15:09 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g27CF83J002988; Thu, 7 Mar 2002 12:15:09 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 7 Mar 2002 12:15:08 +0000 (GMT) From: Mike Silbersack To: Tom Cc: Dimitar Peikov , cjp , Subject: Re: Swapping performance In-Reply-To: <20020307095452.D18855-100000@frond.minions.com> Message-ID: <20020307120940.E2778-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Tom wrote: > But when you lose that data, do you not get burnt by that same situation? > I have written a 1GB file to a linux box, and then within 5 seconds of it > finishing, yanked the power cord. When I booted it back up, the file was > *JUST NOT THERE*, I tried it a few other times, and there were fragments > that showed up. Under FreeBSD I tried the same test, The file was there, > and it finished faster than Linux did. Why is this? Bad procedure to gain > file system speed (from what I can tell). > > Which would you rather have? Fast Calculations, or the results of your > data. Obviously its your choice :) Please stop posting this crap. Dimitar asked a serious question, and I for one would certainly like to be able to give him a serious answer. Despite what your ranting above would indicate, ext2's performance should have NOTHING to do with swapping performance. Once Dimitar posts his test program, we'll be able to generate a more clear picture about what's really happening. Until then, please control the ranting. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:22:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 71F1337B41B for ; Thu, 7 Mar 2002 10:22:34 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g27IMIV96900 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 7 Mar 2002 13:22:20 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Mar 2002 19:33:10 +0100 To: Mike Silbersack , Tom From: "Rogier R. Mulhuijzen" Subject: Re: Swapping performance Cc: Dimitar Peikov , cjp , In-Reply-To: <20020307120940.E2778-100000@patrocles.silby.com> References: <20020307095452.D18855-100000@frond.minions.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Once Dimitar posts his test program, we'll be able to generate a more >clear picture about what's really happening. Until then, please control >the ranting. Am I the only one who saw that he attached it to his 1st mail? Here you go: #include #include #include #define MALLOC_SIZE 1024*1024*256 int main(int argc, char **argv) { char *ptr; int i, i_count; int j; ptr = (char *) malloc(MALLOC_SIZE); bzero(ptr, MALLOC_SIZE); i_count = MALLOC_SIZE / 16; fprintf(stderr, "*"); for (i = 0; i < i_count; i ++) { ptr[i >> 4] = ptr[(i >> 3) + 1]++; } fprintf(stderr, "#"); for (j = 0; j < i_count; j ++) { ptr[j << 4] = ptr[(j >> 3) + 1]++; } free(ptr); 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 Mar 7 10:39: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 0C35637B416; Thu, 7 Mar 2002 10:38:35 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g27Ic4s01239; Thu, 7 Mar 2002 10:38:04 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203071838.g27Ic4s01239@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Maxim Sobolev Cc: Michael Smith , hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks In-reply-to: Your message of "Thu, 07 Mar 2002 14:17:32 +0200." <3C875A5C.53949862@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 10:38:04 -0800 From: Michael Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > At any rate, my key point is that the splitting should be invisible, and > > *definitely* not pushed up into the loader. > > Ok, sounds reasonably. I'll try to reimplement the feature this way. > > Thank you for suggestion. Thanks for doing the real work! = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:44:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 34E0937B416; Thu, 7 Mar 2002 10:42:00 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j2pr-0000Qi-00; Thu, 07 Mar 2002 10:41:52 -0800 Message-ID: <3C87B45F.3061AABF@mindspring.com> Date: Thu, 07 Mar 2002 10:41:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Bill Fumerola , net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times References: Content-Type: multipart/mixed; boundary="------------87879C4452F25813094EB958" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------87879C4452F25813094EB958 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Elischer wrote: > what would be even nicer is if ipfw found the cached entry and passed it > back to ip_input so it didn't need to :-) This is the approach I intended. The problem is that there are cases where you want the inpcb for additional processing (e.g. ipfw), and cases where there is no additioanl processing. Just because you have IP traffic doesn't mean you have an inpcb requirement. In addition, there are two lookup cases that are meaningful to the upper layers of the code (wildcard and non-wildcard); both of these are constrained to the source/source port and dest/dest port. The ipfw code actually does a number of lookups based on both input and output processing. Fixing up the input processing is rather easy (if tedious). The output processing is much harder to do anything but cache. NB: Is there a particular reason Bill's changes haven't simply been committed? In any case, I have a rough set of patches that adds a parameter for the cached inpcb, and passes a pointer to the pointer to the ipfw_chk() that it can fill out, and that will be passed to the upper level protocol processing, if it's filled out. I say "rough" here because I've not included the IPv6 code; don't worry: everything still works, but the IPv6 code seems to use varradic functions as initializers for the protosw in some cases, and seems to be broken in a couple of other places, and I wasn't going to go through and fix it without the IPv6 people being involved. The if_gif code is a particular abomination. 8-(. I also only do the tcp_input() and udp_input() path, and leave the ctlinput path for both for someone else (the parameter is there, I just don't check it before the lookup, which is trivial to do... see tcp_input). A clever eye will note that the lookup in the ip_fw code is non-wildcard, and the lookup in the tcp_input is wildcard. This works because the tcp_input call to in_pcblookup_hash wildcard case matches in both the wildcard and the non-wildcard case. The wildcard case is handled by doing a wildcard lookup if the cached value is NULL. This makes the code work in all cases, including the case where the ipfw code is not enabled (it just falls back to the old behaviour). Actually, I'm not sure that the non-wildcard lookup in the ipfw case is correct. It seems to me that you could use this to do filter avoidance on initial packets (e.g. T/TCP or data piggyback on the ACK for an outbound connection setup). Anyway, patches in unidiff format (that Julian likes) against -stable as of yesterday's CVSup are attached (about 20k). I'd like to see Bill F's stuff rolled in, too... obviously. -- Terry --------------87879C4452F25813094EB958 Content-Type: text/plain; charset=us-ascii; name="inp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="inp.patch" Index: net/bridge.c =================================================================== RCS file: /usr/cvs/src/sys/net/bridge.c,v retrieving revision 1.16.2.17 diff -u -r1.16.2.17 bridge.c --- net/bridge.c 24 Nov 2001 01:48:21 -0000 1.16.2.17 +++ net/bridge.c 7 Mar 2002 18:22:36 -0000 @@ -767,7 +767,8 @@ * The firewall knows this is a bridged packet as the cookie ptr * is NULL. */ - i = ip_fw_chk_ptr(&ip, 0, NULL, NULL /* cookie */, &m0, &rule, NULL); + i = ip_fw_chk_ptr(&ip, 0, NULL, NULL /* cookie */, &m0, &rule, + NULL, NULL); if ( (i & IP_FW_PORT_DENY_FLAG) || m0 == NULL) /* drop */ return m0 ; /* Index: netinet/igmp.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/igmp.c,v retrieving revision 1.29.2.1 diff -u -r1.29.2.1 igmp.c --- netinet/igmp.c 17 Sep 2001 15:17:46 -0000 1.29.2.1 +++ netinet/igmp.c 7 Mar 2002 07:23:22 -0000 @@ -146,9 +146,10 @@ } void -igmp_input(m, off, proto) +igmp_input(m, off, proto, vimp) register struct mbuf *m; int off, proto; + void *vimp; { register int iphlen = off; register struct igmp *igmp; @@ -336,7 +337,7 @@ * Pass all valid IGMP packets up to any process(es) listening * on a raw IGMP socket. */ - rip_input(m, off, proto); + rip_input(m, off, proto, vimp); } void Index: netinet/igmp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/igmp_var.h,v retrieving revision 1.17 diff -u -r1.17 igmp_var.h --- netinet/igmp_var.h 29 Dec 1999 04:40:59 -0000 1.17 +++ netinet/igmp_var.h 7 Mar 2002 07:23:46 -0000 @@ -86,7 +86,7 @@ #define IGMP_AGE_THRESHOLD 540 void igmp_init __P((void)); -void igmp_input __P((struct mbuf *, int, int)); +void igmp_input __P((struct mbuf *, int, int, void *)); void igmp_joingroup __P((struct in_multi *)); void igmp_leavegroup __P((struct in_multi *)); void igmp_fasttimo __P((void)); Index: netinet/in_gif.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/in_gif.c,v retrieving revision 1.5.2.5 diff -u -r1.5.2.5 in_gif.c --- netinet/in_gif.c 24 Jul 2001 19:10:18 -0000 1.5.2.5 +++ netinet/in_gif.c 7 Mar 2002 07:34:19 -0000 @@ -202,10 +202,11 @@ } void -in_gif_input(m, off, proto) +in_gif_input(m, off, proto, vinp) struct mbuf *m; int off; int proto; + void *vinp; { struct ifnet *gifp = NULL; struct ip *ip; Index: netinet/in_gif.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/in_gif.h,v retrieving revision 1.3.2.2 diff -u -r1.3.2.2 in_gif.h --- netinet/in_gif.h 24 Jul 2001 19:10:18 -0000 1.3.2.2 +++ netinet/in_gif.h 7 Mar 2002 07:34:41 -0000 @@ -37,7 +37,7 @@ extern int ip_gif_ttl; -void in_gif_input __P((struct mbuf *, int off, int proto)); +void in_gif_input __P((struct mbuf *, int off, int proto, void *)); int in_gif_output __P((struct ifnet *, int, struct mbuf *, struct rtentry *)); int gif_encapcheck4 __P((const struct mbuf *, int, int, void *)); Index: netinet/ip_divert.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_divert.c,v retrieving revision 1.42.2.4 diff -u -r1.42.2.4 ip_divert.c --- netinet/ip_divert.c 29 Jul 2001 19:32:40 -0000 1.42.2.4 +++ netinet/ip_divert.c 7 Mar 2002 07:44:31 -0000 @@ -129,7 +129,7 @@ * with that protocol number to enter the system from the outside. */ void -div_input(struct mbuf *m, int off, int proto) +div_input(struct mbuf *m, int off, int proto, void *vinp) { ipstat.ips_noproto++; m_freem(m); Index: netinet/ip_encap.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_encap.c,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 ip_encap.c --- netinet/ip_encap.c 3 Jul 2001 11:01:46 -0000 1.1.2.2 +++ netinet/ip_encap.c 7 Mar 2002 17:59:44 -0000 @@ -211,7 +211,7 @@ psw = (const struct ipprotosw *)match->psw; if (psw && psw->pr_input) { encap_fillarg(m, match); - (*psw->pr_input)(m, off, proto); + (*psw->pr_input)(m, off, proto, NULL); } else m_freem(m); return; @@ -230,16 +230,17 @@ #endif /* last resort: inject to raw socket */ - rip_input(m, off, proto); + rip_input(m, off, proto, NULL); } #endif #ifdef INET6 int -encap6_input(mp, offp, proto) +encap6_input(mp, offp, proto, vinp) struct mbuf **mp; int *offp; int proto; + void *vinp; { struct mbuf *m = *mp; struct ip6_hdr *ip6; Index: netinet/ip_encap.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_encap.h,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 ip_encap.h --- netinet/ip_encap.h 15 Jul 2000 07:14:30 -0000 1.1.2.1 +++ netinet/ip_encap.h 7 Mar 2002 07:41:34 -0000 @@ -50,7 +50,7 @@ void encap_init __P((void)); void encap4_input __P((struct mbuf *, ...)); -int encap6_input __P((struct mbuf **, int *, int)); +int encap6_input __P((struct mbuf **, int *, int, void *)); const struct encaptab *encap_attach __P((int, int, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, const struct protosw *, void *)); Index: netinet/ip_fw.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.131.2.30 diff -u -r1.131.2.30 ip_fw.c --- netinet/ip_fw.c 7 Jan 2002 22:40:22 -0000 1.131.2.30 +++ netinet/ip_fw.c 7 Mar 2002 18:27:30 -0000 @@ -227,7 +227,7 @@ static int ip_fw_chk (struct ip **pip, int hlen, struct ifnet *oif, u_int16_t *cookie, struct mbuf **m, struct ip_fw **flow_id, - struct sockaddr_in **next_hop); + struct sockaddr_in **next_hop, struct inpcb **inpp); static int ip_fw_ctl (struct sockopt *sopt); ip_dn_ruledel_t *ip_dn_ruledel_ptr = NULL; @@ -1059,7 +1059,7 @@ ip_fw_chk(struct ip **pip, int hlen, struct ifnet *oif, u_int16_t *cookie, struct mbuf **m, struct ip_fw **flow_id, - struct sockaddr_in **next_hop) + struct sockaddr_in **next_hop, struct inpcb **inpp) { struct ip_fw *f = NULL; /* matching rule */ struct ip *ip = *pip; @@ -1298,10 +1298,13 @@ P = in_pcblookup_hash(&tcbinfo, dst_ip, dst_port, src_ip, src_port, 0, oif); - else + else { P = in_pcblookup_hash(&tcbinfo, src_ip, src_port, dst_ip, dst_port, 0, NULL); + if( inpp) + *inpp = P; + } if (P && P->inp_socket) { if (f->fw_flg & IP_FW_F_UID) { @@ -1327,10 +1330,13 @@ P = in_pcblookup_hash(&udbinfo, dst_ip, dst_port, src_ip, src_port, 1, oif); - else + else { P = in_pcblookup_hash(&udbinfo, src_ip, src_port, dst_ip, dst_port, 1, NULL); + if( inpp) + *inpp = P; + } if (P && P->inp_socket) { if (f->fw_flg & IP_FW_F_UID) { Index: netinet/ip_fw.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.47.2.10 diff -u -r1.47.2.10 ip_fw.h --- netinet/ip_fw.h 3 Nov 2001 00:36:09 -0000 1.47.2.10 +++ netinet/ip_fw.h 7 Mar 2002 18:15:01 -0000 @@ -335,7 +335,7 @@ struct ip; struct sockopt; typedef int ip_fw_chk_t (struct ip **, int, struct ifnet *, u_int16_t *, - struct mbuf **, struct ip_fw **, struct sockaddr_in **); + struct mbuf **, struct ip_fw **, struct sockaddr_in **, struct inpcb **); typedef int ip_fw_ctl_t (struct sockopt *); extern ip_fw_chk_t *ip_fw_chk_ptr; extern ip_fw_ctl_t *ip_fw_ctl_ptr; Index: netinet/ip_icmp.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.39.2.14 diff -u -r1.39.2.14 ip_icmp.c --- netinet/ip_icmp.c 14 Jan 2002 07:54:35 -0000 1.39.2.14 +++ netinet/ip_icmp.c 7 Mar 2002 07:25:59 -0000 @@ -237,9 +237,10 @@ * Process a received ICMP message. */ void -icmp_input(m, off, proto) +icmp_input(m, off, proto, vinp) register struct mbuf *m; int off, proto; + void *vinp; { int hlen = off; register struct icmp *icp; @@ -584,7 +585,7 @@ } raw: - rip_input(m, off, proto); + rip_input(m, off, proto, vinp); return; freeit: Index: netinet/ip_icmp.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_icmp.h,v retrieving revision 1.16 diff -u -r1.16 ip_icmp.h --- netinet/ip_icmp.h 29 Dec 1999 04:41:01 -0000 1.16 +++ netinet/ip_icmp.h 7 Mar 2002 07:26:21 -0000 @@ -186,7 +186,7 @@ #ifdef _KERNEL void icmp_error __P((struct mbuf *, int, int, n_long, struct ifnet *)); -void icmp_input __P((struct mbuf *, int, int)); +void icmp_input __P((struct mbuf *, int, int, void *)); #endif #endif Index: netinet/ip_input.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_input.c,v retrieving revision 1.130.2.31 diff -u -r1.130.2.31 ip_input.c --- netinet/ip_input.c 15 Dec 2001 01:06:27 -0000 1.130.2.31 +++ netinet/ip_input.c 7 Mar 2002 18:09:49 -0000 @@ -282,6 +282,7 @@ u_int32_t divert_info = 0; /* packet divert/tee info */ #endif struct ip_fw *rule = NULL; + struct inpcb *inp = NULL; /* pre-cache inpcb, if any */ #ifdef IPDIVERT /* Get and reset firewall cookie */ @@ -434,7 +435,8 @@ * produced by the firewall. */ i = ip_fw_chk_ptr(&ip, - hlen, NULL, &divert_cookie, &m, &rule, &ip_fw_fwd_addr); + hlen, NULL, &divert_cookie, &m, &rule, &ip_fw_fwd_addr, + &inp); if ( (i & IP_FW_PORT_DENY_FLAG) || m == NULL) { /* drop */ if (m) m_freem(m); @@ -812,7 +814,7 @@ { int off = hlen, nh = ip->ip_p; - (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off, nh); + (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off, nh, inp); #ifdef IPFIREWALL_FORWARD ip_fw_fwd_addr = NULL; /* tcp needed it */ #endif Index: netinet/ip_mroute.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.56.2.3 diff -u -r1.56.2.3 ip_mroute.c --- netinet/ip_mroute.c 7 Dec 2001 09:23:11 -0000 1.56.2.3 +++ netinet/ip_mroute.c 7 Mar 2002 07:32:49 -0000 @@ -118,10 +118,11 @@ int (*mrt_ioctl)(int, caddr_t, struct proc *) = _mrt_ioctl; void -rsvp_input(m, off, proto) /* XXX must fixup manually */ +rsvp_input(m, off, proto, vinp) /* XXX must fixup manually */ struct mbuf *m; int off; int proto; + void *vinp; { /* Can still get packets with rsvp_on = 0 if there is a local member * of the group to which the RSVP packet is addressed. But in this @@ -135,15 +136,17 @@ if (ip_rsvpd != NULL) { if (rsvpdebug) printf("rsvp_input: Sending packet up old-style socket\n"); - rip_input(m, off, proto); + rip_input(m, off, proto, vinp); return; } /* Drop the packet */ m_freem(m); } -void ipip_input(struct mbuf *m, int off, int proto) { /* XXX must fixup manually */ - rip_input(m, off, proto); +/* XXX must fixup manually */ +void ipip_input(struct mbuf *m, int off, int proto, void *vinp) +{ + rip_input(m, off, proto, vinp); } int (*legal_vif_num)(int) = 0; @@ -1615,13 +1618,14 @@ */ void #ifdef MROUTE_LKM -X_ipip_input(m, off, proto) +X_ipip_input(m, off, proto, vinp) #else -ipip_input(m, off, proto) +ipip_input(m, off, proto, vinp) #endif register struct mbuf *m; int off; int proto; + void *vinp; { struct ifnet *ifp = m->m_pkthdr.rcvif; register struct ip *ip = mtod(m, struct ip *); @@ -1631,7 +1635,7 @@ register struct vif *vifp; if (!have_encap_tunnel) { - rip_input(m, off, proto); + rip_input(m, off, proto, vinp); return; } /* @@ -2125,10 +2129,11 @@ } void -rsvp_input(m, off, proto) +rsvp_input(m, off, proto, vinp) struct mbuf *m; int off; int proto; + void *vinp; { int vifi; register struct ip *ip = mtod(m, struct ip *); @@ -2173,7 +2178,7 @@ if (ip_rsvpd != NULL) { if (rsvpdebug) printf("rsvp_input: Sending packet up old-style socket\n"); - rip_input(m, off, proto); /* xxx */ + rip_input(m, off, proto, vinp); /* xxx */ } else { if (rsvpdebug && vifi == numvifs) printf("rsvp_input: Can't find vif for packet.\n"); Index: netinet/ip_output.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_output.c,v retrieving revision 1.99.2.24 diff -u -r1.99.2.24 ip_output.c --- netinet/ip_output.c 28 Dec 2001 10:08:33 -0000 1.99.2.24 +++ netinet/ip_output.c 7 Mar 2002 18:15:33 -0000 @@ -577,7 +577,7 @@ struct sockaddr_in *old = dst; off = ip_fw_chk_ptr(&ip, - hlen, ifp, &divert_cookie, &m, &rule, &dst); + hlen, ifp, &divert_cookie, &m, &rule, &dst, NULL); /* * On return we must do the following: * IP_FW_PORT_DENY_FLAG -> drop the pkt (XXX new) Index: netinet/ip_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ip_var.h,v retrieving revision 1.50.2.5 diff -u -r1.50.2.5 ip_var.h --- netinet/ip_var.h 7 Dec 2001 09:23:14 -0000 1.50.2.5 +++ netinet/ip_var.h 7 Mar 2002 07:45:04 -0000 @@ -176,12 +176,12 @@ ip_randomid __P((void)); #endif int rip_ctloutput __P((struct socket *, struct sockopt *)); -void rip_ctlinput __P((int, struct sockaddr *, void *)); +void rip_ctlinput __P((int, struct sockaddr *, void *, void *)); void rip_init __P((void)); -void rip_input __P((struct mbuf *, int, int)); +void rip_input __P((struct mbuf *, int, int, void *)); int rip_output __P((struct mbuf *, struct socket *, u_long)); -void ipip_input __P((struct mbuf *, int, int)); -void rsvp_input __P((struct mbuf *, int, int)); +void ipip_input __P((struct mbuf *, int, int, void *)); +void rsvp_input __P((struct mbuf *, int, int, void *)); int ip_rsvp_init __P((struct socket *)); int ip_rsvp_done __P((void)); int ip_rsvp_vif_init __P((struct socket *, struct sockopt *)); @@ -190,7 +190,7 @@ #ifdef IPDIVERT void div_init __P((void)); -void div_input __P((struct mbuf *, int, int)); +void div_input __P((struct mbuf *, int, int, void *)); void divert_packet __P((struct mbuf *, int, int)); extern struct pr_usrreqs div_usrreqs; extern u_int16_t ip_divert_cookie; Index: netinet/ipprotosw.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/ipprotosw.h,v retrieving revision 1.1 diff -u -r1.1 ipprotosw.h --- netinet/ipprotosw.h 22 Dec 1999 19:13:23 -0000 1.1 +++ netinet/ipprotosw.h 7 Mar 2002 04:31:56 -0000 @@ -79,11 +79,11 @@ short pr_protocol; /* protocol number */ short pr_flags; /* see below */ /* protocol-protocol hooks */ - void (*pr_input) __P((struct mbuf *, int off, int proto)); + void (*pr_input) __P((struct mbuf *, int off, int proto, void *)); /* input to protocol (from below) */ int (*pr_output) __P((struct mbuf *m, struct socket *so)); /* output to protocol (from above) */ - void (*pr_ctlinput)__P((int, struct sockaddr *, void *)); + void (*pr_ctlinput)__P((int, struct sockaddr *, void *, void *)); /* control input (from below) */ int (*pr_ctloutput)__P((struct socket *, struct sockopt *)); /* control output (from above) */ Index: netinet/raw_ip.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.64.2.10 diff -u -r1.64.2.10 raw_ip.c --- netinet/raw_ip.c 26 Nov 2001 10:07:57 -0000 1.64.2.10 +++ netinet/raw_ip.c 7 Mar 2002 07:32:20 -0000 @@ -113,9 +113,10 @@ * mbuf chain. */ void -rip_input(m, off, proto) +rip_input(m, off, proto, vimp) struct mbuf *m; int off, proto; + void *vimp; { register struct ip *ip = mtod(m, struct ip *); register struct inpcb *inp; @@ -396,10 +397,11 @@ * interface routes. */ void -rip_ctlinput(cmd, sa, vip) +rip_ctlinput(cmd, sa, vip, vinp) int cmd; struct sockaddr *sa; void *vip; + void *vinp; { struct in_ifaddr *ia; struct ifnet *ifp; Index: netinet/tcp_input.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.107.2.20 diff -u -r1.107.2.20 tcp_input.c --- netinet/tcp_input.c 14 Dec 2001 20:21:12 -0000 1.107.2.20 +++ netinet/tcp_input.c 7 Mar 2002 18:34:55 -0000 @@ -321,15 +321,16 @@ return IPPROTO_DONE; } - tcp_input(m, *offp, proto); + tcp_input(m, *offp, proto, NULL); return IPPROTO_DONE; } #endif void -tcp_input(m, off0, proto) +tcp_input(m, off0, proto, vinp) register struct mbuf *m; int off0, proto; + void *vinp; { register struct tcphdr *th; register struct ip *ip = NULL; @@ -544,8 +545,11 @@ m->m_pkthdr.rcvif); else #endif /* INET6 */ - inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, - ip->ip_dst, th->th_dport, 1, m->m_pkthdr.rcvif); + if( vinp != NULL) + inp = vinp; /* use cached value */ + else + inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, + ip->ip_dst, th->th_dport, 1, m->m_pkthdr.rcvif); } #ifdef IPSEC Index: netinet/tcp_subr.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.73.2.23 diff -u -r1.73.2.23 tcp_subr.c --- netinet/tcp_subr.c 14 Dec 2001 20:21:12 -0000 1.73.2.23 +++ netinet/tcp_subr.c 7 Mar 2002 05:05:03 -0000 @@ -972,10 +972,11 @@ void -tcp_ctlinput(cmd, sa, vip) +tcp_ctlinput(cmd, sa, vip, vinp) int cmd; struct sockaddr *sa; void *vip; + void *vinp; { struct ip *ip = vip; struct tcphdr *th; Index: netinet/tcp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.56.2.10 diff -u -r1.56.2.10 tcp_var.h --- netinet/tcp_var.h 14 Dec 2001 20:21:12 -0000 1.56.2.10 +++ netinet/tcp_var.h 7 Mar 2002 05:17:04 -0000 @@ -437,7 +437,7 @@ void tcp_canceltimers __P((struct tcpcb *)); struct tcpcb * tcp_close __P((struct tcpcb *)); -void tcp_ctlinput __P((int, struct sockaddr *, void *)); +void tcp_ctlinput __P((int, struct sockaddr *, void *, void *)); int tcp_ctloutput __P((struct socket *, struct sockopt *)); struct tcpcb * tcp_drop __P((struct tcpcb *, int)); @@ -446,7 +446,7 @@ struct rmxp_tao * tcp_gettaocache __P((struct in_conninfo *)); void tcp_init __P((void)); -void tcp_input __P((struct mbuf *, int, int)); +void tcp_input __P((struct mbuf *, int, int, void *)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); void tcp_drop_syn_sent __P((struct inpcb *, int)); Index: netinet/udp_usrreq.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.64.2.15 diff -u -r1.64.2.15 udp_usrreq.c --- netinet/udp_usrreq.c 29 Oct 2001 19:28:43 -0000 1.64.2.15 +++ netinet/udp_usrreq.c 7 Mar 2002 18:35:08 -0000 @@ -148,9 +148,10 @@ } void -udp_input(m, off, proto) +udp_input(m, off, proto, vinp) register struct mbuf *m; int off, proto; + void *vinp; { int iphlen = off; register struct ip *ip; @@ -339,8 +340,11 @@ /* * Locate pcb for datagram. */ - inp = in_pcblookup_hash(&udbinfo, ip->ip_src, uh->uh_sport, - ip->ip_dst, uh->uh_dport, 1, m->m_pkthdr.rcvif); + if (vinp != NULL) + inp = vinp; /* use cached value */ + else + inp = in_pcblookup_hash(&udbinfo, ip->ip_src, uh->uh_sport, + ip->ip_dst, uh->uh_dport, 1, m->m_pkthdr.rcvif); if (inp == NULL) { if (log_in_vain) { char buf[4*sizeof "123"]; @@ -502,10 +506,11 @@ } void -udp_ctlinput(cmd, sa, vip) +udp_ctlinput(cmd, sa, vip, vinp) int cmd; struct sockaddr *sa; void *vip; + void *vinp; { struct ip *ip = vip; struct udphdr *uh; Index: netinet/udp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/udp_var.h,v retrieving revision 1.22.2.1 diff -u -r1.22.2.1 udp_var.h --- netinet/udp_var.h 18 Feb 2001 07:12:25 -0000 1.22.2.1 +++ netinet/udp_var.h 7 Mar 2002 05:17:48 -0000 @@ -103,9 +103,9 @@ extern struct udpstat udpstat; extern int log_in_vain; -void udp_ctlinput __P((int, struct sockaddr *, void *)); +void udp_ctlinput __P((int, struct sockaddr *, void *, void *)); void udp_init __P((void)); -void udp_input __P((struct mbuf *, int, int)); +void udp_input __P((struct mbuf *, int, int, void *)); void udp_notify __P((struct inpcb *inp, int errno)); int udp_shutdown __P((struct socket *so)); --------------87879C4452F25813094EB958-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:46:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d133.as21.nwbl0.wi.voyager.net [169.207.139.199]) by hub.freebsd.org (Postfix) with ESMTP id 142A637B400 for ; Thu, 7 Mar 2002 10:46:16 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g27CoaNu003137; Thu, 7 Mar 2002 12:50:36 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g27CoYVp003132; Thu, 7 Mar 2002 12:50:36 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 7 Mar 2002 12:50:34 +0000 (GMT) From: Mike Silbersack To: "Rogier R. Mulhuijzen" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance In-Reply-To: <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> Message-ID: <20020307125002.G2778-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Rogier R. Mulhuijzen wrote: > > >Once Dimitar posts his test program, we'll be able to generate a more > >clear picture about what's really happening. Until then, please control > >the ranting. > > Am I the only one who saw that he attached it to his 1st mail? Apparently not, I just got bitchslapped by a bunch of other people. :) /me goes off to look at the program. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:46:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 11A1D37B404 for ; Thu, 7 Mar 2002 10:46:28 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g27Ik9A61208; Thu, 7 Mar 2002 10:46:09 -0800 (PST) (envelope-from obrien) Date: Thu, 7 Mar 2002 10:42:05 -0800 From: "David O'Brien" To: Dimitar Peikov Cc: GB Clark , mitko@rila.bg, freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance Message-ID: <20020307104205.C61088@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020307080906.367be8df.gclarkii@vsservices.com>; from gclarkii@vsservices.com on Thu, Mar 07, 2002 at 08:09:06AM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote: > > I've tested it with : > > > > cc -O6 -o malloc_test malloc_test.c > > That -O6 does not look right from here. Do we support anything over -O2? > > And how about some source for malloc_test.c? The fact of running > something at -O6 started some bells ringing. Not us, but GCC does not support anything over -O3. -O4 and above are treated as -O3. I *really* wish people would have a clue with with in the hell they think they are achieving with -O. Not all optimizations are appropriate in all cases. And given this level of optimization and the fact that the linux box is probably a different version of GCC, I wonder how much of this could be due to the compiler. Please rerun your tests with '/usr/bin/time -l' on FreeBSD and however you achieve the same on Linux. P.S. are you sure you are swapping, vs. paging? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:49:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 1A4D237B404; Thu, 7 Mar 2002 10:49:15 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g27Imgs01327; Thu, 7 Mar 2002 10:48:42 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203071848.g27Imgs01327@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Maxim Sobolev , Michael Smith , hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks In-reply-to: Your message of "Thu, 07 Mar 2002 09:50:14 PST." <3C87A856.E222EDD3@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 10:48:42 -0800 From: Michael Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > I don't like this. I would much rather see support for 'split' files > > > implemented as a stacking filesystem layer like the gzip support, with > > > the simple recognition of 'foo.gz.aa' as the first part of a split > > > version of 'foo.gz', which in turn is recognised as a compressed version > > > of 'foo'. > > > > I am curious how in this case the layer is going to know how many > > parts the file contains? > > I'm curious how you're going to get the code to execute > to do this layering, when it's spread across three floppy > images. I'm curious to know what you think you're doing getting into yet another discussion about something you don't understand. Which is about the best answer I can offer to your question, since it's otherwise a non sequiter. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:50:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 1CC8837B417 for ; Thu, 7 Mar 2002 10:50:49 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j2xO-0004jS-00; Thu, 07 Mar 2002 10:49:39 -0800 Message-ID: <3C87B632.43156193@mindspring.com> Date: Thu, 07 Mar 2002 10:49:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon 'corecode' Schubert Cc: Erik Trulsson , roam@ringlet.net, mitko@rila.bg, freebsd-hackers@FreeBSD.ORG, gclarkii@vsservices.com Subject: Re: Swapping performance References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> <20020307164724.D377@straylight.oblivion.bg> <20020307153615.GB1942@student.uu.se> <20020307164500.5dd21d16.corecode@corecode.ath.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Simon 'corecode' Schubert wrote: > to everybody who doesn't believe that: it really generates bad code. > i've been having severe problems with my tcp and udp stack lately (on a > i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<< > generated bad tcp and/or udp checksums (depending on ip). i didn't > investigate any further, but believe me: not being able to access some > dns servers is a pain in the ass. Are you using NAT? The libalias incremental checksum calculation is incorrect; it assumes that a two's complement network order underflow will result in the same value as a one's complement host order underflow. This results in off-by-one errors. This is actually a *different* problem than the RFC 1624 correction of RFC 1141 (also an off-by-one error). Have you used a recent version of ethereal? It's an incredible bugger to get installed correctly for 4.5 or above, since you have to come from packages (the dependencies for the ports are incorrect), but it will tell you the correct checksum vs. the one that it got. There's also printing it out in tcp_input when you get a bad checksum. If you see a lot of "0xfffe", then you'll know it's an off-by-one error. If the problem is only on ACK packets... I can tell you that the tcp_respond() code path is not really throughly exercised. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:53:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id A1ABF37B43E for ; Thu, 7 Mar 2002 10:51:45 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g27Ipdl61288; Thu, 7 Mar 2002 10:51:39 -0800 (PST) (envelope-from obrien) Date: Thu, 7 Mar 2002 10:47:35 -0800 From: "David O'Brien" To: Mike Silbersack Cc: freebsd-hackers@freebsd.org Subject: Re: Swapping performance Message-ID: <20020307104735.D61088@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <05fe01c1c5e6$6a02e890$2400010a@eight> <20020307113735.M2778-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020307113735.M2778-100000@patrocles.silby.com>; from silby@silby.com on Thu, Mar 07, 2002 at 11:41:28AM +0000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 11:41:28AM +0000, Mike Silbersack wrote: > In any case, we can't make any useful comparisons until Dimitar posts the > source to his test program. > > Dimitar, post the source for the test program! Does your MTA strip attachments? -> I 1 [text/plain, 7bit, US-ASCII, 1.2K] A 2 malloc_test.c [applica/octet-stre, base64, 0.7K] [-- Attachment #1 --] [-- Type: text/plain, Encoding: 7bit, Size: 1.2K --] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit [-- Attachment #2: malloc_test.c --] [-- Type: application/octet-stream, Encoding: base64, Size: 0.7K --] Content-Type: application/octet-stream; name="malloc_test.c" Content-Disposition: attachment; filename="malloc_test.c" Content-Transfer-Encoding: base64 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:53:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 4DE5837B400 for ; Thu, 7 Mar 2002 10:52:56 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j30X-00027u-00; Thu, 07 Mar 2002 10:52:54 -0800 Message-ID: <3C87B6F6.C56CC50C@mindspring.com> Date: Thu, 07 Mar 2002 10:52:38 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: A question of VM page ownership References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Zhihui Zhang wrote: > Is there any fundamental reason why a page can not be owned by more than > one VM object? If that was the case, the bogus page stuff in vfs_bio.c > could be made cleaner IMHO. When you need to reclaim the page, you would have to identify all owners, rather than a single owner. THis converts the lookup fron an O(1) to an O(N) problem. Keeping a linked list of owners doesn't really help, either, since it introduces locking issues that will cause -current to blow chunks. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:54:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 40F4B37B4A7 for ; Thu, 7 Mar 2002 10:53:54 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g27IrIs01371; Thu, 7 Mar 2002 10:53:19 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203071853.g27IrIs01371@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Valery N. Khromov" Cc: freebsd-hackers@freebsd.org Subject: Re: Converting physical into virtual address In-reply-to: Your message of "Mon, 04 Mar 2002 11:28:35 +0300." <009c01c1c356$93e13be0$c80ca8c0@khromovv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 10:53:18 -0800 From: Michael Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I'd like to develop a kernel module for FreeBSD, able to read & write > directly to VGA text-mode screen buffer. I know that this buffer is located > at 0xB8000 in physical address space. But in kernel I must address it using > kernel virtual address space. > > Thus, the question is: how can I _correctly_ convert physical address into > kernel virtual address? You don't. > Now I use the following trick: 0xC0000000 + 0xB8000, but I want to use more > correct method. :) The memory at 0xb8000 is owned by the VGA driver. Depending on what your module wants to do, you can either become a client of the driver (using eg. the screensaver interface) or you can look over its' shoulder and steal its' mapping yourself. There's a good chance you don't actually want/need to be in the kernel in the first place, and if that's so, you can access video memory from userspace (see the VGL library for examples). If you're trying to completely replace the VGA driver, then you will want to look at how it handles creating and then allocating resources for video memory. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 10:55:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 17C5337B400 for ; Thu, 7 Mar 2002 10:55:45 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g27Ith468535; Thu, 7 Mar 2002 10:55:43 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Mar 2002 10:55:43 -0800 (PST) From: Matthew Dillon Message-Id: <200203071855.g27Ith468535@apollo.backplane.com> To: Tom Cc: Dimitar Peikov , cjp , Subject: Re: Swapping performance References: <20020307095452.D18855-100000@frond.minions.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :... :> > This is a comparison of how fast Linux can do something :> > STUPID versus how fast a real OS can do something intelligently. Your :> > test is giving you misleading, and dangerous numbers. Do not go waving :> > them around until you have actually looked at mallocs behavior on the :> > different systems. :> :> In fact if I have to compute something really important for me (STUPID as :> you said) I would choose the fastest OS. : :But when you lose that data, do you not get burnt by that same situation? :I have written a 1GB file to a linux box, and then within 5 seconds of it :finishing, yanked the power cord. When I booted it back up, the file was :*JUST NOT THERE*, I tried it a few other times, and there were fragments :that showed up. Under FreeBSD I tried the same test, The file was there, :and it finished faster than Linux did. Why is this? Bad procedure to gain :file system speed (from what I can tell). : :Which would you rather have? Fast Calculations, or the results of your :data. Obviously its your choice :) :... :--- :Tom bifrost@minions.com Well, even under FreeBSD yanking the plug can lead to the just-written file being lost. It depends what filesystem options you use. And yanking the plug would also be dangerous if the hard disk were doing a write operation at the time of the yank no matter the OS. Then you'd lose some sectors (or even an entire track, or multiple tracks depending the drive manufacturer). The only reason this particular test worked for you is probably because you were writing the file out sequentially and FreeBSD does clustered write-behind and file-cache-invalidate-behind when a file is being written out sequentially. But this is just one particular feature under the specified conditions so you can't really use it to justify a general comparison. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11: 1:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 85AD737B422 for ; Thu, 7 Mar 2002 11:00:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307190012.LHEK2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 19:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA43213; Thu, 7 Mar 2002 10:43:02 -0800 (PST) Date: Thu, 7 Mar 2002 10:43:01 -0800 (PST) From: Julian Elischer To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: A question of VM page ownership In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG which one does the data come from? On Thu, 7 Mar 2002, Zhihui Zhang wrote: > > Is there any fundamental reason why a page can not be owned by more than > one VM object? If that was the case, the bogus page stuff in vfs_bio.c > could be made cleaner IMHO. > > -Zhihui > > > 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 Mar 7 11:12:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 323CA37B42C for ; Thu, 7 Mar 2002 11:12:07 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g27JC3A68645; Thu, 7 Mar 2002 11:12:03 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Mar 2002 11:12:03 -0800 (PST) From: Matthew Dillon Message-Id: <200203071912.g27JC3A68645@apollo.backplane.com> To: "Rogier R. Mulhuijzen" , Mike Silbersack , Tom , Dimitar Peikov , cjp , Subject: Re: Swapping performance References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hmm. well, I don't think this test is very meaningful. If the machines have 256M of ram and the test is doing a two-swipe access of 256M of VM. This doesn't represent any real test and I would not be surprised by the difference in timing. It all comes down to how much real memory Linux and FreeBSD give to the process and there is no right answer to the question because it's a tradeoff. An OS does not magically know that only one process will ever need all of the machine's resources, for example, so different operating systems are going to have very different characteristics under these sorts of conditions. One might give over more memory, another might want to avoid completely blowing away its other caches. One might work well for linux in a one-process memory test could fail miserably in a multi-process memory test, for example, or with a different pattern of memory accesses, or a different load split between cpu, memory, and disk I/O. You (Dimitar and others) also need to be careful about making broad generalizations. Testing pure swapping performance with the below program implies that you intend to run applications that will need to swap heavily (for example, big mathmatical applications). If you don't intend to run applications that will need to swap heavily then this test is fairly meaningless as a measure of performance. Another point that I should bring up in regards to swap performance: systems that require good swap performance will almost always have more then one physical disk to swap to. FreeBSD is very good at paging to swap with a single disk, but it kicks ass paging to swap with multiple disks because it implements a very good interleaving algorithm. -Matt Matthew Dillon :Am I the only one who saw that he attached it to his 1st mail? : :Here you go: : :#include :#include :#include : :#define MALLOC_SIZE 1024*1024*256 : :int main(int argc, char **argv) { : char *ptr; : int i, i_count; : int j; : : ptr = (char *) malloc(MALLOC_SIZE); : bzero(ptr, MALLOC_SIZE); : : i_count = MALLOC_SIZE / 16; : fprintf(stderr, "*"); : for (i = 0; i < i_count; i ++) { : ptr[i >> 4] = ptr[(i >> 3) + 1]++; : } : fprintf(stderr, "#"); : for (j = 0; j < i_count; j ++) { : ptr[j << 4] = ptr[(j >> 3) + 1]++; : } : : free(ptr); : 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 Mar 7 11:12:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 1745D37B420 for ; Thu, 7 Mar 2002 11:12:28 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g27JCNw21139; Thu, 7 Mar 2002 14:12:23 -0500 (EST) Date: Thu, 7 Mar 2002 14:10:36 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: Julian Elischer Cc: freebsd-hackers@freebsd.org Subject: Re: A question of VM page ownership In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The bogus page is owned by the system object, not by individual objects associated with the files. If a page could be owned by more than one objects, then we could let the object associated with a file to own the bogus page. -Zhihui On Thu, 7 Mar 2002, Julian Elischer wrote: > which one does the data come from? > > On Thu, 7 Mar 2002, Zhihui Zhang wrote: > > > > > Is there any fundamental reason why a page can not be owned by more than > > one VM object? If that was the case, the bogus page stuff in vfs_bio.c > > could be made cleaner IMHO. > > > > -Zhihui > > > > > > 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 Mar 7 11:20:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 09EE637B404 for ; Thu, 7 Mar 2002 11:20:19 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j3QU-0006TH-00; Thu, 07 Mar 2002 11:19:42 -0800 Message-ID: <3C87BD3D.49BE8105@mindspring.com> Date: Thu, 07 Mar 2002 11:19:25 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: Mike Silbersack , Tom , Dimitar Peikov , cjp , freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > #include > #include > #include > > #define MALLOC_SIZE 1024*1024*256 > > int main(int argc, char **argv) { > char *ptr; > int i, i_count; > int j; > > ptr = (char *) malloc(MALLOC_SIZE); > bzero(ptr, MALLOC_SIZE); The bzero is unnecessary on FreeBSD. Allocated pages start out zero'ed. Part of the performance issue might be that FreeBSD is being asked to zero the pages twice, instead of once. > i_count = MALLOC_SIZE / 16; > fprintf(stderr, "*"); > for (i = 0; i < i_count; i ++) { > ptr[i >> 4] = ptr[(i >> 3) + 1]++; ** Is this what was intended? This will keep the lvalue in the first 256th of memory, and the rvalue in the first half. > } > fprintf(stderr, "#"); > for (j = 0; j < i_count; j ++) { > ptr[j << 4] = ptr[(j >> 3) + 1]++; > } This looks more right... the lvalue hits every page, and the rvalue is (still) limited to the first half of memory. > > free(ptr); Try just exiting; free() might be trying to be too clever on FreeBSD. Doing the same on both platforms should not invalidate the test. > return 0; > } It might be more interesting to mmap() anonymous memory (e.g. out of /dev/zero), rather than using malloc, and then use that memory the same way, instead (it's swap backed, as well). Giving it an madvise, to tell it your intended access pattern would also be useful. I'm also not sure if the Linux VM "prefers" code pages to data pages. It could very well be the case that it does; that would result in a potentiall much better performance on this test. It would also be useful to know the relative load addresses in the code; FreeBSD might end up having the code compiled to be split across cache lines, etc, where the Linux version of the code does not. As other people pointed out, the "speed" of the swap partition is also potentially an issue. Make sure that FreBSD and Linux are using the same region relative to the drive spindle for swap. In addition, you should verify that the hardware is, in fact, identical. The easiest way to do this would be to swap drives in the machines to see if the affects the results, and -- while they are out -- verify that the drives themselves are as identical as possible. You might also want to turn *off* the FreeBSD "harvesting entropy", if it's doing it on disk interrupts or other interrupts inportant to the code path. If all this still has the FreeBSD slower, it still, unfortunately, isn't conclusive, one way or the other; it could still be that what you are testing is not the swap performance of FreeBSD, but, perhaps, the differences in the disk device drivers for the particular controller you ended up with in the motherboard lottery. It would also be useful to see the verbose dmesg output for both systems for the devices involved in the test code path. It may be that FreeBSD is working around a known controller issue (e.g. the CMD640B IDE controller), etc., where interleaved I/O's are being permitted by Linux, but not by FreeBSD, for fear of data corruption. Finally... you might want to try the Linux version of the program on FreeBSD, rather than using a native FreeBSD version. THis should account for many things, including the sync'ing of mapping regions, if that's a factor. All this information is useless to me personally; please post to the list, if you post at all, thanks. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11:25:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id ED13E37B438 for ; Thu, 7 Mar 2002 11:24:21 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g27JNoe68754; Thu, 7 Mar 2002 11:23:50 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Mar 2002 11:23:50 -0800 (PST) From: Matthew Dillon Message-Id: <200203071923.g27JNoe68754@apollo.backplane.com> To: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG, Julian Elischer Subject: Re: A question of VM page ownership References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :which one does the data come from? : :On Thu, 7 Mar 2002, Zhihui Zhang wrote: : :> :> Is there any fundamental reason why a page can not be owned by more than :> one VM object? If that was the case, the bogus page stuff in vfs_bio.c :> could be made cleaner IMHO. :> :> -Zhihui :> I think there is some confusion here. The bogus_page stuff in vfs_bio has nothing to do with VM page ownership. Bogus_page's are used when a BIO buffer is reconstituted from pages in the VM Page cache. In this situation some pages required to reconstitute the buffer may be missing and other pages may be dirty. In order to deal with this case new pages must be allocated for the ones that are missing and a bogus page must be mapped into the BIO buffer for the page that is dirty in order for the BIO system to be able to issue a 'read' to fill in the missing data and not accidently overwrite the dirty page. When the I/O is complete, the bogus page is removed and the original dirty page takes its place. This occurs entirely within the domain of BIO. bogus pages have nothing to do with real VM pages and VM objects. VM object ownership of a page is totally independant from memory mappings of the page. A VM page can only be associated with a single VM object, but it can be mapped into memory in many places and by many processes. For example, you can mmap() offset 4096 in a file at location X, and you can mmap() the SAME offset at location Y, so you wind up with two different VM addresses associated with the same page. It is the job of the PMAP subsystem to keep track of these (hardware MMU / pagetable) mappings. In the same manner, pages may be wired into kernel virtual memory (KVM), which is how the buffer cache works. But the page is still 'owned' by a single VM object. I recommend reviewing vm/vm_mmap.c and vm/vm_map.c .. specifically, the vm_map_entry structure (which maps VM objects into an address space), and i386/i386/pmap.c (which tracks MMU mappings), and vm/vm_pageout.c and vm/vm_object.c (so you can see how object flushing works.. I suggest reading the vm_object_page_clean() procedure). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11:26:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 4B87737B404; Thu, 7 Mar 2002 11:25:41 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j3WF-00006q-00; Thu, 07 Mar 2002 11:25:40 -0800 Message-ID: <3C87BEA3.452B8860@mindspring.com> Date: Thu, 07 Mar 2002 11:25:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Maxim Sobolev , hackers@FreeBSD.org, audit@FreeBSD.org, re@FreeBSD.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks References: <200203071848.g27Imgs01327@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > > > I don't like this. I would much rather see support for 'split' files > > > > implemented as a stacking filesystem layer like the gzip support, with > > > > the simple recognition of 'foo.gz.aa' as the first part of a split > > > > version of 'foo.gz', which in turn is recognised as a compressed version > > > > of 'foo'. > > > > > > I am curious how in this case the layer is going to know how many > > > parts the file contains? > > > > I'm curious how you're going to get the code to execute > > to do this layering, when it's spread across three floppy > > images. > > I'm curious to know what you think you're doing getting into yet another > discussion about something you don't understand. Which is about the best > answer I can offer to your question, since it's otherwise a non sequiter. I guess it was your use of "a stacking filesystem layer" that made me thing you were stacking filesystem layers. Sorry if this wasn't clear to you. I guess what you really meant to say was that you wanted it pounded into the file I/O in libstand, rather than saying that you wanted it in a stacking layer? It wasn't clear that what you meant was not what you said until you replied with your scheme to the same posting which I replied to. It would be nice if you didn't rip people a new one, merely because you had replied to the same message they replied to earlier, and they didn't have the information clarifying the original post at the time they made theirs. It would be particularly nice, considering it was your statements that required the clarification in the first place. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11:27:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2EFFF37B4BD for ; Thu, 7 Mar 2002 11:26:45 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g27JQhU68778; Thu, 7 Mar 2002 11:26:43 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Mar 2002 11:26:43 -0800 (PST) From: Matthew Dillon Message-Id: <200203071926.g27JQhU68778@apollo.backplane.com> To: Terry Lambert Cc: "Rogier R. Mulhuijzen" , Mike Silbersack , Tom , Dimitar Peikov , cjp , freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> <3C87BD3D.49BE8105@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> ptr = (char *) malloc(MALLOC_SIZE); :> bzero(ptr, MALLOC_SIZE); : :The bzero is unnecessary on FreeBSD. Allocated pages start out :zero'ed. Part of the performance issue might be that FreeBSD is :being asked to zero the pages twice, instead of once. malloc() does not guarentee a zero'd page, even though the side effect of a malloc() that large could very well be to map demand-zero-fill space. The bzero() will have the effect of force-instantiating the storage for the malloc'd space. It's appropriate for the test, I suppose, since the test is trying to test swap performance. :It might be more interesting to mmap() anonymous memory :(e.g. out of /dev/zero), rather than using malloc, and :then use that memory the same way, instead (it's swap :backed, as well). Giving it an madvise, to tell it your :intended access pattern would also be useful. Just mmap(... MAP_ANON...). It will make no difference, though, because that is effectively what a malloc() of that size will do anyway. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11:34:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by hub.freebsd.org (Postfix) with ESMTP id 325DC37B41C for ; Thu, 7 Mar 2002 11:34:41 -0800 (PST) Received: from fwd00.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16j3d4-0007lF-03; Thu, 07 Mar 2002 20:32:42 +0100 Received: from spirit.corecode.ath.cx (320050403952-0001@[80.128.122.16]) by fmrl00.sul.t-online.com with esmtp id 16j3cr-1nZBGSC; Thu, 7 Mar 2002 20:32:29 +0100 Received: from elevation.zuhause.stoert.net (elevation.zuhause.stoert.net [192.168.66.46]) by spirit.corecode.ath.cx (8.11.6/8.11.6) with ESMTP id g27JWZc06400; Thu, 7 Mar 2002 20:32:35 +0100 (CET) (envelope-from corecode@corecode.ath.cx) Received: (from corecode@localhost) by elevation.zuhause.stoert.net (8.11.6/8.11.6) id g27JWTS84234; Thu, 7 Mar 2002 20:32:29 +0100 (CET) (envelope-from corecode) Date: Thu, 7 Mar 2002 20:32:25 +0100 From: "Simon 'corecode' Schubert" To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Optimisation errors (Was: Swapping performance) Message-Id: <20020307203225.54d79d1d.corecode@corecode.ath.cx> In-Reply-To: <3C87B632.43156193@mindspring.com> References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> <20020307164724.D377@straylight.oblivion.bg> <20020307153615.GB1942@student.uu.se> <20020307164500.5dd21d16.corecode@corecode.ath.cx> <3C87B632.43156193@mindspring.com> X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.RKEMOP_lw+EYp7" X-Sender: 320050403952-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=.RKEMOP_lw+EYp7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 07 Mar 2002 10:49:22 -0800 Terry Lambert wrote: > Simon 'corecode' Schubert wrote: > > to everybody who doesn't believe that: it really generates bad code. > > i've been having severe problems with my tcp and udp stack lately (on a > > i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<< > > generated bad tcp and/or udp checksums (depending on ip). i didn't > > investigate any further, but believe me: not being able to access some > > dns servers is a pain in the ass. > > Are you using NAT? yep. > The libalias incremental checksum calculation is incorrect; > it assumes that a two's complement network order underflow > will result in the same value as a one's complement host > order underflow. This results in off-by-one errors. so is this an optimisation issue or not? when compiling with -O it works again. furthermore i don't know if my bind uses the internal address or the external one for queries. > This is actually a *different* problem than the RFC 1624 > correction of RFC 1141 (also an off-by-one error). > > Have you used a recent version of ethereal? It's an incredible > bugger to get installed correctly for 4.5 or above, since you > have to come from packages (the dependencies for the ports are > incorrect), but it will tell you the correct checksum vs. the > one that it got. > > There's also printing it out in tcp_input when you get a bad > checksum. If you see a lot of "0xfffe", then you'll know it's > an off-by-one error. yah, got lots of them, seen in tcpdump -vvvxXlei gif0 ;] > If the problem is only on ACK packets... I can tell you that > the tcp_respond() code path is not really throughly exercised. tho i've seen these problems recently on UDP DNS lookups, too. then i switched back to -O cheerz corecode -- /"\ http://corecode.ath.cx/ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --=.RKEMOP_lw+EYp7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE8h8BMr5S+dk6z85oRAi7RAJ4qod0k5H4LDGuPaFp5keJ9mLmH6wCfcp5X v20R+i1Gb1Ujbcx+dWuns1U= =HVVj -----END PGP SIGNATURE----- --=.RKEMOP_lw+EYp7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11:37:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 0D59637B404 for ; Thu, 7 Mar 2002 11:37:41 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16j3hd-0006Bq-00; Thu, 07 Mar 2002 11:37:25 -0800 Message-ID: <3C87C164.A97EDEF0@mindspring.com> Date: Thu, 07 Mar 2002 11:37:08 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: "Rogier R. Mulhuijzen" , Mike Silbersack , Tom , Dimitar Peikov , cjp , freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> <3C87BD3D.49BE8105@mindspring.com> <200203071926.g27JQhU68778@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :The bzero is unnecessary on FreeBSD. Allocated pages start out > :zero'ed. Part of the performance issue might be that FreeBSD is > :being asked to zero the pages twice, instead of once. > > malloc() does not guarentee a zero'd page, even though the > side effect of a malloc() that large could very well be to map > demand-zero-fill space. For his particular test, all the pages come that way. > The bzero() will have the effect of force-instantiating the > storage for the malloc'd space. It's appropriate for the > test, I suppose, since the test is trying to test swap > performance. Maybe. If so, it's not really something that belongs in the time calculation, I think, unless he's testing the instantiation, rather than the swapping speed... which is what he said he was testing. > :It might be more interesting to mmap() anonymous memory > :(e.g. out of /dev/zero), rather than using malloc, and > :then use that memory the same way, instead (it's swap > :backed, as well). Giving it an madvise, to tell it your > :intended access pattern would also be useful. > > Just mmap(... MAP_ANON...). It will make no difference, > though, because that is effectively what a malloc() of > that size will do anyway. It gets all the malloc() code out of the code path, so we can tell if it's a slow malloc or a slow swap... basically, it makes it more likely he is measuring what he says he is intent on measuring. The other issue is that the bzero is definitely not needed in that case. The access pattern is actually pessimal; it avoids all of the sequential access optimizations, at the same time not disabling FreeBSD's looking for them. If the code were to mmap() and still bzero(), then it should madvise() sequential for the bzero, and then re-madvise() for the pessimal modification/access phase, so that FreeBSD didn't attempt to look for things to optimize. All in all, it's a test for the degenerate case; but I'm trying very hard not to just throw it out as a dumb thing to do, and play the game in figuring out why it's slow, and if it's really measuring swap performance, or malloc or bzero or whatever performance. Hell, part of the issue might be the use of the fprintf() paging the stdio buffer back in, when using a write() would avoid the problem entirely. ;^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11:46:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id B884D37B405; Thu, 7 Mar 2002 11:46:06 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g27JjXs01815; Thu, 7 Mar 2002 11:45:33 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203071945.g27JjXs01815@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Michael Smith , Maxim Sobolev , hackers@freebsd.org, audit@freebsd.org, re@freebsd.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks In-reply-to: Your message of "Thu, 07 Mar 2002 11:25:23 PST." <3C87BEA3.452B8860@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 11:45:33 -0800 From: Michael Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Michael Smith wrote: > > > > > I don't like this. I would much rather see support for 'split' files > > > > > implemented as a stacking filesystem layer like the gzip support, wit > h > > > > > the simple recognition of 'foo.gz.aa' as the first part of a split > > > > > version of 'foo.gz', which in turn is recognised as a compressed vers > ion > > > > > of 'foo'. > > > > > > > > I am curious how in this case the layer is going to know how many > > > > parts the file contains? > > > > > > I'm curious how you're going to get the code to execute > > > to do this layering, when it's spread across three floppy > > > images. > > > > I'm curious to know what you think you're doing getting into yet another > > discussion about something you don't understand. Which is about the best > > answer I can offer to your question, since it's otherwise a non sequiter. > > I guess it was your use of "a stacking filesystem layer" that > made me thing you were stacking filesystem layers. Oddly enough, that's exactly what I'm doing, or more accurately, asking Maxim to do. Should you care to be informed rather than playing from the sidelines, see the primitive 'stacking' used to implement transparent gzipped file support in libstand. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11:51: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id A8EF337B41D for ; Thu, 7 Mar 2002 11:50:55 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16j3ud-00036n-00; Thu, 07 Mar 2002 11:50:51 -0800 Message-ID: <3C87C48B.C734EEEB@mindspring.com> Date: Thu, 07 Mar 2002 11:50:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon 'corecode' Schubert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Optimisation errors (Was: Swapping performance) References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> <20020307164724.D377@straylight.oblivion.bg> <20020307153615.GB1942@student.uu.se> <20020307164500.5dd21d16.corecode@corecode.ath.cx> <3C87B632.43156193@mindspring.com> <20020307203225.54d79d1d.corecode@corecode.ath.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Simon 'corecode' Schubert wrote: > > Are you using NAT? > > yep. > > > The libalias incremental checksum calculation is incorrect; > > it assumes that a two's complement network order underflow > > will result in the same value as a one's complement host > > order underflow. This results in off-by-one errors. > > so is this an optimisation issue or not? when compiling with -O it works > again. furthermore i don't know if my bind uses the internal address or > the external one for queries. The short answer is "I don't know". The longer answer is "It depends". The problem is that there are certain optimizations that are permissable, which could break associativity on the carry. The only way to tell would be to have a dump that included wire/before NAT/after NAT/decode, and then see where it blew up. I made the assumption (perhaps invalid) that when you said the checksum calculation was invalid that it was invalid on check vs. being invalid on transmit. That it's the incremental checksum calculation is a good bet anyway, since the optimized machine dependent code that's used in the standard path isn't going to change much anyway. > > There's also printing it out in tcp_input when you get a bad > > checksum. If you see a lot of "0xfffe", then you'll know it's > > an off-by-one error. > > yah, got lots of them, seen in tcpdump -vvvxXlei gif0 ;] > > > If the problem is only on ACK packets... I can tell you that > > the tcp_respond() code path is not really throughly exercised. > > tho i've seen these problems recently on UDP DNS lookups, too. then i > switched back to -O Most likely it's the TTL update, then, near border underflow cases. I had a recent situation where I was doing sequence adjustment, and by using the loopback for testing, I ended up with the sequence number randomness causing the problem about 45% of the time, because of the probability of underflow being so much higher. THe easy answer is that you need to ntohs((u_short)ip->ip_ttl) before you add it, and then do the incremental update in HTONS(ip->ip_seq); /* adjust */ HTONS(ip-ip_seq);. The harder way would be to correct the carry for the byte swapped order, but it's a real pain to do. If you look at the code in RFC 1141, it shows how to do this, but it's not exactly correct because of the problem RFC 1624 points out. Basically, you end up needing to do the complemnatry math, instead of the complement of the regular math. Hope this helps. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 11:58:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 945B637B43B; Thu, 7 Mar 2002 11:58:09 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16j41g-0006Gh-00; Thu, 07 Mar 2002 11:58:09 -0800 Message-ID: <3C87C640.E26DE955@mindspring.com> Date: Thu, 07 Mar 2002 11:57:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Maxim Sobolev , hackers@freebsd.org, audit@freebsd.org, re@freebsd.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks References: <200203071945.g27JjXs01815@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > Should you care to be informed rather than playing from the sidelines, > see the primitive 'stacking' used to implement transparent gzipped file > support in libstand. The only place this is referred to as a "stack" at all is in one comment in the libstand.3 man page, which hardly excuses you ripping me a new one. The source code in zipfs.c itself *certainly* doesn't call it that in comments. Also the way the operations are encapsulated (not stacked, since a stack could be reordered) is by directly calling "read", rather than calling through a "stack". This basically means that the reassembly order means that you would have to call the reassembly both at the read and the zfread, so that you could handle multipart for both cases of uncompressed and compressed multipart files. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 12:17:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 574A637B402; Thu, 7 Mar 2002 12:17:04 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g27KGVs02007; Thu, 7 Mar 2002 12:16:31 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203072016.g27KGVs02007@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Michael Smith , Maxim Sobolev , hackers@freebsd.org, audit@freebsd.org, re@freebsd.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks In-reply-to: Your message of "Thu, 07 Mar 2002 11:57:52 PST." <3C87C640.E26DE955@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 12:16:31 -0800 From: Michael Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Michael Smith wrote: > > Should you care to be informed rather than playing from the sidelines, > > see the primitive 'stacking' used to implement transparent gzipped file > > support in libstand. > > The only place this is referred to as a "stack" at all is in > one comment in the libstand.3 man page, which hardly excuses > you ripping me a new one. So because I called it a "stack" I *must* have been referring to the kernel, not actually the loader (since that's only mentioned in the subject line and implicitly throughout my message)? Get real, Terry. > Also the way the operations are encapsulated (not stacked, > since a stack could be reordered) is by directly calling > "read", rather than calling through a "stack". This is an implementation detail. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 12:22:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cauchy.clarkevans.com (209-9-30-66.sdsl.cais.net [209.9.30.66]) by hub.freebsd.org (Postfix) with ESMTP id 648A537B416 for ; Thu, 7 Mar 2002 12:22:24 -0800 (PST) Received: from cce by cauchy.clarkevans.com with local (Exim 3.33 #1) id 16j4QR-0003IV-00 for freebsd-hackers@FreeBSD.org; Thu, 07 Mar 2002 15:23:43 -0500 Date: Thu, 7 Mar 2002 15:23:43 -0500 From: "Clark C . Evans" To: freebsd-hackers@FreeBSD.org Subject: Re: read-only root partition? Message-ID: <20020307152343.B12503@doublegemini.com> References: <20020227175541.A17132@doublegemini.com> <20020228003540.V39476-100000@nohow.demon.co.uk> <20020228012649.A23259@doublegemini.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020228012649.A23259@doublegemini.com>; from cce@clarkevans.com on Thu, Feb 28, 2002 at 01:26:49AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Feb 28, 2002 at 01:26:49AM -0500, Clark C . Evans wrote: | | http://people.freebsd.org/~bsd/cdroot/ | | Ok. I've tried this route and it seems to be working, | thank you all so much for your help and pointers. Thus far, cdroot has worked well for me. I have a PleXwriter 23/10/40A and an old Mitsumi 12x CD-ROM (PIO 3). I get the following boot messages... cd9660: RockRidge extension Warning: bytes per inode restricts cylinders per group to 9. Warning: inode blocks/cyl group (285) >= data blocks (256) in last cylinder group. This implies 4096 sector(s) cannot be allocated. 496 blocks Warning: block size restricts cylinders per group to 26. 496 blocks After that, all seems to go well. Unfortunately, when this same CD-ROM is placed into a newer CD-ROM reader it either doesn't boot at all... (such as the Data Research 56x max or Vintech Intl. VIN-44A) or it gives me the following result: (results vary) pid 7 (sh) uid 0: exited on signal 5/10/11 Where it can't seem to make up it's mind about what signal it exits with 5, 10, or most frequently, 11. I've tried everything... and purched 2 additional new CD-ROM units with the same result... the new CD-ROMs don't like the file that's being generated. Thoughts? Clark I've had some problems getting cdroot to work | | I also see a few drives complaining (like the mouse), | I think I know how to re-do the kernel to leave out | the mouse driver though. Is this a cd driver that | needs to be removed? | | Anyway, I log-in and everything works nicely. Cool. | Given that I've gotten this far with cdroot, I think | I'm going to stick with this solution... and figure | out how it works. This kit makes three mfs for me: | tmp, var, etc, dev. I'm wondering if the etc | and dev must be done as mfs? | | My next step is to make a custom boot process: | | 1. Check to see if /dev/ad0s1b exists and is a | swap partition, if so, load it. | | 2. Check to see if /dev/ad0s1? exists and is | a FreeBSD partition. If so, see if it looks | like a /tmp, /var, or /home partition. If | so mount as appropriate. | | 3. Modify (2) above, to search on /ad?s1? for | a similar structure. If so, then mount it | using vinum. | | If steps 1-3 above fail, then assume it is an | "uninitialized" box. Ask the user to verify | this fact, and then create the partitions | automagically. If there are two disks, ask | the user if a software mirror is to be used, | if so, then configure this as well. | | If any of you have any suggestions/comments/ideas | as to how to best do this, I'd love to hear them! | | Best, | | Clark | | | | | | | | | | | Thank you all so much for your | suggestions and thoughts! | | My next step is to examine the file system: | | (a) if the "data" partition exists, then this | can be mounted and /var and /tmp can be | | | | | | | To Unsubscribe: send mail to majordomo@FreeBSD.org | with "unsubscribe freebsd-hackers" in the body of the message -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 12:28: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id D873337B404 for ; Thu, 7 Mar 2002 12:27:55 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g27KRoKD115050; Thu, 7 Mar 2002 15:27:54 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020307071630.E26DBBA03@i8k.babbleon.org> References: <52204.1015480748@critter.freebsd.dk> <20020307071630.E26DBBA03@i8k.babbleon.org> Date: Thu, 7 Mar 2002 15:27:49 -0500 To: "Brian T.Schellenberger" From: Garance A Drosihn Subject: Re: RFC: style(9) isn't explicit about booleans for testing -- an actual analysis of the code! Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:16 AM -0500 3/7/02, Brian T.Schellenberger wrote: >Maybe your brain has gotten used to it, but to us ordinary >mortals, even us ordinary mortals who've been slogging C >code for time periods that can be measured in decades >(yikes!), it is very tempting to read > > if (!strcmp(a,b,l)) > >as "if the strings don't compare" which, in ordinary usage, >means don't compare *equal*. But of course the C program >is going to proceed to do exactly the opposite of that. Okay, I will agree I have made that mistake a few times. Not often, but it really burns me up when I realize that's the source of some bug. So, that sounds like a good reason. >But *ALL* of this is beside the nominal point ANYWAY, which >is to discuss the proper wording for the man(9) style guide >which is supposed to document how things things are actually >done in the kernel, not personal preference. As to the wording, PHK suggested that the wording for this rule in style(9) be changed: - - - get rid of the word boolean, ie: change Do not use ! for tests unless it is a boolean, e.g. use to Do not use ! for tests unless it is an integer type, e.g. use - - - Dave O'Brien claimed the very same rule was *only* there to prevent "if (!strcmp(a,b))". May I suggest that we probably want two different rules? Change the current rule so it says 'integer type' instead of 'boolean' (which doesn't really exist in C anyway), and then add the rule about strcmp()? -- 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 Thu Mar 7 12:54:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id 2EC4037B416 for ; Thu, 7 Mar 2002 12:54:20 -0800 (PST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id g27KrFA21254; Thu, 7 Mar 2002 15:53:15 -0500 (EST) (envelope-from bicknell) Date: Thu, 7 Mar 2002 15:53:15 -0500 From: Leo Bicknell To: Garance A Drosihn Cc: "Brian T.Schellenberger" , hackers@FreeBSD.ORG Subject: Re: RFC: style(9) isn't explicit about booleans for testing -- an actual analysis of the code! Message-ID: <20020307205315.GA21048@ussenterprise.ufp.org> References: <52204.1015480748@critter.freebsd.dk> <20020307071630.E26DBBA03@i8k.babbleon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In a message written on Thu, Mar 07, 2002 at 03:27:49PM -0500, Garance A Drosihn wrote: > As to the wording, PHK suggested that the wording for this > rule in style(9) be changed: > - - - > get rid of the word boolean, ie: change > Do not use ! for tests unless it is a boolean, e.g. use > to > Do not use ! for tests unless it is an integer type, e.g. use Although C doesn't have the type "boolean", I believe this is a conceptual distinction. That is, we don't want to allow this: if (!uid) { /* do thing only root can do */ } Because UID is not a boolean type. It takes a range of values, and should be: if (uid == 0) { /* do thing only root can do */ } The only proper use of "!" is on a boolean type, defined as a type that has two values, 0, and everything else. Personally, I would clarify boolean in the document as follows: C does not provide a proper boolean type. As a result, FreeBSD uses integers for a boolean type. The boolean values are 0 for false, and all other values for true. All code using a boolean type must not depend on "true" having any specific value. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 13: 4:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from root.com (unknown [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 36AC237B402 for ; Thu, 7 Mar 2002 13:04:34 -0800 (PST) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id g27Kqaf67063; Thu, 7 Mar 2002 12:52:36 -0800 (PST) (envelope-from dg) Date: Thu, 7 Mar 2002 12:52:36 -0800 From: David Greenman To: Matthew Dillon Cc: "Rogier R. Mulhuijzen" , Mike Silbersack , Tom , Dimitar Peikov , cjp , freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance Message-ID: <20020307125236.E64508@nexus.root.com> References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> <200203071912.g27JC3A68645@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203071912.g27JC3A68645@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Mar 07, 2002 at 11:12:03AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Another point that I should bring up in regards to swap performance: > systems that require good swap performance will almost always have > more then one physical disk to swap to. FreeBSD is very good at > paging to swap with a single disk, but it kicks ass paging to swap > with multiple disks because it implements a very good interleaving > algorithm. I think it's also useful to point out that the performance of this test is likely going to vary greatly as it is run. This is because it is heavily affected by the order of the pageouts in terms of their physical swap block allocations. In other words, what you're really testing is how sequentially the blocks are paged out vs. how randomly at the swap block level. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 13:55:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 78F9E37B402 for ; Thu, 7 Mar 2002 13:55:37 -0800 (PST) Received: (qmail 93758 invoked by uid 100); 7 Mar 2002 21:55:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.57816.98439.143709@guru.mired.org> Date: Thu, 7 Mar 2002 15:55:36 -0600 To: Miguel Mendez Cc: Mike Meyer , freebsd-hackers@freebsd.org, D J Hawkey Jr , bts@babbleon.org Subject: Re: C vs C++ In-Reply-To: <20020307095141.A2889@energyhq.homeip.net> References: <20020305164731.530B5BA03_i8k.babbleon.org@ns.sol.net> <200203061219.g26CJEJ61813@sheol.localdomain> <20020306191709.A55297@dragon.nuxi.com> <15494.57538.888210.658115@guru.mired.org> <20020307095141.A2889@energyhq.homeip.net> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Miguel Mendez types: > On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote: > > That is true. C++ is as ugly as C, but has all the problems of Object > > Orient Languages. > What are you smoking? :-) No language in this world fits OS development > better than C. IMHO is one of the most beautiful languages ever created. > It's simple, small and efficient. And it requires you to know what you > are doing, but I consider that a feature. C resembles assembler on many > of it's constructs. C makes a good portable assembler, and that's what I use it for. That makes it nearly OS development and systems level applications work. In other domains, this can be a serious problem. The only real problem with C is the type decleration syntax. C is the only language I've ever run into that someone - and someone bright, at that - felt the need to write a tool for explaining what a variable declaration meant, or one to translate from english to the language in question. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 14: 3:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id A79E637B402; Thu, 7 Mar 2002 14:03:47 -0800 (PST) Received: from pool0584.cvx40-bradley.dialup.earthlink.net ([216.244.44.74] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16j5zG-00077v-00; Thu, 07 Mar 2002 14:03:47 -0800 Message-ID: <3C87E3B1.E1443DFF@mindspring.com> Date: Thu, 07 Mar 2002 14:03:29 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Maxim Sobolev , hackers@freebsd.org, audit@freebsd.org, re@freebsd.org Subject: Re: Extending loader(8) for loading kerels/modules split across several disks References: <200203072016.g27KGVs02007@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > The only place this is referred to as a "stack" at all is in > > one comment in the libstand.3 man page, which hardly excuses > > you ripping me a new one. > > So because I called it a "stack" I *must* have been referring to the > kernel, not actually the loader (since that's only mentioned in the > subject line and implicitly throughout my message)? > > Get real, Terry. So I asked a question in a humorous fashion because what you said didn't make sense to me, I must be a dolt. Get real, Michael. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 14:28: 5 2002 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 AC69037B402 for ; Thu, 7 Mar 2002 14:27:57 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g27MRui95205; Thu, 7 Mar 2002 15:27:56 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g27MRtL97469; Thu, 7 Mar 2002 15:27:55 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 07 Mar 2002 15:27:47 -0700 (MST) Message-Id: <20020307.152747.127669206.imp@village.org> To: valery.khromov@icluk.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Converting physical into virtual address From: "M. Warner Losh" In-Reply-To: <009c01c1c356$93e13be0$c80ca8c0@khromovv> References: <009c01c1c356$93e13be0$c80ca8c0@khromovv> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <009c01c1c356$93e13be0$c80ca8c0@khromovv> "Valery N. Khromov" writes: : I'd like to develop a kernel module for FreeBSD, able to read & write : directly to VGA text-mode screen buffer. I know that this buffer is located : at 0xB8000 in physical address space. But in kernel I must address it using : kernel virtual address space. : : Thus, the question is: how can I _correctly_ convert physical address into : kernel virtual address? : : Now I use the following trick: 0xC0000000 + 0xB8000, but I want to use more : correct method. :) bus_alloc_resource() followed by bus_space_{read,write}_*. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 15:30: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.wa3dbj.vix.com (dbj-pa.pp.vix.com [204.152.184.150]) by hub.freebsd.org (Postfix) with ESMTP id 0964237B41B for ; Thu, 7 Mar 2002 15:29:49 -0800 (PST) Received: from gw.wa3dbj.vix.com (boggs@[127.0.0.1]) by gw.wa3dbj.vix.com (8.9.3/8.9.3) with ESMTP id PAA15449 for ; Thu, 7 Mar 2002 15:29:44 -0800 (PST) Message-Id: <200203072329.PAA15449@gw.wa3dbj.vix.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: FreeBSD-hackers@freebsd.org Subject: Berkeley Packet Filter question Date: Thu, 07 Mar 2002 15:29:44 -0800 From: David Boggs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [reposted from FreeBSD-questions] I'm writing a network device driver. I'm using FreeBSD 4.4-RELEASE. I can't get BPF to work; it dereferences a nil pointer. Attached below is some BPF code. As I read it, bpfattach() is passed an ifp (struct ifnet *). It mallocs a 'bpf_if' (1) and installs the ifp in it (2). Then it uses this pointer to ZERO a pointer in the ifp named if_bpf (3) (presumably a back-pointer). Later, bpf_mtap() is called, and it picks up the back-pointer to the if_bpf (4) (which has been ZEROed) and dereferences it (5), causing a type 12 trap. Grepping through other device drivers, I note that most of them don't call bpfattach(), but two or three do. Those that do, are NOT passing a struct ifnet * as the first argument. What's going on here? My driver is for a synchronous serial line. The proper place for snooping packets is in sppp, rather than in each individual driver. Why doesn't sppp call bpf? Why should I ever have to deal with this? /David Boggs void bpfattach(ifp, dlt, hdrlen) struct ifnet *ifp; u_int dlt, hdrlen; { struct bpf_if *bp; (1) bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT); (2) bp->bif_ifp = ifp; ..... (3) bp->bif_ifp->if_bpf = 0; /* this seems wrong */ ..... } void bpf_mtap(ifp, m) struct ifnet *ifp; struct mbuf *m; { (4) struct bpf_if *bp = ifp->if_bpf; ..... (5) for (d = bp->bif_dlist; d != 0; d = d->bd_next) { ..... } ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 15:44:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 795A437B405 for ; Thu, 7 Mar 2002 15:44:08 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g27Nhjs03688; Thu, 7 Mar 2002 15:43:45 -0800 Date: Thu, 7 Mar 2002 15:43:45 -0800 From: Brooks Davis To: David Boggs Cc: FreeBSD-hackers@FreeBSD.ORG Subject: Re: Berkeley Packet Filter question Message-ID: <20020307154345.A2084@Odin.AC.HMC.Edu> References: <200203072329.PAA15449@gw.wa3dbj.vix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200203072329.PAA15449@gw.wa3dbj.vix.com>; from boggs@boggs.palo-alto.ca.us on Thu, Mar 07, 2002 at 03:29:44PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 07, 2002 at 03:29:44PM -0800, David Boggs wrote: > Attached below is some BPF code. As I read it, bpfattach() is passed > an ifp (struct ifnet *). It mallocs a 'bpf_if' (1) and installs the ifp > in it (2). Then it uses this pointer to ZERO a pointer in the ifp named > if_bpf (3) (presumably a back-pointer). Later, bpf_mtap() is called, > and it picks up the back-pointer to the if_bpf (4) (which has been ZEROed) > and dereferences it (5), causing a type 12 trap. >=20 > Grepping through other device drivers, I note that most of them don't > call bpfattach(), but two or three do. Those that do, are NOT passing > a struct ifnet * as the first argument. What's going on here? I'm not sure where you're looking for drivers, but every instance of bpfattach I can find passes in a struct ifnet * at the first argument. Take a look at sys/net/if_loop.c for a trivial example of bpf usage. The key thing is that in the input phase you check the if_bpf pointer and only call bpf_mtap if it's non-NULL and hence there is a listener. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8h/swXY6L6fI4GtQRAtMdAJ4oFaITy/IoDMBIR+9zvK5KoY9rOwCgj+LS 7hl78O9Do1u1FwMR95VOjFk= =INr8 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 19:37:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 70B3237B402; Thu, 7 Mar 2002 19:37:24 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 415D2AE265; Thu, 7 Mar 2002 19:37:24 -0800 (PST) Date: Thu, 7 Mar 2002 19:37:24 -0800 From: Bill Fumerola To: Julian Elischer , Terry Lambert Cc: green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308033724.GZ803@elvis.mu.org> References: <20020307092848.GX803@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020215 i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote: > what would be even nicer is if ipfw found the cached entry and passed it > back to ip_input so it didn't need to :-) i think this entire idea of cacheing it in ip_input() is a bad idea, no offense terry. first, having a uid or gid rule in your ipfw ruleset (or even running ipfw) certainly isn't the common case. we're now going to bloat the ip_fw_chk() calls protocol handler calls to add an arguement that 99% of time is going to be NULL. then you have to bloat the protocol handlers to check if that pointer, that is NULL 99% of the time, isn't NULL. i just don't think that the gain in the edge case justifies the slowdown in the common case. the first person to say 'sysctl' or '#ifdef' gets to drink from the fire hose. second, the real travesty is that if you have N rules in ipfw that reference a uid or gid, you will do a pcb lookup on the same packet for each of those N rules until you match. the worst case scenario of having to do a lookup for each uid rule is what the charts in my previous post measure. terry asked in his post: "NB: Is there a particular reason Bill's changes haven't simply been committed?", the reason is that my cache of the pcb and uid was done in my compiledipfw code, not the mainline ipfw. its really not a straight port because of somethings that compiledipfw keeps state on before generating code (skiptos, mostly); ipfw would have to be more careful then the generated code needs to be. if brian feldman (the author of the ipfw uid/gid code) doesn't fix this out of embarassment first, i'll backport my cache into the main ipfw code. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 20: 3:52 2002 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 C731A37B405; Thu, 7 Mar 2002 20:03:31 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g2843JD42713; Thu, 7 Mar 2002 23:03:19 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 7 Mar 2002 23:03:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bill Fumerola Cc: Julian Elischer , Terry Lambert , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020308033724.GZ803@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A couple of comments: - You can always cache the pcb the first time it's used, and then have it available for future use. I agree with your concerns about generating it every time -- that would be a disaster for routers where no packets are even delivered locally. :-) - The uid/gid code is broken for a number of important applications, including SSH forwarding, because SSHd binds the socket using a root credential rather than the user credential. Arguably, this is a bug with SSHd, and it also breaks a number of other things including the MAC support we're adding to 5.0-CURRENT. Also, it had some *evil* bugs involving NFS that I recently fixed in 5.0-CURRENT, where sockets were rebound using the credential of the user making the VFS operation, resulting in ipfw uid/gid rules dropping/rate-limiting file system requests for all users. For those running into the whole sshd tunnel and ident problem, it's the same cause. Now we have a combined pcred/ucred in ucred, in theory the rules could also act on effective/real/saved credentials, although that might not be useful. Actually, it arguably might be for setuid network tools. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 7 Mar 2002, Bill Fumerola wrote: > On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote: > > what would be even nicer is if ipfw found the cached entry and passed it > > back to ip_input so it didn't need to :-) > > i think this entire idea of cacheing it in ip_input() is a bad idea, no > offense terry. > > first, having a uid or gid rule in your ipfw ruleset (or even running > ipfw) certainly isn't the common case. we're now going to bloat the > ip_fw_chk() calls protocol handler calls to add an arguement that 99% > of time is going to be NULL. then you have to bloat the protocol handlers > to check if that pointer, that is NULL 99% of the time, isn't NULL. > > i just don't think that the gain in the edge case justifies the slowdown > in the common case. the first person to say 'sysctl' or '#ifdef' gets > to drink from the fire hose. > > second, the real travesty is that if you have N rules in ipfw that > reference a uid or gid, you will do a pcb lookup on the same packet for > each of those N rules until you match. the worst case scenario of having > to do a lookup for each uid rule is what the charts in my previous post > measure. > > terry asked in his post: "NB: Is there a particular reason Bill's changes > haven't simply been committed?", the reason is that my cache of the pcb > and uid was done in my compiledipfw code, not the mainline ipfw. its > really not a straight port because of somethings that compiledipfw keeps > state on before generating code (skiptos, mostly); ipfw would have to > be more careful then the generated code needs to be. > > if brian feldman (the author of the ipfw uid/gid code) doesn't fix this > out of embarassment first, i'll backport my cache into the main ipfw > code. > > -- > - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org > - my anger management counselor can beat up your self-affirmation therapist > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" 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 Mar 7 21:15:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 5B99C37B405; Thu, 7 Mar 2002 21:15:20 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 245A4AE211; Thu, 7 Mar 2002 21:15:20 -0800 (PST) Date: Thu, 7 Mar 2002 21:15:20 -0800 From: Bill Fumerola To: Robert Watson Cc: Julian Elischer , Terry Lambert , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308051520.GB803@elvis.mu.org> Reply-To: Bill Fumerola References: <20020308033724.GZ803@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020215 i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 11:03:19PM -0500, Robert Watson wrote: > A couple of comments: > > - You can always cache the pcb the first time it's used, and then have it > available for future use. I agree with your concerns about generating > it every time -- that would be a disaster for routers where no packets > are even delivered locally. :-) you can't cache it and make it available for future use without making the invasive changes that i mention: > > first, having a uid or gid rule in your ipfw ruleset (or even running > > ipfw) certainly isn't the common case. we're now going to bloat the > > ip_fw_chk() calls protocol handler calls to add an arguement that 99% ^-- "and" > > of time is going to be NULL. then you have to bloat the protocol handlers > > to check if that pointer, that is NULL 99% of the time, isn't NULL. i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene. adding another one to the protocol handlers doesn't seem like a great idea either. we're talking about an optimization that less then .1% of our userbase will ever take advantage of v. a pessimization (additional argument in the protocol handler + check of that arguement in the handler) in the critical path of packet delivery in ALL cases (even kernels w/o ipfw). it's just not worth it. with ipfw cacheing the pcb lookup + credential check and w/o terry's patch, the worst case would be a ruleset with any uid/gid rules: a pcb lookup being done twice (once ever in ipfw, once in the protocol handler). that's really not so bad compared with the current behavior with uid/gid rules where the lookup is done of a lot of times (as many uid/gid rules you walk through before you match) in ipfw and once in the protocol handler. > - The uid/gid code is broken for a number of important applications, > including SSH forwarding, because SSHd binds the socket using a root > credential rather than the user credential. Arguably, this is a bug > with SSHd, and it also breaks a number of other things including the MAC > support we're adding to 5.0-CURRENT. Also, it had some *evil* bugs > involving NFS that I recently fixed in 5.0-CURRENT, where sockets were > rebound using the credential of the user making the VFS operation, > resulting in ipfw uid/gid rules dropping/rate-limiting file system > requests for all users. For those running into the whole sshd tunnel > and ident problem, it's the same cause. i would like to make my cache have the proper credential(s) rather then just cache the current socket credentials cr_uid, if that's wrong. please let me know privately just what exactly i should be comparing against (or functions i should be using, if an API exists now) in -current with the changes to credentials. when i mfc the cache, i'll just keep the current uid comparing behavior. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 22: 1:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 2762F37B417; Thu, 7 Mar 2002 22:00:25 -0800 (PST) Received: from pool0036.cvx21-bradley.dialup.earthlink.net ([209.179.192.36] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jDQL-0006dx-00; Thu, 07 Mar 2002 22:00:14 -0800 Message-ID: <3C885357.931A4E43@mindspring.com> Date: Thu, 07 Mar 2002 21:59:51 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fumerola Cc: Julian Elischer , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times References: <20020307092848.GX803@elvis.mu.org> <20020308033724.GZ803@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Fumerola wrote: > On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote: > > what would be even nicer is if ipfw found the cached entry and passed it > > back to ip_input so it didn't need to :-) > > i think this entire idea of cacheing it in ip_input() is a bad idea, no > offense terry. No, the idea is to cache it when it's looked up, and pass it arounf from ip_input. In the modified firewall code, I have: P = in_pcblookup_hash(&udbinfo, src_ip, src_port, dst_ip, dst_port, 1, NULL); if( inpp) *inpp = P; inside the loop. THis could just as easily be: if (inpp) { if (*inpp) { P = *inpp; } else { P = *inpp = in_pcblookup_hash(&udbinfo, src_ip, src_port, dst_ip, dst_port, 1, NULL); } } else { P = *inpp = in_pcblookup_hash(&udbinfo, src_ip, src_port, dst_ip, dst_port, 1, NULL); } etc., which would cache the lookup. Also, the ip_fw_chk is not necessarily the first thing that gets called that needs to do an in_pcblookup_hash. > first, having a uid or gid rule in your ipfw ruleset (or even running > ipfw) certainly isn't the common case. we're now going to bloat the > ip_fw_chk() calls protocol handler calls to add an arguement that 99% > of time is going to be NULL. That's an extra push and pop. When a UDP or TCP packet is handed off to the upper level code, the cost compared to an additional in_pcblookup_hash call is very, very tiny. If you want to get technical, the same sort of lookup is used in the ip_flow.c code. If ipforwarding is enabled, and there is at least one flow active, then the lookup will happen, as well. > then you have to bloat the protocol handlers to check if > that pointer, that is NULL 99% of the time, isn't NULL. For the TCP and UDP cases, this is true... if the firewall code was not invoked. That's an extra push/pop and compare. > i just don't think that the gain in the edge case justifies the slowdown > in the common case. the first person to say 'sysctl' or '#ifdef' gets > to drink from the fire hose. 8-). Actually, you should ask John Lemon about this; he has splicing code. Splicing needs to do the same sort of lookup. I don't know if Cisco will let him commit it, but if so, that's three cases. > second, the real travesty is that if you have N rules in ipfw that > reference a uid or gid, you will do a pcb lookup on the same packet for > each of those N rules until you match. the worst case scenario of having > to do a lookup for each uid rule is what the charts in my previous post > measure. That's cacheable (per the above). > terry asked in his post: "NB: Is there a particular reason Bill's changes > haven't simply been committed?", the reason is that my cache of the pcb > and uid was done in my compiledipfw code, not the mainline ipfw. its > really not a straight port because of somethings that compiledipfw keeps > state on before generating code (skiptos, mostly); ipfw would have to > be more careful then the generated code needs to be. I think that you could cache the lookup the first time through the loop, in any case, or, even better, before the loop, if the loop is going to be hit (the list of rules is non-empty). > if brian feldman (the author of the ipfw uid/gid code) doesn't fix this > out of embarassment first, i'll backport my cache into the main ipfw > code. I think it's useful to push the cached value up through the stack. In a firewall case, or in a splice case, if you can get the code out of Lemon, or in the ip_flow case for the IP fast forwarding, if the hash is unified properly, we're talking about 1/2 to 1/4 of the overhead for the lookup. Actually, I'd use a global if I thought I could get away with it... ;^)... but the overhead of pushing another pointer and popping it later is really low, compared to the alternative. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 22:24:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 89C2137B402; Thu, 7 Mar 2002 22:24:25 -0800 (PST) Received: from pool0036.cvx21-bradley.dialup.earthlink.net ([209.179.192.36] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16jDnj-0000k3-00; Thu, 07 Mar 2002 22:24:24 -0800 Message-ID: <3C885900.E1CB18C0@mindspring.com> Date: Thu, 07 Mar 2002 22:24:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fumerola Cc: Robert Watson , Julian Elischer , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times References: <20020308033724.GZ803@elvis.mu.org> <20020308051520.GB803@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Fumerola wrote: > i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene. ip_fw_chk should be obscene and not heard? 8-). > we're talking about an optimization that less then .1% of our userbase > will ever take advantage of v. a pessimization (additional argument in > the protocol handler + check of that arguement in the handler) in the > critical path of packet delivery in ALL cases (even kernels w/o ipfw). The check occurs only in the case that an in_pcblookup_hash() of the type needed was imminent. In the failure case, the call is made anyway. The comparative overhead relative to the actual hash lookup itself is miniscule. > it's just not worth it. 8-). The main performance path is going to be ip_flow fast forwarding. Actually, it's tempting to replace the src/src dst/dst hash with a src/src hash with a second level hash for the dst/dst lookup. THis would simplify the wildcard/non-wildcard case, as well as allowing a unification of the search space. If it were just the pcbhash, I think I'd go with a btree... or to make Alfred happy... a skiplist... ;^). > with ipfw cacheing the pcb lookup + credential check and w/o terry's > patch, the worst case would be a ruleset with any uid/gid rules: a pcb > lookup being done twice (once ever in ipfw, once in the protocol handler). > > that's really not so bad compared with the current behavior with uid/gid > rules where the lookup is done of a lot of times (as many uid/gid rules > you walk through before you match) in ipfw and once in the protocol > handler. This is the expensive part that I'd like to avoid. There are actually three hash lookups, if you have the firewall and ipflow code active. > > - The uid/gid code is broken for a number of important applications, > > including SSH forwarding, because SSHd binds the socket using a root > > credential rather than the user credential. [ ... ] > > i would like to make my cache have the proper credential(s) rather then > just cache the current socket credentials cr_uid, if that's wrong. Actually, I think the place to correct this is by allowing the fchown/fchmod on sockets to actually do the right thing... > please let me know privately just what exactly i should be comparing > against (or functions i should be using, if an API exists now) in -current > with the changes to credentials. > > when i mfc the cache, i'll just keep the current uid comparing behavior. The cache is a definite win; I think it should be more general, though. Luigi was talking about adding metadata to mbufs; you *could* tunnel the inp looked up through the metadata on the mbuf on which the data was dereferenced out of for the lookup in the first place. I think it's easier to just pass another parameter. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 22:30: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id B6DA837B416 for ; Thu, 7 Mar 2002 22:30:05 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 9C64BAE272; Thu, 7 Mar 2002 22:30:05 -0800 (PST) Date: Thu, 7 Mar 2002 22:30:05 -0800 From: Alfred Perlstein To: Terry Lambert Cc: Bill Fumerola , hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308063005.GW26621@elvis.mu.org> References: <20020308033724.GZ803@elvis.mu.org> <20020308051520.GB803@elvis.mu.org> <3C885900.E1CB18C0@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C885900.E1CB18C0@mindspring.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Terry Lambert [020307 22:24] wrote: > > If it were just the pcbhash, I think I'd go with a btree... > or to make Alfred happy... a skiplist... ;^). Argh, someone hand me the firehose, Terry seems really thirsty... -- -Alfred Perlstein [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 Mar 7 22:32:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id 5198E37B404 for ; Thu, 7 Mar 2002 22:31:50 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g286V2J48635; Fri, 8 Mar 2002 08:31:03 +0200 (EET) (envelope-from mitko@rila.bg) Date: Fri, 8 Mar 2002 08:31:02 +0200 From: Dimitar Peikov To: Mike Silbersack Cc: freebsd-hackers@freebsd.org Subject: Re: Swapping performance Message-Id: <20020308083102.3d350933.mitko@rila.bg> In-Reply-To: <20020307113735.M2778-100000@patrocles.silby.com> References: <05fe01c1c5e6$6a02e890$2400010a@eight> <20020307113735.M2778-100000@patrocles.silby.com> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002 11:41:28 +0000 (GMT) Mike Silbersack wrote: > > On Thu, 7 Mar 2002, cjp wrote: > > > In order to handle the kruft that occurs, there is the out of memory > > killer, oom_killer. > > Which merrily goes through the list of processes, killing off the low > > priority processes > > until enough memory is free to satisfy what was most recently used. > > It's the loan shark > > repayment program, with OOMKiller performing the function of the > > deliquency reminder. > > FreeBSD overcommits and has a OOMKiller too. You just haven't noticed it > because it's not triggered until you're out of swap space. > > The one thing that _does_ strike me as odd in this comparison is that > Dimitar is using 2.4.17. If that's 2.4.17, I'm surprised that it's > working ok, as everyone on the linux-kernel list seems to be applying > either the -AA or -rmap patches. Of course, if that's SUSE's 2.4.17, I > assume that the -AA patches are already applied. > Well, this SuSE is upgraded 7.1 installation, with no SuSE kernel downloaded from kernel.org). > In any case, we can't make any useful comparisons until Dimitar posts the > source to his test program. > > Dimitar, post the source for the test program! > > Mike "Silby" Silbersack > > > -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 22:33: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id 4CAD237B400; Thu, 7 Mar 2002 22:32:49 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g286WeJ48640; Fri, 8 Mar 2002 08:32:40 +0200 (EET) (envelope-from mitko@rila.bg) Date: Fri, 8 Mar 2002 08:32:40 +0200 From: Dimitar Peikov To: obrien@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance Message-Id: <20020308083240.555163ac.mitko@rila.bg> In-Reply-To: <20020307104205.C61088@dragon.nuxi.com> References: <20020307090707.GC26621@elvis.mu.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> <20020307104205.C61088@dragon.nuxi.com> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002 10:42:05 -0800 "David O'Brien" wrote: > On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote: > > > I've tested it with : > > > > > > cc -O6 -o malloc_test malloc_test.c > > > > That -O6 does not look right from here. Do we support anything over > > -O2? > > > > And how about some source for malloc_test.c? The fact of running > > something at -O6 started some bells ringing. > > Not us, but GCC does not support anything over -O3. -O4 and above are > treated as -O3. I *really* wish people would have a clue with with in > the hell they think they are achieving with -O. Not all > optimizations are appropriate in all cases. And given this level of > optimization and the fact that the linux box is probably a different > version of GCC, I wonder how much of this could be due to the compiler. > > Please rerun your tests with '/usr/bin/time -l' on FreeBSD and however > you achieve the same on Linux. Sorry, no -l on Linux box! > > P.S. are you sure you are swapping, vs. paging? -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 22:35:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d103.as26.nwbl0.wi.voyager.net [169.207.65.231]) by hub.freebsd.org (Postfix) with ESMTP id 4439A37B405 for ; Thu, 7 Mar 2002 22:35:38 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g280e9Nu005918; Fri, 8 Mar 2002 00:40:09 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g280dvsR005912; Fri, 8 Mar 2002 00:39:58 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 8 Mar 2002 00:39:57 +0000 (GMT) From: Mike Silbersack To: Alfred Perlstein Cc: Terry Lambert , Bill Fumerola , Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020308063005.GW26621@elvis.mu.org> Message-ID: <20020308003943.Y3443-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Alfred Perlstein wrote: > * Terry Lambert [020307 22:24] wrote: > > > > If it were just the pcbhash, I think I'd go with a btree... > > or to make Alfred happy... a skiplist... ;^). > > Argh, someone hand me the firehose, Terry seems really thirsty... > > -- > -Alfred Perlstein [alfred@freebsd.org] Ok, I have to ask. What is a skiplist? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 22:46: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id D318037B402 for ; Thu, 7 Mar 2002 22:45:53 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g286jjJ48660 for ; Fri, 8 Mar 2002 08:45:45 +0200 (EET) (envelope-from mitko@rila.bg) Date: Fri, 8 Mar 2002 08:45:21 +0200 From: Dimitar Peikov (by way of Dimitar Peikov ) To: Terry Lambert Subject: Re: Swapping performance Message-Id: <20020308084521.65ef47a8.mitko@rila.bg> In-Reply-To: <3C87BD3D.49BE8105@mindspring.com> References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> <3C87BD3D.49BE8105@mindspring.com> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 07 Mar 2002 11:19:25 -0800 Terry Lambert wrote: > > #include > > #include > > #include > > > > #define MALLOC_SIZE 1024*1024*256 > > > > int main(int argc, char **argv) { > > char *ptr; > > int i, i_count; > > int j; > > > > ptr = (char *) malloc(MALLOC_SIZE); > > bzero(ptr, MALLOC_SIZE); > > The bzero is unnecessary on FreeBSD. Allocated pages start out > zero'ed. Part of the performance issue might be that FreeBSD is > being asked to zero the pages twice, instead of once. > > > i_count = MALLOC_SIZE / 16; > > fprintf(stderr, "*"); > > for (i = 0; i < i_count; i ++) { > > ptr[i >> 4] = ptr[(i >> 3) + 1]++; > ** > Is this what was intended? This will keep the lvalue in the > first 256th of memory, and the rvalue in the first half. > > > } > > fprintf(stderr, "#"); > > for (j = 0; j < i_count; j ++) { > > ptr[j << 4] = ptr[(j >> 3) + 1]++; > > } > > This looks more right... the lvalue hits every page, and the > rvalue is (still) limited to the first half of memory. > > > > > free(ptr); > > Try just exiting; free() might be trying to be too clever > on FreeBSD. Doing the same on both platforms should not > invalidate the test. > > > return 0; > > } > > It might be more interesting to mmap() anonymous memory > (e.g. out of /dev/zero), rather than using malloc, and > then use that memory the same way, instead (it's swap > backed, as well). Giving it an madvise, to tell it your > intended access pattern would also be useful. > > I'm also not sure if the Linux VM "prefers" code pages to > data pages. It could very well be the case that it does; > that would result in a potentiall much better performance > on this test. It would also be useful to know the relative > load addresses in the code; FreeBSD might end up having the > code compiled to be split across cache lines, etc, where > the Linux version of the code does not. > > As other people pointed out, the "speed" of the swap > partition is also potentially an issue. Make sure that > FreBSD and Linux are using the same region relative to the > drive spindle for swap. > > In addition, you should verify that the hardware is, in > fact, identical. The easiest way to do this would be to > swap drives in the machines to see if the affects the results, > and -- while they are out -- verify that the drives themselves > are as identical as possible. > > You might also want to turn *off* the FreeBSD "harvesting > entropy", if it's doing it on disk interrupts or other > interrupts inportant to the code path. > > If all this still has the FreeBSD slower, it still, > unfortunately, isn't conclusive, one way or the other; it > could still be that what you are testing is not the swap > performance of FreeBSD, but, perhaps, the differences in > the disk device drivers for the particular controller you > ended up with in the motherboard lottery. > > It would also be useful to see the verbose dmesg output > for both systems for the devices involved in the test code > path. It may be that FreeBSD is working around a known > controller issue (e.g. the CMD640B IDE controller), etc., > where interleaved I/O's are being permitted by Linux, but > not by FreeBSD, for fear of data corruption. > > Finally... you might want to try the Linux version of the > program on FreeBSD, rather than using a native FreeBSD > version. THis should account for many things, including > the sync'ing of mapping regions, if that's a factor. > > All this information is useless to me personally; please > post to the list, if you post at all, thanks. > > -- Terry In fact I was starting these tests as a result of heavy mathematical operations (composing, compacting, minimizing automata's with a lot of states and much much more arcs between them). Our application that deals with this is written in C and is not optimized to any particular OS. If I had to optimize it for Linux or FreeBSD there certainly would be major changes, but our team uses not only *BSD. So when we start to build our automata's some of them require more than 1G to be created and most of the memory has temporary usage (there are most malloc, realloc, calloc, free operatons) because of atomic operations in algorithms for making automata's. And when we saw that one think on Linux was done for a few hours, but on FreeBSD much, much more, I start tests to investigate where the problem is. This test (malloc_test) is the first think that gives serious difference and I thought that the problem is in swapping or paging. I understand that there are a lot of optimizations that can be made if have more time for that, but even in this case I don't think that the things would be much more bright for the FreeBSD. -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 22:52:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [194.141.1.31]) by hub.freebsd.org (Postfix) with ESMTP id EFC5137B400 for ; Thu, 7 Mar 2002 22:52:26 -0800 (PST) Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with SMTP id g286oWJ48670; Fri, 8 Mar 2002 08:50:33 +0200 (EET) (envelope-from mitko@rila.bg) Date: Fri, 8 Mar 2002 08:50:32 +0200 From: Dimitar Peikov To: Matthew Dillon Cc: drwilco@drwilco.net, silby@silby.com, bifrost@minions.com, cjp@sandstorm.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance Message-Id: <20020308085032.69568968.mitko@rila.bg> In-Reply-To: <200203071912.g27JC3A68645@apollo.backplane.com> References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> <200203071912.g27JC3A68645@apollo.backplane.com> Reply-To: mitko@rila.bg Organization: Rila Solutions X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002 11:12:03 -0800 (PST) Matthew Dillon wrote: > Hmm. well, I don't think this test is very meaningful. If the > machines have 256M of ram and the test is doing a two-swipe access of > 256M of VM. This doesn't represent any real test and I would not be > surprised by the difference in timing. > > It all comes down to how much real memory Linux and FreeBSD give to > the process and there is no right answer to the question because it's > a tradeoff. An OS does not magically know that only one process will > ever need all of the machine's resources, for example, so different > operating systems are going to have very different characteristics > under these sorts of conditions. One might give over more memory, > another might want to avoid completely blowing away its other caches. > One might work well for linux in a one-process memory test could fail > miserably in a multi-process memory test, for example, or with a > different pattern of memory accesses, or a different load split > between cpu, memory, and disk I/O. > > You (Dimitar and others) also need to be careful about making broad > generalizations. Testing pure swapping performance with the below > program implies that you intend to run applications that will need to > swap heavily (for example, big mathmatical applications). If you > don't intend to run applications that will need to swap heavily then > this test is fairly meaningless as a measure of performance. > I don't make any generalizations if I can't prove that for myself. If I increase the amount of MALLOC_SIZE in this test, the results goes much more worse. Even in case that I have 25 processes running concurently with this task (there is no X, almost empty system), the program runs but ... > Another point that I should bring up in regards to swap performance: > systems that require good swap performance will almost always have > more then one physical disk to swap to. FreeBSD is very good at > paging to swap with a single disk, but it kicks ass paging to swap > with multiple disks because it implements a very good interleaving > algorithm. > > -Matt > Matthew Dillon > > > :Am I the only one who saw that he attached it to his 1st mail? > : > :Here you go: > : > :#include > :#include > :#include > : > :#define MALLOC_SIZE 1024*1024*256 > : > :int main(int argc, char **argv) { > : char *ptr; > : int i, i_count; > : int j; > : > : ptr = (char *) malloc(MALLOC_SIZE); > : bzero(ptr, MALLOC_SIZE); > : > : i_count = MALLOC_SIZE / 16; > : fprintf(stderr, "*"); > : for (i = 0; i < i_count; i ++) { > : ptr[i >> 4] = ptr[(i >> 3) + 1]++; > : } > : fprintf(stderr, "#"); > : for (j = 0; j < i_count; j ++) { > : ptr[j << 4] = ptr[(j >> 3) + 1]++; > : } > : > : free(ptr); > : return 0; > :} -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 22:52:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 7E0C337B400 for ; Thu, 7 Mar 2002 22:52:39 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 62940AE1FC; Thu, 7 Mar 2002 22:52:39 -0800 (PST) Date: Thu, 7 Mar 2002 22:52:39 -0800 From: Alfred Perlstein To: Mike Silbersack Cc: Terry Lambert , Bill Fumerola , hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308065239.GX26621@elvis.mu.org> References: <20020308063005.GW26621@elvis.mu.org> <20020308003943.Y3443-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020308003943.Y3443-100000@patrocles.silby.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Mike Silbersack [020307 22:35] wrote: > > On Thu, 7 Mar 2002, Alfred Perlstein wrote: > > > * Terry Lambert [020307 22:24] wrote: > > > > > > If it were just the pcbhash, I think I'd go with a btree... > > > or to make Alfred happy... a skiplist... ;^). > > > > Argh, someone hand me the firehose, Terry seems really thirsty... > > > > -- > > -Alfred Perlstein [alfred@freebsd.org] > > Ok, I have to ask. What is a skiplist? Do a web search. It's basically a way to have a linked list that you can do nearly a binary search on, however it costs several additional linkages. It was also the "pool on the roof" trick we'd do to the new guy at clickarray. "hey, I need a fast way to do X.." "dude, try a skiplist.." "a what?" "a skiplist, look it up!" "ummm... ok.." after reading it... "that's not even close to what i need!" "lol, have you tried the pool on the roof?" -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Mar 7 23:14: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d103.as26.nwbl0.wi.voyager.net [169.207.65.231]) by hub.freebsd.org (Postfix) with ESMTP id 1878737B404 for ; Thu, 7 Mar 2002 23:14:05 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g281IaNu006076; Fri, 8 Mar 2002 01:18:37 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g281IZ6Z006073; Fri, 8 Mar 2002 01:18:36 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 8 Mar 2002 01:18:35 +0000 (GMT) From: Mike Silbersack To: Alfred Perlstein Cc: Terry Lambert , Bill Fumerola , Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020308065239.GX26621@elvis.mu.org> Message-ID: <20020308011112.N6029-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Alfred Perlstein wrote: > Do a web search. It's basically a way to have a linked list that > you can do nearly a binary search on, however it costs several > additional linkages. It was also the "pool on the roof" trick > we'd do to the new guy at clickarray. Hm, did you guys then invent the "cache-optimized concurrent skip list" after people got wise? :) http://sourceforge.net/projects/skiplist I found the original paper on skiplists, I guess I'll give it a read so that if anyone tries that trick on me I'll know better. :) "Have you tried a skiplist?" "Regular, or cache-optimized concurrent?" Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 0: 0:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 5C44137B416 for ; Fri, 8 Mar 2002 00:00:37 -0800 (PST) Received: from localhost (root@localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.2/8.12.2) with ESMTP id g2880YZR033379 for ; Fri, 8 Mar 2002 18:30:34 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Remote GDB in -stable.. From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 Mar 2002 19:30:34 +1130 Message-Id: <1015574434.456.35.camel@chowder.gsoft.com.au> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm trying to debug a KLD in -stable and I can't get gdb to show me a stack trace with the extra info (variable names, line numbers etc..) I've built a debugging kernel and copied it to the debug machine and I can connect to the machine to be debugged OK, but none of the back traces have the extra info in them. I even read the handbook, but to no avail :( Anyone have any handy tips? -- --- 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 Mar 8 0:44:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 2192E37B405 for ; Fri, 8 Mar 2002 00:44:31 -0800 (PST) Received: from davidwnt (davidwnt.viasoft.com.cn [192.168.1.239]) by mail.viasoft.com.cn (8.9.3/8.9.3) with SMTP id QAA22029; Fri, 8 Mar 2002 16:53:40 +0800 Message-ID: <00e601c1c67d$5e45d110$ef01a8c0@davidwnt> From: "David Xu" To: , "Matthew Dillon" Cc: , , , , References: <20020307095452.D18855-100000@frond.minions.com><5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net><200203071912.g27JC3A68645@apollo.backplane.com> <20020308085032.69568968.mitko@rila.bg> Subject: Re: Swapping performance Date: Fri, 8 Mar 2002 16:43:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have done some tests on my machine, the machine has both Linux and = FreeBSD installed, the following is the data: MALLOC_SIZE =3D 1024*1024*400 has bzero Red Linux 6.2(kernel 2.2.14) 5.09user 5.62system 1:15.33elapsed 14%CPU (0avgtext+0avgdata = 0maxresident)k 0inputs+0outputs (115298major+206560minor)pagefaults 161471swaps 4.70user 5.73system 1:17.13elapsed 13%CPU (0avgtext+0avgdata = 0maxresident)k 0inputs+0outputs (116402major+206554minor)pagefaults 160731swaps 4.88user 5.68system 1:17.04elapsed 13%CPU (0avgtext+0avgdata = 0maxresident)k 0inputs+0outputs (117309major+206550minor)pagefaults 161273swaps FreeBSD 4.5-STABLE 5.489u 6.815s 1:25.96 14.2% 4+425738k 0+0io 12937pf+0w 5.342u 6.728s 1:24.40 14.2% 4+414152k 0+0io 12929pf+0w 5.073u 6.815s 1:28.58 13.4% 3+408011k 1+0io 12920pf+0w ------- MALLOC_SIZE =3D 1024*1024*400 no bzero Red Linux 6.2(kernel 2.2.14) 2.01user 4.16system 0:24.79elapsed 24%CPU (0avgtext+0avgdata = 0maxresident)k 0inputs+0outputs (5127major+103353minor)pagefaults 59369swaps 1.82user 4.31system 0:24.90elapsed 24%CPU (0avgtext+0avgdata = 0maxresident)k 0inputs+0outputs (4897major+103339minor)pagefaults 59250swaps 1.76user 4.29system 0:24.51elapsed 24%CPU (0avgtext+0avgdata = 0maxresident)k 0inputs+0outputs (5814major+103343minor)pagefaults 59360swaps FreeBSD 4.5-STABLE 2.802u 3.604s 0:23.20 27.5% 4+415497k 0+0io 81pf+0w 2.975u 3.434s 0:23.58 27.1% 4+412937k 0+0io 83pf+0w 2.871u 3.480s 0:23.91 26.5% 4+413607k 0+0io 83pf+0w /* * vmstress.c */ #include #include #include #define MALLOC_SIZE 1024*1024*400 int main(int argc, char **argv) { char *ptr; int i, i_count; int j; ptr =3D (char *) malloc(MALLOC_SIZE); bzero(ptr, MALLOC_SIZE); i_count =3D MALLOC_SIZE / 16; fprintf(stderr, "*"); for (i =3D 0; i < i_count; i ++) { ptr[i >> 4] =3D ptr[(i >> 3) + 1]++; } fprintf(stderr, "#"); for (j =3D 0; j < i_count; j ++) { ptr[j << 4] =3D ptr[(j >> 3) + 1]++; } free(ptr); return 0; } Unfortunately, I havn't Linux kernel 2.4.17 installed, is Linux kernel = 2.4.17 faster? -- David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 1:56:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from atlantis.homeip.net (a30032.upc-a.chello.nl [62.163.30.32]) by hub.freebsd.org (Postfix) with SMTP id 8906837B405 for ; Fri, 8 Mar 2002 01:56:34 -0800 (PST) Received: (qmail 11509 invoked from network); 8 Mar 2002 09:56:32 -0000 Received: from jeremy.ourhome.nl (192.168.1.4) by atlantis.ourhome.nl with SMTP; 8 Mar 2002 09:56:32 -0000 Date: Fri, 8 Mar 2002 10:56:32 +0100 From: Willem van Engen To: freebsd-hackers@freebsd.org Subject: Re: Remote GDB in -stable.. Message-Id: <20020308105632.7fbfa098.wvengen@stack.nl> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08 Mar 2002 19:30:34 +1130 "Daniel O'Connor" wrote: > I'm trying to debug a KLD in -stable and I can't get gdb to show me a > stack trace with the extra info (variable names, line numbers etc..) > > I've built a debugging kernel and copied it to the debug machine and I > can connect to the machine to be debugged OK, but none of the back > traces have the extra info in them. > > I even read the handbook, but to no avail :( > > Anyone have any handy tips? Did you read the developers' handbook, chapter 16? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x5013.html - Willem To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 1:59:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id BB34337B400 for ; Fri, 8 Mar 2002 01:59:40 -0800 (PST) Received: from pool0067.cvx21-bradley.dialup.earthlink.net ([209.179.192.67] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jHA1-0004ya-00; Fri, 08 Mar 2002 01:59:38 -0800 Message-ID: <3C888B6F.D8BFF2A2@mindspring.com> Date: Fri, 08 Mar 2002 01:59:11 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Alfred Perlstein , Bill Fumerola , hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times References: <20020308011112.N6029-100000@patrocles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG If you want code, go out to the DDJ archive on UUNET; it has all the source code from the DDJ article from 1996 or so... -- Terry Mike Silbersack wrote: > > On Thu, 7 Mar 2002, Alfred Perlstein wrote: > > > Do a web search. It's basically a way to have a linked list that > > you can do nearly a binary search on, however it costs several > > additional linkages. It was also the "pool on the roof" trick > > we'd do to the new guy at clickarray. > > Hm, did you guys then invent the "cache-optimized concurrent skip list" > after people got wise? :) > > http://sourceforge.net/projects/skiplist > > I found the original paper on skiplists, I guess I'll give it a read so > that if anyone tries that trick on me I'll know better. :) > > "Have you tried a skiplist?" > "Regular, or cache-optimized concurrent?" > > Mike "Silby" Silbersack > > 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 Mar 8 2: 3:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 2DF7337B400 for ; Fri, 8 Mar 2002 02:03:24 -0800 (PST) Received: from pool0067.cvx21-bradley.dialup.earthlink.net ([209.179.192.67] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jH8b-0004JI-00; Fri, 08 Mar 2002 01:58:10 -0800 Message-ID: <3C888AF9.71F87D03@mindspring.com> Date: Fri, 08 Mar 2002 01:57:13 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Xu Cc: mitko@rila.bg, Matthew Dillon , drwilco@drwilco.net, silby@silby.com, bifrost@minions.com, cjp@sandstorm.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance References: <20020307095452.D18855-100000@frond.minions.com><5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net><200203071912.g27JC3A68645@apollo.backplane.com> <20020308085032.69568968.mitko@rila.bg> <00e601c1c67d$5e45d110$ef01a8c0@davidwnt> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Xu wrote: > I have done some tests on my machine, the machine has both > Linux and FreeBSD installed, the following is the data: > > MALLOC_SIZE = 1024*1024*400 > has bzero > > Red Linux 6.2(kernel 2.2.14) > 5.09u 5.62s 1:15.33 14% > 4.70u 5.73s 1:17.13 13% > 4.88u 5.68s 1:17.04 13% > > FreeBSD 4.5-STABLE > 5.489u 6.815s 1:25.96 14.2% 4+425738k 0+0io 12937pf+0w > 5.342u 6.728s 1:24.40 14.2% 4+414152k 0+0io 12929pf+0w > 5.073u 6.815s 1:28.58 13.4% 3+408011k 1+0io 12920pf+0w OK. > MALLOC_SIZE = 1024*1024*400 > no bzero > > Red Linux 6.2(kernel 2.2.14) > 2.01u 4.16s 0:24.79 24% > 1.82u 4.31s 0:24.90 24% > 1.76u 4.29s 0:24.51 24% > > FreeBSD 4.5-STABLE > 2.802u 3.604s 0:23.20 27.5% 4+415497k 0+0io 81pf+0w > 2.975u 3.434s 0:23.58 27.1% 4+412937k 0+0io 83pf+0w > 2.871u 3.480s 0:23.91 26.5% 4+413607k 0+0io 83pf+0w I expected this. The bzero() has two effects: 1) It presets the LRU list to inverse sequential order 2) It faults the pages in order, with a byte-by-byte write through So when we take the bzero out, the FreeBSD version is faster. I think if you were to mmap() and madvise() sequential before the bzero, and madvise random after, that the FreeBSD would end up faster even with the bzero present. Even so, the earlier observations on the slopes of the page selection curves and the domains, mean that the access pattern is pessimal. Actually, given the LRU ordering as a result of the bzero, I would expect that if you reversed the access pattern, the FreeBSD case would be significantly faster, since it would hit cache for all of the pages until it hit the first swap backed page. You could simulate this by doing a touch backwards, replacing the single bzero: /* reverse LRU list */ i_count = MALLOC_SIZE/4096; /* pages*/ for( i = i_count - 1; i >= 0; i--) bzero(&ptr[ i<<12], 4096); In other words, my observations on page access and Matt's observations on what was being measured are overall correct. The mmap() would also allow you to make FreeBSD do what Linux does; I'm not certain that this would work with the malloc'ed pages, though it should (PHK would be a better judge). Basically, replace the bzero() with: madvise(ptr, MALLOC_SIZE, MADV_SEQUENTIAL|MADV_NOSYNC); bzero(ptr, MALLOC_SIZE); madvise(ptr, MALLOC_SIZE, MADV_RANDOM|MADV_NOSYNC); If you invert the LRU list, I would also suggest: madvise(ptr, MALLOC_SIZE, MADV_RANDOM|MADV_NOSYNC|MADV_WILLNEED); Though WILLNEED and RANDOM may not get along completely. 8-(. I would say "WILLNEED is more important, since it keeps the PTEs in place. The NOSYNC turns off the explicit write-through of pages; this is most likely the slowdown relative to Linux, since Linux maintains explicit coherency between the VM and buffer cache, instead of implicit, so the "write through" case in the Linux case is not the default; this is probably the mail thing that is making the bzero case slower on FreeBSD vs. Linux. > Unfortunately, I havn't Linux kernel 2.4.17 installed, is > Linux kernel 2.4.17 faster? Higher version numbers usually mean more speed. Unfortunately, there are two main Linux VM systems these days, and which one you get really depends on *both* the kernel version and which distribution you get. We need to be very clear here on which Linux is being tested, since just saying "Linux" is no longer enough, now that they have forked their kernel along several important axis. VM speed, in particular, is going to vary widely by load and vendor. Oh. Ugh. Almost forgot. I think very large mappings in Linux get 4M pages. This takes them ot of the TLB collision domain with ordinary pages (most Pentium class CPUs have 16 4k data page TLBs, 16 4k code page TLBs, and 8 4M page TLBs that are seperate. TLB thrashing can account for as much as 14% of performance, which is one of the reasons we went to 4M pages for all the mbufs at ClickArray last year. Doing the mapping off of /dev/zero *should* get the 4M page mappings on FreeBSD... again, malloc may take care of this already, though I think it doesn't necessarily mmap off of /dev/zero, but we *are* talking some very large allocations here... PHK is the guy to ask on that, again. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 2:17:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by hub.freebsd.org (Postfix) with SMTP id 48F0237B416 for ; Fri, 8 Mar 2002 02:17:54 -0800 (PST) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Fri Mar 8 02:17:42 2002 To: "Robert Watson" Date: Fri, 08 Mar 2002 15:47:42 +0530 From: "Rajesh P Jain" Message-ID: Mime-Version: 1.0 Cc: freebsd-hackers@FreeBSD.org X-Sent-Mail: on Reply-To: rpjain_1977@eudoramail.com X-Mailer: MailCity Service Subject: Re: BPF - Locally Generated Packet Reception X-Sender-Ip: 203.197.138.199 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, Thank you very much for your reply. BIOCSSEESENT ioctl works fine with the Ethernet interface. But this ioctl does not work for the 'tun' (user PPP of FreeBSD) device. I have seen bpf code also. 'bpfioctl' function sets the d->bd_seesent flag to the value which is passed for this BIOCSSEESENT. In bpf_mtap also checks for this variable and ( m->m_pkthdr.rcvif == NULL ) As you had told in your earlier mail, the received interface is not null for our case. Any help on this would be greatly appreciated. -Raj -- On Wed, 6 Mar 2002 23:08:55 Robert Watson wrote: > >It could be that this fails for interfaces that perform hardware loopback, >since it relies on the behavior of software loop. There may also be some >other circumstances where this occurs. Basically, the BPF device can tell >it's "locally sourced" because it has a NULL interface pointer associated >with it. If the packet ends up with a none-NULL interface pointer for >some reason, it will be considered a non-locally sourced packet. In >practice, we've used this successfully on a variety of ethernet devices -- >which interface type are you using? > >Robert N M Watson FreeBSD Core Team, TrustedBSD Project >robert@fledge.watson.org NAI Labs, Safeport Network Services > >On Wed, 6 Mar 2002, Rajesh P Jain wrote: > >> Hi, >> In the BPF - Berkeley Packet Filter, when a file descriptor is associated to an interface to send and receive packets, there is an ioctl parameter "BIOCSSEESENT", which is by default set to 1. Hence the packets both from "remote systems" and "locally generated" are received. >> >> If "locally generated" packets needs to be filtered, we can use the option "BIOCSSEESENT" and set the value to 0. >> >> But even after setting this value to 0 (using the ioctl call), the "locally generated" packets are received. >> >> Am I missing something ? Plese throw light on this issue. >> >> TIA >> Raj >> >> >> Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-hackers" in the body of the message >> > > Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 5:30:48 2002 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 C0CFA37B423; Fri, 8 Mar 2002 05:30:21 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g28DThD67687; Fri, 8 Mar 2002 08:29:43 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 8 Mar 2002 08:29:42 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bill Fumerola Cc: Julian Elischer , Terry Lambert , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times In-Reply-To: <20020308051520.GB803@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Bill Fumerola wrote: > On Thu, Mar 07, 2002 at 11:03:19PM -0500, Robert Watson wrote: > > A couple of comments: > > > > - You can always cache the pcb the first time it's used, and then have it > > available for future use. I agree with your concerns about generating > > it every time -- that would be a disaster for routers where no packets > > are even delivered locally. :-) > > you can't cache it and make it available for future use without making > the invasive changes that i mention: Ah, I misread your e-mail. I was interested in caching it within ipfw, but not exporting the cached entry to be reused in ip_input(). My personal feeling is that the notion of uid/gid rules doesn't really fit the model very well at all, but it falles into the category of "interesting hack". > with ipfw cacheing the pcb lookup + credential check and w/o terry's > patch, the worst case would be a ruleset with any uid/gid rules: a pcb > lookup being done twice (once ever in ipfw, once in the protocol > handler). > > that's really not so bad compared with the current behavior with uid/gid > rules where the lookup is done of a lot of times (as many uid/gid rules > you walk through before you match) in ipfw and once in the protocol > handler. Sounds like we agree. > > - The uid/gid code is broken for a number of important applications, > > including SSH forwarding, because SSHd binds the socket using a root > > credential rather than the user credential. Arguably, this is a bug > > with SSHd, and it also breaks a number of other things including the MAC > > support we're adding to 5.0-CURRENT. Also, it had some *evil* bugs > > involving NFS that I recently fixed in 5.0-CURRENT, where sockets were > > rebound using the credential of the user making the VFS operation, > > resulting in ipfw uid/gid rules dropping/rate-limiting file system > > requests for all users. For those running into the whole sshd tunnel > > and ident problem, it's the same cause. > > i would like to make my cache have the proper credential(s) rather then > just cache the current socket credentials cr_uid, if that's wrong. > > please let me know privately just what exactly i should be comparing > against (or functions i should be using, if an API exists now) in > -current with the changes to credentials. > > when i mfc the cache, i'll just keep the current uid comparing behavior. I don't think there is a "proper" set of credentials in most cases. Consider the following cases: (1) Socket-to-socket communication (loop-back packet to another socket) (2) Stack-to-socket communication (icmp version of EHOSTUNREACH) (3) Socket-to-stack communication (resulting in stack response such as icmp version of EHOSTUNREACH) (4) Socket to interface communication (outbound packet to remote host) (5) Interface to socket communication (inbound packet from remote host) (6) Stack to interface communication (connection refused icmp) (7) Interface to stack communication (tcp SYN that will be refused) (8) Interface to interface communication (routed packet) The only situations in which you could argue a credential might be involved are the cases including a socket. Then the question arises: what credential is the right credential? Observe that a socket may be in use by a number of processes, and even the kernel. A credential is always available when the socket is created, and that's generally cached as so->so_cred. However, after that point, the notion of an active credential is ambiguous. When a packet is created on the socket by a process (kernel or otherwise), then potentially that is the "proper" credential for out-going authorization. However, when a packet is received for a socket, you don't know yet which process will be receiving the data, since that's done asynchronously by one of potentially many different credentials listening on the socket. In fact, it may *never* be read. And it gets even more confusing with stream sockets, where different credentials might potentially read the same data. Another pointer: for loopback communication, potentially *two* sockets will match the same packet. Part of what's going on here is that a socket isn't really a subject (credential). It's an object. Subjects put data (either as part of a stream or as datagrams) into the object, and that generates new objects that can't be directly referenced by a subject except through another object (be it another socket, bpf device, whatever). In the MAC implementation, we recognize that a socket is an object, and provide it with a label, which may be managed using socket options. Datagrams generated from the socket generally inherit the same label, although individual policies might do different things. When a datagram is being considered for delivery to a socket, the labels of the mbuf and socket can be used in two ways: (1) to affect the pcb match, and (2) to perform access control on the delivery. This allows policies maximum flexibility in both defining the notion of a "match", and in blocking inappropriate but matching traffic. Likewise, we've hypothesized having ipfw rules that use the labels. That said, I think moving to having uids/gids on sockets may not be a good idea, because most applications would simply not understand how to change them (and the mode on the socket). Part of the confusion would come also from the fact that some sockets have filesystem representations: because a socket is not the same as its filesystem representation, there would be two seperate owner/group/mode sets, and that can be confusing for the developer. We accept that confusion for the MAC code, because it's required, but for uid/gid rules, just using a cached credential may be a lot easier. So what I'm suggesting is that you stick with the so_cred model, because it's easy, but that we fix applications like SSH, which Do The Wrong Thing, and kernel facilities that fall into the same boat. I've already fixed the NFS client so it caches the mount-time credential and uses that to rebind the socket, which differs from the old behavior, where the VOP cred was used to rebind the socket. If you had ipfw uid/gid rules that affected the uid or gid that happened to be on hand, from then until the point when the socket got disconnected, you'd have your NFS mount impacted by the rules. We ran into this with the MAC code: if the NFS mount was over a high integrity interface, and the connection broke (TCP, or whatever), and the first user to read from the filesystem was low integrity, NFS would use the low integrity credential to rebind the socket, and then packets would no longer be allowed out the high integrity interface. So NFS would keel over with EPERM. This also, until recently, caused an mbuf leak because NFS took mbuf delivery failures poorly. :-) I am concerned netsmb might have some of the same issues, and need to look at it, although I haven't yet. 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 Fri Mar 8 8:45:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from penfold.unixbeard.net (seshat.demon.co.uk [62.49.6.120]) by hub.freebsd.org (Postfix) with ESMTP id EE2D537B400 for ; Fri, 8 Mar 2002 08:44:39 -0800 (PST) Received: by penfold.unixbeard.net (Postfix, from userid 1000) id C2A165D02D; Fri, 8 Mar 2002 16:41:15 +0000 (GMT) To: perlbug@perl.com Subject: bug in Time::Local (can't handle 1901) Cc: hackers@FreeBSD.org Message-Id: <20020308164115.C2A165D02D@penfold.unixbeard.net> Date: Fri, 8 Mar 2002 16:41:15 +0000 (GMT) From: mstevens@penfold.unixbeard.net (Michael Stevens) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a bug report for perl from mstevens@etla.org, generated with the help of perlbug 1.26 running under perl 5.00503. ----------------------------------------------------------------- [Please enter your report here] michaels@host:~> perl -MTime::Local -e 'timegm(0,0,0, 01, 01, 1901)' Can't handle date (0, 0, 0, 1, 1, 1) at -e line 1 This seems contrary to the documentation which suggests that this is a perfectly valid date that will be handled as 1901. Tested with perl 5.6.1. [Please do not change anything below this line] ----------------------------------------------------------------- --- Site configuration information for perl 5.00503: Configured by markm at Sun Mar 5 13:39:27 SAST 2000. Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=freebsd, osvers=4.0-current, archname=i386-freebsd uname='FreeBSD freefall.FreeBSD.org 4.0-current FreeBSD 4.0-current #0: $Date$' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='undef', gccversion=2.95.2 19991024 (release) cppflags='' ccflags ='' stdchar='char', d_stdstdio=undef, usevfork=true intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -lperl -lm ' libpth=/usr/lib libs=-lm -lc -lcrypt libc=, so=so, useshrplib=true, libperl=libperl.so.3 Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/lib' cccdlflags='-DPIC -fpic', lddlflags='-Wl,-E -shared -lperl -lm ' Locally applied patches: --- @INC for perl 5.00503: /usr/libdata/perl/5.00503/mach /usr/libdata/perl/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd /usr/local/lib/perl5/site_perl/5.005 . --- Environment for perl 5.00503: HOME=/home/mstevens LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/mstevens/bin PERL_BADLANG (unset) SHELL=/usr/local/bin/zsh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 10:11:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d59.as26.nwbl0.wi.voyager.net [169.207.65.187]) by hub.freebsd.org (Postfix) with ESMTP id 70FB237B402 for ; Fri, 8 Mar 2002 10:11:35 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g28CFwNu008102; Fri, 8 Mar 2002 12:15:58 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g28CFZeh008099; Fri, 8 Mar 2002 12:15:54 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 8 Mar 2002 12:15:35 +0000 (GMT) From: Mike Silbersack To: David Xu Cc: mitko@rila.bg, Matthew Dillon , , , , Subject: Re: Swapping performance In-Reply-To: <00e601c1c67d$5e45d110$ef01a8c0@davidwnt> Message-ID: <20020308121400.Q8029-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Mar 2002, David Xu wrote: > Unfortunately, I havn't Linux kernel 2.4.17 installed, is Linux kernel 2.4.17 faster? > -- > David Xu Well, the VM in it is certainly different. Since he's using SUSE 2.4.17, I believe that would mean that he's actually using 2.4.17-AA; you'd want to try that to get the best possible comparison. (Actually, I guess suse 2.4.17 is what you'd want, but I would assume that it is a pain to install on redhat.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 13:46:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id C2F6C37B402 for ; Fri, 8 Mar 2002 13:46:28 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308214628.OFHI1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Fri, 8 Mar 2002 21:46:28 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g28LkRi14094; Fri, 8 Mar 2002 13:46:27 -0800 (PST) (envelope-from cjc) Date: Fri, 8 Mar 2002 13:46:27 -0800 From: "Crist J. Clark" To: Michael Stevens Cc: perlbug@perl.com, hackers@FreeBSD.ORG Subject: Re: bug in Time::Local (can't handle 1901) Message-ID: <20020308134627.F57999@blossom.cjclark.org> References: <20020308164115.C2A165D02D@penfold.unixbeard.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020308164115.C2A165D02D@penfold.unixbeard.net>; from mstevens@seshat.demon.co.uk on Fri, Mar 08, 2002 at 04:41:15PM +0000 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 04:41:15PM +0000, Michael Stevens wrote: > This is a bug report for perl from mstevens@etla.org, > generated with the help of perlbug 1.26 running under perl 5.00503. > > > ----------------------------------------------------------------- > [Please enter your report here] > > michaels@host:~> perl -MTime::Local -e 'timegm(0,0,0, 01, 01, 1901)' > Can't handle date (0, 0, 0, 1, 1, 1) at -e line 1 > > This seems contrary to the documentation which suggests that this is > a perfectly valid date that will be handled as 1901. It so happens that the 2^31 seconds before the UNIX epcoh falls on Fri Dec 13 20:45:52 UTC 1901. $ date -ju 190112132045.52 Fri Dec 13 20:45:52 UTC 1901 $ date -ju 190112132045.51 date: nonexistent time $ date -ju 190112132045.52 +%s -2147483648 $ dc 2 31^ p 2147483648 mktime(3) will choke on dates before Fri Dec 13 20:45:52 UTC 1901. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@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 Mar 8 14: 0:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 3092837B416 for ; Fri, 8 Mar 2002 14:00:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308220013.CTTN2951.rwcrmhc53.attbi.com@InterJet.elischer.org> for ; Fri, 8 Mar 2002 22:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA50238 for ; Fri, 8 Mar 2002 13:59:57 -0800 (PST) Date: Fri, 8 Mar 2002 13:59:56 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Subject: Where are the TCP patches for 4.4? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I remember someone saying that they were going to make a repository for patches for releases. In particular I[m looking at teh TCP patches that fixed the slow transfers in some situations. Thes changes were put in before 4.5 so I want to find them to upgrade some production 4.4 machines. I have the diffs for 4.4p9 but they seem to be only security fixes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 14:14:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from squall.waterspout.com (squall.waterspout.com [208.13.56.12]) by hub.freebsd.org (Postfix) with ESMTP id 22FEF37B42C for ; Fri, 8 Mar 2002 14:14:20 -0800 (PST) Received: by squall.waterspout.com (Postfix, from userid 1050) id A1C1D9B08; Fri, 8 Mar 2002 17:14:12 -0500 (EST) Date: Fri, 8 Mar 2002 17:14:12 -0500 From: Will Andrews To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: Where are the TCP patches for 4.4? Message-ID: <20020308221412.GK53073@squall.waterspout.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.26i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 08, 2002 at 01:59:56PM -0800, Julian Elischer wrote: > > I remember someone saying that they were going to make a repository > for patches for releases. > > In particular I[m looking at teh TCP patches that fixed the slow transfers > in some situations. Thes changes were put in before 4.5 > so I want to find them to upgrade some production 4.4 machines. > > I have the diffs for 4.4p9 but they seem to be only security fixes. That's the purpose of RELENG_4_*. No other patches are applied, or have been to my knowledge. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 14:27:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 8A62837B416 for ; Fri, 8 Mar 2002 14:26:48 -0800 (PST) Received: (qmail 27400 invoked from network); 8 Mar 2002 22:26:26 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 8 Mar 2002 22:26:26 -0000 Date: Fri, 8 Mar 2002 17:26:25 -0500 (EST) From: Kenneth Culver To: Julian Elischer Cc: hackers@FreeBSD.ORG Subject: Re: Where are the TCP patches for 4.4? In-Reply-To: Message-ID: <20020308172538.Q27342-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG If you want, I can make you some patches, I think I still remember when they went in... however I can't do any more than that... and I suspect since you're one of the developers, you already have a CVS repository and can do it yourself :-D Ken On Fri, 8 Mar 2002, Julian Elischer wrote: > > I remember someone saying that they were going to make a repository > for patches for releases. > > In particular I[m looking at teh TCP patches that fixed the slow transfers > in some situations. Thes changes were put in before 4.5 > so I want to find them to upgrade some production 4.4 machines. > > I have the diffs for 4.4p9 but they seem to be only security fixes. > > > > > 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 Mar 8 15: 1: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id E136537B41A for ; Fri, 8 Mar 2002 15:00:20 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308230020.QNBU1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 23:00:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA50510; Fri, 8 Mar 2002 14:48:53 -0800 (PST) Date: Fri, 8 Mar 2002 14:48:53 -0800 (PST) From: Julian Elischer To: Kenneth Culver Cc: hackers@FreeBSD.ORG Subject: Re: Where are the TCP patches for 4.4? In-Reply-To: <20020308172538.Q27342-100000@alpha.yumyumyum.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Mar 2002, Kenneth Culver wrote: > If you want, I can make you some patches, I think I still remember when > they went in... however I can't do any more than that... and I suspect > since you're one of the developers, you already have a CVS repository and > can do it yourself :-D I'm sure I can get them, I'm just trying to find who it was that said they were compiling a set of "good patches for 4.4" > > Ken > > On Fri, 8 Mar 2002, Julian Elischer wrote: > > > > > I remember someone saying that they were going to make a repository > > for patches for releases. > > > > In particular I[m looking at teh TCP patches that fixed the slow transfers > > in some situations. Thes changes were put in before 4.5 > > so I want to find them to upgrade some production 4.4 machines. > > > > I have the diffs for 4.4p9 but they seem to be only security fixes. > > > > > > > > > > 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 Fri Mar 8 15:42: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from brea.mc.mpls.visi.com (brea.mc.mpls.visi.com [208.42.156.100]) by hub.freebsd.org (Postfix) with ESMTP id 7CF1C37B400 for ; Fri, 8 Mar 2002 15:41:55 -0800 (PST) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by brea.mc.mpls.visi.com (Postfix) with ESMTP id AEE1D2DDBBE; Fri, 8 Mar 2002 17:41:54 -0600 (CST) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.6/8.11.6) id g28NfrI03496; Fri, 8 Mar 2002 17:41:53 -0600 (CST) (envelope-from hawkeyd) Date: Fri, 8 Mar 2002 17:41:53 -0600 (CST) Message-Id: <200203082341.g28NfrI03496@sheol.localdomain> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: hawkeyd@visi.com Organization: if (!FIFO) if (!LIFO) break; References: In-Reply-To: From: hawkeyd@visi.com (D J Hawkey Jr) Subject: Re: Where are the TCP patches for 4.4? X-Original-Newsgroups: sol.lists.freebsd.hackers To: julian@elischer.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article , julian@elischer.org writes: > > I remember someone saying that they were going to make a repository > for patches for releases. > > In particular I[m looking at teh TCP patches that fixed the slow transfers > in some situations. Thes changes were put in before 4.5 > so I want to find them to upgrade some production 4.4 machines. > > I have the diffs for 4.4p9 but they seem to be only security fixes. You might be thinking of the thread I started, and the subsequent web page I put up? http://www.visi.com/~hawkeyd/freebsd-backports.html Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 15:47:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 34D9037B404 for ; Fri, 8 Mar 2002 15:47:51 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g28NlnNH079592; Fri, 8 Mar 2002 18:47:49 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 8 Mar 2002 18:47:48 -0500 To: Julian Elischer From: Garance A Drosihn Subject: Re: Where are the TCP patches for 4.4? Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:48 PM -0800 3/8/02, Julian Elischer wrote: >On Fri, 8 Mar 2002, Kenneth Culver wrote: > > > If you want, I can make you some patches, I think I still > > remember when they went in... however I can't do any more > > than that... > >I'm sure I can get them, >I'm just trying to find who it was that said they were >compiling a set of "good patches for 4.4" The only memory this triggers for me is: http://www.visi.com/~hawkeyd/freebsd-backports.html Is that what you're thinking 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 Fri Mar 8 15:58:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by hub.freebsd.org (Postfix) with ESMTP id 4BEE637B416 for ; Fri, 8 Mar 2002 15:58:16 -0800 (PST) Received: from fwd08.sul.t-online.de by mailout08.sul.t-online.com with smtp id 16jTQX-0004fa-07; Sat, 09 Mar 2002 00:05:29 +0100 Received: from pc5.abc (520067998749-0001@[217.233.117.73]) by fmrl08.sul.t-online.com with esmtp id 16jTQX-07dWDYC; Sat, 9 Mar 2002 00:05:29 +0100 Received: (from nicolas@localhost) by pc5.abc (8.11.6/8.11.6) id g28N5R908568 for freebsd-hackers@freebsd.org; Sat, 9 Mar 2002 00:05:27 +0100 (CET) (envelope-from list@rachinsky.de) Date: Sat, 9 Mar 2002 00:05:27 +0100 From: Nicolas Rachinsky To: freebsd-hackers@freebsd.org Subject: bug in libutil or ppp? Message-ID: <20020308230527.GA5533@pc5.abc> 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.27i X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: C11ABC0E X-PGP-Fingerprint: 19DB 8392 8FE0 814A 7362 EEBD A53B 526A C11A BC0E X-PGP-Key: http://www.rachinsky.de/nicolas/nicolas_rachinsky.asc X-Sender: 520067998749-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hallo, I think there is an bug either in libutil's login function or in ppp. If you login via a port not in /etc/ttys (for example, i4brbch0) with ppp and utmp is enabled (the default) then ppp calls login() from libutil, login writes an entry to wtmp but not to utmp, because i4brbch0 is not in /etc/ttys and so ttyslot fails. On logout ppp checks tries to logout via libutil's logout function wich fails because there is no utmp entry, because of that ppp does not log the end of the session to wtmp. I think either should ppp write always the "logout entry" to wtmp, or login should write either both to utmp and wtmp or to none of them. Which would be the correct behaviour? Or is the present behaviour correct, and it is the users fault to use a line not mentioned in /etc/ttys? thanks Nicolas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 17:20:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 87BF537B419 for ; Fri, 8 Mar 2002 17:20:24 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020309012024.LYKD1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Sat, 9 Mar 2002 01:20:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA51173; Fri, 8 Mar 2002 17:15:21 -0800 (PST) Date: Fri, 8 Mar 2002 17:15:20 -0800 (PST) From: Julian Elischer To: Garance A Drosihn Cc: hackers@FreeBSD.ORG Subject: Re: Where are the TCP patches for 4.4? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG yes, thanks.. he recognised it too :-) On Fri, 8 Mar 2002, Garance A Drosihn wrote: > http://www.visi.com/~hawkeyd/freebsd-backports.html > > Is that what you're thinking 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 Fri Mar 8 17:20:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 7AC5B37B41C for ; Fri, 8 Mar 2002 17:20:35 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020309012034.LYNB1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Sat, 9 Mar 2002 01:20:34 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA51161; Fri, 8 Mar 2002 17:13:17 -0800 (PST) Date: Fri, 8 Mar 2002 17:13:16 -0800 (PST) From: Julian Elischer To: D J Hawkey Jr Cc: freebsd-hackers@freebsd.org Subject: Re: Where are the TCP patches for 4.4? In-Reply-To: <200203082341.g28NfrI03496@sheol.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG YES! Thanks.... On Fri, 8 Mar 2002, D J Hawkey Jr wrote: > In article , > julian@elischer.org writes: > > > > I remember someone saying that they were going to make a repository > > for patches for releases. > > > > In particular I[m looking at teh TCP patches that fixed the slow transfers > > in some situations. Thes changes were put in before 4.5 > > so I want to find them to upgrade some production 4.4 machines. > > > > I have the diffs for 4.4p9 but they seem to be only security fixes. > > You might be thinking of the thread I started, and the subsequent > web page I put up? > > http://www.visi.com/~hawkeyd/freebsd-backports.html > > Dave > > -- > > Windows: "Where do you want to go today?" > Linux: "Where do you want to go tomorrow?" > FreeBSD: "Are you guys coming, or what?" > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Mar 8 20: 1:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 9186F37B404 for ; Fri, 8 Mar 2002 20:01:02 -0800 (PST) Received: from localhost (root@localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.2/8.12.2) with ESMTP id g2940iZR052185; Sat, 9 Mar 2002 14:30:48 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Where are the TCP patches for 4.4? From: "Daniel O'Connor" To: Julian Elischer Cc: hackers@FreeBSD.ORG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 09 Mar 2002 15:30:22 +1130 Message-Id: <1015646431.68150.4.camel@chowder.dons.net.au> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 2002-03-09 at 09:29, Julian Elischer wrote: > In particular I[m looking at teh TCP patches that fixed the slow transfers > in some situations. Thes changes were put in before 4.5 > so I want to find them to upgrade some production 4.4 machines. That particular patch is available at.. http://apollo.backplane.com/FreeBSD.old/ It applies with to easily fixable rejects (well, I assume my changes work, but I haven't properly tested yet :) --- 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 Mar 8 20: 2:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 3566837B404 for ; Fri, 8 Mar 2002 20:02:24 -0800 (PST) Received: from localhost (root@localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.2/8.12.2) with ESMTP id g2942HZR052210; Sat, 9 Mar 2002 14:32:20 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Remote GDB in -stable.. From: "Daniel O'Connor" To: Willem van Engen Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20020308105632.7fbfa098.wvengen@stack.nl> References: <20020308105632.7fbfa098.wvengen@stack.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 09 Mar 2002 15:31:55 +1130 Message-Id: <1015646519.68150.6.camel@chowder.dons.net.au> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 2002-03-08 at 21:26, Willem van Engen wrote: > > Anyone have any handy tips? > Did you read the developers' handbook, chapter 16? > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x5013.html Yeah I read that. I can't get an annotates back trace though :( ie I want gdb to show me line numbers of function calls and the like.. I have a debugging kernel and all of the source, but it doesn't seem to work :( --- 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 Mar 8 20:49:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 1B6C637B404 for ; Fri, 8 Mar 2002 20:49:19 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id A6C6E3E2F; Sat, 9 Mar 2002 04:49:14 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id A577F3C12E; Sat, 9 Mar 2002 04:49:14 +0000 (UTC) To: hackers@freebsd.org Cc: Jordan DeLong Subject: Re: bin/34744: Add -a (same as -PpR) flag to cp(1) In-Reply-To: <200202090347.g193lXd55117@cs6668125-184.austin.rr.com>; from fracture@allusion.net on "Fri, 8 Feb 2002 21:47:33 -0600 (CST)" Date: Sat, 09 Mar 2002 04:49:09 +0000 From: Dima Dorfman Message-Id: <20020309044914.A6C6E3E2F@bazooka.trit.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jordan DeLong wrote: > > >Number: 34744 > >Category: bin > >Synopsis: Add -a (same as -PpR) flag to cp(1) > >Description: > some other cp(1) implementations (such as GNU cp) provide a -a > flag, which just means -PpR. somewhat useful. Does anybody on -hackers object to this change? I find myself using `cp -RPp` frequently and would welcome this shortcut. If nobody objects, I'll clean up the patch (minor style and mdoc nits) before committing. Thanks. > >Fix: > > diff -ruN cp.dist/cp.1 cp/cp.1 > --- cp.dist/cp.1 Thu Aug 16 05:01:03 2001 > +++ cp/cp.1 Fri Feb 8 21:44:40 2002 > @@ -77,6 +77,13 @@ > .Pp > The following options are available: > .Bl -tag -width flag > +.It Fl a > +Same as specifying the > +.Fl R > +.Fl P > +and > +.Fl p > +flags. > .It Fl H > If the > .Fl R > @@ -226,7 +233,9 @@ > .Pp > The > .Fl v > -option is non-standard and its use in scripts is not recommended. > +and > +.Fl a > +options are non-standard and use in scripts is not recommended. > .Sh SEE ALSO > .Xr mv 1 , > .Xr rcp 1 , > diff -ruN cp.dist/cp.c cp/cp.c > --- cp.dist/cp.c Wed Jan 30 09:15:46 2002 > +++ cp/cp.c Fri Feb 8 21:43:28 2002 > @@ -102,7 +102,7 @@ > char *target; > > Hflag = Lflag = Pflag = 0; > - while ((ch = getopt(argc, argv, "HLPRfiprv")) != -1) > + while ((ch = getopt(argc, argv, "aHLPRfiprv")) != -1) > switch (ch) { > case 'H': > Hflag = 1; > @@ -112,6 +112,10 @@ > Lflag = 1; > Hflag = Pflag = 0; > break; > + case 'a': > + Rflag = 1; > + pflag = 1; > + /* FALLTHROUGH */ > case 'P': > Pflag = 1; > Hflag = Lflag = 0; > diff -ruN cp.dist/utils.c cp/utils.c > --- cp.dist/utils.c Wed Jan 30 09:15:46 2002 > +++ cp/utils.c Fri Feb 8 21:39:05 2002 > @@ -312,7 +312,7 @@ > { > > (void)fprintf(stderr, "%s\n%s\n", > -"usage: cp [-R [-H | -L | -P]] [-f | -i] [-pv] src target", > -" cp [-R [-H | -L | -P]] [-f | -i] [-pv] src1 ... srcN directory"); > +"usage: cp [-R [-H | -L | -P]] [-f | -i] [-apv] src target", > +" cp [-R [-H | -L | -P]] [-f | -i] [-apv] src1 ... srcN directory"); > exit(EX_USAGE); > } > > > >Release-Note: > >Audit-Trail: > >Unformatted: > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-bugs" 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 Mar 9 2: 3:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 5629537B41C for ; Sat, 9 Mar 2002 02:03:50 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g29A3dP65408; Sat, 9 Mar 2002 02:03:39 -0800 (PST) (envelope-from obrien) Date: Sat, 9 Mar 2002 01:59:35 -0800 From: "David O'Brien" To: Dima Dorfman Cc: hackers@freebsd.org, Jordan DeLong Subject: Re: bin/34744: Add -a (same as -PpR) flag to cp(1) Message-ID: <20020309015935.A65349@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200202090347.g193lXd55117@cs6668125-184.austin.rr.com> <20020309044914.A6C6E3E2F@bazooka.trit.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020309044914.A6C6E3E2F@bazooka.trit.org>; from dima@trit.org on Sat, Mar 09, 2002 at 04:49:09AM +0000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Mar 09, 2002 at 04:49:09AM +0000, Dima Dorfman wrote: > Jordan DeLong wrote: > > > > >Number: 34744 > > >Category: bin > > >Synopsis: Add -a (same as -PpR) flag to cp(1) > > >Description: > > some other cp(1) implementations (such as GNU cp) provide a -a > > flag, which just means -PpR. somewhat useful. > > Does anybody on -hackers object to this change? I find myself using > `cp -RPp` frequently and would welcome this shortcut. If nobody I just see no need in this shortcut. When I added -v (yes, not POSUCKS), there was no other way to get that functionality. Here someone is just too lazy to type on extra keystroke (-P is the default). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 9 5:46:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from atlantis.homeip.net (a30032.upc-a.chello.nl [62.163.30.32]) by hub.freebsd.org (Postfix) with SMTP id 57F9637B400 for ; Sat, 9 Mar 2002 05:46:39 -0800 (PST) Received: (qmail 1587 invoked from network); 9 Mar 2002 13:46:37 -0000 Received: from jeremy.ourhome.nl (192.168.1.4) by atlantis.ourhome.nl with SMTP; 9 Mar 2002 13:46:37 -0000 Date: Sat, 9 Mar 2002 14:46:37 +0100 From: Willem van Engen To: "Daniel O'Connor" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Remote GDB in -stable.. Message-Id: <20020309144637.028f317e.wvengen@stack.nl> In-Reply-To: <1015646519.68150.6.camel@chowder.dons.net.au> References: <20020308105632.7fbfa098.wvengen@stack.nl> <1015646519.68150.6.camel@chowder.dons.net.au> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 09 Mar 2002 15:31:55 +1130 "Daniel O'Connor" wrote: > On Fri, 2002-03-08 at 21:26, Willem van Engen wrote: > > > Anyone have any handy tips? > > Did you read the developers' handbook, chapter 16? > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x5013.html > > Yeah I read that. > I can't get an annotates back trace though :( > ie I want gdb to show me line numbers of function calls and the like.. So what exactly doesn't work and what does? Are the kernel's symbols loaded (try 'list printf' e.g. before 'target'-ing)? If it fails, make sure you load the kernel with symbols included, not the stripped one. If you used 'makeoptions DEBUG=foo' in the kernel config, you need to load kernel.debug (from /sys/compile/MYKERNEL) into gdb, instead of kernel. - Willem To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 9 11:50:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from priv-edtnes16-hme0.telusplanet.net (defout.telus.net [199.185.220.240]) by hub.freebsd.org (Postfix) with ESMTP id 106EB37B405 for ; Sat, 9 Mar 2002 11:50:39 -0800 (PST) Received: from pfak ([216.232.34.44]) by priv-edtnes16-hme0.telusplanet.net (InterMail vM.5.01.04.02 201-253-122-122-102-20011128) with SMTP id <20020309195038.QDZD5907.priv-edtnes16-hme0.telusplanet.net@pfak> for ; Sat, 9 Mar 2002 12:50:38 -0700 Message-ID: <000b01c1c7a3$b5038cf0$6401a8c0@pfak> From: "Peter Kieser" To: Subject: Problems with Network after compile of latest 4.5-STABLE Date: Sat, 9 Mar 2002 11:50:46 -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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hey hackers, As of the SSH bug, I updated the source for my kernel, and recompiled it. I was running 4.5-STABLE, and was just updating to the latest release. After the compile was complete, I rebooted and my network cards stopped working. This has happened on every box that I have attempted to upgrade, When I look on the actual console on the box, it says something about not being able to find lnc0, or de0, etc. Anyone had a similair problem? Thanks alot, --Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 9 12: 1:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from scanner.secnap.net (scanner.secnap.net [216.241.67.74]) by hub.freebsd.org (Postfix) with ESMTP id 76C6937B404 for ; Sat, 9 Mar 2002 12:01:14 -0800 (PST) Received: (from scheidell@localhost) by scanner.secnap.net (8.11.6/8.11.6) id g29K10B45017; Sat, 9 Mar 2002 15:01:00 -0500 (EST) (envelope-from scheidell) Message-Id: <200203092001.g29K10B45017@scanner.secnap.net> Subject: Re: Problems with Network after compile of latest 4.5-STABLE In-Reply-To: <000b01c1c7a3$b5038cf0$6401a8c0@pfak> To: Peter Kieser Date: Sat, 9 Mar 2002 15:01:00 -0500 (EST) Cc: hackers@FreeBSD.ORG From: Michael Scheidell X-Loop: scheidell@secnap.net X-Mailer: ELM [version 2.4ME+ PL92 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Hey hackers, > > As of the SSH bug, I updated the source for my kernel, and recompiled it. I > was running 4.5-STABLE, and was just updating to the latest release. After > the compile was complete, I rebooted and my network cards stopped working. > This has happened on every box that I have attempted to upgrade, When I look > on the actual console on the box, it says something about not being able to > find lnc0, or de0, etc. Anyone had a similair problem? > you compare generic kernels? didn't 4.5 requir emii bus or something > Thanks alot, > > --Peter > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Michael Scheidell SECNAP Network Security, LLC (561) 368-9561 scheidell@secnap.net http://www.secnap.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 9 12: 1:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2DF3437B427 for ; Sat, 9 Mar 2002 12:01:36 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g29K1Yp25353; Sat, 9 Mar 2002 12:01:34 -0800 (PST) (envelope-from rizzo) Date: Sat, 9 Mar 2002 12:01:34 -0800 From: Luigi Rizzo To: Peter Kieser Cc: hackers@FreeBSD.ORG Subject: Re: Problems with Network after compile of latest 4.5-STABLE Message-ID: <20020309120134.A24526@iguana.icir.org> References: <000b01c1c7a3$b5038cf0$6401a8c0@pfak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000b01c1c7a3$b5038cf0$6401a8c0@pfak> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Mar 09, 2002 at 11:50:46AM -0800, Peter Kieser wrote: > Hey hackers, > > As of the SSH bug, I updated the source for my kernel, and recompiled it. I > was running 4.5-STABLE, and was just updating to the latest release. After > the compile was complete, I rebooted and my network cards stopped working. > This has happened on every box that I have attempted to upgrade, When I look > on the actual console on the box, it says something about not being able to > find lnc0, or de0, etc. Anyone had a similair problem? those who have cannot tell anymore :) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 9 12: 3:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from priv-edtnes11-hme0.telusplanet.net (fepout3.telus.net [199.185.220.238]) by hub.freebsd.org (Postfix) with ESMTP id 1CE2F37B417 for ; Sat, 9 Mar 2002 12:03:52 -0800 (PST) Received: from pfak ([216.232.34.44]) by priv-edtnes11-hme0.telusplanet.net (InterMail vM.5.01.04.01 201-253-122-122-101-20011014) with SMTP id <20020309200351.MXNA16061.priv-edtnes11-hme0.telusplanet.net@pfak>; Sat, 9 Mar 2002 13:03:51 -0700 Message-ID: <002c01c1c7a5$8dc31c30$6401a8c0@pfak> From: "Peter Kieser" To: "Michael Scheidell" Cc: References: <200203092001.g29K10B45017@scanner.secnap.net> Subject: Re: Problems with Network after compile of latest 4.5-STABLE Date: Sat, 9 Mar 2002 12:04:00 -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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I installed the machines all with 4.5-RELEASE, then did 4.5-STABLE, and the generic kernel config, which worked with my network cards. Then I upgraded a few days later to the latest source tree to recompile, recompiled; and it stopped work. --Peter ----- Original Message ----- From: "Michael Scheidell" To: "Peter Kieser" Cc: Sent: Saturday, March 09, 2002 12:01 PM Subject: Re: Problems with Network after compile of latest 4.5-STABLE > > Hey hackers, > > > > As of the SSH bug, I updated the source for my kernel, and recompiled it. I > > was running 4.5-STABLE, and was just updating to the latest release. After > > the compile was complete, I rebooted and my network cards stopped working. > > This has happened on every box that I have attempted to upgrade, When I look > > on the actual console on the box, it says something about not being able to > > find lnc0, or de0, etc. Anyone had a similair problem? > > > you compare generic kernels? didn't 4.5 requir emii bus or something > > Thanks alot, > > > > --Peter > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > Michael Scheidell > SECNAP Network Security, LLC > (561) 368-9561 scheidell@secnap.net > http://www.secnap.net/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 9 13: 4:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d28.as21.nwbl0.wi.voyager.net [169.207.138.156]) by hub.freebsd.org (Postfix) with ESMTP id 4B80D37B419 for ; Sat, 9 Mar 2002 13:04:39 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g29F99jJ001090; Sat, 9 Mar 2002 15:09:09 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g29F96n4001087; Sat, 9 Mar 2002 15:09:08 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Sat, 9 Mar 2002 15:09:05 +0000 (GMT) From: Mike Silbersack To: Peter Kieser Cc: hackers@freebsd.org Subject: Re: Problems with Network after compile of latest 4.5-STABLE In-Reply-To: <000b01c1c7a3$b5038cf0$6401a8c0@pfak> Message-ID: <20020309150750.N380-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 9 Mar 2002, Peter Kieser wrote: > Hey hackers, > > As of the SSH bug, I updated the source for my kernel, and recompiled it. I > was running 4.5-STABLE, and was just updating to the latest release. After > the compile was complete, I rebooted and my network cards stopped working. > This has happened on every box that I have attempted to upgrade, When I look > on the actual console on the box, it says something about not being able to > find lnc0, or de0, etc. Anyone had a similair problem? > > Thanks alot, > > --Peter I just cvsup'd a -stable box, and the resulting kernel appears to be working just fine. What server did you cvsup from, and have you tried cvsupping again? It's possible that you updated between two parts of a patch being applied. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 9 15:31:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from nas.dgap.mipt.ru (nas.dgap.mipt.ru [194.85.81.203]) by hub.freebsd.org (Postfix) with ESMTP id 122A537B416; Sat, 9 Mar 2002 15:30:53 -0800 (PST) Received: from localhost (andrew@localhost) by nas.dgap.mipt.ru (8.11.6/8.11.6) with ESMTP id g29NUn813282; Sun, 10 Mar 2002 02:30:50 +0300 (MSK) (envelope-from andr@dgap.mipt.ru) X-Authentication-Warning: nas.dgap.mipt.ru: andrew owned process doing -bs Date: Sun, 10 Mar 2002 02:30:49 +0300 (MSK) From: "Andrew L. Neporada" To: freebsd-bugs@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: [PATCH] exit status of mtree(1) Message-ID: <20020310015221.J11778-200000@nas.dgap.mipt.ru> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-793760758-1015716649=:11778" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-793760758-1015716649=:11778 Content-Type: TEXT/PLAIN; charset=US-ASCII According to man page, mtree should exit with a status of 0 on success (directory matches spec.), 1 if any error occurred and 2 in the case of directory with spec. mismatch. But our mtree(1) is badly broken here (see f.e. bin/28424). Attached patch solves (I hope) this problem. This patch also introduces slightly enhanced exit status reporting: 0 - directory matches spec, success 1 - "hard error" -- spec/dir not found, wrong options, etc. 2 - directory/spec mismatch that was fixed successfully 3 - unfixed directory/spec mismatch Please comment/review. Andrew. --0-793760758-1015716649=:11778 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mtree.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20020310023049.P11778@nas.dgap.mipt.ru> Content-Description: mtree.diff Content-Disposition: attachment; filename="mtree.diff" SW5kZXg6IGNvbXBhcmUuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNT IGZpbGU6IC9ob21lL25jdnMvc3JjL3Vzci5zYmluL210cmVlL2NvbXBhcmUu Yyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjANCmRpZmYgLXUgLXIxLjIw IGNvbXBhcmUuYw0KLS0tIGNvbXBhcmUuYwk2IE9jdCAyMDAwIDEyOjQ4OjU1 IC0wMDAwCTEuMjANCisrKyBjb21wYXJlLmMJNyBNYXIgMjAwMiAyMjo1Njoy NSAtMDAwMA0KQEAgLTYyLDYgKzYyLDcgQEANCiANCiBleHRlcm4gaW50IHVm bGFnOw0KIGV4dGVybiBpbnQgbGluZW5vOw0KK2V4dGVybiBpbnQgcnZhbDsN CiANCiBzdGF0aWMgY2hhciAqZnR5cGUgX19QKCh1X2ludCkpOw0KIA0KQEAg LTExNSw2ICsxMTYsNyBAQA0KIHR5cGVlcnI6CQlMQUJFTDsNCiAJCQkodm9p ZClwcmludGYoIlx0dHlwZSBleHBlY3RlZCAlcyBmb3VuZCAlc1xuIiwNCiAJ CQkgICAgZnR5cGUocy0+dHlwZSksIGlub3R5cGUocC0+ZnRzX3N0YXRwLT5z dF9tb2RlKSk7DQorCQkJRkFJTEVEOw0KIAkJCXJldHVybiAobGFiZWwpOw0K IAkJfQ0KIAkJYnJlYWs7DQpAQCAtMTI0LDExICsxMjYsMTMgQEANCiAJCUxB QkVMOw0KIAkJKHZvaWQpcHJpbnRmKCIlc3VzZXIgZXhwZWN0ZWQgJWx1IGZv dW5kICVsdSIsDQogCQkgICAgdGFiLCAodV9sb25nKXMtPnN0X3VpZCwgKHVf bG9uZylwLT5mdHNfc3RhdHAtPnN0X3VpZCk7DQorCQlGSVhFRDsNCiAJCWlm ICh1ZmxhZykNCi0JCQlpZiAoY2hvd24ocC0+ZnRzX2FjY3BhdGgsIHMtPnN0 X3VpZCwgLTEpKQ0KKwkJCWlmIChjaG93bihwLT5mdHNfYWNjcGF0aCwgcy0+ c3RfdWlkLCAtMSkpIHsNCiAJCQkJKHZvaWQpcHJpbnRmKCIgbm90IG1vZGlm aWVkOiAlc1xuIiwNCiAJCQkJICAgIHN0cmVycm9yKGVycm5vKSk7DQotCQkJ ZWxzZQ0KKwkJCQlGQUlMRUQ7DQorCQkJfSBlbHNlDQogCQkJCSh2b2lkKXBy aW50ZigiIG1vZGlmaWVkXG4iKTsNCiAJCWVsc2UNCiAJCQkodm9pZClwcmlu dGYoIlxuIik7DQpAQCAtMTM4LDExICsxNDIsMTMgQEANCiAJCUxBQkVMOw0K IAkJKHZvaWQpcHJpbnRmKCIlc2dpZCBleHBlY3RlZCAlbHUgZm91bmQgJWx1 IiwNCiAJCSAgICB0YWIsICh1X2xvbmcpcy0+c3RfZ2lkLCAodV9sb25nKXAt PmZ0c19zdGF0cC0+c3RfZ2lkKTsNCisJCUZJWEVEOw0KIAkJaWYgKHVmbGFn KQ0KLQkJCWlmIChjaG93bihwLT5mdHNfYWNjcGF0aCwgLTEsIHMtPnN0X2dp ZCkpDQorCQkJaWYgKGNob3duKHAtPmZ0c19hY2NwYXRoLCAtMSwgcy0+c3Rf Z2lkKSkgew0KIAkJCQkodm9pZClwcmludGYoIiBub3QgbW9kaWZpZWQ6ICVz XG4iLA0KIAkJCQkgICAgc3RyZXJyb3IoZXJybm8pKTsNCi0JCQllbHNlDQor CQkJCUZBSUxFRDsNCisJCQl9IGVsc2UNCiAJCQkJKHZvaWQpcHJpbnRmKCIg bW9kaWZpZWRcbiIpOw0KIAkJZWxzZQ0KIAkJCSh2b2lkKXByaW50ZigiXG4i KTsNCkBAIC0xNTQsMTEgKzE2MCwxMyBAQA0KIAkJTEFCRUw7DQogCQkodm9p ZClwcmludGYoIiVzcGVybWlzc2lvbnMgZXhwZWN0ZWQgJSNvIGZvdW5kICUj byIsDQogCQkgICAgdGFiLCBzLT5zdF9tb2RlLCBwLT5mdHNfc3RhdHAtPnN0 X21vZGUgJiBNQklUUyk7DQorCQlGSVhFRDsNCiAJCWlmICh1ZmxhZykNCi0J CQlpZiAoY2htb2QocC0+ZnRzX2FjY3BhdGgsIHMtPnN0X21vZGUpKQ0KKwkJ CWlmIChjaG1vZChwLT5mdHNfYWNjcGF0aCwgcy0+c3RfbW9kZSkpIHsNCiAJ CQkJKHZvaWQpcHJpbnRmKCIgbm90IG1vZGlmaWVkOiAlc1xuIiwNCiAJCQkJ ICAgIHN0cmVycm9yKGVycm5vKSk7DQotCQkJZWxzZQ0KKwkJCQlGQUlMRUQ7 DQorCQkJfSBlbHNlDQogCQkJCSh2b2lkKXByaW50ZigiIG1vZGlmaWVkXG4i KTsNCiAJCWVsc2UNCiAJCQkodm9pZClwcmludGYoIlxuIik7DQpAQCAtMTY5 LDYgKzE3Nyw3IEBADQogCQlMQUJFTDsNCiAJCSh2b2lkKXByaW50ZigiJXNs aW5rX2NvdW50IGV4cGVjdGVkICV1IGZvdW5kICV1XG4iLA0KIAkJICAgIHRh Yiwgcy0+c3RfbmxpbmssIHAtPmZ0c19zdGF0cC0+c3RfbmxpbmspOw0KKwkJ RkFJTEVEOw0KIAkJdGFiID0gIlx0IjsNCiAJfQ0KIAlpZiAocy0+ZmxhZ3Mg JiBGX1NJWkUgJiYgcy0+c3Rfc2l6ZSAhPSBwLT5mdHNfc3RhdHAtPnN0X3Np emUgJiYNCkBAIC0xNzYsNiArMTg1LDcgQEANCiAJCUxBQkVMOw0KIAkJKHZv aWQpcHJpbnRmKCIlc3NpemUgZXhwZWN0ZWQgJXFkIGZvdW5kICVxZFxuIiwN CiAJCSAgICB0YWIsIHMtPnN0X3NpemUsIHAtPmZ0c19zdGF0cC0+c3Rfc2l6 ZSk7DQorCQlGQUlMRUQ7DQogCQl0YWIgPSAiXHQiOw0KIAl9DQogCS8qDQpA QCAtMTkwLDYgKzIwMCw3IEBADQogCQkgICAgdGFiLCBjdGltZSgmcy0+c3Rf bXRpbWVzcGVjLnR2X3NlYykpOw0KIAkJKHZvaWQpcHJpbnRmKCJmb3VuZCAl LjI0c1xuIiwNCiAJCSAgICBjdGltZSgmcC0+ZnRzX3N0YXRwLT5zdF9tdGlt ZXNwZWMudHZfc2VjKSk7DQorCQlGQUlMRUQ7DQogCQl0YWIgPSAiXHQiOw0K IAl9DQogCWlmIChzLT5mbGFncyAmIEZfQ0tTVU0pIHsNCkBAIC0xOTcsMTIg KzIwOCwxNCBAQA0KIAkJCUxBQkVMOw0KIAkJCSh2b2lkKXByaW50ZigiJXNj a3N1bTogJXM6ICVzXG4iLA0KIAkJCSAgICB0YWIsIHAtPmZ0c19hY2NwYXRo LCBzdHJlcnJvcihlcnJubykpOw0KKwkJCUZBSUxFRDsNCiAJCQl0YWIgPSAi XHQiOw0KIAkJfSBlbHNlIGlmIChjcmMoZmQsICZ2YWwsICZsZW4pKSB7DQog CQkJKHZvaWQpY2xvc2UoZmQpOw0KIAkJCUxBQkVMOw0KIAkJCSh2b2lkKXBy aW50ZigiJXNja3N1bTogJXM6ICVzXG4iLA0KIAkJCSAgICB0YWIsIHAtPmZ0 c19hY2NwYXRoLCBzdHJlcnJvcihlcnJubykpOw0KKwkJCUZBSUxFRDsNCiAJ CQl0YWIgPSAiXHQiOw0KIAkJfSBlbHNlIHsNCiAJCQkodm9pZCljbG9zZShm ZCk7DQpAQCAtMjEwLDYgKzIyMyw3IEBADQogCQkJCUxBQkVMOw0KIAkJCQko dm9pZClwcmludGYoIiVzY2tzdW0gZXhwZWN0ZWQgJWx1IGZvdW5kICVsdVxu IiwNCiAJCQkJICAgIHRhYiwgcy0+Y2tzdW0sIHZhbCk7DQorCQkJCUZBSUxF RDsNCiAJCQl9DQogCQkJdGFiID0gIlx0IjsNCiAJCX0NCkBAIC0yMjksMTIg KzI0MywxNCBAQA0KIAkJZmZsYWdzID0gZmxhZ3NfdG9fc3RyaW5nKHAtPmZ0 c19zdGF0cC0+c3RfZmxhZ3MpOw0KIAkJKHZvaWQpcHJpbnRmKCIgZm91bmQg XCIlc1wiIiwgZmZsYWdzKTsNCiAJCWZyZWUoZmZsYWdzKTsNCisJCUZJWEVE Ow0KIA0KIAkJaWYgKHVmbGFnKQ0KLQkJCWlmIChjaGZsYWdzKHAtPmZ0c19h Y2NwYXRoLCBzLT5zdF9mbGFncykpDQorCQkJaWYgKGNoZmxhZ3MocC0+ZnRz X2FjY3BhdGgsIHMtPnN0X2ZsYWdzKSkgew0KIAkJCQkodm9pZClwcmludGYo IiBub3QgbW9kaWZpZWQ6ICVzXG4iLA0KIAkJCQkgICAgc3RyZXJyb3IoZXJy bm8pKTsNCi0JCQllbHNlDQorCQkJCUZBSUxFRDsNCisJCQl9IGVsc2UNCiAJ CQkJKHZvaWQpcHJpbnRmKCIgbW9kaWZpZWRcbiIpOw0KIAkJZWxzZQ0KIAkJ CSh2b2lkKXByaW50ZigiXG4iKTsNCkBAIC0yNDksMTEgKzI2NSwxMyBAQA0K IAkJCUxBQkVMOw0KIAkJCXByaW50ZigiJXNNRDU6ICVzOiAlc1xuIiwgdGFi LCBwLT5mdHNfYWNjcGF0aCwNCiAJCQkgICAgICAgc3RyZXJyb3IoZXJybm8p KTsNCisJCQlGQUlMRUQ7DQogCQkJdGFiID0gIlx0IjsNCiAJCX0gZWxzZSBp ZiAoc3RyY21wKG5ld19kaWdlc3QsIHMtPm1kNWRpZ2VzdCkpIHsNCiAJCQlM QUJFTDsNCiAJCQlwcmludGYoIiVzTUQ1IGV4cGVjdGVkICVzIGZvdW5kICVz XG4iLCB0YWIsIHMtPm1kNWRpZ2VzdCwNCiAJCQkgICAgICAgbmV3X2RpZ2Vz dCk7DQorCQkJRkFJTEVEOw0KIAkJCXRhYiA9ICJcdCI7DQogCQl9DQogCX0N CkBAIC0yNjcsMTEgKzI4NSwxMyBAQA0KIAkJCUxBQkVMOw0KIAkJCXByaW50 ZigiJXNTSEEtMTogJXM6ICVzXG4iLCB0YWIsIHAtPmZ0c19hY2NwYXRoLA0K IAkJCSAgICAgICBzdHJlcnJvcihlcnJubykpOw0KKwkJCUZBSUxFRDsNCiAJ CQl0YWIgPSAiXHQiOw0KIAkJfSBlbHNlIGlmIChzdHJjbXAobmV3X2RpZ2Vz dCwgcy0+c2hhMWRpZ2VzdCkpIHsNCiAJCQlMQUJFTDsNCiAJCQlwcmludGYo IiVzU0hBLTEgZXhwZWN0ZWQgJXMgZm91bmQgJXNcbiIsIA0KIAkJCSAgICAg ICB0YWIsIHMtPnNoYTFkaWdlc3QsIG5ld19kaWdlc3QpOw0KKwkJCUZBSUxF RDsNCiAJCQl0YWIgPSAiXHQiOw0KIAkJfQ0KIAl9DQpAQCAtMjg1LDExICsz MDUsMTMgQEANCiAJCQlMQUJFTDsNCiAJCQlwcmludGYoIiVzUklQRU1EMTYw OiAlczogJXNcbiIsIHRhYiwNCiAJCQkgICAgICAgcC0+ZnRzX2FjY3BhdGgs IHN0cmVycm9yKGVycm5vKSk7DQorCQkJRkFJTEVEOw0KIAkJCXRhYiA9ICJc dCI7DQogCQl9IGVsc2UgaWYgKHN0cmNtcChuZXdfZGlnZXN0LCBzLT5ybWQx NjBkaWdlc3QpKSB7DQogCQkJTEFCRUw7DQogCQkJcHJpbnRmKCIlc1JJUEVN RDE2MCBleHBlY3RlZCAlcyBmb3VuZCAlc1xuIiwNCiAJCQkgICAgICAgdGFi LCBzLT5ybWQxNjBkaWdlc3QsIG5ld19kaWdlc3QpOw0KKwkJCUZBSUxFRDsN CiAJCQl0YWIgPSAiXHQiOw0KIAkJfQ0KIAl9DQpAQCAtMzAwLDYgKzMyMiw3 IEBADQogCQlMQUJFTDsNCiAJCSh2b2lkKXByaW50ZigiJXNsaW5rX3JlZiBl eHBlY3RlZCAlcyBmb3VuZCAlc1xuIiwNCiAJCSAgICAgIHRhYiwgY3AsIHMt PnNsaW5rKTsNCisJCUZBSUxFRDsNCiAJfQ0KIAlyZXR1cm4gKGxhYmVsKTsN CiB9DQpJbmRleDogZXh0ZXJuLmgNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy91c3Iuc2Jpbi9tdHJlZS9leHRl cm4uaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNQ0KZGlmZiAtdSAtcjEu NSBleHRlcm4uaA0KLS0tIGV4dGVybi5oCTE3IEp1biAyMDAwIDE0OjE5OjMz IC0wMDAwCTEuNQ0KKysrIGV4dGVybi5oCTcgTWFyIDIwMDIgMjI6NTY6MjUg LTAwMDANCkBAIC00Myw3ICs0Myw3IEBADQogdV9pbnQJIHBhcnNla2V5IF9f UCgoY2hhciAqLCBpbnQgKikpOw0KIGNoYXIJKnJsaW5rIF9fUCgoY2hhciAq KSk7DQogTk9ERQkqc3BlYyBfX1AoKHZvaWQpKTsNCi1pbnQJIHZlcmlmeSBf X1AoKHZvaWQpKTsNCit2b2lkCSB2ZXJpZnkgX19QKCh2b2lkKSk7DQogDQog aW50CSBjaGVja19leGNsdWRlcyBfX1AoKGNvbnN0IGNoYXIgKiwgY29uc3Qg Y2hhciAqKSk7DQogdm9pZAkgaW5pdF9leGNsdWRlcyBfX1AoKHZvaWQpKTsN CkluZGV4OiBtdHJlZS5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvdXNyLnNiaW4vbXRyZWUvbXRyZWUuYyx2 DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTgNCmRpZmYgLXUgLXIxLjE4IG10 cmVlLmMNCi0tLSBtdHJlZS5jCTI1IFNlcCAyMDAwIDE2OjI0OjIyIC0wMDAw CTEuMTgNCisrKyBtdHJlZS5jCTkgTWFyIDIwMDIgMjE6MDY6NDcgLTAwMDAN CkBAIC01OSw2ICs1OSw3IEBADQogDQogaW50IGZ0c29wdGlvbnMgPSBGVFNf UEhZU0lDQUw7DQogaW50IGNmbGFnLCBkZmxhZywgZWZsYWcsIGlmbGFnLCBu ZmxhZywgcWZsYWcsIHJmbGFnLCBzZmxhZywgdWZsYWcsIFVmbGFnOw0KK2lu dCBydmFsOw0KIHVfaW50IGtleXM7DQogY2hhciBmdWxscGF0aFtNQVhQQVRI TEVOXTsNCiANCkBAIC03MSw3ICs3Miw2IEBADQogew0KIAlpbnQgY2g7DQog CWNoYXIgKmRpciwgKnA7DQotCWludCBzdGF0dXM7DQogDQogCWRpciA9IE5V TEw7DQogCWtleXMgPSBLRVlERUZBVUxUOw0KQEAgLTE2NCwxMCArMTY0LDEw IEBADQogCQljd2FsaygpOw0KIAkJZXhpdCgwKTsNCiAJfQ0KLQlzdGF0dXMg PSB2ZXJpZnkoKTsNCi0JaWYgKFVmbGFnICYgKHN0YXR1cyA9PSBNSVNNQVRD SEVYSVQpKQ0KLQkJc3RhdHVzID0gMDsNCi0JZXhpdChzdGF0dXMpOw0KKwl2 ZXJpZnkoKTsNCisJaWYgKFVmbGFnICYgKHJ2YWwgPT0gTUlTTUFUQ0hGSVhF RCkpDQorCQlydmFsID0gMDsNCisJZXhpdChydmFsKTsNCiB9DQogDQogc3Rh dGljIHZvaWQNCkluZGV4OiBtdHJlZS5oDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvdXNyLnNiaW4vbXRyZWUv bXRyZWUuaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNQ0KZGlmZiAtdSAt cjEuNSBtdHJlZS5oDQotLS0gbXRyZWUuaAk5IERlYyAxOTk5IDIwOjM4OjM1 IC0wMDAwCTEuNQ0KKysrIG10cmVlLmgJOSBNYXIgMjAwMiAyMDo0NzowOCAt MDAwMA0KQEAgLTQwLDcgKzQwLDEwIEBADQogI2RlZmluZQlLRVlERUZBVUxU IFwNCiAJKEZfR0lEIHwgRl9NT0RFIHwgRl9OTElOSyB8IEZfU0laRSB8IEZf U0xJTksgfCBGX1RJTUUgfCBGX1VJRCB8IEZfRkxBR1MpDQogDQotI2RlZmlu ZQlNSVNNQVRDSEVYSVQJMg0KKyNkZWZpbmUJTUlTTUFUQ0hGSVhFRAkyDQor I2RlZmluZQlGSVhGQUlMRUQJMw0KKyNkZWZpbmUJRklYRUQJaWYgKHJ2YWwg IT0gRklYRkFJTEVEKSBydmFsID0gTUlTTUFUQ0hGSVhFRDsNCisjZGVmaW5l CUZBSUxFRAlydmFsID0gRklYRkFJTEVEOw0KIA0KIHR5cGVkZWYgc3RydWN0 IF9ub2RlIHsNCiAJc3RydWN0IF9ub2RlCSpwYXJlbnQsICpjaGlsZDsJLyog dXAsIGRvd24gKi8NCkluZGV4OiB2ZXJpZnkuYw0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3Vzci5zYmluL210 cmVlL3ZlcmlmeS5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNQ0KZGlm ZiAtdSAtcjEuMTUgdmVyaWZ5LmMNCi0tLSB2ZXJpZnkuYwkzIE9jdCAyMDAw IDEzOjEzOjQ3IC0wMDAwCTEuMTUNCisrKyB2ZXJpZnkuYwk5IE1hciAyMDAy IDIwOjM5OjQxIC0wMDAwDQpAQCAtNTYsMzEgKzU2LDI5IEBADQogZXh0ZXJu IGludCBkZmxhZywgZWZsYWcsIHFmbGFnLCByZmxhZywgc2ZsYWcsIHVmbGFn Ow0KIGV4dGVybiBjaGFyIGZ1bGxwYXRoW01BWFBBVEhMRU5dOw0KIGV4dGVy biBpbnQgbGluZW5vOw0KK2V4dGVybiBpbnQgcnZhbDsNCiANCiBzdGF0aWMg Tk9ERSAqcm9vdDsNCiBzdGF0aWMgY2hhciBwYXRoW01BWFBBVEhMRU5dOw0K IA0KIHN0YXRpYyB2b2lkCW1pc3MgX19QKChOT0RFICosIGNoYXIgKikpOw0K LXN0YXRpYyBpbnQJdndhbGsgX19QKCh2b2lkKSk7DQorc3RhdGljIHZvaWQJ dndhbGsgX19QKCh2b2lkKSk7DQogDQotaW50DQordm9pZA0KIHZlcmlmeSgp DQogew0KLQlpbnQgcnZhbDsNCi0NCiAJcm9vdCA9IHNwZWMoKTsNCi0JcnZh bCA9IHZ3YWxrKCk7DQorCXZ3YWxrKCk7DQogCW1pc3Mocm9vdCwgcGF0aCk7 DQotCXJldHVybiAocnZhbCk7DQogfQ0KIA0KLXN0YXRpYyBpbnQNCit2b2lk DQogdndhbGsoKQ0KIHsNCiAJcmVnaXN0ZXIgRlRTICp0Ow0KIAlyZWdpc3Rl ciBGVFNFTlQgKnA7DQogCXJlZ2lzdGVyIE5PREUgKmVwLCAqbGV2ZWw7DQot CWludCBzcGVjZGVwdGgsIHJ2YWw7DQorCWludCBzcGVjZGVwdGg7DQogCWNo YXIgKmFyZ3ZbMl07DQogDQogCWFyZ3ZbMF0gPSAiLiI7DQpAQCAtMTIyLDkg KzEyMCw4IEBADQogCQkJICAgICFmbm1hdGNoKGVwLT5uYW1lLCBwLT5mdHNf bmFtZSwgRk5NX1BBVEhOQU1FKSkgfHwNCiAJCQkgICAgIXN0cmNtcChlcC0+ bmFtZSwgcC0+ZnRzX25hbWUpKSB7DQogCQkJCWVwLT5mbGFncyB8PSBGX1ZJ U0lUOw0KLQkJCQlpZiAoKGVwLT5mbGFncyAmIEZfTk9DSEFOR0UpID09IDAg JiYNCi0JCQkJICAgIGNvbXBhcmUoZXAtPm5hbWUsIGVwLCBwKSkNCi0JCQkJ CXJ2YWwgPSBNSVNNQVRDSEVYSVQ7DQorCQkJCWlmICgoZXAtPmZsYWdzICYg Rl9OT0NIQU5HRSkgPT0gMCkNCisJCQkJCSh2b2lkKWNvbXBhcmUoZXAtPm5h bWUsIGVwLCBwKTsNCiAJCQkJaWYgKGVwLT5mbGFncyAmIEZfSUdOKQ0KIAkJ CQkJKHZvaWQpZnRzX3NldCh0LCBwLCBGVFNfU0tJUCk7DQogCQkJCWVsc2Ug aWYgKGVwLT5jaGlsZCAmJiBlcC0+dHlwZSA9PSBGX0RJUiAmJg0KQEAgLTEz OSwxNSArMTM2LDE4IEBADQogCQkJY29udGludWU7DQogZXh0cmE6DQogCQlp ZiAoIWVmbGFnKSB7DQorCQkJRklYRUQ7DQogCQkJKHZvaWQpcHJpbnRmKCIl cyBleHRyYSIsIFJQKHApKTsNCiAJCQlpZiAocmZsYWcpIHsNCiAJCQkJaWYg KChTX0lTRElSKHAtPmZ0c19zdGF0cC0+c3RfbW9kZSkNCiAJCQkJICAgID8g cm1kaXIgOiB1bmxpbmspKHAtPmZ0c19hY2NwYXRoKSkgew0KIAkJCQkJKHZv aWQpcHJpbnRmKCIsIG5vdCByZW1vdmVkOiAlcyIsDQogCQkJCQkgICAgc3Ry ZXJyb3IoZXJybm8pKTsNCisJCQkJCUZBSUxFRDsNCiAJCQkJfSBlbHNlDQog CQkJCQkodm9pZClwcmludGYoIiwgcmVtb3ZlZCIpOw0KLQkJCX0NCisJCQl9 IGVsc2UNCisJCQkJRkFJTEVEOw0KIAkJCSh2b2lkKXB1dGNoYXIoJ1xuJyk7 DQogCQl9DQogCQkodm9pZClmdHNfc2V0KHQsIHAsIEZUU19TS0lQKTsNCkBA IC0xNTUsNyArMTU1LDYgQEANCiAJKHZvaWQpZnRzX2Nsb3NlKHQpOw0KIAlp ZiAoc2ZsYWcpDQogCQl3YXJueCgiJXMgY2hlY2tzdW06ICVsdSIsIGZ1bGxw YXRoLCBjcmNfdG90YWwpOw0KLQlyZXR1cm4gKHJ2YWwpOw0KIH0NCiANCiBz dGF0aWMgdm9pZA0KQEAgLTE3OCw4ICsxNzcsMTAgQEANCiAgDQogCQkJaWYg KHFmbGFnICYmIHN0YXQocGF0aCwgJnN0YXRidWYpID09IDApDQogCQkJCXAt PmZsYWdzIHw9IEZfVklTSVQ7DQotCQkJZWxzZQ0KKwkJCWVsc2Ugew0KIAkJ CQkodm9pZClwcmludGYoIiVzIG1pc3NpbmciLCBwYXRoKTsNCisJCQkJRklY RUQ7DQorCQkJfQ0KIAkJfQ0KIAkJaWYgKHAtPnR5cGUgIT0gRl9ESVIgJiYg cC0+dHlwZSAhPSBGX0xJTkspIHsNCiAJCQlwdXRjaGFyKCdcbicpOw0KQEAg LTE5NywxNCArMTk4LDE3IEBADQogCQkJZWxzZSBpZiAoIShwLT5mbGFncyAm IChGX0dJRCB8IEZfR05BTUUpKSkNCiAJCQkJKHZvaWQpcHJpbnRmKCIgKCVz IG5vdCBjcmVhdGVkOiBncm91cCBub3Qgc3BlY2lmaWVkKSIsIHR5cGUpOw0K IAkJCWVsc2UgaWYgKHAtPnR5cGUgPT0gRl9MSU5LKSB7DQotCQkJCWlmIChz eW1saW5rKHAtPnNsaW5rLCBwYXRoKSkNCisJCQkJaWYgKHN5bWxpbmsocC0+ c2xpbmssIHBhdGgpKSB7DQogCQkJCQkodm9pZClwcmludGYoIiAoc3ltbGlu ayBub3QgY3JlYXRlZDogJXMpXG4iLA0KIAkJCQkJICAgIHN0cmVycm9yKGVy cm5vKSk7DQotCQkJCWVsc2UNCisJCQkJCUZBSUxFRDsNCisJCQkJfSBlbHNl DQogCQkJCQkodm9pZClwcmludGYoIiAoY3JlYXRlZClcbiIpOw0KLQkJCQlp ZiAobGNob3duKHBhdGgsIHAtPnN0X3VpZCwgcC0+c3RfZ2lkKSkNCisJCQkJ aWYgKGxjaG93bihwYXRoLCBwLT5zdF91aWQsIHAtPnN0X2dpZCkpIHsNCiAJ CQkJCSh2b2lkKXByaW50ZigiJXM6IHVzZXIvZ3JvdXAgbm90IG1vZGlmaWVk OiAlc1xuIiwNCiAJCQkJCSAgICBwYXRoLCBzdHJlcnJvcihlcnJubykpOw0K KwkJCQkJRkFJTEVEOw0KKwkJCQl9DQogCQkJCWNvbnRpbnVlOw0KIAkJCX0g ZWxzZSBpZiAoIShwLT5mbGFncyAmIEZfTU9ERSkpDQogCQkJICAgICh2b2lk KXByaW50ZigiIChkaXJlY3Rvcnkgbm90IGNyZWF0ZWQ6IG1vZGUgbm90IHNw ZWNpZmllZCkiKTsNCkBAIC0yMTUsNiArMjE5LDggQEANCiAJCQkJY3JlYXRl ID0gMTsNCiAJCQkJKHZvaWQpcHJpbnRmKCIgKGNyZWF0ZWQpIik7DQogCQkJ fQ0KKwkJCWlmICghY3JlYXRlKQ0KKwkJCQlGQUlMRUQ7DQogCQl9DQogCQlp ZiAoIShwLT5mbGFncyAmIEZfVklTSVQpKQ0KIAkJCSh2b2lkKXB1dGNoYXIo J1xuJyk7DQpAQCAtMjMxLDE0ICsyMzcsMTkgQEANCiAJCQkgICAgcGF0aCwg c3RyZXJyb3IoZXJybm8pKTsNCiAJCQkodm9pZClwcmludGYoIiVzOiB3YXJu aW5nOiBmaWxlIG1vZGUgJXNub3Qgc2V0XG4iLCBwYXRoLA0KIAkJCSAgICAo cC0+ZmxhZ3MgJiBGX0ZMQUdTKSA/ICJhbmQgZmlsZSBmbGFncyAiIDogIiIp Ow0KKwkJCUZBSUxFRDsNCiAJCQljb250aW51ZTsNCiAJCX0NCi0JCWlmIChj aG1vZChwYXRoLCBwLT5zdF9tb2RlKSkNCisJCWlmIChjaG1vZChwYXRoLCBw LT5zdF9tb2RlKSkgew0KIAkJCSh2b2lkKXByaW50ZigiJXM6IHBlcm1pc3Np b25zIG5vdCBzZXQ6ICVzXG4iLA0KIAkJCSAgICBwYXRoLCBzdHJlcnJvcihl cnJubykpOw0KKwkJCUZBSUxFRDsNCisJCX0NCiAJCWlmICgocC0+ZmxhZ3Mg JiBGX0ZMQUdTKSAmJiBwLT5zdF9mbGFncyAmJg0KLQkJICAgIGNoZmxhZ3Mo cGF0aCwgcC0+c3RfZmxhZ3MpKQ0KKwkJICAgIGNoZmxhZ3MocGF0aCwgcC0+ c3RfZmxhZ3MpKSB7DQogCQkJKHZvaWQpcHJpbnRmKCIlczogZmlsZSBmbGFn cyBub3Qgc2V0OiAlc1xuIiwNCiAJCQkgICAgcGF0aCwgc3RyZXJyb3IoZXJy bm8pKTsNCisJCQlGQUlMRUQ7DQorCQl9DQogCX0NCiB9DQo= --0-793760758-1015716649=:11778-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Mar 9 21:37:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from priv-edtnes16-hme0.telusplanet.net (defout.telus.net [199.185.220.240]) by hub.freebsd.org (Postfix) with ESMTP id 189EA37B417 for ; Sat, 9 Mar 2002 21:37:46 -0800 (PST) Received: from pfak ([216.232.34.44]) by priv-edtnes16-hme0.telusplanet.net (InterMail vM.5.01.04.02 201-253-122-122-102-20011128) with SMTP id <20020310053745.OBN5907.priv-edtnes16-hme0.telusplanet.net@pfak> for ; Sat, 9 Mar 2002 22:37:45 -0700 Message-ID: <002001c1c7f5$b9bdc060$6401a8c0@pfak> From: "Peter Kieser" To: References: <200203092001.g29K10B45017@scanner.secnap.net> <002c01c1c7a5$8dc31c30$6401a8c0@pfak> Subject: Re: Problems with Network after compile of latest 4.5-STABLE Date: Sat, 9 Mar 2002 21:37:53 -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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Welp, i've narrowed it down. When I take out 2 of the network cards (I have three in total) in my box, it boots. I had three in the box before I upgraded to the latest kernel. What's up with that? Someone goof up with some code? --Peter ----- Original Message ----- From: "Peter Kieser" To: "Michael Scheidell" Cc: Sent: Saturday, March 09, 2002 12:04 PM Subject: Re: Problems with Network after compile of latest 4.5-STABLE > I installed the machines all with 4.5-RELEASE, then did 4.5-STABLE, and the > generic kernel config, which worked with my network cards. Then I upgraded > a few days later to the latest source tree to recompile, recompiled; and it > stopped work. > > --Peter > > ----- Original Message ----- > From: "Michael Scheidell" > To: "Peter Kieser" > Cc: > Sent: Saturday, March 09, 2002 12:01 PM > Subject: Re: Problems with Network after compile of latest 4.5-STABLE > > > > > Hey hackers, > > > > > > As of the SSH bug, I updated the source for my kernel, and recompiled > it. I > > > was running 4.5-STABLE, and was just updating to the latest release. > After > > > the compile was complete, I rebooted and my network cards stopped > working. > > > This has happened on every box that I have attempted to upgrade, When I > look > > > on the actual console on the box, it says something about not being able > to > > > find lnc0, or de0, etc. Anyone had a similair problem? > > > > > you compare generic kernels? didn't 4.5 requir emii bus or something > > > Thanks alot, > > > > > > --Peter > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > -- > > Michael Scheidell > > SECNAP Network Security, LLC > > (561) 368-9561 scheidell@secnap.net > > http://www.secnap.net/ > > > > > > > > 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