From owner-freebsd-arch Sun Mar 9 5:48:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BB6A37B401 for ; Sun, 9 Mar 2003 05:48:33 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C13F43FA3 for ; Sun, 9 Mar 2003 05:48:30 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA22032; Mon, 10 Mar 2003 00:48:22 +1100 Date: Mon, 10 Mar 2003 00:48:21 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes, -Create option for rc.diskless In-Reply-To: Message-ID: <20030310000219.N15648-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 9 Mar 2003, Garance A Drosihn wrote: > When looking through some /etc/rc files the other day, I noticed > that /etc/rc.diskless2 picks up entries in /etc/newsyslog.conf > and uses 'touch' to create them. With all the other changes I > have made and plan to make, this is not a good idea. In fact, it > was already a bad idea because it won't get owner, group, or > permissions set right. > > I have an update in: > http://people.freebsd.org/~gad/newsyslog/create-opt.diff > > which implements a '-C' option for newyslog. Once this is > committed, /etc/rc.diskless2 should be changed to use it. The > update also adds a a 'C' flag for the config file entries, to > match an option that NetBSD has. > > Please pay close attention to the new createlog() routine, as a > later update will switch to using that for all logfile creations. > My goal was to eliminate all windows in the create of a new log > file. This (once I do it) should complete the job started in > revision 1.41 (committed in april 2002). mtree(8) should be used to control the original files. The original set of files very little to do with newsyslog. It has more to do with syslogd, but it's normal for both syslog.conf and newsyslog.conf to have default rules for files that don't exist, with the actual creation done manually. Manual creation is too hard to do for diskless mounts, so we need a database, and mtree(8) handles this perfectly: %%% Script started on Mon Mar 10 00:18:22 2003 ttyp0:root@besplex:/tmp> cat /etc/mtree/BSD.log.dist # $FreeBSD$ # # Please see the file src/etc/mtree/README before making changes to this file. # /set type=file uname=root gname=wheel mode=0644 . type=dir mode=0755 auth.log mode=0600 cron mode=0600 lastlog lpd-errs maillog mode=0640 messages ppp.log gname=network mode=0640 security mode=0600 slip.log gname=network mode=0640 wtmp xferlog mode=0600 .. ttyp0:root@besplex:/tmp> mtree -f /etc/mtree/BSD.log.dist -p /var/log sendmail.st extra setuid.today extra setuid.yesterday extra mount.today extra mount.yesterday extra cron.0.gz extra messages.0.gz extra console.log extra messages.1.gz extra messages.2.gz extra messages.3.gz extra messages.4.gz extra ppp.log.0.gz extra connect-errors extra console.log.0.gz extra ttyp0:root@besplex:/tmp> exit Script done on Mon Mar 10 00:19:20 2003 %%% I created the database using mergemaster to an empty tree. This uses mainly src/etc/Makefile. The Makefile should use a database too, and at least the customized version of the database should have a few more files so that there are no "extras" except .gz's. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 9 5:51: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D02337B401 for ; Sun, 9 Mar 2003 05:51:04 -0800 (PST) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 460A843FAF for ; Sun, 9 Mar 2003 05:51:03 -0800 (PST) (envelope-from sean@perrin.int.nxad.com) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id D31FD21064; Sun, 9 Mar 2003 05:50:37 -0800 (PST) Date: Sun, 9 Mar 2003 05:50:37 -0800 From: Sean Chittenden To: "Alan L. Cox" Cc: arch@freebsd.org Subject: Re: Should sendfile() to return EAGAIN? [patch] Message-ID: <20030309135037.GK79234@perrin.int.nxad.com> References: <3E64FEA0.CCA21C7@imimic.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D85EWoRcDXv1uhH1" Content-Disposition: inline In-Reply-To: <3E64FEA0.CCA21C7@imimic.com> User-Agent: Mutt/1.4i X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --D85EWoRcDXv1uhH1 Content-Type: multipart/mixed; boundary="Sh9dYexoRflRb0jn" Content-Disposition: inline --Sh9dYexoRflRb0jn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Given that the main purpose of the sf_buf is simply to provide an > in-kernel virtual address for the page, one sf_buf per page should > suffice. Sf_bufs are already reference counted. So, the principle > change would be to add a directory data structure that could answer > the question "Does this page already have an allocated sf_buf?" Is this kind of a structure already in use someplace in the tree? I poked around for a bit and couldn't find anything that'd suggest that it's already been done. Do you know if/where I could poach code that'd provide this functionality or would this be fresh bits that'd that'd have to hit the tree? Was there any form of consensus regarding whether or not sf_buf_alloc() should be called in the non-blocking case? I think that there should be another call, sf_buf_alloc_nb() that is used that doesn't block the call when there aren't any sf_buf's available and is used in the non-blocking case. I can't imagine Greenman meant to use msleep(..., 0) for the non-blocking case. The attached patch corrects this. The patch updates the case of sendfile() when there aren't any sf_buf's available. Instead of calling msleep() and blocking the caller on a socket that has been marked non-blocking, return instantly with EAGAIN. This doesn't provide a mechanism for identifying that there aren't any sf_buf's available. At some point a read only sysctl should be added that lets an administrator know how many sf_buf's are free (max number already exists in -CURRENT so it should be trivial for an admin to figure out how many are in use), but that will come at a later date (ENOSLEEP). Returning control to the program should dramatically improve the responsiveness of a non-blocking application that uses sendfile(), hopefully sf_buf's will be freed up for use making it possible to deal with the load. Currently when this limit is hit, it kills the concurrency of the server that non-blocking IO affords and the throughput of a system drops from __Mbps down to near 0Mbps. With this patch, at the very least the server should be able to continue to send data at __Mbps. There is a race in this code, however. There is a race with this code in that if a non-blocking socket that has had sendfile() called on it where there wasn't an sf_buf available, and it is set back to being a blocking socket, sf_buf_alloc_want will never reach zero and as a result, wakeup_one(&sf_freelist) will be called every time in sf_buf_free(). I'm not sure how best to fix this if it should be, or even what the behavior of wakeup_one(&sf_freelist) will be if it is called when there isn't anything msleep()'ing on sf_freelist. Another something that came to mind was to alert the server admin that he/she's out of sf_buf's the same way that the kernel does when it runs out of nmbclusters. Lastly, I couldn't find any bits to suggest how data coherency is maintained. What's the mechanism in place that guarantee's this? -sc Patch can also be found at: http://people.freebsd.org/~seanc/patches/#sendfile_no_block --=20 Sean Chittenden --Sh9dYexoRflRb0jn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch Content-Transfer-Encoding: quoted-printable Index: uipc_syscalls.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v retrieving revision 1.142 diff -u -r1.142 uipc_syscalls.c --- uipc_syscalls.c 6 Mar 2003 04:48:19 -0000 1.142 +++ uipc_syscalls.c 9 Mar 2003 13:14:43 -0000 @@ -1661,6 +1661,27 @@ return (sf); } =20 +/* + * Get an sf_buf from the freelist. Will return NULL if none are + * available. + */ +struct sf_buf * +sf_buf_alloc_nb() +{ + struct sf_buf *sf; + + mtx_lock(&sf_freelist.sf_lock); + sf_buf_alloc_want++; + sf =3D SLIST_FIRST(&sf_freelist.sf_head); + if (sf !=3D NULL) { + SLIST_REMOVE_HEAD(&sf_freelist.sf_head, free_list); + sf_buf_alloc_want--; + } + + mtx_unlock(&sf_freelist.sf_lock); + return (sf); +} + #define dtosf(x) (&sf_bufs[((uintptr_t)(x) - (uintptr_t)sf_base) >> PAGE_S= HIFT]) =20 /* @@ -1929,17 +1950,22 @@ vm_page_unlock_queues(); =20 /* - * Get a sendfile buf. We usually wait as long as necessary, - * but this wait can be interrupted. + * Get a sendfile buf. */ - if ((sf =3D sf_buf_alloc()) =3D=3D NULL) { + if (so->so_state & SS_NBIO) { + if ((sf =3D sf_buf_alloc_nb()) =3D=3D NULL) + error =3D EAGAIN; + } else { + if ((sf =3D sf_buf_alloc()) =3D=3D NULL) + error =3D EINTR; + } + if (sf =3D=3D NULL) { vm_page_lock_queues(); vm_page_unwire(pg, 0); if (pg->wire_count =3D=3D 0 && pg->object =3D=3D NULL) vm_page_free(pg); vm_page_unlock_queues(); sbunlock(&so->so_snd); - error =3D EINTR; goto done; } =20 --Sh9dYexoRflRb0jn-- --D85EWoRcDXv1uhH1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: Sean Chittenden iD8DBQE+a0at3ZnjH7yEs0ERAmRSAJ9wXd+g+rPqHQ/dL9K1Ds0ku2aMqACfSgfv xaRjZ5R5gJNFkPNdnrK1tl0= =ngMe -----END PGP SIGNATURE----- --D85EWoRcDXv1uhH1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 9 9:27:33 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79FD237B401 for ; Sun, 9 Mar 2003 09:27:32 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F5DB43FB1 for ; Sun, 9 Mar 2003 09:27:29 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h29HRAmF037627; Sun, 9 Mar 2003 20:27:10 +0300 (MSK) Date: Sun, 9 Mar 2003 20:27:10 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: Sean Chittenden Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] In-Reply-To: <20030309135037.GK79234@perrin.int.nxad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 9 Mar 2003, Sean Chittenden wrote: >The patch updates the case of sendfile() when there aren't any >sf_buf's available. Instead of calling msleep() and blocking the >caller on a socket that has been marked non-blocking, return instantly >with EAGAIN. This doesn't provide a mechanism for identifying that >there aren't any sf_buf's available. At some point a read only sysctl I think if this sendfile() behaviour will be implemented it should return ENOBUFS and should be explicity enabled by the application via sendfile() flag (something like SF_ENOBUFS). EAGAIN should be returned only if there is some way to notify the application about the operation readiness via select()/poll()/kevent(). Igor Sysoev http://sysoev.ru/en/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 9 13:32:17 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90C3537B401 for ; Sun, 9 Mar 2003 13:32:15 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3AF543FBF for ; Sun, 9 Mar 2003 13:32:14 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h29LWBD5020967; Sun, 9 Mar 2003 16:32:11 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030310000219.N15648-100000@gamplex.bde.org> References: <20030310000219.N15648-100000@gamplex.bde.org> Date: Sun, 9 Mar 2003 16:32:10 -0500 To: Bruce Evans From: Garance A Drosihn Subject: Re: NEWSYSLOG changes, -Create option for rc.diskless Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:48 AM +1100 3/10/03, Bruce Evans wrote: >On Sun, 9 Mar 2003, Garance A Drosihn wrote: >> > > I have an update in: >> http://people.freebsd.org/~gad/newsyslog/create-opt.diff >> >> which implements a '-C' option for newyslog. Once this is >> committed, /etc/rc.diskless2 should be changed to use it. The >> update also adds a a 'C' flag for the config file entries, to > > match an option that NetBSD has. > >mtree(8) should be used to control the original files. The >original set of files very little to do with newsyslog. It has >more to do with syslogd, but it's normal for both syslog.conf >and newsyslog.conf to have default rules for files that don't >exist, with the actual creation done manually. Manual creation >is too hard to do for diskless mounts, so we need a database, >and mtree(8) handles this perfectly: Well, the idea of -C is to make the "manual creation" process something that rc.diskless2 can do trivially and reliably, by just asking newsyslog to do it. If we instead use mtree to create the initial files, then I think we'll end up with two different databases that will have to have the same information. However, I have been thinking about the fact that newsyslog.conf does often contain rules for files that don't exist. This patch currently adds the -C option, and also adds a C flag for config-file entries. Perhaps the 'C' flag should not mean "always create this file if it does not exist". Perhaps it should mean "create this file if it does not exist, and if -C was given". That way, the -C option becomes "create all log files which have a C flag". That means our C flag would be a little different than NetBSD's C flag, but I think it's a reasonable idea. That way the config file can have a long list of entries, only some of which would be automatically created. What do people think about that idea? [the more I think about it, the more I like it, although it means more explanation will be needed in the man page] -- Garance Alistair Drosehn = gad@gilead.netel.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-arch" in the body of the message From owner-freebsd-arch Sun Mar 9 13:47: 7 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD54937B409 for ; Sun, 9 Mar 2003 13:47:05 -0800 (PST) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B36243F3F for ; Sun, 9 Mar 2003 13:47:05 -0800 (PST) (envelope-from sean@perrin.int.nxad.com) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id 8CEE42105E; Sun, 9 Mar 2003 13:46:38 -0800 (PST) Date: Sun, 9 Mar 2003 13:46:38 -0800 From: Sean Chittenden To: Igor Sysoev Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] Message-ID: <20030309214638.GN79234@perrin.int.nxad.com> References: <20030309135037.GK79234@perrin.int.nxad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >The patch updates the case of sendfile() when there aren't any > >sf_buf's available. Instead of calling msleep() and blocking the > >caller on a socket that has been marked non-blocking, return > >instantly with EAGAIN. This doesn't provide a mechanism for > >identifying that there aren't any sf_buf's available. At some > >point a read only sysctl > > I think if this sendfile() behaviour will be implemented it should > return ENOBUFS and should be explicity enabled by the application > via sendfile() flag (something like SF_ENOBUFS). > > EAGAIN should be returned only if there is some way to notify the > application about the operation readiness via > select()/poll()/kevent(). Eh, well, I vacillate on this topic, but there is something to be said for source compatibility. Using EAGAIN requires no changes to existing code. Returning ENOBUFS does require a change to existing code. Since the cat's five years out of the bag, I'm not too thrilled about the possibility of breaking existing apps by changing the behavior of a syscall. By the same token, it seems more correct to me to signify to the app that the OS is maxed (ENOBUFS) as opposed to the client being maxed (EAGAIN). ::shrug:: I lean on the side of preserving src level logic compatibility along with adding the ability to monitor the number of sf_buf's in use, free, and the max number of sf_buf's used (akin to mbuf's usage). -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 9 20:17:23 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 887CC37B401 for ; Sun, 9 Mar 2003 20:17:21 -0800 (PST) Received: from terry.dorm11.nctu.edu.tw (Terry.Dorm11.NCTU.edu.tw [140.113.192.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA4DB43F85 for ; Sun, 9 Mar 2003 20:17:20 -0800 (PST) (envelope-from ijliao@terry.dorm11.nctu.edu.tw) Received: by terry.dorm11.nctu.edu.tw (Postfix, from userid 1000) id 08E0F3D0D; Mon, 10 Mar 2003 12:17:14 +0800 (CST) Date: Mon, 10 Mar 2003 12:17:14 +0800 From: Ying-Chieh Liao To: Marijn Meijles Cc: arch@FreeBSD.ORG Subject: Re: New scheduler problem Message-ID: <20030310041714.GA67308@terry.dragon2.net> References: <20030206094040.GA2000@kevad.internal> <20030207211000.P72073-100000@mail.chesapeake.net> <20030210113928.GA10552@hoop.bitpit.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20030210113928.GA10552@hoop.bitpit.net> X-Operating-System: FreeBSD 5.0-CURRENT i386 X-PGP-Key-Location: http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x11C02382 X-PGP-Key-Fingerprint: 4E98 55CC 2866 7A90 EFD7 9DA5 ACC6 0165 11C0 2382 User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 10, 2003 at 12:39:28 +0100, Marijn Meijles wrote: > With strict rescheduling turned on it runs a lot better. It is about as > responsive as the 4BSD scheduler. how to turn on "strict rescheduling" ? -- self-producing in python : l='l=%s;print l%%`l`';print l%`l` -- Frank Stajano --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+bBHKrMYBZRHAI4IRAuMSAJ9XuU5k+FIT+sAlUd5NYFHAkI6gfgCg+gPJ toGU8XW5ZCF7jAbp1RR2MYw= =P/N/ -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 9 23: 9: 4 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CD1137B405 for ; Sun, 9 Mar 2003 23:08:58 -0800 (PST) Received: from web40812.mail.yahoo.com (web40812.mail.yahoo.com [66.218.78.189]) by mx1.FreeBSD.org (Postfix) with SMTP id A528443FE5 for ; Sun, 9 Mar 2003 23:08:54 -0800 (PST) (envelope-from rimi4eva@yahoo.com) Message-ID: <20030310070854.48360.qmail@web40812.mail.yahoo.com> Received: from [217.146.9.213] by web40812.mail.yahoo.com via HTTP; Sun, 09 Mar 2003 23:08:54 PST Date: Sun, 9 Mar 2003 23:08:54 -0800 (PST) From: Ango A Reply-To: ango_a@yahoo.com Subject: Mutual Investment proposal To: rimi4eva@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG DEAR SIR, I HAVE THE HONOUR AND CONFIDENCE TO INTRODUCE TO YOU THIS BUSSINESS IN VIEW OF THE FACT THAT YOU ARE TRUSTWORTHY AND RELIABLE. I AM MR. Ango A, THE EASTERN DISTRICT ACCOUNTANT OF STANDARD TRUST BANK PLC (STB). THERE IS AN ACCOUNT OPENED IN THIS BANK IN 1982 AND SINCE 1990 NOBODY HAS OPERATED ON THIS ACCOUNT AGAIN. AFTER INTENSIVE INVESTIGATION, I DISCOVERED THAT THE OWNER OF THIS ACCOUNT WAS THE OWNER OF CREST MARTINS CO. LTD. A FOREIGNER FROM SWEDEN, A CRUDE OIL MERCHANT, AND HE DIED IN 1990 AND HAS NO NEXT OF KIN AND THE ACCOUNT HAS NO BENEFICIARY, MY INVESTIGATION PROVED TO ME AS WELL THAT HIS COMPANY DOES NOT KNOW ANYTHING ABOUT THIS ACCOUNT. THE AMOUNT INVOLVED RUNS INTO SEVERAL MILLIONS OF UNITED STATES DOLLARS, ABOUT US $17,460,000.00 SEVENTEEN MILLION, FOUR HUNDRED AND SIXTY THOUSAND DOLLARS. IN THE LIGHT OF THE ABOVE FACT, I NEED YOUR ASSISTANCE TO OPEN YOUR DOOR TO THIS OPPORTUNITY BY PROVIDING YOUR ACCOUNT OR ANY ACCOUNT OF YOUR CHOICE WHERE THE FUND WILL BE REMITTED. YOUR ASSISTANCE AS A FOREIGNER IS NECESSARY BECAUSE THIS MANAGEMENT IS READY TO WELCOME ANY PERSON, A FOREIGNER WHO HAS CORRECT INFORMATION TO THIS ACCOUNT, WHICH I WILL GIVE TO YOU IMMEDIATELY, IF YOU INTRESTED TO CONCLUDE THIS TRANSACTION WITH ME. I WILL APPLY FOR AN ANNUAL LEAVE IMMEDIATELY I HEAR FROM YOU THAT YOU ARE READY TO ACT AND RECEIVE THIS FUND INTO YOUR ACCOUNT. THIS IS TO ENABLE ME USE MY POSITION AND INFLUENCE TO EFFECT THE ONWARD TRANSMISSION OF THIS MONEY TO YOUR DESIRED ACCOUNT. AT THE CONCLUSION OF THIS BUSINESS, YOU WILL BE GIVEN 20% OF THE TOTAL AMOUNT, 75% WILL BE FOR US, WHILE 5% BE SET ASIDE FOR CHARITY ORGANISATION AND EXPENSE WE MIGHT INCURE DURING THE TRANSACTION. I LOOK FORWARD TO YOUR EARNEST REPLY. YOURS TRULY, Mr. Ango A __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 9 23:23:43 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 306FD37B401 for ; Sun, 9 Mar 2003 23:23:42 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EB8D43F93 for ; Sun, 9 Mar 2003 23:23:40 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.6/8.12.5) with ESMTP id h2A7NPiM003405; Mon, 10 Mar 2003 18:23:26 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h2A7NINU003404; Mon, 10 Mar 2003 18:23:18 +1100 (EST) Date: Mon, 10 Mar 2003 18:23:18 +1100 From: Peter Jeremy To: Sean Chittenden Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] Message-ID: <20030310072318.GA3343@cirb503493.alcatel.com.au> References: <20030309135037.GK79234@perrin.int.nxad.com> <20030309214638.GN79234@perrin.int.nxad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030309214638.GN79234@perrin.int.nxad.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Mar 09, 2003 at 01:46:38PM -0800, Sean Chittenden wrote: >Eh, well, I vacillate on this topic, but there is something to be said >for source compatibility. Using EAGAIN requires no changes to >existing code. Returning ENOBUFS does require a change to existing >code. I support source compatibility as a guideline but not as a hard-and-fast rule. This wouldn't be the first time that source compatability has been broken and won't be the last time. In any case, that last "does" should be "may" - some applications may no care. Looking at FreeBSD, the only standard application that uses sendfile(2) is ftpd(8) - and it doesn't care what the actual errno is. The libc_r wrapper would need to be modified though and there may be ports that use sendfile(2). > By the same token, it seems more correct to me >to signify to the app that the OS is maxed (ENOBUFS) as opposed to the >client being maxed (EAGAIN). ::shrug:: The descriptions of the errors (from intro(2)) are: 35 EAGAIN Resource temporarily unavailable. This is a temporary condi- tion and later calls to the same routine may complete normally. 55 ENOBUFS No buffer space available. An operation on a socket or pipe was not performed because the system lacked sufficient buffer space or because a queue was full. Whilst both errors cover the situation, "ENOBUFS" provides more information to the caller and I would therefore consider it as the preferred error. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 9 23:33:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61F7037B401 for ; Sun, 9 Mar 2003 23:33:58 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B858843FB1 for ; Sun, 9 Mar 2003 23:33:56 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h2A7XqmF051026; Mon, 10 Mar 2003 10:33:52 +0300 (MSK) Date: Mon, 10 Mar 2003 10:33:52 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: Sean Chittenden Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] In-Reply-To: <20030309214638.GN79234@perrin.int.nxad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 9 Mar 2003, Sean Chittenden wrote: >Eh, well, I vacillate on this topic, but there is something to be said >for source compatibility. Using EAGAIN requires no changes to >existing code. Returning ENOBUFS does require a change to existing >code. Since the cat's five years out of the bag, I'm not too thrilled >about the possibility of breaking existing apps by changing the >behavior of a syscall. By the same token, it seems more correct to me >to signify to the app that the OS is maxed (ENOBUFS) as opposed to the >client being maxed (EAGAIN). ::shrug:: If you protect ENOBUFS with SF_ENOBUFS flag then you do not break any source and binary compatibility. All current apllication should call sendfile() with zero flag so they will never get ENOBUFS. Yes, of course they will still block when sf_buf's would exhausted. But current application has no knowledge about sf_buf's exausting and has no ways to workaround it. If they will get EAGAIN on this condition then they will simply eat CPU cycles polling sendfile(). The applcation that knows about ENOBUFS and has the code to workaround it can pass SF_ENOBUFS flag to sendfile(). >I lean on the side of preserving src level logic compatibility along >with adding the ability to monitor the number of sf_buf's in use, >free, and the max number of sf_buf's used (akin to mbuf's usage). Monitoring is the good thing but if you want to preserve the compatibility and add the non-blocking behaviour to current applicaiton then it's much better to bind select()/etc with sf_buf's freeing - it would be the transparent change to the applications. Igor Sysoev http://sysoev.ru/en/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 10 0: 4:53 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86B3D37B401; Mon, 10 Mar 2003 00:04:52 -0800 (PST) Received: from MX1.estpak.ee (mta1.mail.neti.ee [194.126.101.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E37043FA3; Mon, 10 Mar 2003 00:04:51 -0800 (PST) (envelope-from kalts@estpak.ee) Received: from kevad.internal (80-235-38-161-dsl.mus.estpak.ee [80.235.38.161]) by MX1.estpak.ee (Postfix) with ESMTP id A9EE38882A; Mon, 10 Mar 2003 10:03:26 +0200 (EET) Received: (from vallo@localhost) by kevad.internal (8.12.6/8.12.6/Submit) id h2A84i9O001289; Mon, 10 Mar 2003 10:04:44 +0200 (EET) (envelope-from vallo) Date: Mon, 10 Mar 2003 10:04:44 +0200 From: Vallo Kallaste To: Ying-Chieh Liao Cc: Marijn Meijles , arch@FreeBSD.org Subject: Re: New scheduler problem Message-ID: <20030310080444.GB1122@kevad.internal> Reply-To: kalts@estpak.ee References: <20030206094040.GA2000@kevad.internal> <20030207211000.P72073-100000@mail.chesapeake.net> <20030210113928.GA10552@hoop.bitpit.net> <20030310041714.GA67308@terry.dragon2.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030310041714.GA67308@terry.dragon2.net> User-Agent: Mutt/1.5.1i-ja.1 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 10, 2003 at 12:17:14PM +0800, Ying-Chieh Liao wrote: > On Mon, Feb 10, 2003 at 12:39:28 +0100, Marijn Meijles wrote: > > With strict rescheduling turned on it runs a lot better. It is about as > > responsive as the 4BSD scheduler. > > how to turn on "strict rescheduling" ? Can't remember the kernel configuration option, but IMO Jeff turned it on by default some time ago, so you needn't be concerned about it. Search arch@ archives for last month. -- Vallo Kallaste To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 10 0:50:17 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67BD137B401 for ; Mon, 10 Mar 2003 00:50:15 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E24F43FBF for ; Mon, 10 Mar 2003 00:50:13 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h2A8o7mF052825; Mon, 10 Mar 2003 11:50:07 +0300 (MSK) Date: Mon, 10 Mar 2003 11:50:07 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] In-Reply-To: <20030310072318.GA3343@cirb503493.alcatel.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Mar 2003, Peter Jeremy wrote: > Looking at FreeBSD, the only standard application that uses sendfile(2) > is ftpd(8) - and it doesn't care what the actual errno is. The libc_r > wrapper would need to be modified though and there may be ports that > use sendfile(2). ftpd(8) will not get ENOBUFS because it uses the blocking sockets. libc_r wrapper and sendfile() patch in the thttpd port are under the control so it can be modified to use SF_ENOBUFS flag and to understand ENOBUFS condition. But I think there are many in-house high perfomance solutions that use kqueue() and sendfile(). If they handle too many simultaneous slow connections with sendfile() then after FreeBSD upgrade they start to eat CPU without any visible reasons (in EAGAIN case) or will broke (in ENOBUFS case). > > By the same token, it seems more correct to me > >to signify to the app that the OS is maxed (ENOBUFS) as opposed to the > >client being maxed (EAGAIN). ::shrug:: > > The descriptions of the errors (from intro(2)) are: > 35 EAGAIN Resource temporarily unavailable. This is a temporary condi- > tion and later calls to the same routine may complete normally. > 55 ENOBUFS No buffer space available. An operation on a socket or pipe > was not performed because the system lacked sufficient buffer > space or because a queue was full. > > Whilst both errors cover the situation, "ENOBUFS" provides more > information to the caller and I would therefore consider it as the > preferred error. Yes, ENOBUFS is the good candidate but it should be enabled via flag. Igor Sysoev http://sysoev.ru/en/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 10 6:25:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AE1837B401 for ; Mon, 10 Mar 2003 06:25:47 -0800 (PST) Received: from unox.bitpit.net (t-23-57.athome.tue.nl [131.155.227.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B00043F3F for ; Mon, 10 Mar 2003 06:25:45 -0800 (PST) (envelope-from marijn@bitpit.net) Received: from hoop.bitpit.net (unknown [192.168.1.2]) by unox.bitpit.net (Postfix) with ESMTP id B92CC4A4; Mon, 10 Mar 2003 15:25:43 +0100 (CET) Received: from hoop.bitpit.net (localhost [127.0.0.1]) by hoop.bitpit.net (8.12.6/8.12.6) with ESMTP id h2AEQDcP016578; Mon, 10 Mar 2003 15:26:13 +0100 (CET) (envelope-from marijn@hoop.bitpit.net) Received: (from marijn@localhost) by hoop.bitpit.net (8.12.6/8.12.6/Submit) id h2AEQBed016577; Mon, 10 Mar 2003 15:26:11 +0100 (CET) Date: Mon, 10 Mar 2003 15:26:11 +0100 From: Marijn Meijles To: Vallo Kallaste Cc: arch@FreeBSD.org Subject: Re: New scheduler problem Message-ID: <20030310142610.GC7580@hoop.bitpit.net> References: <20030206094040.GA2000@kevad.internal> <20030207211000.P72073-100000@mail.chesapeake.net> <20030210113928.GA10552@hoop.bitpit.net> <20030310041714.GA67308@terry.dragon2.net> <20030310080444.GB1122@kevad.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030310080444.GB1122@kevad.internal> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Vallo Kallaste wrote: > On Mon, Mar 10, 2003 at 12:17:14PM +0800, Ying-Chieh Liao > wrote: > > > On Mon, Feb 10, 2003 at 12:39:28 +0100, Marijn Meijles wrote: > > > With strict rescheduling turned on it runs a lot better. It is about as > > > responsive as the 4BSD scheduler. > > > > how to turn on "strict rescheduling" ? > > Can't remember the kernel configuration option, but IMO Jeff turned > it on by default some time ago, so you needn't be concerned about > it. Search arch@ archives for last month. It's turned on by default now. The latest version is quite good, although nice values are not handled correctly. But I believe Jeff is working on that. The same is true for forking. On a loaded system child processes are born with a rather high PRI value. -- Marijn@bitpit.net --- Hard work pays off later, laziness pays off now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 10 8:49: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 150EA37B401 for ; Mon, 10 Mar 2003 08:48:59 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5775C43F93 for ; Mon, 10 Mar 2003 08:48:58 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.244.104.52.dial1.sanjose1.level3.net ([209.244.104.52] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18sQSM-0002Ce-00; Mon, 10 Mar 2003 08:48:55 -0800 Message-ID: <3E6CC194.96EADAA7@mindspring.com> Date: Mon, 10 Mar 2003 08:47:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes, -Create option for rc.diskless References: <20030310000219.N15648-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4b417cee0c253cdfab57b3c599ff4a050350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > Well, the idea of -C is to make the "manual creation" process > something that rc.diskless2 can do trivially and reliably, by > just asking newsyslog to do it. If we instead use mtree to > create the initial files, then I think we'll end up with two > different databases that will have to have the same information. Or worse: one that's a subset or superset of the other. It's much more useful to have a "create" option, like you have. BTW: mtree would make that *three* databases, not two. There are seperate syslog and newsyslog databases. This is probably less important, since newsyslog is bound to be a superset or equivalence set of the syslog file, but they are seperately maintained, which is annoying (and probably the main reason people keep talking about integrating newsyslog into syslog). > However, I have been thinking about the fact that newsyslog.conf > does often contain rules for files that don't exist. This patch > currently adds the -C option, and also adds a C flag for config-file > entries. Perhaps the 'C' flag should not mean "always create > this file if it does not exist". Perhaps it should mean "create > this file if it does not exist, and if -C was given". That way, > the -C option becomes "create all log files which have a C flag". Yes. This makes more sense. For example, Samba is likely to start after newsyslog starts, so it should be non-automatic. > That means our C flag would be a little different than NetBSD's > C flag, but I think it's a reasonable idea. That way the config > file can have a long list of entries, only some of which would be > automatically created. What do people think about that idea? What do the NetBSD folks say? They may have good reasons for not behaving that way... > [the more I think about it, the more I like it, although it means > more explanation will be needed in the man page] -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 10 11:54:23 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B2F337B401 for ; Mon, 10 Mar 2003 11:54:21 -0800 (PST) Received: from mail26a.sbc-webhosting.com (mail26a.sbc-webhosting.com [216.173.237.36]) by mx1.FreeBSD.org (Postfix) with SMTP id B0CDF43FA3 for ; Mon, 10 Mar 2003 11:54:20 -0800 (PST) (envelope-from alc@imimic.com) Received: from www.imimic.com (64.143.12.21) by mail26a.sbc-webhosting.com (RS ver 1.0.77vs) with SMTP id 0385216041; Mon, 10 Mar 2003 14:54:01 -0500 (EST) Message-ID: <3E6CED5E.260E568E@imimic.com> Date: Mon, 10 Mar 2003 13:54:06 -0600 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sean Chittenden Cc: arch@freebsd.org Subject: Re: Should sendfile() to return EAGAIN? [patch] References: <3E64FEA0.CCA21C7@imimic.com> <20030309135037.GK79234@perrin.int.nxad.com> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sean Chittenden wrote: > > > Given that the main purpose of the sf_buf is simply to provide an > > in-kernel virtual address for the page, one sf_buf per page should > > suffice. Sf_bufs are already reference counted. So, the principle > > change would be to add a directory data structure that could answer > > the question "Does this page already have an allocated sf_buf?" > > Is this kind of a structure already in use someplace in the tree? I > poked around for a bit and couldn't find anything that'd suggest that > it's already been done. Do you know if/where I could poach code > that'd provide this functionality or would this be fresh bits that'd > that'd have to hit the tree? Andrew Gallatin outlined an implementation earlier in this thread. I've e-mailed you a patch that does the critical parts of what he outlined. > ... > Lastly, I couldn't find any bits to suggest how data coherency is > maintained. What's the mechanism in place that guarantee's this? > It's inherent. The same physical page is being shared by all invocations of sendfile() and the rest of the system. Observe that vm_page_lookup() is among the first VM operations performed. This checks to see if there is an existing physical page containing the data. If not, one is allocated and filled with data. This new page is then available to other sendfile() invocations and the rest of the system. If there is a coherence problem with sendfile(), it's the opposite of what you think: If someone mutates the file through, e.g., an mmap()ing, after a sendfile() had already started and returned, the data sent could include some of the new changes. (I think this is easiest to see if you imagine packet loss and retransmission occuring.) Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 11 1:43:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91B2537B401 for ; Tue, 11 Mar 2003 01:43:58 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 032A843FB1 for ; Tue, 11 Mar 2003 01:43:56 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h2B9hsmF083353 for ; Tue, 11 Mar 2003 12:43:54 +0300 (MSK) Date: Tue, 11 Mar 2003 12:43:54 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] In-Reply-To: <3E6CED5E.260E568E@imimic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Mar 2003, Alan L. Cox wrote: >Andrew Gallatin outlined an implementation earlier in this thread. I've >e-mailed you a patch that does the critical parts of what he outlined. If this implementation increases vm_page size I think it should be enabled via option in the kernel configuration. A typical FreeBSD machine never uses sendfile() or uses little and never exhausts sf_buf's so this increase would waste the kernel memory. Igor Sysoev http://sysoev.ru/en/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 11 11:30:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D40B37B401 for ; Tue, 11 Mar 2003 11:30:45 -0800 (PST) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FBFE43FBF for ; Tue, 11 Mar 2003 11:30:44 -0800 (PST) (envelope-from roam@ringlet.net) Received: (qmail 19261 invoked from network); 11 Mar 2003 19:26:20 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 11 Mar 2003 19:26:20 -0000 Received: (qmail 89861 invoked by uid 1000); 11 Mar 2003 19:29:13 -0000 Date: Tue, 11 Mar 2003 21:29:13 +0200 From: Peter Pentchev To: arch@FreeBSD.org Subject: [CFR] Remove ftp2.it.FreeBSD.org from sysinstall's mirrors list Message-ID: <20030311192913.GA578@straylight.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FT/vNgDLxVq4t/AU" Content-Disposition: inline User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --FT/vNgDLxVq4t/AU Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Would anybody have any serious objections to my committing the attached patch, which goes hand-in-hand with the one submitted by Alex Dupre in PR docs/49117 to remove ftp2.it from the Handbook? G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. Index: src/usr.sbin/sysinstall/menus.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v retrieving revision 1.369 diff -u -r1.369 menus.c --- src/usr.sbin/sysinstall/menus.c 8 Mar 2003 12:07:13 -0000 1.369 +++ src/usr.sbin/sysinstall/menus.c 11 Mar 2003 19:19:18 -0000 @@ -657,8 +657,6 @@ VAR_FTP_PATH "=3Dftp://ftp2.il.freebsd.org" }, { "Italy", "ftp.it.freebsd.org", NULL, dmenuSetVariable, NULL, VAR_FTP_PATH "=3Dftp://ftp.it.freebsd.org" }, - { " Italy #2", "ftp2.it.freebsd.org", NULL, dmenuSetVariable, NULL, - VAR_FTP_PATH "=3Dftp://ftp2.it.freebsd.org" }, { "Japan", "ftp.jp.freebsd.org", NULL, dmenuSetVariable, NULL, VAR_FTP_PATH "=3Dftp://ftp.jp.freebsd.org" }, { " Japan #2", "ftp2.jp.freebsd.org", NULL, dmenuSetVariable, NULL, --FT/vNgDLxVq4t/AU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+bjkJ7Ri2jRYZRVMRAiJrAJ9tZuSPRIHStGPwTfn11EJF8WCK7QCfcoun 0naslr5vffzaCbZ6a022IhM= =pG3U -----END PGP SIGNATURE----- --FT/vNgDLxVq4t/AU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 11 17:23:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FFD537B401 for ; Tue, 11 Mar 2003 17:23:45 -0800 (PST) Received: from cocono.com.tw (170-142.kingnet.net.tw [61.57.170.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id C008343F85 for ; Tue, 11 Mar 2003 17:23:43 -0800 (PST) (envelope-from ibenz@cocono.com.tw) From: acom@cm.com.tw To: arch@FreeBSD.ORG Subject: =?ISO-8859-1?B?pOmxYKXOq36kV7r0wco=?= Reply-To: com@cc.com.tw Date: 12 Mar 2003 09:22:17 +0800 MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: <20030312012343.C008343F85@mx1.FreeBSD.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ±z¦³¤U¦C¯S½è¶Ü
«lÃz¡I¡I¾_¾Ù¡I¡I
±z¦³¤U¦C¯S½è¶Ü¡H
1.¨Æ·~¥ø¹Ï¤ß
2.¤£¥Ì¤ß¥­¤Z
3.¤£º¡©ó²{ª¬
4.«i©ó­±¹ï¥¼¨Ó
¥u­n±z¾Ö¦³¤W¦C¯S½è¡A§Ú­Ì±N§K¶O°ö°V±z©Ò¦³¬ÛÃö§Þ¾¯à¤O¡A´£¨Ñ±zµ²¦Xºô¸ô¡B¹êÅé¡A­¹¦ç¦í¦æ¡B ¦Y³Üª±¼Öªº³q¸ô¨Æ·~¡IÂI¿ï§Ú¡A±z´N¥i¥H±o¨ì¡I
ps:±N·|¦³±M¤H¬°±z¸Ô²Ó¸Ñ»¡³á¡I
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 12 18: 4:13 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 219B537B401 for ; Wed, 12 Mar 2003 18:04:12 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C74743FBD for ; Wed, 12 Mar 2003 18:04:11 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.8/8.12.8) with ESMTP id h2D24ARv000274 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Mar 2003 21:04:10 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h2D245d88680; Wed, 12 Mar 2003 21:04:05 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15983.59156.942545.147957@grasshopper.cs.duke.edu> Date: Wed, 12 Mar 2003 21:04:04 -0500 (EST) To: Igor Sysoev Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return EAGAIN? [patch] In-Reply-To: References: <3E6CED5E.260E568E@imimic.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Igor Sysoev writes: > On Mon, 10 Mar 2003, Alan L. Cox wrote: > > >Andrew Gallatin outlined an implementation earlier in this thread. I've > >e-mailed you a patch that does the critical parts of what he outlined. > > If this implementation increases vm_page size I think it should be enabled > via option in the kernel configuration. A typical FreeBSD machine never uses > sendfile() or uses little and never exhausts sf_buf's so this increase > would waste the kernel memory. > This could be done w/o increasing the page size. (ie, move the cow field of the vm_page to the sf_buf; see earlier message for details). Also, this change will be very helpful as it will allow sf_bufs to be used as general purpose containers for temporary kvm mappings.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 13 11:20:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B50C337B401 for ; Thu, 13 Mar 2003 11:20:45 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B01443F75 for ; Thu, 13 Mar 2003 11:20:45 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 453622ED3CF; Thu, 13 Mar 2003 11:20:45 -0800 (PST) Date: Thu, 13 Mar 2003 20:20:45 +0100 From: Maxime Henrion To: arch@FreeBSD.org Subject: WARNS=6 changes Message-ID: <20030313192045.GG3819@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, I've been told it would be good to post this change here for discussion, so here it is. This patch changes the default standard used for warnings from c89 to c99. It only affects WARNS=6 code (that is, very few code). It also makes it possible to select another standard with the WSTD variable if we ever need to. Of course, I've tested that no parts of the build is broken with this patch. Cheers, Maxime --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bsd.sys.mk.patch" Index: bsd.sys.mk =================================================================== RCS file: /space2/ncvs/src/share/mk/bsd.sys.mk,v retrieving revision 1.11 diff -u -p -r1.11 bsd.sys.mk --- bsd.sys.mk 13 Nov 2002 13:49:29 -0000 1.11 +++ bsd.sys.mk 13 Mar 2003 18:25:40 -0000 @@ -29,7 +29,8 @@ CFLAGS += -Wuninitialized . endif # BDECFLAGS . if ${WARNS} > 5 -CFLAGS += -ansi -pedantic -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls +WSTD ?= c99 +CFLAGS += -std=${WSTD} -pedantic -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls . endif . if ${WARNS} > 1 && ${WARNS} < 5 # XXX Delete -Wuninitialized by default for now -- the compiler doesn't --uZ3hkaAS1mZxFaxD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 14 3:16:55 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EDA337B444 for ; Fri, 14 Mar 2003 03:16:54 -0800 (PST) Received: from bol.com.br (200-163-046-058.cpece7003.dsl.brasiltelecom.net.br [200.163.46.58]) by mx1.FreeBSD.org (Postfix) with SMTP id 3E44144003 for ; Fri, 14 Mar 2003 03:16:35 -0800 (PST) (envelope-from redacaocoml@bol.com.br) From: "Redação Comercial" To: Subject: 300 Modelos de Cartas comerciais, avisos, convites, propostas, etc. Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 14 Mar 2003 07:16:28 -0400 Content-Transfer-Encoding: 8bit Message-Id: <20030314111635.3E44144003@mx1.FreeBSD.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG COMUNICADO IMPORTANTE!! Estamos lançando o KIT DE CARTAS COMERCIAIS, que sana suas dúvidas na elaboração de: agradecimentos, atestados e declarações, avisos, cartas de cobrança, cartas em inglês, comunicados, convites, contratos, propostas, empregos, solicitações e pedidos, telegramas, cartas por e-mail, etc. Composto de 02 (dois) disquetes com 150 modelos de documentos cada um, mais livreto 20 páginas, com técnicas de redação comercial. Indicado para: secretárias em geral, gerências, Rh, executivos, estudantes e empresas de toda ordem. Este kit possui um preço ínfimo em relação ao que poderá gerar no aperfeiçoamento da comunicação de sua empresa. Acesse nossa Home Page para mais detalhes: http://www.redacaocartas.ihp.com.br Ps: Caso não queira receber novas mensagens e novidades sobre esse assunto, acesse: http://www.remova-me.ihp.com.br To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 14 9:58:27 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9763737B401; Fri, 14 Mar 2003 09:58:25 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D5A843FBD; Fri, 14 Mar 2003 09:58:21 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Sunbay) with ESMTP id h2EHwEFZ095962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2003 19:58:14 +0200 (EET) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Submit) id h2EHwEMC095957; Fri, 14 Mar 2003 19:58:14 +0200 (EET) (envelope-from ru) Date: Fri, 14 Mar 2003 19:58:14 +0200 From: Ruslan Ermilov To: Maxime Henrion Cc: arch@FreeBSD.ORG Subject: Re: WARNS=6 changes Message-ID: <20030314175814.GC94719@sunbay.com> References: <20030313192045.GG3819@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9" Content-Disposition: inline In-Reply-To: <20030313192045.GG3819@elvis.mu.org> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2003 at 08:20:45PM +0100, Maxime Henrion wrote: > Hi all, >=20 >=20 > I've been told it would be good to post this change here for discussion, > so here it is. This patch changes the default standard used for > warnings from c89 to c99. It only affects WARNS=3D6 code (that is, very > few code). It also makes it possible to select another standard with > the WSTD variable if we ever need to. Of course, I've tested that no > parts of the build is broken with this patch. >=20 I think that *not* hard-coding WSTD is not good, because it then may mean different things for different settings. > Index: bsd.sys.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /space2/ncvs/src/share/mk/bsd.sys.mk,v > retrieving revision 1.11 > diff -u -p -r1.11 bsd.sys.mk > --- bsd.sys.mk 13 Nov 2002 13:49:29 -0000 1.11 > +++ bsd.sys.mk 13 Mar 2003 18:25:40 -0000 > @@ -29,7 +29,8 @@ CFLAGS +=3D -Wuninitialized > . endif > # BDECFLAGS > . if ${WARNS} > 5 > -CFLAGS +=3D -ansi -pedantic -Wbad-function-cast -Wchar-subscripts -Winl= ine -Wnested-externs -Wredundant-decls > +WSTD ?=3D c99 > +CFLAGS +=3D -std=3D${WSTD} -pedantic -Wbad-function-cast -Wchar-subscri= pts -Winline -Wnested-externs -Wredundant-decls > . endif > . if ${WARNS} > 1 && ${WARNS} < 5 > # XXX Delete -Wuninitialized by default for now -- the compiler doesn't Cheers, --=20 Ruslan Ermilov Sysadmin and 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 --gj572EiMnwbLXET9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+chg2Ukv4P6juNwoRAjVtAJ0fHM1PRKSkCeFmTV4uOvRfqfNIkQCggzvB 1TVQ6RdXbHxtHXx74fJGhms= =1MCt -----END PGP SIGNATURE----- --gj572EiMnwbLXET9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 14 10:15:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9C4237B401; Fri, 14 Mar 2003 10:15:46 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 664C943FA3; Fri, 14 Mar 2003 10:15:46 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 4E7012ED40A; Fri, 14 Mar 2003 10:15:46 -0800 (PST) Date: Fri, 14 Mar 2003 19:15:46 +0100 From: Maxime Henrion To: Ruslan Ermilov Cc: arch@FreeBSD.ORG Subject: Re: WARNS=6 changes Message-ID: <20030314181546.GH3819@elvis.mu.org> References: <20030313192045.GG3819@elvis.mu.org> <20030314175814.GC94719@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030314175814.GC94719@sunbay.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > On Thu, Mar 13, 2003 at 08:20:45PM +0100, Maxime Henrion wrote: > > Hi all, > > > > > > I've been told it would be good to post this change here for discussion, > > so here it is. This patch changes the default standard used for > > warnings from c89 to c99. It only affects WARNS=6 code (that is, very > > few code). It also makes it possible to select another standard with > > the WSTD variable if we ever need to. Of course, I've tested that no > > parts of the build is broken with this patch. > > > I think that *not* hard-coding WSTD is not good, because it then > may mean different things for different settings. I'm not sure I understand your concerns here. Could you explain what you mean a bit please? Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 14 10:21:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2385437B401; Fri, 14 Mar 2003 10:21:52 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E69FC43F75; Fri, 14 Mar 2003 10:21:47 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Sunbay) with ESMTP id h2EILiFZ099480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2003 20:21:44 +0200 (EET) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Submit) id h2EILip7099475; Fri, 14 Mar 2003 20:21:44 +0200 (EET) (envelope-from ru) Date: Fri, 14 Mar 2003 20:21:44 +0200 From: Ruslan Ermilov To: Maxime Henrion Cc: arch@freebsd.org Subject: Re: WARNS=6 changes Message-ID: <20030314182144.GA98870@sunbay.com> References: <20030313192045.GG3819@elvis.mu.org> <20030314175814.GC94719@sunbay.com> <20030314181546.GH3819@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <20030314181546.GH3819@elvis.mu.org> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2003 at 07:15:46PM +0100, Maxime Henrion wrote: > Ruslan Ermilov wrote: > > On Thu, Mar 13, 2003 at 08:20:45PM +0100, Maxime Henrion wrote: > > > Hi all, > > >=20 > > >=20 > > > I've been told it would be good to post this change here for discussi= on, > > > so here it is. This patch changes the default standard used for > > > warnings from c89 to c99. It only affects WARNS=3D6 code (that is, v= ery > > > few code). It also makes it possible to select another standard with > > > the WSTD variable if we ever need to. Of course, I've tested that no > > > parts of the build is broken with this patch. > > >=20 > > I think that *not* hard-coding WSTD is not good, because it then > > may mean different things for different settings. >=20 > I'm not sure I understand your concerns here. Could you explain what > you mean a bit please? >=20 I want WARNS=3DX to be a constant set of warning options, no variable portion. Cheers, --=20 Ruslan Ermilov Sysadmin and 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 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+ch24Ukv4P6juNwoRAlyEAJ0TOA7FfLNIFpGvr6cD5k8wsebB2QCfRH3G jpR4vCtSiLdc2/SgJ5IhPBI= =wbsy -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 14 11:43:10 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4121537B401; Fri, 14 Mar 2003 11:43:09 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6878D43F75; Fri, 14 Mar 2003 11:43:07 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h2EJh5QA023186; Fri, 14 Mar 2003 14:43:05 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030314181546.GH3819@elvis.mu.org> References: <20030313192045.GG3819@elvis.mu.org> <20030314175814.GC94719@sunbay.com> <20030314181546.GH3819@elvis.mu.org> Date: Fri, 14 Mar 2003 14:43:04 -0500 To: Maxime Henrion , Ruslan Ermilov From: Garance A Drosihn Subject: Re: WARNS=6 changes Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:15 PM +0100 3/14/03, Maxime Henrion wrote: >Ruslan Ermilov wrote: > > On Thu, Mar 13, 2003, Maxime Henrion wrote: > > > This patch changes the default standard used for warnings > > > from c89 to c99. It only affects WARNS=6 code (that is, very > > > few code). It also makes it possible to select another > > > standard with the WSTD variable if we ever need to. > > > > I think that *not* hard-coding WSTD is not good, because it > > then may mean different things for different settings. > >I'm not sure I understand your concerns here. Could you explain >what you mean a bit please? I think he's saying that he does not want the user to have a separate switch for WSTD. WARNS=6 would always mean C99, or would never mean it. Me, I'd kinda like the idea of a separate switch for which standard to use, but I'm not sure why that switch would only be for WARNS=6... Basically I'm inclined to think that trying to merge the 4800 different -W flags of gcc into just one numerical value is pretty much a hopeless task anyway... -- Garance Alistair Drosehn = gad@gilead.netel.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-arch" in the body of the message From owner-freebsd-arch Fri Mar 14 12:12:53 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD8637B401; Fri, 14 Mar 2003 12:12:50 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D149343FBF; Fri, 14 Mar 2003 12:12:46 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Sunbay) with ESMTP id h2EKCaeK011331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2003 22:12:37 +0200 (EET) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Submit) id h2EKCaMF011326; Fri, 14 Mar 2003 22:12:36 +0200 (EET) (envelope-from ru) Date: Fri, 14 Mar 2003 22:12:36 +0200 From: Ruslan Ermilov To: Garance A Drosihn Cc: Maxime Henrion , arch@FreeBSD.ORG Subject: Re: WARNS=6 changes Message-ID: <20030314201236.GD8760@sunbay.com> References: <20030313192045.GG3819@elvis.mu.org> <20030314175814.GC94719@sunbay.com> <20030314181546.GH3819@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C+ts3FVlLX8+P6JN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --C+ts3FVlLX8+P6JN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2003 at 02:43:04PM -0500, Garance A Drosihn wrote: > At 7:15 PM +0100 3/14/03, Maxime Henrion wrote: > >Ruslan Ermilov wrote: > > > On Thu, Mar 13, 2003, Maxime Henrion wrote: > > > > This patch changes the default standard used for warnings > > > > from c89 to c99. It only affects WARNS=3D6 code (that is, very > > > > few code). It also makes it possible to select another > > > > standard with the WSTD variable if we ever need to. > > > > > > I think that *not* hard-coding WSTD is not good, because it > > > then may mean different things for different settings. > > > >I'm not sure I understand your concerns here. Could you explain > >what you mean a bit please? >=20 > I think he's saying that he does not want the user to have a > separate switch for WSTD. WARNS=3D6 would always mean C99, or > would never mean it. >=20 Yes. More precisely, I don't want it to affect WARNS=3D6. > Me, I'd kinda like the idea of a separate switch for which > standard to use, but I'm not sure why that switch would only > be for WARNS=3D6... Basically I'm inclined to think that trying > to merge the 4800 different -W flags of gcc into just one > numerical value is pretty much a hopeless task anyway... >=20 If you want to switch between different stds, then user redefineable CWARNFLAGS is probably what you should use. (This is in an assumption that the last standard option specified is what's getting used.) As an aside, having -ansi in "warning flags" is probably a bug anyway, as this is the language rather than warning option. Cheers, --=20 Ruslan Ermilov Sysadmin and 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 --C+ts3FVlLX8+P6JN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+cje0Ukv4P6juNwoRAsNHAJ9mXZpPJYE6mxutFen4zrsc4QaF2wCeI8o+ bN8M28LtJrkecqtH27sPjzg= =qLNY -----END PGP SIGNATURE----- --C+ts3FVlLX8+P6JN-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 14 23:54:39 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BF2037B404; Fri, 14 Mar 2003 23:54:34 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A65F43F93; Fri, 14 Mar 2003 23:54:33 -0800 (PST) (envelope-from das@FreeBSD.org) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h2F7sSIX025528; Fri, 14 Mar 2003 23:54:28 -0800 (PST) (envelope-from das@FreeBSD.org) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h2F7sSpC025527; Fri, 14 Mar 2003 23:54:28 -0800 (PST) (envelope-from das@FreeBSD.org) Date: Fri, 14 Mar 2003 23:54:27 -0800 From: David Schultz To: Juli Mallett Cc: Eivind Eklund , Mike Silbersack , arch@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c Message-ID: <20030315075427.GA25332@HAL9000.homeunix.com> Mail-Followup-To: Juli Mallett , Eivind Eklund , Mike Silbersack , arch@FreeBSD.org References: <200303122313.h2CNDHMU046431@repoman.freebsd.org> <20030312175458.J32334@odysseus.silby.com> <20030313005115.GA11794@HAL9000.homeunix.com> <20030313154226.X682@odysseus.silby.com> <20030314012954.A42430@FreeBSD.org> <20030314101857.A98861@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030314101857.A98861@FreeBSD.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Followups set to arch@] Thus spake Juli Mallett : > I've had that happen for me (though the combinations required are a lot > lower, as my RAM is a lot lower :>), and that's why I started looking into > this. I didn't realise my name had been dragged into this until just now :) > > Basically I was adding a new signal, SIGVM (or SIGNOMEM), and the semantics > were as such: > 1) If a process has SIG_IGN for the signal set, it is skipped over > when looking for a process to kill. > 2) If a process has SIG_DFL for the signal set, it is "killable," > in that it is willing to die. > 3) If a process has a handler for the signal set, that handler is > invoked*. The rest of this thread seems to have gone off in half a dozen unrelated directions, so I'm replying to your original post. I think the fundamental principle here is that when the kernel is dangerously low on virtual memory, it needs to be able to choose a process to kill and be guaranteed that the process will die right away and without generating many page faults. It would also be great if the administrator could mark a few processes as off-limits in a way that the pagedaemon can understand. Remember that this is a rather rare situation; the system doesn't have to do something incredibly intelligent, it just has to do something reasonable. Beyond that, getting the kernel to send out ``I might kill you soon, so exit'' warnings ahead of time would be cool if userland programs were taught about them. But the kernel has to do that while there's still enough memory to entertain the idea of cooperation. phk's idea is also interesting but unrelated; IIRC, the keyword to search the archives for is SIGVM. > * - Note that I've waffled about that quite a bit. I think that we'd want > libc to maybe default to letting phkmalloc try to shrink the break area, > or get rid of some spare buffers. All the obvious things like that. The 'H' option to malloc() notifies the kernel of heap space that can be marked clean and reused via madvise(). It is disabled by default, but you could imagine that malloc() might take a signal from the kernel and start making madvise() calls automatically. But as phk mentioned, this is something you do when you have insufficient physical memory, not when you're out of swap, so it's a separate topic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 15 2: 4:17 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB51237B405 for ; Sat, 15 Mar 2003 02:04:03 -0800 (PST) Received: from 211-189-139-167.rev.krline.net (211-189-139-167.rev.krline.net [211.189.139.167]) by mx1.FreeBSD.org (Postfix) with SMTP id A53E843FBF for ; Sat, 15 Mar 2003 02:04:02 -0800 (PST) (envelope-from sender@refill.co.kr) Received: from zOA (unverified [211.235.237.59]) by 211-189-139-167.rev.krline.net (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 15 Mar 2003 06:54:33 +0900 Message-ID: Subject: =?ks_c_5601-1987?Q?(=B1=A4=B0=ED)=C0=FA=B7=C5=C7=D1_=C7=C1=B8=B0=C5=CD_=C5=E4=B3=CA_=BC=EE=C7=CE=B8=F4_REFILL=2ECO=2EKR__@?= From: "=?ks_c_5601-1987?Q?REFILL=2ECO=2EKR?=" Date: Sat, 15 Mar 2003 06:54:34 +0900 To: "=?ks_c_5601-1987?Q?freebsd-arch@freebsd=2Eorg?=" X-Priority: 3 X-MSMail-Priority: Normal Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailer: JMail 4.3.1 by Dimac Content-Type: text/html X-Antirelay: Good relay from local net1 211.235.237.1/26 'Kiologic Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG DQo8aHRtbD4NCjxoZWFkPg0KPHRpdGxlPrTrx9G5zrG5ILTrx6UguK7Hyrvn wMzGriA6Ojo6Ojo6Ojo6IFJlZmlsbC5jby5rcjwvdGl0bGU+DQo8bWV0YSBo dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg Y2hhcnNldD1ldWMta3IiPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwh LS0NCi5ub21fdHh0IHsgIGZvbnQtZmFtaWx5OiAitbi/8iI7IGZvbnQtc2l6 ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6ICNBNUE1QTV9 DQotLT4NCjwvc3R5bGU+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9IiNG RkZGRkYiIGxlZnRtYXJnaW49IjAiIHRvcG1hcmdpbj0iMCIgbWFyZ2lud2lk dGg9IjAiIG1hcmdpbmhlaWdodD0iMCI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 IjYwMCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9 IjAiIGFsaWduPSJjZW50ZXIiPg0KPHRyPg0KPHRkIHdpZHRoPSIxIiBiZ2Nv bG9yPSIjQzZDNkM2Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28u a3IvbWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9ibGFuay5naWYiPjwvdGQ+DQo8 dGQgd2lkdGg9IjU5OCI+DQo8dGFibGUgd2lkdGg9IjU5OCIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRyPg0KPHRk IGNvbHNwYW49IjIiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZmlsbC5jby5r ci9tYWlsL25ld3NsZXR0ZXIvaW1hZ2VzL2Jhcl90b3AuZ2lmIiB3aWR0aD0i NTk4IiBoZWlnaHQ9IjIxIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZD48YSBo cmVmPSJodHRwOi8vd3d3LnJlZmlsbC5jby5rci9pbmRleC5hc3AiIHRhcmdl dD0iX2JsYW5rIj48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3Iv bWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9sb2dvLmdpZiIgd2lkdGg9IjE3MiIg aGVpZ2h0PSI1NiIgYm9yZGVyPSIwIj48L2E+PC90ZD4NCjx0ZD48YSBocmVm PSJodHRwOi8vd3d3LnJlZmlsbC5jby5rci9odG1sL1Byb1RvbmVyTGlzdC5h c3A/aW1nY2hrPTIiIHRhcmdldD0iX2JsYW5rIj48aW1nIHNyYz0iaHR0cDov L3d3dy5yZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9iX3No b3BwaW5nLmdpZiIgd2lkdGg9IjEzOSIgaGVpZ2h0PSI1NiIgYWxpZ249InJp Z2h0IiBib3JkZXI9IjAiPjwvYT48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBj b2xzcGFuPSIyIj48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3Iv bWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9iYW5fbWFpbi5qcGciIHdpZHRoPSI1 OTgiIGhlaWdodD0iMTk1Ij48YnI+DQo8aW1nIHNyYz0iaHR0cDovL3d3dy5y ZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9leHAuZ2lmIiB3 aWR0aD0iNTk4IiBoZWlnaHQ9IjQ5Ij48L3RkPg0KPC90cj4NCjx0ciBhbGln bj0iY2VudGVyIj4NCjx0ZCBjb2xzcGFuPSIyIj4NCjx0YWJsZSB3aWR0aD01 MjQgYm9yZGVyPTAgY2VsbHBhZGRpbmc9MCBjZWxsc3BhY2luZz0wPg0KPHRy Pg0KPHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVmaWxsLmNvLmtyL2h0bWwv UHJvVG9uZXJMaXN0LmFzcD9pbWdjaGs9MiIgdGFyZ2V0PSJfYmxhbmsiPjxp bWcgc3JjPSJodHRwOi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0 ZXIvaW1hZ2VzL2JyYW5kXzAxLmdpZiIgd2lkdGg9MTAxIGhlaWdodD01NiBh bHQ9IiIgYm9yZGVyPSIwIj48L2E+PC90ZD4NCjx0ZD48YSBocmVmPSJodHRw Oi8vd3d3LnJlZmlsbC5jby5rci9odG1sL1Byb1RvbmVyTGlzdC5hc3A/aW1n Y2hrPTImYW1wO0NhdGVnb3J5PVQmYW1wO1NlbGVjdENvbXBhbnk9JUJCJUVG JUJDJUJBIiB0YXJnZXQ9Il9ibGFuayI+PGltZyBzcmM9Imh0dHA6Ly93d3cu cmVmaWxsLmNvLmtyL21haWwvbmV3c2xldHRlci9pbWFnZXMvYnJhbmRfMDIu Z2lmIiB3aWR0aD0xMDkgaGVpZ2h0PTU2IGFsdD0iIiBib3JkZXI9IjAiPjwv YT48L3RkPg0KPHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVmaWxsLmNvLmty L2h0bWwvUHJvVG9uZXJMaXN0LmFzcD9pbWdjaGs9MiZhbXA7Q2F0ZWdvcnk9 VCZhbXA7U2VsZWN0Q29tcGFueT0lQzUlQTUlQjQlRDAlQkQlQkEiIHRhcmdl dD0iX2JsYW5rIj48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3Iv bWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9icmFuZF8wMy5naWYiIHdpZHRoPTEx NiBoZWlnaHQ9NTYgYWx0PSIiIGJvcmRlcj0iMCI+PC9hPjwvdGQ+DQo8dGQ+ PGEgaHJlZj0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3IvaHRtbC9Qcm9Ub25l ckxpc3QuYXNwP2ltZ2Noaz0yJmFtcDtDYXRlZ29yeT1UJmFtcDtTZWxlY3RD b21wYW55PSVCRCVDNSVCNSVCNSVCOCVBRSVDNCVEQSIgdGFyZ2V0PSJfYmxh bmsiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25l d3NsZXR0ZXIvaW1hZ2VzL2JyYW5kXzA0LmdpZiIgd2lkdGg9OTkgaGVpZ2h0 PTU2IGFsdD0iIiBib3JkZXI9IjAiPjwvYT48L3RkPg0KPHRkPjxhIGhyZWY9 Imh0dHA6Ly93d3cucmVmaWxsLmNvLmtyL2h0bWwvUHJvVG9uZXJMaXN0LmFz cD9pbWdjaGs9MiZhbXA7Q2F0ZWdvcnk9VCZhbXA7U2VsZWN0Q29tcGFueT1F UFNPTi8lQkIlRUYlQkElQjgiIHRhcmdldD0iX2JsYW5rIj48aW1nIHNyYz0i aHR0cDovL3d3dy5yZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0dGVyL2ltYWdl cy9icmFuZF8wNS5naWYiIHdpZHRoPTk5IGhlaWdodD01NiBhbHQ9IiIgYm9y ZGVyPSIwIj48L2E+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQ+PGEgaHJlZj0i aHR0cDovL3d3dy5yZWZpbGwuY28ua3IvaHRtbC9Qcm9Ub25lckxpc3QuYXNw P2ltZ2Noaz0yJmFtcDtDYXRlZ29yeT1UJmFtcDtTZWxlY3RDb21wYW55PSVD MSVBNiVCNyVDRiVCRCVCQSIgdGFyZ2V0PSJfYmxhbmsiPjxpbWcgc3JjPSJo dHRwOi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0ZXIvaW1hZ2Vz L2JyYW5kXzA2LmdpZiIgd2lkdGg9MTAxIGhlaWdodD00MCBhbHQ9IiIgYm9y ZGVyPSIwIj48L2E+PC90ZD4NCjx0ZD48YSBocmVmPSJodHRwOi8vd3d3LnJl ZmlsbC5jby5rci9odG1sL1Byb1RvbmVyTGlzdC5hc3A/aW1nY2hrPTImYW1w O0NhdGVnb3J5PVQmYW1wO1NlbGVjdENvbXBhbnk9TEciIHRhcmdldD0iX2Js YW5rIj48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3IvbWFpbC9u ZXdzbGV0dGVyL2ltYWdlcy9icmFuZF8wNy5naWYiIHdpZHRoPTEwOSBoZWln aHQ9NDAgYWx0PSIiIGJvcmRlcj0iMCI+PC9hPjwvdGQ+DQo8dGQ+PGEgaHJl Zj0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3IvaHRtbC9Qcm9Ub25lckxpc3Qu YXNwP2ltZ2Noaz0yJmFtcDtDYXRlZ29yeT1UJmFtcDtTZWxlY3RDb21wYW55 PSVDNCVCMyVCMyVFRCIgdGFyZ2V0PSJfYmxhbmsiPjxpbWcgc3JjPSJodHRw Oi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0ZXIvaW1hZ2VzL2Jy YW5kXzA4LmdpZiIgd2lkdGg9MTE2IGhlaWdodD00MCBhbHQ9IiIgYm9yZGVy PSIwIj48L2E+PC90ZD4NCjx0ZD48YSBocmVmPSJodHRwOi8vd3d3LnJlZmls bC5jby5rci9odG1sL1Byb1RvbmVyTGlzdC5hc3A/aW1nY2hrPTImYW1wO0Nh dGVnb3J5PVQmYW1wO1NlbGVjdENvbXBhbnk9JUMxJUE2JUMwJUNGJUMxJUE0 JUI5JUQwIiB0YXJnZXQ9Il9ibGFuayI+PGltZyBzcmM9Imh0dHA6Ly93d3cu cmVmaWxsLmNvLmtyL21haWwvbmV3c2xldHRlci9pbWFnZXMvYnJhbmRfMDku Z2lmIiB3aWR0aD05OSBoZWlnaHQ9NDAgYWx0PSIiIGJvcmRlcj0iMCI+PC9h PjwvdGQ+DQo8dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3Iv aHRtbC9Qcm9Ub25lckxpc3QuYXNwP2ltZ2Noaz0yJmFtcDtDYXRlZ29yeT1U JmFtcDtTZWxlY3RDb21wYW55PSVCMSVFMiVDNSVCOCIgdGFyZ2V0PSJfYmxh bmsiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25l d3NsZXR0ZXIvaW1hZ2VzL2JyYW5kXzEwLmdpZiIgd2lkdGg9OTkgaGVpZ2h0 PTQwIGFsdD0iIiBib3JkZXI9IjAiPjwvYT48L3RkPg0KPC90cj4NCjwvdGFi bGU+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBjb2xzcGFuPSIyIj48aW1n IHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0dGVy L2ltYWdlcy9iYXJfZG90LmdpZiIgd2lkdGg9IjU5OCIgaGVpZ2h0PSIxNyI+ PC90ZD4NCjwvdHI+DQo8dHIgYWxpZ249ImNlbnRlciI+DQo8dGQgY29sc3Bh bj0iMiI+DQo8dGFibGUgd2lkdGg9IjU3MiIgYm9yZGVyPSIwIiBjZWxsc3Bh Y2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGhlaWdodD0iOTAiPg0KPHRyPg0K PHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVmaWxsLmNvLmtyL2h0bWwvcHJv bWlzZS5hc3AiIHRhcmdldD0iX2JsYW5rIj48aW1nIHNyYz0iaHR0cDovL3d3 dy5yZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9iYW5fc3Vi MDEuZ2lmIiB3aWR0aD0iMTkxIiBoZWlnaHQ9Ijc1IiBib3JkZXI9IjAiPjwv YT48L3RkPg0KPHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVmaWxsLmNvLmty L2h0bWwvcG9wdXBfcmVjeWNsZS5odG0iIHRhcmdldD0iX2JsYW5rIj48aW1n IHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0dGVy L2ltYWdlcy9iYW5fc3ViMDIuZ2lmIiB3aWR0aD0iMTkwIiBoZWlnaHQ9Ijc1 IiBib3JkZXI9IjAiPjwvYT48L3RkPg0KPHRkPjxpbWcgc3JjPSJodHRwOi8v d3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0ZXIvaW1hZ2VzL2Jhbl9z dWIwMy5naWYiIHdpZHRoPSIxOTEiIGhlaWdodD0iNzUiPjwvdGQ+DQo8L3Ry Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIGNvbHNwYW49 IjIiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25l d3NsZXR0ZXIvaW1hZ2VzL2Jhcl9kb3QuZ2lmIiB3aWR0aD0iNTk4IiBoZWln aHQ9IjE3Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBjb2xzcGFuPSIyIj48 aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0 dGVyL2ltYWdlcy90X2NhcnRvb24uZ2lmIiB3aWR0aD0iMTYzIiBoZWlnaHQ9 IjIxIj48L3RkPg0KPC90cj4NCjx0ciBhbGlnbj0iY2VudGVyIj4NCjx0ZCBj b2xzcGFuPSIyIj4NCjx0YWJsZSB3aWR0aD01MTggYm9yZGVyPTAgY2VsbHBh ZGRpbmc9MCBjZWxsc3BhY2luZz0wPg0KPHRyPg0KPHRkPjxpbWcgc3JjPSJo dHRwOi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0ZXIvaW1hZ2Vz L2NhcnRvb25fMDEuZ2lmIiB3aWR0aD0yNzUgaGVpZ2h0PTIxNiBhbHQ9IiI+ PC90ZD4NCjx0ZD48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3Iv bWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9jYXJ0b29uXzAyLmdpZiIgd2lkdGg9 MjQzIGhlaWdodD0yMTYgYWx0PSIiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk PjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3Ns ZXR0ZXIvaW1hZ2VzL2NhcnRvb25fMDMuZ2lmIiB3aWR0aD0yNzUgaGVpZ2h0 PTIxMiBhbHQ9IiI+PC90ZD4NCjx0ZD48aW1nIHNyYz0iaHR0cDovL3d3dy5y ZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0dGVyL2ltYWdlcy9jYXJ0b29uXzA0 LmdpZiIgd2lkdGg9MjQzIGhlaWdodD0yMTIgYWx0PSIiPjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZmlsbC5jby5r ci9tYWlsL25ld3NsZXR0ZXIvaW1hZ2VzL2NhcnRvb25fMDUuZ2lmIiB3aWR0 aD0yNzUgaGVpZ2h0PTE5MSBhbHQ9IiI+PC90ZD4NCjx0ZD48aW1nIHNyYz0i aHR0cDovL3d3dy5yZWZpbGwuY28ua3IvbWFpbC9uZXdzbGV0dGVyL2ltYWdl cy9jYXJ0b29uXzA2LmdpZiIgd2lkdGg9MjQzIGhlaWdodD0xOTEgYWx0PSIi PjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkPjxpbWcgc3JjPSJodHRwOi8vd3d3 LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0ZXIvaW1hZ2VzL2NhcnRvb25f MDcuZ2lmIiB3aWR0aD0yNzUgaGVpZ2h0PTE4NiBhbHQ9IiI+PC90ZD4NCjx0 ZD48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3IvbWFpbC9uZXdz bGV0dGVyL2ltYWdlcy9jYXJ0b29uXzA4LmdpZiIgd2lkdGg9MjQzIGhlaWdo dD0xODYgYWx0PSIiPjwvdGQ+DQo8L3RyPg0KPC90YWJsZT4NCjwvdGQ+DQo8 L3RyPg0KPHRyPg0KPHRkIGNvbHNwYW49IjIiPjxpbWcgc3JjPSJodHRwOi8v d3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0ZXIvaW1hZ2VzL2Jhcl9k b3QuZ2lmIiB3aWR0aD0iNTk4IiBoZWlnaHQ9IjE3Ij48L3RkPg0KPC90cj4N Cjx0ciBhbGlnbj0iY2VudGVyIj4NCjx0ZCBjb2xzcGFuPSIyIj4NCjx0YWJs ZSB3aWR0aD0iNTc4IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxs cGFkZGluZz0iMTAiPg0KPHRyPg0KPHRkIHdpZHRoPSI0NzQiIHZhbGlnbj0i dG9wIiBjbGFzcz0ibm9tX3R4dCI+waS6uMXrvcW6ziCxx7DtILvnx9cguf23 /CDBpg0KNTDBtr+hIMDHsMXHz7+pIMGmuPG/oSAosaSw7Sm287DtIMelseLH 0SCxpLDtuN7Az8DMuOcsILHNx8/AxyC43sDPwda80rTCIMClILytx87B3yC+ y7DUILXIILDNwMy45ywgZU1haWwNCsHWvNIgv9y/oSCxzcfPwMcgvu62sMfR IMGkuri1tSCwocH2sO0gwNbB9iC+ysC4tM8gvsi9ycfPvcOx5iC52bb4tM+0 2S4gursguN7Az8C6ILnfvNvA/L/rILjewM/A08C4t84sIL/4xKENCr7KwLi9 w7jpIFu89r3FsMW6zl0gufbGsMC7IENsaWNrIMfYIMHWvLy/5C48YnI+PGJy Pg0KSWYgeW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGFueSBv ZiBvdXIgZGlzdHJpYnV0aW9uIGxpc3RzLCBwbGVhc2UgY2xpY2sgJ1JFRlVT RScuIEl0IHdpbGwgYmUgaGFuZGxlZCBwcm9tcHRseS4gVGhhbmsgeW91LiA8 YSBocmVmPSJodHRwOi8vd3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0 ZXIvMDMwMnJlamVjdC5hc3A/TWFpbE51bT1mcmVlYnNkLWFyY2hAZnJlZWJz ZC5vcmciIHRhcmdldD0iX2JsYW5rIj5bUkVGVVNFXTwvYT4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjY0IiBhbGlnbj0iY2VudGVyIj48YSBocmVmPSJodHRwOi8v d3d3LnJlZmlsbC5jby5rci9tYWlsL25ld3NsZXR0ZXIvMDMwMnJlamVjdC5h c3A/TWFpbE51bT1mcmVlYnNkLWFyY2hAZnJlZWJzZC5vcmciIHRhcmdldD0i X2JsYW5rIj48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWZpbGwuY28ua3IvbWFp bC9uZXdzbGV0dGVyL2ltYWdlcy9iX25vbWFpbC5naWYiIHdpZHRoPSI2MCIg aGVpZ2h0PSI2MCIgYm9yZGVyPSIwIj48L2E+PC90ZD4NCjwvdHI+DQo8L3Rh YmxlPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgY29sc3Bhbj0iMiI+PGlt ZyBzcmM9Imh0dHA6Ly93d3cucmVmaWxsLmNvLmtyL21haWwvbmV3c2xldHRl ci9pbWFnZXMvYmFyX2RvdC5naWYiIHdpZHRoPSI1OTgiIGhlaWdodD0iMTci PjwvdGQ+DQo8L3RyPg0KPHRyIGFsaWduPSJjZW50ZXIiPg0KPHRkIGNvbHNw YW49IjIiPg0KPHRhYmxlIHdpZHRoPSI1NzgiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIxMCI+DQo8dHI+DQo8dGQgd2lkdGg9 IjIyNyIgdmFsaWduPSJ0b3AiIGNsYXNzPSJub21fdHh0Ij48Yj6h2CCw7bC0 ILytuvG9uiC5rsDHIDogMDItMzI4MS03Nzc3IDwvYj48L3RkPg0KPHRkIHdp ZHRoPSIzMTEiIGFsaWduPSJyaWdodCIgY2xhc3M9Im5vbV90eHQiPkNvcHly aWdodCAxOTkxLTIwMDIuIEZ1dGVjaCBjbywuTHRkLiBBbGwgcmlnaHQgcmVz ZXJ2ZWQuPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8 dHI+PHRkIGNvbHNwYW49IjIiIGhlaWdodD0iMSIgYmdjb2xvcj0iI0M2QzZD NiI+PGltZyBzcmM9Imh0dHA6Ly93d3cucmVmaWxsLmNvLmtyL21haWwvbmV3 c2xldHRlci9pbWFnZXMvYmxhbmsuZ2lmIj48L3RkPjwvdHI+DQo8L3RhYmxl Pg0KPC90ZD4NCjx0ZCB3aWR0aD0iMSIgYmdjb2xvcj0iI0M2QzZDNiI+PGlt ZyBzcmM9Imh0dHA6Ly93d3cucmVmaWxsLmNvLmtyL21haWwvbmV3c2xldHRl ci9pbWFnZXMvYmxhbmsuZ2lmIj48L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8 YnI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 15 6:13:12 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CB7137B401; Sat, 15 Mar 2003 06:13:11 -0800 (PST) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD6443F75; Sat, 15 Mar 2003 06:13:09 -0800 (PST) (envelope-from fanf@chiark.greenend.org.uk) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 18uCPL-00046G-00 (Debian); Sat, 15 Mar 2003 14:13:07 +0000 Date: Sat, 15 Mar 2003 14:13:07 +0000 From: Tony Finch To: Juli Mallett , Eivind Eklund , Mike Silbersack , arch@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c Message-ID: <20030315141307.C10065@chiark.greenend.org.uk> References: <200303122313.h2CNDHMU046431@repoman.freebsd.org> <20030312175458.J32334@odysseus.silby.com> <20030313005115.GA11794@HAL9000.homeunix.com> <20030313154226.X682@odysseus.silby.com> <20030314012954.A42430@FreeBSD.org> <20030314101857.A98861@FreeBSD.org> <20030315075427.GA25332@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030315075427.GA25332@HAL9000.homeunix.com>; from das@FreeBSD.org on Fri, Mar 14, 2003 at 11:54:27PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 14, 2003 at 11:54:27PM -0800, David Schultz wrote: > > I think the fundamental principle here is that when the kernel is > dangerously low on virtual memory, it needs to be able to choose a > process to kill and be guaranteed that the process will die right > away and without generating many page faults. It would also be > great if the administrator could mark a few processes as > off-limits in a way that the pagedaemon can understand. Remember > that this is a rather rare situation; the system doesn't have to > do something incredibly intelligent, it just has to do something > reasonable. A couple of suggestions: don't kill processes with lots of children also counting their children's children (e.g. X) or that don't have a controlling terminal (daemons). Tony. -- f.a.n.finch http://dotat.at/ ROCKALL MALIN: SOUTHEASTERLY 4 OR 5, OCCASIONALLY 6 AT FIRST. MAINLY FAIR. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 15 7:52:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B48237B401 for ; Sat, 15 Mar 2003 07:52:37 -0800 (PST) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABA843FA3 for ; Sat, 15 Mar 2003 07:52:33 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd10.sul.t-online.de by mailout10.sul.t-online.com with smtp id 18uDxY-00056J-02; Sat, 15 Mar 2003 16:52:32 +0100 Received: from Andro-Beta.Leidinger.net (520065502893-0001@[217.83.30.174]) by fmrl10.sul.t-online.com with esmtp id 18uDxP-1xhW1AC; Sat, 15 Mar 2003 16:52:23 +0100 Received: from Magelan.Leidinger.net (Magelan [192.168.1.1]) by Andro-Beta.Leidinger.net (8.12.6/8.12.6) with ESMTP id h2FFqMOq021526 for ; Sat, 15 Mar 2003 16:52:22 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.12.7/8.12.7) with SMTP id h2FFqLL3006099 for ; Sat, 15 Mar 2003 16:52:21 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Sat, 15 Mar 2003 16:52:21 +0100 From: Alexander Leidinger To: arch@FreeBSD.org Subject: Bug in our make or undocumented feature? Message-Id: <20030315165221.27d3d424.Alexander@Leidinger.net> X-Mailer: Sylpheed version 0.8.9claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Sender: 520065502893-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, this part of a makefile doesn't work for me: ---snip--- WANTED_PORTS= shells/zsh lang/perl5 mytarget: .for i in ${WANTED_PORTS} @echo "${i}" .if ${i} == lang/perl5 @echo "Yep, perl5." .endif .endfor ---snip--- I get this output: ---snip--- # make "Makefile", line 2: Malformed conditional (shells/zsh == lang/perl5) "Makefile", line 2: Need an operator "Makefile", line 4: if-less endif "Makefile", line 4: Need an operator "Makefile", line 2: Malformed conditional (lang/perl5 == lang/perl5) "Makefile", line 2: Need an operator "Makefile", line 3: warning: duplicate script for target ".if" ignored "Makefile", line 3: warning: duplicate script for target "==" ignored "Makefile", line 4: if-less endif "Makefile", line 4: Need an operator make: fatal errors encountered -- cannot continue ---snip--- This is on -current as of Feb 14 and on -stable as of Dec 1. Did I overlook that we can't use such a conditional in a .for loop (where in make(1)?) or is this a bug in our make? Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 15 11:21:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2182037B401 for ; Sat, 15 Mar 2003 11:21:46 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A9EF43F93 for ; Sat, 15 Mar 2003 11:21:43 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.8/8.12.8) with ESMTP id h2FJLgSd071043; Sat, 15 Mar 2003 11:21:42 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h2FJLflO001048; Sat, 15 Mar 2003 11:21:41 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h2FJLfON001047; Sat, 15 Mar 2003 11:21:41 -0800 (PST) (envelope-from marcel) Date: Sat, 15 Mar 2003 11:21:41 -0800 From: Marcel Moolenaar To: Alexander Leidinger Cc: arch@FreeBSD.ORG Subject: Re: Bug in our make or undocumented feature? Message-ID: <20030315192141.GA564@dhcp01.pn.xcllnt.net> References: <20030315165221.27d3d424.Alexander@Leidinger.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20030315165221.27d3d424.Alexander@Leidinger.net> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Mar 15, 2003 at 04:52:21PM +0100, Alexander Leidinger wrote: > this part of a makefile doesn't work for me: > ---snip--- > WANTED_PORTS= shells/zsh lang/perl5 > > mytarget: > .for i in ${WANTED_PORTS} > @echo "${i}" > .if ${i} == lang/perl5 > @echo "Yep, perl5." > .endif > .endfor > ---snip--- Bug. A simpler case: .if "shells/zsh" == "lang/perl5" .endif dhcp01% make -f mf "mf", line 1: Malformed conditional ("shells/zsh" == "lang/perl5") "mf", line 1: Need an operator "mf", line 2: if-less endif "mf", line 2: Need an operator make: fatal errors encountered -- cannot continue The problem is that our make needs a variable on the left in order to parse this correctly as a comparison. Now we end up evaluating this like: .if defined("shells/zsh") ... The attached patches partly fixes it by allowing string comparisons (ie make sure you have the lhs and rhs quoted) Try it out, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="make.diff" Index: cond.c =================================================================== RCS file: /home/ncvs/src/usr.bin/make/cond.c,v retrieving revision 1.25 diff -u -r1.25 cond.c --- cond.c 23 Oct 2002 23:16:42 -0000 1.25 +++ cond.c 15 Mar 2003 19:17:24 -0000 @@ -500,6 +500,7 @@ case '\0': t = EndOfFile; break; + case '"': case '$': { char *lhs; char *rhs; @@ -511,16 +512,21 @@ * Parse the variable spec and skip over it, saving its * value in lhs. */ - t = Err; - lhs = Var_Parse(condExpr, VAR_CMD, doEval,&varSpecLen,&doFree); - if (lhs == var_Error) { - /* - * Even if !doEval, we still report syntax errors, which - * is what getting var_Error back with !doEval means. - */ - return(Err); - } - condExpr += varSpecLen; + if (*condExpr == '$') { + t = Err; + lhs = Var_Parse(condExpr, VAR_CMD, doEval, &varSpecLen, + &doFree); + if (lhs == var_Error) { + /* + * Even if !doEval, we still report syntax + * errors, which is what getting var_Error + * back with !doEval means. + */ + return(Err); + } + condExpr += varSpecLen; + } else + lhs = NULL; if (!isspace((unsigned char) *condExpr) && strchr("!=><", *condExpr) == NULL) { @@ -529,8 +535,10 @@ buf = Buf_Init(0); - for (cp = lhs; *cp; cp++) - Buf_AddByte(buf, (Byte)*cp); + if (lhs != NULL) { + for (cp = lhs; *cp; cp++) + Buf_AddByte(buf, (Byte)*cp); + } if (doFree) free(lhs); @@ -545,6 +553,9 @@ doFree = TRUE; } + + if (lhs == NULL) + return (Err); /* * Skip whitespace to get to the operator --2oS5YaxWCcQjTEyO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 15 14:19: 9 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7842337B404 for ; Sat, 15 Mar 2003 14:19:07 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E465143F85 for ; Sat, 15 Mar 2003 14:19:03 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Sunbay) with ESMTP id h2FMIveK056076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Mar 2003 00:18:57 +0200 (EET) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Submit) id h2FMIuHS056071; Sun, 16 Mar 2003 00:18:56 +0200 (EET) (envelope-from ru) Date: Sun, 16 Mar 2003 00:18:56 +0200 From: Ruslan Ermilov To: Alexander Leidinger Cc: arch@FreeBSD.ORG Subject: Re: Bug in our make or undocumented feature? Message-ID: <20030315221856.GB54789@sunbay.com> References: <20030315165221.27d3d424.Alexander@Leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" Content-Disposition: inline In-Reply-To: <20030315165221.27d3d424.Alexander@Leidinger.net> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 15, 2003 at 04:52:21PM +0100, Alexander Leidinger wrote: > Hi, >=20 > this part of a makefile doesn't work for me: > ---snip--- > WANTED_PORTS=3D shells/zsh lang/perl5 >=20 > mytarget: > .for i in ${WANTED_PORTS} > @echo "${i}" > .if ${i} =3D=3D lang/perl5 =20 > @echo "Yep, perl5." > .endif > .endfor > ---snip--- >=20 This is the nasty implementation of the .for operator. It works by duplicating the lines for each argument, substituting the value, so the above would be evaluate like this, so that i isn't a real variable: mytarget: @echo "shells/zsh" =2Eif shells/zsh =3D=3D lang/perl5 =20 @echo "Yep, perl5." =2Eendif @echo "lang/perl5" =2Eif lang/perl5 =3D=3D lang/perl5 =20 @echo "Yep, perl5." =2Eendif After that, the (recently documented) rule requiring the LHS of the test to be a variable should be applied. P.S. -arch was a bad choice for mailing this. Cheers, --=20 Ruslan Ermilov Sysadmin and 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 --8GpibOaaTibBMecb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+c6bQUkv4P6juNwoRApO1AJoCGeZcVdY0H11Za834BbbSWD7TtwCfdUUs ptSxLDEydClutHzucH5sEL0= =wzER -----END PGP SIGNATURE----- --8GpibOaaTibBMecb-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 15 14:21:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7741037B401 for ; Sat, 15 Mar 2003 14:21:26 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8494F43FD7 for ; Sat, 15 Mar 2003 14:21:22 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Sunbay) with ESMTP id h2FMLGeK056478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Mar 2003 00:21:16 +0200 (EET) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Submit) id h2FMLFbr056473; Sun, 16 Mar 2003 00:21:15 +0200 (EET) (envelope-from ru) Date: Sun, 16 Mar 2003 00:21:15 +0200 From: Ruslan Ermilov To: Marcel Moolenaar Cc: Alexander Leidinger , arch@FreeBSD.ORG Subject: Re: Bug in our make or undocumented feature? Message-ID: <20030315222115.GC54789@sunbay.com> References: <20030315165221.27d3d424.Alexander@Leidinger.net> <20030315192141.GA564@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline In-Reply-To: <20030315192141.GA564@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marcel, I will look into this patch some time later and let you know. Thanks for taking care of this. On Sat, Mar 15, 2003 at 11:21:41AM -0800, Marcel Moolenaar wrote: > On Sat, Mar 15, 2003 at 04:52:21PM +0100, Alexander Leidinger wrote: > > this part of a makefile doesn't work for me: > > ---snip--- > > WANTED_PORTS=3D shells/zsh lang/perl5 > >=20 > > mytarget: > > .for i in ${WANTED_PORTS} > > @echo "${i}" > > .if ${i} =3D=3D lang/perl5 =20 > > @echo "Yep, perl5." > > .endif > > .endfor > > ---snip--- >=20 > Bug. A simpler case: >=20 > .if "shells/zsh" =3D=3D "lang/perl5" > .endif >=20 > dhcp01% make -f mf > "mf", line 1: Malformed conditional ("shells/zsh" =3D=3D "lang/perl5") > "mf", line 1: Need an operator > "mf", line 2: if-less endif > "mf", line 2: Need an operator > make: fatal errors encountered -- cannot continue >=20 > The problem is that our make needs a variable on the left in order > to parse this correctly as a comparison. Now we end up evaluating this > like: > .if defined("shells/zsh") ... >=20 > The attached patches partly fixes it by allowing string comparisons > (ie make sure you have the lhs and rhs quoted) >=20 > Try it out, >=20 > --=20 > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > Index: cond.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/usr.bin/make/cond.c,v > retrieving revision 1.25 > diff -u -r1.25 cond.c > --- cond.c 23 Oct 2002 23:16:42 -0000 1.25 > +++ cond.c 15 Mar 2003 19:17:24 -0000 > @@ -500,6 +500,7 @@ > case '\0': > t =3D EndOfFile; > break; > + case '"': > case '$': { > char *lhs; > char *rhs; > @@ -511,16 +512,21 @@ > * Parse the variable spec and skip over it, saving its > * value in lhs. > */ > - t =3D Err; > - lhs =3D Var_Parse(condExpr, VAR_CMD, doEval,&varSpecLen,&doFree); > - if (lhs =3D=3D var_Error) { > - /* > - * Even if !doEval, we still report syntax errors, which > - * is what getting var_Error back with !doEval means. > - */ > - return(Err); > - } > - condExpr +=3D varSpecLen; > + if (*condExpr =3D=3D '$') { > + t =3D Err; > + lhs =3D Var_Parse(condExpr, VAR_CMD, doEval, &varSpecLen, > + &doFree); > + if (lhs =3D=3D var_Error) { > + /* > + * Even if !doEval, we still report syntax > + * errors, which is what getting var_Error > + * back with !doEval means. > + */ > + return(Err); > + } > + condExpr +=3D varSpecLen; > + } else > + lhs =3D NULL; > =20 > if (!isspace((unsigned char) *condExpr) && > strchr("!=3D><", *condExpr) =3D=3D NULL) { > @@ -529,8 +535,10 @@ > =20 > buf =3D Buf_Init(0); > =20 > - for (cp =3D lhs; *cp; cp++) > - Buf_AddByte(buf, (Byte)*cp); > + if (lhs !=3D NULL) { > + for (cp =3D lhs; *cp; cp++) > + Buf_AddByte(buf, (Byte)*cp); > + } > =20 > if (doFree) > free(lhs); > @@ -545,6 +553,9 @@ > =20 > doFree =3D TRUE; > } > + > + if (lhs =3D=3D NULL) > + return (Err); > =20 > /* > * Skip whitespace to get to the operator --=20 Ruslan Ermilov Sysadmin and 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 --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+c6dbUkv4P6juNwoRAnixAJ9dgK623qgZhAjMHEon0cNtKCnYtgCfQpJN SOVaZ8UTtT8LT++Fs4vh7Fw= =npMK -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 15 22:23:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7689437B401; Sat, 15 Mar 2003 22:23:20 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1DA443FA3; Sat, 15 Mar 2003 22:23:16 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (smmsp@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.7/8.12.7) with ESMTP id h2G6NFFU081965; Sat, 15 Mar 2003 22:23:16 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.7/8.12.7/Submit) id h2G6NFaF081964; Sat, 15 Mar 2003 22:23:15 -0800 (PST) Date: Sat, 15 Mar 2003 22:23:15 -0800 From: "David O'Brien" To: Maxime Henrion Cc: arch@freebsd.org Subject: Re: WARNS=6 changes Message-ID: <20030316062315.GA75492@dragon.nuxi.com> Reply-To: arch@freebsd.org Mail-Followup-To: David O'Brien , Maxime Henrion , arch@FreeBSD.org References: <20030313192045.GG3819@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030313192045.GG3819@elvis.mu.org> User-Agent: Mutt/1.4i 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-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 13, 2003 at 08:20:45PM +0100, Maxime Henrion wrote: > I've been told it would be good to post this change here for discussion, > so here it is. This patch changes the default standard used for > warnings from c89 to c99. Hi Maxime, I am all for this change of making our C standard level C99. Do you think we should do this for lower WARNS than 6? As far as warnings go, -ansi (aka, -std=c89) is responsable for all the 'long long' warnings and that is why it was done at WARNS==6. Since that will go away, maybe we should turn on -std= at a lower WARNS. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message