From owner-freebsd-hackers Sun Apr 15 6:34:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 426F337B449 for ; Sun, 15 Apr 2001 06:34:55 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 20894 invoked by uid 666); 15 Apr 2001 10:50:49 -0000 Received: from unknown (HELO elischer.org) (203.59.176.234) by mail.m.iinet.net.au with SMTP; 15 Apr 2001 10:50:49 -0000 Message-ID: <3AD97C00.EF3A91FF@elischer.org> Date: Sun, 15 Apr 2001 03:46:24 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Doug Barton Cc: Bakul Shah , Robert Watson , r.hyunseog@ieee.org, hackers@FreeBSD.ORG Subject: Re: Interesting article. References: <200104101733.NAA09610@renown.cnchost.com> <3AD90C59.53E7DB55@DougBarton.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Barton wrote: > > Bakul Shah wrote: > > > > >From the top level page I read hotmail handles 550,000 change > > requests a day. Later in the article they say they have a > > 5000 server farm. That translates to 110 change requests a > > day on average per server. If the peak rate is 10 times the > > average, that is still only about 1100 requests/server/day or > > about 78 seconds on average. This rate seems quite low even > > when you account for multiple web page servings per change > > request.... Am I missing something obvious? > > You neglected to deduct the number of servers that are down/rebooting from > the 5k. :) > > http://www.microsoft.com/backstage/column_T2_1.htm this gives a blank screen... maybe they removed it. > > You just can't make this stuff up.... > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 6:39:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 213BC37B446 for ; Sun, 15 Apr 2001 06:39:42 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3FDb4f51412; Sun, 15 Apr 2001 09:37:04 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 15 Apr 2001 09:37:04 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: Doug Barton , Bakul Shah , r.hyunseog@ieee.org, hackers@FreeBSD.ORG Subject: Re: Interesting article. In-Reply-To: <3AD97C00.EF3A91FF@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Apr 2001, Julian Elischer wrote: > > http://www.microsoft.com/backstage/column_T2_1.htm > > this gives a blank screen... maybe they removed it. I found I had some netscape interop problems. Trying hitting reload a couple of times. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 7: 1:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from clmboh1-smtp3.columbus.rr.com (clmboh1-smtp3.columbus.rr.com [65.24.0.112]) by hub.freebsd.org (Postfix) with ESMTP id 7300C37B423; Sun, 15 Apr 2001 07:01:07 -0700 (PDT) (envelope-from wmoran@iowna.com) Received: from iowna.com (dhcp065-024-023-038.columbus.rr.com [65.24.23.38]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with ESMTP id f3FDwAf00862; Sun, 15 Apr 2001 09:58:10 -0400 (EDT) Message-ID: <3AD9A923.AD35A7D9@iowna.com> Date: Sun, 15 Apr 2001 09:58:59 -0400 From: Bill Moran X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: Julian Elischer , Doug Barton , Bakul Shah , r.hyunseog@ieee.org, hackers@FreeBSD.ORG Subject: Re: Interesting article. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > > On Sun, 15 Apr 2001, Julian Elischer wrote: > > > > http://www.microsoft.com/backstage/column_T2_1.htm > > > > this gives a blank screen... maybe they removed it. > > I found I had some netscape interop problems. Trying hitting reload a > couple of times. If you're using Netscrap, turn off javascript and the page will load fine. I'd guess the M$ is using "Visual J" or something which is almost compatable with JavaScript, but not quite. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 8:55:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id E594D37B43E; Sun, 15 Apr 2001 08:55:10 -0700 (PDT) (envelope-from rminnich@lanl.gov) Received: from white.acl.lanl.gov (root@white.acl.lanl.gov [128.165.147.100]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id JAA3489432; Sun, 15 Apr 2001 09:55:05 -0600 (MDT) Received: from localhost (rminnich@localhost) by white.acl.lanl.gov (8.9.3/8.8.8) with ESMTP id JAA11886; Sun, 15 Apr 2001 09:55:05 -0600 X-Authentication-Warning: white.acl.lanl.gov: rminnich owned process doing -bs Date: Sun, 15 Apr 2001 09:55:05 -0600 (MDT) From: Ronald G Minnich X-Sender: To: Robert Watson Cc: Julian Elischer , Doug Barton , Bakul Shah , , Subject: Re: Interesting article. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Apr 2001, Robert Watson wrote: > > On Sun, 15 Apr 2001, Julian Elischer wrote: > > > > http://www.microsoft.com/backstage/column_T2_1.htm > > > > this gives a blank screen... maybe they removed it. > > I found I had some netscape interop problems. Trying hitting reload a > couple of times. well there's a shock ... a microsoft web page not working with netscape? ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 9:31:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from firewall.moonworld.org (dsl-64-34-46-105.telocity.com [64.34.46.105]) by hub.freebsd.org (Postfix) with ESMTP id F33EE37B449; Sun, 15 Apr 2001 09:31:41 -0700 (PDT) (envelope-from moonhunt@moonworld.org) Received: from moonworld.org (moonhunt.moonworld.org [192.168.1.1]) by firewall.moonworld.org (8.9.3/8.9.3) with ESMTP id LAA93295; Sun, 15 Apr 2001 11:28:04 -0500 (CDT) (envelope-from moonhunt@moonworld.org) Message-ID: <3AD9CCE6.14527CD7@moonworld.org> Date: Sun, 15 Apr 2001 11:31:34 -0500 From: HyunSeog Ryu Reply-To: r.hyunseog@ieee.org Organization: Moon world X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,ko MIME-Version: 1.0 To: Ronald G Minnich Cc: Robert Watson , Julian Elischer , Doug Barton , Bakul Shah , r.hyunseog@ieee.org, hackers@FreeBSD.ORG Subject: Re: Interesting article. References: Content-Type: multipart/mixed; boundary="------------5E59E6DEA72D22B7A447145A" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------5E59E6DEA72D22B7A447145A Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Not very well. Especially if somebody made webpage using Microsoft tools, it doesn't work with Netscape very well. Sometimes you will see empty screen from Netscape. Sometimes javascript button will appear different location in the screen. ;< Hyun Ronald G Minnich wrote: > > On Sun, 15 Apr 2001, Robert Watson wrote: > > > > > On Sun, 15 Apr 2001, Julian Elischer wrote: > > > > > > http://www.microsoft.com/backstage/column_T2_1.htm > > > > > > this gives a blank screen... maybe they removed it. > > > > I found I had some netscape interop problems. Trying hitting reload a > > couple of times. > > well there's a shock ... a microsoft web page not working with netscape? > > ron --------------5E59E6DEA72D22B7A447145A Content-Type: text/x-vcard; charset=EUC-KR; name="moonhunt.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for HyunSeog Ryu Content-Disposition: attachment; filename="moonhunt.vcf" begin:vcard n:Ryu;HyunSeog tel;pager:(414)557-2253 tel;fax:(262)792-7733 tel;work:(262)792-7965 x-mozilla-html:FALSE url:http://www.moonworld.org/~moonhunt org:Norlight Telecommunications;Applications Engineering adr:;;275 North Corporate Drive;Brookfield;WI;53045-5818;US version:2.1 email;internet:r.hyunseog@ieee.org title:Network Engineer note;quoted-printable:nic-handile : HR201, HR201-ARIN, HR1-APNIC and work for AS#7260=0D=0A fn:HyunSeog Ryu end:vcard --------------5E59E6DEA72D22B7A447145A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 11:30:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 51B4B37B422 for ; Sun, 15 Apr 2001 11:30:49 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA77818 for ; Sun, 15 Apr 2001 14:30:48 -0400 (EDT) Message-Id: <200104151830.OAA77818@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: a bug in ypserv found Date: Sun, 15 Apr 2001 14:30:47 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have found _a_ bug in ypserv (I think I may be stumbling over multiple different bugs, but this one is very reproducable). It is dying in the yp_testflags routine, in the for loop that goes through the CIRCLEQ. The loop dies with qptr pointing to a struct that is all NULL (my reading of CIRCLEQ suggests this isn't supposed to be possible), *and* qhead (the global variable representing the CIRCLEQ_HEAD) pointing to a structure that is all NULL (also not supposed to be possible). The fact that &qptr != qhead to me suggests that there was data there when it started, but that it got ripped out from in under it. I am not sure how though: qhead is a "static" global variable, and the only async entry into the routine is called from the signal-handler for SIGHUP, problem is that SIGHUP is not being called. (Aside: this has been a real pain to track down... I traced it into the RPC library and back out the other side... NOT FUN) -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 12:53:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by hub.freebsd.org (Postfix) with ESMTP id 4815937B43E; Sun, 15 Apr 2001 12:53:27 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by illustrious.cnchost.com id PAA11103; Sun, 15 Apr 2001 15:53:25 -0400 (EDT) [ConcentricHost SMTP Relay 1.11] Message-ID: <200104151953.PAA11103@illustrious.cnchost.com> To: Doug Barton Cc: Robert Watson , r.hyunseog@ieee.org, hackers@FreeBSD.ORG Subject: Re: Interesting article. In-Reply-To: Your message of "Sat, 14 Apr 2001 19:50:01 PDT." <3AD90C59.53E7DB55@DougBarton.net> Date: Sun, 15 Apr 2001 12:53:24 -0700 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >From the top level page I read hotmail handles 550,000 change > > requests a day. Later in the article they say they have a > > 5000 server farm. That translates to 110 change requests a > > day on average per server. If the peak rate is 10 times the > > average, that is still only about 1100 requests/server/day or > > about 78 seconds on average. This rate seems quite low even > > when you account for multiple web page servings per change > > request.... Am I missing something obvious? > > You neglected to deduct the number of servers that are down/rebooting from > the 5k. :) > > http://www.microsoft.com/backstage/column_T2_1.htm > > You just can't make this stuff up.... It was a back-of-an-envelope kind of figuring to make some sense of their numbers -- not that it helped. But even if 50% of the machines are down (we don't have data to prove that) at any given time, the request serving rate still seems low. Also, the above article talks about www.microsoft.com servers not hotmail servers. Thanks for the url, though. Without that I would not have seen this gem: Not having a one-to-one ratio of VIPs to DIPs gives us a mixture of fail-safe and ease of maintenance, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 17:28: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id E01EA37B496; Sun, 15 Apr 2001 17:27:58 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 46891676E0; Sun, 15 Apr 2001 17:27:58 -0700 (PDT) Date: Sun, 15 Apr 2001 17:27:58 -0700 From: Kris Kennaway To: audit@FreeBSD.org, hackers@freebsd.org Subject: OpenBSD interesting commits Message-ID: <20010415172758.A17079@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've put a mailbox containing some of the 'interesting commits' I've flagged from the OpenBSD CVS commit mailing list at http://www.freebsd.org/~kris/openbsd.mbox There are some easy commits there, but I don't have time to do much myself (it's enough work just reading the commit lists). Perhaps someone else does: if you commit something, or look into it and discover it to not be relevant to FreeBSD, please let me know which messages to remove from the mailbox (i.e. by Message-ID). Kris --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE62jyNWry0BWjoQKURAryuAJ0UK/rO66Fb4bbG37nqT3BmmG4QJACfc2bK 3Qjn7Bni/BgQOZrO9jpBq0A= =XvOx -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 18:58:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from castle.dreaming.org (castle.dreaming.org [216.221.214.170]) by hub.freebsd.org (Postfix) with ESMTP id A8E6F37B42C; Sun, 15 Apr 2001 18:58:13 -0700 (PDT) (envelope-from mitayai@branchmedia.com) Received: (from root@localhost) by castle.dreaming.org (8.11.3/8.11.2) id f3G1w8462452; Sun, 15 Apr 2001 21:58:08 -0400 (EDT) (envelope-from mitayai@branchmedia.com) Received: from arachne.dreaming.org (arachne.dreaming.org [216.221.214.171]) by castle.dreaming.org (8.11.3/8.11.2av) with ESMTP id f3G1w5M62443; Sun, 15 Apr 2001 21:58:05 -0400 (EDT) (envelope-from mitayai@branchmedia.com) Received: (from www@localhost) by arachne.dreaming.org (8.11.3/8.11.2) id f3G1ukM56365; Sun, 15 Apr 2001 21:56:46 -0400 (EDT) (envelope-from mitayai@branchmedia.com) X-Authentication-Warning: arachne.dreaming.org: www set sender to mitayai@branchmedia.com using -f To: freebsd-questions@freebsd.org Subject: Mounting Linux Partitions in Extended Partitions Message-ID: <987386205.3ada515dd3520@postoffice.dreaming.org> Date: Sun, 15 Apr 2001 21:56:45 -0400 (EDT) From: Will Mitayai Keeso Rowe Cc: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 216.129.192.238 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! I have a machine here that has a SCSI disk that used to have Linux installed on it. When i check fdisk, it appears that there are two partitions, 1 with 23M that seems to have the boot stuff and kernel, and then one with several Gigs with the actual data (i booted into Linux to make sure, everything looks fine). In FreeBSD, when i look at fdisk, the first partition is labelled as ext2fs and the second partition is labelled as DOS extended. I can mount the first one fine with mount_ext2fs, but i can't figure out if, or how, i can mount the larger one. Does anyone have any insight? Regards, Mit Will Mitayai Keeso Rowe Branch Media, Inc. / DreamLabs / Mitayai.Net mit@branchmedia.com http://www.branchmedia.com | http://www.dreamlabs.com v: (416)323-0840 f: (416)323-0894 ------------------------------------------------- This mail sent through IMP: postoffice.dreaming.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 19: 3:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chmod.ath.cx (CC2-861.charter-stl.com [24.217.115.99]) by hub.freebsd.org (Postfix) with ESMTP id 50D9A37B42C; Sun, 15 Apr 2001 19:03:38 -0700 (PDT) (envelope-from ajh3@chmod.ath.cx) Received: by chmod.ath.cx (Postfix, from userid 1001) id 0AD47A91E; Sun, 15 Apr 2001 21:02:36 -0500 (CDT) Date: Sun, 15 Apr 2001 21:02:35 -0500 From: Andrew Hesford To: Will Mitayai Keeso Rowe Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Mounting Linux Partitions in Extended Partitions Message-ID: <20010415210235.A12986@cec.wustl.edu> References: <987386205.3ada515dd3520@postoffice.dreaming.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <987386205.3ada515dd3520@postoffice.dreaming.org>; from mitayai@branchmedia.com on Sun, Apr 15, 2001 at 09:56:45PM -0400 X-Loop: Andrew Hesford Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 15, 2001 at 09:56:45PM -0400, Will Mitayai Keeso Rowe wrote: > Hello! > > I have a machine here that has a SCSI disk that used to have Linux > installed on it. > > When i check fdisk, it appears that there are two partitions, 1 with > 23M that seems to have the boot stuff and kernel, and then one with > several Gigs with the actual data (i booted into Linux to make sure, > everything looks fine). > > In FreeBSD, when i look at fdisk, the first partition is labelled as > ext2fs and the second partition is labelled as DOS extended. I can > mount the first one fine with mount_ext2fs, but i can't figure out if, > or how, i can mount the larger one. > > Does anyone have any insight? Use the slice number equal to the partition number in linux. For instace, if Linux saw the disk as sdb6, use da1s6 in FreeBSD. This will work just fine. -- Andrew Hesford ajh3@chmod.ath.cx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 19:53:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gradient.cis.upenn.edu (GRADIENT.CIS.UPENN.EDU [158.130.67.48]) by hub.freebsd.org (Postfix) with ESMTP id 801CA37B423; Sun, 15 Apr 2001 19:53:32 -0700 (PDT) (envelope-from agoodloe@gradient.cis.upenn.edu) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f3G2rUp05126; Sun, 15 Apr 2001 22:53:30 -0400 (EDT) Date: Sun, 15 Apr 2001 22:53:30 -0400 (EDT) From: Alwyn Goodloe To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Anyone managed to get microns ClientPro's X going Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We have several systems like our Micron ClientPros running FreeBSD. These machines have the Intel 82810E chip in it and what seems forever there has only been XFree86 drivers for the Linux. Is my info out of date?? Has anyone found a workaround ?? To be honest I'm tired of all the snickering from the Linux guys in my office. Not haveing X windows running was embarsing, but now I MUST have it working. I know that the XFree86 guys are the ones to bitch to but the last time I did they seemed to say -- use Linux. Any help, suggestions, etc. Alwyn agoodloe@gradient.cis.upenn.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 20:39:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by hub.freebsd.org (Postfix) with SMTP id 0739C37B449 for ; Sun, 15 Apr 2001 20:39:27 -0700 (PDT) (envelope-from fasi_74@yahoo.com) Received: from unknown (HELO client2) (202.87.102.168) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Apr 2001 03:39:25 -0000 X-Apparently-From: Message-ID: <00a101c0c68b$cd31ca40$a86657ca@client2> From: "faisal" To: "Andrew Hesford" , "Will Mitayai Keeso Rowe" Cc: "FreeBSD" , References: <987386205.3ada515dd3520@postoffice.dreaming.org> <20010415210235.A12986@cec.wustl.edu> Subject: freebsd in dos extended ? Date: Mon, 16 Apr 2001 08:42:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Can freeBSD be installed in a dos extended partition ? I am having real trouble creating another primary partition .. on have 1 dos logical partition in my extended .. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 21:35:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A379437B43F; Sun, 15 Apr 2001 21:35:41 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3G4ZbR20312; Sun, 15 Apr 2001 21:35:37 -0700 (PDT) Date: Sun, 15 Apr 2001 21:35:37 -0700 From: Alfred Perlstein To: Alwyn Goodloe Cc: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Anyone managed to get microns ClientPro's X going Message-ID: <20010415213537.B976@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from agoodloe@gradient.cis.upenn.edu on Sun, Apr 15, 2001 at 10:53:30PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alwyn Goodloe [010415 19:54] wrote: > > We have several systems like our Micron ClientPros running FreeBSD. > > These machines have the Intel 82810E chip in it and what seems forever > there has only been XFree86 drivers for the Linux. > > Is my info out of date?? > > Has anyone found a workaround ?? > > To be honest I'm tired of all the snickering from the Linux guys in my > office. Not haveing X windows running was embarsing, but now I MUST have > it working. > > I know that the XFree86 guys are the ones to bitch to but the last time I > did they seemed to say -- use Linux. > > > Any help, suggestions, etc. Almost all the graphical support in XFree86 is in XFree86, there's probably nothing in there that's Linux dependant. so: 1) ask these snickering wankers for thier XFree config files, they should just work (as long as you have the same version of XFree) 2) make sure you're running the same version of XFree that they are, perhaps you're using XFree 3 while the Linux people have Xfree 4. (XFree 4 is available in ports) 3) or... ask your boss to plonk down ~100$ for a commercial X server: http://www.metrolink.com/ http://www.xig.com/ -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 21:37:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id CB71337B43F; Sun, 15 Apr 2001 21:37:56 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=55ec35fc744f4083832c055185db7b68) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14p0lk-0000KW-00; Sun, 15 Apr 2001 22:37:44 -0600 Message-ID: <3ADA7717.BFFF01AB@softweyr.com> Date: Sun, 15 Apr 2001 22:37:44 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Robert Watson , r.hyunseog@ieee.org, hackers@freebsd.org Subject: Re: Interesting article. References: <200104101733.NAA09610@renown.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bakul Shah wrote: > > Though, a lack of good Unicode support on FreeBSD seems like > a legitimate enough reason for the move. Yes, it would, if it were true, see /usr/ports/devel/libunicode. > Regardless, note that doubling of the performance meant they > saved anywhere from $10M to $20M (5000 servers x (price + > maintenance of each server) - development and testing costs). > Another doubling would still save them $5M or so! I'd take > that challenge if I can get 50% of the savings!:-) In order to determine if they really made any savings or not -- I notice that they've increased the number of servers at Hotmail from 3,400 to 5,000 - you'd also have to determine how much they could have improved the performance by merely writing their code as an Apache module. In my experience, if they were running on a relatively unmodified Apache CGI interface and using compiled C or C++ CGI's, they could easily double their performance by making the same code into a module, an exercise that should take a couple of experienced programmers a few weeks to do, at worst. They specifically mention the process-per-socket model in Apache, but don't mention attempting to do any performance tuning on it. The obvious first experiment would be a pre-forked server; another would be to replace the process per socket with a single process and I/O selection via select(2) or kqueue(2). So, was that 18 month development project really necessary from a technical standpoint, or only justified as a marketing cost? Nobody outside Microsoft management will ever really know. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 21:41:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id AE80F37B42C; Sun, 15 Apr 2001 21:41:24 -0700 (PDT) Date: Sun, 15 Apr 2001 21:41:24 -0700 From: "John W. De Boskey" To: Hackers List Subject: sys/kern/tty.c ttnread(tp) logic question Message-ID: <20010415214124.A93344@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've been reviewing parts of the tty driver and ran into a very basic question which I am unable to find an answer for. The function ttnread(): static int ttnread(tp) struct tty *tp; { int nread; if (ISSET(tp->t_lflag, PENDIN)) ttypend(tp); nread = tp->t_canq.c_cc; if (!ISSET(tp->t_lflag, ICANON)) { nread += tp->t_rawq.c_cc; if (nread < tp->t_cc[VMIN] && tp->t_cc[VTIME] == 0) nread = 0; } return (nread); } sets the variable nread to t_canq.c_cc (reasonable). However, if ICANON mode is not set (ie: the terminal is probably in raw mode), it then adds to the value to nread. This is where my question comes from. The tty linesw[] function for l_read "ttread()" has the following near the top: qp = ISSET(lflag, ICANON) ? &tp->t_canq : &tp->t_rawq; and the code only seems to satisfy the read request from the single chosen queue. So it seems that it may be possible for more data to be reported available than can actually be read. If anyone can shed some light on this code I would appreciate it. Thanks, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 21:43:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp-2.enteract.com (smtp-2.enteract.com [207.229.143.4]) by hub.freebsd.org (Postfix) with ESMTP id 1960137B423; Sun, 15 Apr 2001 21:43:14 -0700 (PDT) (envelope-from dscheidt@tumbolia.com) Received: from shell-1.enteract.com (shell-1.enteract.com [207.229.143.40]) by smtp-2.enteract.com (Postfix) with ESMTP id D97FF6351; Sun, 15 Apr 2001 23:43:01 -0500 (CDT) Date: Sun, 15 Apr 2001 23:43:03 -0500 (CDT) From: David Scheidt X-Sender: dscheidt@shell-1.enteract.com To: Alfred Perlstein Cc: Alwyn Goodloe , freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Anyone managed to get microns ClientPro's X going In-Reply-To: <20010415213537.B976@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 15 Apr 2001, Alfred Perlstein wrote: :* Alwyn Goodloe [010415 19:54] wrote: :> :> We have several systems like our Micron ClientPros running FreeBSD. :> :> These machines have the Intel 82810E chip in it and what seems forever :> there has only been XFree86 drivers for the Linux. : :Almost all the graphical support in XFree86 is in XFree86, there's :probably nothing in there that's Linux dependant. And, in the event that there's some linux binary-only server for this card, it can probably be run on FreeBSD in Linux emulation. I did this for a VodooMumble, when the only xserver was 3dxf's linux binary one. It just worked, except when my linux module got out of sync. David -- dscheidt@tumbolia.com Bipedalism is only a fad. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 15 22:20:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from vbook.express.ru (vbook.express.ru [212.24.37.106]) by hub.freebsd.org (Postfix) with ESMTP id 6C1D437B424 for ; Sun, 15 Apr 2001 22:20:16 -0700 (PDT) (envelope-from vova@vbook.express.ru) Received: (from vova@localhost) by vbook.express.ru (8.9.3/8.9.3) id TAA02304; Sat, 14 Apr 2001 19:51:32 +0400 (MSD) (envelope-from vova) From: "Vladimir B. Grebenschikov" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15064.29187.667341.757712@vbook.express.ru> Date: Sat, 14 Apr 2001 19:51:31 +0400 (MSD) To: freebsd-hackers@freebsd.org Subject: Idea about modules build X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have idea about modules build/install process: May be it need to create some makefile variable like KERNEL_MODULES, that can be defined in /etc/make.conf to limit list of modules to build/install, it is not very good idea to spend a lot of CPU time building modules, that never be used ? -- 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 Sun Apr 15 22:27:46 2001 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 4F68F37B424; Sun, 15 Apr 2001 22:27:38 -0700 (PDT) (envelope-from bsddiy@21cn.com) Received: from xyf ([192.168.1.204]) by mail.viasoft.com.cn (8.9.3/8.9.3) with SMTP id NAA19848; Mon, 16 Apr 2001 13:24:22 +0800 Message-ID: <005101c0c636$22166300$cc01a8c0@xyf> From: "bsddiy" To: "faisal" , "Andrew Hesford" , "Will Mitayai Keeso Rowe" Cc: "FreeBSD" , References: <987386205.3ada515dd3520@postoffice.dreaming.org> <20010415210235.A12986@cec.wustl.edu> <00a101c0c68b$cd31ca40$a86657ca@client2> Subject: Re: freebsd in dos extended ? Date: Mon, 16 Apr 2001 13:28:36 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know if FreeBSD supports installing into DOS extended partition. installing an OS in a DOS extended partition is dangrous, it can be easily rewritten by DOS utils, if you havn't space to create a partition, I sugguest you use PQMagic like partition utils to shrink existing partitions, then install FreeBSD in new partition. David Xu ----- Original Message ----- From: faisal To: Andrew Hesford ; Will Mitayai Keeso Rowe Cc: FreeBSD ; Sent: Monday, April 16, 2001 11:42 PM Subject: freebsd in dos extended ? > Hello > > Can freeBSD be installed in a dos extended partition ? > I am having real trouble creating another primary partition .. > on have 1 dos logical partition in my extended .. > > > > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.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 Sun Apr 15 22:51:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from vbook.express.ru (vbook.express.ru [212.24.37.106]) by hub.freebsd.org (Postfix) with ESMTP id 95CC537B43F for ; Sun, 15 Apr 2001 22:51:14 -0700 (PDT) (envelope-from vova@vbook.express.ru) Received: (from vova@localhost) by vbook.express.ru (8.9.3/8.9.3) id JAA01380 for freebsd-hackers@freebsd.org; Mon, 16 Apr 2001 09:51:20 +0400 (MSD) (envelope-from vova) Date: Mon, 16 Apr 2001 09:51:20 +0400 (MSD) Message-Id: <200104160551.JAA01380@vbook.express.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Vladimir B. Grebenschikov" To: freebsd-hackers@freebsd.org Subject: Idea about modules build X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have idea about modules build/install process: May be it need to create some makefile variable like KERNEL_MODULES, that can be defined in /etc/make.conf to limit list of modules to build/install, it is not very good idea to spend a lot of CPU time building modules, that never be used ? -- 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 Sun Apr 15 23:17:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by hub.freebsd.org (Postfix) with ESMTP id 489BA37B422 for ; Sun, 15 Apr 2001 23:17:30 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by repulse.cnchost.com id CAA22321; Mon, 16 Apr 2001 02:17:24 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <200104160617.CAA22321@repulse.cnchost.com> To: Wes Peters Cc: hackers@freebsd.org Reply-To: freebsd-chat@freebsd.org Subject: Re: Interesting article. In-Reply-To: Your message of "Sun, 15 Apr 2001 22:37:44 MDT." <3ADA7717.BFFF01AB@softweyr.com> Date: Sun, 15 Apr 2001 23:17:23 -0700 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Though, a lack of good Unicode support on FreeBSD seems like > > a legitimate enough reason for the move. > > Yes, it would, if it were true, see /usr/ports/devel/libunicode. One port does not make good support. For that FreeBDS has to have native unicode support. > In order to determine if they really made any savings or not -- I > notice that they've increased the number of servers at Hotmail from > 3,400 to 5,000 - you'd also have to determine how much they could have > improved the performance by merely writing their code as an Apache > module. If as they claim they doubled the performance, they saved a few mil in not having to use 10,000 servers. My point was they didn't save *as much money as* they could've, had they used various performance increasing tricks we are well aware of. > So, was that 18 month development project really necessary from a > technical standpoint, or only justified as a marketing cost? Nobody > outside Microsoft management will ever really know. Suspect the most likely cause of conversion can be summed up in the phrase `eating your own dogfood'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 0:11:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id EAC9B37B43C for ; Mon, 16 Apr 2001 00:11:35 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3G7BGO59505; Mon, 16 Apr 2001 00:11:16 -0700 (PDT) (envelope-from obrien) Date: Mon, 16 Apr 2001 00:09:54 -0700 From: "David O'Brien" To: "Vladimir B. Grebenschikov" Cc: hackers@freebsd.org Subject: Re: Idea about modules build Message-ID: <20010416000954.A59480@dragon.nuxi.com> Reply-To: hackers@freebsd.org References: <200104160551.JAA01380@vbook.express.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104160551.JAA01380@vbook.express.ru>; from vova@express.ru on Mon, Apr 16, 2001 at 09:51:20AM +0400 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 X-Loop: FreeBSD.ORG On Mon, Apr 16, 2001 at 09:51:20AM +0400, Vladimir B. Grebenschikov wrote: > I have idea about modules build/install process: Warner (imp) was to commit this fuctionality to 5-current (and back port to releng_4 after 4.3-RELEASE). -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 0:48:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by hub.freebsd.org (Postfix) with SMTP id 48C4437B440 for ; Mon, 16 Apr 2001 00:48:30 -0700 (PDT) (envelope-from thunderch1ld@yahoo.com) Received: from adsl-64-172-25-118.dsl.sntc01.pacbell.net (64.172.25.118) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Apr 2001 07:48:30 -0000 X-Apparently-From: Date: Mon, 16 Apr 2001 00:51:37 PDT From: Mike Makonnen To: "faisal" , "Andrew Hesford" , "Will Mitayai Keeso Rowe" Cc: "FreeBSD" , Subject: Re: freebsd in dos extended ? Reply-To: thunderch1ld@yahoo.com X-Mailer: Spruce 0.6.5 for X11 w/smtpio 0.7.9 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20010416074830.48C4437B440@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Why do you want to install it on a DOS extended partition? Just remove that extended patition and install FreeBSD in the unused portion of the disk. Install the FreeBSD boot manager so you can boot into whichever OS you want to. Mike. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 2:34:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by hub.freebsd.org (Postfix) with ESMTP id 917BF37B43C for ; Mon, 16 Apr 2001 02:34:26 -0700 (PDT) (envelope-from oscar@ac.upc.es) Received: from ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id f3G9YGI08603 for ; Mon, 16 Apr 2001 11:34:16 +0200 (MET DST) Message-ID: <3ADABC98.B26D6C78@ac.upc.es> Date: Mon, 16 Apr 2001 11:34:16 +0200 From: Oscar-Ivan Lepe-Aldama Organization: DAC/UPC X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: es, en MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Sysctl question (again) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! the technical question follows the next commentary. This is the second (third) time I post this question. I'm wondering why I haven't got any answers. Is it because this isn't the right forum? Is it because I haven't been clear enough? Is it because my bad english? Any clue on why the people in this forum can not give me any kind of answer for the following question will be aprreciated. Now, the technical question follows. Is there a maximum for the size of an object that sysctl can handle? I'm asking this because I have inserted in a 4.1.1 kernel an array defined as struct buf_entry { unsgined int id; u_int64_t tsc; u_int64_t pmec1; u_int64_t pmec2; } mybuffer[NUMENTRIES]; SYSCTL_NODE(, CTL_NAVI, experiments, CTLFLAG_RW, 0,"Experiments"); SYSCTL_OPAQUE(_experiments, OID_AUTO, buffer, CTLFLAG_RD, &mybuffer, sizeof(mybuffer), "", ""); When NUMENTRIES equals 100000 (100 thousand) everything works well; that is, I can read the content of the array using sysctl -b experiments.mybuffer > somefile.raw But when NUMENTRIES equals 1000000 (1 million) and I use the above command to read the content of the array, the system stops working properly; that is, all virtual terminals freezed so I can't sent any command to the system, although the kernel seams to be alive as it responds to ICMP echo packets. I do want to have a large array within the kernel's memory space as I'm measuring the performance of some kernel's routines using the Pentium's Performance Monitoring Event Counters, and the more performance data I could get in one experiment the best. By the way, the system under test has 64 MB of RAM and 20 GB of free space on disk. Any explanation on the possibility or the impossibility of having such large array within the kernel memory-space and having it exported through sysctlt will be verry much appreciated. Thanks, -- ======================================================================== 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC 0 0 0 e-mail: oscar@ac.upc.es | Modul D6, despatx 116 0 0 0 phone: +34 93 401 7187 | Jordi Girona, 1-3 U P C fax: +34 93 401 7055 | 08034 Barcelona - SPAIN WWW: http://www.ac.upc.es/homes/oscar/ ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 2:48:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8A10337B42C for ; Mon, 16 Apr 2001 02:48:53 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3G9mok27600; Mon, 16 Apr 2001 02:48:50 -0700 (PDT) Date: Mon, 16 Apr 2001 02:48:50 -0700 From: Alfred Perlstein To: Oscar-Ivan Lepe-Aldama Cc: hackers@FreeBSD.ORG Subject: Re: Sysctl question (again) Message-ID: <20010416024850.I976@fw.wintelcom.net> References: <3ADABC98.B26D6C78@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ADABC98.B26D6C78@ac.upc.es>; from oscar@ac.upc.es on Mon, Apr 16, 2001 at 11:34:16AM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Oscar-Ivan Lepe-Aldama [010416 02:34] wrote: > Hi! > the technical question follows the next commentary. This is the second > (third) time I post this question. I'm wondering why I haven't got any > answers. Is it because this isn't the right forum? Is it because I > haven't been clear enough? Is it because my bad english? Any clue on why > the people in this forum can not give me any kind of answer for the > following question will be aprreciated. Now, the technical question > follows. > > Is there a maximum for the size of an object that sysctl can handle? > > I'm asking this because I have inserted in a 4.1.1 kernel an array > defined as > > > struct buf_entry { > unsgined int id; > u_int64_t tsc; > u_int64_t pmec1; > u_int64_t pmec2; > } mybuffer[NUMENTRIES]; > > SYSCTL_NODE(, CTL_NAVI, experiments, CTLFLAG_RW, 0,"Experiments"); > SYSCTL_OPAQUE(_experiments, OID_AUTO, buffer, CTLFLAG_RD, &mybuffer, > sizeof(mybuffer), "", ""); > > > When NUMENTRIES equals 100000 (100 thousand) everything works well; that > is, I can read the content of the array using > > sysctl -b experiments.mybuffer > somefile.raw > > But when NUMENTRIES equals 1000000 (1 million) and I use the above > command to read the content of the array, the system stops working > properly; that is, all virtual terminals freezed so I can't sent any > command to the system, although the kernel seams to be alive as it > responds to ICMP echo packets. > > I do want to have a large array within the kernel's memory space as I'm > measuring the performance of some kernel's routines using the Pentium's > Performance Monitoring Event Counters, and the more performance data I > could get in one experiment the best. > > By the way, the system under test has 64 MB of RAM and 20 GB of free > space on disk. > > Any explanation on the possibility or the impossibility of having such > large array within the kernel memory-space and having it exported > through sysctlt will be verry much appreciated. > uh: struct buf_entry { 4 unsgined int id; 8 u_int64_t tsc; 8 u_int64_t pmec1; 8 u_int64_t pmec2; } mybuffer[NUMENTRIES]; 28 * 1,000,000 = 28Megs That's quite a bit of space to wire down in your kernel, especially for a 64meg box. I would get more ram. You can also read on how to enable a kernel debugger and get us a meaningful traceback in order to possibly fix the problem. -Alfred > Thanks, > > -- > ======================================================================== > 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC > 0 0 0 e-mail: oscar@ac.upc.es | Modul D6, despatx 116 > 0 0 0 phone: +34 93 401 7187 | Jordi Girona, 1-3 > U P C fax: +34 93 401 7055 | 08034 Barcelona - SPAIN > WWW: http://www.ac.upc.es/homes/oscar/ > ======================================================================== > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 3:24:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 3525A37B424 for ; Mon, 16 Apr 2001 03:24:20 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f3GAO7Z34787 ; Mon, 16 Apr 2001 19:24:08 +0900 (JST) Message-Id: <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp> Date: Mon, 16 Apr 2001 19:24:07 +0900 From: Seigo Tanimura To: bright@wintelcom.net Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, phk@critter.freebsd.dk, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG, tanimura@r.dl.itc.u-tokyo.ac.jp Subject: Re: vm balance In-Reply-To: In your message of "Fri, 13 Apr 2001 20:08:57 +0900" <200104131108.f3DB8vZ49897@rina.r.dl.itc.u-tokyo.ac.jp> References: <200104121757.f3CHvJd20639@earth.backplane.com> <59188.987108650@critter> <200104130939.f3D9d7Z37169@rina.r.dl.itc.u-tokyo.ac.jp> <20010413025806.A976@fw.wintelcom.net> <200104131108.f3DB8vZ49897@rina.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 13 Apr 2001 20:08:57 +0900, Seigo Tanimura said: Alfred> Are these changes planned for integration? Seigo> Yes, but not very soon as there are a few kinds of works that should Seigo> be done. Seigo> One is that a directory vnode may be held as the working directory of Seigo> a process, in which case we should not reclaim the directory vnode. Seigo> Another is to determine how often namecache should be traversed to Seigo> reclaim how many directory vnodes. At this moment, namecache is (snip) Those pieces of work were done in the last weekend, and the patch at Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff has been updated and now ready to commit. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 3:29:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0C9E337B42C for ; Mon, 16 Apr 2001 03:29:28 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3GAT7h28470; Mon, 16 Apr 2001 03:29:07 -0700 (PDT) Date: Mon, 16 Apr 2001 03:29:07 -0700 From: Alfred Perlstein To: Seigo Tanimura Cc: phk@critter.freebsd.dk, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance Message-ID: <20010416032907.J976@fw.wintelcom.net> References: <200104121757.f3CHvJd20639@earth.backplane.com> <59188.987108650@critter> <200104130939.f3D9d7Z37169@rina.r.dl.itc.u-tokyo.ac.jp> <20010413025806.A976@fw.wintelcom.net> <200104131108.f3DB8vZ49897@rina.r.dl.itc.u-tokyo.ac.jp> <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Mon, Apr 16, 2001 at 07:24:07PM +0900 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Seigo Tanimura [010416 03:25] wrote: > On Fri, 13 Apr 2001 20:08:57 +0900, > Seigo Tanimura said: > > Alfred> Are these changes planned for integration? > > Seigo> Yes, but not very soon as there are a few kinds of works that should > Seigo> be done. > > Seigo> One is that a directory vnode may be held as the working directory of > Seigo> a process, in which case we should not reclaim the directory vnode. > > Seigo> Another is to determine how often namecache should be traversed to > Seigo> reclaim how many directory vnodes. At this moment, namecache is > (snip) > > Those pieces of work were done in the last weekend, and the patch at > > Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff > > has been updated and now ready to commit. Heh, go for it. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 3:32:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (diskworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 487BD37B42C for ; Mon, 16 Apr 2001 03:32:31 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 1950 invoked by uid 1000); 16 Apr 2001 10:31:01 -0000 Date: Mon, 16 Apr 2001 13:31:00 +0300 From: Peter Pentchev To: "Vladimir B. Grebenschikov" Cc: freebsd-hackers@freebsd.org Subject: Re: Idea about modules build Message-ID: <20010416133100.A414@ringworld.oblivion.bg> Mail-Followup-To: "Vladimir B. Grebenschikov" , freebsd-hackers@freebsd.org References: <15064.29187.667341.757712@vbook.express.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15064.29187.667341.757712@vbook.express.ru>; from vova@express.ru on Sat, Apr 14, 2001 at 07:51:31PM +0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 14, 2001 at 07:51:31PM +0400, Vladimir B. Grebenschikov wrote: > > I have idea about modules build/install process: > > May be it need to create some makefile variable like KERNEL_MODULES, > that can be defined in /etc/make.conf to limit list of modules > to build/install, it is not very good idea to spend a lot of > CPU time building modules, that never be used ? This was recently discussed on -arch, and was brought into -current by Warner Losch in rev. 1.172 of src/sys/modules/Makefile from 2001/04/02 08:52:05; if there is a MODULES_OVERRIDE variable (defined either in /etc/make.conf or on the 'make' command line), it overrides the list of modules to build. This variable can - and probably should ;) - contain second-level module names, too - e.g. sound/pcm or syscons/daemon. G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 3:36:32 2001 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 7421537B424 for ; Mon, 16 Apr 2001 03:36:29 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3GAa3U01200; Mon, 16 Apr 2001 12:36:03 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Seigo Tanimura Cc: bright@wintelcom.net, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: Your message of "Mon, 16 Apr 2001 19:24:07 +0900." <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp> Date: Mon, 16 Apr 2001 12:36:03 +0200 Message-ID: <1198.987417363@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp>, Seigo Tanim ura writes: >Those pieces of work were done in the last weekend, and the patch at > >Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff > >has been updated and now ready to commit. I'm a bit worried about the amount of work done in the cache_purgeleafdirs(), considering how often it is called, Do you have measured the performance impact of this to be an insignificant overhead ? Once we have that figured out I will commit the patch for you... -- 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 Mon Apr 16 4: 2:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C8BE637B422 for ; Mon, 16 Apr 2001 04:02:53 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3GB2Yl29248; Mon, 16 Apr 2001 04:02:34 -0700 (PDT) Date: Mon, 16 Apr 2001 04:02:34 -0700 From: Alfred Perlstein To: Seigo Tanimura Cc: phk@critter.freebsd.dk, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance Message-ID: <20010416040234.K976@fw.wintelcom.net> References: <200104121757.f3CHvJd20639@earth.backplane.com> <59188.987108650@critter> <200104130939.f3D9d7Z37169@rina.r.dl.itc.u-tokyo.ac.jp> <20010413025806.A976@fw.wintelcom.net> <200104131108.f3DB8vZ49897@rina.r.dl.itc.u-tokyo.ac.jp> <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Mon, Apr 16, 2001 at 07:24:07PM +0900 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Seigo Tanimura [010416 03:25] wrote: > On Fri, 13 Apr 2001 20:08:57 +0900, > Seigo Tanimura said: > > Alfred> Are these changes planned for integration? > > Seigo> Yes, but not very soon as there are a few kinds of works that should > Seigo> be done. > > Seigo> One is that a directory vnode may be held as the working directory of > Seigo> a process, in which case we should not reclaim the directory vnode. > > Seigo> Another is to determine how often namecache should be traversed to > Seigo> reclaim how many directory vnodes. At this moment, namecache is > (snip) > > Those pieces of work were done in the last weekend, and the patch at > > Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff > > has been updated and now ready to commit. There's actually a few style bugs in here: pointers should be compared against NULL, not 0 using a bit more meaningful variable names would be nice: + struct nchashhead *ncpp; + struct namecache *ncp, *nnp, *ncpc, *nnpc; I'm also wondering why you can't track the number of nodes that ought to be cleaned, well, you do, but it doesn't look like it's used: + numcachehv--; + numcachehv++; then later: + if (vnodeallocs % vnoderecycleperiod == 0 && + freevnodes < vnoderecycleminfreevn && + vnoderecyclemintotalvn < numvnodes) { shouldn't this be related to numcachehv somehow? excuse me if i'm missing something obvious, i'm in desperate need of sleep. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 5:23:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id EE83F37B43C for ; Mon, 16 Apr 2001 05:23:38 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f3GCNZZ51680 ; Mon, 16 Apr 2001 21:23:36 +0900 (JST) Message-Id: <200104161223.f3GCNZZ51680@rina.r.dl.itc.u-tokyo.ac.jp> Date: Mon, 16 Apr 2001 21:23:34 +0900 From: Seigo Tanimura To: phk@critter.freebsd.dk Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, bright@wintelcom.net, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: In your message of "Mon, 16 Apr 2001 12:36:03 +0200" <1198.987417363@critter> References: <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp> <1198.987417363@critter> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Apr 2001 12:36:03 +0200, Poul-Henning Kamp said: Poul-Henning> In message <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp>, Seigo Tanim Poul-Henning> ura writes: >> Those pieces of work were done in the last weekend, and the patch at >> Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff >> >> has been updated and now ready to commit. Poul-Henning> I'm a bit worried about the amount of work done in the Poul-Henning> cache_purgeleafdirs(), considering how often it is called, Poul-Henning> Do you have measured the performance impact of this to be an Poul-Henning> insignificant overhead ? No precise results right now, mainly because I cannot find a benchmark to measure the performance of name lookup going down to a deep directory depth. It has been confirmed, though, that the hit ratio of name lookup is around 96-98% for a box serving cvsup both with and without my patch (observed by systat(1)). Here are the details of the name lookup on that box: Frequency: Around 25,000-35,000 lookups/sec at most, 8,000-10,000 generally. Name vs Directory: 98% or more of the lookups are for names, the rest of them are for directories (up to 1.5% of the whole lookup at most). Hit ratio: 96-98% for names and up to 1% at most for directories (both with and without my patch) Considering that most of lookup operations are for names and its hit ratio is not observed to degrade, and assuming that the time consumed for lookup hit is always constant, the performance of lookup is not found to be deteriorated. For a more precise investigation, we have to measure the actial time taken for a lookup operation, in which case I may have to write a benchmark for it and test in single-user mode. It is interesting that the hit ratio of directory lookup is up to only 1% at most, even without my patch. Why is it like that? -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 5:31:24 2001 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 0BA1237B446 for ; Mon, 16 Apr 2001 05:31:21 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3GCUqU02035; Mon, 16 Apr 2001 14:30:52 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Seigo Tanimura Cc: bright@wintelcom.net, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: Your message of "Mon, 16 Apr 2001 21:23:34 +0900." <200104161223.f3GCNZZ51680@rina.r.dl.itc.u-tokyo.ac.jp> Date: Mon, 16 Apr 2001 14:30:52 +0200 Message-ID: <2033.987424252@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104161223.f3GCNZZ51680@rina.r.dl.itc.u-tokyo.ac.jp>, Seigo Tanim ura writes: >Poul-Henning> I'm a bit worried about the amount of work done in the >Poul-Henning> cache_purgeleafdirs(), considering how often it is called, > >Poul-Henning> Do you have measured the performance impact of this to be an >Poul-Henning> insignificant overhead ? > >No precise results right now, mainly because I cannot find a benchmark >to measure the performance of name lookup going down to a deep >directory depth. Have you done any "trivial" checks, like timing "make world" and such ? >It has been confirmed, though, that the hit ratio of name lookup is >around 96-98% for a box serving cvsup both with and without my patch >(observed by systat(1)). Here are the details of the name lookup on >that box: Ohh, sure, I don't expect this to have a big impact on the hit rate, If I thought it would have I would have protested :-) >For a more precise investigation, we have to measure the actial time >taken for a lookup operation, in which case I may have to write a >benchmark for it and test in single-user mode. I would be satisfied with a "sanity-check", for instance running a "cvs co src ; cd src ; make buildworld ; cd release ; make release" with and without, just to see that it doesn't have a significant negative impact. >It is interesting that the hit ratio of directory lookup is up to only >1% at most, even without my patch. Why is it like that? Uhm, which cache is this ? The one reported in "vmstat -vm" ? That is entirely different from the vfs-namecache, I think it is a per process one-slot directory cache. I have never studied it's performance, but I belive a good case was made for it in the 4.[34] BSD books. -- 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 Mon Apr 16 6:42: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from lisa.darkworld.prv (pD9505AB1.dip.t-dialin.net [217.80.90.177]) by hub.freebsd.org (Postfix) with ESMTP id 847EC37B440 for ; Mon, 16 Apr 2001 06:41:59 -0700 (PDT) (envelope-from d_f0rce@gmx.de) Received: from blade (blade.darkworld.prv [10.10.10.2]) by lisa.darkworld.prv (8.11.1/8.11.0) with SMTP id f3GDfxn00667 for ; Mon, 16 Apr 2001 15:42:01 +0200 (CEST) (envelope-from d_f0rce@gmx.de) From: "Alex" To: Subject: Is it ok to compile a device driver as a module though no load_function is declared in DRIVER_MODULE()? Date: Mon, 16 Apr 2001 15:42:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, i've got a little question about device drivers for FreeBSD. I'm testing my device driver by compiling it as a module and kldloading it. But as I don't want to use it as a module in the future I declared DRIVER_MODULE(..) as follows: DRIVER_MODULE( ir, isa, ir_isa_driver, ir_devclass, 0, 0); As I read on deamonnews that one has to declare a load_function to use a driver as a KLD I'm not sure if the above DRIVER_MODULE() is valid for testing. I can see that my identify and probe functions are called but I'm not sure if this can cause troubles if I don't declare a load_function but let the system get the device by identifying and probing it. Can it? If yes, how can I get "dev" to get my softc structure with device_get_softc(dev) within a load function. Sorry for my bad english. Please answer directly to me as I'm not on the list. Greetings, Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 7:43:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 2E2C337B42C; Mon, 16 Apr 2001 07:43:43 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=40ea636f26e1a62d5676ac26bcc488be) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14pAE6-0000Vw-00; Mon, 16 Apr 2001 08:43:38 -0600 Message-ID: <3ADB051A.17674A2F@softweyr.com> Date: Mon, 16 Apr 2001 08:43:38 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-chat@freebsd.org Cc: hackers@freebsd.org Subject: Re: Interesting article. References: <200104160617.CAA22321@repulse.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bakul Shah wrote: > > > > Though, a lack of good Unicode support on FreeBSD seems like > > > a legitimate enough reason for the move. > > > > Yes, it would, if it were true, see /usr/ports/devel/libunicode. > > One port does not make good support. For that FreeBDS has to > have native unicode support. Why? All they're interested in is having unicode in their web-based app. > > In order to determine if they really made any savings or not -- I > > notice that they've increased the number of servers at Hotmail from > > 3,400 to 5,000 - you'd also have to determine how much they could have > > improved the performance by merely writing their code as an Apache > > module. > > If as they claim they doubled the performance, they saved a > few mil in not having to use 10,000 servers. My point was > they didn't save *as much money as* they could've, had they > used various performance increasing tricks we are well aware > of. We're definitely in agreement on that. They did not start this project to save money, though they claim that as a motivation. It would have (most likely) been far less expensive to make a few performance enhancements to Apache itself, or to the interface they use for their application code. Of course, that would not have been a testimonial for Win2K or IIS. > > So, was that 18 month development project really necessary from a > > technical standpoint, or only justified as a marketing cost? Nobody > > outside Microsoft management will ever really know. > > Suspect the most likely cause of conversion can be summed up > in the phrase `eating your own dogfood'. Which is fine, but it's disingenous to declare it a 'cost-saving measure' when it was obviously very expensive. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 8:37:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by hub.freebsd.org (Postfix) with SMTP id 038D137B632 for ; Mon, 16 Apr 2001 08:37:19 -0700 (PDT) (envelope-from fasi_74@yahoo.com) Received: from unknown (HELO client2) (202.87.102.168) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Apr 2001 15:37:17 -0000 X-Apparently-From: Message-ID: <003801c0c6f0$157d2e70$a86657ca@client2> From: "faisal" To: , "Andrew Hesford" , "Will Mitayai Keeso Rowe" Cc: "FreeBSD" , Subject: Re: freebsd in dos extended ? Date: Mon, 16 Apr 2001 16:29:19 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have exceded my partitions limit & cannot delete my extended windoze is on it .. it seems that i am out of luck .... no problem i think its time to buy a new harddrive .... :-) i wish they didnt have this limit of 4 primary partition on a disk ... :-( ----- Original Message ----- From: "Mike Makonnen" To: "faisal" ; "Andrew Hesford" ; "Will Mitayai Keeso Rowe" Cc: "FreeBSD" ; Sent: Monday, April 16, 2001 12:51 AM Subject: Re: freebsd in dos extended ? > > > Why do you want to install it on a DOS extended partition? > Just remove that extended patition and install FreeBSD in the unused > portion > of the disk. Install the FreeBSD boot manager so you can boot into > whichever OS you want to. > > Mike. > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 9:50:40 2001 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 0529637B440 for ; Mon, 16 Apr 2001 09:50:37 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3GGo4U04081; Mon, 16 Apr 2001 18:50:04 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Seigo Tanimura Cc: bright@wintelcom.net, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: Your message of "Mon, 16 Apr 2001 19:24:07 +0900." <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp> Date: Mon, 16 Apr 2001 18:50:04 +0200 Message-ID: <4079.987439804@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp>, Seigo Tanim ura writes: >Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff > >has been updated and now ready to commit. Ok, I ran a "cvs update ; make buildworld" here with and without your patch. without: 2049.846u 1077.358s 41:29.65 125.6% 594+714k 121161+5608io 7725pf+331w with: 2053.464u 1075.493s 41:29.50 125.6% 595+715k 123125+5682io 8897pf+446w Difference: + .17% -.18% ~0% 0% +.17% +.14% +1.6% +1.3% +15% +35% I think that means we're inside epsilon for the normal case, so I'll commit your patch later tonight. -- 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 Mon Apr 16 13:36:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from CPE-61-9-164-106.vic.bigpond.net.au (CPE-61-9-138-241.vic.bigpond.net.au [61.9.138.241]) by hub.freebsd.org (Postfix) with ESMTP id B261837B43E for ; Mon, 16 Apr 2001 13:36:45 -0700 (PDT) (envelope-from darrenr@reed.wattle.id.au) Received: (from root@localhost) by CPE-61-9-164-106.vic.bigpond.net.au (8.11.0/8.11.0) id f3GKaiB04723 for ; Tue, 17 Apr 2001 06:36:44 +1000 (EST) From: Darren Reed Message-Id: <200104162036.GAA25344@avalon.reed.wattle.id.au> Subject: User-defined bit in sysctl flags ? To: hackers@freebsd.org Date: Tue, 17 Apr 2001 06:36:21 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What do people think about having a range of bits in oid_kind that are not used by FreeBSD but are only to be used by ``private'' sysctl handlers? e.g. #define CTLFLAG_PRIVATE 0x000ffff0 Do I need elaborate any further ? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 15:10:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id EA77137B424 for ; Mon, 16 Apr 2001 15:10:08 -0700 (PDT) (envelope-from crossd@antares.cs.rpi.edu) Received: from antares.cs.rpi.edu (antares.cs.rpi.edu [128.213.12.33]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id SAA25716 for ; Mon, 16 Apr 2001 18:10:07 -0400 (EDT) Message-Id: <200104162210.SAA25716@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: still more ypserv woes Date: Mon, 16 Apr 2001 18:10:07 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok... I am coming to the conclusion that there is some sort of kernel issue that is causing this problem. Here is what I have done and discovered to date (this is all with 4.3-RC2 FWIW): At some point the 'qhead' CIRCLEQ structure in yp_dblookup.c gets corrupted. This is declared as a static, and no handles are passed back out of the function, so aside from data-segment smashing, all accesses to that structure _must_ happen within yp_dblookup.c. To date, _almost_ every single segfault has been in the for loop of yp_testflags (this is a bit odd in and of itself given that the CIRCLEQ is being mangled) ( I do not recall the exact situation for the one not in yp_testflags. ), so I wrote a function called 'queue_verify()' whose only lob is to travel once down the CIRCLEQ, assert the number of entries in the CIRCLEQ is the same as numdbs and exit. I placed this function after every Berkeley DB function call and other random points in the function calls in "yp_dblookup.c". Right now I am only seeing seg-faults in the queue_verify() that I placed before the for loop in yp_testflags *very* strange, one would think with the number I have placed everywhere that it would get tripped up somewhere else too). I also notice that it always dies very shortly after it fork()s a child to handle a YP_ALL request (one of the things the child does is the delete its copy of the CIRCLEQ). Is it possible that a copy-on-write is somehow getting mangled and causing this? FWIW: this system is a single CPU PentiumPro acting as a firewall/gateway with 1 FXP, 2 dc, and 2 xl interfaces (the fxp and one each of the dc and xl are active). Any ideas? Any clue where to look next, I am running out ideas here. -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 17: 1:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from one.net (ip-216-23-120-82.adsl.one.net [216.23.120.82]) by hub.freebsd.org (Postfix) with ESMTP id 6A8B737B43E for ; Mon, 16 Apr 2001 17:01:43 -0700 (PDT) (envelope-from cokane@one.net) Received: (from cokane@localhost) by one.net (8.11.3/8.11.3) id f3H0GDv01939; Mon, 16 Apr 2001 20:16:13 -0400 (EDT) (envelope-from cokane) Date: Mon, 16 Apr 2001 20:16:13 -0400 From: Coleman Kane To: Peter Pentchev Cc: "Vladimir B. Grebenschikov" , freebsd-hackers@freebsd.org Subject: Re: Idea about modules build Message-ID: <20010416201613.B1843@cokane.yi.org> References: <15064.29187.667341.757712@vbook.express.ru> <20010416133100.A414@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="H8ygTp4AXg6deix2" X-Mailer: Mutt 1.0.1i In-Reply-To: <20010416133100.A414@ringworld.oblivion.bg>; from roam@orbitel.bg on Mon, Apr 16, 2001 at 01:31:00PM +0300 X-Vim: vim:tw=70:ts=4:sw=4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --H8ygTp4AXg6deix2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable It would also be nice to be able to update third-party modules (like those = in ports, x11, etc...) after a kernel recompile. Perhaps some way of setting t= hese up into /usr/local? Peter Pentchev had the audacity to say: >=20 > On Sat, Apr 14, 2001 at 07:51:31PM +0400, Vladimir B. Grebenschikov wrote: > >=20 > > I have idea about modules build/install process: > >=20 > > May be it need to create some makefile variable like KERNEL_MODULES, > > that can be defined in /etc/make.conf to limit list of modules > > to build/install, it is not very good idea to spend a lot of > > CPU time building modules, that never be used ? >=20 > This was recently discussed on -arch, and was brought into -current > by Warner Losch in rev. 1.172 of src/sys/modules/Makefi= le > from 2001/04/02 08:52:05; if there is a MODULES_OVERRIDE variable (defined > either in /etc/make.conf or on the 'make' command line), it overrides > the list of modules to build. This variable can - and probably should ;)= - > contain second-level module names, too - e.g. sound/pcm or syscons/daemon. >=20 > G'luck, > Peter >=20 > --=20 > This sentence would be seven words long if it were six words shorter. >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 --H8ygTp4AXg6deix2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE624tMERViMObJ880RAZsbAJ9e9gMM7/NyJQ6VEwXh8BAvpgLJKACfbefi B/dXCbCl08ylala8cjA3YAA= =+pRK -----END PGP SIGNATURE----- --H8ygTp4AXg6deix2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 17: 6:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 4A70037B423 for ; Mon, 16 Apr 2001 17:06:30 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (bill.cs.rpi.edu [128.213.2.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id UAA29563 for ; Mon, 16 Apr 2001 20:06:29 -0400 (EDT) Message-Id: <200104170006.UAA29563@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: ypserv: a resolution (i think) Date: Mon, 16 Apr 2001 20:06:29 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After some more intensive debugging, and a leap of faith, I _think_ I have the problem licked, but I would appreciate some more brains to examine the logic. The original cause of ypserv's problems was the sharing of DBPs between the parent and child. The resolution to this was to close all of them, in the child. This appears to be where the problem lies, it was assumed to be safe to call the dbclose in the child... apparently dbclose does some stuff that is still dangerous. So, my solution is to move the close routine _before_ the fork (so far *crossed fingers* this is working). However, since yp_all is called fairly frequently, this is bad(TM) for the parent. My second solution was to have the child call yp_init_dbs() instead of yp_flush_all() (the former would just nuke the references to the FDs, but actually keep them open). This didn't work. Can anyone provide any clues as to why? Does the DB library keep its own cache, and unless they are "really" closed it will just loop back to the open ones anyway? The current solution is suboptimal since for many cases it removes the DBCACHE entirely, but I don't know what other solution exists. I know some others who use ypserv heavily have run into these problems, if you need the patch, I can provide it if you are willing to give it a test ;) JKH: I think this _really_ needs to get into 4.3-RELEASE, this has been a vexing bug for over a year. The current solution may be sub-optimal, but it is more optimal than: pid 75351 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75364 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75365 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75370 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75377 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75379 (ypserv), uid 0: exited on signal 11 (core dumped) pid 75215 (ypserv), uid 0: exited on signal 11 (core dumped) ;) -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 18: 8:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A30AC37B43E for ; Mon, 16 Apr 2001 18:08:27 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3H189a22460; Mon, 16 Apr 2001 18:08:09 -0700 (PDT) Date: Mon, 16 Apr 2001 18:08:09 -0700 From: Alfred Perlstein To: Darren Reed Cc: hackers@FreeBSD.ORG Subject: Re: User-defined bit in sysctl flags ? Message-ID: <20010416180809.N976@fw.wintelcom.net> References: <200104162036.GAA25344@avalon.reed.wattle.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104162036.GAA25344@avalon.reed.wattle.id.au>; from darrenr@reed.wattle.id.au on Tue, Apr 17, 2001 at 06:36:21AM +1000 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Darren Reed [010416 13:37] wrote: > > What do people think about having a range of bits in oid_kind that are > not used by FreeBSD but are only to be used by ``private'' sysctl handlers? > > e.g. > > #define CTLFLAG_PRIVATE 0x000ffff0 > > Do I need elaborate any further ? I think a half-paragraph explaining what this does would help. :) I'm assuming this allows someone to have thier own private numbered mib in the sysctl tree, my question is why are you using hardcoded numbers rather than names? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 21:55:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from winston.osd.bsdi.com (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 18C8D37B43C for ; Mon, 16 Apr 2001 21:55:32 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f3H4tQM32265; Mon, 16 Apr 2001 21:55:26 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) To: crossd@cs.rpi.edu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ypserv: a resolution (i think) In-Reply-To: <200104170006.UAA29563@cs.rpi.edu> References: <200104170006.UAA29563@cs.rpi.edu> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010416215526O.jkh@osd.bsdi.com> Date: Mon, 16 Apr 2001 21:55:26 -0700 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm open to the idea of fixing it, but I wouldn't mind just another day or two of testing first, hopefully with other folks involved. I didn't see a diff attached? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 22:47:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from arutam.inch.com (ns.inch.com [216.223.192.21]) by hub.freebsd.org (Postfix) with ESMTP id 3FB2A37B43C for ; Mon, 16 Apr 2001 22:47:17 -0700 (PDT) (envelope-from spork@inch.com) Received: from inch.com (inch.com [216.223.192.20]) by arutam.inch.com (8.9.3/8.9.3/UTIL-INCH-2.2.0) with ESMTP id BAA22792 for ; Tue, 17 Apr 2001 01:47:11 -0400 (EDT) Date: Tue, 17 Apr 2001 01:47:11 -0400 (EDT) From: Charles Sprickman To: Subject: Shoutcast, high cpu, threads Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm running shoutcast on a 4.2R machine, and I'm finding that the shoutcast server, when idle climbs up to around 90% cpu usage. Included is a bit of back-and-forth with a shoutcast support person. I'm not too clear on what he's talking about, is there any information I can pass on to him to help debug this? While I will take his suggestion on increasing the sleep time, I don't want to push it too far or I may end up with a "stuttering" server. Thanks, Charles ---------- Forwarded message ---------- Date: Mon, 16 Apr 2001 10:27:33 -0700 From: Tom Pepper To: Charles Sprickman Subject: Re: high cpu usage keep going up. your machine is fast enough that values as high as 10,000 may show improvement. you're seeing this problem because freebsd is the only o/s i know of that ignores sleep values with very small microsecond values. it seems to be aggravated by the amount of different pc hardware available, which is why the config option for sleep is definable. -t At 07:45 PM 4/14/2001 -0400, you wrote: >How far can I go? The conf file says the recommended max is 1,024 and >that setting it too high might cause skipping... > >Here's the result with 0 listeners and the sleep timer set to 999: > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND >25292 scserv 55 0 46860K 46340K RUN 1:09 93.58% 91.16% sc_serv > >The cpu usage goes down as more people connect. Odd. > >In the forums, there is a post about this, and the guy fixed it by using >the freebsd 3.x version. Perhaps I'll try that? Or even the Linux >version under emulation? > >It just seems odd that it should chew up all that processor (this is an >otherwise idle PIII-800) doing nothing... > >Thanks, > >Charles > >| Charles Sprickman | Internet Channel >| INCH System Administration Team | (212)243-5200 >| spork@inch.com | access@inch.com > >On Sat, 14 Apr 2001, Tom Pepper wrote: > > > try increasing the sleep= value in the .conf file and let me know at > > what point it seems to work for you. > > > > -t > > > > On Friday, April 13, 2001, at 11:31 PM, Charles Sprickman wrote: > > > > > Hi, > > > > > > We're checking this out on FreeBSD 4.2, and it seems to work OK, even as > > > it chews up CPU. > > > > > > Currently, the server is idle, web interface still responding, etc: > > > > > > last pid: 19214; load averages: 1.04, 1.05, 1.01 up 50+12:28:15 > > > 02:27:23 > > > 25 processes: 2 running, 23 sleeping > > > CPU states: 41.2% user, 0.0% nice, 57.2% system, 0.0% interrupt, 1.6% > > > idle > > > Mem: 411M Active, 151M Inact, 90M Wired, 44K Cache, 112M Buf, 353M Free > > > Swap: 1024M Total, 1024M Free > > > > > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > > > 16822 scserv 53 0 6660K 6108K RUN 463:43 96.19% 96.19% sc_serv > > > 43230 mysql 2 0 415M 400M poll 581:21 0.00% 0.00% mysqld > > > > > > Any idea why the high cpu usage? We've been playing with RealServer and > > > outsourced WMA crap, and now we're trying shoutcast. Other than this, > > > it > > > looks good. > > > > > > Let me know if there's any information you'd like. > > > > > > Thanks, > > > > > > Charles > > > > > > | Charles Sprickman | Internet Channel > > > | INCH System Administration Team | (212)243-5200 > > > | spork@inch.com | access@inch.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 23: 2:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 7D9B637B424 for ; Mon, 16 Apr 2001 23:02:41 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id XAA55944; Mon, 16 Apr 2001 23:02:19 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200104170602.XAA55944@beastie.mckusick.com> To: Julian Elischer Subject: Re: vm balance Cc: Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu In-Reply-To: Your message of "Tue, 10 Apr 2001 22:14:28 PDT." <3AD3E834.AFB6C5BA@elischer.org> Date: Mon, 16 Apr 2001 23:02:19 -0700 From: Kirk McKusick Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Tue, 10 Apr 2001 22:14:28 -0700 From: Julian Elischer To: Rik van Riel CC: Matt Dillon , David Xu , freebsd-hackers@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: vm balance Rik van Riel wrote: > > I'm curious about the other things though ... FreeBSD still seems > to have the early 90's abstraction layer from Mach and the vnode > cache doesn't seem to grow and shrink dynamically (which can be a > big win for systems with lots of metadata activity). > > So while it's true that FreeBSD's VM balancing seems to be the > best one out there, I'm not quite sure about the rest of the VM... > Many years ago Kirk was talking about merging the vm objects and the vnodes.. (they tend to come in pairs anyhow) I still think it might be an idea worth investigating further. kirk? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v I am still of the opinion that merging VM objects and vnodes would be a good idea. Although it would touch a huge number of lines of code, when the dust settled, it would simplify some nasty bits of the system. This merger is really independent of making the number of vnodes dynamic. Under the old name cache implementation, decreasing the number of vnodes was slow and hard. With the current name cache implementation, decreasing the number of vnodes would be easy. I concur that adding a dynamically sized vnode cache would help performance on some workloads. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 23:31: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 240E437B423 for ; Mon, 16 Apr 2001 23:30:59 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f3H6UqZ76132 ; Tue, 17 Apr 2001 15:30:53 +0900 (JST) Message-Id: <200104170630.f3H6UqZ76132@rina.r.dl.itc.u-tokyo.ac.jp> Date: Tue, 17 Apr 2001 15:30:52 +0900 From: Seigo Tanimura To: bright@wintelcom.net Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, phk@critter.freebsd.dk, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: In your message of "Mon, 16 Apr 2001 04:02:34 -0700" <20010416040234.K976@fw.wintelcom.net> References: <200104121757.f3CHvJd20639@earth.backplane.com> <59188.987108650@critter> <200104130939.f3D9d7Z37169@rina.r.dl.itc.u-tokyo.ac.jp> <20010413025806.A976@fw.wintelcom.net> <200104131108.f3DB8vZ49897@rina.r.dl.itc.u-tokyo.ac.jp> <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp> <20010416040234.K976@fw.wintelcom.net> Cc: Seigo Tanimura User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Apr 2001 04:02:34 -0700, Alfred Perlstein said: Alfred> I'm also wondering why you can't track the number of Alfred> nodes that ought to be cleaned, well, you do, but it doesn't Alfred> look like it's used: Alfred> + numcachehv--; Alfred> + numcachehv++; Alfred> then later: Alfred> + if (vnodeallocs % vnoderecycleperiod == 0 && Alfred> + freevnodes < vnoderecycleminfreevn && Alfred> + vnoderecyclemintotalvn < numvnodes) { Alfred> shouldn't this be related to numcachehv somehow? One reason is that the number of directory vnodes attempted to reclaim should be greater than vnoderecycleperiod, the period of reclaim in getnewvnodes() calls. Otherwise, all of the vnodes reclaimed in the last attempt might be eaten up by the next attempt. This fact calls for an constraint of vnoderecyclenumber >= vnoderecycleperiod, but it is not checked yet. The other one is that not all of the directory vnodes in namecache can be reclaimed because some of them may be held as the working directory of a process. Since a directory vnode in namecache can become or no longer be a working directory without entering or purging namecache, it is rather hard to track the number of the reclaimable directory vnodes in namecache by simple watching cache_enter() and cache_purge(). While the number of reclaimable directory vnodes can be counted by traversing the whole namecache entries, we again have to traverse the namecache entries in order to actually reclaim vnodes, so this method is not an option to predetermine the number of directory vnodes attempted to reclaim. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 23:38:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id A6B1A37B424 for ; Mon, 16 Apr 2001 23:38:55 -0700 (PDT) (envelope-from fmela0@sm.socccd.cc.ca.us) Received: from sm.socccd.cc.ca.us (pool0928.cvx14-bradley.dialup.earthlink.net [209.179.41.163]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA25064; Mon, 16 Apr 2001 23:38:53 -0700 (PDT) Message-ID: <3ADBE569.C0BC5724@sm.socccd.cc.ca.us> Date: Mon, 16 Apr 2001 23:40:41 -0700 From: Farooq Mela X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Doug White , freebsd-hackers@FreeBSD.ORG Subject: Re: lockf in apache References: <20010410131254.V15938@fw.wintelcom.net> <20010411161858.T15938@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > We haven't applied wakeup_one() to select() yet? (I think I've argued > > about this before.) > > > > Someone get cracking! :) > > I'm not sure it's possible without redesigning the way select works. > Perhaps its not possible, as I'm not very familiar with the way kqueue works, but would it be possible to rewrite select() to use the kqueue() mechanism underneath, and thus avoid this situation? Or am I missing something? -- farooq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 16 23:44:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 43FDF37B424 for ; Mon, 16 Apr 2001 23:44:10 -0700 (PDT) (envelope-from danny@cs.huji.ac.il) Received: from sexta.cs.huji.ac.il ([132.65.16.13] ident=exim) by cs.huji.ac.il with esmtp (Exim 3.22 #1) id 14pPDc-0006O8-00 for freebsd-hackers@freebsd.org; Tue, 17 Apr 2001 09:44:08 +0300 Received: from localhost ([127.0.0.1] helo=sexta.cs.huji.ac.il ident=danny) by sexta.cs.huji.ac.il with esmtp (Exim 3.15 #1) id 14pPDb-0000wE-00 for freebsd-hackers@FreeBSD.ORG; Tue, 17 Apr 2001 09:44:07 +0300 X-Mailer: exmh version 2.2 06/23/2000 with nmh-0.24 To: freebsd-hackers@FreeBSD.ORG Subject: 4.3-RC3/SMP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 09:44:07 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, at the begining of the 4.3 beta->rc->... i was having problems when doing a make -j4 buildworld, now with the latest, it's doing ok, but i think there is a slowdown: plain make: 1607.475u 674.053s 46:42.23 81.4% 1266+1445k 28160+305923io 1470pf+0w 1556.391u 575.160s 46:28.44 76.4% 1294+1445k 26065+173066io 1468pf+0w make -j4: 1602.193u 666.496s 45:52.42 82.4% 1268+1441k 8614+305942io 659pf+0w comments? danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 0:40:14 2001 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 6D61637B43E for ; Tue, 17 Apr 2001 00:40:11 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3H7dpU18023; Tue, 17 Apr 2001 09:39:51 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Kirk McKusick Cc: Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: Your message of "Mon, 16 Apr 2001 23:02:19 PDT." <200104170602.XAA55944@beastie.mckusick.com> Date: Tue, 17 Apr 2001 09:39:50 +0200 Message-ID: <18021.987493190@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104170602.XAA55944@beastie.mckusick.com>, Kirk McKusick writes: >I am still of the opinion that merging VM objects and vnodes would >be a good idea. Although it would touch a huge number of lines of >code, when the dust settled, it would simplify some nasty bits of >the system. When I first heard you say this I thought you were off your rockers, but gradually I have come to think that you may be right. I think the task will be easier if we get the vnode/buf relationship untangled a bit first. I may also pay off to take vnodes out of diskoperations entirely before we try the merge. >Under the old name cache implementation, decreasing >the number of vnodes was slow and hard. With the current name cache >implementation, decreasing the number of vnodes would be easy. Actually the main problem is that NFS relies on vnodes never being freed to hold "soft references" using "struct vnode * + v_id). -- 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 Apr 17 1:33:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 962A837B43E for ; Tue, 17 Apr 2001 01:33:50 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [63.198.170.139]) by bazooka.unixfreak.org (Postfix) with ESMTP id 5989F3E2F for ; Tue, 17 Apr 2001 01:33:50 -0700 (PDT) To: hackers@freebsd.org Subject: Patch to make snp(4) devfs-friendly Date: Tue, 17 Apr 2001 01:33:50 -0700 From: Dima Dorfman Message-Id: <20010417083350.5989F3E2F@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Attached is a patch to make the snp(4) driver play ball with DEVFS. For better or for worse, I used the bpf(4) driver as a guide on how to do this. If someone could review this, and, if nothing is wrong with it, commit it, I'd appreciate it. Thanks in advance, Dima Dorfman dima@unixfreak.org Index: tty_snoop.c =================================================================== RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v retrieving revision 1.52 diff -u -r1.52 tty_snoop.c --- tty_snoop.c 2001/03/26 12:41:01 1.52 +++ tty_snoop.c 2001/04/17 08:17:23 @@ -286,12 +286,9 @@ if ((error = suser(p)) != 0) return (error); - if (dev->si_drv1 == NULL) { - int mynor = minor(dev); - + if (dev->si_drv1 == NULL) dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO); - make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor); - } else + else return (EBUSY); /* @@ -365,6 +362,7 @@ free(snp->snp_buf, M_SNP); snp->snp_flags &= ~SNOOP_OPEN; dev->si_drv1 = NULL; + destroy_dev(dev); return (snp_detach(snp)); } @@ -505,10 +503,25 @@ static void snp_drvinit __P((void *unused)); static void +snp_clone(void *arg, char *name, int namelen, dev_t *dev) +{ + int u; + + if (*dev != NODEV) + return; + if (dev_stdclone(name, NULL, "snp", &u) != 1) + return; + *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600, + "snp%d", u); + return; +} + +static void snp_drvinit(unused) void *unused; { + EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000); cdevsw_add(&snp_cdevsw); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 2: 5:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 3EF1037B424 for ; Tue, 17 Apr 2001 02:05:39 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f3H96Eb49816; Tue, 17 Apr 2001 10:06:14 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f3H95lr61736; Tue, 17 Apr 2001 10:05:47 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200104170905.f3H95lr61736@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Dima Dorfman Cc: hackers@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Patch to make snp(4) devfs-friendly In-Reply-To: Message from Dima Dorfman of "Tue, 17 Apr 2001 01:33:50 PDT." <20010417083350.5989F3E2F@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 10:05:47 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I haven't actually tested the code, but looking at the patch, I think there's a problem with it... Specifically, on a non-devfs system - where the device nodes are created with mknod(1), snp_clone() isn't going to be called before snpopen(). I've (ab)used drv2 as a flag to say whether make_dev() has been called in net/if_tun.c, but I'm not sure if this is the right answer either :*] > Attached is a patch to make the snp(4) driver play ball with DEVFS. > For better or for worse, I used the bpf(4) driver as a guide on how to > do this. > > If someone could review this, and, if nothing is wrong with it, commit > it, I'd appreciate it. > > Thanks in advance, > > Dima Dorfman > dima@unixfreak.org > > Index: tty_snoop.c > =================================================================== > RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v > retrieving revision 1.52 > diff -u -r1.52 tty_snoop.c > --- tty_snoop.c 2001/03/26 12:41:01 1.52 > +++ tty_snoop.c 2001/04/17 08:17:23 > @@ -286,12 +286,9 @@ > if ((error = suser(p)) != 0) > return (error); > > - if (dev->si_drv1 == NULL) { > - int mynor = minor(dev); > - > + if (dev->si_drv1 == NULL) > dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO); > - make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor); > - } else > + else > return (EBUSY); > > /* > @@ -365,6 +362,7 @@ > free(snp->snp_buf, M_SNP); > snp->snp_flags &= ~SNOOP_OPEN; > dev->si_drv1 = NULL; > + destroy_dev(dev); > > return (snp_detach(snp)); > } > @@ -505,10 +503,25 @@ > static void snp_drvinit __P((void *unused)); > > static void > +snp_clone(void *arg, char *name, int namelen, dev_t *dev) > +{ > + int u; > + > + if (*dev != NODEV) > + return; > + if (dev_stdclone(name, NULL, "snp", &u) != 1) > + return; > + *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600, > + "snp%d", u); > + return; > +} > + > +static void > snp_drvinit(unused) > void *unused; > { > > + EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000); > cdevsw_add(&snp_cdevsw); > } > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 2:22:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id ED09A37B43E for ; Tue, 17 Apr 2001 02:22:26 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 9AC973E09; Tue, 17 Apr 2001 02:22:23 -0700 (PDT) To: Brian Somers Cc: hackers@FreeBSD.ORG Subject: Re: Patch to make snp(4) devfs-friendly In-Reply-To: <200104170905.f3H95lr61736@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on "Tue, 17 Apr 2001 10:05:47 +0100" Date: Tue, 17 Apr 2001 02:22:23 -0700 From: Dima Dorfman Message-Id: <20010417092223.9AC973E09@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers writes: > I haven't actually tested the code, but looking at the patch, I think > there's a problem with it... > > Specifically, on a non-devfs system - where the device nodes are > created with mknod(1), snp_clone() isn't going to be called before > snpopen(). > > I've (ab)used drv2 as a flag to say whether make_dev() has been > called in net/if_tun.c, but I'm not sure if this is the right answer > either :*] I think the correct approach is to check for !(si_flags & SI_NAMED) as done in rev. 1.68 of sys/net/bpf.c (that rev. has a precedence bug, which has since been fixed). That was written by phk, who I take to be pretty authoritative on the subject; looking at the places SI_NAMED is used also supports this conclusion. A corrected patch is attached (although I didn't test it in the non-devfs case). Thanks! Dima Dorfman dima@unixfreak.org Index: tty_snoop.c =================================================================== RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v retrieving revision 1.52 diff -u -r1.52 tty_snoop.c --- tty_snoop.c 2001/03/26 12:41:01 1.52 +++ tty_snoop.c 2001/04/17 09:16:52 @@ -287,10 +287,10 @@ return (error); if (dev->si_drv1 == NULL) { - int mynor = minor(dev); - + if (!(dev->si_flags & SI_NAMED)) + make_dev(&snp_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, + 0600, "snp%d", dev2unit(dev)); dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO); - make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor); } else return (EBUSY); @@ -365,6 +365,7 @@ free(snp->snp_buf, M_SNP); snp->snp_flags &= ~SNOOP_OPEN; dev->si_drv1 = NULL; + destroy_dev(dev); return (snp_detach(snp)); } @@ -505,10 +506,25 @@ static void snp_drvinit __P((void *unused)); static void +snp_clone(void *arg, char *name, int namelen, dev_t *dev) +{ + int u; + + if (*dev != NODEV) + return; + if (dev_stdclone(name, NULL, "snp", &u) != 1) + return; + *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600, + "snp%d", u); + return; +} + +static void snp_drvinit(unused) void *unused; { + EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000); cdevsw_add(&snp_cdevsw); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 2:58:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 875B137B423 for ; Tue, 17 Apr 2001 02:58:31 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f3H9wpb50015; Tue, 17 Apr 2001 10:58:51 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f3H9wOr62584; Tue, 17 Apr 2001 10:58:24 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200104170958.f3H9wOr62584@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Dima Dorfman Cc: Brian Somers , hackers@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Patch to make snp(4) devfs-friendly In-Reply-To: Message from Dima Dorfman of "Tue, 17 Apr 2001 02:22:23 PDT." <20010417092223.9AC973E09@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 10:58:24 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This looks good. I'd say you should commit the change yourself - feel free to say it's reviewed by me. As an aside, when I did this to if_tun, I chose to do all the destroy_dev()s at module unload time (I guess the snp device could do with a MODULE_DECLARE). This allows the administrator to relax the driver-chosen permissions on tun devices with something like kldload if_tun >/dev/tun0 chmod blah /dev/tun0 The destroy_dev() added to snpclose() prevents this. Having said all that, it's unlikely that anyone would want to relax the permissions a snoop device that wasn't already opened, so the destroy_dev() looks ok here in practice. > Brian Somers writes: > > I haven't actually tested the code, but looking at the patch, I think > > there's a problem with it... > > > > Specifically, on a non-devfs system - where the device nodes are > > created with mknod(1), snp_clone() isn't going to be called before > > snpopen(). > > > > I've (ab)used drv2 as a flag to say whether make_dev() has been > > called in net/if_tun.c, but I'm not sure if this is the right answer > > either :*] > > I think the correct approach is to check for !(si_flags & SI_NAMED) as > done in rev. 1.68 of sys/net/bpf.c (that rev. has a precedence bug, > which has since been fixed). That was written by phk, who I take to > be pretty authoritative on the subject; looking at the places SI_NAMED > is used also supports this conclusion. > > A corrected patch is attached (although I didn't test it in the > non-devfs case). > > Thanks! > > Dima Dorfman > dima@unixfreak.org > > > Index: tty_snoop.c > =================================================================== > RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v > retrieving revision 1.52 > diff -u -r1.52 tty_snoop.c > --- tty_snoop.c 2001/03/26 12:41:01 1.52 > +++ tty_snoop.c 2001/04/17 09:16:52 > @@ -287,10 +287,10 @@ > return (error); > > if (dev->si_drv1 == NULL) { > - int mynor = minor(dev); > - > + if (!(dev->si_flags & SI_NAMED)) > + make_dev(&snp_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, > + 0600, "snp%d", dev2unit(dev)); > dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO); > - make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor); > } else > return (EBUSY); > > @@ -365,6 +365,7 @@ > free(snp->snp_buf, M_SNP); > snp->snp_flags &= ~SNOOP_OPEN; > dev->si_drv1 = NULL; > + destroy_dev(dev); > > return (snp_detach(snp)); > } > @@ -505,10 +506,25 @@ > static void snp_drvinit __P((void *unused)); > > static void > +snp_clone(void *arg, char *name, int namelen, dev_t *dev) > +{ > + int u; > + > + if (*dev != NODEV) > + return; > + if (dev_stdclone(name, NULL, "snp", &u) != 1) > + return; > + *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600, > + "snp%d", u); > + return; > +} > + > +static void > snp_drvinit(unused) > void *unused; > { > > + EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000); > cdevsw_add(&snp_cdevsw); > } > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 3:56:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp1.ooe.gv.at (smtp1.ooe.gv.at [194.48.60.10]) by hub.freebsd.org (Postfix) with ESMTP id 6805537B424 for ; Tue, 17 Apr 2001 03:56:45 -0700 (PDT) (envelope-from Egon.Rath@lsr-ooe.gv.at) Received: (from daemon@localhost) by smtp1.ooe.gv.at (8.10.2/8.10.2) id f3HAuau00853 for freebsd-hackers@freebsd.org.stripped; Tue, 17 Apr 2001 12:56:36 +0200 Received: Received: Received: Received: Message-ID: From: Egon.Rath@lsr-ooe.gv.at To: freebsd-hackers@freebsd.org Subject: Problems with German Keyboard Date: Tue, 17 Apr 2001 12:56:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I=B4ve troubles getting german "umlauts" to work properly. I played = around with vidcontrol and kbdcontrol to load different keymaps, fonts and screenmaps but nothing changed. I always get a single beep when i press = a key with an "umlaut". This problem only occurs when i am on the = console. When i connect using ssh or telnet everything works. I am using = 4.2-RELEASE and the SC console driver. Thanks, Egon --=20 Egon Rath, Thanstetten 67, 4521 Schiedlberg, Austria (Info: finger er@purple.altf4.at, ICQ 95692730) In God we Trust -- all others must submit an X.509 certificate. Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 6:20:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.musha.org (daemon.musha.org [61.122.44.178]) by hub.freebsd.org (Postfix) with ESMTP id 0047537B424; Tue, 17 Apr 2001 06:20:49 -0700 (PDT) (envelope-from knu@iDaemons.org) Received: from archon.local.idaemons.org (archon.local.idaemons.org [192.168.1.32]) by mail.musha.org (Postfix) with ESMTP id 069664DF45; Tue, 17 Apr 2001 22:20:49 +0900 (JST) Date: Tue, 17 Apr 2001 22:20:48 +0900 Message-ID: <86elury85r.wl@archon.local.idaemons.org> From: "Akinori MUSHA" To: deischen@FreeBSD.org Cc: hackers@FreeBSD.org Subject: bin/25110 User-Agent: Wanderlust/2.5.4 (Smooth) SEMI/1.14.2 (=?ISO-8859-1?Q?Daish=F2?= =?ISO-8859-1?Q?ji?=) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Associated I. Daemons X-PGP-Public-Key: finger knu@FreeBSD.org X-PGP-Fingerprint: 081D 099C 1705 861D 4B70 B04A 920B EFC7 9FD9 E1EE MIME-Version: 1.0 (generated by SEMI 1.14.2 - =?ISO-8859-1?Q?=22Daish=F2ji=22?=) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Would you take a look at PR#25110 ? Some programs are suffering with a problem that with the threaded library a process cannot receive due signals except SIGKILL and SIGSTOP from its children and thus it stalls at waitpid() after forking. The PR precisely describes the underlying cause and points out how you can examine and solve the problem. I'd appreciate if you or someone else with a clue could deal with it. Regards, -- / /__ __ Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Freeze this moment a little bit longer, make each impression a little bit stronger.. Experience slips away -- Time stand still" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 6:50:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 251CA37B443 for ; Tue, 17 Apr 2001 06:50:08 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3HDnsf84122; Tue, 17 Apr 2001 09:49:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 17 Apr 2001 09:49:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kirk McKusick Cc: Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: <200104170602.XAA55944@beastie.mckusick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Apr 2001, Kirk McKusick wrote: > I am still of the opinion that merging VM objects and vnodes would be a > good idea. Although it would touch a huge number of lines of code, when > the dust settled, it would simplify some nasty bits of the system. This > merger is really independent of making the number of vnodes dynamic. > Under the old name cache implementation, decreasing the number of vnodes > was slow and hard. With the current name cache implementation, > decreasing the number of vnodes would be easy. I concur that adding a > dynamically sized vnode cache would help performance on some workloads. I'm interested in this idea, although profess a gaping blind spot in expertise in the area of the VM system. However, one of the aspects of our VFS that has always concerned me is that use of a single vnode simplelock funnels most of the relevant (and performance-sensitive) calls. The result is that all accesses to an object represented by a vnode are serialized, which can represent a substantial performance hit for applications such as databases, where simultaneous write would be advantageous, or for various vn-backed oddities (possibly including vnode-backed swap?). At some point, apparently an effort was made to mark up vnode_if.src with possible alternative locking using read/write locks, but given that all the consumers use exclusive locks right now, I assume that was not followed through on. A large part of the cost is mitigated through caching on the under-side of VFS, allowing vnode operations to return rapidly, but while this catches a number of common cases (where the file is already in the cache), there are sufficient non-common cases that I would anticipate this being a problem. Are there any performance figures available that either confirm this concern, or demonstrate that in fact it is not relevant? :-) Would this concern introduce additional funneling in the VM system, or is the granularity of locks in the VM sufficiently low that it might improve performance by combining existing broad locks? 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 Tue Apr 17 7:42:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 34FE237B424; Tue, 17 Apr 2001 07:42:23 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt19.pcnet.net [206.105.29.93]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id KAA28054; Tue, 17 Apr 2001 10:41:33 -0400 (EDT) Message-ID: <3ADC5884.F48D58BD@vigrid.com> Date: Tue, 17 Apr 2001 10:51:48 -0400 From: Dan Eischen X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Akinori MUSHA Cc: deischen@FreeBSD.org, hackers@FreeBSD.org Subject: Re: bin/25110 References: <86elury85r.wl@archon.local.idaemons.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Akinori MUSHA wrote: > > Hi, > > Would you take a look at PR#25110 ? Some programs are suffering with > a problem that with the threaded library a process cannot receive due > signals except SIGKILL and SIGSTOP from its children and thus it > stalls at waitpid() after forking. > > The PR precisely describes the underlying cause and points out how you > can examine and solve the problem. > > I'd appreciate if you or someone else with a clue could deal with it. You can try the patch below. I think I've posted this patch before, but I guess I never committed it. -- Dan Eischen Index: uthread/uthread_fork.c =================================================================== RCS file: /opt/b/CVS/src/lib/libc_r/uthread/uthread_fork.c,v retrieving revision 1.23 diff -u -r1.23 uthread_fork.c --- uthread/uthread_fork.c 2001/04/10 04:25:49 1.23 +++ uthread/uthread_fork.c 2001/04/17 14:44:37 @@ -32,6 +32,7 @@ * $FreeBSD: src/lib/libc_r/uthread/uthread_fork.c,v 1.23 2001/04/10 04:25:49 deischen Exp $ */ #include +#include #include #include #include @@ -112,7 +113,16 @@ else if (_pq_init(&_readyq) != 0) { /* Abort this application: */ PANIC("Cannot initialize priority ready queue."); - } else { + } else if ((_thread_sigstack.ss_sp == NULL) && + ((_thread_sigstack.ss_sp = malloc(SIGSTKSZ)) == NULL)) + PANIC("Unable to allocate alternate signal stack"); + else { + /* Install the alternate signal stack: */ + _thread_sigstack.ss_size = SIGSTKSZ; + _thread_sigstack.ss_flags = 0; + if (__sys_sigaltstack(&_thread_sigstack, NULL) != 0) + PANIC("Unable to install alternate signal stack"); + /* * Enter a loop to remove all threads other than * the running thread from the thread list: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 10:12:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7126737B424; Tue, 17 Apr 2001 10:12:19 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HHCIG93862; Tue, 17 Apr 2001 10:12:18 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 10:12:18 -0700 (PDT) From: Matt Dillon Message-Id: <200104171712.f3HHCIG93862@earth.backplane.com> To: Robert Watson Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'm interested in this idea, although profess a gaping blind spot in :expertise in the area of the VM system. However, one of the aspects of :our VFS that has always concerned me is that use of a single vnode :simplelock funnels most of the relevant (and performance-sensitive) calls. :The result is that all accesses to an object represented by a vnode are :serialized, which can represent a substantial performance hit for :applications such as databases, where simultaneous write would be :advantageous, or for various vn-backed oddities (possibly including :vnode-backed swap?). : :At some point, apparently an effort was made to mark up vnode_if.src with :possible alternative locking using read/write locks, but given that all :... We only use simplelocks on vnodes for interlock operations. We use normal kern/kern_lock.c locks for vnode locking and use both shared and exclusive locks. You are absolutely correct about the serialization that can occur. A stalled write() will stall all other write()'s plus any read()'s. Stalled write()s are easy to come by. I did some work in this area to try to mitigate the problem. In 4.1/4.2 I added the bwillwrite() function. This function is called prior to obtaining the exclusive vnode lock and blocks the process if there aren't a sufficient number of filesystem buffers available to (likely) accomodate the operation. This (mostly) prevents the process from blocking in the buffer cache while holding an exclusive vnode lock and makes a big difference. :is already in the cache), there are sufficient non-common cases that I :would anticipate this being a problem. Are there any performance figures :available that either confirm this concern, or demonstrate that in fact it :is not relevant? :-) Would this concern introduce additional funneling in :the VM system, or is the granularity of locks in the VM sufficiently low :that it might improve performance by combining existing broad locks? : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :robert@fledge.watson.org NAI Labs, Safeport Network Services The VM system is in pretty good shape in regards to fine-grained locking (you get down to the VM page). The VFS system is in terrible shape - there is no fine grained locking at all for writes. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 10:28:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id DEC8A37B440 for ; Tue, 17 Apr 2001 10:28:38 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HHSRY94888; Tue, 17 Apr 2001 10:28:27 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 10:28:27 -0700 (PDT) From: Matt Dillon Message-Id: <200104171728.f3HHSRY94888@earth.backplane.com> To: Poul-Henning Kamp Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <18021.987493190@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :When I first heard you say this I thought you were off your rockers, :but gradually I have come to think that you may be right. : :I think the task will be easier if we get the vnode/buf relationship :untangled a bit first. : :I may also pay off to take vnodes out of diskoperations entirely before :we try the merge. Yes, I agree. The vnode/VM-object issue is minor compared to the vnode/buf/io issue. :>Under the old name cache implementation, decreasing :>the number of vnodes was slow and hard. With the current name cache :>implementation, decreasing the number of vnodes would be easy. : :Actually the main problem is that NFS relies on vnodes never being :freed to hold "soft references" using "struct vnode * + v_id). : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I don't think NFS relies on vnodes never being freed. The worst that should happen is that NFS might need to do a LOOKUP. I haven't had a chance to look at the namei/vnode patch set yet but as long as a reasonable number of vnodes remain cached NFS shouldn't be effected too much. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 10:33:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.musha.org (daemon.musha.org [61.122.44.178]) by hub.freebsd.org (Postfix) with ESMTP id 2C98E37B423; Tue, 17 Apr 2001 10:33:46 -0700 (PDT) (envelope-from knu@iDaemons.org) Received: from archon.local.idaemons.org (archon.local.idaemons.org [192.168.1.32]) by mail.musha.org (Postfix) with ESMTP id F3E084DF47; Wed, 18 Apr 2001 02:33:44 +0900 (JST) Date: Wed, 18 Apr 2001 02:33:44 +0900 Message-ID: <868zkzxwg7.wl@archon.local.idaemons.org> From: "Akinori MUSHA" To: deischen@FreeBSD.org, Cc: hackers@FreeBSD.org, jagarl@creator.club.ne.jp Subject: Re: bin/25110 In-Reply-To: <3ADC5884.F48D58BD@vigrid.com> References: <86elury85r.wl@archon.local.idaemons.org> <3ADC5884.F48D58BD@vigrid.com> User-Agent: Wanderlust/2.5.4 (Smooth) SEMI/1.14.2 (=?ISO-8859-1?Q?Daish=F2?= =?ISO-8859-1?Q?ji?=) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Associated I. Daemons X-PGP-Public-Key: finger knu@FreeBSD.org X-PGP-Fingerprint: 081D 099C 1705 861D 4B70 B04A 920B EFC7 9FD9 E1EE MIME-Version: 1.0 (generated by SEMI 1.14.2 - =?ISO-8859-1?Q?=22Daish=F2ji=22?=) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for the quick reply! At Tue, 17 Apr 2001 10:51:48 -0400, Dan Eischen wrote: > Akinori MUSHA wrote: > > Would you take a look at PR#25110 ? Some programs are suffering with > > a problem that with the threaded library a process cannot receive due > > signals except SIGKILL and SIGSTOP from its children and thus it > > stalls at waitpid() after forking. > > > > The PR precisely describes the underlying cause and points out how you > > can examine and solve the problem. > > > > I'd appreciate if you or someone else with a clue could deal with it. > > You can try the patch below. I think I've posted this patch before, > but I guess I never committed it. I tested your patch with the latest 4-STABLE and the latest 5-CURRENT, and both passed my test programs that didn't work before! Of course, the test program provided in the PR by Ueno-san also worked properly. Attached is the patch I used for 4-STABLE. Now Dan, do you consider sliding it into 4.3-RELEASE? The problem had been reported, you recognized and posted a fix, and the fix looks reasonable and indeed works. I would be great to see 4.3-RELEASE shipped with the fork-safe libc_r. If you are sure it's a mature fix, I'd like you to pester jkh for approval. :) Regards, -- / /__ __ Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Freeze this moment a little bit longer, make each impression a little bit stronger.. Experience slips away -- Time stand still" Index: uthread/uthread_fork.c =================================================================== RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_fork.c,v retrieving revision 1.19.2.1 diff -u -r1.19.2.1 uthread_fork.c --- uthread/uthread_fork.c 2000/11/09 23:46:03 1.19.2.1 +++ uthread/uthread_fork.c 2001/04/17 17:07:43 @@ -32,6 +32,7 @@ * $FreeBSD: src/lib/libc_r/uthread/uthread_fork.c,v 1.19.2.1 2000/11/09 23:46:03 deischen Exp $ */ #include +#include #include #include #include @@ -108,7 +109,16 @@ else if (_pq_init(&_readyq) != 0) { /* Abort this application: */ PANIC("Cannot initialize priority ready queue."); - } else { + } else if ((_thread_sigstack.ss_sp == NULL) && + ((_thread_sigstack.ss_sp = malloc(SIGSTKSZ)) == NULL)) + PANIC("Unable to allocate alternate signal stack"); + else { + /* Install the alternate signal stack: */ + _thread_sigstack.ss_size = SIGSTKSZ; + _thread_sigstack.ss_flags = 0; + if (_thread_sys_sigaltstack(&_thread_sigstack, NULL) != 0) + PANIC("Unable to install alternate signal stack"); + /* * Enter a loop to remove all threads other than * the running thread from the thread list: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 10:35:28 2001 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 59A5B37B647 for ; Tue, 17 Apr 2001 10:35:13 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3HHYGU24579; Tue, 17 Apr 2001 19:34:16 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: Your message of "Tue, 17 Apr 2001 10:28:27 PDT." <200104171728.f3HHSRY94888@earth.backplane.com> Date: Tue, 17 Apr 2001 19:34:16 +0200 Message-ID: <24577.987528856@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104171728.f3HHSRY94888@earth.backplane.com>, Matt Dillon writes: > >:When I first heard you say this I thought you were off your rockers, >:but gradually I have come to think that you may be right. >: >:I think the task will be easier if we get the vnode/buf relationship >:untangled a bit first. >: >:I may also pay off to take vnodes out of diskoperations entirely before >:we try the merge. > > Yes, I agree. The vnode/VM-object issue is minor compared to > the vnode/buf/io issue. We're getting there, we're getting there... >:Actually the main problem is that NFS relies on vnodes never being >:freed to hold "soft references" using "struct vnode * + v_id). >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > I don't think NFS relies on vnodes never being freed. It does, in some case nfs stashes a vnode pointer and the v_id value away, and some time later tries to use that pair to try to refind the vnode again. If you free vnodes, it will still think the pointer is a vnode and if junk happens to be right it will think it is still a vnode. QED: Bad things (TM) will happen. # cd /sys/nfs # grep v_id * nfs_nqlease.c: vpid = vp->v_id; nfs_nqlease.c: if (vpid == vp->v_id) { nfs_nqlease.c: if (vpid == vp->v_id && nfs_vnops.c: vpid = newvp->v_id; nfs_vnops.c: if (vpid == newvp->v_id) { -- 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 Apr 17 10:45:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id CC97B37B423 for ; Tue, 17 Apr 2001 10:45:12 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HHj2K95255; Tue, 17 Apr 2001 10:45:02 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 10:45:02 -0700 (PDT) From: Matt Dillon Message-Id: <200104171745.f3HHj2K95255@earth.backplane.com> To: Poul-Henning Kamp Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <24577.987528856@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I don't think NFS relies on vnodes never being freed. : :It does, in some case nfs stashes a vnode pointer and the v_id :value away, and some time later tries to use that pair to try to :refind the vnode again. If you free vnodes, it will still think :the pointer is a vnode and if junk happens to be right it will :think it is still a vnode. QED: Bad things (TM) will happen. : :# cd /sys/nfs :# grep v_id * :nfs_nqlease.c: vpid = vp->v_id; :nfs_nqlease.c: if (vpid == vp->v_id) { :nfs_nqlease.c: if (vpid == vp->v_id && :nfs_vnops.c: vpid = newvp->v_id; :nfs_vnops.c: if (vpid == newvp->v_id) { : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 hahahahahahahaha.. Look at the code more closely. v_id is not managed by NFS, it's managed by vfs_cache.c. There's a big XXX comment just before cache_purge() that explains it. Believe me, NFS is the least of your worries here. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 10:55:30 2001 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 272EF37B423 for ; Tue, 17 Apr 2001 10:55:27 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3HHt1U24893; Tue, 17 Apr 2001 19:55:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: Your message of "Tue, 17 Apr 2001 10:45:02 PDT." <200104171745.f3HHj2K95255@earth.backplane.com> Date: Tue, 17 Apr 2001 19:55:01 +0200 Message-ID: <24891.987530101@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104171745.f3HHj2K95255@earth.backplane.com>, Matt Dillon writes: >:> I don't think NFS relies on vnodes never being freed. >: >:It does, in some case nfs stashes a vnode pointer and the v_id >:value away, and some time later tries to use that pair to try to >:refind the vnode again. If you free vnodes, it will still think >:the pointer is a vnode and if junk happens to be right it will >:think it is still a vnode. QED: Bad things (TM) will happen. >: >:# cd /sys/nfs >:# grep v_id * >:nfs_nqlease.c: vpid = vp->v_id; >:nfs_nqlease.c: if (vpid == vp->v_id) { >:nfs_nqlease.c: if (vpid == vp->v_id && >:nfs_vnops.c: vpid = newvp->v_id; >:nfs_vnops.c: if (vpid == newvp->v_id) { >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > hahahahahahahaha.. Look at the code more closely. v_id is not > managed by NFS, it's managed by vfs_cache.c. There's a big XXX > comment just before cache_purge() that explains it. Believe me, > NFS is the least of your worries here. Matt, you try to free vnodes back to the malloc pool and you will see what happens OK ? -- 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 Apr 17 11:28:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 3F4C637B423 for ; Tue, 17 Apr 2001 11:28:12 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HIS3E96964; Tue, 17 Apr 2001 11:28:03 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 11:28:03 -0700 (PDT) From: Matt Dillon Message-Id: <200104171828.f3HIS3E96964@earth.backplane.com> To: Poul-Henning Kamp Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <24891.987530101@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200104171745.f3HHj2K95255@earth.backplane.com>, Matt Dillon writes: :>:> I don't think NFS relies on vnodes never being freed. :>: :>:It does, in some case nfs stashes a vnode pointer and the v_id :>:value away, and some time later tries to use that pair to try to :>:refind the vnode again. If you free vnodes, it will still think :>:the pointer is a vnode and if junk happens to be right it will :>:think it is still a vnode. QED: Bad things (TM) will happen. :>: :>:# cd /sys/nfs :>:# grep v_id * :>:nfs_nqlease.c: vpid = vp->v_id; :>:nfs_nqlease.c: if (vpid == vp->v_id) { :>:nfs_nqlease.c: if (vpid == vp->v_id && :>:nfs_vnops.c: vpid = newvp->v_id; :>:nfs_vnops.c: if (vpid == newvp->v_id) { :>: :>:-- :>:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :> :> hahahahahahahaha.. Look at the code more closely. v_id is not :> managed by NFS, it's managed by vfs_cache.c. There's a big XXX :> comment just before cache_purge() that explains it. Believe me, :> NFS is the least of your worries here. : :Matt, you try to free vnodes back to the malloc pool and you will :see what happens OK ? : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 ok ok... lets see. Oh, ok I see what it's doing. Actually I think you just found a bug. if ((error = cache_lookup(dvp, vpp, cnp)) && error != ENOENT) { struct vattr vattr; int vpid; if ((error = VOP_ACCESS(dvp, VEXEC, cnp->cn_cred, p)) != 0) { *vpp = NULLVP; return (error); } newvp = *vpp; vpid = newvp->v_id; This is totally bogus. VOP_ACCESS can block, so even using vpid above to check that the vnode hasn't been ripped out from under the code won't work. Also, take a look at the vput() later on, and also the vput() in kern/vfs_cache.c/vfs_cache_lookup() - that looks bogus to me too and would probably crash the machine. The easiest solution here is to make cache_lookup bump the ref count on the returned vnode and require that all users of cache_lookup vrele() it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 11:47:58 2001 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 98AFD37B42C for ; Tue, 17 Apr 2001 11:47:54 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f3HIlqH08992; Tue, 17 Apr 2001 14:47:53 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200104170006.UAA29563@cs.rpi.edu> References: <200104170006.UAA29563@cs.rpi.edu> Date: Tue, 17 Apr 2001 14:47:47 -0400 To: "David E. Cross" , freebsd-hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: ypserv: a resolution (LOOKING for YP/DB experts!) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:06 PM -0400 4/16/01, David E. Cross wrote: [...skipping over some important stuff...] >My second solution was to have the child call yp_init_dbs() >instead of yp_flush_all() (the former would just nuke the >references to the FDs, but actually keep them open). This >didn't work. Can anyone provide any clues as to why? Does >the DB library keep its own cache, and unless they are >"really" closed it will just loop back to the open ones anyway? >The current solution is suboptimal since for many cases it >removes the DBCACHE entirely, but I don't know what other >solution exists. >JKH: I think this _really_ needs to get into 4.3-RELEASE, >this has been a vexing bug for over a year. The current >solution may be sub-optimal, but... I'm inclined to think that we should have a better understanding of what is going on in the DB routines in this parent/child situation. If it was something that worked in 4.2 but would be newly broken in 4.3, then I would be more inclined to see a last-minute sub-optimal fix rushed into 4.3, but as it is I do not have a warm fuzzy feeling that the real problem is understood at this point. If someone familiar with these DB routines could look into Dave's problem and comment, that would make any patch feel somewhat warmer and fuzzier... Perhaps Dave should put up a proposed patch to the gang in freebsd-audit as well as freebsd-hackers? -- 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 Apr 17 11:48: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from CPE-61-9-164-106.vic.bigpond.net.au (CPE-61-9-138-241.vic.bigpond.net.au [61.9.138.241]) by hub.freebsd.org (Postfix) with ESMTP id 12F1F37B423 for ; Tue, 17 Apr 2001 11:47:50 -0700 (PDT) (envelope-from darrenr@reed.wattle.id.au) Received: (from root@localhost) by CPE-61-9-164-106.vic.bigpond.net.au (8.11.0/8.11.0) id f3HIleK07299; Wed, 18 Apr 2001 04:47:40 +1000 (EST) From: Darren Reed Message-Id: <200104171847.EAA26963@avalon.reed.wattle.id.au> Subject: Re: User-defined bit in sysctl flags ? In-Reply-To: <20010416180809.N976@fw.wintelcom.net> from Alfred Perlstein at "Apr 16, 1 06:08:09 pm" To: bright@wintelcom.net (Alfred Perlstein) Date: Wed, 18 Apr 2001 04:47:34 +1000 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In some email I received from Alfred Perlstein, sie wrote: > * Darren Reed [010416 13:37] wrote: > > > > What do people think about having a range of bits in oid_kind that are > > not used by FreeBSD but are only to be used by ``private'' sysctl handlers? > > > > e.g. > > > > #define CTLFLAG_PRIVATE 0x000ffff0 > > > > Do I need elaborate any further ? > > I think a half-paragraph explaining what this does would help. :) > > I'm assuming this allows someone to have thier own private numbered > mib in the sysctl tree, my question is why are you using hardcoded > numbers rather than names? Uh, no. The idea is so you can do this: #define SYSCTL_IPF(parent, nbr, name, access, ptr, val, descr) \ SYSCTL_OID(parent, nbr, name, CTLTYPE_INT|access, \ ptr, val, sysctl_ipf_int, "I", descr); SYSCTL_IPF(_net_inet_ipf, OID_AUTO, fr_tcpidletimeout, CTLFLAG_RW|CTL_PRIV, &fr_tcpidletimeout, 0, ""); and have CTL_PRIV be a bit which sysctl_ipf_int understands and not have to worry about the value of CTL_PRIV ever being afflicted with double-use by a FreeBSD flag because CTL_PRIV is part of CTLFLAG_PRIVATE. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 12:50: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id CC82637B42C for ; Tue, 17 Apr 2001 12:49:55 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 28450 invoked from network); 17 Apr 2001 19:49:45 -0000 Received: from sherline.cts.com (HELO cx443070b) (204.216.163.132) by dualcpus.com with SMTP; 17 Apr 2001 19:49:45 -0000 Message-ID: <000001c0c777$f9529b30$215778d8@cx443070b> From: "Jeremiah Gowdy" To: References: <200104171836.LAA06378@akira.lanfear.com> Subject: x86-64 Hammer and IA64 Itainium Date: Tue, 17 Apr 2001 12:49:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like to know if anyone's considering support for the new AMD Sledgehammer/Clawhammer/*hammer with x86-64 architecture. I know the new hammer cpus will run as _very_ fast x86-32 processors, and FreeBSD would run happily under that, however, the x86-64 architecture offers major advantages over the 32bit architecture. More than simply 64bit integers. Like the Itainium, the Hammer has more registers. Not as many as Itainium's 128 64bit general purpose registers, but a good 16 64bit registers rather than the 8 32bit that exist now. I would love to see FreeBSD running natively (64bit) under the x86-64 architecture, and unlike the Itainium, it's differences with x86-32 seem to be few (of course). From what I understand of the FreeBSD kernel, the parts of the system which are platform specific are somewhat abstracted from the rest. And since it's really just the next revision of the 'same' platform, I'm hoping it would not be excessively difficult. There is coming a time soon when IA32/x86-32 production will be coming to an end, and since all of the processors FreeBSD supports are IA32, a decision will have to be made on where to move next. I've read the data sheet (read: book) Intel sent me on the Itainium, and if it performs as they say it does, it will be an excellent offering. As an x86 assembly programmer, the idea of 128 64bit registers makes me happy. However, there's not much room for an assembly language programmer in the bundled instruction world of the Itainium. Porting FreeBSD to Itainium would/will/could be a much much larger project than the port to x86-64. Linux/GNU people in association with AMD have already begun work on x86-64 versions of gcc and binutils. If Linux ports first, which in my opinion they probably will since they are working on it actively, FreeBSD can only gain from the work already done by the Linux/GNU/x86-64 group. http://www.x86-64.org Another group, supporting the IA64/Itainium architecture for Linux and GNU also exists. From reading their wish list for the IA64 gcc compiler, I can see they haven't really mastered the architecture with ILP, but instead are merely working on a functioning version first, with architectural optimizations coming later. As far as I can see, their work is benefitting future versions of FreeBSD as well. http://www.linuxia64.org/ I'm studying the AMD architecture in an effort to port my x86 assembly skills to x86-64. Learning IA64 assembly seems pointless since they want everything done with an ILP capable compiler for maximum performance. Although my kernel programming skills are in their infancy, I am a good C and assembly language programmer. Perhaps I could contribute to the FreeBSD x86-64 project, if and when there was one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 12:57:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id C5DD337B423 for ; Tue, 17 Apr 2001 12:57:41 -0700 (PDT) (envelope-from scanner@jurai.net) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id PAA40698; Tue, 17 Apr 2001 15:57:38 -0400 (EDT) Date: Tue, 17 Apr 2001 15:57:37 -0400 (EDT) From: To: Jeremiah Gowdy Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium In-Reply-To: <000001c0c777$f9529b30$215778d8@cx443070b> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to see this too, however I think you have to sign NDA's and the like to be a part of the AMD effort to develop for it. Understandable I guess. Also they only seem interested in boosting Linux adoption of the new AMD 64 bit procs. *shrug* ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 12:59: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 76AF737B43E for ; Tue, 17 Apr 2001 12:59:00 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3HJwcN22192; Tue, 17 Apr 2001 12:58:38 -0700 (PDT) Date: Tue, 17 Apr 2001 12:58:38 -0700 From: Alfred Perlstein To: Poul-Henning Kamp Cc: Matt Dillon , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance Message-ID: <20010417125838.J976@fw.wintelcom.net> References: <200104171745.f3HHj2K95255@earth.backplane.com> <24891.987530101@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <24891.987530101@critter>; from phk@critter.freebsd.dk on Tue, Apr 17, 2001 at 07:55:01PM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [010417 10:56] wrote: > In message <200104171745.f3HHj2K95255@earth.backplane.com>, Matt Dillon writes: > >:> I don't think NFS relies on vnodes never being freed. > >: > >:It does, in some case nfs stashes a vnode pointer and the v_id > >:value away, and some time later tries to use that pair to try to > >:refind the vnode again. If you free vnodes, it will still think > >:the pointer is a vnode and if junk happens to be right it will > >:think it is still a vnode. QED: Bad things (TM) will happen. > >: > >:# cd /sys/nfs > >:# grep v_id * > >:nfs_nqlease.c: vpid = vp->v_id; > >:nfs_nqlease.c: if (vpid == vp->v_id) { > >:nfs_nqlease.c: if (vpid == vp->v_id && > >:nfs_vnops.c: vpid = newvp->v_id; > >:nfs_vnops.c: if (vpid == newvp->v_id) { > >: > >:-- > >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > > > hahahahahahahaha.. Look at the code more closely. v_id is not > > managed by NFS, it's managed by vfs_cache.c. There's a big XXX > > comment just before cache_purge() that explains it. Believe me, > > NFS is the least of your worries here. > > Matt, you try to free vnodes back to the malloc pool and you will > see what happens OK ? I thought vnodes were in stable storage? Note that I really don't care for using stable storeage as a hack to deal with this sort of thing. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 13: 3:13 2001 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 614E437B42C for ; Tue, 17 Apr 2001 13:03:08 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3HK2hU27003; Tue, 17 Apr 2001 22:02:43 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: Matt Dillon , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: Your message of "Tue, 17 Apr 2001 12:58:38 PDT." <20010417125838.J976@fw.wintelcom.net> Date: Tue, 17 Apr 2001 22:02:43 +0200 Message-ID: <27001.987537763@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010417125838.J976@fw.wintelcom.net>, Alfred Perlstein writes: >I thought vnodes were in stable storage? They are, that's the point Matt is not seeing yet. >Note that I really don't care for using stable storeage as a hack >to deal with this sort of thing. Well, I have to admit that it is a pretty smart way of dealing with it for remote operations, but the trouble is that it prevents us from ever lowering their number again. If Matt can device a smart way to loose the soft reference in nfs, vnodes can be a truly dynamic thing. -- 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 Apr 17 13:16:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 02D7E37B423 for ; Tue, 17 Apr 2001 13:16:19 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HKG9l05966; Tue, 17 Apr 2001 13:16:09 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 13:16:09 -0700 (PDT) From: Matt Dillon Message-Id: <200104172016.f3HKG9l05966@earth.backplane.com> To: Poul-Henning Kamp Cc: Alfred Perlstein , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <27001.987537763@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In message <20010417125838.J976@fw.wintelcom.net>, Alfred Perlstein writes: : :>I thought vnodes were in stable storage? : :They are, that's the point Matt is not seeing yet. I know vnodes are in stable storage. I'm just saying that NFS is the least of your worries in trying to change that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 13:16:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 64D0537B423; Tue, 17 Apr 2001 13:16:52 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id NAA08915; Tue, 17 Apr 2001 13:16:47 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp05.primenet.com, id smtpdAAAaJaGyr; Tue Apr 17 13:16:42 2001 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA27566; Tue, 17 Apr 2001 13:17:02 -0700 (MST) From: Terry Lambert Message-Id: <200104172017.NAA27566@usr09.primenet.com> Subject: Very Bad Bug: current, 4.2, 4.3 To: current@freebsd.org Date: Tue, 17 Apr 2001 20:16:57 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I mentioned a very bad bug on the -arch list a while back, which occurred when To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 13:18: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id DD2DF37B43C for ; Tue, 17 Apr 2001 13:18:02 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HKHsU06007; Tue, 17 Apr 2001 13:17:54 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 13:17:54 -0700 (PDT) From: Matt Dillon Message-Id: <200104172017.f3HKHsU06007@earth.backplane.com> To: Poul-Henning Kamp Cc: Alfred Perlstein , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <27001.987537763@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>Note that I really don't care for using stable storeage as a hack :>to deal with this sort of thing. : :Well, I have to admit that it is a pretty smart way of dealing with :it for remote operations, but the trouble is that it prevents us from :ever lowering their number again. : :If Matt can device a smart way to loose the soft reference in nfs, :vnodes can be a truly dynamic thing. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 NFS uses vnodes the same way that VFS uses vnodes. If you solve the problem for general VFS operation (namely *cache_lookup), you solve the problem for NFS as well. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 13:22: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id B044837B423 for ; Tue, 17 Apr 2001 13:22:02 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [63.198.170.139]) by bazooka.unixfreak.org (Postfix) with ESMTP id 2EE4F3E29; Tue, 17 Apr 2001 13:22:02 -0700 (PDT) To: Brian Somers Cc: hackers@FreeBSD.ORG Subject: Re: Patch to make snp(4) devfs-friendly In-Reply-To: <200104170958.f3H9wOr62584@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on "Tue, 17 Apr 2001 10:58:24 +0100" Date: Tue, 17 Apr 2001 13:22:02 -0700 From: Dima Dorfman Message-Id: <20010417202202.2EE4F3E29@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers writes: > This looks good. I'd say you should commit the change yourself - > feel free to say it's reviewed by me. I'm not a src/ committer.. :-/ > As an aside, when I did this to if_tun, I chose to do all the > destroy_dev()s at module unload time (I guess the snp device could do > with a MODULE_DECLARE). This allows the administrator to relax the The problem with making snp a module is that it relies on hooks in the tty subsystem which normally aren't there. Take a look at tty.c and search for "DEV_SNP". If we wanted to make it a module, those hooks would have to be compiled into the base kernel. Since they call some snp-specific functions (snpin, snpinc), those would also have to be in the base kernel. Of course, all of that stuff can be made a kernel option, but that kind of defeats the purpose of making it a module. Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 13:25:19 2001 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 041A837B424 for ; Tue, 17 Apr 2001 13:25:16 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3HKOoU27293; Tue, 17 Apr 2001 22:24:50 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Alfred Perlstein , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: Your message of "Tue, 17 Apr 2001 13:16:09 PDT." <200104172016.f3HKG9l05966@earth.backplane.com> Date: Tue, 17 Apr 2001 22:24:50 +0200 Message-ID: <27291.987539090@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104172016.f3HKG9l05966@earth.backplane.com>, Matt Dillon writes: > >:In message <20010417125838.J976@fw.wintelcom.net>, Alfred Perlstein writes: >: >:>I thought vnodes were in stable storage? >: >:They are, that's the point Matt is not seeing yet. > > I know vnodes are in stable storage. I'm just saying that NFS > is the least of your worries in trying to change that. The namecache can do without the use of soft references. The only reason vnodes are stable storage any more is that NFS uses soft references to vnodes. -- 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 Apr 17 13:33: 6 2001 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 88E9C37B43F for ; Tue, 17 Apr 2001 13:33:03 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3HKWhU27413; Tue, 17 Apr 2001 22:32:43 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Dima Dorfman Cc: Brian Somers , hackers@FreeBSD.ORG Subject: Re: Patch to make snp(4) devfs-friendly In-Reply-To: Your message of "Tue, 17 Apr 2001 13:22:02 PDT." <20010417202202.2EE4F3E29@bazooka.unixfreak.org> Date: Tue, 17 Apr 2001 22:32:43 +0200 Message-ID: <27411.987539563@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010417202202.2EE4F3E29@bazooka.unixfreak.org>, Dima Dorfman write s: >Brian Somers writes: >> This looks good. I'd say you should commit the change yourself - >> feel free to say it's reviewed by me. > >I'm not a src/ committer.. :-/ If you have a "reviewed by" an old hand like Brian, then it is OK for you to commit it yourself. -- 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 Apr 17 13:37:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 682CB37B43F; Tue, 17 Apr 2001 13:37:32 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id NAA17079; Tue, 17 Apr 2001 13:35:57 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpdAAAZraadH; Tue Apr 17 13:35:39 2001 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA27919; Tue, 17 Apr 2001 13:37:32 -0700 (MST) From: Terry Lambert Message-Id: <200104172037.NAA27919@usr09.primenet.com> Subject: BAD BUG: Second try To: current@freeBSD.org Date: Tue, 17 Apr 2001 20:37:32 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oops. NOTE: I don't follow this lists for weeks at a time, so please include me directly in any responses. Thanks. Matt Dillon was looking at this, but I haven't heard from him for a while on it. Here is a patch to make it panic, instead of really, really trashing memory (ignore the version, I'm using a vendor import locally); the patch is to "crfree() and should be obvious: =================================================================== diff -c -r1.2 kern_prot.c *** kern/kern_prot.c 2001/03/21 02:33:03 1.2 --- kern/kern_prot.c 2001/04/17 02:22:48 *************** *** 1001,1006 **** --- 1001,1009 ---- int s; s = splhigh(); + if ( cr->cr_ref == 0) { + panic("Freeing already free credential!\n"); + } if (--cr->cr_ref == 0) { /* * Some callers of crget(), such as nfs_statfs(), =================================================================== Unfortunately, There's also a nameidata structure (it's the only data structure that's exactly 72 bytes long, which I was able to determine by printing sizeof() information for all kernel structures, and gre'ping for "72") getting freed and then either continued to be used, or being used as a result of an unchecked allocation failure (I'm still looking for that one). Basically, the second causes invariants to whine about data modified on the freelist to my console, while the first one results in an eventual panic dues to spammed memory (for the obvious reason that you can't free the same thing twice). The problems only become obvious when you open and then close around 30,000 TCP connections; sometimes it takes a couple of tries before it panics your machine. I have some programs that demonstrate the bug, if anyone is interested in repeating it on their machines locally (you will need appropriate open file limits and bump up to 40,000 or so net.inet.ip.portrange.last, e.g.: sysctl -w net.inet.ip.portrange.last=45000 Which means your box will need about a gig of memory. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 13:58:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 369DD37B43C for ; Tue, 17 Apr 2001 13:58:30 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HKwL907470; Tue, 17 Apr 2001 13:58:21 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 13:58:21 -0700 (PDT) From: Matt Dillon Message-Id: <200104172058.f3HKwL907470@earth.backplane.com> To: Poul-Henning Kamp Cc: Alfred Perlstein , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <27291.987539090@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200104172016.f3HKG9l05966@earth.backplane.com>, Matt Dillon writes: :> :>:In message <20010417125838.J976@fw.wintelcom.net>, Alfred Perlstein writes: :>: :>:>I thought vnodes were in stable storage? :>: :>:They are, that's the point Matt is not seeing yet. :> :> I know vnodes are in stable storage. I'm just saying that NFS :> is the least of your worries in trying to change that. : :The namecache can do without the use of soft references. : :The only reason vnodes are stable storage any more is that NFS :uses soft references to vnodes. The only place I see soft references on vnode is in the NFS lookup code which duplicates the VFS lookup code (except gets it wrong). If you are refering to the nqlease code... that looks like a hard reference to me. I'm not even sure why they bother to check v_id. The vp reference from an nfsnode is a hard reference. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 14: 1:22 2001 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 1F30837B42C for ; Tue, 17 Apr 2001 14:01:17 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3HL0iU27881; Tue, 17 Apr 2001 23:00:44 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Alfred Perlstein , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: Your message of "Tue, 17 Apr 2001 13:58:21 PDT." <200104172058.f3HKwL907470@earth.backplane.com> Date: Tue, 17 Apr 2001 23:00:44 +0200 Message-ID: <27879.987541244@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104172058.f3HKwL907470@earth.backplane.com>, Matt Dillon writes: > >: >:In message <200104172016.f3HKG9l05966@earth.backplane.com>, Matt Dillon writes: >:> >:>:In message <20010417125838.J976@fw.wintelcom.net>, Alfred Perlstein writes: >:>: >:>:>I thought vnodes were in stable storage? >:>: >:>:They are, that's the point Matt is not seeing yet. >:> >:> I know vnodes are in stable storage. I'm just saying that NFS >:> is the least of your worries in trying to change that. >: >:The namecache can do without the use of soft references. >: >:The only reason vnodes are stable storage any more is that NFS >:uses soft references to vnodes. > > The only place I see soft references on vnode is in the NFS > lookup code which duplicates the VFS lookup code (except gets it wrong). > If you are refering to the nqlease code... that looks like a hard > reference to me. I'm not even sure why they bother to check v_id. > The vp reference from an nfsnode is a hard reference. > Well, if that's the case, yank all uses of v_id from the nfs code, I'll do the namecache and vnodes can be deleted to the joy of our users... -- 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 Apr 17 14: 4: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id C9D4D37B422 for ; Tue, 17 Apr 2001 14:03:59 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 28838 invoked from network); 17 Apr 2001 21:03:57 -0000 Received: from sherline.cts.com (HELO cx443070b) (204.216.163.132) by dualcpus.com with SMTP; 17 Apr 2001 21:03:57 -0000 Message-ID: <001001c0c782$5683ad80$215778d8@cx443070b> From: "Jeremiah Gowdy" To: Cc: References: Subject: Re: x86-64 Hammer and IA64 Itainium Date: Tue, 17 Apr 2001 14:06:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I would like to see this too, however I think you have to sign NDA's and > the like to be a part of the AMD effort to develop for it. Understandable > I guess. Also they only seem interested in boosting Linux adoption of the > new AMD 64 bit procs. *shrug* I'm not talking about joining the x86-64 project, otherwise I'd be mailing them. I'm talking about FreeBSD using the gcc x86-64 compiler to port FreeBSD to x86-64. I have a copy of the AMD x86-64 spec, mailed to me by AMD (also available on their page in PDF), and there's no NDA with it. It's public data. And the source code for the x86-64/Linux/GNU project is public (GPL). I'm talking about a FreeBSD project to port to x86-64. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 14:14:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0E34C37B424 for ; Tue, 17 Apr 2001 14:14:08 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HLDxP07733; Tue, 17 Apr 2001 14:13:59 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 14:13:59 -0700 (PDT) From: Matt Dillon Message-Id: <200104172113.f3HLDxP07733@earth.backplane.com> To: Poul-Henning Kamp Cc: Alfred Perlstein , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <27879.987541244@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> reference to me. I'm not even sure why they bother to check v_id. :> The vp reference from an nfsnode is a hard reference. :> : :Well, if that's the case, yank all uses of v_id from the nfs code, :I'll do the namecache and vnodes can be deleted to the joy of our users... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 If you can yank v_id out from the kern/vfs_cache code, I will make similar fixes to the NFS code. I am not particularly interesting in returning vnodes to the MALLOC pool myself, but I am interested in fixing the two bugs I noticed when I ran over the code earlier today. Actually one bug. The vput() turns out to be correct, I just looked at the code again. However, the cache_lookup() call in nfs_vnops.c is broken. Assuming no other fixes, the vpid load needs to occur before the VOP_ACCESS call rather then after. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 14:17:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (Postfix) with ESMTP id D5C1737B422 for ; Tue, 17 Apr 2001 14:17:14 -0700 (PDT) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.11.1/8.11.1) id f3HLIeV06941; Tue, 17 Apr 2001 23:18:41 +0200 (CEST) (envelope-from logix) Date: Tue, 17 Apr 2001 23:18:40 +0200 From: Harold Gutch To: Egon.Rath@lsr-ooe.gv.at Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Problems with German Keyboard Message-ID: <20010417231840.D5702@foobar.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from Egon.Rath@lsr-ooe.gv.at on Tue, Apr 17, 2001 at 12:56:23PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 17, 2001 at 12:56:23PM +0200, Egon.Rath@lsr-ooe.gv.at wrote: > I´ve troubles getting german "umlauts" to work properly. I played around This should have gone to -questions or to one of the German lists. Have a look at http://www.de.freebsd.org/de/umlaute/umlaute.html HTH, Harold To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 15:56:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id 4C9AB37B424 for ; Tue, 17 Apr 2001 15:56:33 -0700 (PDT) (envelope-from float@firedrake.org) Received: from float by dayspring.firedrake.org with local (Exim 3.12 #1 (Debian)) id 14pePm-000410-00; Tue, 17 Apr 2001 23:57:42 +0100 Date: Tue, 17 Apr 2001 23:57:41 +0100 To: Charles Sprickman Cc: freebsd-hackers@freebsd.org Subject: Re: Shoutcast, high cpu, threads Message-ID: <20010417235741.A11063@firedrake.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spork@inch.com on Tue, Apr 17, 2001 at 01:47:11AM -0400 From: void Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 17, 2001 at 01:47:11AM -0400, Charles Sprickman wrote: > Hi, > > I'm running shoutcast on a 4.2R machine, and I'm finding that the > shoutcast server, when idle climbs up to around 90% cpu usage. Included > is a bit of back-and-forth with a shoutcast support person. > > I'm not too clear on what he's talking about, is there any information I > can pass on to him to help debug this? While I will take his suggestion > on increasing the sleep time, I don't want to push it too far or I may end > up with a "stuttering" server. > > Thanks, > > Charles > > ---------- Forwarded message ---------- > Date: Mon, 16 Apr 2001 10:27:33 -0700 > From: Tom Pepper > To: Charles Sprickman > Subject: Re: high cpu usage > > keep going up. your machine is fast enough that values as high as 10,000 > may show improvement. > > you're seeing this problem because freebsd is the only o/s i know of that > ignores sleep values with very small microsecond values. The man pages say: sleep - suspend process execution for an interval measured in seconds usleep - suspend process execution for an interval measured in microseconds Maybe he's using the wrong routine? -- Ben "I told Paddy no, I told Steve no, I told Paul no, and Ben fell asleep." --Kate C. (no, different Ben, I would have stayed up) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 17:59:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nwd2mime2.analog.com (nwd2gtw1.analog.com [137.71.23.34]) by hub.freebsd.org (Postfix) with ESMTP id 552DA37B424 for ; Tue, 17 Apr 2001 17:59:21 -0700 (PDT) (envelope-from justin.wojdacki.chiplogic.com@analog.com) Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.1.5) with SMTP id for ; Tue, 17 Apr 2001 21:00:15 -0400 Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id RAA01182 for ; Tue, 17 Apr 2001 17:59:17 -0700 (PDT) Received: from chiplogic.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id RAA02016 for ; Tue, 17 Apr 2001 17:59:21 -0700 (PDT) Message-ID: <3ADCE6E9.633D8275@chiplogic.com> Date: Tue, 17 Apr 2001 17:59:21 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-hackers@freebsd.org Subject: Re: Shoutcast, high cpu, threads References: <20010417235741.A11063@firedrake.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG void wrote: > > The man pages say: > > sleep - suspend process execution for an interval measured in seconds > usleep - suspend process execution for an interval measured in microseconds > > Maybe he's using the wrong routine? > The FreeBSD manpages don't appear to comment on this matter, but usleep() isn't thread safe on all platforms. -- ------------------------------------------------- Justin Wojdacki justin@chiplogic.com (408) 350-5032 Communications Processors Group -- Analog Devices To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 18:58:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chmod.ath.cx (CC2-861.charter-stl.com [24.217.115.99]) by hub.freebsd.org (Postfix) with ESMTP id 48E5637B424 for ; Tue, 17 Apr 2001 18:58:24 -0700 (PDT) (envelope-from ajh3@chmod.ath.cx) Received: by chmod.ath.cx (Postfix, from userid 1001) id CDFC3A91E; Tue, 17 Apr 2001 20:57:11 -0500 (CDT) Date: Tue, 17 Apr 2001 20:57:11 -0500 From: Andrew Hesford To: Jeremiah Gowdy Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium Message-ID: <20010417205711.C64757@cec.wustl.edu> References: <200104171836.LAA06378@akira.lanfear.com> <000001c0c777$f9529b30$215778d8@cx443070b> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000001c0c777$f9529b30$215778d8@cx443070b>; from jgowdy@home.com on Tue, Apr 17, 2001 at 12:49:04PM -0700 X-Loop: Andrew Hesford Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 17, 2001 at 12:49:04PM -0700, Jeremiah Gowdy wrote: > I would love to see FreeBSD running natively (64bit) under the x86-64 > architecture, and unlike the Itainium, it's differences with x86-32 > seem to be few (of course). > Porting FreeBSD to Itainium would/will/could be a much much larger > project than the port to x86-64. First things first... paragraphs would be nice. Large chunks of words are hard to read. Second, it is this difference from x86 that I think is justification enough to focus on Itanium rather than x86-64. I'm not sure exactly how x86-64 works, but it seems to me that it's simply the standard x86 architecture expanded to 64 bits. Isn't time we kill the x86? It's been around too long. I'm not sure how the Itanium looks, and I'm no Intel freak, but a change would be nice. We should begin moving in the direction of RISC (or at least VLIW). There's a reason every other processor has a radically different architecture. Motorola, Sun and Digital all broke new ground with their processors, because the x86 doesn't amount to all that much any more. Remember, this technology was designed for 20-year old computers. You can probably tell I'm not one to say, "If it ain't broke, don't fix it." My general attitude is that even if it works great, new possibilities should be explored if they promise something better. Now is our chance. Focus main development on Alpha and Itanium (ideally, major focus should be put on UltraSPARC and PPC, too), and leave the x86-64 porting to people who actually care. -- Andrew Hesford ajh3@chmod.ath.cx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 22:40:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id E357D37B422; Tue, 17 Apr 2001 22:40:50 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id WAA58303; Tue, 17 Apr 2001 22:40:21 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200104180540.WAA58303@beastie.mckusick.com> To: Robert Watson Cc: Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: Your message of "Tue, 17 Apr 2001 09:49:54 EDT." Date: Tue, 17 Apr 2001 22:40:21 -0700 From: Kirk McKusick Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Tue, 17 Apr 2001 09:49:54 -0400 (EDT) From: Robert Watson To: Kirk McKusick cc: Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance On Mon, 16 Apr 2001, Kirk McKusick wrote: > I am still of the opinion that merging VM objects and vnodes would be a > good idea. Although it would touch a huge number of lines of code, when > the dust settled, it would simplify some nasty bits of the system. This > merger is really independent of making the number of vnodes dynamic. > Under the old name cache implementation, decreasing the number of vnodes > was slow and hard. With the current name cache implementation, > decreasing the number of vnodes would be easy. I concur that adding a > dynamically sized vnode cache would help performance on some workloads. I'm interested in this idea, although profess a gaping blind spot in expertise in the area of the VM system. However, one of the aspects of our VFS that has always concerned me is that use of a single vnode simplelock funnels most of the relevant (and performance-sensitive) calls. The result is that all accesses to an object represented by a vnode are serialized, which can represent a substantial performance hit for applications such as databases, where simultaneous write would be advantageous, or for various vn-backed oddities (possibly including vnode-backed swap?). At some point, apparently an effort was made to mark up vnode_if.src with possible alternative locking using read/write locks, but given that all the consumers use exclusive locks right now, I assume that was not followed through on. A large part of the cost is mitigated through caching on the under-side of VFS, allowing vnode operations to return rapidly, but while this catches a number of common cases (where the file is already in the cache), there are sufficient non-common cases that I would anticipate this being a problem. Are there any performance figures available that either confirm this concern, or demonstrate that in fact it is not relevant? :-) Would this concern introduce additional funneling in the VM system, or is the granularity of locks in the VM sufficiently low that it might improve performance by combining existing broad locks? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services Every vnode in the system has an associated object. Every object backed by a file (e.g., everything but anonymous objects) has an associated vnode. So, the performance of one is pretty tied to the performance of the other. Matt is right that the VM does locking on a page level, but then has to get a lock on the associated vnode to do a read or a write, so really is pretty tied to the vnode lock performance. Merging the two data structures is not likely to change the performance characteristics of the system for either better or worse. But it will save a lot of headaches having to do with lock ordering that we have to deal with at the moment. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 17 23:31:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (adam042-060.resnet.wisc.edu [146.151.42.60]) by hub.freebsd.org (Postfix) with ESMTP id 44AFC37B424 for ; Tue, 17 Apr 2001 23:31:47 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 19782 invoked by uid 1000); 18 Apr 2001 06:31:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Apr 2001 06:31:40 -0000 Date: Wed, 18 Apr 2001 01:31:40 -0500 (CDT) From: Mike Silbersack To: Jeremiah Gowdy Cc: , Subject: Re: x86-64 Hammer and IA64 Itainium In-Reply-To: <001001c0c782$5683ad80$215778d8@cx443070b> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Apr 2001, Jeremiah Gowdy wrote: > I'm not talking about joining the x86-64 project, otherwise I'd be mailing > them. I'm talking about FreeBSD using the gcc x86-64 compiler to port > FreeBSD to x86-64. I have a copy of the AMD x86-64 spec, mailed to me by > AMD (also available on their page in PDF), and there's no NDA with it. It's > public data. And the source code for the x86-64/Linux/GNU project is public > (GPL). I'm talking about a FreeBSD project to port to x86-64. I think a port to x86-64 is an excellent idea, but I also think that you're worrying about it too far in advance. As you say, the x86-64 project is working on getting gcc ported, which is important chunk of work. As such, it's probably best to not worry about a FreeBSD port until after they're done and have linux up and running on the processors. Once that's done, it'll probably be a matter to send a clawhammer system and a large box of cheese and crackers to the guys who did the freebsd alpha port. If the architecture is actually so similar to x86, it should only take them a few weekends. :) (Alternative options include Matt Dillon splurge-buying a clawhammer system at CompUSA and doing the port himself... the likelihood of such a plan seems to hinge on how much free time he has, though. Maybe send him cheese, crackers, and a CompUSA ad to help the process along.) 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 Tue Apr 17 23:33:57 2001 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 E6C6137B42C; Tue, 17 Apr 2001 23:33:47 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3I6XdU33031; Wed, 18 Apr 2001 08:33:39 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Kirk McKusick Cc: Robert Watson , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: Your message of "Tue, 17 Apr 2001 22:40:21 PDT." <200104180540.WAA58303@beastie.mckusick.com> Date: Wed, 18 Apr 2001 08:33:39 +0200 Message-ID: <33029.987575619@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104180540.WAA58303@beastie.mckusick.com>, Kirk McKusick writes: >Every vnode in the system has an associated object. No: device vnodes dont... I think the correct solution to that is to move devices away from vnodes and into the fdesc layer, just like fifo's and sockets. -- 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 Apr 17 23:47:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from star.rila.bg (star.rila.bg [212.39.75.32]) by hub.freebsd.org (Postfix) with ESMTP id AB08B37B422 for ; Tue, 17 Apr 2001 23:47:40 -0700 (PDT) (envelope-from vlady@star.rila.bg) Received: from star.rila.bg (vlady@localhost [127.0.0.1]) by star.rila.bg (8.9.3/8.9.3) with ESMTP id JAA75409 for ; Wed, 18 Apr 2001 09:47:34 +0300 (EEST) (envelope-from vlady@star.rila.bg) Message-Id: <200104180647.JAA75409@star.rila.bg> X-Mailer: exmh version 2.1.1 10/15/1999 To: freebsd-hackers@freebsd.org From: "Vladimir Terziev" Subject: Problem patching libc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Apr 2001 09:47:34 +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi hackers, I saw the security-advisory about globbing vulnerability in ftpd and I tryed to patch my FreeBSD 4.0, but I got an error: /usr/src/lib/libc/../libc/gen/glob.c: In function `glob': /usr/src/lib/libc/../libc/gen/glob.c:171: `GLOB_MAXPATH' undeclared and the next /usr/src/lib/libc/../libc/gen/glob.c: In function `globextend': /usr/src/lib/libc/../libc/gen/glob.c:689: `GLOB_LIMIT' undeclared I think the patch is not correct or I'm wrong? Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 1:10: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 787B337B424 for ; Wed, 18 Apr 2001 01:09:55 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [63.198.170.139]) by bazooka.unixfreak.org (Postfix) with ESMTP id 52F3E3E09 for ; Wed, 18 Apr 2001 01:09:52 -0700 (PDT) To: hackers@freebsd.org Subject: Restricting the console to one vty (patch) Date: Wed, 18 Apr 2001 01:09:52 -0700 From: Dima Dorfman Message-Id: <20010418080952.52F3E3E09@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Attached is a patch that makes it possible to restrict (``freeze'') the console to a single vty (the active one). This can be used in conjunction with, e.g., lock(1) to setup a relative safeguard against malicious access while the user is away from his terminal (lock(1) alone doesn't help unless the user wants to do it for every vty he's logged into, which quickly gets repetitive). I believe this would be especially useful for laptops. Of course, this doesn't prevent malicious access in terms of somebody ripping out a disk, rebooting off of another disk, or one of the other umpteen things one can do with physical access to a computer. Instead, this is intended to protect things like ssh-agent sessions where rebooting destroys the cached credentials. Comments? Suggestions? Thanks in advance, Dima Dorfman dima@unixfreak.org Index: sys/sys/consio.h =================================================================== RCS file: /home/ncvs/src/sys/sys/consio.h,v retrieving revision 1.6 diff -u -r1.6 consio.h --- sys/sys/consio.h 2000/04/27 13:34:31 1.6 +++ sys/sys/consio.h 2001/04/18 07:29:30 @@ -116,6 +116,9 @@ /* set the history (scroll back) buffer size (in lines) */ #define CONS_HISTORY _IOW('c', 9, int) +/* freeze the console (prevent vty switching) */ +#define CONS_FREEZE _IOW('c', 10, int) + /* mouse cursor ioctl */ struct mouse_data { int x; Index: sys/dev/syscons/syscons.c =================================================================== RCS file: /home/ncvs/src/sys/dev/syscons/syscons.c,v retrieving revision 1.355 diff -u -r1.355 syscons.c --- sys/dev/syscons/syscons.c 2001/03/26 12:40:39 1.355 +++ sys/dev/syscons/syscons.c 2001/04/18 07:29:32 @@ -747,6 +747,13 @@ sc->flags &= ~SC_QUIET_BELL; return 0; + case CONS_FREEZE: + if ((*(int *)data) & 0x01) + sc->flags |= SC_SCRN_FROZEN; + else + sc->flags &= ~SC_SCRN_FROZEN; + return 0; + case CONS_GETINFO: /* get current (virtual) console info */ { vid_info_t *ptr = (vid_info_t*)data; @@ -2070,6 +2077,13 @@ int s; DPRINTF(5, ("sc0: sc_switch_scr() %d ", next_scr + 1)); + + /* if the console is frozen, disallow vty switching */ + if (sc->flags & SC_SCRN_FROZEN) { + sc_bell(sc->cur_scp, sc->cur_scp->bell_pitch, + sc->cur_scp->bell_duration); + return EPERM; + } /* delay switch if the screen is blanked or being updated */ if ((sc->flags & SC_SCRN_BLANKED) || sc->write_in_progress Index: sys/dev/syscons/syscons.h =================================================================== RCS file: /home/ncvs/src/sys/dev/syscons/syscons.h,v retrieving revision 1.65 diff -u -r1.65 syscons.h --- sys/dev/syscons/syscons.h 2001/03/11 22:48:03 1.65 +++ sys/dev/syscons/syscons.h 2001/04/18 07:29:32 @@ -163,6 +163,7 @@ #define SC_SCRN_IDLE (1 << 5) #define SC_SCRN_BLANKED (1 << 6) #define SC_SAVER_FAILED (1 << 7) +#define SC_SCRN_FROZEN (1 << 8) #define SC_INIT_DONE (1 << 16) #define SC_SPLASH_SCRN (1 << 17) Index: usr.sbin/vidcontrol/vidcontrol.1 =================================================================== RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.1,v retrieving revision 1.33 diff -u -r1.33 vidcontrol.1 --- usr.sbin/vidcontrol/vidcontrol.1 2001/04/18 07:21:58 1.33 +++ usr.sbin/vidcontrol/vidcontrol.1 2001/04/18 07:29:33 @@ -30,6 +30,7 @@ .Ar file .Oc .Op Fl g Ar geometry +.Op Fl h Cm on | off .Op Fl i Cm adapter | mode .Op Fl l Ar screen_map .Op Fl L @@ -163,6 +164,11 @@ and .Sx EXAMPLES below. +.It Fl h Cm on | off +Freeze or unfreeze the console. +When the console is frozen +.Pq Cm on , +all attempts to switch to a different virtual terminal will fail. .It Fl i Cm adapter Shows info about the current video adapter. .It Fl i Cm mode Index: usr.sbin/vidcontrol/vidcontrol.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.c,v retrieving revision 1.35 diff -u -r1.35 vidcontrol.c --- usr.sbin/vidcontrol/vidcontrol.c 2001/04/09 17:24:29 1.35 +++ usr.sbin/vidcontrol/vidcontrol.c 2001/04/18 07:29:33 @@ -69,7 +69,7 @@ { fprintf(stderr, "%s\n%s\n%s\n%s\n", "usage: vidcontrol [-r fg bg] [-b color] [-c appearance] [-d] [-l scrmap]", -" [-i adapter | mode] [-L] [-M char] [-m on|off]", +" [-i adapter | mode] [-L] [-M char] [-m on|off] [-h on|off]", " [-f size file] [-s number] [-t N|off] [-x] [-g geometry]", " [mode] [fgcol [bgcol]] [show]"); exit(1); @@ -470,6 +470,25 @@ } void +set_freeze(char *arg) +{ + int data; + int rv = 0; + + if (strcmp(arg, "on") == 0) + data = 0x01; + else if (strcmp(arg, "off") == 0) + data = 0x02; + else { + warnx("argument to -h must be either on or off"); + return; + } + rv = ioctl(0, CONS_FREEZE, &data); + if (rv) + warn("ioctl(CONS_FREEZE)"); +} + +void set_border_color(char *arg) { int color; @@ -648,7 +667,7 @@ info.size = sizeof(info); if (ioctl(0, CONS_GETINFO, &info) < 0) err(1, "must be on a virtual console"); - while((opt = getopt(argc, argv, "b:c:df:g:i:l:LM:m:r:s:t:x")) != -1) + while((opt = getopt(argc, argv, "b:c:df:g:h:i:l:LM:m:r:s:t:x")) != -1) switch(opt) { case 'b': set_border_color(optarg); @@ -674,6 +693,9 @@ warnx("incorrect geometry: %s", optarg); usage(); } + break; + case 'h': + set_freeze(optarg); break; case 'i': show_info(optarg); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 1:20: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 1107F37B43C for ; Wed, 18 Apr 2001 01:19:46 -0700 (PDT) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 9404 invoked by uid 1000); 18 Apr 2001 08:18:06 -0000 Date: Wed, 18 Apr 2001 11:18:06 +0300 From: Peter Pentchev To: Vladimir Terziev Cc: freebsd-hackers@freebsd.org Subject: Re: Problem patching libc Message-ID: <20010418111806.C2925@ringworld.oblivion.bg> Mail-Followup-To: Vladimir Terziev , freebsd-hackers@freebsd.org References: <200104180647.JAA75409@star.rila.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104180647.JAA75409@star.rila.bg>; from vlady@rila.bg on Wed, Apr 18, 2001 at 09:47:34AM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 18, 2001 at 09:47:34AM +0300, Vladimir Terziev wrote: > > Hi hackers, > > > I saw the security-advisory about globbing vulnerability in ftpd and I > tryed to patch my FreeBSD 4.0, but I got an error: > > /usr/src/lib/libc/../libc/gen/glob.c: In function `glob': > /usr/src/lib/libc/../libc/gen/glob.c:171: `GLOB_MAXPATH' undeclared > > and the next > > /usr/src/lib/libc/../libc/gen/glob.c: In function `globextend': > /usr/src/lib/libc/../libc/gen/glob.c:689: `GLOB_LIMIT' undeclared > > > I think the patch is not correct or I'm wrong? This was discussed on the -security mailing list. Yes, the patch was missing the include/glob.h part; try to also apply the attached patch. G'luck, Peter -- If I were you, who would be reading this sentence? =================================================================== RCS file: /home/ncvs/src/include/glob.h,v retrieving revision 1.3 retrieving revision 1.3.6.1 diff -u -p -r1.3 -r1.3.6.1 --- src/include/glob.h 1998/02/25 02:15:59 1.3 +++ src/include/glob.h 2001/03/21 14:33:56 1.3.6.1 @@ -34,6 +34,7 @@ * SUCH DAMAGE. * * @(#)glob.h 8.1 (Berkeley) 6/2/93 + * $FreeBSD: /home/ncvs/src/include/glob.h,v 1.3.6.1 2001/03/21 14:33:56 jlemon Exp $ */ #ifndef _GLOB_H_ @@ -76,9 +77,11 @@ typedef struct { #define GLOB_NOMAGIC 0x0200 /* GLOB_NOCHECK without magic chars (csh). */ #define GLOB_QUOTE 0x0400 /* Quote special chars with \. */ #define GLOB_TILDE 0x0800 /* Expand tilde names from the passwd file. */ +#define GLOB_MAXPATH 0x1000 /* limit number of returned paths */ #define GLOB_NOSPACE (-1) /* Malloc call failed. */ #define GLOB_ABEND (-2) /* Unignored error. */ +#define GLOB_LIMIT (-3) /* Path limit was hit. */ __BEGIN_DECLS int glob __P((const char *, int, int (*)(const char *, int), glob_t *)); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 2:20:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by hub.freebsd.org (Postfix) with ESMTP id 0CC2437B423 for ; Wed, 18 Apr 2001 02:20:51 -0700 (PDT) (envelope-from K.J.Koster@kpn.com) Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id <2TM2CCR8>; Wed, 18 Apr 2001 11:20:49 +0100 Message-ID: <59063B5B4D98D311BC0D0001FA7E452205FD9B53@l04.research.kpn.com> From: "Koster, K.J." To: 'Matt Dillon' Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: vm balance Date: Wed, 18 Apr 2001 11:20:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Matt, > : > :Well, if that's the case, yank all uses of v_id from the nfs code, > :I'll do the namecache and vnodes can be deleted to the joy > of our users... > : > > If you can yank v_id out from the kern/vfs_cache code, I > will make similar > fixes to the NFS code. I am not particularly interesting > in returning > vnodes to the MALLOC pool myself, but I am interested in > fixing the > two bugs I noticed when I ran over the code earlier today. > > Actually one bug. The vput() turns out to be correct, I > just looked at > the code again. However, the cache_lookup() call in > nfs_vnops.c is > broken. Assuming no other fixes, the vpid load needs to > occur before > the VOP_ACCESS call rather then after. > I'm just curious: would this be the "redundant call/non-optimal performance"--type bug or the "panics or trashes the system in dark and mysterious ways"--type bug? If it is the latter, do you think it may be an opportunity for you to close some NFS-related PR's? Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 4:21:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.dcn-asu.ru (ns.dcn-asu.ru [212.192.20.33]) by hub.freebsd.org (Postfix) with ESMTP id 8A65037B43F for ; Wed, 18 Apr 2001 04:21:23 -0700 (PDT) (envelope-from svm@dcn-asu.ru) Received: from dcn-asu.ru ([212.192.20.54]) by ns.dcn-asu.ru (8.9.3/8.9.1-BPO1) with ESMTP id SAA20048 for ; Wed, 18 Apr 2001 18:21:06 +0700 (NOVST) Message-ID: <3ADD78A9.4B019C44@dcn-asu.ru> Date: Wed, 18 Apr 2001 18:21:13 +0700 From: "Vladimir M. Shelyugin" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: SSE support Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All!! I have 4.2-RELEASE and have written a little patch for npx driver and several kernel files to support FXSAVE/FXRSTOR instructions to enable SSE support (needed for avifile library). Does project needs this? I don't have -CURRENT, and don't know about current state of SSE support. Best regards, Vladimir M. Shelyugin, Altai State University ICQ# 17541775 (at work) 99825635 (at home) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 6:25:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id DA9DC37B423 for ; Wed, 18 Apr 2001 06:25:47 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA17002; Wed, 18 Apr 2001 09:25:47 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f3IDPGP64009; Wed, 18 Apr 2001 09:25:16 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15069.38332.759360.177827@grasshopper.cs.duke.edu> Date: Wed, 18 Apr 2001 09:25:16 -0400 (EDT) To: Mike Silbersack Cc: Subject: Re: x86-64 Hammer and IA64 Itainium In-Reply-To: References: <001001c0c782$5683ad80$215778d8@cx443070b> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Silbersack writes: > > Once that's done, it'll probably be a matter to send a clawhammer > system and a large box of cheese and crackers to the guys who did the > freebsd alpha port. If the architecture is actually so similar to x86, > it should only take them a few weekends. :) As one of the FreeBSD/alpha porters, I must point out that I don't know diddly-squat about low-level x86isms. I've never even written a line of x86 assembly. What's the timeframe that they're shooting for with this beast, anyway? Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 6:53:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7084437B424 for ; Wed, 18 Apr 2001 06:53:15 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3IDqPf02579; Wed, 18 Apr 2001 09:52:25 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Apr 2001 09:52:25 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: <33029.987575619@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > In message <200104180540.WAA58303@beastie.mckusick.com>, Kirk McKusick writes: > > >Every vnode in the system has an associated object. > > No: device vnodes dont... > > I think the correct solution to that is to move devices away from vnodes > and into the fdesc layer, just like fifo's and sockets. I dislike that idea for a number of reasons, not least of which is that introducing more and more file-descriptor level objects increases the complexity of the system call service implementation, and duplicates code. If we're going to pretend that everything in the system is a file, and most people seem willing to accept that, acting on devices through vnodes seems like a reasonable choice. The vnode provides us with a notion of open/close, reference counting, access to a generic vnode pager for memory mapping of objects without specific memory mapping characteristics, and so on. Right now, the mapping from vnodes into devices is a bit poor due to some odd reference / open / close behavior, and due to a lack of a notion of stateful access to vnodes (there have been a number of proposals to remedy this, however). The vnode is our abstraction for objects that have address spaces, can be opened/closed and retain a seeking position, can be mapped, have protections, etc, etc. It may not be a perfect representation of a device, but it does a reasonable job. Besides which, the kernel knows how to act on vnodes, and there is plenty of precedent for the kernel opening vnodes and keeping around references for its own ends, but there isn't all that much precedent for the kernel doing this using file descriptors :-). 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 Wed Apr 18 7: 3:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (adam042-060.resnet.wisc.edu [146.151.42.60]) by hub.freebsd.org (Postfix) with ESMTP id 69A7F37B423 for ; Wed, 18 Apr 2001 07:03:40 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 20891 invoked by uid 1000); 18 Apr 2001 14:03:38 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Apr 2001 14:03:38 -0000 Date: Wed, 18 Apr 2001 09:03:38 -0500 (CDT) From: Mike Silbersack To: Andrew Gallatin Cc: Subject: Re: x86-64 Hammer and IA64 Itainium In-Reply-To: <15069.38332.759360.177827@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Andrew Gallatin wrote: > Mike Silbersack writes: > > > > Once that's done, it'll probably be a matter to send a clawhammer > > system and a large box of cheese and crackers to the guys who did the > > freebsd alpha port. If the architecture is actually so similar to x86, > > it should only take them a few weekends. :) > > As one of the FreeBSD/alpha porters, I must point out that I don't > know diddly-squat about low-level x86isms. I've never even written a > line of x86 assembly. Hm, no cheese or crackers for you then. The reason I figured alpha experience would help is because I suspect that the important part of the porting would be the 32 -> 64 bit conversion; everything else _should_ be similar enough that it would be straightforward to convert for someone familiar with the lowlevel innards. (If the end product works how they have personified it, at least.) I guess getting dual 64/32 bit mode could be tricky, though. > What's the timeframe that they're shooting for with this beast, anyway? > > Drew The first x86-64 chips (the clawhammer series) are supposed to ship in the first half of 2002. 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 Wed Apr 18 7: 6:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BA4F237B422 for ; Wed, 18 Apr 2001 07:06:30 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3IE55f02718; Wed, 18 Apr 2001 10:05:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Apr 2001 10:05:05 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Robert Watson wrote: > On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > address spaces, can be opened/closed and retain a seeking position, can be This is what I get for sending messages in the morning after staying up late -- needless to say, you can ignore the "retain a seeking position" statement: vnodes generally don't operate with a notion of "position", that occurs at the struct file level. It's arguable, if you had stateful vnodes, that you might want to push the seek operation down from the open file layer, as devices might want to implement the seeking service themselves. In any case, this is not a problem that moving the device operations into the struct file array will fix--in fact, it's arguable for devices wanting to offer services to different consumers on the same instance (such as /dev/vmmon), you want the vnode reference counting notion of open/close + the sprinkled state vnode design we've discussed before, which would allow VFS and the struct file layer to do the state management binding state to consumers, rather than teaching the device layer how to do that. 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 Wed Apr 18 7:23:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 7AF9337B424 for ; Wed, 18 Apr 2001 07:23:04 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.lxlun.boostworks.com [192.168.8.101]) by luxren2.boostworks.com (8.11.3/8.11.3) with ESMTP id f3IELwC11439; Wed, 18 Apr 2001 16:22:00 +0200 (CEST) Message-Id: <200104181422.f3IELwC11439@luxren2.boostworks.com> Date: Wed, 18 Apr 2001 16:24:18 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: x86-64 Hammer and IA64 Itainium To: ajh3@chmod.ath.cx Cc: jgowdy@home.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <20010417205711.C64757@cec.wustl.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17 Apr, Andrew Hesford wrote: > On Tue, Apr 17, 2001 at 12:49:04PM -0700, Jeremiah Gowdy wrote: >> I would love to see FreeBSD running natively (64bit) under the x86-64 >> architecture, and unlike the Itainium, it's differences with x86-32 >> seem to be few (of course). > >> Porting FreeBSD to Itainium would/will/could be a much much larger >> project than the port to x86-64. > > First things first... paragraphs would be nice. Large chunks of words > are hard to read. > > Second, it is this difference from x86 that I think is justification > enough to focus on Itanium rather than x86-64. I'm not sure exactly how > x86-64 works, but it seems to me that it's simply the standard x86 > architecture expanded to 64 bits. > > Isn't time we kill the x86? It's been around too long. I'm not sure how > the Itanium looks, and I'm no Intel freak, but a change would be nice. > We should begin moving in the direction of RISC (or at least VLIW). > > There's a reason every other processor has a radically different > architecture. Motorola, Sun and Digital all broke new ground with their > processors, because the x86 doesn't amount to all that much any more. > Remember, this technology was designed for 20-year old computers. > For sure. Look at how it's pretty more easy to use an ARM or MIPS core to handle gluelessly the PCI, SDRAM, Flash etc... and just add specific components for the analogic interface side. X86 (and -64) is going to be just die hard PC and workstations where deadly wrong past must be taken into account at the price of wasted power. Futur is more than probably Itanium and alike for servers CPUs and a bunch of ARMs for low-level I/O tasks. Back to imagination. (Take a look at 0.15um copper process FPGAs with embeded ARM at Altera, for example, and you will see why no one, in the futur, will never ever need a proprietary and undocumented 'server class' SCSI or network card). It would be really interesting to have a server-class FreeBSD SMPng version and, in conjonction, an highly portable and small Pico-bsd like one to animate the embeded processors. RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 7:27:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 110D737B424 for ; Wed, 18 Apr 2001 07:27:34 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.3) id f3IERVQ24148; Wed, 18 Apr 2001 09:27:31 -0500 (CDT) (envelope-from dan) Date: Wed, 18 Apr 2001 09:27:31 -0500 From: Dan Nelson To: Dima Dorfman Cc: hackers@FreeBSD.ORG Subject: Re: Restricting the console to one vty (patch) Message-ID: <20010418092731.B733@dan.emsphone.com> References: <20010418080952.52F3E3E09@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010418080952.52F3E3E09@bazooka.unixfreak.org>; from "Dima Dorfman" on Wed Apr 18 01:09:52 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Apr 18), Dima Dorfman said: > Attached is a patch that makes it possible to restrict (``freeze'') > the console to a single vty (the active one). This can be used in > conjunction with, e.g., lock(1) to setup a relative safeguard against > malicious access while the user is away from his terminal (lock(1) > alone doesn't help unless the user wants to do it for every vty he's > logged into, which quickly gets repetitive). I believe this would be > especially useful for laptops. Isn't there already support for this? struct vt_mode { char mode; #define VT_AUTO 0 /* switching is automatic */ #define VT_PROCESS 1 /* switching controlled by prog */ #define VT_KERNEL 255 /* switching controlled in kernel */ char waitv; /* not implemented yet SOS */ short relsig; short acqsig; short frsig; /* not implemented yet SOS */ }; typedef struct vt_mode vtmode_t; #define VT_SETMODE _IOW('v', 2, vtmode_t) #define VT_GETMODE _IOR('v', 3, vtmode_t) If you call VT_SETMODE and tell the console that screen switching is VT_PROCESS, that will disable VTY switching (libvgl sets this so it can disable graphics mode when the user wants to switch screens). -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 7:28:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from jhs.muc.de (jhs.muc.de [193.149.49.84]) by hub.freebsd.org (Postfix) with ESMTP id 9C4EE37B423 for ; Wed, 18 Apr 2001 07:28:44 -0700 (PDT) (envelope-from jhs@jhs.muc.de) Received: from park.jhs.private (localhost [127.0.0.1]) by jhs.muc.de (8.11.0/8.11.0) with ESMTP id f3ICO7P05036; Wed, 18 Apr 2001 12:24:07 GMT (envelope-from jhs@park.jhs.private) Message-Id: <200104181224.f3ICO7P05036@jhs.muc.de> To: Egon.Rath@lsr-ooe.gv.at Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Problems with German Keyboard In-Reply-To: Message from Egon.Rath@lsr-ooe.gv.at of "Tue, 17 Apr 2001 12:56:23 +0200." Date: Wed, 18 Apr 2001 14:24:07 +0200 From: "Julian Stacey Jhs@jhs.muc.de" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Egon.Rath@lsr-ooe.gv.at wrote: > I´ve troubles getting german "umlauts" to work properly. I played around If you don't get an answer here, ask on a list administered by majordomo@de.freebsd.org EG de-bsd-chat@ de-bsd-hackers@ (I only use USA default myself). Julian - Julian Stacey Unix Consultant - Munich Germany http://bim.bsn.com/~jhs/ Considering Linux ? Try FreeBSD with 4500 packages ! Ihr Rauchen => mein allergischer Kopfschmerz ! Kau/Schnupftabak probieren ! Vintage Computer Fest Europa 28&9 Apr 2001 http://www.vintage.org/vcfe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 7:55: 7 2001 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 4982637B422; Wed, 18 Apr 2001 07:55:03 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3IEsqU38780; Wed, 18 Apr 2001 16:54:53 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Robert Watson Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: Your message of "Wed, 18 Apr 2001 09:52:25 EDT." Date: Wed, 18 Apr 2001 16:54:52 +0200 Message-ID: <38778.987605692@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Rober t Watson writes: > >On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > >> In message <200104180540.WAA58303@beastie.mckusick.com>, Kirk McKusick writes: >> >> >Every vnode in the system has an associated object. >> >> No: device vnodes dont... >> >> I think the correct solution to that is to move devices away from vnodes >> and into the fdesc layer, just like fifo's and sockets. > >I dislike that idea for a number of reasons, not least of which is that >introducing more and more file-descriptor level objects increases the >complexity of the system call service implementation, and duplicates code. >If we're going to pretend that everything in the system is a file, and >most people seem willing to accept that, acting on devices through vnodes >seems like a reasonable choice. I have not examined the full details of doing the shift yet, but it is my impression that it actually will reduce the amount of code duplication and special casing. Basically we will need a new: struct fileops devfileops = { dev_read, dev_write,, dev_ioctl, dev_poll, dev_kqfilter, dev_stat, dev_close }; The only places we will need new magic is open, which needs to fix the plumbing for us. mmap, which may have to be added to the fileops vector. The amount of special-casing code this would remove from the vnode layer is rather astonishing. If we merger vm-objects and vnodes without taking devices out of the mix, we will need even more special-case code for devices. >The vnode is our abstraction for objects that have >address spaces, can be opened/closed and retain a seeking position, can be >mapped, have protections, etc, etc. This is simply not correct Robert, UNIX::sockets also have many of those properties, but they're not vnodes... >Besides which, >the kernel knows how to act on vnodes, and there is plenty of precedent >for the kernel opening vnodes and keeping around references for its own >ends, but there isn't all that much precedent for the kernel doing this >using file descriptors :-). Have you actually examined how FIFO and Sockets work Robert ? :-) -- 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 Apr 18 8:28:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0139F37B422 for ; Wed, 18 Apr 2001 08:28:02 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3IFSBf03840; Wed, 18 Apr 2001 11:28:11 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Apr 2001 11:28:11 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: <38778.987605692@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > >The vnode is our abstraction for objects that have > >address spaces, can be opened/closed and retain a seeking position, can be > >mapped, have protections, etc, etc. > > This is simply not correct Robert, UNIX::sockets also have many of those > properties, but they're not vnodes... As I indicated in my follow-up mail, the statement about seeking was incorrect, that is a property of the open file structure; I believe the remainder still holds true. When was the last time you tried mmap'ing or seeking on the socket? A socket represents a buffered data stream which does not allow arbitrary read/write operations at arbitrary offsets. I guess what I'd really like to see is this: for devices that provide an address space service (such as disks), vnodes would be used. For devices that represent streams (such as many pseudo-devices and ttys), they would be represented by a slightly improved socket abstraction. The socket is a somewhat poor abstraction for this right now, perhaps a vstream would be a better concept. > >Besides which, > >the kernel knows how to act on vnodes, and there is plenty of precedent > >for the kernel opening vnodes and keeping around references for its own > >ends, but there isn't all that much precedent for the kernel doing this > >using file descriptors :-). > > Have you actually examined how FIFO and Sockets work Robert ? :-) What I'm refering to is the fact that the kernel frequently keeps open vnodes for use internally in various sorts of operations, such as quotas, accounting, core dumps, etc. BTW, part of the problem here may be a terminology problem: for me, a file descriptor refers to the per-process reference in the file descriptor table. What you appear to refer to here is the open file entry, struct file, which stores the operation array, seeking location, cached credential, etc. 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 Wed Apr 18 8:42: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by hub.freebsd.org (Postfix) with ESMTP id 4B23237B422 for ; Wed, 18 Apr 2001 08:41:59 -0700 (PDT) (envelope-from watchman@ludd.luth.se) Received: from d1o907.telia.com (d1o907.telia.com [195.252.38.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id RAA06387; Wed, 18 Apr 2001 17:41:56 +0200 (CEST) Received: from ludd.luth.se (h63n2fls21o907.telia.com [213.66.203.63]) by d1o907.telia.com (8.8.8/8.8.8) with ESMTP id RAA10727; Wed, 18 Apr 2001 17:41:55 +0200 (CEST) Message-ID: <3ADDB5AC.AA624F@ludd.luth.se> Date: Wed, 18 Apr 2001 17:41:32 +0200 From: Joachim =?iso-8859-1?Q?Str=F6mbergson?= Organization: Acne X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en-US MIME-Version: 1.0 To: Jeremiah Gowdy Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium References: <200104171836.LAA06378@akira.lanfear.com> <000001c0c777$f9529b30$215778d8@cx443070b> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG AlohA! Jeremiah Gowdy wrote: > Linux/GNU people in association with AMD have already begun work on x86-64 > versions of gcc and binutils. If Linux ports first, which in my opinion > they probably will since they are working on it actively, FreeBSD can only > gain from the work already done by the Linux/GNU/x86-64 group. > > http://www.x86-64.org Ok, that site seems to be the obviuos starting point for a FreeBSD port too. First reading through the documentation and then trying to get the instruction simulator running. Unfortunately, the ISS is only available as binary RPM - but that shouldn't stop us. The ISS is available here: http://www.x86-64.org/downloads BTW: I know a few of the persons at Virtutech (the guys behind Simics - the other simulator). Let me try and see if they would be interested in letting the FreeBSD project have access in some way to their ISS. The worst that could possibly happen is that we get a "no way". -- Cheers! Joachim - Alltid i harmonisk svängning --- FairLight ------ FairLight ------ FairLight ------ FairLight --- Joachim Strömbergson ASIC SoC designer, nice to CUTE animals Phone: +46(0)31 - 27 98 47 Web: http://www.ludd.luth.se/~watchman --------------- Spamfodder: regeringen@regeringen.se --------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 9:18:27 2001 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 A6EB237B422 for ; Wed, 18 Apr 2001 09:18:24 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from opal (cs.binghamton.edu [128.226.123.101]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f3IGIM518187 for ; Wed, 18 Apr 2001 12:18:22 -0400 (EDT) Date: Wed, 18 Apr 2001 12:18:22 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@opal To: freebsd-hackers@freebsd.org Subject: Buffer emergence reserve Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While looking at the code in vfs_bio.c, I notice the existence of low and high free buffer counters. The comments say they are there to give some special process like buf daemon access to emergence reserve. I just don't get the reason for having this emergence reserve. Do we allocate buffer in an interrupt environment? Do we need extra buffers in order to free buffers? Please shed a light on this for me. Thanks. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 9:29:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8251C37B423 for ; Wed, 18 Apr 2001 09:29:36 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3IGTof04958; Wed, 18 Apr 2001 12:29:50 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Apr 2001 12:29:50 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: <38778.987605692@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > I have not examined the full details of doing the shift yet, but it is > my impression that it actually will reduce the amount of code > duplication and special casing. .. > The only places we will need new magic is > open, which needs to fix the plumbing for us. > mmap, which may have to be added to the fileops vector. > > The amount of special-casing code this would remove from the vnode > layer is rather astonishing. > > If we merger vm-objects and vnodes without taking devices out of the > mix, we will need even more special-case code for devices. Let me expand a bit on what I want to object to, and then comment a bit on what I have mixed feelings about but am not actively objecting to. I believe it is necessary to retain a reference to the vnode used to access the device in f_data, and an f_type of DTYPE_VNODE. This is used with tty's extensively, where it is desirable to open /dev/ttyfoo and then perform file system operations on it, such as fchflags(), fchmod(), fchown(), revoke(), et al, and relies on reaching the vnode via the open file entry associated with the file descriptor designated by the invoking process. This behavior is needed for a variety of race-free operations at login, et al. Changing this would require *extensive* modification to the syscall service layer (that is, what sits above VFS). Assuming the modifications were made so that the fileops array provided these services (makine the struct file be the entire abstraction, hiding VFS from the system call service layer) you've now completely rewritten the large majority of system calls, as well as introduced a whole ne category of inter-abstraction synchronization that must occur when a change is made to any abstraction (i.e., adding ACLs, MAC, ...). So it seems to me that access to the vnode must be maintained in struct file, that we cannot totally replace references to the vnode with references to, for example, the device abstraction. So with these assumptions in place, it's still possible to consider what you were suggesting: replacing the vnode fileops array with a device fileops array, so that these calls would be short-cutted directly to the device abstraction rather than passing through the VFS abstractions on the way. In some ways, this makes sense: many of the device services map poorly into the file-like abstraction of the vnode. For example, devices may have a notion of a stateful seeking position: tape drives, for example, really *do* seek to a particular location where the next read or write must be performed. Similarly, some devices really do act like streaming data sources or sinks: especially with regards to pseudo-devices, they may behave much more like sockets, with a notion of a discrete transmission unit, a maximum transmission unit, or addressibility (imagine if you could open a device representing a bus, and use socket addressing calls to set the bus address being targetted -- say for a /dev/usb0, you could say "address the following messages to USB address 4", or being able to open /dev/ed0, set the target address of the device instance to an ethernet address, and send). We already have this problem to some extent with sockets: we use the file system vnode for two purposes: first, as a namespace in which to identify the IPC object, and second, as a means for storing protection properties. It's arguable that devices might work that way also, which I think is what you're asserting. I'm not strictly opposed to this viewpoint, but it begins to make me wonder a bit about the current structuring of that whole section of the kernel: to me, a vnode really does seem like a decent abstraction of the file system concept. The socket seems like a less decent abstraction of the IPC concept, but a better abstraction of a send/receive stream. This is all complicated by long-standing interfaces and notions about how the abstractions are to be used. I guess I'd rather see it look something like this: +-----------------+ | file descriptor | +-------+---------+ | +-----------+-------------+ | kernel object reference | +-----------+-------------+ | +---------------+-----------------+ | | | vfile kqueue vstream | +--------+------+--+--------+ IPC Socket FIFO Pipe Stream Device (note the above, and below, are highly fictional) Where "kernel object reference" is the equivilent of today's "struct file", "vfile" is the equivilent of today's "vnode", and "vstream" is a new abstraction for discrete or streamed, ordered, message/event-oriented services. Devices might choose to appear as a file-like service, offering an ordered data address space where all points of the address space have fairly similar properties, provide a memory mapping service (possibly a generic vfile pager), data can be read or written arbitrarily, and so on. They could also choose to appear as a stream-oriented service which would offer send/receive primitives, possibly as a stream with discrete message boundaries, with addressing management, etc. Ideally, I'd actually rather kqueue fit under an abstraction like that, although it's currently a first-class object. You could imagine: struct kernel_object { struct vnode *ko_vp; /* Optional vnode that provided * access to the object. */ int ko_type; /* Which service abstraction. */ union { struct vfile *kso_vfile; struct vstream *kso_vstream; struct kqueue *kso_kqueue; } ko_service; }; The optional vnode (possibly NULL) is maintained so that the caller can perform file-system f* operations on the file descriptor pointing at the object, but wouldn't apply for things like pipe's, where there is no file system object. Presumably most operations would go either to the ko_vp, or to the ko_service; some might be propagated to both, such as open and close operations. Another thing to keep in mind, btw, is that security services are poorly divided between the device system and file system right now. File system permissions are applied on device open, and used by many consumers -- in fact, one cool thing about using BPF with a /dev/bpf is being able to give out read/write access to unprivileged. This doesn't work for a number of devices, which enforce their own protections in the open operation... 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 Wed Apr 18 9:44:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 8FCDE37B422 for ; Wed, 18 Apr 2001 09:44:55 -0700 (PDT) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id C44C85920C; Wed, 18 Apr 2001 11:44:49 -0500 (CDT) Date: Wed, 18 Apr 2001 11:44:49 -0500 From: "Michael C . Wu" To: hackers@freebsd.org Subject: parallel computing clusters on freebsd Message-ID: <20010418114449.A9679@peorth.iteration.net> Reply-To: "Michael C . Wu" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Everyone, As the institution that I work at is considering to build a new parallel computing cluster, I would like to push for a FreeBSD one. I know that there are several FreeBSD clusters out there. And I would like to talk to the people who use or run such clusters to better understand the problems. If you wish, could you tell me about the problems, caveats, difficuties, performance, and in general anything about your cluster? I would also like to talk to the people that run or built the cluster on the phone for a bit to get a sense of what they went through. (I will make the call of course.) If you think you can help me, please email me your phone number and a good time to call you privately. Thanks, Michael -- +-----------------------------------------------------------+ | keichii@iteration.net | keichii@freebsd.org | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +-----------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 9:45: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id EF19E37B443 for ; Wed, 18 Apr 2001 09:45:01 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3IGiRG49494; Wed, 18 Apr 2001 09:44:27 -0700 (PDT) (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: <15069.38332.759360.177827@grasshopper.cs.duke.edu> Date: Wed, 18 Apr 2001 09:43:48 -0700 (PDT) From: John Baldwin To: Andrew Gallatin Subject: Re: x86-64 Hammer and IA64 Itainium Cc: freebsd-hackers@FreeBSD.org, Mike Silbersack Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Apr-01 Andrew Gallatin wrote: > > Mike Silbersack writes: > > > > Once that's done, it'll probably be a matter to send a clawhammer > > system and a large box of cheese and crackers to the guys who did the > > freebsd alpha port. If the architecture is actually so similar to x86, > > it should only take them a few weekends. :) > > As one of the FreeBSD/alpha porters, I must point out that I don't > know diddly-squat about low-level x86isms. I've never even written a > line of x86 assembly. > > What's the timeframe that they're shooting for with this beast, anyway? The person you want to be asking is Peter Wemm, who has already looked at the feasibility of a port from the kernel side for x86-64. He estimates one week if we clean up the i386 pmap first so we can pull from it when doing the x86-64 (or ka64) stuff. Also, in case you aren't aware (this is not to you Drew, I know you know :)) FreeBSD already has an ia64 port underway in -current. ia64, x86-64, ppc, and a few others are on the radar scope of the FreeBSD developers. > Drew -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Wed Apr 18 10: 2:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id F2F8F37B422; Wed, 18 Apr 2001 10:02:17 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3IH24s23282; Wed, 18 Apr 2001 10:02:04 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Apr 2001 10:02:04 -0700 (PDT) From: Matt Dillon Message-Id: <200104181702.f3IH24s23282@earth.backplane.com> To: Poul-Henning Kamp Cc: Robert Watson , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <38778.987605692@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If this will get rid of or clean up the specfs garbage, then I'm all for it. I would love to see a 'clean' fileops based device interface. -Matt :I have not examined the full details of doing the shift yet, but it is :my impression that it actually will reduce the amount of code :duplication and special casing. : :Basically we will need a new: : : struct fileops devfileops = { : dev_read, : dev_write,, : dev_ioctl, : dev_poll, : dev_kqfilter, : dev_stat, : dev_close : }; : :The only places we will need new magic is : open, which needs to fix the plumbing for us. : mmap, which may have to be added to the fileops vector. : :The amount of special-casing code this would remove from the vnode :layer is rather astonishing. : :If we merger vm-objects and vnodes without taking devices out of the :mix, we will need even more special-case code for devices. : :>The vnode is our abstraction for objects that have :>address spaces, can be opened/closed and retain a seeking position, can be :>mapped, have protections, etc, etc. : :This is simply not correct Robert, UNIX::sockets also have many of :those properties, but they're not vnodes... : :>Besides which, :>the kernel knows how to act on vnodes, and there is plenty of precedent :>for the kernel opening vnodes and keeping around references for its own :>ends, but there isn't all that much precedent for the kernel doing this :>using file descriptors :-). : :Have you actually examined how FIFO and Sockets work Robert ? :-) : :-- :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 Apr 18 10:13:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by hub.freebsd.org (Postfix) with ESMTP id 0E57F37B423 for ; Wed, 18 Apr 2001 10:13:12 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 27D9516B1A for ; Wed, 18 Apr 2001 14:13:00 -0300 (EST) Received: (qmail 3145 invoked by uid 0); 18 Apr 2001 17:12:59 -0000 Received: from duckman.distro.conectiva (root@10.0.17.2) by burns.conectiva with SMTP; 18 Apr 2001 17:12:59 -0000 Received: from localhost (riel@localhost) by duckman.distro.conectiva (8.11.3/8.11.3) with ESMTP id f3IHCxe18216 for ; Wed, 18 Apr 2001 14:12:59 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Wed, 18 Apr 2001 14:12:59 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Subject: SMP in 2.4 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, better back out SMPng real fast, otherwise you'll get into a flamewar with Dennis again ;) Rik ---------- Forwarded message ---------- Date: Wed, 18 Apr 2001 11:08:22 -0400 From: Dennis To: linux-kernel@vger.kernel.org Subject: SMP in 2.4 Does 2.4 have something similar to spl levels or does it still require the ridiculous MS-DOSish spin-locks to protect every bit of code? DB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 10:15:39 2001 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 D423337B423; Wed, 18 Apr 2001 10:15:36 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3IHFRU40679; Wed, 18 Apr 2001 19:15:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Robert Watson , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: Your message of "Wed, 18 Apr 2001 10:02:04 PDT." <200104181702.f3IH24s23282@earth.backplane.com> Date: Wed, 18 Apr 2001 19:15:27 +0200 Message-ID: <40677.987614127@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104181702.f3IH24s23282@earth.backplane.com>, Matt Dillon writes: > If this will get rid of or clean up the specfs garbage, then I'm all > for it. I would love to see a 'clean' fileops based device interface. specfs, aliased vnodes, you name it... I think the aliased vnodes is the single most strong argument of them all for doing this... -- 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 Apr 18 10:25:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 75EAD37B423 for ; Wed, 18 Apr 2001 10:25:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 4067 invoked by uid 666); 18 Apr 2001 17:27:57 -0000 Received: from i192-224.nv.iinet.net.au (HELO elischer.org) (203.59.192.224) by mail.m.iinet.net.au with SMTP; 18 Apr 2001 17:27:57 -0000 Message-ID: <3ADDCDCA.86D1B3BE@elischer.org> Date: Wed, 18 Apr 2001 10:24:26 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance References: <38778.987605692@critter> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You can mmap() devices and you can mmap files.. you cannot mmap FIFOs or sockets. for this reason I think that devices are still well represented by vnodes. If we merged vnodes and vm objects, then if devices were not vnodes, how would you represent a vm area that maps a device? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 10:27:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 891B637B423 for ; Wed, 18 Apr 2001 10:27:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 4084 invoked by uid 666); 18 Apr 2001 17:30:11 -0000 Received: from i192-224.nv.iinet.net.au (HELO elischer.org) (203.59.192.224) by mail.m.iinet.net.au with SMTP; 18 Apr 2001 17:30:11 -0000 Message-ID: <3ADDCE50.132B9F5D@elischer.org> Date: Wed, 18 Apr 2001 10:26:40 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Robert Watson Cc: Poul-Henning Kamp , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > > On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > As I indicated in my follow-up mail, the statement about seeking was > incorrect, that is a property of the open file structure; I believe the > remainder still holds true. When was the last time you tried mmap'ing or > seeking on the socket? A socket represents a buffered data stream which > does not allow arbitrary read/write operations at arbitrary offsets. Actually there have been times when I did want to mmap a datastream.. I think a datastream mapped into a user buffer-space is one of the possible 0-copy methods people sometimes mention. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 10:31:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id E707D37B422 for ; Wed, 18 Apr 2001 10:31:12 -0700 (PDT) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 87EEE59217; Wed, 18 Apr 2001 12:31:12 -0500 (CDT) Date: Wed, 18 Apr 2001 12:31:12 -0500 From: "Michael C . Wu" To: Rik van Riel Cc: freebsd-hackers@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: SMP in 2.4 (fwd) Message-ID: <20010418123112.A9822@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , Rik van Riel , freebsd-hackers@freebsd.org, linux-kernel@vger.kernel.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from riel@conectiva.com.br on Wed, Apr 18, 2001 at 02:12:59PM -0300 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 18, 2001 at 02:12:59PM -0300, Rik van Riel scribbled: | Hi, | | better back out SMPng real fast, otherwise you'll get into a | flamewar with Dennis again ;) | | Riki What? You mean we cannot share development and progress? :) If FreeBSD can't contribute anything else, we will contribute some trolls. Deep humble apologies for troll migration Michael | ---------- Forwarded message ---------- | Date: Wed, 18 Apr 2001 11:08:22 -0400 | From: Dennis | To: linux-kernel@vger.kernel.org | Subject: SMP in 2.4 | | Does 2.4 have something similar to spl levels or does it still require the | ridiculous MS-DOSish spin-locks to protect every bit of code? | | DB | | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to majordomo@vger.kernel.org | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/ | | | To Unsubscribe: send mail to majordomo@FreeBSD.org | with "unsubscribe freebsd-hackers" in the body of the message -- +-----------------------------------------------------------+ | keichii@iteration.net | keichii@freebsd.org | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +-----------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 10:56:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 8130E37B424 for ; Wed, 18 Apr 2001 10:56:12 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id NAA06547; Wed, 18 Apr 2001 13:56:04 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.2.1.0.20010418131202.03d0a280@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 18 Apr 2001 13:17:03 -0400 To: Rik van Riel , From: Dennis Subject: Re: SMP in 2.4 (fwd) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:12 PM 04/18/2001, Rik van Riel wrote: >Hi, > >better back out SMPng real fast, otherwise you'll get into a >flamewar with Dennis again ;) I just fear that "ng" will have the same negative connotations that "NT" did. DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 10:56:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0960337B423; Wed, 18 Apr 2001 10:56:34 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3IHu1D25098; Wed, 18 Apr 2001 10:56:01 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Apr 2001 10:56:01 -0700 (PDT) From: Matt Dillon Message-Id: <200104181756.f3IHu1D25098@earth.backplane.com> To: Julian Elischer Cc: Poul-Henning Kamp , Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <38778.987605692@critter> <3ADDCDCA.86D1B3BE@elischer.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :You can mmap() devices and you can mmap files.. : :you cannot mmap FIFOs or sockets. : :for this reason I think that devices are still well represented by :vnodes. If we merged vnodes and vm objects, :then if devices were not vnodes, how would you represent :a vm area that maps a device? : :-- : __--_|\ Julian Elischer I think the crux of the issue here is that most devices just don't need the baggage of a vnode and many don't need the baggage of a VM object except possibly for mmap(). A fileops interface would be the cleanest way to implement a wide range of devices. Lets compare our various function dispatch structures. It's quite obvious to me that we can merge cdevsw and fileops and remove all vnode references from most of our devices. Ok, maybe not /dev/tty... but most of the rest surely! We would also want to have an optional vnode pointer in the fileops (like we do now) which 'enables' the additional VOP operations on that file descriptor (in this case the fileops for read, write, etc... would point to VOP wrappers like they do now), and of course we would need an opaque pointer for use by the fileops (devices would most likely load their cdev reference into it). cdevsw fileops vfsops VOPs OPEN X - - X CLOSE X X - X READ X X - X WRITE X X - X IOCTL X X - - POLL X X - X MMAP X - - X STRATEGY X - - X DUMP X - - - KQFILTER - X - X STAT - X - - NAME X - - - MAJ X - - - PSIZE X - - - FLAGS X - - - BMAJ X - - - ADVLOCK - - - X BWRITE - - - X FSYNC - - - X ISLOCKED - - - X LEASE - - - X LOCK - - - X PATHCONF - - - X READLINK - - - X REALLOCBLKS - - - X REVOKE - - - X UNLOCK - - - X BMAP - - - X PRINT - - - X BALLOC - - - X GETPAGES - - - X PUTPAGES - - - X FREEBLKS - - - X GETACL - - - X SETACL - - - X ACLCHECK - - - X GETEXTATTR - - - X SETEXTATTR - - - X LOOKUP - - - X CACHEDLOOKUP - - - X CREATE - - - X WHITEOUT - - - X MKNOD - - - X ACCESS - - - X GETATTR - - - X SETATTR - - - X REMOVE - - - X LINK - - - X RENAME - - - X MKDIR - - - X RMDIR - - - X SYMLINK - - - X READDIR - - - X INACTIVE - - - X RECLAIM - - - X MOUNT - - X - START - - X - UNMOUNT - - X - ROOT - - X - QUOTACTL - - X - STATFS - - X - SYNC - - X - VGET - - X - FHTOVP - - X - CHECKEXP - - X - VPTOFH - - X - INIT - - X - UNINIT - - X - EXTATTRCTL - - X - -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 10:57:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 88D1A37B42C for ; Wed, 18 Apr 2001 10:57:19 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 4136 invoked by uid 666); 18 Apr 2001 18:00:06 -0000 Received: from i192-224.nv.iinet.net.au (HELO elischer.org) (203.59.192.224) by mail.m.iinet.net.au with SMTP; 18 Apr 2001 18:00:06 -0000 Message-ID: <3ADDD553.46BF216D@elischer.org> Date: Wed, 18 Apr 2001 10:56:35 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Matt Dillon , Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <40677.987614127@critter> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <200104181702.f3IH24s23282@earth.backplane.com>, Matt Dillon writes: > > If this will get rid of or clean up the specfs garbage, then I'm all > > for it. I would love to see a 'clean' fileops based device interface. > > specfs, aliased vnodes, you name it... > > I think the aliased vnodes is the single most strong argument of them > all for doing this... Great. Then we have aliased file pointers... that's not a great improvement.. You'd still have to have 'per instance' storage somewhere, so that the openned devices could have different permissions, and still have them point to common data. so you still need aliases, except now it's not a vnode being aliased but some other structure. > > -- > 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. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11: 9:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 62C4237B50B for ; Wed, 18 Apr 2001 11:09:41 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3II9kf06894; Wed, 18 Apr 2001 14:09:46 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Apr 2001 14:09:46 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: Poul-Henning Kamp , Matt Dillon , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: <3ADDD553.46BF216D@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Julian Elischer wrote: > Poul-Henning Kamp wrote: > > > > In message <200104181702.f3IH24s23282@earth.backplane.com>, Matt Dillon writes: > > > If this will get rid of or clean up the specfs garbage, then I'm all > > > for it. I would love to see a 'clean' fileops based device interface. > > > > specfs, aliased vnodes, you name it... > > > > I think the aliased vnodes is the single most strong argument of them > > all for doing this... > > Great. Then we have aliased file pointers... that's not a great > improvement.. > > You'd still have to have 'per instance' storage somewhere, so that the > openned devices could have different permissions, and still have them > point to common data. so you still need aliases, except now it's not a > vnode being aliased but some other structure. As I justed stated in a private e-mail to Matt, I'm not opposed to the idea of promoting devices to a first-class object (i.e., equivilent to vnodes, rather than below vnodes) in FreeBSD, I just want to approach this very cautiously, as there's a lot of obscure behavior in this area, and a lot of portability concerns regarding the obscure behavior. In particular, the "special case" of ttys is a very important special case -- operations such as revoke() must continue to work. With device operations currently being pushed through VFS, VFS becomes a possible mediation point for those operations, allowing "VFS magic" to be used on devices. If we remove VFS from the call stack, we lose that capability. Poul-Henning has successfully argued that this has a number of good implications, but we need to make sure that the functionality lost there doesn't out-weight the good bits. One way to look at this disagreement might be the following: some people feel that devices are simply evil, and not files, and shouldn't try to act like them. Others feel that, modulo ioctl, we really can make devices look like files, and should do that. The observation I tried to make in an earlier e-mail was that it might be possible to accept the world-view that "devices aren't files" by mapping some devices into a better abstraction, such as the socket "data stream" concept, while still making use of current abstractions. For example, using read() on /dev/audit sucks, since what comes out of /dev/audit is a set of discrete records. I'd rather use recv(), which has far superior semantics, since this is a record-oriented data stream. The same goes for kernel log messages, which on a discrete message-oriented stream could essentially become standard syslog messages, rather than treating it as a text buffer with character pointers. This would allow wrap-around to be handled much more cleanly, by simply dropping records off one end of the record chain, rather than severing lines and ending up with the current /dev/console abomination (send too much to /dev/console -- i.e., single user mode, and dmesg becomes useless). I won't claim that moving to the slightly more abstracted viewpoint I proposed earlier is the way to go, just that it's worth keeping in mind. Maybe we should just throw up our hands and say "devices are devices, screw files" -- this decision was made with NFS, and dramatically simplifies the problem space. 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 Wed Apr 18 11:11:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 16DBD37B423; Wed, 18 Apr 2001 11:11:53 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3IIBJp25644; Wed, 18 Apr 2001 11:11:19 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Apr 2001 11:11:19 -0700 (PDT) From: Matt Dillon Message-Id: <200104181811.f3IIBJp25644@earth.backplane.com> To: Julian Elischer Cc: Poul-Henning Kamp , Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <40677.987614127@critter> <3ADDD553.46BF216D@elischer.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Great. Then we have aliased file pointers... :that's not a great improvement.. : :You'd still have to have 'per instance' storage somewhere, :so that the openned devices could have different permissions, and still :have them point to common data. so you still need :aliases, except now it's not a vnode being aliased but some :other structure. VNodes should never have been aliased in the first place, IMHO. We have to deal with certain special cases, like mmap'ing /dev/zero, but that is a minor issue I think. Actually, all this talk does imply that VM objects should be independant of vnodes. Devices may need to mmap (requiring a VM object), but don't need all the baggage of a vnode. Julian is absolutely correct there. We do need to guarentee locking order, which means that all I/O operations should be consistent. If a device or vnode is mmap()able, then all read, write, and truncation(/extention) ops *should* run through the VM object first: read/write/truncate fileops -> [VM object] -> device read/write/truncate fileops -> [VM object] -> vnode Relative to Poul's last message, this would require not only adding MMAP to the fileops, but also adding FTRUNCATE to the fileops. Not a big deal! If a device or file is not mmap()able, then the VM object would not exist. You wouldn't get any caching, either, in that case, unless the device implemented the caching natively. If a device or file can be mmap()'d, then the VM Object acts as the cache layer for the object. We would in fact be able to remove nearly *ALL* the caching crap from *ALL* the filesystem code. Filesystem code would be responsible for low level I/O operations and meta ops (VOPs) only and not be responsible for any caching of file data. The filesystem would still potentially be responsible for caching things like bitmaps and such, but it could use a struct file for the backing device and get it for free (the backing device is mmapable and thus would have a VM Object layer, so you get the bitmap caching for free). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11:15:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id 8532F37B42C for ; Wed, 18 Apr 2001 11:15:24 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0933F66F19; Wed, 18 Apr 2001 11:15:23 -0700 (PDT) Date: Wed, 18 Apr 2001 11:15:23 -0700 From: Kris Kennaway To: Dennis Cc: Rik van Riel , freebsd-hackers@FreeBSD.ORG Subject: Re: SMP in 2.4 (fwd) Message-ID: <20010418111523.B35813@xor.obsecurity.org> References: <5.0.2.1.0.20010418131202.03d0a280@mail.etinc.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.0.20010418131202.03d0a280@mail.etinc.com>; from dennis@etinc.com on Wed, Apr 18, 2001 at 01:17:03PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2001 at 01:17:03PM -0400, Dennis wrote: > At 01:12 PM 04/18/2001, Rik van Riel wrote: > >Hi, > > > >better back out SMPng real fast, otherwise you'll get into a > >flamewar with Dennis again ;) >=20 > I just fear that "ng" will have the same negative connotations that "NT" = did. Feel free to test it and contribute your bug reports to the developers. We make -current available for this reason, you know.. Kris --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE63dm7Wry0BWjoQKURAimrAKCTkrfL9I1b9eXg16RcrL+n6bpGTwCg/hdS PF9o5rSFc7Yi9dafKFZoA4M= =+tpT -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11:22: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3]) by hub.freebsd.org (Postfix) with ESMTP id 0796C37B440 for ; Wed, 18 Apr 2001 11:22:00 -0700 (PDT) (envelope-from janb@cs.utep.edu) Received: from gecko (gecko [129.108.5.51]) by cs.utep.edu (8.11.3/8.11.3) with ESMTP id f3IILc022547; Wed, 18 Apr 2001 12:21:38 -0600 (MDT) Date: Wed, 18 Apr 2001 12:21:38 -0600 (MDT) From: X-Sender: To: Kris Kennaway Cc: Subject: Re: SMP in 2.4 (fwd) In-Reply-To: <20010418111523.B35813@xor.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Feel free to test it and contribute your bug reports to the > developers. We make -current available for this reason, you know.. > > Kris > Are there any sites or articles anybody knows of that desribe the differences between the 'SMPnow' and SMPng? In other words, what changes are there to ng? Thank you, JAn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11:23:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BFD2F37B43E for ; Wed, 18 Apr 2001 11:23:03 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3IINJf07135; Wed, 18 Apr 2001 14:23:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Apr 2001 14:23:19 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Dillon Cc: Julian Elischer , Poul-Henning Kamp , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: <200104181811.f3IIBJp25644@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Matt Dillon wrote: > If a device or file can be mmap()'d, then the VM Object acts as the > cache layer for the object. We would in fact be able to remove nearly > *ALL* the caching crap from *ALL* the filesystem code. Filesystem > code would be responsible for low level I/O operations and meta ops > (VOPs) only and not be responsible for any caching of file data. The > filesystem would still potentially be responsible for caching things > like bitmaps and such, but it could use a struct file for the backing > device and get it for free (the backing device is mmapable and thus > would have a VM Object layer, so you get the bitmap caching for free). Does this give you a cache coherence problem if the file system itself invokes data writes on files? Consider the UFS quota and extended attribute cases: here, the file system will invoke VOP_WRITE() on its vnodes to avoid understanding file system internals, so you can have such operations shared across file systems using UFS. If there is caching happening above VOP_WRITE(), will changes get propagated up the stack? Or does VOP_WRITE() change so that it talks to the memory object which then talks to VOP_REALLYWRITE()? Also, what implications does this have for security-oriented revocation? Memory mapping has always been a problem for revocation, but a number of interesting pieces of work have been done wherein access to a file is revoked resulting in EPERM being returned from future reads. In fact, I believe Secure Computing even contracted with BSDI to have support for some sort of virtual memory revocation service to get written -- in MAC environments, a label change on a file can result in future operations failing. Many third party security extensions on various platforms implement some sort of revocation service -- while it hasn't been part of the base OS in many cases, this is still a relevant audience. Also, however this is implemented, it would be nice to consider supporting stateful access to devices: i.e., dev_open() returns a state reference that is fed into future operations, so that pseudo-devices emulating multi-instance devices from other platforms can operate correctly. In my mind, for this to work with file descriptor passing, either the open file record needs to hold the state, and be passed into operations (this is what Linux does -- all file system operations accept a open file entry pointer, allowing vmmon, for example, to determine which session is in use), or we need a more general state management technique. In any case, one thing this means is that if operations are pushed through a virtual memory object, different "instances" must have different objects... I may be off-base on some points here based on a lack of expertise on the device and vm sides, but my feeling is that there are a lot of implications to this type of change, and we want to be careful not to preclude a number of potential future development directions, especially when it comes to security work and emulation. 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 Wed Apr 18 11:31:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id D74FA37B424 for ; Wed, 18 Apr 2001 11:31:16 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8277866D8B; Wed, 18 Apr 2001 11:31:16 -0700 (PDT) Date: Wed, 18 Apr 2001 11:31:16 -0700 From: Kris Kennaway To: janb@cs.utep.edu Cc: Kris Kennaway , freebsd-hackers@FreeBSD.ORG Subject: Re: SMP in 2.4 (fwd) Message-ID: <20010418113116.C36295@xor.obsecurity.org> References: <20010418111523.B35813@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from janb@cs.utep.edu on Wed, Apr 18, 2001 at 12:21:38PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --nmemrqcdn5VTmUEE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 18, 2001 at 12:21:38PM -0600, janb@cs.utep.edu wrote: > > Feel free to test it and contribute your bug reports to the > > developers. We make -current available for this reason, you know.. > > > > Kris > > > Are there any sites or articles anybody knows of that desribe the > differences between the 'SMPnow' and SMPng? In other words, what changes > are there to ng? Yes; see the project page on the website or check the status reports posted to -smp. Kris --nmemrqcdn5VTmUEE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE63d1zWry0BWjoQKURAl88AKC9Mp1Qop6/60bvEkn4aGTZ0Z9TdACgoI09 Y4K1BqFeGC6mA+WkohARQ5Q= =csYF -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11:35:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from www.mdres.com (www.mdres.com [209.180.205.201]) by hub.freebsd.org (Postfix) with ESMTP id 734FF37B424; Wed, 18 Apr 2001 11:35:25 -0700 (PDT) (envelope-from list-owner@mdres.com) Received: (from petidomo@localhost) by www.mdres.com (8.9.3/8.9.3) id JAA12674; Wed, 18 Apr 2001 09:15:44 -0700 X-Authentication-Warning: www.mdres.com: petidomo set sender to list-owner@mdres.com using -f Received: from mktg ([209.180.205.202]) by www.mdres.com (8.9.3/8.9.3) with SMTP id JAA12670 for ; Wed, 18 Apr 2001 09:15:44 -0700 From: "Hamilton Global Management" To: Subject: New CD-ROM Atlas of Russia - all oblasts, krays, and republics Date: Wed, 18 Apr 2001 10:16:12 -0700 Message-ID: Reply-To: mktg@mdres.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Colleague, Subject: New CD-ROM Atlas of Russia - all oblasts, krays, and republics We have recently acquired a new, unique CD-ROM atlas of the Russian Federation. The atlas displays highly detailed maps of all oblasts, krays, and republics. Visible details include cities, towns, and villages; roads and highways; pipelines; power lines; railroads; canals; forests; bodies of water; mountains; much more. Population figures are also shown for most populated places. Additional details are available for many map objects - e.g., road coverings, route names, as well as specifics about bodies of water and forest cover. Map scales range from 1:200000 to 1:1000000. All the maps show longitude and latitude for any location or object. The atlas uses vector maps based on WGS-84 and Krasovsky systems. We invite you to see sample maps and to get additional information at our web site: http://www.mdres.com/AtlasCatalog/ The CD-ROM atlas is in stock and available for immediate shipment from the USA. It is priced at $165.00 US + $6.00 shipping and handling. Please feel free to send us an e-mail or call if you have any questions. Our customers have previously included major libraries, map centers, universities, international and national agencies, and individuals from around the world. Sincerely, David C. Andresen Vice-President P.S. This e-mail is being sent to you as a person interested in atlases and maps. If you do not wish to receive future e-mails about our map products from Russia, please let us know by return e-mail, and we will remove your e-mail address from our database. Please place the word "Remove" in the message subject box and indicate in the message body the precise e-mail address or addresses you wish us to remove. We do not share our databases with other organi- zations of any type. -------------------------------------- Hamilton Global Management, Ltd. 8103 104th St., S.W. Lakewood, WA 98498 Tel. (253) 588-4149 Fax: (253) 588-4366 E-mail: mktg@mdres.com Web: http://www.mdres.com/AtlasCatalog/ -------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11:42:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 8321E37B423; Wed, 18 Apr 2001 11:42:09 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3IIg9D38399; Wed, 18 Apr 2001 11:42:09 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Apr 2001 11:42:09 -0700 (PDT) From: Matt Dillon Message-Id: <200104181842.f3IIg9D38399@earth.backplane.com> To: Robert Watson Cc: Julian Elischer , Poul-Henning Kamp , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Does this give you a cache coherence problem if the file system itself :invokes data writes on files? Consider the UFS quota and extended :attribute cases: here, the file system will invoke VOP_WRITE() on its :vnodes to avoid understanding file system internals, so you can have such :operations shared across file systems using UFS. If there is caching :happening above VOP_WRITE(), will changes get propagated up the stack? Or :does VOP_WRITE() change so that it talks to the memory object which then :talks to VOP_REALLYWRITE()? There are a number of places where the kernel opens and then manipulates files with VOP calls. That's been a major eyesore, frankly. We would change those instances to open and manipulate files through struct file's (like it should have been done in the first place). :Also, what implications does this have for security-oriented revocation? :Memory mapping has always been a problem for revocation, but a number of :interesting pieces of work have been done wherein access to a file is I don't think there are any implications. Rather then scanning for a vnode we instead just scan for an opaque data pointer in the struct file. It might not be quite that trivial, but it wouldn't be difficult either. mmap is another matter, but certainly no more difficult then it would be with the current scheme. :Also, however this is implemented, it would be nice to consider supporting :stateful access to devices: i.e., dev_open() returns a state reference :that is fed into future operations, so that pseudo-devices emulating :multi-instance devices from other platforms can operate correctly. In my I was thinking more like allocating a struct file, filling it in with defaults, then passing it to dev_open() which would override the defaults as necessary. In otherwords, the open function manipulates the struct file and is otherwise completely opaque to the caller. :use), or we need a more general state management technique. In any case, :one thing this means is that if operations are pushed through a virtual :memory object, different "instances" must have different objects... If the fileops must handle mmap, then the VM object would be directly associated with the fileops. If a file has an associated vnode there might also be a VM object reference in the vnode (assuming we don't merge them), but it would be opaque to the rest of the system. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11:45:19 2001 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 DEE4D37B422; Wed, 18 Apr 2001 11:45:15 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3IIj4U42009; Wed, 18 Apr 2001 20:45:04 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: Your message of "Wed, 18 Apr 2001 10:24:26 PDT." <3ADDCDCA.86D1B3BE@elischer.org> Date: Wed, 18 Apr 2001 20:45:04 +0200 Message-ID: <42007.987619504@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3ADDCDCA.86D1B3BE@elischer.org>, Julian Elischer writes: >If we merged vnodes and vm objects, >then if devices were not vnodes, how would you represent >a vm area that maps a device? You would use a VM object of course, but it would be a special kind of VM object, just like today... -- 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 Apr 18 11:48:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by hub.freebsd.org (Postfix) with ESMTP id 2C7D137B423 for ; Wed, 18 Apr 2001 11:48:15 -0700 (PDT) (envelope-from K.J.Koster@kpn.com) Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id <2TM2CGK7>; Wed, 18 Apr 2001 20:48:13 +0100 Message-ID: <59063B5B4D98D311BC0D0001FA7E452205FD9B5D@l04.research.kpn.com> From: "Koster, K.J." To: 'Jonathan Lemon' Cc: hackers@FreeBSD.ORG Subject: RE: non-working fxp cards Date: Wed, 18 Apr 2001 20:48:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Jonathan, > > I would like anyone who has a fxp card which doesn't work with > the current driver to contact me in order to test out an alternate > driver. > I've (finally!) sat down with a few machines and my collection of fxp cards, only to find that the problem seems to have been fixed. I'm confused. %-) Before testing the alternate drivers I wanted to see the problem again, so I cvsupped to 4.3-RC2 about three hours ago. Plop in the cards, reboot and ... everything works fine. Ping, ftp chunky files, mount NFS. No errors. I have three more cards that I'd like to test, but they are in someone else's server at the moment and people in the lab are a little hard to get hold of at nine o'clock at night. |-) Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11:49:37 2001 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 DCD4E37B423; Wed, 18 Apr 2001 11:49:31 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3IInKU42321; Wed, 18 Apr 2001 20:49:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Julian Elischer , Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: Your message of "Wed, 18 Apr 2001 10:56:01 PDT." <200104181756.f3IHu1D25098@earth.backplane.com> Date: Wed, 18 Apr 2001 20:49:20 +0200 Message-ID: <42319.987619760@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104181756.f3IHu1D25098@earth.backplane.com>, Matt Dillon writes: > >:You can mmap() devices and you can mmap files.. >: >:you cannot mmap FIFOs or sockets. >: >:for this reason I think that devices are still well represented by >:vnodes. If we merged vnodes and vm objects, >:then if devices were not vnodes, how would you represent >:a vm area that maps a device? >: >:-- >: __--_|\ Julian Elischer > > I think the crux of the issue here is that most devices just don't > need the baggage of a vnode and many don't need the baggage of a VM > object except possibly for mmap(). A fileops interface would be the > cleanest way to implement a wide range of devices. > > Lets compare our various function dispatch structures. It's quite > obvious to me that we can merge cdevsw and fileops and remove all > vnode references from most of our devices. Ok, maybe not /dev/tty... > but most of the rest surely! We would also want to have an optional > vnode pointer in the fileops (like we do now) which 'enables' the > additional VOP operations on that file descriptor (in this case the > fileops for read, write, etc... would point to VOP wrappers like they > do now), and of course we would need an opaque pointer for use by > the fileops (devices would most likely load their cdev reference into > it). Right on. I think your table is wrong for "REVOKE", there is TTY magic in that. The fact that we have aliased vnodes for devices and for nothing else. The fact that all devices are handled by a magic filesystem (specfs) in the same "orphan" mode by all filesystems which support devices is another good reason. I think I'll kick back tonight and try to see what it actually takes to do it... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 11:53:35 2001 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 91CC937B424; Wed, 18 Apr 2001 11:53:30 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3IIrIU42364; Wed, 18 Apr 2001 20:53:18 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Julian Elischer , Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: Your message of "Wed, 18 Apr 2001 11:11:19 PDT." <200104181811.f3IIBJp25644@earth.backplane.com> Date: Wed, 18 Apr 2001 20:53:18 +0200 Message-ID: <42362.987619998@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104181811.f3IIBJp25644@earth.backplane.com>, Matt Dillon writes: > Actually, all this talk does imply that VM objects should be independant > of vnodes. Devices may need to mmap (requiring a VM object), but > don't need all the baggage of a vnode. Julian is absolutely correct > there. Well, you have other VM Objects which doesn't map to vnodes: swap backed anonymous objects for instance. > We do need to guarentee locking order, which means that all I/O > operations should be consistent. If a device or vnode is mmap()able, > then all read, write, and truncation(/extention) ops *should* run > through the VM object first: We guarantee that today my mapping the actual hardware and my having all read/writes be synchronouse. I remember at least one other UNIX which didn't make that guarantee. -- 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 Apr 18 11:58:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5CD2B37B422 for ; Wed, 18 Apr 2001 11:58:22 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3IIwKG01465; Wed, 18 Apr 2001 11:58:20 -0700 (PDT) Date: Wed, 18 Apr 2001 11:58:20 -0700 From: Alfred Perlstein To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Buffer emergence reserve Message-ID: <20010418115820.R976@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zzhang@cs.binghamton.edu on Wed, Apr 18, 2001 at 12:18:22PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Zhihui Zhang [010418 09:18] wrote: > > While looking at the code in vfs_bio.c, I notice the existence of low and > high free buffer counters. The comments say they are there to give some > special process like buf daemon access to emergence reserve. I just > don't get the reason for having this emergence reserve. Do we allocate > buffer in an interrupt environment? Do we need extra buffers in order to > free buffers? Please shed a light on this for me. Thanks. It's really a simple issue of: "sometimes to clean a buffer we need one or more buffers" Think of some random data block at the far end of a large file. If the indirect blocks aren't in memory you will need to bring them in to lookup the location of the buffer you're writing because buffers use logical offsets rather than physical ones. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 12: 3:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4855437B423; Wed, 18 Apr 2001 12:03:20 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3IJ3Bw40186; Wed, 18 Apr 2001 12:03:11 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Apr 2001 12:03:11 -0700 (PDT) From: Matt Dillon Message-Id: <200104181903.f3IJ3Bw40186@earth.backplane.com> To: Poul-Henning Kamp Cc: Julian Elischer , Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Proposed struct file (was Re: vm balance) References: <42007.987619504@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is all preliminary. The question is whether we can cover enough bases for this to be viable. Here is a proposed struct file. Make f_data opaque (or more opaque), add f_object, extend fileops (see next structure), Added f_vopflags to indicate the presence of a vnode in f_data, allowing extended filesystem ops (e.g. rename, remove, fchown, etc etc etc). struct file { LIST_ENTRY(file) f_list;/* list of active files */ short f_flag; /* see fcntl.h */ short f_type; /* descriptor type */ short f_vopflags; /* extended command set flags */ short f_FILLER2; /* (OLD) references from message queue */ struct ucred *f_cred; /* credentials associated with descriptor */ struct fileops *f_ops; /* FILE OPS */ int f_seqcount; /* (sequential heuristic) */ off_t f_nextoff; /* (sequential heuristic) */ off_t f_offset; /* seek position */ caddr_t f_data; /* opaque data (was vnode or socket) */ vm_object_t f_object; /* VM object if mmapable/cacheable, or NULL */ int f_count; /* reference count */ int f_msgcount; /* reference count from message queue */ (additional elements required to support devices, maybe just a dev_t reference or something like that. I dunno). }; Proposed fileops structure (shared): Remove ucred argument (obtain ucred from struct file), add additional functions. Add cached and uncached versions for fo_read() ... all users will use fo_read() but this way you can vector fo_read() to a generic VM Object layer which can then call fo_readnc() for anything that can't be handled by that layer. Same with fo_write(). Add additional flags to fo_writenc() to handle write behind, notification that a write occured in the VM layer (e.g. required by NFS), and other heuristic features. Note the lack of any reference to the buffer cache here. The filesystem is responsible for manipulation of the buffer cache if it wants to use the buffer cache. I've left the uio in for the moment since it's the most generic way of passing a buffer. struct fileops { int (*fo_read) (fp, uio, flags, p); /* cachable */ int (*fo_readnc) (fp, uio, flags, p); /* uncached */ int (*fo_write) (fp, uio, flags, p); /* cachable */ int (*fo_writenc) (fp, uio, flags, p); /* uncached */ int (*fo_ioctl) (fp, com, data, p); int (*fo_poll) (fp, events, p); int (*fo_kqfilter) (fp, knote); int (*fo_stat) (fp, stat, p); int (*fo_close) (fp, p); int (*fo_mmap) (fp, mmap_args); int (*fo_dump) ( ? ) ... others ... } *f_ops; -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 12: 5:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 94B8737B422; Wed, 18 Apr 2001 12:05:36 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3IJ5Z240374; Wed, 18 Apr 2001 12:05:35 -0700 (PDT) (envelope-from dillon) Date: Wed, 18 Apr 2001 12:05:35 -0700 (PDT) From: Matt Dillon Message-Id: <200104181905.f3IJ5Z240374@earth.backplane.com> To: Poul-Henning Kamp , Julian Elischer , Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: Proposed struct file (was Re: vm balance) References: <42007.987619504@critter> <200104181903.f3IJ3Bw40186@earth.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (oops, I forgot to add fo_truncate() to the fileops) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 12:22:59 2001 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 38A8637B42C for ; Wed, 18 Apr 2001 12:22:54 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f3IJMq503572; Wed, 18 Apr 2001 15:22:52 -0400 (EDT) Date: Wed, 18 Apr 2001 15:22:50 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@onyx To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Buffer emergence reserve In-Reply-To: <20010418115820.R976@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks! I am wondering whether the free VM page reserve has similar reason to exist, i.e., to clean dirty pages you need more pages. Probably not, that is for interrupt routines that can not block. On Wed, 18 Apr 2001, Alfred Perlstein wrote: > * Zhihui Zhang [010418 09:18] wrote: > > > > While looking at the code in vfs_bio.c, I notice the existence of low and > > high free buffer counters. The comments say they are there to give some > > special process like buf daemon access to emergence reserve. I just > > don't get the reason for having this emergence reserve. Do we allocate > > buffer in an interrupt environment? Do we need extra buffers in order to > > free buffers? Please shed a light on this for me. Thanks. > > It's really a simple issue of: > > "sometimes to clean a buffer we need one or more buffers" > > Think of some random data block at the far end of a large file. > > If the indirect blocks aren't in memory you will need to bring > them in to lookup the location of the buffer you're writing > because buffers use logical offsets rather than physical ones. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > Represent yourself, show up at BABUG http://www.babug.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 12:47:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id A1C6037B422 for ; Wed, 18 Apr 2001 12:47:39 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f3IJlYd82416; Wed, 18 Apr 2001 12:47:34 -0700 (PDT) Date: Wed, 18 Apr 2001 12:47:34 -0700 (PDT) From: Doug White To: Charles Sprickman Cc: Subject: Re: Shoutcast, high cpu, threads In-Reply-To: Message-ID: X-All-Your-Base: are belong to us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Apr 2001, Charles Sprickman wrote: > Hi, > > I'm running shoutcast on a 4.2R machine, and I'm finding that the > shoutcast server, when idle climbs up to around 90% cpu usage. Included > is a bit of back-and-forth with a shoutcast support person. Does sc_serv use select() in it's main loop? I've seen applications that use a zero timeout for select() and when they're idle the select() loop runs really fast. This certainly sucks for multiuser systems but for dedicated boxes it allows for great response time. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | 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 Wed Apr 18 12:51:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id ACA6237B424; Wed, 18 Apr 2001 12:51:19 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f3IJpHa82480; Wed, 18 Apr 2001 12:51:17 -0700 (PDT) Date: Wed, 18 Apr 2001 12:51:17 -0700 (PDT) From: Doug White To: John Baldwin Cc: Andrew Gallatin , , Mike Silbersack Subject: Re: x86-64 Hammer and IA64 Itainium In-Reply-To: Message-ID: X-All-Your-Base: are belong to us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, John Baldwin wrote: > Also, in case you aren't aware (this is not to you Drew, I know you know :)) > FreeBSD already has an ia64 port underway in -current. ia64, x86-64, ppc, > and a few others are on the radar scope of the FreeBSD developers. And at one point, the Project even had one or two emulator boxes, software and hardware, supplied by AMD. Where did those go? (Yes I know the emulator is ass-slow and a gigantic beast, but it does work, right?) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | 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 Wed Apr 18 12:58:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 6C15737B43C for ; Wed, 18 Apr 2001 12:58:09 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3IJvlG56529; Wed, 18 Apr 2001 12:57:47 -0700 (PDT) (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: Date: Wed, 18 Apr 2001 12:57:11 -0700 (PDT) From: John Baldwin To: Doug White Subject: Re: x86-64 Hammer and IA64 Itainium Cc: Mike Silbersack , freebsd-hackers@FreeBSD.org, Andrew Gallatin Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Apr-01 Doug White wrote: > On Wed, 18 Apr 2001, John Baldwin wrote: > >> Also, in case you aren't aware (this is not to you Drew, I know you know :)) >> FreeBSD already has an ia64 port underway in -current. ia64, x86-64, ppc, >> and a few others are on the radar scope of the FreeBSD developers. > > And at one point, the Project even had one or two emulator boxes, software > and hardware, supplied by AMD. Where did those go? They currently reside at the WC/BSDi/WR Concord office. O`Brien has played with the emulator and it is indeed very, very slow. He is already working on getting a better emulator out of AMD and has also made some contact with the tools people AFAIK. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Wed Apr 18 13:38:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from herbelot.dyndns.org (s014.dhcp212-24.cybercable.fr [212.198.24.14]) by hub.freebsd.org (Postfix) with ESMTP id 873A837B422; Wed, 18 Apr 2001 13:38:51 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id WAA28916; Wed, 18 Apr 2001 22:42:58 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3ADDFB59.A5F20D24@herbelot.com> Date: Wed, 18 Apr 2001 22:38:49 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: freebsd-hackers@FreeBSD.ORG Subject: AMD and SMP ? (was :Re: x86-64 Hammer and IA64 Itainium) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG BTW, is there any AMD SMP machine already running FreeBSD ? (my BP6 is getting old and tired, and I'd like to keep an SMP machine) -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 14:51: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0882A37B42C for ; Wed, 18 Apr 2001 14:50:55 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3ILogG59972; Wed, 18 Apr 2001 14:50:42 -0700 (PDT) (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: <3ADDFB59.A5F20D24@herbelot.com> Date: Wed, 18 Apr 2001 14:50:06 -0700 (PDT) From: John Baldwin To: Thierry Herbelot Subject: RE: AMD and SMP ? (was :Re: x86-64 Hammer and IA64 Itainium) Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Apr-01 Thierry Herbelot wrote: > BTW, is there any AMD SMP machine already running FreeBSD ? (my BP6 is > getting old and tired, and I'd like to keep an SMP machine) Not that I'm aware of. I would love to get my hands on a dual Athlon to get it working if I could get docs and/or a machine out of AMD to do it with. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Wed Apr 18 15:50:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 1D02537B422 for ; Wed, 18 Apr 2001 15:50:38 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id SAA08066 for ; Wed, 18 Apr 2001 18:51:08 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.2.1.0.20010418181113.0427c010@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 18 Apr 2001 18:12:21 -0400 To: hackers@FreeBSD.ORG From: Dennis Subject: Re: SMP in 2.4 (fwd) In-Reply-To: References: <20010418111523.B35813@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 02:21 PM 04/18/2001, you wrote: > > Feel free to test it and contribute your bug reports to the > > developers. We make -current available for this reason, you know.. > > > > Kris > > >Are there any sites or articles anybody knows of that desribe the >differences between the 'SMPnow' and SMPng? In other words, what changes >are there to ng? Is the source tree for 5.0 posted anywhere, or a spec on the driver requirements? I only see tarball chunks in the snapshots. Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 16: 4: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id E518637B422 for ; Wed, 18 Apr 2001 16:04:00 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id TAA08136; Wed, 18 Apr 2001 19:04:14 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.2.1.0.20010418174822.03b13910@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 18 Apr 2001 18:25:25 -0400 To: Kris Kennaway From: Dennis Subject: Re: SMP in 2.4 (fwd) Cc: Rik van Riel , freebsd-hackers@FreeBSD.ORG In-Reply-To: <20010418111523.B35813@xor.obsecurity.org> References: <5.0.2.1.0.20010418131202.03d0a280@mail.etinc.com> <5.0.2.1.0.20010418131202.03d0a280@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 02:15 PM 04/18/2001, Kris Kennaway wrote: >On Wed, Apr 18, 2001 at 01:17:03PM -0400, Dennis wrote: > > At 01:12 PM 04/18/2001, Rik van Riel wrote: > > >Hi, > > > > > >better back out SMPng real fast, otherwise you'll get into a > > >flamewar with Dennis again ;) > > > > I just fear that "ng" will have the same negative connotations that > "NT" did. > >Feel free to test it and contribute your bug reports to the >developers. We make -current available for this reason, you know.. > >Kris No thanks. I treasure these tranquil days without endless race conditions, lockups and undebuggable code. I see that the more stressful days approach. I'll stick with single processor and count on my buddies at intel to raise the bar by 75% every year without having to introduce the instability that SMPng will undoubted suffer with for long periods. A 1.5Ghz processor can outperform 2 fully saturated PCI buses, so its not going to help much in the networking world, which is where I live. Processing power is already exceeding the busses capabilities. Its nice to have a processor for user space and one for kernel/interrupt space, but going beyond that to seriously adulterate the OS to squeeze a few extra cycles in a world where processors are jumping 20% in speed every few months seems counterproductive. You dont put 2 engines in a car to make it faster, you get a faster engine. It seems that there is a lack of foresight here...you're losing a year or more of engineering time and before SMPng is stablilized the IA-64 will be out and most multiprocessor applications will be rushing to move over to that. DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 16: 5:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id AB78D37B42C for ; Wed, 18 Apr 2001 16:05:09 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3IN4UG62178; Wed, 18 Apr 2001 16:04:30 -0700 (PDT) (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: <5.0.2.1.0.20010418181113.0427c010@mail.etinc.com> Date: Wed, 18 Apr 2001 16:03:55 -0700 (PDT) From: John Baldwin To: Dennis Subject: Re: SMP in 2.4 (fwd) Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Apr-01 Dennis wrote: > At 02:21 PM 04/18/2001, you wrote: >> > Feel free to test it and contribute your bug reports to the >> > developers. We make -current available for this reason, you know.. >> > >> > Kris >> > >>Are there any sites or articles anybody knows of that desribe the >>differences between the 'SMPnow' and SMPng? In other words, what changes >>are there to ng? > > Is the source tree for 5.0 posted anywhere, or a spec on the driver > requirements? I only see tarball chunks in the snapshots. You can always use cvsup, ctm, etc. as described in the handbook. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Wed Apr 18 16: 7: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9E75237B423 for ; Wed, 18 Apr 2001 16:07:03 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA06536 for ; Wed, 18 Apr 2001 16:07:02 -0700 Date: Wed, 18 Apr 2001 16:07:02 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: freebsd-hackers@FreeBSD.ORG Subject: Re: SMP in 2.4 (fwd) In-Reply-To: <5.0.2.1.0.20010418174822.03b13910@mail.etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It seems that there is a lack of foresight here...you're losing a year or > more of engineering time and before SMPng is stablilized the IA-64 will be > out and most multiprocessor applications will be rushing to move over to that. > Yup, one could say that. But because this is an effort from volunteers, nobody's stock is losing value. I think Jordan pointed out a while back that nothing we're doing here, or in Linux for that matter, is all that new. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 16: 9:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9E36D37B424 for ; Wed, 18 Apr 2001 16:09:55 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3IN9f109752; Wed, 18 Apr 2001 16:09:41 -0700 (PDT) Date: Wed, 18 Apr 2001 16:09:41 -0700 From: Alfred Perlstein To: Dennis Cc: Kris Kennaway , Rik van Riel , freebsd-hackers@FreeBSD.ORG Subject: Re: SMP in 2.4 (fwd) Message-ID: <20010418160941.X976@fw.wintelcom.net> References: <5.0.2.1.0.20010418131202.03d0a280@mail.etinc.com> <20010418111523.B35813@xor.obsecurity.org> <5.0.2.1.0.20010418174822.03b13910@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.0.20010418174822.03b13910@mail.etinc.com>; from dennis@etinc.com on Wed, Apr 18, 2001 at 06:25:25PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dennis [010418 16:04] wrote: > At 02:15 PM 04/18/2001, Kris Kennaway wrote: > >On Wed, Apr 18, 2001 at 01:17:03PM -0400, Dennis wrote: > > > At 01:12 PM 04/18/2001, Rik van Riel wrote: > > > >Hi, > > > > > > > >better back out SMPng real fast, otherwise you'll get into a > > > >flamewar with Dennis again ;) > > > > > > I just fear that "ng" will have the same negative connotations that > > "NT" did. > > > >Feel free to test it and contribute your bug reports to the > >developers. We make -current available for this reason, you know.. > > > >Kris > > No thanks. I treasure these tranquil days without endless race conditions, > lockups and undebuggable code. I see that the more stressful days approach. > > I'll stick with single processor and count on my buddies at intel to raise > the bar by 75% every year without having to introduce the instability that > SMPng will undoubted suffer with for long periods. > > A 1.5Ghz processor can outperform 2 fully saturated PCI buses, so its not > going to help much in the networking world, which is where I live. > Processing power is already exceeding the busses capabilities. > > Its nice to have a processor for user space and one for kernel/interrupt > space, but going beyond that to seriously adulterate the OS to squeeze a > few extra cycles in a world where processors are jumping 20% in speed every > few months seems counterproductive. You dont put 2 engines in a car to make > it faster, you get a faster engine. > > It seems that there is a lack of foresight here...you're losing a year or > more of engineering time and before SMPng is stablilized the IA-64 will be > out and most multiprocessor applications will be rushing to move over to that. I know that engaging you in conversation is a futile exercise but I'd like to point out that we've got our feet in both boats right now as well as some others that you don't mention. Ia64 is nearly working, we are taking the platform quite seriously. You think Intel isn't going to market dual/quad ia64 machines? -- -Alfred Perlstein - [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 17: 2: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id B1CD337B423 for ; Wed, 18 Apr 2001 17:02:04 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id UAA08424; Wed, 18 Apr 2001 20:02:21 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 18 Apr 2001 19:23:33 -0400 To: Alfred Perlstein From: Dennis Subject: Re: SMP in 2.4 (fwd) Cc: Kris Kennaway , Rik van Riel , freebsd-hackers@FreeBSD.ORG In-Reply-To: <20010418160941.X976@fw.wintelcom.net> References: <5.0.2.1.0.20010418174822.03b13910@mail.etinc.com> <5.0.2.1.0.20010418131202.03d0a280@mail.etinc.com> <20010418111523.B35813@xor.obsecurity.org> <5.0.2.1.0.20010418174822.03b13910@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > It seems that there is a lack of foresight here...you're losing a year or > > more of engineering time and before SMPng is stablilized the IA-64 will be > > out and most multiprocessor applications will be rushing to move over > to that. > >I know that engaging you in conversation is a futile exercise but >I'd like to point out that we've got our feet in both boats right >now as well as some others that you don't mention. >Ia64 is nearly working, we are taking the platform quite seriously. > >You think Intel isn't going to market dual/quad ia64 machines? Yes, but who'll need them? You say that "engaging me" is useless, yet you dont make a point that has anything to do with what i said. My question is, Is it worth it to tear apart the FreeBSD internals and to significantly adulterate the kernel proper with SMP-specifics to sqeeze some extra performance in the wake of the forthcoming performance boosts seems counterproductive. We dont program in assembler (much), because the extra performance isnt worth the effort. Im not saying that SMP should not be supported, only that making the OS and drivers more cumbersome for a small performance boost may be counterproductive in the long run. Db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 17:48:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from areilly.bpc-users.org (CPE-144-132-234-126.nsw.bigpond.net.au [144.132.234.126]) by hub.freebsd.org (Postfix) with SMTP id 89AE437B423 for ; Wed, 18 Apr 2001 17:48:32 -0700 (PDT) (envelope-from areilly@bigpond.net.au) Received: (qmail 9127 invoked by uid 1000); 19 Apr 2001 00:48:31 -0000 From: "Andrew Reilly" Date: Thu, 19 Apr 2001 10:48:31 +1000 To: Julian Elischer Cc: Robert Watson , Poul-Henning Kamp , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance Message-ID: <20010419104831.A8598@gurney.reilly.home> References: <3ADDCE50.132B9F5D@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ADDCE50.132B9F5D@elischer.org>; from julian@elischer.org on Wed, Apr 18, 2001 at 10:26:40AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 18, 2001 at 10:26:40AM -0700, Julian Elischer wrote: > Robert Watson wrote: > > > > On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > > > As I indicated in my follow-up mail, the statement about seeking was > > incorrect, that is a property of the open file structure; I believe the > > remainder still holds true. When was the last time you tried mmap'ing or > > seeking on the socket? A socket represents a buffered data stream which > > does not allow arbitrary read/write operations at arbitrary offsets. > > Actually there have been times when I did want to mmap a datastream.. > I think a datastream mapped into a user buffer-space is one of the > possible 0-copy methods people sometimes mention. Mmapped data streams: audio IO. There are probably others. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 17:56: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id DD53B37B424 for ; Wed, 18 Apr 2001 17:55:56 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f3J0upb60763 for ; Thu, 19 Apr 2001 01:56:51 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f3J0uI513245; Thu, 19 Apr 2001 01:56:18 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200104190056.f3J0uI513245@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: freebsd-hackers@FreeBSD.org Cc: Brian Somers Subject: Modules with INVARIANTS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Apr 2001 01:56:18 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Does anyone know of a clean way to have module builds detect that INVARIANTS is defined in opt_global.h ? -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 18:31:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay2.net.com (relay2.net.com [134.56.3.108]) by hub.freebsd.org (Postfix) with ESMTP id 070EA37B424 for ; Wed, 18 Apr 2001 18:31:33 -0700 (PDT) (envelope-from shankar_agarwal@net.com) Received: from unet.net.com (fremont-ns2.net.com [134.56.112.30]) by relay2.net.com (8.11.3/8.9.3) with ESMTP id f3J1VA616484 for ; Wed, 18 Apr 2001 18:31:10 -0700 (PDT) Received: from west-mail.net.com by unet.net.com (8.9.3/SMI-SVR4) id SAA18246; Wed, 18 Apr 2001 18:31:10 -0700 (PDT) Received: from net.com ([134.56.103.239]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA4997; Wed, 18 Apr 2001 18:32:34 -0700 Message-ID: <3ADE3FDB.E082BC69@net.com> Date: Wed, 18 Apr 2001 18:31:07 -0700 From: Shankar Agarwal Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 Cc: tech-kern@netbsd.org, bsd hackers Subject: Question regarding ifconfig. References: <3AB7A76B.2BCF5D6E@net.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, I have a doubt about the ifconfig file. when i am trying to configure or change ip address on the interface. The main calls setifaddr function which calls ioctl function with command as SIOCGIFADDR by the following lines ifr->ifr_addr.sa_family = afp->af_af; if (ioctl(s, afp->af_gifaddr, afp->af_ridreq) == 0) clearaddr = 1; Now i don't understand why the ioctl is called by SIOCGIFADDR when i am configuring an ip address on the interface. Moreover i believe that when ioctl returns successfully it returns 0 so the clearaddr will be set and later on the ip address will be deleted. Please help me out if i am interpreting it wrong as i am not able to assign an ip address to the interface in my ported code. Thanks Regards Shankar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 18:56:21 2001 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 05EF237B422 for ; Wed, 18 Apr 2001 18:56:19 -0700 (PDT) (envelope-from mwlucas@blackhelicopters.org) Received: (from mwlucas@localhost) by blackhelicopters.org (8.9.3/8.9.3) id VAA46724 for hackers@freebsd.org; Wed, 18 Apr 2001 21:56:10 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 18 Apr 2001 21:56:10 -0400 From: Michael Lucas To: hackers@freebsd.org Subject: thoughts on /etc/newsyslog.conf Message-ID: <20010418215610.A46691@blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, In writing an article on syslogd and newsyslog, I've noticed something intensely annoying about newsyslog.conf. FreeBSD supports three different formats for dates in newsyslog.conf: raw hours since last rotation, ISO 8601, and FreeBSD-specific week-day-month. Wouldn't it make sense to standardize on one or the other of ISO8601 or W-D-M for the default newsyslog.conf? All of the existing entries could easily be expressed in W-D-M. Or is there some particular reason why we must use both formats in the default file? I'll be happy to document it if that's the case. I'd rather not try to justify using different formats to a new user without such a reason, however. As someone writing documentation, I'd prefer W-D-M since it's easier to explain. :) I will even volunteer patches to make it consistent in whatever form is chosen -- although I suspect one of you real hackers could do it with your eyes closed, I feel obliged to offer. Thanks, ==ml -- Michael Lucas mwlucas@blackhelicopters.org http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 18:58:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id B5A3A37B43C; Wed, 18 Apr 2001 18:58:30 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 1E447287A6; Thu, 19 Apr 2001 08:38:16 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id BD03028769; Thu, 19 Apr 2001 08:38:16 +0700 (ALMST) Date: Thu, 19 Apr 2001 08:38:16 +0700 (ALMST) From: Boris Popov To: Poul-Henning Kamp Cc: Matt Dillon , Robert Watson , Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance In-Reply-To: <40677.987614127@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > In message <200104181702.f3IH24s23282@earth.backplane.com>, Matt Dillon writes: > > If this will get rid of or clean up the specfs garbage, then I'm all > > for it. I would love to see a 'clean' fileops based device interface. > > specfs, aliased vnodes, you name it... > > I think the aliased vnodes is the single most strong argument of them > all for doing this... I think that this can be (and already is) solved in the other way. Here is how I done it on my test system (quoted from the mail to Bruce Evans): --quote-start-- I'm working on this problem too, and these vop_lock/unlock in the spec_open/read/write vnops cause a real pain. Using a generic vnode stacking/layering mechanism (diffs will be published soon) I've reorganized the way how device vnodes are handled. Each device gets its own vnode of type VT_SPEC which is belongs to a hidden specfs mount. When any real filesystem tries to lookup vnode for a specific device via addaliasu(), addalias() just stacks filesystem vnode over specfs vnode: fs1/vnode1 fs1/vnode8 fs2/vnode1 | | | +-------+-----------------------+ | V specfs vnode Specfs vnode also can be used directly as root vnode for any mounted filesystem. Obviously, there is no need in the device aliases because device can be controlled only via single vnode. v_rdev field is also goes away from vnode structure and vn_todev() is the right way to get a pointer to underlying device. But there is a real problem with a locking/unlocking used by specfs. Eg, if specfs vnode's lock used as lock for an entire layer tree, then things will be totally broken because blocked spec_read() operation may unlock a different vnode which should be locked, and even more problems caused that the read lock is shared... Use of separate lock for each vnode partially solves the problem, but not completely emulates the old behavior for exclusive lock on open operation. For example if we call open(vn1) and it block, the second open(vn1) will stuck waiting for lock on vn1, while open(vn8) will work just fine. This problem is common for stacked filesystems and many papers avoid talking about it. The "right" solution is to have a "call stack", so an unlock operation can unlock only a single chain of the above vnodes, but I'm don't see the simple way to implement it for stacks containing more than two layers :( --quote-end-- Now, regarding to the new file operations structure: it is pretty obvious that most of the operations will resemble vnode operations. However, it is a misdesign of VFS to not allow a filesystem to track a per-file descriptor tracking for at least OPEN/CLOSE operations. It is also a pretty obvious that file operations (FOP) are just a layer above VOP operations. So, why not to do things right and add capability to the existing VFS to handle a per-file operations properly ? Of course, this will require more brain work, but results will be definitely better. Lets back to vnode/vm/file/devices: I think it is a mistake to rip out vnodes from devices. But I'm agree that vnode structure is too fat to be used in the more general way. If it is possible to cleanup it, then we can easily build any hierarchies we want: file1 file2 file3 | | | +-------+ | | | vnode1 vnode2 | | +---------------+ | device1 -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 19: 3:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id EC85137B424 for ; Wed, 18 Apr 2001 19:03:41 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id EEC8D28769; Thu, 19 Apr 2001 09:03:39 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id DF40F286FD; Thu, 19 Apr 2001 09:03:39 +0700 (ALMST) Date: Thu, 19 Apr 2001 09:03:39 +0700 (ALMST) From: Boris Popov To: Brian Somers Cc: freebsd-hackers@FreeBSD.org Subject: Re: Modules with INVARIANTS In-Reply-To: <200104190056.f3J0uI513245@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Apr 2001, Brian Somers wrote: > Does anyone know of a clean way to have module builds detect that > INVARIANTS is defined in opt_global.h ? Peter Wemm working on this. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 19:17:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.43.230.149]) by hub.freebsd.org (Postfix) with ESMTP id 5270D37B423 for ; Wed, 18 Apr 2001 19:17:18 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.3) with SMTP id f3J2F3p19734; Wed, 18 Apr 2001 22:15:03 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <003a01c0c876$52242310$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Michael Lucas" , References: <20010418215610.A46691@blackhelicopters.org> Subject: Re: thoughts on /etc/newsyslog.conf Date: Wed, 18 Apr 2001 22:13:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hello, > > In writing an article on syslogd and newsyslog, I've noticed something > intensely annoying about newsyslog.conf. > > FreeBSD supports three different formats for dates in newsyslog.conf: > raw hours since last rotation, ISO 8601, and FreeBSD-specific > week-day-month. > > Wouldn't it make sense to standardize on one or the other of ISO8601 > or W-D-M for the default newsyslog.conf? You need 'raw hours' format to support relative times, commonly used with size parameters to control the growth of web logs. (ie "Rotate when size > 10M or 6 hours from last rotate") You need ISO8601 to support rolling on fixed dates (1st of the month, etc.) You need 'W-D-M' format to support rolling on a weekly/monthly/daily basis. This can't be done using ISO8601 because ISO uses fixed dates. (How would you specify rotating every monday using ISO8601, when the date of every monday changes from month to month and year to year?) As a point of reference, cron's time/date parameters are functionally a combination of W-D-M and ISO8601. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 19:19: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 891D137B422 for ; Wed, 18 Apr 2001 19:18:56 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from surriel.ddts.net (1-193.cwb-adsl.brasiltelecom.net.br [200.193.160.193]) by netbank.com.br (Postfix) with ESMTP id B30BC4681A; Wed, 18 Apr 2001 23:19:57 -0300 (BRST) Received: from localhost (svhtlr@localhost [127.0.0.1]) by surriel.ddts.net (8.11.2/8.11.2) with ESMTP id f3J2H6402562; Wed, 18 Apr 2001 23:17:16 -0300 Date: Wed, 18 Apr 2001 23:17:06 -0300 (BRST) From: Rik van Riel X-Sender: riel@imladris.rielhome.conectiva To: Dennis Cc: Alfred Perlstein , Kris Kennaway , freebsd-hackers@FreeBSD.ORG Subject: Re: SMP in 2.4 (fwd) In-Reply-To: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Dennis wrote: > >You think Intel isn't going to market dual/quad ia64 machines? > > Yes, but who'll need them? If nobody needed them, what would be the point in SELLING them ? I know you don't trust our technical instinct, but you might at least consider the business instinct of companies like Intel, IBM or Unisys (who all sell big SMP systems). Besides, there are LOTS of people who need tomorrow's performance yesterday. There will always be a big market for overpowered, overpriced SMP systems... And as for the "but you can wait 2 years until UP is faster than today's SMP" doesn't quite work for eg. investment banking and stock funds. More computing power means better calculations, which means more money. And for folks like them, computing power is not measured in FLOPS, but in ACRES. And when you're talking 3 acres of computing power, you'd better have some decend density (ie. SMP in 2U rackmounted boxes, or something similarly suitable). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 19:40:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 0BB6637B422 for ; Wed, 18 Apr 2001 19:40:54 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 964B16ACB8; Thu, 19 Apr 2001 12:10:51 +0930 (CST) Date: Thu, 19 Apr 2001 12:10:51 +0930 From: Greg Lehey To: Rik van Riel Cc: Dennis , Alfred Perlstein , Kris Kennaway , freebsd-hackers@FreeBSD.ORG Subject: The future of multiprocessors (was: SMP in 2.4 (fwd)) Message-ID: <20010419121051.D72816@wantadilla.lemis.com> References: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from riel@conectiva.com.br on Wed, Apr 18, 2001 at 11:17:06PM -0300 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 18 April 2001 at 23:17:06 -0300, Rik van Riel wrote: > On Wed, 18 Apr 2001, Dennis wrote: > >>> You think Intel isn't going to market dual/quad ia64 machines? >> >> Yes, but who'll need them? > > If nobody needed them, what would be the point in SELLING > them ? That's never been an argument for a good salesperson. Think of selling refrigerators to Eskimos, or the small farmer with one cow who bought a milking machine and sold his cow to pay for it. > I know you don't trust our technical instinct, but you might > at least consider the business instinct of companies like > Intel, IBM or Unisys (who all sell big SMP systems). > > Besides, there are LOTS of people who need tomorrow's performance > yesterday. There will always be a big market for overpowered, > overpriced SMP systems... And, of course, a bigger market for high-powered, reasonably priced MP systems. Note that it's cheaper to buy an SMP Intel MB with two 750 MHz processors than it is to buy one with a 1.5 GHz processor. > And as for the "but you can wait 2 years until UP is faster than > today's SMP" doesn't quite work for eg. investment banking and stock > funds. More computing power means better calculations, which means > more money. And for folks like them, computing power is not measured > in FLOPS, but in ACRES. And when you're talking 3 acres of computing > power, you'd better have some decend density (ie. SMP in 2U > rackmounted boxes, or something similarly suitable). More to the point, the processors of the not-too-distant future will have multiple processors on the single die. Multiprocessors are here to stay. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 21:25:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D41D837B423 for ; Wed, 18 Apr 2001 21:25:18 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f3J4P4I27412; Wed, 18 Apr 2001 22:25:10 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104190425.f3J4P4I27412@harmony.village.org> To: "Vladimir B. Grebenschikov" Subject: Re: Idea about modules build Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Apr 2001 09:51:20 +0400." <200104160551.JAA01380@vbook.express.ru> References: <200104160551.JAA01380@vbook.express.ru> Date: Wed, 18 Apr 2001 22:23:49 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104160551.JAA01380@vbook.express.ru> "Vladimir B. Grebenschikov" writes: : May be it need to create some makefile variable like KERNEL_MODULES, : that can be defined in /etc/make.conf to limit list of modules : to build/install, it is not very good idea to spend a lot of : CPU time building modules, that never be used ? Been there done that in -current :-). It was too late to get into 4.3, but I'd like to MFC it after the release. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 21:25:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4B3B137B42C for ; Wed, 18 Apr 2001 21:25:31 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f3J4PUI27762; Wed, 18 Apr 2001 22:25:30 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104190425.f3J4PUI27762@harmony.village.org> To: hackers@FreeBSD.ORG Subject: Re: Idea about modules build Cc: "Vladimir B. Grebenschikov" In-reply-to: Your message of "Mon, 16 Apr 2001 00:09:54 PDT." <20010416000954.A59480@dragon.nuxi.com> References: <20010416000954.A59480@dragon.nuxi.com> <200104160551.JAA01380@vbook.express.ru> Date: Wed, 18 Apr 2001 22:24:15 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010416000954.A59480@dragon.nuxi.com> "David O'Brien" writes: : On Mon, Apr 16, 2001 at 09:51:20AM +0400, Vladimir B. Grebenschikov wrote: : > I have idea about modules build/install process: : : Warner (imp) was to commit this fuctionality to 5-current (and back port : to releng_4 after 4.3-RELEASE). I thought I committed this about two weeks ago. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 21:28:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id 5D28137B42C for ; Wed, 18 Apr 2001 21:28:18 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 39670 invoked from network); 19 Apr 2001 04:28:16 -0000 Received: from cx443070-b.vista1.sdca.home.com (HELO cx443070b) (24.0.36.170) by dualcpus.com with SMTP; 19 Apr 2001 04:28:16 -0000 Message-ID: <003501c0c889$930f44a0$aa240018@cx443070b> From: "Jeremiah Gowdy" To: "John Baldwin" , "Andrew Gallatin" Cc: , "Mike Silbersack" References: Subject: Re: x86-64 Hammer and IA64 Itainium Date: Wed, 18 Apr 2001 21:31:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Once that's done, it'll probably be a matter to send a clawhammer > > > system and a large box of cheese and crackers to the guys who did the > > > freebsd alpha port. If the architecture is actually so similar to x86, > > > it should only take them a few weekends. :) > > > > As one of the FreeBSD/alpha porters, I must point out that I don't > > know diddly-squat about low-level x86isms. I've never even written a > > line of x86 assembly. > > > > What's the timeframe that they're shooting for with this beast, anyway? > > The person you want to be asking is Peter Wemm, who has already looked at the > feasibility of a port from the kernel side for x86-64. He estimates one week > if we clean up the i386 pmap first so we can pull from it when doing the x86-64 > (or ka64) stuff. Sweet. > Also, in case you aren't aware (this is not to you Drew, I know you know :)) > FreeBSD already has an ia64 port underway in -current. ia64, x86-64, ppc, > and a few others are on the radar scope of the FreeBSD developers. Absolutely excellent. Who cares about the Itainium vs Hammer issue ? Let the industry sort it out as long as FreeBSD supports both :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 21:28:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 8237237B423 for ; Wed, 18 Apr 2001 21:28:39 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 6712 invoked by uid 666); 19 Apr 2001 04:31:27 -0000 Received: from i182-041.nv.iinet.net.au (HELO elischer.org) (203.59.182.41) by mail.m.iinet.net.au with SMTP; 19 Apr 2001 04:31:27 -0000 Message-ID: <3ADE6949.C07B46D2@elischer.org> Date: Wed, 18 Apr 2001 21:27:53 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Matt Dillon , Robert Watson , Kirk McKusick , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: <42362.987619998@critter> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <200104181811.f3IIBJp25644@earth.backplane.com>, Matt Dillon writes: > > > Actually, all this talk does imply that VM objects should be independant > > of vnodes. Devices may need to mmap (requiring a VM object), but > > don't need all the baggage of a vnode. Julian is absolutely correct > > there. > > Well, you have other VM Objects which doesn't map to vnodes: swap > backed anonymous objects for instance. there has been talk of MAKING those have a vnode by making a swapfs. > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 21:29: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 741C337B422; Wed, 18 Apr 2001 21:29:02 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f3J4T1I32771; Wed, 18 Apr 2001 22:29:01 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104190429.f3J4T1I32771@harmony.village.org> To: Coleman Kane Subject: Re: Idea about modules build Cc: Peter Pentchev , "Vladimir B. Grebenschikov" , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Apr 2001 20:16:13 EDT." <20010416201613.B1843@cokane.yi.org> References: <20010416201613.B1843@cokane.yi.org> <15064.29187.667341.757712@vbook.express.ru> <20010416133100.A414@ringworld.oblivion.bg> Date: Wed, 18 Apr 2001 22:27:46 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010416201613.B1843@cokane.yi.org> Coleman Kane writes: : It would also be nice to be able to update third-party modules (like those = : in : ports, x11, etc...) after a kernel recompile. Perhaps some way of setting t= : hese : up into /usr/local? I do this all the time at work with 4.2-BETA. But you do need to define SYSDIR if you are compiling a kernel that isn't in /usr/src. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 18 22:18:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id E409837B423 for ; Wed, 18 Apr 2001 22:18:15 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f3J5IAp00333 for ; Thu, 19 Apr 2001 05:18:10 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Thu, 19 Apr 2001 05:18:09 +0000 (GMT) From: "E.B. Dreger" To: hackers@freebsd.org Subject: aic7xxx angry (MPARERR) in 4.2-R Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, (If I'm OT, please feel free to tell me where to go... as in which list, not that other place. ;-) I have a couple of AHC cards. When I cold boot, I receive MPARERR before "Waiting XXX seconds for SCSI bus to settle". Panic. I've tried two different AHC boards and two different motherboards, and *always* receive MPARERR on cold boot. *Never* after a warm boot. Quick STFWing via Google told me that I'm not the first: http://www.luga.at/mailing-lists/aic7xxx/msg09868.html It appears that 4.0-C was the topic of discussion, and the problem was fixed circa 2000/02/09... but my 2940 and 2940UW are most unhappy on 4.2-R. Now what? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 0: 7:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B428437B423; Thu, 19 Apr 2001 00:07:12 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3J77C723562; Thu, 19 Apr 2001 00:07:12 -0700 (PDT) Date: Thu, 19 Apr 2001 00:07:12 -0700 From: Alfred Perlstein To: hackers@freebsd.org Cc: Kirk McKusick Subject: utilizing write caching Message-ID: <20010419000712.C976@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm sure you guys remeber the recent discusion wrt write caching on disks possibly causing inconsistancies for UFS and just about any filesystem or program that expect things like fsync() to actually work. The result of the discussion was that write caching was disabled for all disks. I really think this is suboptimal. I mean _really_ suboptimal, my laptop disk is a pig since the default went in for ata disks. Or maybe it's just a pig anyway, but I'd like to take a look at this. The most basic fix to gain performance back would be to have the device examine the B_ASYNC flags and decide there whether or not to perform write caching. However, I have this strange feeling that softupdates is actually able to issue the meta-data writes with B_ASYNC set. Kirk, is this true? If so would it be possible to tag the buffer with yet another flag saying "yes, write me async, but safely" when doing softdep disk io? If softupdates doesn't use B_ASYNC, then it seems trivial to make DEV_STRATEGY propogate B_ASYNC into the bio request (BIO_STRATEGY) via OR'ing something like BIO_CACHE so that the device driver could then choose to activate write caching. This is still suboptimal because we'll be turning off caching when the buffer system is experiencing a shortage and issuing sync writes in order not to deadlock, but it's still better IMO than turning it off completely. If on the otherhand Kirk can figure out a quick hack to flag buffers that need completely stable storage (including fsync(2)*) ops then I think we've got a solution. (*) i'll look at fsync and physio if the scope of fixing those seems to be too much wrt to time available. If softupdates doesn't use B_ASYNC something like this: Index: sys/bio.h =================================================================== RCS file: /home/ncvs/src/sys/sys/bio.h,v retrieving revision 1.104 diff -u -r1.104 bio.h --- sys/bio.h 2001/01/14 18:48:42 1.104 +++ sys/bio.h 2001/04/19 06:53:52 @@ -91,6 +91,7 @@ #define BIO_ERROR 0x00000001 #define BIO_ORDERED 0x00000002 #define BIO_DONE 0x00000004 +#define BIO_ASYNC 0x00000008 /* Device may choose to write cache */ #define BIO_FLAG2 0x40000000 /* Available for local hacks */ #define BIO_FLAG1 0x80000000 /* Available for local hacks */ Index: sys/conf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/conf.h,v retrieving revision 1.126 diff -u -r1.126 conf.h --- sys/conf.h 2001/03/26 12:41:26 1.126 +++ sys/conf.h 2001/04/19 06:52:08 @@ -157,6 +157,8 @@ (bp)->b_io.bio_offset = (bp)->b_offset; \ else \ (bp)->b_io.bio_offset = dbtob((bp)->b_blkno); \ + if ((bp)->b_flags & B_ASYNC) \ + (bp)->b_io.bio_flags |= BIO_ASYNC \ (bp)->b_io.bio_done = bufdonebio; \ (bp)->b_io.bio_caller2 = (bp); \ BIO_STRATEGY(&(bp)->b_io, dummy); \ could do the trick, no? -- -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. ----- End forwarded message ----- -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 4:49: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from erouter0.it-datacntr.louisville.edu (erouter0.it-datacntr.louisville.edu [136.165.1.36]) by hub.freebsd.org (Postfix) with ESMTP id A10E537B496 for ; Thu, 19 Apr 2001 04:49:04 -0700 (PDT) (envelope-from keith.stevenson@louisville.edu) Received: from osaka.louisville.edu (osaka.louisville.edu [136.165.1.114]) by erouter0.it-datacntr.louisville.edu (Postfix) with ESMTP id 440581045 for ; Thu, 19 Apr 2001 07:49:04 -0400 (EDT) Received: by osaka.louisville.edu (Postfix, from userid 15) id EC2DC18613; Thu, 19 Apr 2001 07:49:03 -0400 (EDT) Date: Thu, 19 Apr 2001 07:49:03 -0400 From: Keith Stevenson To: freebsd-hackers@FreeBSD.ORG Subject: Re: The future of multiprocessors (was: SMP in 2.4 (fwd)) Message-ID: <20010419074903.B28694@osaka.louisville.edu> References: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> <20010419121051.D72816@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010419121051.D72816@wantadilla.lemis.com>; from grog@lemis.com on Thu, Apr 19, 2001 at 12:10:51PM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 19, 2001 at 12:10:51PM +0930, Greg Lehey wrote: > More to the point, the processors of the not-too-distant future will > have multiple processors on the single die. Multiprocessors are here > to stay. That day will be here in Q4 2001. IBM is planning to launch a new system based on the Power4 processor. According to the design papers I've read, the Power4 has two processor cores per die. Big computing it certainly not going away. SMP may not be the most efficient design, but NUMA appears to have a lot of promise. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville keith.stevenson@louisville.edu GPG key fingerprint = 332D 97F0 6321 F00F 8EE7 2D44 00D8 F384 75BB 89AE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 7:16: 6 2001 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 8BF0A37B424 for ; Thu, 19 Apr 2001 07:16:01 -0700 (PDT) (envelope-from mwlucas@blackhelicopters.org) Received: (from mwlucas@localhost) by blackhelicopters.org (8.9.3/8.9.3) id KAA48378; Thu, 19 Apr 2001 10:15:47 -0400 (EDT) (envelope-from mwlucas) Date: Thu, 19 Apr 2001 10:15:47 -0400 From: Michael Lucas To: Matthew Emmerton Cc: hackers@FreeBSD.ORG Subject: Re: thoughts on /etc/newsyslog.conf Message-ID: <20010419101547.B48300@blackhelicopters.org> References: <20010418215610.A46691@blackhelicopters.org> <003a01c0c876$52242310$1200a8c0@gsicomp.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <003a01c0c876$52242310$1200a8c0@gsicomp.on.ca>; from matt@gsicomp.on.ca on Wed, Apr 18, 2001 at 10:13:26PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 18, 2001 at 10:13:26PM -0400, Matthew Emmerton wrote: > You need ISO8601 to support rolling on fixed dates (1st of the month, etc.) > > You need 'W-D-M' format to support rolling on a weekly/monthly/daily basis. > This can't be done using ISO8601 because ISO uses fixed dates. (How would > you specify rotating every monday using ISO8601, when the date of every > monday changes from month to month and year to year?) What I'm suggesting is the default newsyslog.conf use WDM everywhere, instead of being half WDM and half ISO8601. Or is there something you can do with ISO8601 that you can't do with WDM? This would make things more clear for the new administrator. If the answer is "because we've always done it this way", then I'll document it as such. :) --- newsyslog.conf-dist Thu Apr 19 10:10:11 2001 +++ newsyslog.conf Thu Apr 19 10:11:33 2001 @@ -6,15 +6,15 @@ /var/log/amd.log 644 7 100 * Z /var/log/kerberos.log 644 7 100 * Z /var/log/lpd-errs 644 7 100 * Z -/var/log/maillog 644 7 * @T00 Z +/var/log/maillog 644 7 * $H0 Z /var/log/sendmail.st 644 10 * 168 B /var/log/messages 644 5 100 * Z -/var/log/all.log 600 7 * @T00 Z +/var/log/all.log 600 7 * $H0 Z /var/log/slip.log 600 3 100 * Z /var/log/ppp.log 600 3 100 * Z /var/log/security 600 10 100 * Z -/var/log/wtmp 644 3 * @01T05 B -/var/log/daily.log 640 7 * @T00 Z +/var/log/wtmp 644 3 * $M1H5 B +/var/log/daily.log 640 7 * $H0 Z /var/log/weekly.log 640 5 1 $W6D0 Z /var/log/monthly.log 640 12 * $M1D0 Z /var/log/console.log 640 5 100 * Z The sendmail.st rotation also seems odd: why rotate once a week at some (essentially) randomly chosen time, rather than once a week at a set time like the rest of the logs? But that's a separate issue. ==ml -- Michael Lucas mwlucas@blackhelicopters.org http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 7:34:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns2.myway.com.br (ns2.myway.com.br [200.186.239.2]) by hub.freebsd.org (Postfix) with SMTP id 16F1537B423 for ; Thu, 19 Apr 2001 07:34:07 -0700 (PDT) (envelope-from leal@myway.com.br) Received: from sup02 (unverified [200.186.239.5]) by ns2.myway.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 19 Apr 2001 11:33:09 -0300 Message-ID: <01c601c0c8dd$a4377780$1400000a@myway.com.br> From: "leal" To: References: <20010418215610.A46691@blackhelicopters.org> <003a01c0c876$52242310$1200a8c0@gsicomp.on.ca> <20010419101547.B48300@blackhelicopters.org> Subject: services... Date: Thu, 19 Apr 2001 11:33:03 -0300 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 X-Antirelay: Good relay from local net2 200.186.239.0/24 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG i don't know if this list is for me... but... i invited myself... well, i'm brazilian and i don't speak english very well...... :O) i hope you understand me. i work with wireless, and i use slack and red hat. But now i wanna true OS. I found the solution, FreeBSD. I installed it, and don't need configure my isa adapter because it configure itself. native. But the configuration files in red hat for example is in /etc/pcmcia/network.opts and config.opts. Where i put my configuration in FreeBSD??? station name, encryption... etc.. the parameters of my pccard??? And, how can i manipulate the services of my box??? the sendmail is running and i don't know one adminstrative software for ativate and desativate services... or files that i must edit.... thanks for all. i come in.... :O) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 7:37:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by hub.freebsd.org (Postfix) with ESMTP id B5BE337B422 for ; Thu, 19 Apr 2001 07:37:23 -0700 (PDT) (envelope-from daverufino@btinternet.com) Received: from [213.122.119.6] (helo=213.122.37.230) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 14qFYg-0007Ta-00 for freebsd-hackers@freebsd.org; Thu, 19 Apr 2001 15:37:22 +0100 Date: Thu, 19 Apr 2001 16:39:16 +0100 From: David Rufino To: freebsd-hackers@freebsd.org Subject: vm fun Message-ID: <20010419163916.A816@btinternet.com> Mail-Followup-To: David Rufino , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, If inside a syscall, what is the proper way to find the physical address of an arbitrary userland address of the current process ? Thanks, David Rufino To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 7:42:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tango.entreri.com (tango.entreri.com [205.219.158.250]) by hub.freebsd.org (Postfix) with ESMTP id 963E037B423 for ; Thu, 19 Apr 2001 07:42:53 -0700 (PDT) (envelope-from dp@penix.org) Received: from penix.org (Toronto-ppp221365.sympatico.ca [64.228.106.182]) by tango.entreri.com (8.10.2/8.9.1) with ESMTP id f3JEgk119176; Thu, 19 Apr 2001 09:42:48 -0500 Message-ID: <3ADEFC47.99A7DD2E@penix.org> Date: Thu, 19 Apr 2001 10:55:03 -0400 From: Paul Halliday X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: leal Cc: hackers@FreeBSD.ORG Subject: Re: services... References: <20010418215610.A46691@blackhelicopters.org> <003a01c0c876$52242310$1200a8c0@gsicomp.on.ca> <20010419101547.B48300@blackhelicopters.org> <01c601c0c8dd$a4377780$1400000a@myway.com.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG leal wrote: > > i don't know if this list is for me... but... i invited myself... > well, i'm brazilian and i don't speak english very well...... :O) > i hope you understand me. > i work with wireless, and i use slack and red hat. But now i wanna true OS. > I found the solution, FreeBSD. I installed it, and don't need configure my > isa adapter because it configure itself. native. > But the configuration files in red hat for example is in > /etc/pcmcia/network.opts and config.opts. Where i put my configuration in > FreeBSD??? station name, encryption... etc.. the parameters of my pccard??? > And, how can i manipulate the services of my box??? the sendmail is running > and i don't know one adminstrative software for ativate and desativate > services... or files that i must edit.... > thanks for all. > i come in.... > :O) > Leal FreeBSD offers another forum for questions such as this,checkout freebsd-questions. Also, the answers to these questions can be easilly found at www.freebsd.org. Checkout the handbook and the FAQ and you will be quickly on your way. -- Paul Halliday ============================================================================ Don't underestimate the power of stupid people in large groups. Web: http://dp.penix.org Current Project: http://dp.penix.org/cl.html Public Key available here: http://dp.penix.org/dp.txt ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 7:57:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id BDF8137B423 for ; Thu, 19 Apr 2001 07:57:41 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f3JEwab64379; Thu, 19 Apr 2001 15:58:36 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f3JEvu505789; Thu, 19 Apr 2001 15:57:56 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200104191457.f3JEvu505789@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: David Rufino Cc: freebsd-hackers@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: vm fun In-Reply-To: Message from David Rufino of "Thu, 19 Apr 2001 16:39:16 BST." <20010419163916.A816@btinternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Apr 2001 15:57:55 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > > If inside a syscall, what is the proper way to find the physical address of > an arbitrary userland address of the current process ? Probably something like VM_PAGE_TO_PHYS - but you'll need a vm_page_t to use that. vm_page_list_find() looks promising, but I've never used it :-/ > Thanks, > David Rufino -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 8: 3:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id 5C81537B424 for ; Thu, 19 Apr 2001 08:03:19 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 42404 invoked from network); 19 Apr 2001 15:03:16 -0000 Received: from sherline.cts.com (HELO server2) (204.216.163.132) by dualcpus.com with SMTP; 19 Apr 2001 15:03:16 -0000 Message-ID: <000301c0c8e1$e12ddd10$015778d8@sherline.net> From: "Jeremiah Gowdy" To: "Andrew Hesford" Cc: References: <200104171836.LAA06378@akira.lanfear.com> <000001c0c777$f9529b30$215778d8@cx443070b> <20010417205711.C64757@cec.wustl.edu> Subject: Re: x86-64 Hammer and IA64 Itainium Date: Wed, 18 Apr 2001 09:03:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Second, it is this difference from x86 that I think is justification > enough to focus on Itanium rather than x86-64. > I'm not sure exactly how > x86-64 works, but it seems to me that it's simply the standard x86 > architecture expanded to 64 bits. With several enchancements, yes. > Isn't time we kill the x86? It's been around too long. I'm not sure how > the Itanium looks, and I'm no Intel freak, but a change would be nice. > We should begin moving in the direction of RISC (or at least VLIW). Itainium is EPIC. > is our chance. Focus main development on Alpha and Itanium (ideally, > major focus should be put on UltraSPARC and PPC, too), and leave the > x86-64 porting to people who actually care. As for killing the x86, that's a battle for the industry to decide. What happens if and when either Intel can't make Itainium work or sell ? Intel is the one taking the big risk here, by creating a new arcitecture. I have no problem with Sparc or PPC support, they are tested over a period of years. But I for one am not willing to wager alot of time and effort on Intel's new platform when it seems they're breaking their own losing streak record daily. This is not a kill the x86 discussion, nor am I willing to partake in one. Certainly the architecture is tired, no doubts there. Certainly there are better architectures. However, FreeBSD is an i386/x86 and Alpha OS the way things stand now. The x86-64 Hammer architecture is the next step in the x86 series, since Intel will soon end their involvement of the x86 line (they might as well stop now the way P4s are looking). If you want to work on the Itainium production, that's fine, my interest is in the Hammer because I believe legacy support is what drives the market. If that wasn't true, we wouldn't still be using the x86 today. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 8: 3:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id 1A26537B422 for ; Thu, 19 Apr 2001 08:03:20 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 42407 invoked from network); 19 Apr 2001 15:03:18 -0000 Received: from sherline.cts.com (HELO server2) (204.216.163.132) by dualcpus.com with SMTP; 19 Apr 2001 15:03:18 -0000 Message-ID: <000601c0c8e1$e229f050$015778d8@sherline.net> From: "Jeremiah Gowdy" To: "Mike Silbersack" Cc: , References: Subject: Re: x86-64 Hammer and IA64 Itainium Date: Wed, 18 Apr 2001 09:04:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think a port to x86-64 is an excellent idea, but I also think that > you're worrying about it too far in advance. As you say, the x86-64 > project is working on getting gcc ported, which is important chunk of > work. As such, it's probably best to not worry about a FreeBSD port > until after they're done and have linux up and running on the processors. Probably true. I'm just trying to feel out who else is interested. > Once that's done, it'll probably be a matter to send a clawhammer > system and a large box of cheese and crackers to the guys who did the > freebsd alpha port. If the architecture is actually so similar to x86, > it should only take them a few weekends. :) > > (Alternative options include Matt Dillon splurge-buying a clawhammer > system at CompUSA and doing the port himself... the likelihood of such a > plan seems to hinge on how much free time he has, though. Maybe send him > cheese, crackers, and a CompUSA ad to help the process along.) I will prepare large shipments of cheese and crackers immediately. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 8: 3:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id CA74C37B42C for ; Thu, 19 Apr 2001 08:03:21 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 42411 invoked from network); 19 Apr 2001 15:03:19 -0000 Received: from sherline.cts.com (HELO server2) (204.216.163.132) by dualcpus.com with SMTP; 19 Apr 2001 15:03:19 -0000 Message-ID: <000701c0c8e1$e3016490$015778d8@sherline.net> From: "Jeremiah Gowdy" To: , Cc: References: <200104181422.f3IELwC11439@luxren2.boostworks.com> Subject: Re: x86-64 Hammer and IA64 Itainium Date: Wed, 18 Apr 2001 09:21:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Isn't time we kill the x86? It's been around too long. I'm not sure how > > the Itanium looks, and I'm no Intel freak, but a change would be nice. > > We should begin moving in the direction of RISC (or at least VLIW). > > > > There's a reason every other processor has a radically different > > architecture. Motorola, Sun and Digital all broke new ground with their > > processors, because the x86 doesn't amount to all that much any more. > > Remember, this technology was designed for 20-year old computers. > X86 (and -64) is going to be just die hard PC and workstations where > deadly wrong past must be taken into account at the price of wasted > power. Futur is more than probably Itanium and alike for servers CPUs > and a bunch of ARMs for low-level I/O tasks. Back to imagination. (Take > a look at 0.15um copper process FPGAs with embeded ARM at Altera, for > example, and you will see why no one, in the futur, will never ever need > a proprietary and undocumented 'server class' SCSI or network card). Excuse me for saying so, but I've heard all this talk before. "x86 will die. Some other architecture like Alpha will take over." Why hasn't it happened yet ? Tell me there haven't been far superior cpus than the x86 line almost since it's creation. Why weren't those other cpus adopted ? If technical merit ruled the processor market, Intel would be out of business having screwed themselves so royally in the past 2 years. When the Athlon is faster AND cheaper, why do people continue to buy Pentium IIIs ? The answer is simple. The industry is conservative. They will stick with what they know works. If you don't believe there are hoards of IT Managers out there who will frown at the idea of a new architecture, you're wrong. And besides, because of the design of the Itainium, the only software that will run at the super speeds that it provides is that which is compiled with an ILP aware/capable compiler. The Itainium is ALL about having the right compiler. The current GCC port to Itainium has NO ILP support. It may have something in the future, but something is not everything. Now think about this. Microsoft Visual C++ will be *the* industry compiler for Itainium. Their compiler is already working and has ILP support. Plus Intel makes its own compiler which plugs into Visual Studio. Both the Microsoft and Intel compilers for ILP are going to kick the crap out of gcc and I think we all know it. So then what, you're going to have FreeBSD and Linux compiled with an inferior compiler compared to Windows with their compilers ? The first thing that will happen is Microsoft will pay for a benchmark showing Windows beating the living crap out of Linux and BSD. And this time they won't have to fake it. Not having proper ILP support is like intentionally stalling pipes constantly. The whole design of this new cpu is the ILP. Without it, the GNU compiled programs aren't going to have much to show for. The Hammer is another standard x86 processor with a new 64bit mode, 64bit registers, and a few other advantages. FreeBSD will already run under the Hammer in 32bit mode, and it will be faster than current Athlon/P4 cpus by quite a margin. There's no reason not to extend FreeBSD support to this next generation of x86. FreeBSD is based in the x86 (and Alpha) world. If you have issues with that, or want to push for a Sparc, PPC, or Itainium port, I don't see what that has to do with FreeBSD's continued x86 support. The two are not mutually exclusive in my opinion. > > RN. > IeM > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 8:19:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tango.entreri.com (tango.entreri.com [205.219.158.250]) by hub.freebsd.org (Postfix) with ESMTP id B154037B42C for ; Thu, 19 Apr 2001 08:19:31 -0700 (PDT) (envelope-from dp@penix.org) Received: from penix.org (Toronto-ppp221365.sympatico.ca [64.228.106.182]) by tango.entreri.com (8.10.2/8.9.1) with ESMTP id f3JFJX119304 for ; Thu, 19 Apr 2001 10:19:34 -0500 Message-ID: <3ADF04E8.55D0888E@penix.org> Date: Thu, 19 Apr 2001 11:31:52 -0400 From: Paul Halliday X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Dilemma. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I will try to make this quick. I am writting a little monitoring script in bash and I have run into a little stumbling block. Basically, one of the checks this program will perform is to take a fingerprint of the entire filesystem. For my needs this is only required every 24 hours as the other procedures that use this as a template will do so in little chunks. Now, I have a couple of concerns. 1) Is there a simpler and faster way to perform something equivalent to "ls -aliTR /"? This portion of output will be queried with checks on inode numbers, last modified, and sizes at random intervals and subsequently updated if valid. 2) The more I test the above, the more I realise that this is not without loopholes. Even if my checks are every 5 minutes there still exists the possibility and time for someone that has compromised the system to modify date / inodes to match what was existing. <- any input on this issue would be really great. ie: a field that cannot be modified even by root. I have had some silly ideas such as: changing kernel secure level and chflaging every file (probably not even possible),or maybe using pgp in some way to sign the most important files, /bin, /usr/bin, etc. I hope to build enough superfluity into this baby so that the above would just be another check not the backbone of this IDS idea. Any help, ideas, please send. -- Paul Halliday ============================================================================ Don't underestimate the power of stupid people in large groups. Web: http://dp.penix.org Current Project: http://www3.sympatico.ca/transmogrify/cl.html Public Key available here: http://dp.penix.org/dp.txt ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 8:31:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by hub.freebsd.org (Postfix) with ESMTP id 823E137B423 for ; Thu, 19 Apr 2001 08:31:41 -0700 (PDT) (envelope-from michael.adler@compaq.com) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 6CD103D3; Thu, 19 Apr 2001 08:34:21 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 448611E8 for ; Thu, 19 Apr 2001 08:34:21 -0700 (PDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 65DE820A; Thu, 19 Apr 2001 10:31:40 -0500 (CDT) Received: from vssad.hlo.dec.com (vssad.hlo.dec.com [16.128.112.187]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 08B9E227 for ; Thu, 19 Apr 2001 10:31:40 -0500 (CDT) Received: from mulva.vssad.hlo.dec.com by vssad.hlo.dec.com (8.8.8/1.1.19.2/20Jul99-0349PM) id LAA0000021613; Thu, 19 Apr 2001 11:31:38 -0400 (EDT) Message-Id: <5.1.0.14.0.20010419111106.02d68f50@vssad.hlo.dec.com> X-Sender: madler@vssad.hlo.dec.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Apr 2001 11:31:07 -0400 To: freebsd-hackers@FreeBSD.ORG From: Michael Adler Subject: Re: The future of multiprocessors (was: SMP in 2.4 (fwd)) In-Reply-To: <20010419074903.B28694@osaka.louisville.edu> References: <20010419121051.D72816@wantadilla.lemis.com> <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> <20010419121051.D72816@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A number of our larger customers care about computation/cubic foot. The density of processors is important to them. SMP machines work well here. A future Alpha processor will be an SMT (symmetric multi threaded) machine. Above the lowest levels, it will look like a multi-CPU machine. The machine will keep multiple thread contexts live within the CPU and will be capable of switching between these threads in a single cycle. As it grows harder for compilers to find parallelism within a single thread we have had to look elsewhere to keep the machine busy. -Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 8:32:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns2.myway.com.br (ns2.myway.com.br [200.186.239.2]) by hub.freebsd.org (Postfix) with SMTP id 09BBB37B43C for ; Thu, 19 Apr 2001 08:32:36 -0700 (PDT) (envelope-from leal@myway.com.br) Received: from sup02 (unverified [200.186.239.5]) by ns2.myway.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 19 Apr 2001 12:30:57 -0300 Message-ID: <000f01c0c8e5$b4bfab60$1400000a@myway.com.br> From: "leal" To: "Paul Halliday" Cc: References: <20010418215610.A46691@blackhelicopters.org> <003a01c0c876$52242310$1200a8c0@gsicomp.on.ca> <20010419101547.B48300@blackhelicopters.org> <01c601c0c8dd$a4377780$1400000a@myway.com.br> <3ADEFC47.99A7DD2E@penix.org> Subject: Re: services... Date: Thu, 19 Apr 2001 12:30:37 -0300 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 X-Antirelay: Good relay from local net2 200.186.239.0/24 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG thanks, but what the point of this forum??? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 8:52:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tango.entreri.com (tango.entreri.com [205.219.158.250]) by hub.freebsd.org (Postfix) with ESMTP id 7658937B422 for ; Thu, 19 Apr 2001 08:52:16 -0700 (PDT) (envelope-from dp@penix.org) Received: from penix.org (Toronto-ppp221365.sympatico.ca [64.228.106.182]) by tango.entreri.com (8.10.2/8.9.1) with ESMTP id f3JFqO119434 for ; Thu, 19 Apr 2001 10:52:24 -0500 Message-ID: <3ADF0C9C.FC7E6891@penix.org> Date: Thu, 19 Apr 2001 12:04:44 -0400 From: Paul Halliday X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: Dilemma. References: Content-Type: multipart/mixed; boundary="------------08012C3E56A66318CE0CEC09" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------08012C3E56A66318CE0CEC09 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Troy Corbin wrote: > > will your monitoring script be publicly available? > > -troy heh.. I doubt anyone would want it when it is complete. I have attached what I have so far. Which isnt much. you can see what it checks, I still need to add the check for running processes. Anyway, when this is all done the program will loop checking certain things every 5min, 1 hour, 12 hours, and full every 24 hours. all logs will be emailed to whatever address and whenever there is a significant change somewhere, ambiguous processes, logs etc will be directed to the main terminal, if unattended and depending on the severity of the situation processes will be terminated or if valid yet drawing a lot of resources reniced, firewall rules may be added or modified, shells destroyed, and if something very serious, say a scenario such as there has been a compromise somewhere, it was dealt with, checks increase on that area, then same or similar occurs again and things are logged yet no action is taken within set number of minutes or whatever the system will shutdown to single user mode etc.. this of course only occuring when something REALLY goes bad. The primary concern will be to make sure that all binaries are ok and the the program itself is sane and recieving the proper information. before you laugh, this is just an at home type of thing. something like that. -- Paul Halliday ============================================================================ Don't underestimate the power of stupid people in large groups. Web: http://dp.penix.org Current Project: http://www3.sympatico.ca/transmogrify/cl.html Public Key available here: http://dp.penix.org/dp.txt ============================================================================ --------------08012C3E56A66318CE0CEC09 Content-Type: text/plain; charset=us-ascii; name="spike" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="spike" #!/usr/local/bin/bash # Lets begin.. # Initial system check. Take some records. What will we watch? for now lets # examine filesystem structure and sizes and monitor memory and cpu usage. We # will also determine how many users their is, what terminal they are on, and # what they are up to. Note: this is designed for smaller system setups. # Most of the checks that are performed will take far too much time and resources # to be practical on larger systems. ie. raid arrays, terabytes of # disk space etc. #---------------------------------------# _clean_up () { echo echo 'Caught SIGnal.. Exiting cleanly..' echo exit 1 # add stuff in here to cleanup working dirs. } trap _clean_up 1 2 3 15 17 #----------------------------------------# _init_state () { echo echo "[ spike v.01b ]" echo echo "The first time this program is run it must aquire a fingerprint" echo "of the filesystem, this process will take about 5-10 minutes." echo "A full system fingerprint like this will be taken once every" echo -n "24 hours. " check=1 while [ $check = 1 ]; do echo -n "Do you wish to continue? [y/n]: " read comply case $comply in [Nn]) echo Quit!;exit 1;; [Yy]) check=2;; *) echo; echo "-- Invalid entry! --";echo;; esac done; echo echo -n "=> checking filesystem.. " echo "##### Archived: `/bin/date` #####" >spike.init /bin/ls -aliTR / >>spike.init; chmod 600 spike.init; chflags schg spike.init; echo "done!" _usr_state } #----------------------------------------# _usr_state () { echo -n "=> collecting user base.. " echo "##### Archived: `/bin/date` #####" > spike.user /usr/bin/who >>spike.user; chmod 600 spike.user; chflags schg spike.user echo "done!" _disk_state } #----------------------------------------# _disk_state () { echo -n "=> collecting HD, CPU and memory usage.. " echo "##### Archived: `/bin/date` #####" >spike.dcm; echo "Load: `uptime|awk '{print $10}' | tr -d ,`" >>spike.dcm; /usr/bin/top -d 3 0 | sed -n 18,20p >>spike.dcm; /bin/df -h >>spike.dcm chmod 600 spike.dcm; chflags schg spike.dcm; echo "done!" #_check_state } #--------------------------------------# # Time to begin with the checks. We will work hierarchically following that # which we have covered so far. This will be a continuous loop until main # is called again or until we reach an alert state. #_check_state () #{ # last_date= #} #_spike_released () _init_state --------------08012C3E56A66318CE0CEC09-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 8:57:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id 99C8037B422 for ; Thu, 19 Apr 2001 08:57:36 -0700 (PDT) (envelope-from data@dualcpus.com) Received: (qmail 42847 invoked from network); 19 Apr 2001 15:57:33 -0000 Received: from sherline.cts.com (HELO server2) (204.216.163.132) by dualcpus.com with SMTP; 19 Apr 2001 15:57:33 -0000 Message-ID: <002101c0c8e9$759443c0$015778d8@sherline.net> From: "Jeremiah Gowdy" To: Subject: OpenBSD's FFS/dirpref/softupdates improvements Date: Thu, 19 Apr 2001 08:57:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Two aspects of the FFS filesystem in OpenBSD have received significant improvements since 2.8, increasing performance dramatically. Thanks to art, gluk, csapuntz, and a host of other developers and testers, Soft Updates are now much more stable than ever before. The second improvement, contributed by gluk@openbsd.org, is a new directory allocation policy (codenamed "dirpref"). Coupled with soft updates, the new dirpref code offers up to a 60x speed increase in gluk's tests, documented here:" http://groups.google.com/groups?q=dirpref&num=100&hl=en&lr=&safe=off&rnum=2& seld=905073910&ic=1 Does anyone know anything about this ? > > Log message: > > Replace FFS directory preference algorithm(dirpref) by new one. > > It allocates directory inode in the same cylinder group as a parent > > directory in. This speedup file/directory intensive operations on > > a big file systems in times. The benchmarks they're showing here are huge. 4 to 8 to 11 times faster depending on sync, async, or softdep. I don't know about you guys, but this sounds pretty nice to me. Any possibility we can implement this into FreeBSD ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 9:14:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from lindt.urgle.com (lindt.urgle.com [62.49.202.23]) by hub.freebsd.org (Postfix) with ESMTP id 65CDF37B423 for ; Thu, 19 Apr 2001 09:14:51 -0700 (PDT) (envelope-from mike@urgle.com) Received: from mike by lindt.urgle.com with local (Exim 3.22 #1) id 14qH4p-0000vM-00; Thu, 19 Apr 2001 16:14:39 +0000 Date: Thu, 19 Apr 2001 17:14:39 +0100 From: Mike Bristow To: Jeremiah Gowdy Cc: hackers@freebsd.org Subject: Re: OpenBSD's FFS/dirpref/softupdates improvements Message-ID: <20010419171439.A3535@lindt.urgle.com> References: <002101c0c8e9$759443c0$015778d8@sherline.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002101c0c8e9$759443c0$015778d8@sherline.net>; from data@dualcpus.com on Thu, Apr 19, 2001 at 08:57:37AM -0700 X-Rated: M-16 AK-47, Albania Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 19, 2001 at 08:57:37AM -0700, Jeremiah Gowdy wrote: > "Two aspects of the FFS filesystem in OpenBSD have received significant > improvements since 2.8, increasing performance dramatically. Thanks to art, > gluk, csapuntz, and a host of other developers and testers, Soft Updates are > now much more stable than ever before. The second improvement, contributed > by gluk@openbsd.org, is a new directory allocation policy (codenamed > "dirpref"). Coupled with soft updates, the new dirpref code offers up to a > 60x speed increase in gluk's tests, documented here:" > > http://groups.google.com/groups?q=dirpref&num=100&hl=en&lr=&safe=off&rnum=2& > seld=905073910&ic=1 > > Does anyone know anything about this ? Commited to -current about 10 April. I suspect that Jordan would shoot someone who suggested a MFC before 4.3 is out. -- Mike Bristow, seebitwopie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 9:15:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id DCF8237B71A for ; Thu, 19 Apr 2001 09:15:07 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 4319 invoked by uid 1000); 19 Apr 2001 16:13:32 -0000 Date: Thu, 19 Apr 2001 19:13:32 +0300 From: Peter Pentchev To: Paul Halliday Cc: hackers@freebsd.org Subject: Re: Dilemma. Message-ID: <20010419191332.E1527@ringworld.oblivion.bg> Mail-Followup-To: Paul Halliday , hackers@freebsd.org References: <3ADF04E8.55D0888E@penix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ADF04E8.55D0888E@penix.org>; from dp@penix.org on Thu, Apr 19, 2001 at 11:31:52AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 19, 2001 at 11:31:52AM -0400, Paul Halliday wrote: > Hi. > > I will try to make this quick. I am writting a little monitoring script > in bash and I have run into a little > stumbling block. Basically, one of the checks this program will perform > is to take a fingerprint of the entire filesystem. > For my needs this is only required every 24 hours as the other > procedures that use this as a template will do so in little chunks. Now, > I have a couple of concerns. > > 1) Is there a simpler and faster way to perform something equivalent to > "ls -aliTR /"? This portion of output will > be queried with checks on inode numbers, last modified, and sizes at > random intervals and subsequently updated if valid. "find / -ls" shall give you more relevant info, less redundant info, and less irrelevant info. > 2) The more I test the above, the more I realise that this is not > without loopholes. Even if my checks are every 5 minutes > there still exists the possibility and time for someone that has > compromised the system to modify date / inodes to match what was > existing. <- any input on this issue would be really great. ie: a field > that cannot be modified even by root. I have had some silly ideas such > as: changing kernel secure level and chflaging every file (probably not > even possible),or maybe using pgp in some way to sign the most important > files, /bin, /usr/bin, etc. No, I don't believe there is any aspect of the filesystem that cannot be modified/faked, given appropriate privileges :( I might be wrong, though. G'luck, Peter -- This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 9:34:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id A42D537B42C for ; Thu, 19 Apr 2001 09:34:30 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id MAA12328; Thu, 19 Apr 2001 12:35:01 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.2.1.0.20010419114632.03cacdd0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 19 Apr 2001 11:56:09 -0400 To: Rik van Riel From: Dennis Subject: Re: SMP in 2.4 (fwd) Cc: Alfred Perlstein , Kris Kennaway , freebsd-hackers@FreeBSD.ORG In-Reply-To: References: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:17 PM 04/18/2001, Rik van Riel wrote: >On Wed, 18 Apr 2001, Dennis wrote: > > > >You think Intel isn't going to market dual/quad ia64 machines? > > > > Yes, but who'll need them? > >If nobody needed them, what would be the point in SELLING >them ? > >I know you don't trust our technical instinct, but you might >at least consider the business instinct of companies like >Intel, IBM or Unisys (who all sell big SMP systems). I didnt say they shouldnt support SMP, only that complicating the OS with highly SMP-specific code to make it slightly more efficient when 99% of users dont need it is a questionable endeavor. >And as for the "but you can wait 2 years until UP is faster than >today's SMP" doesn't quite work for eg. investment banking and >stock funds. More computing power means better calculations, which >means more money. And for folks like them, computing power is not >measured in FLOPS, but in ACRES. And when you're talking 3 acres >of computing power, you'd better have some decend density (ie. SMP >in 2U rackmounted boxes, or something similarly suitable). Your point is moot, as you already have SMP support. The question is whether squeezing a few extra cycles out (SMPng) is worth making the OS significantly more complex, particularly when more computing power is always on the way. I understand there is a language thing, but I went out of my way to say that i wasnt saying that SMP shouldnt be supported. It already is, and its been done very cleanly in a way that doesnt compromise the integrity of the OS internals. DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 9:59:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from buddha.automagic.org (buddha-nexxia.automagic.org [207.61.141.34]) by hub.freebsd.org (Postfix) with SMTP id 2B62737B43C for ; Thu, 19 Apr 2001 09:59:43 -0700 (PDT) (envelope-from jabley@buddha.automagic.org) Received: (qmail 29312 invoked by uid 100); 19 Apr 2001 16:59:35 -0000 Date: Thu, 19 Apr 2001 12:59:34 -0400 From: Joe Abley To: leal Cc: Paul Halliday , hackers@FreeBSD.ORG Subject: Re: services... Message-ID: <20010419125934.R16654@buddha.home.automagic.org> References: <20010418215610.A46691@blackhelicopters.org> <003a01c0c876$52242310$1200a8c0@gsicomp.on.ca> <20010419101547.B48300@blackhelicopters.org> <01c601c0c8dd$a4377780$1400000a@myway.com.br> <3ADEFC47.99A7DD2E@penix.org> <000f01c0c8e5$b4bfab60$1400000a@myway.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000f01c0c8e5$b4bfab60$1400000a@myway.com.br>; from leal@myway.com.br on Thu, Apr 19, 2001 at 12:30:37PM -0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 19, 2001 at 12:30:37PM -0300, leal wrote: > thanks, > but what the point of this forum??? See: http://www.freebsd.org/doc/en_US.ISO_8859-1/books/handbook/eresources.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 10:12:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 44C2D37B424 for ; Thu, 19 Apr 2001 10:12:21 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3JHBVG89641; Thu, 19 Apr 2001 10:11:31 -0700 (PDT) (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: <5.0.2.1.0.20010419114632.03cacdd0@mail.etinc.com> Date: Thu, 19 Apr 2001 10:10:51 -0700 (PDT) From: John Baldwin To: Dennis Subject: Re: SMP in 2.4 (fwd) Cc: freebsd-hackers@FreeBSD.org, Kris Kennaway , Alfred Perlstein , Rik van Riel Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 19-Apr-01 Dennis wrote: > At 10:17 PM 04/18/2001, Rik van Riel wrote: >>On Wed, 18 Apr 2001, Dennis wrote: >> >> > >You think Intel isn't going to market dual/quad ia64 machines? >> > >> > Yes, but who'll need them? >> >>If nobody needed them, what would be the point in SELLING >>them ? >> >>I know you don't trust our technical instinct, but you might >>at least consider the business instinct of companies like >>Intel, IBM or Unisys (who all sell big SMP systems). > > I didnt say they shouldnt support SMP, only that complicating the OS with > highly SMP-specific code to make it slightly more efficient when 99% of > users dont need it is a questionable endeavor. We are not complicating the OS. In fact, in many cases, we are cleaning up and simplifying the kernel internals. For example, the way we handle clock interrupts is very ugly and hacky on SMP x86, and the changes in SMPng have allowed me to clean it up and simplfly it greatly in a manner that allows us to share code with both alpha and x86 SMP support and avoid potential deadlocks and races in the x86 SMP code. >>And as for the "but you can wait 2 years until UP is faster than >>today's SMP" doesn't quite work for eg. investment banking and >>stock funds. More computing power means better calculations, which >>means more money. And for folks like them, computing power is not >>measured in FLOPS, but in ACRES. And when you're talking 3 acres >>of computing power, you'd better have some decend density (ie. SMP >>in 2U rackmounted boxes, or something similarly suitable). > > Your point is moot, as you already have SMP support. The question is > whether squeezing a few extra cycles out (SMPng) is worth making the OS > significantly more complex, particularly when more computing power is > always on the way. We aren't squeezing a few extra cycles out, we are squeezing a buttload of cycles out in the SMP case. Do you even know how the SMP support works? If all the CPU's want to make a system call at the same time, only one of them does any work, all the other CPU's sit _idle_ doing _absolutely_ _zero_ _productive_ _work_ but still sucking juice. > I understand there is a language thing, but I went out of my way to say > that i wasnt saying that SMP shouldnt be supported. It already is, and its > been done very cleanly in a way that doesnt compromise the integrity of the > OS internals. Actually, it's done in about the most inefficient manner possible, to be brutally honest. The first stage of the SMP support focused more on getting the machine to run than on getting it to perform well. You really should go do some actual research on SMP before spouting off. I highly recommend Curt Schimmel's _Unix Systems for Modern Architectures_: Caching and SMP for Kernel Programmers. If you read it, you will find that our current implementation is actually worse than a master/slave kernel setup, which is the slowest one mentioned in the book. :( Please, go do some actual research so you can at least spout off some semi-clueful nonsense rather than completely clueless nonsense. > DB -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Thu Apr 19 10:15:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id B8DFD37B424 for ; Thu, 19 Apr 2001 10:15:14 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3JHETG89717; Thu, 19 Apr 2001 10:14:29 -0700 (PDT) (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: <20010419171439.A3535@lindt.urgle.com> Date: Thu, 19 Apr 2001 10:13:50 -0700 (PDT) From: John Baldwin To: Mike Bristow Subject: Re: OpenBSD's FFS/dirpref/softupdates improvements Cc: hackers@FreeBSD.org, Jeremiah Gowdy Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 19-Apr-01 Mike Bristow wrote: > On Thu, Apr 19, 2001 at 08:57:37AM -0700, Jeremiah Gowdy wrote: >> "Two aspects of the FFS filesystem in OpenBSD have received significant >> improvements since 2.8, increasing performance dramatically. Thanks to art, >> gluk, csapuntz, and a host of other developers and testers, Soft Updates are >> now much more stable than ever before. The second improvement, contributed >> by gluk@openbsd.org, is a new directory allocation policy (codenamed >> "dirpref"). Coupled with soft updates, the new dirpref code offers up to a >> 60x speed increase in gluk's tests, documented here:" >> >> http://groups.google.com/groups?q=dirpref&num=100&hl=en&lr=&safe=off&rnum=2& >> seld=905073910&ic=1 >> >> Does anyone know anything about this ? > > Commited to -current about 10 April. > > I suspect that Jordan would shoot someone who suggested a MFC before > 4.3 is out. It needs more work, too. If you try to use an old fsck with the new kernel, then the old fsck will clobber some new variables in the superblock. Then the new kernel will panic later on instead of doing a sanity check on the new values in the superblock and falling back to defaults if they are bogus. This is a major POLA bug and the changes shouldn't go into 4.x unless this is fixed. This breaks the recommended method of updating stable by doing the installworld after rebooting into a new kernel. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Thu Apr 19 10:34:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id 1DC4A37B424 for ; Thu, 19 Apr 2001 10:34:56 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 51953 invoked from network); 19 Apr 2001 17:34:55 -0000 Received: from sherline.cts.com (HELO server2) (204.216.163.132) by dualcpus.com with SMTP; 19 Apr 2001 17:34:55 -0000 Message-ID: <007f01c0c8f7$0d2e7680$015778d8@sherline.net> From: "Jeremiah Gowdy" To: "Rik van Riel" , "Dennis" Cc: "Alfred Perlstein" , "Kris Kennaway" , References: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> <5.0.2.1.0.20010419114632.03cacdd0@mail.etinc.com> Subject: Re: SMP in 2.4 (fwd) Date: Thu, 19 Apr 2001 10:34:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I didnt say they shouldnt support SMP, only that complicating the OS with > highly SMP-specific code to make it slightly more efficient when 99% of > users dont need it is a questionable endeavor. Are you high ? What are you smoking ? There are MANY people that use SMP, and for some of us, SMP is the choice factor between FreeBSD and OpenBSD. I find Linux SMP vs Win2k SMP vs FreeBSD SMP to be an important subject in enterprise class servers. > Your point is moot, as you already have SMP support. The question is > whether squeezing a few extra cycles out (SMPng) is worth making the OS > significantly more complex, particularly when more computing power is > always on the way. Much of the code is being simplified and cleaned up. And it's not a "few extra cycles". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 12:33:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 00C5537B443; Thu, 19 Apr 2001 12:33:14 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3JJXDG58095; Thu, 19 Apr 2001 12:33:13 -0700 (PDT) (envelope-from dillon) Date: Thu, 19 Apr 2001 12:33:13 -0700 (PDT) From: Matt Dillon Message-Id: <200104191933.f3JJXDG58095@earth.backplane.com> To: John Baldwin Cc: Mike Bristow , hackers@FreeBSD.ORG, Jeremiah Gowdy Subject: Re: OpenBSD's FFS/dirpref/softupdates improvements References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've accepted the job of MFCing the dirpref stuff to -stable ... after the 4.3 release. If fsck is clobbering consistently we can probably make the kernel avoid a panic. I'll look at the issue carefully when I do the MFC. -Matt :On 19-Apr-01 Mike Bristow wrote: :> On Thu, Apr 19, 2001 at 08:57:37AM -0700, Jeremiah Gowdy wrote: :>> "Two aspects of the FFS filesystem in OpenBSD have received significant :>> improvements since 2.8, increasing performance dramatically. Thanks to art, :>> gluk, csapuntz, and a host of other developers and testers, Soft Updates are :>> now much more stable than ever before. The second improvement, contributed :>> by gluk@openbsd.org, is a new directory allocation policy (codenamed :>> "dirpref"). Coupled with soft updates, the new dirpref code offers up to a :>> 60x speed increase in gluk's tests, documented here:" :>> :>> http://groups.google.com/groups?q=dirpref&num=100&hl=en&lr=&safe=off&rnum=2& :>> seld=905073910&ic=1 :>> :>> Does anyone know anything about this ? :> :> Commited to -current about 10 April. :> :> I suspect that Jordan would shoot someone who suggested a MFC before :> 4.3 is out. : :It needs more work, too. If you try to use an old fsck with the new kernel, :then the old fsck will clobber some new variables in the superblock. Then the :new kernel will panic later on instead of doing a sanity check on the new :values in the superblock and falling back to defaults if they are bogus. This :is a major POLA bug and the changes shouldn't go into 4.x unless this is fixed. :This breaks the recommended method of updating stable by doing the installworld :after rebooting into a new kernel. : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 12:34:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id BCC6C37B43C for ; Thu, 19 Apr 2001 12:34:29 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f3JJYH806407; Thu, 19 Apr 2001 13:34:18 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104191934.f3JJYH806407@harmony.village.org> To: David Miller Subject: Re: [OT] parallel port for IO? Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 13 Apr 2001 12:38:21 EDT." References: Date: Thu, 19 Apr 2001 13:34:17 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message David Miller writes: : Anyone know of a way to get a low cost port of some kind to to simple : state change detection? The specific purpose is to time external events : which are triggered by breaking an LED light beam. Millisecond resolution : would be fine. : : I was thinking of sampling the parallel port repeatedly and looking for : data lines to be high or low. Feasible? If you have only 1 source, then you can use the ack line of the parallel port and the ppi driver to get timestamped events. If you have more than one, then you might be able to wire a simple latch to the ACK line and sample of to 8 sources. That's trickier as their's some hair in converting the signals to pulses, worrying about races, etc. 1 source gives you nanosecond resolution (but only ms accuracy due to interrupt latencies, us if you hack it to be a fast interrupt). N sources gets dicier, and I don't even want to think about it. You likely could also create a driver similar to the ppi driver that polled the parallel port every tick. This would give you approx 10ms accuracy and resolution, assuming that HZ is 100. Not sure how far you could push this technique. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 12:36:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by hub.freebsd.org (Postfix) with ESMTP id E1E4137B424 for ; Thu, 19 Apr 2001 12:36:17 -0700 (PDT) (envelope-from justin.wojdacki.chiplogic.com@analog.com) Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.1.5) with SMTP id for ; Thu, 19 Apr 2001 15:37:13 -0400 Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id MAA03030 for ; Thu, 19 Apr 2001 12:36:00 -0700 (PDT) Received: from chiplogic.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id MAA04542 for ; Thu, 19 Apr 2001 12:36:04 -0700 (PDT) Message-ID: <3ADF3E24.74661D46@chiplogic.com> Date: Thu, 19 Apr 2001 12:36:04 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: The future of multiprocessors (was: SMP in 2.4 (fwd)) References: <20010419121051.D72816@wantadilla.lemis.com> <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> <20010419121051.D72816@wantadilla.lemis.com> <5.1.0.14.0.20010419111106.02d68f50@vssad.hlo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Adler wrote: > > A number of our larger customers care about computation/cubic foot. The > density of processors is important to them. SMP machines work well here. > > A future Alpha processor will be an SMT (symmetric multi threaded) > machine. Above the lowest levels, it will look like a multi-CPU > machine. The machine will keep multiple thread contexts live within the > CPU and will be capable of switching between these threads in a single > cycle. As it grows harder for compilers to find parallelism within a > single thread we have had to look elsewhere to keep the machine busy. > > -Michael > FWIW: The IBM Power3 CPU (AS/400 boxen) already has multiple hardware threads. IIRC, they don't exploit them largely because the compilers and OS were having a hard time figuring out how to use them. But the hardware can do it, if they so desire. I've found this to be a good general rule: If it's worth doing in computing, IBM's probably already tried it. -- ------------------------------------------------- Justin Wojdacki justin@chiplogic.com (408) 350-5032 Communications Processors Group -- Analog Devices To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 12:42:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 8C28437B424 for ; Thu, 19 Apr 2001 12:42:21 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3JJfvU60548; Thu, 19 Apr 2001 21:41:57 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: David Miller , freebsd-hackers@FreeBSD.ORG Subject: Re: [OT] parallel port for IO? In-Reply-To: Your message of "Thu, 19 Apr 2001 13:34:17 MDT." <200104191934.f3JJYH806407@harmony.village.org> Date: Thu, 19 Apr 2001 21:41:57 +0200 Message-ID: <60546.987709317@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104191934.f3JJYH806407@harmony.village.org>, Warner Losh writes: >If you have only 1 source, then you can use the ack line of the >parallel port and the ppi driver to get timestamped events. If you >have more than one, then you might be able to wire a simple latch to >the ACK line and sample of to 8 sources. That's trickier as their's >some hair in converting the signals to pulses, worrying about races, >etc. 1 source gives you nanosecond resolution (but only ms accuracy >due to interrupt latencies, us if you hack it to be a fast interrupt). Use the pps driver and you get microsecond jitter with nanosecond resolution. The pps driver implements the RFC2783 PPS-API for timestamping external events. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 12:52:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 94BFC37B424 for ; Thu, 19 Apr 2001 12:52:32 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f3JJqL806575; Thu, 19 Apr 2001 13:52:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104191952.f3JJqL806575@harmony.village.org> To: Poul-Henning Kamp Subject: Re: [OT] parallel port for IO? Cc: David Miller , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 19 Apr 2001 21:41:57 +0200." <60546.987709317@critter> References: <60546.987709317@critter> Date: Thu, 19 Apr 2001 13:52:21 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <60546.987709317@critter> Poul-Henning Kamp writes: : Use the pps driver and you get microsecond jitter with nanosecond : resolution. While I usually see microsecond jitter, I have seen it as high as a few milliseconds when the interrupt load on the machine was high and the cpu was slow. I setup a system for a user here for pps (pulse per second signal), and he was quite upset to see the occasional spike in his data. Fast interrupts reduced the occurance of spikes from a few an hour to one a day. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 12:59:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id CBFFC37B43C for ; Thu, 19 Apr 2001 12:59:38 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3JJxMG94972; Thu, 19 Apr 2001 12:59:22 -0700 (PDT) (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: <200104191933.f3JJXDG58095@earth.backplane.com> Date: Thu, 19 Apr 2001 12:58:45 -0700 (PDT) From: John Baldwin To: Matt Dillon Subject: Re: OpenBSD's FFS/dirpref/softupdates improvements Cc: Jeremiah Gowdy , hackers@FreeBSD.org, Mike Bristow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 19-Apr-01 Matt Dillon wrote: > I've accepted the job of MFCing the dirpref stuff to -stable ... after > the 4.3 release. > > If fsck is clobbering consistently we can probably make the kernel > avoid a panic. I'll look at the issue carefully when I do the MFC. > > -Matt The problem lies in that fsck detects that the dirpref tunables differ between the alternate superblock and the first superblock, so it prompts you to overwrite the first superblock with the values in the alternate. For some reason the values in the alternate end up panic'ing the system. fsck -p doesn't exhibit this problem, IIRC, only an actual fsck or fsck -y. Having the kernel sanity check these parameters in the superblock should be sufficient. >:On 19-Apr-01 Mike Bristow wrote: >:> On Thu, Apr 19, 2001 at 08:57:37AM -0700, Jeremiah Gowdy wrote: >:>> "Two aspects of the FFS filesystem in OpenBSD have received significant >:>> improvements since 2.8, increasing performance dramatically. Thanks to >:>> art, >:>> gluk, csapuntz, and a host of other developers and testers, Soft Updates >:>> are >:>> now much more stable than ever before. The second improvement, contributed >:>> by gluk@openbsd.org, is a new directory allocation policy (codenamed >:>> "dirpref"). Coupled with soft updates, the new dirpref code offers up to a >:>> 60x speed increase in gluk's tests, documented here:" >:>> >:>> http://groups.google.com/groups?q=dirpref&num=100&hl=en&lr=&safe=off&rnum=2 >:>> & >:>> seld=905073910&ic=1 >:>> >:>> Does anyone know anything about this ? >:> >:> Commited to -current about 10 April. >:> >:> I suspect that Jordan would shoot someone who suggested a MFC before >:> 4.3 is out. >: >:It needs more work, too. If you try to use an old fsck with the new kernel, >:then the old fsck will clobber some new variables in the superblock. Then >:the >:new kernel will panic later on instead of doing a sanity check on the new >:values in the superblock and falling back to defaults if they are bogus. >:This >:is a major POLA bug and the changes shouldn't go into 4.x unless this is >:fixed. >:This breaks the recommended method of updating stable by doing the >:installworld >:after rebooting into a new kernel. >: >:-- >: >:John Baldwin -- http://www.FreeBSD.org/~jhb/ -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Thu Apr 19 13: 3: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id B46C837B424 for ; Thu, 19 Apr 2001 13:03:04 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3JK2mU60868; Thu, 19 Apr 2001 22:02:48 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: David Miller , freebsd-hackers@FreeBSD.ORG Subject: Re: [OT] parallel port for IO? In-Reply-To: Your message of "Thu, 19 Apr 2001 13:52:21 MDT." <200104191952.f3JJqL806575@harmony.village.org> Date: Thu, 19 Apr 2001 22:02:48 +0200 Message-ID: <60866.987710568@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104191952.f3JJqL806575@harmony.village.org>, Warner Losh writes: >In message <60546.987709317@critter> Poul-Henning Kamp writes: >: Use the pps driver and you get microsecond jitter with nanosecond >: resolution. > >While I usually see microsecond jitter, I have seen it as high as a >few milliseconds when the interrupt load on the machine was high and >the cpu was slow. > >I setup a system for a user here for pps (pulse per second signal), >and he was quite upset to see the occasional spike in his data. Fast >interrupts reduced the occurance of spikes from a few an hour to one a >day. The BIOS misuse of SMM mode can give you jitter in the 1msec range and there is not much you can do about it. I found out when I clocked a motherboard with a 14.318 derived from a Rb, and timed 1Hz pulses derived from a Cs. Every 400 seconds I ran into the SMM interrupt for about 10 seconds, and all my measurements were late by 800-900 microseconds :-( Intel doesn't care much for precision timing... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 13: 6:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from winston.osd.bsdi.com (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id EB30A37B423 for ; Thu, 19 Apr 2001 13:06:42 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f3JK6UM81411; Thu, 19 Apr 2001 13:06:30 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) To: dp@penix.org Cc: hackers@FreeBSD.ORG Subject: Re: Dilemma. In-Reply-To: <3ADF04E8.55D0888E@penix.org> References: <3ADF04E8.55D0888E@penix.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010419130630B.jkh@osd.bsdi.com> Date: Thu, 19 Apr 2001 13:06:30 -0700 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 11 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You probably want to use the soft updates "snapshot" mechanism to take a frozen snapshot of the filesystem state and then run your checksumming/fingerprinting scan on that. At that point it's obviously going to be divergent with the ongoing state of the filesystem if that filesystem is active, but such is generally true of any monitoring mechanism, you just want to make sure that the state doesn't change under you as you're trying to derive your "base delta" state. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 13:29:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sleipner.eiffel.dk (sub19-229.member.dsl-only.net [63.105.19.229]) by hub.freebsd.org (Postfix) with ESMTP id 6229037B43C for ; Thu, 19 Apr 2001 13:29:29 -0700 (PDT) (envelope-from Torben@ArchimedeSoft.com) Received: from ArchimedeSoft.com (sub19-225.member.dsl-only.net [63.105.19.225]) by sleipner.eiffel.dk (8.11.1/8.11.1) with ESMTP id f3TIvwN12013 for ; Sun, 29 Apr 2001 11:57:58 -0700 (PDT) (envelope-from Torben@ArchimedeSoft.com) Message-ID: <3ADF4A9E.C097EFA1@ArchimedeSoft.com> Date: Thu, 19 Apr 2001 13:29:18 -0700 From: "Torben K. Jensen" Organization: ArchimedeSoft Inc. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD Hacker List Subject: 4.2-STABLE (Feb 20): mkfifo function hangs? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Posted this on freebsd_questions yesterday, but didn't yield any responses, so I'll run the risk of being un-PC and post it here as well. My question is simple: Could there be situations when the mkfifo function might hang? I am currently developing a daemon which uses a named pipe to communicate with any second instances of it the user might attempt to start. The behavior indicating a hangup occurs when the daemon is started, has created the fifo, opened the file for reading (fopen) and then for some reason dies disgracefully in the middle of an fread call. If I subsequently try to start up my daemon again, the very same mkfifo call apparently hangs (at least that's what DDD tells me). I would expect it to return an error code instead. If anyone is interested in looking at this, but would like to see some source code, please let me know. Thanks for you time, -- Torben K. Jensen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 13:36:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id E947C37B42C for ; Thu, 19 Apr 2001 13:36:13 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id QAA13741; Thu, 19 Apr 2001 16:36:12 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.2.1.0.20010419154734.040c4ce0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 19 Apr 2001 15:57:17 -0400 To: "Jeremiah Gowdy" , "Rik van Riel" From: Dennis Subject: Re: SMP in 2.4 (fwd) Cc: "Alfred Perlstein" , "Kris Kennaway" , In-Reply-To: <007f01c0c8f7$0d2e7680$015778d8@sherline.net> References: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> <5.0.2.1.0.20010419114632.03cacdd0@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:34 PM 04/19/2001, Jeremiah Gowdy wrote: > > Your point is moot, as you already have SMP support. The question is > > whether squeezing a few extra cycles out (SMPng) is worth making the OS > > significantly more complex, particularly when more computing power is > > always on the way. > >Much of the code is being simplified and cleaned up. And it's not a "few >extra cycles". I do admit im in a vacuum here, as I havent seen any 5.0 code. Im assuming it will be as ugly and problemattic as linux (which was unfortunately how this thread got started, but some linux moron crossposting)...and thats not fair as there are much better programmers in FBSD's camp than linux's. If its done relatively transparently, then its a big win. If it makes all of the drivers a new learning experience, then its not. db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 14:55:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from canolog.ninthwonder.com (canolog.ninthwonder.com [151.199.66.142]) by hub.freebsd.org (Postfix) with SMTP id D493D37B42C for ; Thu, 19 Apr 2001 14:55:12 -0700 (PDT) (envelope-from briggs@canolog.ninthwonder.com) Received: (qmail 16871 invoked by uid 169); 19 Apr 2001 21:55:10 -0000 Date: Thu, 19 Apr 2001 17:55:08 -0400 From: Allen Briggs To: Shankar Agarwal Cc: tech-kern@netbsd.org, bsd hackers Subject: Re: Question regarding ifconfig. Message-ID: <20010419175508.J21416@canolog.ninthwonder.com> Mail-Followup-To: Shankar Agarwal , tech-kern@netbsd.org, bsd hackers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 18, 2001 at 06:31:07PM -0700, Shankar Agarwal wrote: > I have a doubt about the ifconfig file. when i am trying to configure or > change ip address on the interface. The main calls setifaddr function > which calls ioctl function with command as SIOCGIFADDR by the following > lines I think that you are misunderstanding "setifaddr". You might think that this function actually does the work of setting the interface address. It doesn't. It does, however, set a variable called "newaddr" and check to see if an address is already defined for the interface. If an address is already defined, then it sets the "clearaddr" variable. Both "newaddr" and "clearaddr" are used in main(). Search for all uses of those two variables and you might find a little more clarity... -allen -- Allen Briggs briggs@wasabisystems.com http://www.wasabisystems.com/ Quality NetBSD CDs, Sales, Support, Service NetBSD dev. for _your_ Alpha, ARM, M68K, MIPS, PowerPC, SH3, Sparc, x86, etc... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 15:11:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.zembu.com (nat.zembu.com [209.128.96.253]) by hub.freebsd.org (Postfix) with ESMTP id 69E4437B43C for ; Thu, 19 Apr 2001 15:11:22 -0700 (PDT) (envelope-from wrstuden@zembu.com) Received: from mx-router.z.zembu.com (mx-router.z.zembu.com [172.16.0.104]) by mx2.zembu.com (Postfix) with ESMTP id 1B921AB001; Thu, 19 Apr 2001 15:11:22 -0700 (PDT) Received: from candlekeep.home-net.internetconnect.net (209-128-96-246.bayarea.net [209.128.96.246]) by mx-router.z.zembu.com (Postfix) with ESMTP id C249743D01; Thu, 19 Apr 2001 15:11:21 -0700 (PDT) Received: by candlekeep.home-net.internetconnect.net (Postfix, from userid 100) id 072C11B9D2; Thu, 19 Apr 2001 14:08:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by candlekeep.home-net.internetconnect.net (Postfix) with ESMTP id 058451A28C; Thu, 19 Apr 2001 14:08:54 -0700 (PDT) Date: Thu, 19 Apr 2001 14:08:54 -0700 (PDT) From: Bill Studenmund X-Sender: wrstuden@candlekeep.home-net.internetconnect.net To: Shankar Agarwal Cc: tech-kern@netbsd.org, bsd hackers Subject: Re: Question regarding ifconfig. In-Reply-To: <3ADE3FDB.E082BC69@net.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Apr 2001, Shankar Agarwal wrote: > Hi All, First off, you have sent mail to two different *BSD groups. While we have a common history and share features back and forth over time, you really should limit this message to the group from which you are using code. > I have a doubt about the ifconfig file. when i am trying to configure or > change ip address on the interface. The main calls setifaddr function > which calls ioctl function with command as SIOCGIFADDR by the following > lines > ifr->ifr_addr.sa_family = afp->af_af; > if (ioctl(s, afp->af_gifaddr, afp->af_ridreq) == 0) > clearaddr = 1; > Now i don't understand why the ioctl is called by SIOCGIFADDR when i am > configuring an ip address on the interface. Moreover i believe that when That's because that ioctl is not adding the new address, it is looking to see if there is an existing one. > ioctl returns successfully it returns 0 so the clearaddr will be set and > later on the ip address will be deleted. Any existing IP address will be deleted. If there already is an address, you need to get rid of it before you can add/set the new one. > Please help me out if i am interpreting it wrong as i am not able to > assign an ip address to the interface in my ported code. At least in the NetBSD version, I think the action is in the code block right after the if (clearaddr) { }. That next block is the one which will set the address. Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 18:16:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 5B42A37B423; Thu, 19 Apr 2001 18:16:16 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 410E16ACBA; Fri, 20 Apr 2001 10:46:14 +0930 (CST) Date: Fri, 20 Apr 2001 10:46:14 +0930 From: Greg Lehey To: John Baldwin Cc: Dennis , freebsd-hackers@FreeBSD.org, Kris Kennaway , Alfred Perlstein , Rik van Riel Subject: Re: SMP in 2.4 (fwd) Message-ID: <20010420104614.C72002@wantadilla.lemis.com> References: <5.0.2.1.0.20010419114632.03cacdd0@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Apr 19, 2001 at 10:10:51AM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 19 April 2001 at 10:10:51 -0700, John Baldwin wrote: > > On 19-Apr-01 Dennis wrote: >> I understand there is a language thing, but I went out of my way to say >> that i wasnt saying that SMP shouldnt be supported. It already is, and its >> been done very cleanly in a way that doesnt compromise the integrity of the >> OS internals. > > Actually, it's done in about the most inefficient manner possible, to be > brutally honest. The first stage of the SMP support focused more on getting > the machine to run than on getting it to perform well. You really should go do > some actual research on SMP before spouting off. I highly recommend Curt > Schimmel's _Unix Systems for Modern Architectures_: Caching and SMP for Kernel > Programmers. If you read it, you will find that our current implementation is > actually worse than a master/slave kernel setup, which is the slowest one > mentioned in the book. :( Well, no, it does mention our approach as being the slowest, even slower than master-slave :-) Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 18:26: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 0989E37B423; Thu, 19 Apr 2001 18:26:02 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f3K1PuK19503; Thu, 19 Apr 2001 18:25:56 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f3K1O2331600; Thu, 19 Apr 2001 18:24:02 -0700 (PDT) (envelope-from jhb) 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 Date: Thu, 19 Apr 2001 18:24:01 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: hackers@FreeBSD.org Subject: Patch to change pfind() to lock the process it returns Cc: des@FreeBSD.org, yokota@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The pfind() and zpfind() functions obtain a shared lock while accessing the PID hash table and zombie process lists so that they will have a consistent list to work with while searching for a process. However, since these functions release the lock before returning, there is a race condition whereby a process may be modified in between the time that pfind() locates it and releases its lock and the time that the process that called pfind() gets a pointer to said process. One solution is to require all callers of pfind() and zpfind() to acquire the shared allproc lock before calling the function and then to release it after taking appropriate measures with the returned process. However, this is somewhat painful for users of pfind(). Thus, I've chosen instead to change pfind() and zpfind() use the PROC_LOCK() macro to lock the process that they find before they release the allproc lock and return. Note that if pfind() and zpfind() return NULL, there is no process to lock. This patch changes pfind() and zpfind() to follow this behavior and attempts to adjust all callers of pfind() and zpfind() appropriately. I've attempted to cc appropriate maintainers as well as the list as this change does touch a few areas. Some cases of pfind() in the system can probably be eliminated or changed to use a simpler algorithm, but I'd prefer that that discussion happen later. For now, please review the patch below for correctness, etc.: http://www.FreeBSD.org/~jhb/patches/pfind.patch Thanks. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "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 Thu Apr 19 18:33: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 648D837B43C for ; Thu, 19 Apr 2001 18:33:01 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f3K1WEK19784; Thu, 19 Apr 2001 18:32:14 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f3K1UKT31669; Thu, 19 Apr 2001 18:30:20 -0700 (PDT) (envelope-from jhb) 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: <20010420104614.C72002@wantadilla.lemis.com> Date: Thu, 19 Apr 2001 18:30:20 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Greg Lehey Subject: Re: SMP in 2.4 (fwd) Cc: Rik van Riel , Alfred Perlstein , Kris Kennaway , freebsd-hackers@FreeBSD.org, Dennis Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 20-Apr-01 Greg Lehey wrote: > On Thursday, 19 April 2001 at 10:10:51 -0700, John Baldwin wrote: >> >> On 19-Apr-01 Dennis wrote: >>> I understand there is a language thing, but I went out of my way to say >>> that i wasnt saying that SMP shouldnt be supported. It already is, and its >>> been done very cleanly in a way that doesnt compromise the integrity of the >>> OS internals. >> >> Actually, it's done in about the most inefficient manner possible, to be >> brutally honest. The first stage of the SMP support focused more on getting >> the machine to run than on getting it to perform well. You really should go >> do >> some actual research on SMP before spouting off. I highly recommend Curt >> Schimmel's _Unix Systems for Modern Architectures_: Caching and SMP for >> Kernel >> Programmers. If you read it, you will find that our current implementation >> is >> actually worse than a master/slave kernel setup, which is the slowest one >> mentioned in the book. :( > > Well, no, it does mention our approach as being the slowest, even > slower than master-slave :-) Ah, so it does. :) In fact, the last few lines read: "This situation is made worse by the fact that the processor already holding the lock continues to hold it if it context-switches to another kernel-mode process, making it possible to lock other processors out of the kernel for indefinite periods of time. Situations like these must be avoided in any practical MP kernel implementation." Oops. :) Just to clarify, however, I'm not trying to say that the initial SMP effort was a bad thing. We didn't run at all on SMP hardware before the Giant lock. The implementation can stand some improvement is all. I doubt that SMPng will be perfect as well. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "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 Thu Apr 19 18:59:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E20A237B42C for ; Thu, 19 Apr 2001 18:59:31 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3K1x9Y22406; Thu, 19 Apr 2001 18:59:09 -0700 (PDT) Date: Thu, 19 Apr 2001 18:59:09 -0700 From: Alfred Perlstein To: Dennis Cc: Jeremiah Gowdy , Rik van Riel , Kris Kennaway , freebsd-hackers@FreeBSD.ORG Subject: Re: SMP in 2.4 (fwd) Message-ID: <20010419185909.K976@fw.wintelcom.net> References: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com> <5.0.2.1.0.20010419114632.03cacdd0@mail.etinc.com> <007f01c0c8f7$0d2e7680$015778d8@sherline.net> <5.0.2.1.0.20010419154734.040c4ce0@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.0.20010419154734.040c4ce0@mail.etinc.com>; from dennis@etinc.com on Thu, Apr 19, 2001 at 03:57:17PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dennis [010419 13:36] wrote: > At 01:34 PM 04/19/2001, Jeremiah Gowdy wrote: > > > > > Your point is moot, as you already have SMP support. The question is > > > whether squeezing a few extra cycles out (SMPng) is worth making the OS > > > significantly more complex, particularly when more computing power is > > > always on the way. > > > >Much of the code is being simplified and cleaned up. And it's not a "few > >extra cycles". > > > I do admit im in a vacuum here, as I havent seen any 5.0 code. Im assuming > it will be as ugly and problemattic as linux (which was unfortunately how > this thread got started, but some linux moron crossposting)...and thats not > fair as there are much better programmers in FBSD's camp than linux's. If > its done relatively transparently, then its a big win. If it makes all of > the drivers a new learning experience, then its not. Look spanky, just take a look at the wi driver ok? There, was that all too difficult? -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 21:12:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 2724C37B423; Thu, 19 Apr 2001 21:12:45 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 3E0E228AE2; Fri, 20 Apr 2001 11:12:39 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 3116B28676; Fri, 20 Apr 2001 11:12:39 +0700 (ALMST) Date: Fri, 20 Apr 2001 11:12:39 +0700 (ALMST) From: Boris Popov To: John Baldwin Cc: Mike Bristow , hackers@FreeBSD.org, Jeremiah Gowdy Subject: Re: OpenBSD's FFS/dirpref/softupdates improvements In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 19 Apr 2001, John Baldwin wrote: > > I suspect that Jordan would shoot someone who suggested a MFC before > > 4.3 is out. > > It needs more work, too. If you try to use an old fsck with the new kernel, > then the old fsck will clobber some new variables in the superblock. Then the > new kernel will panic later on instead of doing a sanity check on the new > values in the superblock and falling back to defaults if they are bogus. This > is a major POLA bug and the changes shouldn't go into 4.x unless this is fixed. > This breaks the recommended method of updating stable by doing the installworld > after rebooting into a new kernel. On other hand, it makes some troubles if filesystem is shared between 4.x and -current :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 21:59:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D4DB437B42C for ; Thu, 19 Apr 2001 21:59:50 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f3K4xj809936; Thu, 19 Apr 2001 22:59:45 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104200459.f3K4xj809936@harmony.village.org> To: Poul-Henning Kamp Subject: Re: [OT] parallel port for IO? Cc: David Miller , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 19 Apr 2001 22:02:48 +0200." <60866.987710568@critter> References: <60866.987710568@critter> Date: Thu, 19 Apr 2001 22:59:45 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <60866.987710568@critter> Poul-Henning Kamp writes: : The BIOS misuse of SMM mode can give you jitter in the 1msec range : and there is not much you can do about it. I found out when I : clocked a motherboard with a 14.318 derived from a Rb, and timed : 1Hz pulses derived from a Cs. Every 400 seconds I ran into the : SMM interrupt for about 10 seconds, and all my measurements were : late by 800-900 microseconds :-( : : Intel doesn't care much for precision timing... Agreed. SMM wasn't turned on on this machine. But there was a disk drive that every so often would hammer as a different application would core dump. During the core dump, interrupt latency went way up for reasons I don't understand. The CPU was a tiny 486 133MHz underclocked to 100MHz for cooling. The pentium systems were much better about this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 22: 3:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 6F48237B423 for ; Thu, 19 Apr 2001 22:03:08 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3K4n7U66169; Fri, 20 Apr 2001 06:49:07 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: David Miller , freebsd-hackers@FreeBSD.ORG Subject: Re: [OT] parallel port for IO? In-Reply-To: Your message of "Thu, 19 Apr 2001 22:59:45 MDT." <200104200459.f3K4xj809936@harmony.village.org> Date: Fri, 20 Apr 2001 06:49:07 +0200 Message-ID: <66167.987742147@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104200459.f3K4xj809936@harmony.village.org>, Warner Losh writes: >In message <60866.987710568@critter> Poul-Henning Kamp writes: >: The BIOS misuse of SMM mode can give you jitter in the 1msec range >: and there is not much you can do about it. I found out when I >: clocked a motherboard with a 14.318 derived from a Rb, and timed >: 1Hz pulses derived from a Cs. Every 400 seconds I ran into the >: SMM interrupt for about 10 seconds, and all my measurements were >: late by 800-900 microseconds :-( >: >: Intel doesn't care much for precision timing... > >Agreed. SMM wasn't turned on on this machine. But there was a disk >drive that every so often would hammer as a different application >would core dump. During the core dump, interrupt latency went way up >for reasons I don't understand. The CPU was a tiny 486 133MHz >underclocked to 100MHz for cooling. Then the disk is probably running in PIO mode which thrashes your interrrupts. >The pentium systems were much better about this. Probably because it ran DMA... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 19 22: 5:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (adam042-060.resnet.wisc.edu [146.151.42.60]) by hub.freebsd.org (Postfix) with ESMTP id F0A9437B422 for ; Thu, 19 Apr 2001 22:05:41 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 25261 invoked by uid 1000); 20 Apr 2001 05:05:38 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Apr 2001 05:05:38 -0000 Date: Fri, 20 Apr 2001 00:05:38 -0500 (CDT) From: Mike Silbersack To: Boris Popov Cc: John Baldwin , Mike Bristow , , Jeremiah Gowdy Subject: Re: OpenBSD's FFS/dirpref/softupdates improvements In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Apr 2001, Boris Popov wrote: > On Thu, 19 Apr 2001, John Baldwin wrote: > > > It needs more work, too. If you try to use an old fsck with the new kernel, > > then the old fsck will clobber some new variables in the superblock. Then the > > new kernel will panic later on instead of doing a sanity check on the new > > values in the superblock and falling back to defaults if they are bogus. This > > is a major POLA bug and the changes shouldn't go into 4.x unless this is fixed. > > This breaks the recommended method of updating stable by doing the installworld > > after rebooting into a new kernel. > > On other hand, it makes some troubles if filesystem is shared > between 4.x and -current :) > > -- > Boris Popov Hm, something just struck me. a) Why is fsck checking fields that it doesn't know as anything other than filler? b) When it says that the alternate superblock doesn't match, is that really true? If so, why isn't that being updated? Of course the kernel should sanity check the values so it doesn't panic, but making fsck not louse up future filesystem changes seems prudent as well. (If that's feasible.) 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 Apr 19 22: 7:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6555237B424 for ; Thu, 19 Apr 2001 22:07:57 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f3K57q810028; Thu, 19 Apr 2001 23:07:52 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104200507.f3K57q810028@harmony.village.org> To: Poul-Henning Kamp Subject: Re: [OT] parallel port for IO? Cc: David Miller , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 20 Apr 2001 06:49:07 +0200." <66167.987742147@critter> References: <66167.987742147@critter> Date: Thu, 19 Apr 2001 23:07:52 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <66167.987742147@critter> Poul-Henning Kamp writes: : Then the disk is probably running in PIO mode which thrashes your : interrrupts. That's likely right. This was a real low end machine, designed to be smalffl and cheap. : >The pentium systems were much better about this. : : Probably because it ran DMA... Yes. And a higher clock rate. And faster memory. And no disk (CF only, but that was read only). And more memory. Wanrer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 0:32:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id E905E37B43E for ; Fri, 20 Apr 2001 00:32:14 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [63.198.170.139]) by bazooka.unixfreak.org (Postfix) with ESMTP id 93BD43E09; Fri, 20 Apr 2001 00:32:14 -0700 (PDT) To: Dan Nelson Cc: hackers@FreeBSD.ORG Subject: Re: Restricting the console to one vty (patch) In-Reply-To: <20010418092731.B733@dan.emsphone.com>; from dnelson@emsphone.com on "Wed, 18 Apr 2001 09:27:31 -0500" Date: Fri, 20 Apr 2001 00:32:14 -0700 From: Dima Dorfman Message-Id: <20010420073214.93BD43E09@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson writes: > In the last episode (Apr 18), Dima Dorfman said: > > Attached is a patch that makes it possible to restrict (``freeze'') > > the console to a single vty (the active one). This can be used in > > conjunction with, e.g., lock(1) to setup a relative safeguard against > > malicious access while the user is away from his terminal (lock(1) > > alone doesn't help unless the user wants to do it for every vty he's > > logged into, which quickly gets repetitive). I believe this would be > > especially useful for laptops. > > Isn't there already support for this? > > [ snip definition of struct vt_mode ] > > If you call VT_SETMODE and tell the console that screen switching is > VT_PROCESS, that will disable VTY switching (libvgl sets this so it can > disable graphics mode when the user wants to switch screens). It doesn't do quite what's needed in this case. This mechanism is intended to notify processes when the user wants to switch screens, not to allow the process to stop the switch. It can be used that way, but 1) the process must be in the foreground on that terminal, so if it is used it'd have to be built into lock(1) or some such; and 2) if you do try to switch the screen while it's active, weird stuff starts happening; e.g., all input to the program running stops for a while, then restarts. I don't know if this is how it's supposed to work (although that may very well be the case, since all the program should be doing is releasing resources to allow the switch to happen), but esp. the latter makes it kind of useless for this purpose. Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 0:34: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id BD21637B43C for ; Fri, 20 Apr 2001 00:34:05 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3K7Y5E01377 for hackers@freebsd.org; Fri, 20 Apr 2001 00:34:05 -0700 (PDT) Date: Fri, 20 Apr 2001 00:34:05 -0700 From: Alfred Perlstein To: hackers@freebsd.org Subject: junior kernel hacker assignment. Message-ID: <20010420003405.B595@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From time to time I see Poul-Henning post a junior hacker assignment to this list, so I figured I'd make the same use of the bandwidth and mindshare. A while back OpenBSD "optimized" thier implementation of fdalloc() buy using a complex two level bitmask to track open slots in the descriptor table. After the implementation was ported to FreeBSD it was discovered that it actually had a negative impact on performance as world builds seemed to slow down slightly. An alternative possible optimization would be to overload the fd_ofiles array to also be a union of pointers to empty slots in the fd_ofiles array. It's not as easy as it sounds because you must make it into a doubly linked list so that entries can be removed from arbitrary locations so the freelist is kept consistant. Another trick could be overloading the fd_ofileflags to be the corresponding back-pointer, this would require that both arrays fd_ofiles and fd_ofileflags become unions and it would bloat fd_ofileflags by 4x, but that would save 25% of the bloat of doubling the size requirement of fd_ofiles. If anyone wants to take a crack at doing this it'd be interesting to see the results. I know it will cost at least doubling the size of fd_ofiles, but the speed of lookups especially for programs with a large amount of open files could be signifigant. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 1:15:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 989F337B424 for ; Fri, 20 Apr 2001 01:15:36 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [63.198.170.139]) by bazooka.unixfreak.org (Postfix) with ESMTP id CE1113E09 for ; Fri, 20 Apr 2001 01:15:35 -0700 (PDT) To: hackers@freebsd.org Subject: cut(1) and long lines Date: Fri, 20 Apr 2001 01:15:35 -0700 From: Dima Dorfman Message-Id: <20010420081535.CE1113E09@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Attached is a rather short patch to make cut(1) properly deal with long lines. Basically, it converts it to use fgetln() instead of fgets(). An an aside, this also fixed the case where the last line doesn't have a trailing newline. Note that specifying a list over 2048 on the command line (e.g., the -f option) still isn't supported, but at least cut(1) doesn't choke when you want the second token but feed it a couple thousand characters in one line. Comments? Thanks, Dima Dorfman dima@unixfreak.org Index: cut.c =================================================================== RCS file: /st/src/FreeBSD/src/usr.bin/cut/cut.c,v retrieving revision 1.12 diff -u -r1.12 cut.c --- cut.c 2001/02/06 20:03:48 1.12 +++ cut.c 2001/04/20 07:58:59 @@ -228,19 +228,22 @@ int ch, field, isdelim; char *pos, *p, sep; int output; - char lbuf[_POSIX2_LINE_MAX + 1]; + char *lbuf; + size_t lbuflen; - for (sep = dchar; fgets(lbuf, sizeof(lbuf), fp);) { + for (sep = dchar; (lbuf = fgetln(fp, &lbuflen)) != NULL;) { + /* Assert EOL has a newline. */ + if (*(lbuf + lbuflen - 1) != '\n') + *(lbuf + lbuflen) = '\n'; output = 0; - for (isdelim = 0, p = lbuf;; ++p) { - if (!(ch = *p)) - errx(1, "%s: line too long.", fname); + for (isdelim = 0, p = lbuf; p < lbuf + lbuflen; ++p) { + ch = *p; /* this should work if newline is delimiter */ if (ch == sep) isdelim = 1; if (ch == '\n') { if (!isdelim && !sflag) - (void)printf("%s", lbuf); + (void)fwrite(lbuf, lbuflen, 1, stdout); break; } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 2:30: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id ABCFE37B422 for ; Fri, 20 Apr 2001 02:29:58 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3K9Tcs84983; Fri, 20 Apr 2001 02:29:38 -0700 (PDT) (envelope-from obrien) Date: Fri, 20 Apr 2001 02:29:38 -0700 From: "David O'Brien" To: scanner@jurai.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium Message-ID: <20010420022937.B84772@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <000001c0c777$f9529b30$215778d8@cx443070b> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from scanner@jurai.net on Tue, Apr 17, 2001 at 03:57:37PM -0400 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 X-Loop: FreeBSD.ORG On Tue, Apr 17, 2001 at 03:57:37PM -0400, scanner@jurai.net wrote: > I would like to see this too, however I think you have to sign NDA's and > the like to be a part of the AMD effort to develop for it. Understandable > I guess. Yes. I now have a copy of the Virtutech Simics x86-64 simulator. That is all I'm prepared to say at this point. > Also they only seem interested in boosting Linux adoption of the > new AMD 64 bit procs. *shrug* NOT IN THE LEAST!!! Please do not spread this FUD before asking. There will be a FreeBDS logo at www.x86-64.org as soon as the FreeBSD Project can get a webpage up describing our plans and effort for it to link to. I could really use some help in this area. -- -- David (obrien@BSDi.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 2:31: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 1A1F537B422 for ; Fri, 20 Apr 2001 02:31:03 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3K9UxD85019; Fri, 20 Apr 2001 02:30:59 -0700 (PDT) (envelope-from obrien) Date: Fri, 20 Apr 2001 02:30:59 -0700 From: "David O'Brien" To: Jeremiah Gowdy Cc: scanner@jurai.net, freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium Message-ID: <20010420023059.C84772@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <001001c0c782$5683ad80$215778d8@cx443070b> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001001c0c782$5683ad80$215778d8@cx443070b>; from jgowdy@home.com on Tue, Apr 17, 2001 at 02:06:56PM -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 X-Loop: FreeBSD.ORG On Tue, Apr 17, 2001 at 02:06:56PM -0700, Jeremiah Gowdy wrote: > I'm talking about FreeBSD using the gcc x86-64 compiler to port > FreeBSD to x86-64. What other compiler would we use?? I have access to the SuSE x96-64 compiler effort. > I'm talking about a FreeBSD project to port to x86-64. I'm not talking. I'm doing. -- -- David (obrien@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 Apr 20 2:34:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 1B50437B423; Fri, 20 Apr 2001 02:34:14 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3K9XvT85088; Fri, 20 Apr 2001 02:33:57 -0700 (PDT) (envelope-from obrien) Date: Fri, 20 Apr 2001 02:33:57 -0700 From: "David O'Brien" To: Doug White Cc: John Baldwin , Andrew Gallatin , freebsd-hackers@FreeBSD.ORG, Mike Silbersack Subject: Re: x86-64 Hammer and IA64 Itainium Message-ID: <20010420023356.E84772@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dwhite@resnet.uoregon.edu on Wed, Apr 18, 2001 at 12:51:17PM -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 X-Loop: FreeBSD.ORG On Wed, Apr 18, 2001 at 12:51:17PM -0700, Doug White wrote: > (Yes I know the emulator is ass-slow and a gigantic beast, but it does > work, right?) The public simulator took 12 hours to get to the twirler of our boot loader. I guess it would have booted the i386 kernel I was feeding it in just under 2 weeks. This was on a 950MHz Athlon. -- -- David (obrien@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 Apr 20 2:47: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B9D9B37B424 for ; Fri, 20 Apr 2001 02:47:00 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3K9l0404745 for hackers@freebsd.org; Fri, 20 Apr 2001 02:47:00 -0700 (PDT) Date: Fri, 20 Apr 2001 02:47:00 -0700 From: Alfred Perlstein To: hackers@freebsd.org Subject: thttpd hack for sendfile and accept filters. Message-ID: <20010420024700.E1790@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://people.freebsd.org/~alfred/thttpd/thttpd-sendfile-acceptfilter.diff foo. :) -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 3:42:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 546C437B422 for ; Fri, 20 Apr 2001 03:42:52 -0700 (PDT) (envelope-from danny@cs.huji.ac.il) Received: from sexta.cs.huji.ac.il ([132.65.16.13] ident=exim) by cs.huji.ac.il with esmtp (Exim 3.22 #1) id 14qYNH-00069W-00 for hackers@freebsd.org; Fri, 20 Apr 2001 13:42:51 +0300 Received: from localhost ([127.0.0.1] helo=sexta.cs.huji.ac.il ident=danny) by sexta.cs.huji.ac.il with esmtp (Exim 3.15 #1) id 14qYNG-0004fw-00 for hackers@FreeBSD.org; Fri, 20 Apr 2001 13:42:50 +0300 X-Mailer: exmh version 2.2 06/23/2000 with nmh-0.24 To: hackers@FreeBSD.org Subject: 4.3-RC3 and cd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 13:42:50 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, i have a big and noisy u2 box now in my office, but the weird thing is that about every 10 minutes i can hear the cd move the head, i guess that must be it, since the box has no other moving parts - that i know of :-) btw, the cd is empty. what could be causing this? danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 4:21:12 2001 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 CD28337B42C; Fri, 20 Apr 2001 04:21:07 -0700 (PDT) (envelope-from watchman@ludd.luth.se) Received: from d1o907.telia.com (d1o907.telia.com [195.252.38.241]) by mailg.telia.com (8.11.2/8.11.0) with ESMTP id f3KBL6m06576; Fri, 20 Apr 2001 13:21:06 +0200 (CEST) Received: from ludd.luth.se (h63n2fls21o907.telia.com [213.66.203.63]) by d1o907.telia.com (8.8.8/8.8.8) with ESMTP id NAA01078; Fri, 20 Apr 2001 13:21:05 +0200 (CEST) Message-ID: <3AE01B83.702C3480@ludd.luth.se> Date: Fri, 20 Apr 2001 13:20:35 +0200 From: Joachim =?iso-8859-1?Q?Str=F6mbergson?= Organization: Acne X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en-US MIME-Version: 1.0 To: obrien@FreeBSD.ORG, freebsd-hackers Subject: Re: x86-64 Hammer and IA64 Itainium References: <000001c0c777$f9529b30$215778d8@cx443070b> <20010420022937.B84772@dragon.nuxi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Aloha! I saw your response to the ClawHammer stuff on the hackers maillist. David O'Brien wrote: k> On Tue, Apr 17, 2001 at 03:57:37PM -0400, scanner@jurai.net wrote: > > I would like to see this too, however I think you have to sign NDA's and > > the like to be a part of the AMD effort to develop for it. Understandable > > I guess. > > Yes. I now have a copy of the Virtutech Simics x86-64 simulator. > That is all I'm prepared to say at this point. Pretty good. I know some of the core team at Virtutech and emailed them about the possibility of getting access to VirtuHammer for the FreeBSD project. But, if I undestand what you are saying, then you are waay ahead of me. :-) Have anyome tried running the AMD ISS under FreeBSD? I was planning to but the rpm and rpm2cpio ports seems to be broken right now. > Please do not spread this FUD before asking. > There will be a FreeBDS logo at www.x86-64.org as soon as the FreeBSD > Project can get a webpage up describing our plans and effort for it to > link to. I could really use some help in this area. Ok. What do you want me to do? BTW, David, You had used the emulator. Could you mention what emulator it is, or is it under NDA? -- Cheers! Joachim - Alltid i harmonisk svängning --- FairLight ------ FairLight ------ FairLight ------ FairLight --- Joachim Strömbergson ASIC SoC designer, nice to CUTE animals Phone: +46(0)31 - 27 98 47 Web: http://www.ludd.luth.se/~watchman --------------- Spamfodder: regeringen@regeringen.se --------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 4:44: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B1AAD37B424 for ; Fri, 20 Apr 2001 04:44:02 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KBi2107670 for hackers@FreeBSD.ORG; Fri, 20 Apr 2001 04:44:02 -0700 (PDT) Date: Fri, 20 Apr 2001 04:44:02 -0700 From: Alfred Perlstein To: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010420044402.L1790@fw.wintelcom.net> References: <20010420024700.E1790@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420024700.E1790@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Apr 20, 2001 at 02:47:00AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alfred Perlstein [010420 02:47] wrote: > http://people.freebsd.org/~alfred/thttpd/thttpd-sendfile-acceptfilter.diff > > foo. :) First off the initial patch I put up was broken, but it now seems to work, so if you've downloaded it you might want to make sure you got the right version. Second, it looks like there's a few things in thttpd that could be optimized further. .) an access cache, it stat(2)s each file request that comes in, it could keep a short lived (one or two seconds) cache of stat() requests .) pre-forking, this would help with stalling on disk IO. .) kqueue. So anyone working on this sort of stuff? -- -Alfred Perlstein - [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 5:11:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id D176537B424 for ; Fri, 20 Apr 2001 05:11:12 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 72345 invoked by uid 1001); 20 Apr 2001 12:10:54 +0000 (GMT) To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 20 Apr 2001 04:44:02 -0700" References: <20010420044402.L1790@fw.wintelcom.net> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 20 Apr 2001 14:10:54 +0200 Message-ID: <72342.987768654@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Second, it looks like there's a few things in thttpd that could be > optimized further. ... > .) pre-forking, this would help with stalling on disk IO. Since the author of thttpd makes a point of *not* using pre-forking (and thttpd still being very fast), I'm not sure that pre-forking patches would be accepted. See http://www.acme.com/software/thttpd/ Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 5:19: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 753) id 58CFA37B423; Fri, 20 Apr 2001 05:19:01 -0700 (PDT) Date: Fri, 20 Apr 2001 05:19:01 -0700 From: Adrian Chadd To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010420051901.A66232@hub.freebsd.org> References: <20010420024700.E1790@fw.wintelcom.net> <20010420044402.L1790@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420044402.L1790@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Apr 20, 2001 at 04:44:02AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001, Alfred Perlstein wrote: > * Alfred Perlstein [010420 02:47] wrote: > > http://people.freebsd.org/~alfred/thttpd/thttpd-sendfile-acceptfilter.diff > > > > foo. :) > > First off the initial patch I put up was broken, but it now seems to > work, so if you've downloaded it you might want to make sure you got > the right version. > > Second, it looks like there's a few things in thttpd that could be > optimized further. > > .) an access cache, it stat(2)s each file request that comes in, > it could keep a short lived (one or two seconds) cache of > stat() requests > > .) pre-forking, this would help with stalling on disk IO. A small async disk IO kit would be useful. the aio_ routines don't do async open, close, lseek. They could be implemented using threads, but since our threads aren't diskio-friendly.. :-) (squid gets around this by implementing something using sysv shm/msg.. its simple enough. You might wanna look into nabbing this. I can give you a hand if you'd like.) > .) kqueue. Ahahah. > So anyone working on this sort of stuff? Me. :-) Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 5:22:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 753) id 90E2137B424; Fri, 20 Apr 2001 05:22:27 -0700 (PDT) Date: Fri, 20 Apr 2001 05:22:27 -0700 From: Adrian Chadd To: freebsd-hackers@freebsd.org Subject: adduser bikeshed Message-ID: <20010420052227.B66232@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://www.freebsd.org/~adrian/adduser.patch It adds an option which enables the password that is created. "enabling" means "don't put a * in front". Its aimed for accounts which will use non-password authentication (eg RSA/DSA). Its also aimed at sysadmins who want to create accounts but have them automatically disabled (think university admins who create shell accounts for users but want them to do training BEFORE enabling said account..) Now, the bikeshed: what should the option be? "Enable account at creation" isn't very descriptive and can be confusing. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 5:23:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 514B637B422 for ; Fri, 20 Apr 2001 05:23:41 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KCNbN08738; Fri, 20 Apr 2001 05:23:37 -0700 (PDT) Date: Fri, 20 Apr 2001 05:23:37 -0700 From: Alfred Perlstein To: sthaug@nethelp.no Cc: hackers@FreeBSD.ORG, Jef Poskanzer Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010420052337.O1790@fw.wintelcom.net> References: <20010420044402.L1790@fw.wintelcom.net> <72342.987768654@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <72342.987768654@verdi.nethelp.no>; from sthaug@nethelp.no on Fri, Apr 20, 2001 at 02:10:54PM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cc'd the author... * sthaug@nethelp.no [010420 05:11] wrote: > > Second, it looks like there's a few things in thttpd that could be > > optimized further. > ... > > .) pre-forking, this would help with stalling on disk IO. > > Since the author of thttpd makes a point of *not* using pre-forking (and > thttpd still being very fast), I'm not sure that pre-forking patches > would be accepted. > > See http://www.acme.com/software/thttpd/ I understand his reasoning, it's just that you need multiple contexts (processes) to be able to field disk IO without stalling when something isn't in memory. Basically, you want to keep the disks active, you can't do that very well with a single process unless you use aio. Matt Dillon said that he found that each child should handle about 20 connections using non-blocking IO. I imagine handling any more than that and a stall on disk would get pretty noticeable or just not be able to perform as well. The easiest way would be to have thttpd fork after listening a pre-determined amount of servers, then they'll all compete calling accept() to grab connections. What you'd loose is the ability to do the connection throttling unless you periodically communicated with a collector process that would gather stats and report when to implement throttling. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 5:29:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0A33C37B423; Fri, 20 Apr 2001 05:29:32 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KCTVo08869; Fri, 20 Apr 2001 05:29:31 -0700 (PDT) Date: Fri, 20 Apr 2001 05:29:31 -0700 From: Alfred Perlstein To: Adrian Chadd Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: adduser bikeshed Message-ID: <20010420052931.P1790@fw.wintelcom.net> References: <20010420052227.B66232@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420052227.B66232@hub.freebsd.org>; from adrian@FreeBSD.ORG on Fri, Apr 20, 2001 at 05:22:27AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Adrian Chadd [010420 05:22] wrote: > > http://www.freebsd.org/~adrian/adduser.patch > > It adds an option which enables the password that is created. > "enabling" means "don't put a * in front". Its aimed for accounts > which will use non-password authentication (eg RSA/DSA). > Its also aimed at sysadmins who want to create accounts but have > them automatically disabled (think university admins who create > shell accounts for users but want them to do training BEFORE > enabling said account..) > > Now, the bikeshed: what should the option be? > "Enable account at creation" isn't very descriptive and can be > confusing. I requested this feature and I'm thinking that the "Use passwords (y/n) [y]: " should be changed to: "Use password based authentication and enable account? (y/n)" if "n" "Do you wish to disallow password passed authentication? (y/n)" if "n" "Use an empty password? (y/n)" if "y" "Are you damn sure you want to do that? (n/n)" heh, thanks for doing this btw. -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 5:42:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wit379112.student.utwente.nl (wit379119.student.utwente.nl [130.89.232.129]) by hub.freebsd.org (Postfix) with ESMTP id 79AE537B440 for ; Fri, 20 Apr 2001 05:42:49 -0700 (PDT) (envelope-from niek@wit379112.student.utwente.nl) Received: by wit379112.student.utwente.nl (Postfix, from userid 1000) id AB86D5D3A; Fri, 20 Apr 2001 14:45:43 +0200 (CEST) Date: Fri, 20 Apr 2001 14:45:43 +0200 From: Niek Bergboer To: freebsd-hackers@freebsd.org Subject: UFS block size vs. write speed Message-ID: <20010420144543.F30241@wit379119.student.utwente.nl> Reply-To: niek@bergboer.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I've got a machine connected to a 100 MBit/FDX network and I would like to store largish (~20 MB or bigger) files on it that are downloaded from the network over a dc card. The only consideration here is speed since the files are all temporary. I'm running FreeBSD 4.3-RC1. The dc card is fine and does 9.2 MB/s. The problem arises when writing to the UFS filesystem, which makes the transfer rate drop down to 5.6 MB/s using the standard 8 kb blocksize. The problem here seems to be the combined network and disk interrupt load since writing to the filesystem from /dev/zero results in 13 MB/s rates. The issue is that -- and I'm not feeding trolls here -- that Linux 2.2 smashed up to 8.5 MB/s through... Reading from the filesystem and uploading to the network puts 8.6 MB/s through, so that's no problem. I tried to increase block-sizes on said filesystem to 64 kb, which increased the throughput to around 7 MB/s. When trying to make blocksizes 128 of 256 kb, newfs segfaults (...). So my questions: a.) Is it possible to create larger blocksizes, and would that increase write speed? b.) Are there other newfs options that I can use to increase throughput? c.) Does FreeBSD support filesystem other than UFS/FFS that allow for faster transfer rates? PS: The tests were already done with the fs mounted async. The drive in question communicates at UDMA/33 on a PIIX4 controller in an AMD K6/2 233 system. Niek Bergboer -- Conscience doth make cowards of us all. -- Shakespeare To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 5:54:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6540237B422 for ; Fri, 20 Apr 2001 05:54:28 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KCsQo09479; Fri, 20 Apr 2001 05:54:26 -0700 (PDT) Date: Fri, 20 Apr 2001 05:54:26 -0700 From: Alfred Perlstein To: niek@bergboer.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UFS block size vs. write speed Message-ID: <20010420055426.Q1790@fw.wintelcom.net> References: <20010420144543.F30241@wit379119.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420144543.F30241@wit379119.student.utwente.nl>; from niek@wit379119.student.utwente.nl on Fri, Apr 20, 2001 at 02:45:43PM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ugh, dude, please wrap lines at 70 characters. :( * Niek Bergboer [010420 05:43] wrote: > Hello, > > I've got a machine connected to a 100 MBit/FDX network and I > would like to store largish (~20 MB or bigger) files on it that > are downloaded from the network over a dc card. The only consideration > here is speed since the files are all temporary. I'm running FreeBSD > 4.3-RC1. > > > The dc card is fine and does 9.2 MB/s. The problem arises when > writing to the UFS filesystem, which makes the transfer rate drop > down to 5.6 MB/s using the standard 8 kb blocksize. The problem > here seems to be the combined network and disk interrupt load since > writing to the filesystem from /dev/zero results in 13 MB/s rates. > The issue is that -- and I'm not feeding trolls here -- that Linux > 2.2 smashed up to 8.5 MB/s through... > > Reading from the filesystem and uploading to the network puts > 8.6 MB/s through, so that's no problem. > > I tried to increase block-sizes on said filesystem to 64 kb, > which increased the throughput to around 7 MB/s. When trying to > make blocksizes 128 of 256 kb, newfs segfaults (...). > > So my questions: > > a.) Is it possible to create larger blocksizes, and would that > increase write speed? Not sure. > b.) Are there other newfs options that I can use to increase throughput? Have you tried softupdates? > c.) Does FreeBSD support filesystem other than UFS/FFS that allow > for faster transfer rates? Not afaik. > PS: The tests were already done with the fs mounted async. The > drive in question communicates at UDMA/33 on a PIIX4 controller in > an AMD K6/2 233 system. There's a couple things here. a) what version of freebsd are you using? recent versions turn of IDE write caching, you may want to turn this on, see the ata(4) manpage, remeber that it can only be set at boot time. b) how are you writing these files? perhaps we can figure a faster way to do the io? did you write the program yourself? What size writes are you doing? It's funny, but you have the ideal system for an interesting optimization I've always wanted to try. Since you seem to be reading over the network, have you tried doing this, creating the file and then using ftruncate on it to extend it, then use mmap() and read directly from the socket into the mmap'd area. You may have to experiment with several different madvise() flags to get optimal performance. Or you may discover that doing this "trick" actually makes performance worse because of the way the trick screws with what the vm system expects. I think a combination of MADV_SEQUENTIAL and/or MADV_WILLNEED could do the trick. -- -Alfred Perlstein - [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 6:17:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wit379112.student.utwente.nl (wit379119.student.utwente.nl [130.89.232.129]) by hub.freebsd.org (Postfix) with ESMTP id D404337B42C for ; Fri, 20 Apr 2001 06:17:34 -0700 (PDT) (envelope-from niek@wit379112.student.utwente.nl) Received: by wit379112.student.utwente.nl (Postfix, from userid 1000) id CA2DF5D3A; Fri, 20 Apr 2001 15:20:29 +0200 (CEST) Date: Fri, 20 Apr 2001 15:20:29 +0200 From: Niek Bergboer To: Alfred Perlstein Cc: freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010420152029.A35974@wit379119.student.utwente.nl> Reply-To: niek@bergboer.net References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420055426.Q1790@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Apr 20, 2001 at 05:54:26AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 05:54:26AM -0700, Alfred Perlstein wrote: > * Niek Bergboer [010420 05:43] wrote: > > b.) Are there other newfs options that I can use to increase throughput? > Have you tried softupdates? Isn't it true that softupdates only work when filesystems are mounted sync? Or does it also improve performance when filesystems are mounted async? > > PS: The tests were already done with the fs mounted async. The > > drive in question communicates at UDMA/33 on a PIIX4 controller in > > an AMD K6/2 233 system. > There's a couple things here. > a) what version of freebsd are you using? > recent versions turn of IDE write caching, you may want to turn > this on, see the ata(4) manpage, remeber that it can only be set > at boot time. To be fully informative: FreeBSD wit379119.student.utwente.nl 4.3-RC FreeBSD 4.3-RC #0: Mon Apr 9 16:23:30 CEST 2001 root@wit379119.student.utwente.nl:/usr/obj/usr/src/sys/WUTRA1 i386 Indeed, write caching (hw.ata.wc) was set to zero some time ago, but the loader in configured to enable it at boot time: $ sysctl hw.ata.wc hw.ata.wc: 1 > b) how are you writing these files? perhaps we can figure a faster > way to do the io? did you write the program yourself? What size > writes are you doing? At the moment the files are transferred using FTP. In fact, now matter what optimisation, the files _must_ be transferred using FTP because of interoperability constraints within my network environment, so that cannot be changed. > It's funny, but you have the ideal system for an interesting > optimization I've always wanted to try. Since you seem to be > reading over the network, have you tried doing this, creating > the file and then using ftruncate on it to extend it, then use > mmap() and read directly from the socket into the mmap'd area. I must say that I'm not so much of a system programmer, but I guess that changes to the ftp-client should be relatively easy. I'll look into it when I have so time. > You may have to experiment with several different madvise() flags > to get optimal performance. Or you may discover that doing this > "trick" actually makes performance worse because of the way > the trick screws with what the vm system expects. > I think a combination of MADV_SEQUENTIAL and/or MADV_WILLNEED > could do the trick. Thank you for your input. As I said, it might take some time before I've implemented this, so please do not expect results too fast. Niek Bergboer -- Conscience doth make cowards of us all. -- Shakespeare To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 6:30:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tango.entreri.com (tango.entreri.com [205.219.158.250]) by hub.freebsd.org (Postfix) with ESMTP id 1127437B42C for ; Fri, 20 Apr 2001 06:30:13 -0700 (PDT) (envelope-from dp@penix.org) Received: from penix.org (Toronto-ppp221365.sympatico.ca [64.228.106.182]) by tango.entreri.com (8.10.2/8.9.1) with ESMTP id f3KDTn121656; Fri, 20 Apr 2001 08:30:03 -0500 Message-ID: <3AE03CA9.736E15AA@penix.org> Date: Fri, 20 Apr 2001 09:42:01 -0400 From: Paul Halliday X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: Jordan Hubbard Cc: hackers@FreeBSD.ORG Subject: Re: Dilemma. References: <3ADF04E8.55D0888E@penix.org> <20010419130630B.jkh@osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard wrote: > > You probably want to use the soft updates "snapshot" mechanism to take > a frozen snapshot of the filesystem state and then run your > checksumming/fingerprinting scan on that. > Ok, that sounds like a good idea. Not really knowing what this was I went and read http://www.mckusick.com/softdep. Clever and interesting however this doc seemed to pertain to theory only. I performed a little browse on the mailing list and found nothing very relevent on softupdates ie. semantics. I checked /usr/src/sys/ufs/ffs and their was a softupdates readme that just covers tunefs (enabling soft updates) and a URL which offered more theory. So, just how would I create this snapshot? > - Jordan > > Paul Halliday ============================================================================ Don't underestimate the power of stupid people in large groups. Web: http://dp.penix.org Current Project: http://dp.penix.org/cl.html Public Key available here: http://dp.penix.org/dp.txt ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 7: 5:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4A39B37B42C for ; Fri, 20 Apr 2001 07:05:16 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KE5EG11273; Fri, 20 Apr 2001 07:05:14 -0700 (PDT) Date: Fri, 20 Apr 2001 07:05:14 -0700 From: Alfred Perlstein To: niek@bergboer.net Cc: freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010420070514.R1790@fw.wintelcom.net> References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420152029.A35974@wit379119.student.utwente.nl>; from niek@wit379119.student.utwente.nl on Fri, Apr 20, 2001 at 03:20:29PM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG you really need to try harder to wrap lines properly. * Niek Bergboer [010420 06:17] wrote: > On Fri, Apr 20, 2001 at 05:54:26AM -0700, Alfred Perlstein wrote: > > * Niek Bergboer [010420 05:43] wrote: > > > b.) Are there other newfs options that I can use to increase throughput? > > Have you tried softupdates? > > Isn't it true that softupdates only work when filesystems are mounted sync? Or does it > also improve performance when filesystems are mounted async? It really depends on how temporary those files are. Softupdates can realize when a disk IO never needs to happen where async can't do that. > > > PS: The tests were already done with the fs mounted async. The > > > drive in question communicates at UDMA/33 on a PIIX4 controller in > > > an AMD K6/2 233 system. > > There's a couple things here. > > > a) what version of freebsd are you using? > > recent versions turn of IDE write caching, you may want to turn > > this on, see the ata(4) manpage, remeber that it can only be set > > at boot time. > > To be fully informative: > FreeBSD wit379119.student.utwente.nl 4.3-RC FreeBSD 4.3-RC #0: Mon Apr 9 16:23:30 CEST 2001 root@wit379119.student.utwente.nl:/usr/obj/usr/src/sys/WUTRA1 i386 > > Indeed, write caching (hw.ata.wc) was set to zero some time ago, but the loader in configured to > enable it at boot time: > > $ sysctl hw.ata.wc > hw.ata.wc: 1 ok, what do the disks probe as? > > b) how are you writing these files? perhaps we can figure a faster > > way to do the io? did you write the program yourself? What size > > writes are you doing? > > At the moment the files are transferred using FTP. In fact, now matter what optimisation, the > files _must_ be transferred using FTP because of interoperability constraints within my network > environment, so that cannot be changed. What ftp server are you using? > > It's funny, but you have the ideal system for an interesting > > optimization I've always wanted to try. Since you seem to be > > reading over the network, have you tried doing this, creating > > the file and then using ftruncate on it to extend it, then use > > mmap() and read directly from the socket into the mmap'd area. > > I must say that I'm not so much of a system programmer, but I guess that changes to the > ftp-client should be relatively easy. I'll look into it when I have so time. Wait, are you using an ftp server or client? Which "end" is on the FreeBSD box? Have you tried upping the socketbuffer size? What about turning on fast tcp? (it's one of the sysctl rfc options) > > You may have to experiment with several different madvise() flags > > to get optimal performance. Or you may discover that doing this > > "trick" actually makes performance worse because of the way > > the trick screws with what the vm system expects. > > I think a combination of MADV_SEQUENTIAL and/or MADV_WILLNEED > > could do the trick. > > Thank you for your input. As I said, it might take some time before I've implemented this, so > please do not expect results too fast. k :) -- -Alfred Perlstein - [alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 7:36:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chmod.ath.cx (CC2-861.charter-stl.com [24.217.115.99]) by hub.freebsd.org (Postfix) with ESMTP id 9B69037B42C for ; Fri, 20 Apr 2001 07:36:56 -0700 (PDT) (envelope-from ajh3@chmod.ath.cx) Received: by chmod.ath.cx (Postfix, from userid 1001) id 6A86DA924; Fri, 20 Apr 2001 09:35:30 -0500 (CDT) Date: Fri, 20 Apr 2001 09:35:30 -0500 From: Andrew Hesford To: niek@bergboer.net Cc: Alfred Perlstein , freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010420093530.A98970@cec.wustl.edu> References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420152029.A35974@wit379119.student.utwente.nl>; from niek@wit379119.student.utwente.nl on Fri, Apr 20, 2001 at 03:20:29PM +0200 X-Loop: Andrew Hesford Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 03:20:29PM +0200, Niek Bergboer wrote: > Isn't it true that softupdates only work when filesystems are mounted > sync? Or does it also improve performance when filesystems are > mounted async? The other guy was right; you really do need to wrap text at around 70 lines (I have vim wrap at 72). When I try to reply to messages, it messes up the reply text. I don't send out messages with screwed-up line breaks, so I'm not going to help in the future if the formatting is bad. Soft updates isn't an "async" or "sync" thing. It combines synchronous and asynchronous transfers. If I'm not mistaken, all metadata is synchronously written, and all data is asynchronously written. It also orders writes so that blocks are allocated before inodes, and inodes before directory entries. This is why fsck is so fast: if a directory entry exists for an inode, the file is known to be consistent, so fsck only needs to check for claimed inodes that don't have directory entries, and check the free-block bitmap for used blocks that don't have inodes claiming them. Something like ext2, on the other hand, must check every directory entry, every inode, and every free block to make sure it is allocated properly. This is much slower. But I digress... Since metadata is typically small compared to data, particularly in your case, the synchronous transfers are trivial. According to one paper on FFS with soft updates, I think my Marshall Kirk McKusick, the file system speed approaches that of a memory filesystem. Mounting the partition async would definitely speed up I/O. If you didn't see a noticible gain in network throughput, that tells you the bottleneck is somewhere else. Remember, too, that a network operating at a raw 9Mbits/sec is going to be slower in real-world transfer rates, because transfer protocols have overhead, breaking data into packets and reassembling it takes time, and other things. -- Andrew Hesford ajh3@chmod.ath.cx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 7:40: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id C370A37B422; Fri, 20 Apr 2001 07:39:45 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from vic.sabbo.net (dialup14-27.iptelecom.net.ua [212.9.229.91]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id RAA87242; Fri, 20 Apr 2001 17:39:39 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.3/8.11.2) with ESMTP id f3KEd1228351; Fri, 20 Apr 2001 17:39:01 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3AE049FC.60613D17@FreeBSD.org> Date: Fri, 20 Apr 2001 17:38:52 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: audit@FreeBSD.org Cc: hackers@FreeBSD.org Subject: Merging ln(1) ``-h'' option from NetBSD [patch] Content-Type: multipart/mixed; boundary="------------9D96218EA2955EAD73F8C911" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------9D96218EA2955EAD73F8C911 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Please somebody take a look at attached patch that adds ``-h'' option to the ln(1) command (obtained from NetBSD, which has it since 1997). In addition, I've tried to minimise diffs between our code and NetBSD's one, so there are several changes that at a first glance look superfluous. -Maxim --------------9D96218EA2955EAD73F8C911 Content-Type: text/plain; charset=koi8-r; name="ln.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ln.diff" Index: ln.1 =================================================================== RCS file: /home/ncvs/src/bin/ln/ln.1,v retrieving revision 1.14 diff -d -u -r1.14 ln.1 --- ln.1 2000/11/20 11:39:37 1.14 +++ ln.1 2001/04/20 14:36:37 @@ -44,11 +44,11 @@ .Nd make links .Sh SYNOPSIS .Nm -.Op Fl fisv +.Op Fl fhinsv .Ar source_file .Op target_file .Nm -.Op Fl fisv +.Op Fl fhinsv .Ar source_file ... .Op target_dir .Nm link @@ -79,6 +79,14 @@ option overrides any previous .Fl i options.) +.It Fl h +If the +.Ar target_file +or +.Ar target_dir +is a symbolic link, do not follow it. This is most useful with the +.Fl f +option, to replace a symlink which may point to a directory. .It Fl i Cause .Nm @@ -94,6 +102,12 @@ option overrides any previous .Fl f options.) +.It Fl n +Same as +.Fl h , +for compatibility with other +.Nm +implementations. .It Fl s Create a symbolic link. .It Fl v @@ -168,12 +182,18 @@ and .Fl v options are non-standard and their use in scripts is not recommended. -.Sh HISTORY -An +.Sh STANDARDS +The .Nm -command appeared in -.At v1 . +utility conforms to +.St -p1003.2-92 . +.Pp The simplified .Nm link command conforms to .St -susv2 . +.Sh HISTORY +An +.Nm +command appeared in +.At v1 . Index: ln.c =================================================================== RCS file: /home/ncvs/src/bin/ln/ln.c,v retrieving revision 1.18 diff -d -u -r1.18 ln.c --- ln.c 2000/08/17 16:08:06 1.18 +++ ln.c 2001/04/20 14:36:37 @@ -57,6 +57,7 @@ int fflag; /* Unlink existing files. */ int iflag; /* Interactive mode. */ +int hflag; /* Check new name for symlink first. */ int sflag; /* Symbolic, not hard, link. */ int vflag; /* Verbose output. */ /* System link call. */ @@ -65,6 +66,7 @@ int linkit __P((char *, char *, int)); void usage __P((void)); +int main __P((int, char *[])); int main(argc, argv) @@ -73,7 +75,8 @@ { struct stat sb; int ch, exitval; - char *p, *sourcedir; + char *p; + char *sourcedir; /* * Test for the special case where the utility is called as @@ -92,12 +95,16 @@ usage(); } - while ((ch = getopt(argc, argv, "fisv")) != -1) + while ((ch = getopt(argc, argv, "fhinsv")) != -1) switch (ch) { case 'f': fflag = 1; iflag = 0; break; + case 'h': + case 'n': + hflag = 1; + break; case 'i': iflag = 1; fflag = 0; @@ -122,13 +129,22 @@ switch(argc) { case 0: usage(); + /* NOTREACHED */ case 1: /* ln target */ exit(linkit(argv[0], ".", 1)); + /* NOTREACHED */ case 2: /* ln target source */ exit(linkit(argv[0], argv[1], 0)); + /* NOTREACHED */ } /* ln target1 target2 directory */ sourcedir = argv[argc - 1]; + if (hflag && lstat(sourcedir, &sb) == 0 && S_ISLNK(sb.st_mode)) { + /* we were asked not to follow symlinks, but found one at + the target--simulate "not a directory" error */ + errno = ENOTDIR; + err(1, "%s", sourcedir); + } if (stat(sourcedir, &sb)) err(1, "%s", sourcedir); if (!S_ISDIR(sb.st_mode)) @@ -136,6 +152,7 @@ for (exitval = 0; *argv != sourcedir; ++argv) exitval |= linkit(*argv, sourcedir, 1); exit(exitval); + /* NOTREACHED */ } int @@ -161,18 +178,20 @@ } } - /* If the source is a directory, append the target's name. */ - if (isdir || ((exists = !stat(source, &sb)) && S_ISDIR(sb.st_mode))) { + /* If the source is a directory (and not a symlink if hflag), + append the target's name. */ + if (isdir || + (!lstat(source, &sb) && S_ISDIR(sb.st_mode)) || + (!hflag && !stat(source, &sb) && S_ISDIR(sb.st_mode))) { if ((p = strrchr(target, '/')) == NULL) p = target; else ++p; (void)snprintf(path, sizeof(path), "%s/%s", source, p); source = path; - exists = !lstat(source, &sb); - } else - exists = !lstat(source, &sb); + } + exists = !lstat(source, &sb); /* * If the file exists, then unlink it forcibly if -f was specified * and interactively if -i was specified. @@ -214,8 +233,9 @@ usage() { (void)fprintf(stderr, "%s\n%s\n%s\n", - "usage: ln [-fisv] file1 file2", - " ln [-fisv] file ... directory", + "usage: ln [-fhinsv] file1 file2", + " ln [-fhinsv] file ... directory", " link file1 file2"); exit(1); + /* NOTREACHED */ } --------------9D96218EA2955EAD73F8C911-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 7:43:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from adakro.osowa.gda.osk.pl (adakro.osowa.gda.osk.pl [212.244.103.57]) by hub.freebsd.org (Postfix) with ESMTP id 653D437B43E for ; Fri, 20 Apr 2001 07:43:50 -0700 (PDT) (envelope-from kontakt@poznajkraj.pl) Received: from localhost.localdomain (IDENT:root@localhost.localdomain [127.0.0.1]) by adakro.osowa.gda.osk.pl (8.9.3/8.9.3) with SMTP id QAA07275 for ; Fri, 20 Apr 2001 16:44:31 -0400 Message-Id: <200104202044.QAA07275@adakro.osowa.gda.osk.pl> Subject: Ogolnopolski Wortal Turystyczny Content-transfer-encoding: 8bit Content-type: text/plain; charset="iso-8859-2" Mime-version: 1.0 To: freebsd-hackers@FreeBSD.ORG From: "www.poznajkraj.pl" Date: Fri, 20 Apr 2001 16:44 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OGÓLNOPOLSKI WORTAL KRAJOZNAWCZY HTTP://POZNAJKRAJ.PL TWÓJ PRZEWODNIK PO POLSCE Poznajkraj.pl najdynamiczniej rozwijaj±cy siê w Polsce profesjonalny wortal, prezentuj±cy kompleksow± bazê informacji o wypoczynku, rozrywce i kulturze w naszym kraju. Poznajkraj.pl u³atwi Pañstwu planowanie podró¿y po Polsce, przedstawiaj±c szerok± gamê informacji o regionach, w które chcieliby siê Pañstwo wybraæ. Poznajkraj.pl pomo¿e Pañstwu w wyborze, gdzie znale¼æ odpowiedni± kwaterê, gdzie najlepiej zje¶æ, gdzie najprzyjemniej spêdziæ wolny czas. Poznajkraj.pl - pisz± dla nas najznakomitsi autorzy przewodników. Poznajkraj.pl - ju¿ ponad 400 artyku³ów z zakresu geografii, historii, etnografii, architektury, przyrodoznawstwa i wielu innych dziedzin; tworz± one swoisty multimedialny przewodnik po Polsce, który pozwoli na lepsze poznanie naszego kraju. Poznajkraj.pl - prognoza pogody, równie¿ w systemie WAP. Poznajkraj.pl - czat, galeria sztuki, ksiêgarnia Ju¿ wkrótce wortal bêdzie posiada³ angielsk±, niemieck± i rosyjsk± wersje jêzykow±. ZAPRASZAMY! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 7:52: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7C42237B42C for ; Fri, 20 Apr 2001 07:52:05 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KEq3i12483; Fri, 20 Apr 2001 07:52:03 -0700 (PDT) Date: Fri, 20 Apr 2001 07:52:03 -0700 From: Alfred Perlstein To: Andrew Hesford Cc: niek@bergboer.net, freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010420075203.T1790@fw.wintelcom.net> References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> <20010420093530.A98970@cec.wustl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420093530.A98970@cec.wustl.edu>; from ajh3@chmod.ath.cx on Fri, Apr 20, 2001 at 09:35:30AM -0500 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Andrew Hesford [010420 07:37] wrote: > On Fri, Apr 20, 2001 at 03:20:29PM +0200, Niek Bergboer wrote: > > Isn't it true that softupdates only work when filesystems are mounted > > sync? Or does it also improve performance when filesystems are > > mounted async? > > The other guy was right; you really do need to wrap text at around 70 > lines (I have vim wrap at 72). When I try to reply to messages, it > messes up the reply text. I don't send out messages with screwed-up line > breaks, so I'm not going to help in the future if the formatting is bad. Yes, please. :) However the rest of these statements are incorrect. > Soft updates isn't an "async" or "sync" thing. It combines synchronous > and asynchronous transfers. If I'm not mistaken, all metadata is > synchronously written, and all data is asynchronously written. You're mistaken, what you're describing is the old non-async/non-softupdates way. > It also orders writes so that blocks are allocated before inodes, and > inodes before directory entries. This is why fsck is so fast: if a > directory entry exists for an inode, the file is known to be consistent, > so fsck only needs to check for claimed inodes that don't have directory > entries, and check the free-block bitmap for used blocks that don't have > inodes claiming them. Something like ext2, on the other hand, must check > every directory entry, every inode, and every free block to make sure it > is allocated properly. This is much slower. This is incorrect (afaik), in order to perform a fsck the filesystem must be snapshotted, then since the only inconsistancy that's possible with softupdates is free data that actually isn't, fsck can walk the snapshot and tell the kernel to free blocks that should be free. > But I digress... Since metadata is typically small compared to data, > particularly in your case, the synchronous transfers are trivial. > According to one paper on FFS with soft updates, I think my Marshall > Kirk McKusick, the file system speed approaches that of a memory > filesystem. Actually, with metadata being sync growth of a file can be a problem. Since the blocks allocations may be sync then without softupdates/async it could be expensive to grow a file. > Mounting the partition async would definitely speed up I/O. If you > didn't see a noticible gain in network throughput, that tells you the > bottleneck is somewhere else. Remember, too, that a network operating at > a raw 9Mbits/sec is going to be slower in real-world transfer rates, > because transfer protocols have overhead, breaking data into packets and > reassembling it takes time, and other things. Actually, as I mentioned softupdates can detect when an operation has been "backed out", sort of like a file that's created, but none of the actuall allocations have hit the disk, if that file is deleted under a softupdates filesystem you'll see no disk IO. However an async fs can't see this and will have to do the IO anyway. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 8:17:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from winston.osd.bsdi.com (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 923B437B424; Fri, 20 Apr 2001 08:17:12 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f3KFH1M54695; Fri, 20 Apr 2001 08:17:01 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) To: obrien@FreeBSD.ORG Cc: scanner@jurai.net, freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium In-Reply-To: <20010420022937.B84772@dragon.nuxi.com> References: <000001c0c777$f9529b30$215778d8@cx443070b> <20010420022937.B84772@dragon.nuxi.com> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010420081701F.jkh@osd.bsdi.com> Date: Fri, 20 Apr 2001 08:17:01 -0700 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 10 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >There will be a FreeBDS logo at www.x86-64.org as soon as the FreeBSD >Project can get a webpage up describing our plans and effort for it to >link to. I could really use some help in this area. Heh, sorry, but I think helping you with this was on my TODO list, wasn't it? Let's try to arrange some time today to talk about wordsmithing this into shape. Life has been, erm, "busy" these last few weeks. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 8:32:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dualcpus.com (dualcpus.com [65.160.20.195]) by hub.freebsd.org (Postfix) with SMTP id 1808C37B42C for ; Fri, 20 Apr 2001 08:32:53 -0700 (PDT) (envelope-from jgowdy@home.com) Received: (qmail 26104 invoked from network); 20 Apr 2001 15:32:37 -0000 Received: from sherline.cts.com (HELO server2) (204.216.163.132) by dualcpus.com with SMTP; 20 Apr 2001 15:32:37 -0000 Message-ID: <003b01c0c9af$1ee57d70$015778d8@sherline.net> From: "Jeremiah Gowdy" To: Cc: , References: <001001c0c782$5683ad80$215778d8@cx443070b> <20010420023059.C84772@dragon.nuxi.com> Subject: Re: x86-64 Hammer and IA64 Itainium Date: Fri, 20 Apr 2001 08:32:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Original Message ----- From: "David O'Brien" To: "Jeremiah Gowdy" Cc: ; Sent: Friday, April 20, 2001 2:30 AM Subject: Re: x86-64 Hammer and IA64 Itainium > On Tue, Apr 17, 2001 at 02:06:56PM -0700, Jeremiah Gowdy wrote: > > I'm talking about FreeBSD using the gcc x86-64 compiler to port > > FreeBSD to x86-64. > > What other compiler would we use?? I have access to the SuSE x96-64 > compiler effort. > You're taking me out of context my friend. I was responding to this: > I would like to see this too, however I think you have to sign NDA's and > the like to be a part of the AMD effort to develop for it. Understandable > I guess. Also they only seem interested in boosting Linux adoption of the > new AMD 64 bit procs. *shrug* I was saying that gcc can be used by anyone without signing any NDAs. > > I'm talking about a FreeBSD project to port to x86-64. > > I'm not talking. I'm doing. Then you're the man. I was just trying to spark some discussion about the IA32 to IA64/x86-64 fork, and which way we're going (or if we're going both directions). I appear to have succeeded. I was also looking for a way to contribute to the effort. Having not found a page involving FreeBSD -> x86-64, how was I supposed to know you were 'doing' already ? In any case, thanks for 'doing', because everyone benefits from your work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 8:49:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chmod.ath.cx (CC2-861.charter-stl.com [24.217.115.99]) by hub.freebsd.org (Postfix) with ESMTP id 5B6AB37B43C for ; Fri, 20 Apr 2001 08:49:14 -0700 (PDT) (envelope-from ajh3@chmod.ath.cx) Received: by chmod.ath.cx (Postfix, from userid 1001) id 11129A924; Fri, 20 Apr 2001 10:47:48 -0500 (CDT) Date: Fri, 20 Apr 2001 10:47:48 -0500 From: Andrew Hesford To: Alfred Perlstein Cc: Andrew Hesford , niek@bergboer.net, freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010420104748.A99196@cec.wustl.edu> References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> <20010420093530.A98970@cec.wustl.edu> <20010420075203.T1790@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420075203.T1790@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Apr 20, 2001 at 07:52:03AM -0700 X-Loop: Andrew Hesford Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 07:52:03AM -0700, Alfred Perlstein wrote: > You're mistaken, what you're describing is the old > non-async/non-softupdates way. I do see both synchronous writes and asynchronous writes on my filesystem (as reported by mount); what are these? Is soft updates simply structured asynchronous writing? I always assumed that the metadata was synchronous, which accounted for mount reports. Although, in retrospect, I guess deleting a directory with many files is faster under soft updates than synchronous mounting... Now everything I know is wrong. :) > > It also orders writes so that blocks are allocated before inodes, and > > inodes before directory entries. This is why fsck is so fast: if a > > directory entry exists for an inode, the file is known to be consistent, > > so fsck only needs to check for claimed inodes that don't have directory > > entries, and check the free-block bitmap for used blocks that don't have > > inodes claiming them. Something like ext2, on the other hand, must check > > every directory entry, every inode, and every free block to make sure it > > is allocated properly. This is much slower. > > This is incorrect (afaik), in order to perform a fsck the filesystem > must be snapshotted, then since the only inconsistancy that's > possible with softupdates is free data that actually isn't, fsck > can walk the snapshot and tell the kernel to free blocks that should > be free. According to McKusick, there are two errors that can occur with soft updates: misallocated blocks, and misallocated inodes. Therefore, however fsck analyzes the filesystem, it must check for these problems. This means scanning for inodes that have no directory entry, and scanning for blocks that aren't claimed by any inode. > > Mounting the partition async would definitely speed up I/O. If you > > didn't see a noticible gain in network throughput, that tells you the > > bottleneck is somewhere else. Remember, too, that a network operating at > > a raw 9Mbits/sec is going to be slower in real-world transfer rates, > > because transfer protocols have overhead, breaking data into packets and > > reassembling it takes time, and other things. > > Actually, as I mentioned softupdates can detect when an operation has > been "backed out", sort of like a file that's created, but none of the > actuall allocations have hit the disk, if that file is deleted under > a softupdates filesystem you'll see no disk IO. However an async fs > can't see this and will have to do the IO anyway. Which supports my claim that the bottleneck isn't the filesystem, but something network-related, like protocol overhead or other things. When I said mounting async would speed up I/O, I meant over synchronous writes. The original poster talked about soft updates in a way that led me to believ he wasn't using it, so I'm comparing async I/O to the I/O performance he would see. So I guess we can see that I understand a good portion of how soft updates works in theory, but I've never bothered to learn how all this allows data to be written to disk... -- Andrew Hesford ajh3@chmod.ath.cx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 9: 3: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from unix.infoserve.net (unix.infoserve.net [199.175.157.2]) by hub.freebsd.org (Postfix) with ESMTP id 4518637B423 for ; Fri, 20 Apr 2001 09:03:06 -0700 (PDT) (envelope-from wlodek@infoserve.net) Received: from wlodek (d63-22.infoserve.net [209.82.22.63]) by unix.infoserve.net (8.9.0/8.9.0) with SMTP id JAA26844 for ; Fri, 20 Apr 2001 09:15:05 -0700 (PDT) Message-ID: <007401c0c9b3$5d329960$551652d1@wlodek> From: "wlodek" To: References: <200104202044.QAA07275@adakro.osowa.gda.osk.pl> Subject: Re: Ogolnopolski Wortal Turystyczny Date: Fri, 20 Apr 2001 09:01:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nie rob tego wiecej. to nie jest miejsce do reklamy mozesz miec, ze tak powiem, klopoty z powazaniem wlodek ----- Original Message ----- From: "www.poznajkraj.pl" To: Sent: Friday, April 20, 2001 1:44 PM Subject: Ogolnopolski Wortal Turystyczny > OGÓLNOPOLSKI WORTAL KRAJOZNAWCZY HTTP://POZNAJKRAJ.PL > TWÓJ PRZEWODNIK PO POLSCE > > Poznajkraj.pl najdynamiczniej rozwijaj±cy siê w Polsce profesjonalny wortal, prezentuj±cy kompleksow± bazê informacji o wypoczynku, rozrywce i kulturze w naszym kraju. > > Poznajkraj.pl u³atwi Pañstwu planowanie podró¿y po Polsce, przedstawiaj±c szerok± gamê informacji o regionach, w które chcieliby siê Pañstwo wybraæ. > > Poznajkraj.pl pomo¿e Pañstwu w wyborze, gdzie znale¼æ odpowiedni± kwaterê, gdzie najlepiej zje¶æ, gdzie najprzyjemniej spêdziæ wolny czas. > > Poznajkraj.pl - pisz± dla nas najznakomitsi autorzy przewodników. > > Poznajkraj.pl - ju¿ ponad 400 artyku³ów z zakresu geografii, historii, etnografii, architektury, przyrodoznawstwa i wielu innych dziedzin; tworz± one swoisty multimedialny przewodnik po Polsce, który pozwoli na lepsze poznanie naszego kraju. > > Poznajkraj.pl - prognoza pogody, równie¿ w systemie WAP. > > Poznajkraj.pl - czat, galeria sztuki, ksiêgarnia > > Ju¿ wkrótce wortal bêdzie posiada³ angielsk±, niemieck± i rosyjsk± wersje jêzykow±. > > ZAPRASZAMY! > > 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 Apr 20 9: 8:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 6B5B237B43E for ; Fri, 20 Apr 2001 09:08:28 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3KG8Ms22587; Fri, 20 Apr 2001 09:08:22 -0700 (PDT) (envelope-from obrien) Date: Fri, 20 Apr 2001 09:08:22 -0700 From: "David O'Brien" To: =?iso-8859-1?Q?Joachim_Str=F6mbergson?= Cc: freebsd-hackers Subject: Re: x86-64 Hammer and IA64 Itainium Message-ID: <20010420090822.B85389@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <000001c0c777$f9529b30$215778d8@cx443070b> <20010420022937.B84772@dragon.nuxi.com> <3AE01B83.702C3480@ludd.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3AE01B83.702C3480@ludd.luth.se>; from watchman@ludd.luth.se on Fri, Apr 20, 2001 at 01:20:35PM +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 X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 01:20:35PM +0200, Joachim Strömbergson wrote: > > Yes. I now have a copy of the Virtutech Simics x86-64 simulator. > > Pretty good. I know some of the core team at Virtutech and emailed them > about the possibility of getting access to VirtuHammer for the FreeBSD > project. But, if I undestand what you are saying, then you are waay > ahead of me. :-) I just have one copy. More copies could be useful. > Have anyome tried running the AMD ISS under FreeBSD? I was planning to > but the rpm and rpm2cpio ports seems to be broken right now. They are? Have you emailed ports@freebsd.org describing the breakage? > BTW, David, You had used the emulator. Could you mention what emulator > it is, or is it under NDA? Both of them. At least I'm only aware of two in existance. -- -- David (obrien@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 Apr 20 9:11:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id BC8F437B422; Fri, 20 Apr 2001 09:10:11 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f3KGA8F52731; Fri, 20 Apr 2001 19:10:08 +0300 (EEST) (envelope-from ru) Date: Fri, 20 Apr 2001 19:10:08 +0300 From: Ruslan Ermilov To: Bruce Evans Cc: current@FreeBSD.org, hackers@FreeBSD.org Subject: [CFR] OpenBSD install(1) fixes: atomic install, etc. Message-ID: <20010420191008.A51313@sunbay.com> Mail-Followup-To: Bruce Evans , current@FreeBSD.org, hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! The attached patch incorporates most of OpenBSD fixes to install(1). It does not include manpage update. Most significant changes are: o All TODOs are acted upon. o New flags: -b and -B : -b Backup any existing files before overwriting them by : renaming them to file.old. See -B for specifying a : different backup suffix. : : -B suffix : Use suffix as the backup suffix if -b is given. o New flag: -S (atomic install) : -S Safe copy. Normally, install unlinks an existing target before : installing the new file. With the -S flag a temporary file is : used and then renamed to be the target. The reason this is safer : is that if the copy or rename fails, the existing target is left : untouched. o The -c flag is now the default, and only provided for backwards compatibility. We now never remove the original file. o Flags -v and -D were withdrawn. o strip(1) failure is not considered fatal. Please review. Thanks, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: xinstall.c =================================================================== RCS file: /home/ncvs/src/usr.bin/xinstall/xinstall.c,v retrieving revision 1.40 diff -u -p -r1.40 xinstall.c --- xinstall.c 2000/10/08 09:17:56 1.40 +++ xinstall.c 2001/04/20 15:42:20 @@ -45,21 +45,6 @@ static const char rcsid[] = "$FreeBSD: src/usr.bin/xinstall/xinstall.c,v 1.40 2000/10/08 09:17:56 bde Exp $"; #endif /* not lint */ -/*- - * Todo: - * o for -C, compare original files except in -s case. - * o for -C, don't change anything if nothing needs be changed. In - * particular, don't toggle the immutable flags just to allow null - * attribute changes and don't clear the dump flag. (I think inode - * ctimes are not updated for null attribute changes, but this is a - * bug.) - * o independent of -C, if a copy must be made, then copy to a tmpfile, - * set all attributes except the immutable flags, then rename, then - * set the immutable flags. It's annoying that the immutable flags - * defeat the atomicicity of rename - it seems that there must be - * a window where the target is not immutable. - */ - #include #include #include @@ -82,45 +67,29 @@ static const char rcsid[] = #include "pathnames.h" -/* Bootstrap aid - this doesn't exist in most older releases */ -#ifndef MAP_FAILED -#define MAP_FAILED ((void *)-1) /* from */ -#endif - -int debug, docompare, docopy, dodir, dopreserve, dostrip, nommap, verbose; -int mode = S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH; -char *group, *owner, pathbuf[MAXPATHLEN]; -char pathbuf2[MAXPATHLEN]; - #define DIRECTORY 0x01 /* Tell install it's a directory. */ #define SETFLAGS 0x02 /* Tell install to set flags. */ #define NOCHANGEBITS (UF_IMMUTABLE | UF_APPEND | SF_IMMUTABLE | SF_APPEND) +#define BACKUP_SUFFIX ".old" +struct passwd *pp; +struct group *gp; +int dobackup, docompare, dodir, dopreserve, dostrip, nommap, safecopy; +int mode = S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH; +char pathbuf[MAXPATHLEN], tempfile[MAXPATHLEN]; +char *suffix = BACKUP_SUFFIX; +uid_t uid; +gid_t gid; + void copy __P((int, char *, int, char *, off_t)); -int compare __P((int, const char *, int, const char *, - const struct stat *, const struct stat *)); +int compare __P((int, const char *, size_t, int, const char *, size_t)); +int create_newfile __P((char *, struct stat *)); +int create_tempfile __P((char *, char *, size_t)); void install __P((char *, char *, u_long, u_int)); void install_dir __P((char *)); void strip __P((char *)); -void usage __P((void)); int trymmap __P((int)); - -#define ALLOW_NUMERIC_IDS 1 -#ifdef ALLOW_NUMERIC_IDS - -uid_t uid = -1; -gid_t gid = -1; - -uid_t resolve_uid __P((char *)); -gid_t resolve_gid __P((char *)); -u_long numeric_id __P((char *, char *)); - -#else - -struct passwd *pp; -struct group *gp; - -#endif /* ALLOW_NUMERIC_IDS */ +void usage __P((void)); int main(argc, argv) @@ -132,20 +101,23 @@ main(argc, argv) u_long fset; u_int iflags; int ch, no_target; - char *flags, *to_name; + char *flags, *to_name, *group = NULL, *owner = NULL; iflags = 0; - while ((ch = getopt(argc, argv, "CcdDf:g:m:Mo:psv")) != -1) + while ((ch = getopt(argc, argv, "BbCcdf:g:Mm:o:pSs")) != -1) switch((char)ch) { + case 'B': + suffix = optarg; + /* FALLTHROUGH */ + case 'b': + dobackup = 1; + break; case 'C': - docompare = docopy = 1; + docompare = 1; break; case 'c': - docopy = 1; + /* For backwards compatibility. */ break; - case 'D': - debug++; - break; case 'd': dodir = 1; break; @@ -158,6 +130,9 @@ main(argc, argv) case 'g': group = optarg; break; + case 'M': + nommap = 1; + break; case 'm': if (!(set = setmode(optarg))) errx(EX_USAGE, "invalid file mode: %s", @@ -165,21 +140,18 @@ main(argc, argv) mode = getmode(set, 0); free(set); break; - case 'M': - nommap = 1; - break; case 'o': owner = optarg; break; case 'p': - docompare = docopy = dopreserve = 1; + docompare = dopreserve = 1; + break; + case 'S': + safecopy = 1; break; case 's': dostrip = 1; break; - case 'v': - verbose = 1; - break; case '?': default: usage(); @@ -188,29 +160,24 @@ main(argc, argv) argv += optind; /* some options make no sense when creating directories */ - if (dostrip && dodir) + if ((safecopy || docompare || dostrip) && dodir) usage(); /* must have at least two arguments, except when creating directories */ if (argc < 2 && !dodir) usage(); - -#ifdef ALLOW_NUMERIC_IDS - if (owner) - uid = resolve_uid(owner); - if (group) - gid = resolve_gid(group); + /* need to make a temp copy so we can compare stripped version */ + if (docompare && dostrip) + safecopy = 1; -#else - /* get group and owner id's */ - if (owner && !(pp = getpwnam(owner))) - errx(EX_NOUSER, "unknown user %s", owner); - if (group && !(gp = getgrnam(group))) + if (group && !(gp = getgrnam(group)) && !isdigit(*group)) errx(EX_NOUSER, "unknown group %s", group); - -#endif /* ALLOW_NUMERIC_IDS */ + gid = (group) ? ((gp) ? gp->gr_gid : (gid_t)strtoul(group, NULL, 10)) : (gid_t)-1; + if (owner && !(pp = getpwnam(owner)) && !isdigit(*owner)) + errx(EX_NOUSER, "unknown user %s", owner); + uid = (owner) ? ((pp) ? pp->pw_uid : (uid_t)strtoul(owner, NULL, 10)) : (uid_t)-1; if (dodir) { for (; *argv != NULL; ++argv) @@ -220,7 +187,7 @@ main(argc, argv) } no_target = stat(to_name = argv[argc - 1], &to_sb); - if (!no_target && (to_sb.st_mode & S_IFMT) == S_IFDIR) { + if (!no_target && S_ISDIR(to_sb.st_mode)) { for (; *argv != to_name; ++argv) install(*argv, to_name, fset, iflags | DIRECTORY); exit(EX_OK); @@ -242,72 +209,12 @@ main(argc, argv) to_sb.st_ino == from_sb.st_ino) errx(EX_USAGE, "%s and %s are the same file", *argv, to_name); -/* - * XXX - It's not at all clear why this code was here, since it completely - * duplicates code install(). The version in install() handles the -C flag - * correctly, so we'll just disable this for now. - */ -#if 0 - /* - * Unlink now... avoid ETXTBSY errors later. Try and turn - * off the append/immutable bits -- if we fail, go ahead, - * it might work. - */ - if (to_sb.st_flags & NOCHANGEBITS) - (void)chflags(to_name, - to_sb.st_flags & ~(NOCHANGEBITS)); - (void)unlink(to_name); -#endif } install(*argv, to_name, fset, iflags); exit(EX_OK); /* NOTREACHED */ } -#ifdef ALLOW_NUMERIC_IDS - -uid_t -resolve_uid(s) - char *s; -{ - struct passwd *pw; - - return ((pw = getpwnam(s)) == NULL) ? - (uid_t) numeric_id(s, "user") : pw->pw_uid; -} - -gid_t -resolve_gid(s) - char *s; -{ - struct group *gr; - - return ((gr = getgrnam(s)) == NULL) ? - (gid_t) numeric_id(s, "group") : gr->gr_gid; -} - -u_long -numeric_id(name, type) - char *name, *type; -{ - u_long val; - char *ep; - - /* - * XXX - * We know that uid_t's and gid_t's are unsigned longs. - */ - errno = 0; - val = strtoul(name, &ep, 10); - if (errno) - err(EX_NOUSER, "%s", name); - if (*ep != '\0') - errx(EX_NOUSER, "unknown %s %s", type, name); - return (val); -} - -#endif /* ALLOW_NUMERIC_IDS */ - /* * install -- * build a path name and install the file @@ -319,12 +226,15 @@ install(from_name, to_name, fset, flags) u_int flags; { struct stat from_sb, to_sb; - int devnull, from_fd, to_fd, serrno; - char *p, *old_to_name = 0; + struct utimbuf utb; + int devnull, from_fd, to_fd, serrno, files_match = 0; + char *p; - if (debug >= 2 && !docompare) - fprintf(stderr, "install: invoked without -C for %s to %s\n", - from_name, to_name); +#ifdef __GNUC__ /* XXX: to shut up gcc warnings */ + (void)&from_fd; +#endif + + (void)memset((void *)&from_sb, 0, sizeof(from_sb)); /* If try to install NULL file to a directory, fails. */ if (flags & DIRECTORY || strcmp(from_name, _PATH_DEVNULL)) { @@ -343,143 +253,155 @@ install(from_name, to_name, fset, flags) } devnull = 0; } else { - from_sb.st_flags = 0; /* XXX */ devnull = 1; } - if (docompare) { - old_to_name = to_name; - /* - * Make a new temporary file in the same file system - * (actually, in in the same directory) as the target so - * that the temporary file can be renamed to the target. - */ - snprintf(pathbuf2, sizeof pathbuf2, "%s", to_name); - p = strrchr(pathbuf2, '/'); - p = (p == NULL ? pathbuf2 : p + 1); - snprintf(p, &pathbuf2[sizeof pathbuf2] - p, "INS@XXXX"); - to_fd = mkstemp(pathbuf2); + if (stat(to_name, &to_sb) == 0) { + /* Only compare against regular files. */ + if (docompare && !S_ISREG(to_sb.st_mode)) { + docompare = 0; + errno = EFTYPE; + warn("%s", to_name); + } + } else if (docompare) { + /* File does not exist so silently ignore compare flag. */ + docompare = 0; + } + + if (safecopy) { + to_fd = create_tempfile(to_name, tempfile, sizeof(tempfile)); if (to_fd < 0) - /* XXX should fall back to not comparing. */ - err(EX_OSERR, "mkstemp: %s for %s", pathbuf2, to_name); - to_name = pathbuf2; + err(EX_OSERR, "%s", tempfile); + } else if (docompare && !dostrip) { + if ((to_fd = open(to_name, O_RDONLY, 0)) < 0) + err(EX_OSERR, "%s", to_name); } else { - /* - * Unlink now... avoid errors later. Try to turn off the - * append/immutable bits -- if we fail, go ahead, it might - * work. - */ - if (stat(to_name, &to_sb) == 0 && to_sb.st_flags & NOCHANGEBITS) - (void)chflags(to_name, to_sb.st_flags & ~NOCHANGEBITS); - unlink(to_name); - - /* Create target. */ - to_fd = open(to_name, - O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR); - if (to_fd < 0) + if ((to_fd = create_newfile(to_name, &to_sb)) < 0) err(EX_OSERR, "%s", to_name); } if (!devnull) { if ((from_fd = open(from_name, O_RDONLY, 0)) < 0) { serrno = errno; - (void)unlink(to_name); + (void)unlink(safecopy ? tempfile : to_name); errno = serrno; err(EX_OSERR, "%s", from_name); } - copy(from_fd, from_name, to_fd, to_name, from_sb.st_size); - (void)close(from_fd); + + if (docompare && !safecopy) { + files_match = !(compare(from_fd, from_name, + (size_t)from_sb.st_size, to_fd, + to_name, (size_t)to_sb.st_size)); + + /* Truncate "to" file for copy unless we match */ + if (!files_match) { + (void)close(to_fd); + if ((to_fd = create_newfile(to_name, &to_sb)) < 0) + err(EX_OSERR, "%s", to_name); + } + } + if (!files_match) + copy(from_fd, from_name, to_fd, + safecopy ? tempfile : to_name, from_sb.st_size); } if (dostrip) { - (void)close(to_fd); + strip(safecopy ? tempfile : to_name); - strip(to_name); - - /* Reopen target. */ - to_fd = open(to_name, O_RDWR, 0); + /* + * Re-open our fd on the target, in case we used a strip + * that does not work in-place -- like GNU binutils strip. + */ + close(to_fd); + to_fd = open(safecopy ? tempfile : to_name, O_RDONLY, 0); if (to_fd < 0) - err(EX_OSERR, "%s", to_name); + err(EX_OSERR, "stripping %s", to_name); } /* - * Unfortunately, because we strip the installed file and not the - * original one, it is impossible to do the comparison without - * first laboriously copying things over and then comparing. - * It may be possible to better optimize the !dostrip case, however. - * For further study. + * Compare the (possibly stripped) temp file to the target. */ - if (docompare) { - struct stat old_sb, new_sb, timestamp_sb; - int old_fd; - struct utimbuf utb; - - old_fd = open(old_to_name, O_RDONLY, 0); - if (old_fd < 0 && errno == ENOENT) - goto different; - if (old_fd < 0) - err(EX_OSERR, "%s", old_to_name); - fstat(old_fd, &old_sb); - if (old_sb.st_flags & NOCHANGEBITS) - (void)fchflags(old_fd, old_sb.st_flags & ~NOCHANGEBITS); - fstat(to_fd, &new_sb); - if (compare(old_fd, old_to_name, to_fd, to_name, &old_sb, - &new_sb)) { -different: - if (debug != 0) - fprintf(stderr, - "install: renaming for %s: %s to %s\n", - from_name, to_name, old_to_name); - if (verbose != 0) - printf("install: %s -> %s\n", - from_name, old_to_name); - if (dopreserve && stat(from_name, ×tamp_sb) == 0) { - utb.actime = timestamp_sb.st_atime; - utb.modtime = timestamp_sb.st_mtime; - (void)utime(to_name, &utb); + if (safecopy && docompare) { + int temp_fd = to_fd; + struct stat temp_sb; + + /* Re-open to_fd using the real target name. */ + if ((to_fd = open(to_name, O_RDONLY, 0)) < 0) + err(EX_OSERR, "%s", to_name); + + if (fstat(temp_fd, &temp_sb)) { + serrno = errno; + (void)unlink(tempfile); + errno = serrno; + err(EX_OSERR, "%s", tempfile); + } + + if (compare(temp_fd, tempfile, (size_t)temp_sb.st_size, to_fd, + to_name, (size_t)to_sb.st_size) == 0) { + /* + * If target has more than one link we need to + * replace it in order to snap the extra links. + * Need to preserve target file times, though. + */ + if (to_sb.st_nlink != 1) { + utb.actime = to_sb.st_atime; + utb.modtime = to_sb.st_mtime; + (void)utime(tempfile, &utb); + } else { + files_match = 1; + (void)unlink(tempfile); } -moveit: - if (rename(to_name, old_to_name) < 0) { + (void) close(temp_fd); + } + } + + /* + * Move the new file into place if doing a safe copy + * and the files are different (or just not compared). + */ + if (safecopy && !files_match) { + /* Try to turn off the immutable bits. */ + if (to_sb.st_flags & (NOCHANGEBITS)) + (void)chflags(to_name, to_sb.st_flags & ~(NOCHANGEBITS)); + if (dobackup) { + char backup[MAXPATHLEN]; + (void)snprintf(backup, MAXPATHLEN, "%s%s", to_name, + suffix); + if (rename(to_name, backup) < 0) { serrno = errno; - unlink(to_name); - unlink(old_to_name); - errno = serrno; - err(EX_OSERR, "rename: %s to %s", to_name, - old_to_name); - } - close(old_fd); - } else { - if (old_sb.st_nlink != 1) { - /* - * Replace the target, although it hasn't - * changed, to snap the extra links. But - * preserve the target file times. - */ - if (fstat(old_fd, ×tamp_sb) == 0) { - utb.actime = timestamp_sb.st_atime; - utb.modtime = timestamp_sb.st_mtime; - (void)utime(to_name, &utb); - } - goto moveit; + unlink(tempfile); + errx(EX_OSERR, "rename: %s to %s: %s", to_name, + backup, strerror(serrno)); } - if (unlink(to_name) < 0) - err(EX_OSERR, "unlink: %s", to_name); - close(to_fd); - to_fd = old_fd; + } + if (rename(tempfile, to_name) < 0) { + serrno = errno; + unlink(tempfile); + errno = serrno; + err(EX_OSERR, "rename: %s to %s", + tempfile, to_name); } - to_name = old_to_name; + + /* Re-open to_fd so we aren't hosed by the rename(2). */ + (void) close(to_fd); + if ((to_fd = open(to_name, O_RDONLY, 0)) < 0) + err(EX_OSERR, "%s", to_name); } /* + * Preserve the timestamp of the source file if necesary. + */ + if (dopreserve && !files_match) { + utb.actime = from_sb.st_atime; + utb.modtime = from_sb.st_mtime; + (void)utime(to_name, &utb); + } + + /* * Set owner, group, mode for target; do the chown first, * chown may lose the setuid bits. */ - if ((group || owner) && -#ifdef ALLOW_NUMERIC_IDS - fchown(to_fd, owner ? uid : -1, group ? gid : -1)) { -#else - fchown(to_fd, owner ? pp->pw_uid : -1, group ? gp->gr_gid : -1)) { -#endif + if ((gid != (gid_t)-1 || uid != (uid_t)-1) && fchown(to_fd, uid, gid)) { serrno = errno; (void)unlink(to_name); errno = serrno; @@ -514,8 +436,8 @@ moveit: } (void)close(to_fd); - if (!docopy && !devnull && unlink(from_name)) - err(EX_OSERR, "%s", from_name); + if (!devnull) + (void)close(from_fd); } /* @@ -523,35 +445,32 @@ moveit: * compare two files; non-zero means files differ */ int -compare(int from_fd, const char *from_name, int to_fd, const char *to_name, - const struct stat *from_sb, const struct stat *to_sb) +compare(int from_fd, const char *from_name, size_t from_len, + int to_fd, const char *to_name, size_t to_len) { char *p, *q; int rv; - size_t tsize; int done_compare; rv = 0; - if (from_sb->st_size != to_sb->st_size) + if (from_len != to_len) return 1; - - tsize = (size_t)from_sb->st_size; - if (tsize <= 8 * 1024 * 1024) { + if (from_len <= 8 * 1024 * 1024) { done_compare = 0; if (trymmap(from_fd) && trymmap(to_fd)) { - p = mmap(NULL, tsize, PROT_READ, MAP_SHARED, from_fd, (off_t)0); + p = mmap(NULL, from_len, PROT_READ, MAP_SHARED, from_fd, (off_t)0); if (p == (char *)MAP_FAILED) goto out; - q = mmap(NULL, tsize, PROT_READ, MAP_SHARED, to_fd, (off_t)0); + q = mmap(NULL, from_len, PROT_READ, MAP_SHARED, to_fd, (off_t)0); if (q == (char *)MAP_FAILED) { - munmap(p, tsize); + munmap(p, from_len); goto out; } - rv = memcmp(p, q, tsize); - munmap(p, tsize); - munmap(q, tsize); + rv = memcmp(p, q, from_len); + munmap(p, from_len); + munmap(q, from_len); done_compare = 1; } out: @@ -586,6 +505,59 @@ compare(int from_fd, const char *from_na } /* + * create_tempfile -- + * create a temporary file based on path and open it + */ +int +create_tempfile(path, temp, tsize) + char *path; + char *temp; + size_t tsize; +{ + char *p; + + (void)strncpy(temp, path, tsize); + temp[tsize - 1] = '\0'; + if ((p = strrchr(temp, '/')) != NULL) + p++; + else + p = temp; + (void)strncpy(p, "INS@XXXXXX", &temp[tsize - 1] - p); + temp[tsize - 1] = '\0'; + + return (mkstemp(temp)); +} + +/* + * create_newfile -- + * create a new file, overwriting an existing one if necessary + */ +int +create_newfile(path, sbp) + char *path; + struct stat *sbp; +{ + char backup[MAXPATHLEN]; + + /* + * Unlink now... avoid ETXTBSY errors later. Try to turn + * off the append/immutable bits -- if we fail, go ahead, + * it might work. + */ + if (sbp->st_flags & NOCHANGEBITS) + (void)chflags(path, sbp->st_flags & ~NOCHANGEBITS); + + if (dobackup) { + (void)snprintf(backup, MAXPATHLEN, "%s%s", path, suffix); + if (rename(path, backup) < 0) + err(EX_OSERR, "rename: %s to %s", path, backup); + } else + (void)unlink(path); + + return(open(path, O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR)); +} + +/* * copy -- * copy from one file to another */ @@ -600,16 +572,21 @@ copy(from_fd, from_name, to_fd, to_name, char *p, buf[MAXBSIZE]; int done_copy; + /* Rewind file descriptors. */ + if (lseek(from_fd, (off_t)0, SEEK_SET) == (off_t)-1) + err(EX_OSERR, "lseek: %s", from_name); + if (lseek(to_fd, (off_t)0, SEEK_SET) == (off_t)-1) + err(EX_OSERR, "lseek: %s", to_name); + /* * Mmap and write if less than 8M (the limit is so we don't totally * trash memory on big files. This is really a minor hack, but it * wins some CPU back. */ done_copy = 0; - if (size <= 8 * 1048576 && trymmap(from_fd)) { - if ((p = mmap(NULL, (size_t)size, PROT_READ, - MAP_SHARED, from_fd, (off_t)0)) == (char *)MAP_FAILED) - goto out; + if (size <= 8 * 1048576 && trymmap(from_fd) && + (p = mmap(NULL, (size_t)size, PROT_READ, MAP_SHARED, + from_fd, (off_t)0)) != (char *)MAP_FAILED) { if ((nw = write(to_fd, p, size)) != size) { serrno = errno; (void)unlink(to_name); @@ -617,7 +594,6 @@ copy(from_fd, from_name, to_fd, to_name, err(EX_OSERR, "%s", to_name); } done_copy = 1; - out: } if (!done_copy) { while ((nr = read(from_fd, buf, sizeof(buf))) > 0) @@ -656,7 +632,7 @@ strip(to_name) execlp("strip", "strip", to_name, NULL); err(EX_OSERR, "exec(strip)"); default: - if (wait(&status) == -1 || status) { + if (wait(&status) == -1 || !WIFEXITED(status)) { (void)unlink(to_name); exit(EX_SOFTWARE); /* NOTREACHED */ @@ -704,11 +680,12 @@ install_dir(path) void usage() { - (void)fprintf(stderr,"\ -usage: install [-CcDpsv] [-f flags] [-g group] [-m mode] [-o owner] file1 file2\n\ - install [-CcDpsv] [-f flags] [-g group] [-m mode] [-o owner] file1 ...\n\ - fileN directory\n\ - install -d [-v] [-g group] [-m mode] [-o owner] directory ...\n"); + (void)fprintf(stderr, "\ +usage: install [-bCcpSs] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner]\n\ + file1 file2\n\ + install [-bCcpSs] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner]\n\ + file1 ... fileN directory\n\ + install -d [-g group] [-m mode] [-o owner] directory ...\n"); exit(EX_USAGE); /* NOTREACHED */ } --tThc/1wpZn/ma/RB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 9:11:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bomb.acme.com (bomb.acme.COM [209.133.38.22]) by hub.freebsd.org (Postfix) with ESMTP id C1B0C37B43E for ; Fri, 20 Apr 2001 09:11:41 -0700 (PDT) (envelope-from jef@bomb.acme.com) Received: from bomb.acme.com (localhost [127.0.0.1]) by bomb.acme.com (8.9.3/8.9.3) with ESMTP id JAA95537; Fri, 20 Apr 2001 09:11:32 -0700 (PDT) (envelope-from jef@bomb.acme.com) Message-Id: <200104201611.JAA95537@bomb.acme.com> To: Alfred Perlstein Cc: sthaug@nethelp.no, hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. In-reply-to: Your message of Fri, 20 Apr 2001 05:23:37 PDT. From: Jef Poskanzer Date: Fri, 20 Apr 2001 09:11:32 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The accept-filters change is already on my short list to add. I'll probably use your version. sendfile() probably doesn't make sense in a non-blocking server - wouldn't it block until the entire file is sent? I do plan to use it in my other server mini_httpd. As for making thttpd use multiple processes (each doing non-blocking I/O), yes definitely. I did it in the commercial server I worked on for a while and it was a big win. There are two parts to this: - Collect global state into a single struct and share it among the processes via an anonymous mmap. This would include the throttling table. - A round-robin token-passing scheme to determine which process gets to do the accept(). Turns out it's very bad to just have all the processes do an accept(), since every time there's a new connection *all* the processes wake up. The context switches totally kill performance. But a properly tuned round-robin scheme works great. I'm not sure when I'll add this, but it's definitely in the works. --- Jef Jef Poskanzer jef@acme.com http://www.acme.com/jef/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 9:23: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by hub.freebsd.org (Postfix) with ESMTP id 80E7337B424; Fri, 20 Apr 2001 09:22:59 -0700 (PDT) (envelope-from konstantin.chuguev@dante.org.uk) Received: from theta.dante.org.uk ([193.63.211.7] helo=dante.org.uk) by alpha.dante.org.uk with esmtp (Exim 3.12 #4) id 14qdgP-0004Fj-00; Fri, 20 Apr 2001 17:22:57 +0100 Message-ID: <3AE06267.BE44852F@dante.org.uk> Date: Fri, 20 Apr 2001 17:23:03 +0100 From: Konstantin Chuguev Organization: Delivery of Advanced Network Technology to Europe Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: ru, en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Bruce Evans , current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [CFR] OpenBSD install(1) fixes: atomic install, etc. References: <20010420191008.A51313@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Ruslan Ermilov wrote: > The attached patch incorporates most of OpenBSD fixes to install(1). > It does not include manpage update. Most significant changes are: > > o New flag: -S (atomic install) > > : -S Safe copy. Normally, install unlinks an existing target before > : installing the new file. With the -S flag a temporary file is > : used and then renamed to be the target. The reason this is safer > : is that if the copy or rename fails, the existing target is left > : untouched. > Just curious: why not make this way of doing install default (i.e. always use it)? Regards, Konstantin. -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW: http://www.dante.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 9:33:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C903837B440 for ; Fri, 20 Apr 2001 09:33:50 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KGXoH15389; Fri, 20 Apr 2001 09:33:50 -0700 (PDT) Date: Fri, 20 Apr 2001 09:33:50 -0700 From: Alfred Perlstein To: Jef Poskanzer Cc: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010420093349.X1790@fw.wintelcom.net> References: <200104201611.JAA95537@bomb.acme.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104201611.JAA95537@bomb.acme.com>; from jef@acme.com on Fri, Apr 20, 2001 at 09:11:32AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jef Poskanzer [010420 09:11] wrote: > The accept-filters change is already on my short list to add. I'll > probably use your version. > > sendfile() probably doesn't make sense in a non-blocking server - wouldn't > it block until the entire file is sent? I do plan to use it in my > other server mini_httpd. Yes and no, the sendfile can block until all the file is sent, however if the socket is in non-block mode it will abort when the socket buffer fills. Basically, just how write can return a short count, so will sendfile. > As for making thttpd use multiple processes (each doing non-blocking I/O), > yes definitely. I did it in the commercial server I worked on for a > while and it was a big win. There are two parts to this: > > - Collect global state into a single struct and share it among the > processes via an anonymous mmap. This would include the throttling > table. Yes, interesting, how did you manage the locking on this map? > - A round-robin token-passing scheme to determine which process gets > to do the accept(). Turns out it's very bad to just have all the > processes do an accept(), since every time there's a new connection > *all* the processes wake up. The context switches totally kill > performance. But a properly tuned round-robin scheme works great. Actually this is not a problem on FreeBSD, FreeBSD uses "wakeup_one()" for accept() so "we" don't have this problem. You may have problems on other OSs but apache includes a small library type thingy for serializing accepts for non optimal operating systems you should be able to lift a simple algorithm from it to serialize the accept()s on non optimal systems. You will have a problem if you make thttpd listen() on multiple sockets, becasue then you will need to run select() or poll() on the descriptors, a mear collision on the descriptor being selected on by processes wakes them all up (ie, the wakeup happens when the collision happens, not when the descriptors become ready). So adapting thttpd to listen on multiple sockets with multiple processes will be a bit difficult. > I'm not sure when I'll add this, but it's definitely in the works. Cool! any chance of putting it up as a sourceforge project with cvsup access so I can send proper diffs in the future? There was something else I mentioned in a previous mail that I neglected to cc you on. While tracing thttp I noticed that it does a lot of stat(2) calls, if you implemented a binary tree that kept a cache of recently stat()'d filename (it would only last about 1 or 2 seconds in the cache) then you'd be able to save a signigigant amount of time doing that syscall. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 9:43:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id 4DDFC37B423; Fri, 20 Apr 2001 09:43:32 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from vic.sabbo.net (dialup15-8.iptelecom.net.ua [212.9.229.136]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id TAA02813; Fri, 20 Apr 2001 19:43:22 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.3/8.11.2) with ESMTP id f3KGg9229112; Fri, 20 Apr 2001 19:42:09 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3AE066C0.6B375985@FreeBSD.org> Date: Fri, 20 Apr 2001 19:41:36 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Konstantin Chuguev Cc: Ruslan Ermilov , Bruce Evans , current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [CFR] OpenBSD install(1) fixes: atomic install, etc. References: <20010420191008.A51313@sunbay.com> <3AE06267.BE44852F@dante.org.uk> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Konstantin Chuguev wrote: > Hi, > > Ruslan Ermilov wrote: > > > The attached patch incorporates most of OpenBSD fixes to install(1). > > It does not include manpage update. Most significant changes are: > > > > o New flag: -S (atomic install) > > > > : -S Safe copy. Normally, install unlinks an existing target before > > : installing the new file. With the -S flag a temporary file is > > : used and then renamed to be the target. The reason this is safer > > : is that if the copy or rename fails, the existing target is left > > : untouched. > > > > Just curious: why not make this way of doing install default (i.e. always use > it)? It may effectively doubles disk space requirements during copy (when destination file is not on a sofdep-enabled partition and is not open at the moment when install(8) unlinks it). For small files it doesn't matter, but for a big ones it could lead to a problem. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 9:47:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bomb.acme.com (bomb.acme.COM [209.133.38.22]) by hub.freebsd.org (Postfix) with ESMTP id 89A4837B423 for ; Fri, 20 Apr 2001 09:47:55 -0700 (PDT) (envelope-from jef@bomb.acme.com) Received: from bomb.acme.com (localhost [127.0.0.1]) by bomb.acme.com (8.9.3/8.9.3) with ESMTP id JAA07871; Fri, 20 Apr 2001 09:47:49 -0700 (PDT) (envelope-from jef@bomb.acme.com) Message-Id: <200104201647.JAA07871@bomb.acme.com> To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. In-reply-to: Your message of Fri, 20 Apr 2001 09:33:50 PDT. From: Jef Poskanzer Date: Fri, 20 Apr 2001 09:47:49 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> sendfile() probably doesn't make sense in a non-blocking server - wouldn't >> it block until the entire file is sent? I do plan to use it in my >> other server mini_httpd. > >Yes and no, the sendfile can block until all the file is sent, >however if the socket is in non-block mode it will abort when the >socket buffer fills. Basically, just how write can return a short >count, so will sendfile. Yeah, you're right, I looked at that man page just after sending my earlier message. That sounds pretty useful. >> As for making thttpd use multiple processes (each doing non-blocking I/O), >> yes definitely. I did it in the commercial server I worked on for a >> while and it was a big win. There are two parts to this: >> >> - Collect global state into a single struct and share it among the >> processes via an anonymous mmap. This would include the throttling >> table. > >Yes, interesting, how did you manage the locking on this map? Let's see... Ok, first I was using shmget()/shmat(), not an anonymous mmap(). Locking, hmm. Looks like I didn't do any! Whoever had the accept token also was the one responsible for passing it to the next worker. And in case a worker died unexpectedly, the parent process stuck around and monitored things, restarting dead workers or adding new ones if the load gets high. >> - A round-robin token-passing scheme to determine which process gets >> to do the accept(). Turns out it's very bad to just have all the > >Actually this is not a problem on FreeBSD, FreeBSD uses "wakeup_one()" >for accept() so "we" don't have this problem. Neato. >There was something else I mentioned in a previous mail that I >neglected to cc you on. While tracing thttp I noticed that it does >a lot of stat(2) calls, if you implemented a binary tree that kept >a cache of recently stat()'d filename (it would only last about 1 >or 2 seconds in the cache) then you'd be able to save a signigigant >amount of time doing that syscall. Yeah, I've thought of that too. A stat cache. It would probably help a little. --- Jef Jef Poskanzer jef@acme.com http://www.acme.com/jef/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 9:53:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 6F82F37B43F for ; Fri, 20 Apr 2001 09:53:07 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3KGqgW23386; Fri, 20 Apr 2001 09:52:42 -0700 (PDT) (envelope-from obrien) Date: Fri, 20 Apr 2001 09:52:42 -0700 From: "David O'Brien" To: Jeremiah Gowdy Cc: scanner@jurai.net, freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium Message-ID: <20010420095242.E85389@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <001001c0c782$5683ad80$215778d8@cx443070b> <20010420023059.C84772@dragon.nuxi.com> <003b01c0c9af$1ee57d70$015778d8@sherline.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003b01c0c9af$1ee57d70$015778d8@sherline.net>; from jgowdy@home.com on Fri, Apr 20, 2001 at 08:32:32AM -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 X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 08:32:32AM -0700, Jeremiah Gowdy wrote: > You're taking me out of context my friend. I was responding to this: ... > I was saying that gcc can be used by anyone without signing any NDAs. Ah. Sorry for the misudertanding. You are of course correct. -- -- David (obrien@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 Apr 20 10: 3:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 2263137B42C; Fri, 20 Apr 2001 10:03:36 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f3KH3KO57392; Fri, 20 Apr 2001 20:03:20 +0300 (EEST) (envelope-from ru) Date: Fri, 20 Apr 2001 20:03:20 +0300 From: Ruslan Ermilov To: Maxim Sobolev Cc: Konstantin Chuguev , Bruce Evans , current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [CFR] OpenBSD install(1) fixes: atomic install, etc. Message-ID: <20010420200320.A54192@sunbay.com> Mail-Followup-To: Maxim Sobolev , Konstantin Chuguev , Bruce Evans , current@FreeBSD.org, hackers@FreeBSD.org References: <20010420191008.A51313@sunbay.com> <3AE06267.BE44852F@dante.org.uk> <3AE066C0.6B375985@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AE066C0.6B375985@FreeBSD.org>; from sobomax@FreeBSD.org on Fri, Apr 20, 2001 at 07:41:36PM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 07:41:36PM +0300, Maxim Sobolev wrote: > Konstantin Chuguev wrote: > > > Hi, > > > > Ruslan Ermilov wrote: > > > > > The attached patch incorporates most of OpenBSD fixes to install(1). > > > It does not include manpage update. Most significant changes are: > > > > > > o New flag: -S (atomic install) > > > > > > : -S Safe copy. Normally, install unlinks an existing target before > > > : installing the new file. With the -S flag a temporary file is > > > : used and then renamed to be the target. The reason this is safer > > > : is that if the copy or rename fails, the existing target is left > > > : untouched. > > > > > > > Just curious: why not make this way of doing install default (i.e. always use > > it)? > > It may effectively doubles disk space requirements during copy (when destination > file is not on a sofdep-enabled partition and is not open at the moment when > install(8) unlinks it). For small files it doesn't matter, but for a big ones it > could lead to a problem. > I think -S should be made the default for `installworld' (this was the main reason that triggered this work). But I don't think this should be turned `on' by default in install(1). BTW, this binary just completed the `installworld' test on -STABLE. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 10:41:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 4089037B43E; Fri, 20 Apr 2001 10:41:23 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f3KHfGo60549; Fri, 20 Apr 2001 20:41:16 +0300 (EEST) (envelope-from ru) Date: Fri, 20 Apr 2001 20:41:16 +0300 From: Ruslan Ermilov To: current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [CFR] OpenBSD install(1) fixes: atomic install, etc. Message-ID: <20010420204116.A60253@sunbay.com> Mail-Followup-To: current@FreeBSD.org, hackers@FreeBSD.org References: <20010420191008.A51313@sunbay.com> <3AE06267.BE44852F@dante.org.uk> <3AE066C0.6B375985@FreeBSD.org> <20010420200320.A54192@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420200320.A54192@sunbay.com>; from ru@FreeBSD.org on Fri, Apr 20, 2001 at 08:03:20PM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 08:03:20PM +0300, Ruslan Ermilov wrote: > On Fri, Apr 20, 2001 at 07:41:36PM +0300, Maxim Sobolev wrote: > > Konstantin Chuguev wrote: > > > > > Hi, > > > > > > Ruslan Ermilov wrote: > > > > > > > The attached patch incorporates most of OpenBSD fixes to install(1). > > > > It does not include manpage update. Most significant changes are: > > > > > > > > o New flag: -S (atomic install) > > > > > > > > : -S Safe copy. Normally, install unlinks an existing target before > > > > : installing the new file. With the -S flag a temporary file is > > > > : used and then renamed to be the target. The reason this is safer > > > > : is that if the copy or rename fails, the existing target is left > > > > : untouched. > > > > > > > > > > Just curious: why not make this way of doing install default (i.e. always use > > > it)? > > > > It may effectively doubles disk space requirements during copy (when destination > > file is not on a sofdep-enabled partition and is not open at the moment when > > install(8) unlinks it). For small files it doesn't matter, but for a big ones it > > could lead to a problem. > > > I think -S should be made the default for `installworld' (this was the main > reason that triggered this work). But I don't think this should be turned > `on' by default in install(1). > > BTW, this binary just completed the `installworld' test on -STABLE. > Just tried -j32 installworld with modified install(1) binary for which -S is the default, and it still choked on lib/libncurses. The problem is in bsd.man.mk: we should separate installing of manpages and their MLINKS, otherwise links could be attempted before their originals are installed. Continuing with -DNOMAN now... Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 12:50:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns2.myway.com.br (ns2.myway.com.br [200.186.239.2]) by hub.freebsd.org (Postfix) with SMTP id BB9FC37B43C; Fri, 20 Apr 2001 12:50:34 -0700 (PDT) (envelope-from leal@myway.com.br) Received: from sup02 (unverified [200.186.239.5]) by ns2.myway.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 20 Apr 2001 16:48:17 -0300 Message-ID: <008501c0c9d2$cee98720$1400000a@myway.com.br> From: "leal" To: Cc: References: Subject: right Date: Fri, 20 Apr 2001 16:47:51 -0300 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 X-Antirelay: Good relay from local net2 200.186.239.0/24 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I believe that this question is pertinent in this forum. I have some wireless-lan's interconected with my principal lan that have internet access. Without visible answers, all my wireless-lan is with the traffic terrible!!! lost more lost. 50%, 75% of losses, this started more or less two days. i know tcpdump, how i use it??? i wanna help for debbug my network, looking for worms, viruses, i don't know... and i'm in panic. software??? how can i debbug and looking for bug's??? please... thanks :O) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 14:19:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nova.sparklist.com (nova.sparklist.com [207.250.144.28]) by hub.freebsd.org (Postfix) with SMTP id 417DE37B507 for ; Fri, 20 Apr 2001 14:18:59 -0700 (PDT) (envelope-from bounce-fwd-newswire-2059528@nova.sparklist.com) X-Mailer: Lyris Web Interface Date: Fri, 20 Apr 2001 15:21:53 -0500 Subject: FirewireDirect Gets A New Spark Mime-Version: 1.0 To: "FirewireDirect.com" From: "FirewireDirect NewsWire" Content-Type: multipart/alternative; boundary="============newsletter============" List-Unsubscribe: Reply-To: "FirewireDirect.com" X-Hosted-By: http://SparkLIST.com/ - The Business Email List Experts Message-Id: <20010420211859.417DE37B507@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --============newsletter============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable FirewireDirect is happy to announce the debut and immediate availability of the newest in our series of FireWire storage solutions, the 2.5" Spark II FireWire & USB Portable Hard Drive. The new design means we've retired the number of the original Spark, the popular mobile hard drive that launched our line of FireWire solutions. We've replaced it with an even smaller chassis, and added USB for extra flexability. Come by our web site to see the new package, and order this weekend to receive FREE SHIPPING. Spark II 10GB HDD - $259 Spark II 20GB HDD - $329 Spark II Firewire Enclosure Kit - $119 This offer ends Tuesday, April 24, 200. This is a special offer to subscribers to this list. Please see our web site for info about these offers. --- You are currently subscribed to fwd-newswire as: freebsd-hackers@freebsd.org To unsubscribe send a blank email to leave-fwd-newswire-2059528P@nova.sparklist.com or visit our subscription page at http://firewiredirect.com/company/newswire/subscribe.shtml --============newsletter============ Content-Type: text/html; charset="iso-8859-1" ; Content-Transfer-Encoding: 8bit
FirewireDirect Newswire April 20, 2001
If you have trouble seeing this email, please click here for help.
FirewireDirect is happy to announce the debut and immediate availability of the newest in our series of FireWire storage solutions, the 2.5" Spark II FireWire & USB Portable Hard Drive.

The new design means we've retired the number of the original Spark, the popular mobile hard drive that launched our line of FireWire solutions. We've replaced it with an even smaller chassis, and added USB for extra flexability.

Come by our web site to see the new package, and order this weekend to receive FREE SHIPPING.

Spark II 10GB HDD - $259

Spark II 20GB HDD - $329

Spark II Firewire Enclosure Kit - $119

This offer ends Tuesday, April 24, 200. This is a special offer to subscribers to this list. Please see our web site for info about these offers.

You received this message because you subscribed to the FirewireDirect Newswire.

You are currently subscribed to fwd-newswire as:
freebsd-hackers@freebsd.org
To unsubscribe send a blank email to
leave-fwd-newswire-2059528P@nova.sparklist.com
Or visit our subscription page at
http://firewiredirect.com/company/newswire/subscribe.shtml


To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 14:23:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nova.sparklist.com (nova.sparklist.com [207.250.144.28]) by hub.freebsd.org (Postfix) with SMTP id 3433B37B449 for ; Fri, 20 Apr 2001 14:23:25 -0700 (PDT) (envelope-from sparklist-admin@nova.sparklist.com) Message-Id: X-sparklist-type: unsubscribed From: "SparkLIST.com" Reply-To: "SparkLIST.com" To: freebsd-hackers@freebsd.org Subject: Re: your unsubscribe request Date: Fri, 20 Apr 2001 16:25:28 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As you requested, you have been unsubscribed from 'fwd-newswire'. --- Return-Path: Received: from boreas.isi.edu ([128.9.160.161]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Fri, 20 Apr 2001 16:25:27 -0500 Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f3KLNM514686 for ; Fri, 20 Apr 2001 14:23:22 -0700 (PDT) Sender: larse@ISI.EDU Message-ID: <3AE0A8CA.FBB496FA@isi.edu> Date: Fri, 20 Apr 2001 14:23:22 -0700 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: fwd-newswire-request Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subject: # Mail sent to leave-fwd-newswire-2059528p was converted to these commands: unsubscribe fwd-newswire freebsd-hackers@freebsd.org confirm end # This is the text of the message that triggered the action: Return-Path: Received: from boreas.isi.edu ([128.9.160.161]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Fri, 20 Apr 2001 16:25:27 -0500 Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f3KLNM514686 for ; Fri, 20 Apr 2001 14:23:22 -0700 (PDT) Sender: larse@ISI.EDU Message-ID: <3AE0A8CA.FBB496FA@isi.edu> Date: Fri, 20 Apr 2001 14:23:22 -0700 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: leave-fwd-newswire-2059528P@nova.sparklist.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 14:40:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ambrisko.com (adsl-216-103-208-74.dsl.snfc21.pacbell.net [216.103.208.74]) by hub.freebsd.org (Postfix) with ESMTP id 8642337B423 for ; Fri, 20 Apr 2001 14:40:55 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.3/8.11.2) id f3KLesY94622 for freebsd-hackers@FreeBSD.ORG; Fri, 20 Apr 2001 14:40:54 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200104202140.f3KLesY94622@ambrisko.com> Subject: Any ideas for add driver info to linprocfs? To: freebsd-hackers@FreeBSD.ORG Date: Fri, 20 Apr 2001 14:40:54 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been working on getting things cleaned up for the Aironet driver to emulate the Cisco Linux ioctls so that the binary only utilities for configurating and flashing Aironet cards just work. I send-pr'ed the minor changes to add some DEVPRIVATE ioctls to the emulation layer and support that maps ethX into a FreeBSD ethernet device. However the Cisco binaries want to open "/proc/aironet", well under emulation it also tries "/compat/linux/proc/aironet" first. It does it to detect if the Linux Aironet driver is installed. I can make it work if I unmount "/compat/linux/proc" so that I don't use the linprocfs emulation stuff and then create the directory "/compat/linux/proc/aironet". Is there a way I could detect linprocfs is active and then tell it to create this entry when I attach the Aironet driver (if_an.c)? So it seems I would need a mechanism to: 1) Detect if linprocfs is loaded 2) Tell it to create an "aironet" entry in the root of the proc tree. I don't really have any ideas right now on how to do this. Thanks, Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 15:12:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 7286737B422 for ; Fri, 20 Apr 2001 15:12:19 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 11841 invoked by uid 1000); 20 Apr 2001 22:12:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Apr 2001 22:12:13 -0000 Date: Fri, 20 Apr 2001 15:12:13 -0700 (PDT) From: Dan Phoenix To: freebsd-hackers@freebsd.org Subject: apache nfs hangs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 78662 cvs -4 0 10132K 52K nfsvin 0:09 0.00% 0.00% httpd 83992 cvs -4 0 9904K 52K nfsvin 0:09 0.00% 0.00% httpd 39488 cvs -4 0 9464K 7448K nfsvin 0:08 0.00% 0.00% httpd here is an example from top. killall httpd won;t even work when it is in this state. Nfs could have hung for many reasons prob cause i was beating on nfs today....but regardless ideas to improve apache to timeout apache in this state? -- Dan +------------------------------------------------------+ | BRAVENET WEB SERVICES | | dan@bravenet.com | | make installworld | | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +______________________________________________________+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 15:21:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 510E537B446; Fri, 20 Apr 2001 15:21:22 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3KMLDG37903; Fri, 20 Apr 2001 15:21:14 -0700 (PDT) (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 Date: Fri, 20 Apr 2001 15:20:36 -0700 (PDT) From: John Baldwin To: smp@FreeBSD.org Subject: Athlon AMD SMP Runs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Completely stock -current as of Thursday on a dual Athlon test box graciously provided by AMD with the prodding of David O`Brien. > dmesg Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-SNAP-20010419 #1: Fri Apr 20 14:59:46 PDT 2001 root@:/usr/src/sys/compile/GUINESS-smp Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (1194.68-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x661 Stepping = 1 Features=0x183fbff AMD Features=0xc0440000<,AMIE,DSP,3DNow!> real memory = 1073741824 (1048576K bytes) avail memory = 1041207296 (1016804K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040010, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc043b000. Pentium Pro MTRR support enabled Using $PIR table, 268435454 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.3 (no driver attached) ohci0: mem 0xdc000-0xdcfff irq 11 at device 7.4 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (unknown) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ahc0: port 0x1000-0x10ff mem 0xf4001000-0xf4001fff irq 5 at device 13.0 on pci0 aic7899: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0x1400-0x14ff mem 0xf4002000-0xf4002fff irq 11 at device 13.1 on pci0 aic7899: Wide Channel B, SCSI Id=7, 32/255 SCBs pci0: at 14.0 (no driver attached) xl0: <3Com 3c980 Fast Etherlink XL> port 0x1c00-0x1c7f mem 0xf4004000-0xf400407f irq 3 at device 15.0 on pci0 xl0: command never completed! xl0: command never completed! xl0: Ethernet address: 00:e0:81:02:ac:38 miibus0: on xl0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: <3Com 3c980 Fast Etherlink XL> port 0x1c80-0x1cff mem 0xf4004400-0xf400447f irq 11 at device 16.0 on pci0 xl0: command never completed! xl0: command never completed! xl1: Ethernet address: 00:e0:81:02:ac:39 miibus1: on xl1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto eisa0: on motherboard eisa0: unknown card @@@0000 (0x00000000) at slot 1 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 ata1-slave: ata_command: timeout waiting for intr ata1-slave: identify failed acd0: DVD-ROM at ata1-master PIO4 Waiting 2 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s2a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) SMP: AP CPU #1 Launched! acquring duplicate lock of same type: "allproc" 1st @ ../../kern/kern_proc.c:584 2nd @ ../../kern/kern_proc.c:143 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 2nd 0xc03c9fc0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:967 3rd 0xdf104e2c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:976 # mptable =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f7a40 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x2f mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x0009f870 signature: 'PCMP' base table length: 324 version: 1.4 checksum: 0x67 OEM ID: 'TYAN ' Product ID: 'GUINNESS ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 32 local APIC address: 0xfee00000 extended table length: 344 extended table checksum: 16 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x10 BSP, usable 6 6 1 0x183fbff 0 0x10 AP, usable 6 6 1 0x183fbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 2 0 2 0 INT active-hi edge 2 1 2 1 INT active-hi edge 2 0 2 2 INT active-lo level 2 3 2 3 INT active-hi edge 2 4 2 4 INT active-lo level 2 5 2 5 INT active-hi edge 2 6 2 6 INT active-hi edge 2 7 2 7 INT active-hi edge 2 8 2 8 INT active-hi edge 2 9 2 9 INT active-hi edge 2 10 2 10 INT active-lo level 2 11 2 11 INT active-hi edge 2 12 2 12 INT active-hi edge 2 13 2 13 INT active-hi edge 2 14 2 14 INT active-hi edge 2 15 2 15 INT active-hi edge 2 16 2 16 INT active-hi edge 2 17 2 17 INT active-hi edge 2 18 2 18 INT active-lo level 2 19 2 19 INT active-hi edge 2 20 2 20 INT active-lo level 2 21 2 21 INT active-hi edge 2 22 2 22 INT active-hi edge 2 23 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 2 0 255 0 NMI active-hi edge 1 0:A 255 1 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- System Address Space bus ID: 0 address type: I/O address address base: 0x0 address range: 0x10000 -- System Address Space bus ID: 0 address type: memory address address base: 0x40000000 address range: 0xb4000000 -- System Address Space bus ID: 0 address type: prefetch address address base: 0xf4000000 address range: 0x8000000 -- System Address Space bus ID: 0 address type: memory address address base: 0xfc000000 address range: 0x2e00000 -- System Address Space bus ID: 0 address type: memory address address base: 0xfee01000 address range: 0x11ff000 -- System Address Space bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x24000 -- System Address Space bus ID: 0 address type: memory address address base: 0xc8000 address range: 0x2000 -- System Address Space bus ID: 0 address type: memory address address base: 0xcc000 address range: 0x2000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd0000 address range: 0x1000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd2000 address range: 0x1000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd4000 address range: 0x1000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd6000 address range: 0x1000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd8000 address range: 0x2000 -- System Address Space bus ID: 0 address type: memory address address base: 0xe0000 address range: 0x12000 -- System Address Space bus ID: 0 address type: memory address address base: 0xf4000 address range: 0x2000 -- System Address Space bus ID: 0 address type: memory address address base: 0xf8000 address range: 0x4000 -- Bus Heirarchy bus ID: 2 bus info: 0x01 parent bus ID: 0 -- Compatibility Bus Address bus ID: 0 address modifier: add predefined range: 0x00000000 -- Compatibility Bus Address bus ID: 0 address modifier: add predefined range: 0x00000001 =============================================================================== -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Fri Apr 20 15:26:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8CBBF37B43C for ; Fri, 20 Apr 2001 15:26:42 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KMQgT25273; Fri, 20 Apr 2001 15:26:42 -0700 (PDT) Date: Fri, 20 Apr 2001 15:26:42 -0700 From: Alfred Perlstein To: Dan Phoenix Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: apache nfs hangs Message-ID: <20010420152642.H1790@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dphoenix@bravenet.com on Fri, Apr 20, 2001 at 03:12:13PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dan Phoenix [010420 15:12] wrote: > > 78662 cvs -4 0 10132K 52K nfsvin 0:09 0.00% 0.00% httpd > 83992 cvs -4 0 9904K 52K nfsvin 0:09 0.00% 0.00% httpd > 39488 cvs -4 0 9464K 7448K nfsvin 0:08 0.00% 0.00% httpd > > here is an example from top. > > killall httpd won;t even work when it is in this state. > Nfs could have hung for many reasons prob cause i was beating on nfs > today....but regardless ideas to improve apache to timeout apache > in this state? What are your mount options? Are you running nfsiod? If you want it to timeout I would adding "soft" and "intr" to your mount options. see the mount_nfs manpage for details. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 15:29: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 4B20C37B449 for ; Fri, 20 Apr 2001 15:29:07 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 12446 invoked by uid 1000); 20 Apr 2001 22:28:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Apr 2001 22:28:27 -0000 Date: Fri, 20 Apr 2001 15:28:27 -0700 (PDT) From: Dan Phoenix To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: apache nfs hangs In-Reply-To: <20010420152642.H1790@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ya I think i tried that in the past with no success as freebsd didn't talk solaris nfs to well, but I'll give it a shot again what the hell. On Fri, 20 Apr 2001, Alfred Perlstein wrote: > Date: Fri, 20 Apr 2001 15:26:42 -0700 > From: Alfred Perlstein > To: Dan Phoenix > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: apache nfs hangs > > * Dan Phoenix [010420 15:12] wrote: > > > > 78662 cvs -4 0 10132K 52K nfsvin 0:09 0.00% 0.00% httpd > > 83992 cvs -4 0 9904K 52K nfsvin 0:09 0.00% 0.00% httpd > > 39488 cvs -4 0 9464K 7448K nfsvin 0:08 0.00% 0.00% httpd > > > > here is an example from top. > > > > killall httpd won;t even work when it is in this state. > > Nfs could have hung for many reasons prob cause i was beating on nfs > > today....but regardless ideas to improve apache to timeout apache > > in this state? > > What are your mount options? Are you running nfsiod? > If you want it to timeout I would adding "soft" and "intr" to > your mount options. see the mount_nfs manpage for details. > > -- > -Alfred Perlstein - [alfred@freebsd.org] > Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 15:40:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nova.sparklist.com (nova.sparklist.com [207.250.144.28]) by hub.freebsd.org (Postfix) with SMTP id DCAC837B422 for ; Fri, 20 Apr 2001 15:40:33 -0700 (PDT) (envelope-from sparklist-admin@nova.sparklist.com) Message-Id: X-sparklist-type: unsubscribed From: "SparkLIST.com" Reply-To: "SparkLIST.com" To: freebsd-hackers@freebsd.org Subject: Re: your unsubscribe request Date: Fri, 20 Apr 2001 17:42:37 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As you requested, you have been unsubscribed from 'fwd-newswire'. --- Return-Path: Received: from mailhost.sparknet.net ([207.67.22.123]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Fri, 20 Apr 2001 17:42:36 -0500 Received: from don-oakes.sparklist.com (dhcp-client-26.sparklist.com [207.250.191.151]) by mailhost.sparknet.net (8.10.1/8.10.1) with ESMTP id f3KMioI09190 for ; Fri, 20 Apr 2001 17:44:50 -0500 Message-Id: <4.3.1.2.20010420173701.02d0d4b0@207.67.22.123> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 20 Apr 2001 17:37:05 -0500 To: fwd-newswire-request From: "SparkLIST.com Abuse" Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed # Mail sent to leave-fwd-newswire-2059528p was converted to these commands: unsubscribe fwd-newswire freebsd-hackers@freebsd.org confirm end # This is the text of the message that triggered the action: Return-Path: Received: from mailhost.sparknet.net ([207.67.22.123]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Fri, 20 Apr 2001 17:42:36 -0500 Received: from don-oakes.sparklist.com (dhcp-client-26.sparklist.com [207.250.191.151]) by mailhost.sparknet.net (8.10.1/8.10.1) with ESMTP id f3KMioI09190 for ; Fri, 20 Apr 2001 17:44:50 -0500 Message-Id: <4.3.1.2.20010420173701.02d0d4b0@207.67.22.123> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 20 Apr 2001 17:37:05 -0500 To: leave-fwd-newswire-2059528P@nova.sparklist.com From: "SparkLIST.com Abuse" Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 20 16:25:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id B7CD337B424 for ; Fri, 20 Apr 2001 16:25:48 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-117-217.nnj.dialup.bellatlantic.net [151.198.117.217]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA06269; Fri, 20 Apr 2001 19:24:59 -0400 (EDT) Message-ID: <3AE0C540.1905B113@bellatlantic.net> Date: Fri, 20 Apr 2001 19:24:48 -0400 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: Dennis Cc: Alfred Perlstein , Kris Kennaway , Rik van Riel , freebsd-hackers@FreeBSD.ORG Subject: Re: SMP in 2.4 (fwd) References: <5.0.2.1.0.20010418131202.03d0a280@mail.etinc.com> <20010418111523.B35813@xor.obsecurity.org> <5.0.2.1.0.20010418174822.03b13910@mail.etinc.com> <20010418160941.X976@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Dennis [010418 16:04] wrote: > > > A 1.5Ghz processor can outperform 2 fully saturated PCI buses, so its not > > going to help much in the networking world, which is where I live. > > Processing power is already exceeding the busses capabilities. He-he-he. Wait for Infiniband. And even PCIX is a big step performance-wise. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 7:48:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 61EE237B43C for ; Sat, 21 Apr 2001 07:48:12 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3LEmBY21896; Sat, 21 Apr 2001 07:48:11 -0700 (PDT) Date: Sat, 21 Apr 2001 07:48:11 -0700 From: Alfred Perlstein To: Zach Brown Cc: Jef Poskanzer , hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010421074811.O1790@fw.wintelcom.net> References: <200104201611.JAA95537@bomb.acme.com> <20010420093349.X1790@fw.wintelcom.net> <20010421094738.B7494@erasmus.off.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010421094738.B7494@erasmus.off.net>; from zab@zabbo.net on Sat, Apr 21, 2001 at 09:47:38AM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Zach Brown [010421 06:47] wrote: > [apologies for missing the original post and replying to a reply..] > > > > - A round-robin token-passing scheme to determine which process gets > > > to do the accept(). Turns out it's very bad to just have all the > > > processes do an accept(), since every time there's a new connection > > > *all* the processes wake up. The context switches totally kill > > > performance. But a properly tuned round-robin scheme works great. > > In my apache tuning adventures, including the insanity at the zd mindcraft > tests, I've never seen accept() hurding be a real measurable problem for > the simple reason that when you're under load your waiters aren't waiting > in accept(), they're off doing work. The only time this actually occurs > is when you're entirely idle and get a new connection. > > or so the numbers have lead me to beleive. Its still an annoying > design, but has someone come up with real numbers to show that accept() > hurding is a problem for waiters that do real work after accept() ? Accept herding isn't a problem under FreeBSD because the kernel doesn't allow it to happen. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 8: 0:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id F106E37B424 for ; Sat, 21 Apr 2001 08:00:26 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3LExp975768; Sat, 21 Apr 2001 07:59:51 -0700 (PDT) (envelope-from obrien) Date: Sat, 21 Apr 2001 07:59:51 -0700 From: "David O'Brien" To: Alfred Perlstein Cc: Andrew Hesford , niek@bergboer.net, freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010421075951.B72704@dragon.nuxi.com> Reply-To: freebsd-hackers@freebsd.org References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> <20010420093530.A98970@cec.wustl.edu> <20010420075203.T1790@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420075203.T1790@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Apr 20, 2001 at 07:52:03AM -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 X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 07:52:03AM -0700, Alfred Perlstein wrote: > > Soft updates isn't an "async" or "sync" thing. It combines synchronous > > and asynchronous transfers. If I'm not mistaken, all metadata is > > synchronously written, and all data is asynchronously written. > > You're mistaken, what you're describing is the old > non-async/non-softupdates way. ^^^^^^^^^ actually its called "nosync". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 8: 1:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 01BEF37B422 for ; Sat, 21 Apr 2001 08:01:24 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3LF1Kv75829; Sat, 21 Apr 2001 08:01:20 -0700 (PDT) (envelope-from obrien) Date: Sat, 21 Apr 2001 08:01:20 -0700 From: "David O'Brien" To: Andrew Hesford Cc: Alfred Perlstein , niek@bergboer.net, freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010421080120.C72704@dragon.nuxi.com> Reply-To: freebsd-hackers@freebsd.org References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> <20010420093530.A98970@cec.wustl.edu> <20010420075203.T1790@fw.wintelcom.net> <20010420104748.A99196@cec.wustl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420104748.A99196@cec.wustl.edu>; from ajh3@chmod.ath.cx on Fri, Apr 20, 2001 at 10:47:48AM -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 X-Loop: FreeBSD.ORG On Fri, Apr 20, 2001 at 10:47:48AM -0500, Andrew Hesford wrote: > I do see both synchronous writes and asynchronous writes on my > filesystem (as reported by mount); what are these? The default mount is "nosync". synchronous metadata, asynchronous data. Compare with the "async" and "sync" mount options. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 8:13: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chmod.ath.cx (CC2-861.charter-stl.com [24.217.115.99]) by hub.freebsd.org (Postfix) with ESMTP id F32B637B422 for ; Sat, 21 Apr 2001 08:13:00 -0700 (PDT) (envelope-from ajh3@chmod.ath.cx) Received: by chmod.ath.cx (Postfix, from userid 1001) id E86BAA924; Sat, 21 Apr 2001 10:12:20 -0500 (CDT) Date: Sat, 21 Apr 2001 10:12:20 -0500 From: Andrew Hesford To: David O'Brien Cc: Alfred Perlstein , niek@bergboer.net Subject: Re: UFS block size vs. write speed Message-ID: <20010421101220.A4459@cec.wustl.edu> References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> <20010420093530.A98970@cec.wustl.edu> <20010420075203.T1790@fw.wintelcom.net> <20010420104748.A99196@cec.wustl.edu> <20010421080120.C72704@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: <20010421080120.C72704@dragon.nuxi.com>; from freebsd-hackers@freebsd.org on Sat, Apr 21, 2001 at 08:01:20AM -0700 X-Loop: Andrew Hesford Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 21, 2001 at 08:01:20AM -0700, David O'Brien wrote: > On Fri, Apr 20, 2001 at 10:47:48AM -0500, Andrew Hesford wrote: > > I do see both synchronous writes and asynchronous writes on my > > filesystem (as reported by mount); what are these? > > The default mount is "nosync". synchronous metadata, asynchronous data. > Compare with the "async" and "sync" mount options. Hey, thanks for the info. The synchronous metadata explains why, when I first started using FreeBSD, it took ages to delete a highly-populated directory (it might have been the ports tree, or something that size). With soft updates, however, the deletion happens much quicker. Is this because soft updates does everything asynchronously, but in a structured (ordered) fashion? If so, how often is the cache flushed to disk, and is it user-configurable? -- Andrew Hesford ajh3@chmod.ath.cx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 8:25:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3005A37B423 for ; Sat, 21 Apr 2001 08:25:44 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3LFPh822971; Sat, 21 Apr 2001 08:25:43 -0700 (PDT) Date: Sat, 21 Apr 2001 08:25:42 -0700 From: Alfred Perlstein To: Zach Brown Cc: Jef Poskanzer , hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010421082542.P1790@fw.wintelcom.net> References: <200104201611.JAA95537@bomb.acme.com> <20010420093349.X1790@fw.wintelcom.net> <20010421094738.B7494@erasmus.off.net> <20010421074811.O1790@fw.wintelcom.net> <20010421110308.C8818@erasmus.off.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010421110308.C8818@erasmus.off.net>; from zab@zabbo.net on Sat, Apr 21, 2001 at 11:03:08AM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Zach Brown [010421 08:03] wrote: > > > or so the numbers have lead me to beleive. Its still an annoying > > > design, but has someone come up with real numbers to show that accept() > > > hurding is a problem for waiters that do real work after accept() ? > > > > Accept herding isn't a problem under FreeBSD because the kernel doesn't > > allow it to happen. > > yes, as was previously mentioned. linux has also had "exclusive" wait > queues for quite some time, but thats not the point either :) Linux has had them for under a year. In fact that was a major presentation at the last USENIX. > I wasn't asking how the problem was handled in the kernel, but > whether people have ever found profiles of meaningful workloads the show > it being a problem. sorry if that wasn't clear. I don't understand what you're asking. If it's handled in the kernel then it can't be a problem. -- -Alfred Perlstein - [alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 15:19: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id C261737B423 for ; Sat, 21 Apr 2001 15:19:05 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 24E8366B1C; Sat, 21 Apr 2001 15:19:02 -0700 (PDT) Date: Sat, 21 Apr 2001 15:19:02 -0700 From: Kris Kennaway To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010421151901.D21322@xor.obsecurity.org> References: <20010420024700.E1790@fw.wintelcom.net> <20010420044402.L1790@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="pZs/OQEoSSbxGlYw" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420044402.L1790@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Apr 20, 2001 at 04:44:02AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --pZs/OQEoSSbxGlYw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 20, 2001 at 04:44:02AM -0700, Alfred Perlstein wrote: > .) kqueue. http://people.freebsd.org/~kris/thttpd-2.19+kq.patch Kris --pZs/OQEoSSbxGlYw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE64gdVWry0BWjoQKURAnwyAKDDqGc/8+0ns2PUO2tqWZ4cGArVsgCdFDDG Jo+VoJz+xuVOXiYOw5Isl74= =f+5C -----END PGP SIGNATURE----- --pZs/OQEoSSbxGlYw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 18:23: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from arachna.com (dnai-216-15-61-88.cust.dnai.com [216.15.61.88]) by hub.freebsd.org (Postfix) with SMTP id E5EC537B423 for ; Sat, 21 Apr 2001 18:22:57 -0700 (PDT) (envelope-from spidaman@arachna.com) Received: (qmail 33354 invoked by uid 1001); 22 Apr 2001 01:25:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Apr 2001 01:25:04 -0000 Date: Sat, 21 Apr 2001 18:25:04 -0700 (PDT) From: Ian Kallen To: freebsd-hackers@freebsd.org Subject: mozilla package dumps core Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anyone noticed the mozilla-0.8.1 package core dumping on 4.2-RELEASE and have a fix for it? Here's the gdb output: Program received signal SIGSEGV, Segmentation fault. 0x48158f9a in nsThreadPoolRunnable::Run () from /usr/X11R6/lib/mozilla/./libxpcom.so cheers, -Ian -- Ian Kallen | AIM: iankallen | efax: (415) 354-3326 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 19:42:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 2158837B422 for ; Sat, 21 Apr 2001 19:42:46 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f3M2gR088177; Sat, 21 Apr 2001 19:42:27 -0700 (PDT) (envelope-from obrien) Date: Sat, 21 Apr 2001 19:42:26 -0700 From: "David O'Brien" To: Kris Kennaway Cc: Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010421194226.A88152@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010420024700.E1790@fw.wintelcom.net> <20010420044402.L1790@fw.wintelcom.net> <20010421151901.D21322@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010421151901.D21322@xor.obsecurity.org>; from kris@obsecurity.org on Sat, Apr 21, 2001 at 03:19:02PM -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 X-Loop: FreeBSD.ORG On Sat, Apr 21, 2001 at 03:19:02PM -0700, Kris Kennaway wrote: > http://people.freebsd.org/~kris/thttpd-2.19+kq.patch Commit them to the port! :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 20:55:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-27.dsl.lsan03.pacbell.net [63.207.60.27]) by hub.freebsd.org (Postfix) with ESMTP id E5D9B37B422; Sat, 21 Apr 2001 20:55:56 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1ACA666BAA; Sat, 21 Apr 2001 20:55:56 -0700 (PDT) Date: Sat, 21 Apr 2001 20:55:55 -0700 From: Kris Kennaway To: David O'Brien Cc: Kris Kennaway , Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010421205555.A59042@xor.obsecurity.org> References: <20010420024700.E1790@fw.wintelcom.net> <20010420044402.L1790@fw.wintelcom.net> <20010421151901.D21322@xor.obsecurity.org> <20010421194226.A88152@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010421194226.A88152@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sat, Apr 21, 2001 at 07:42:26PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 21, 2001 at 07:42:26PM -0700, David O'Brien wrote: > On Sat, Apr 21, 2001 at 03:19:02PM -0700, Kris Kennaway wrote: > > http://people.freebsd.org/~kris/thttpd-2.19+kq.patch >=20 > Commit them to the port! :-) Yeah, I should. I should also submit them back to the author :-) Kris --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE64lZLWry0BWjoQKURAvscAKC6QhXHg08zDjxIKed/cHOOYvEWVwCg43hu kx9vv4uTkPexdTqoIkRQhX8= =5jD3 -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 21 23:40:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (adam042-060.resnet.wisc.edu [146.151.42.60]) by hub.freebsd.org (Postfix) with ESMTP id A428737B423 for ; Sat, 21 Apr 2001 23:40:32 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 31913 invoked by uid 1000); 22 Apr 2001 06:40:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Apr 2001 06:40:30 -0000 Date: Sun, 22 Apr 2001 01:40:30 -0500 (CDT) From: Mike Silbersack To: Kris Kennaway Cc: David O'Brien , Alfred Perlstein , Subject: Re: thttpd hack for sendfile and accept filters. In-Reply-To: <20010421205555.A59042@xor.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 21 Apr 2001, Kris Kennaway wrote: > On Sat, Apr 21, 2001 at 07:42:26PM -0700, David O'Brien wrote: > > On Sat, Apr 21, 2001 at 03:19:02PM -0700, Kris Kennaway wrote: > > > http://people.freebsd.org/~kris/thttpd-2.19+kq.patch > > > > Commit them to the port! :-) > > Yeah, I should. I should also submit them back to the author :-) > > Kris Might not be necessary now. An excerpt from the 2.21 changelog: - kqueue support, from Niels Provos. - Use accept filtering if available. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message