From owner-freebsd-current Sun Sep 14 00:21:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27555 for current-outgoing; Sun, 14 Sep 1997 00:21:09 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA27550 for ; Sun, 14 Sep 1997 00:21:04 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA01510; Sun, 14 Sep 1997 09:21:02 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA10292; Sun, 14 Sep 1997 09:14:41 +0200 (MET DST) Message-ID: <19970914091441.PA51985@uriah.heep.sax.de> Date: Sun, 14 Sep 1997 09:14:41 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Cc: louie@TransSys.COM (Louis A. Mamakos) Subject: Re: restore seems to be misbehaving References: <199709140342.XAA07327@whizzo.TransSys.COM> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709140342.XAA07327@whizzo.TransSys.COM>; from Louis A. Mamakos on Sep 13, 1997 23:42:18 -0400 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Louis A. Mamakos wrote: > When I run 'restore -t', I get a bunch of 'resync restore' errors. What's > strange is that when I run 'dd if=/dev/rst0 bs=20b | restore -t -f -' > instead, everythings works just fine. > > What really puzzles me is that when I ktrace the first case, I notice > that the read(2) syscall is returning 32K bytes, rather than the 10K bytes > that I expected: Hmm, it Works For Me(tm): j@uriah 238% /sbin/restore rv Verify tape and initialize maps Tape block size is 10 ^^ I've extra prepared a 10 KB blocked tape for this (normally, they are being blocked 32 KB anyway). This is with a Tandberg TDC4222, using a DC9100 cartridge, and a NCR 53c810 controller. My system is from ~ August 9. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 14 03:18:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04088 for current-outgoing; Sun, 14 Sep 1997 03:18:15 -0700 (PDT) Received: from leif.roskildebc.dk (leif.roskildebc.dk [194.182.101.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA03798 for ; Sun, 14 Sep 1997 03:11:15 -0700 (PDT) Received: from localhost (leif@localhost) by leif.roskildebc.dk (8.8.7/8.8.5) with SMTP id MAA07171 for ; Sun, 14 Sep 1997 12:11:58 +0200 (CEST) Date: Sun, 14 Sep 1997 12:11:55 +0200 (CEST) From: Leif Neland To: freebsd-current@freebsd.org Subject: can't compile current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have cvsup'ed with the standard-supfile, but I can't compile a generic kernel (Am I in the right list, I just noticed my Tag is TRELENG-2-2-2-RELEASE?) cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I../../../include -DFAILSAFE -DCOMPAT_43 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -include o pt_global.h ../../kern/sys_generic.c ../../kern/sys_generic.c: In function `poll': ../../kern/sys_generic.c:734: `INFTIM' undeclared (first use this function) ../../kern/sys_generic.c:734: (Each undeclared identifier is reported only once ../../kern/sys_generic.c:734: for each function it appears in.) *** Error code 1 Stop. Am I mistaken in that I should just be able to cvsup with Tag=. and then compile a kernel, or should other things also be updated? make world from /usr/src, perhaps? Or just lib's or what? Leif From owner-freebsd-current Sun Sep 14 04:32:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA06445 for current-outgoing; Sun, 14 Sep 1997 04:32:56 -0700 (PDT) Received: from leif.roskildebc.dk (leif.roskildebc.dk [194.182.101.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA06340 for ; Sun, 14 Sep 1997 04:29:08 -0700 (PDT) Received: from localhost (leif@localhost) by leif.roskildebc.dk (8.8.7/8.8.5) with SMTP id MAA07171 for ; Sun, 14 Sep 1997 12:11:58 +0200 (CEST) Date: Sun, 14 Sep 1997 12:11:55 +0200 (CEST) From: Leif Neland To: freebsd-current@freebsd.org Subject: can't compile current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have cvsup'ed with the standard-supfile, but I can't compile a generic kernel (Am I in the right list, I just noticed my Tag is TRELENG-2-2-2-RELEASE?) cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I../../../include -DFAILSAFE -DCOMPAT_43 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -include o pt_global.h ../../kern/sys_generic.c ../../kern/sys_generic.c: In function `poll': ../../kern/sys_generic.c:734: `INFTIM' undeclared (first use this function) ../../kern/sys_generic.c:734: (Each undeclared identifier is reported only once ../../kern/sys_generic.c:734: for each function it appears in.) *** Error code 1 Stop. Am I mistaken in that I should just be able to cvsup with Tag=. and then compile a kernel, or should other things also be updated? make world from /usr/src, perhaps? Or just lib's or what? Leif From owner-freebsd-current Sun Sep 14 09:27:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16308 for current-outgoing; Sun, 14 Sep 1997 09:27:27 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16302 for ; Sun, 14 Sep 1997 09:27:23 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id LAA00166 for current@freebsd.org; Sun, 14 Sep 1997 11:27:21 -0500 (EST) From: "John S. Dyson" Message-Id: <199709141627.LAA00166@dyson.iquest.net> Subject: FYI: Interesting IDE-Ultra/33 results To: current@freebsd.org Date: Sun, 14 Sep 1997 11:27:20 -0500 (EST) Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is only FYI. I have successfully gotten our IDE support to work with multiple PCI interfaces, and have added Promise support to one of my experimental copies of the system. One very important note: I was having a significant number of I/O errors, but was using a nice, long IDE cable. When I started using the cable included with the Ultra/33 WDAC35100 drive, the errors went away. The results speak for themselves: System: Dual PPro/200, running SMP (1 512K CPU, and 1 256K CPU), with FreeBSD-current as of a week ago + some mods and improvements. The IDE code is pretty much the same as in -current, with code to support multiple busmasters. The filesystem is 2K/16K UFS. There are 4 other IDEs sitting on the MB PIIX3 controller, and 1 IDE (the WDAC5100 drive) on the Promise Ultra/33 controller. This code is not in -current yet, and it will likely be a week or so before it is ready to be committed. Note that the IOZONE being run is modified only to support more complete results. IOZONE: Performance Test of Sequential File I/O -- V2.01 (10/21/94) By Bill Norcott Operating System: FreeBSD 2.x -- using fsync() IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 8947848 26843545 1 1024 8388608 44739242 1 2048 8947848 67108864 1 4096 7895160 134217728 1 8192 8947848 67108864 1 16384 7895160 134217728 1 32768 8388608 134217728 1 65536 8388608 134217728 2 512 9586980 26843545 2 1024 9586980 53687091 2 2048 9586980 67108864 2 4096 9586980 89478485 2 8192 9586980 134217728 2 16384 9586980 268435456 2 32768 9586980 134217728 2 65536 9256395 134217728 4 512 10129639 26843545 4 1024 10129639 44739242 4 2048 10129639 76695844 4 4096 9942053 107374182 4 8192 9942053 107374182 4 16384 9942053 134217728 4 32768 9942053 178956970 4 65536 10129639 134217728 8 512 10324440 24403223 8 1024 10129639 41297762 8 2048 10226112 59652323 8 4096 10129639 89478485 8 8192 10324440 107374182 8 16384 10324440 134217728 8 32768 10129639 153391689 8 65536 10226112 153391689 16 512 10475529 24683720 16 1024 10475529 39768215 16 2048 10177647 56512727 16 4096 10275041 71582788 16 8192 10275041 79536431 16 16384 10275041 85899345 16 32768 10275041 89478485 16 65536 10275041 89478485 32 512 10475529 24683720 32 1024 10399436 39768215 32 2048 10324440 56512727 32 4096 10324440 69273666 32 8192 10275041 78090314 32 16384 10374317 85899345 32 32768 10349318 89478485 32 65536 10374317 91382282 64 512 10475529 24612993 64 1024 10412041 39584952 64 2048 10250518 56886984 64 4096 10361802 68719476 64 8192 10299681 78090314 64 16384 10336864 85048857 64 32768 10238301 88556026 64 65536 10324440 89478485 128 512 10141599 10494727 128 1024 10330648 10494727 128 2048 10268899 10481921 128 4096 10207884 10559231 128 8192 10165603 10552745 128 16384 10159591 10559231 128 32768 10129639 10552745 128 65536 10189720 10598315 Completed series of tests File './Bonnie.141', size: 209715200 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 200 10215 90.2 10137 33.4 2905 10.8 9157 82.8 10308 28.3 137.6 4.3 -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Sun Sep 14 11:03:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA20617 for current-outgoing; Sun, 14 Sep 1997 11:03:36 -0700 (PDT) Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA20610 for ; Sun, 14 Sep 1997 11:03:31 -0700 (PDT) Received: (from ume@localhost) by tasogare.imasy.or.jp (8.8.7+2.7Wbeta7/3.4W4-96030215) with UUCP id CAA18263; Mon, 15 Sep 1997 02:41:52 +0900 (JST) Received: from peace.calm.imasy.or.jp (root@peace.calm.imasy.or.jp [158.214.107.233]) by chaos.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CHAOS1.5) with ESMTP id CAA24531; Mon, 15 Sep 1997 02:40:53 +0900 (JST) Received: from localhost (ume@localhost [127.0.0.1]) by peace.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CALM1.0) with ESMTP id CAA02407; Mon, 15 Sep 1997 02:40:10 +0900 (JST) Message-Id: <199709141740.CAA02407@peace.calm.imasy.or.jp> To: nnd@itfs.nsk.su Cc: current@FreeBSD.ORG Cc: ume@calm.imasy.or.jp Subject: Re: Make and SMP - what can be done ? In-Reply-To: Your message of "17 Aug 1997 06:15:24 GMT" <5t64ts$7ae@news.itfs.nsk.su> References: <5t64ts$7ae@news.itfs.nsk.su> X-Mailer: Mew version 1.90 on XEmacs 20.3 (Kiev) X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.or.jp/~ume/ Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Sep_15_02:40:05_1997_518)--" Content-Transfer-Encoding: 7bit Date: Mon, 15 Sep 1997 02:40:10 +0900 From: Hajimu UMEMOTO X-Dispatcher: imput version 970830 Lines: 60 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ----Next_Part(Mon_Sep_15_02:40:05_1997_518)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >>>>> On 17 Aug 1997 06:15:24 GMT, nnd@itfs.nsk.su said: nnd> Here is a report of my experiments in "parallel" nnd> world making. I applied your patch with recent -current, and tried `make -j8 buildworld'. It failed in sys/i386/boot/netboot. sys/i386/boot/netboot/Makefile is seems to not parallel-safe. Here is a patch. ----Next_Part(Mon_Sep_15_02:40:05_1997_518)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit --- sys/i386/boot/netboot/Makefile.orig Fri May 16 04:04:33 1997 +++ sys/i386/boot/netboot/Makefile Sun Sep 14 20:05:17 1997 @@ -72,16 +72,18 @@ ${.OBJDIR}/makerom ${.TARGET} nb8390.com: makerom start2.ro ${SRCS:N*.h:R:S/$/.o/g} ns8390.o - ${LD} ${LDFLAGS} -o netboot.com ${OBJS} ns8390.o - strip netboot.com - size netboot.com - dd ibs=32 skip=1 if=netboot.com of=${.TARGET} + ${LD} ${LDFLAGS} -o ${.TARGET}.tmp ${OBJS} ns8390.o + strip ${.TARGET}.tmp + size ${.TARGET}.tmp + dd ibs=32 skip=1 if=${.TARGET}.tmp of=${.TARGET} + rm -f ${.TARGET}.tmp nb3c509.com: start2.o ${SRCS:N*.h:R:S/$/.o/g} 3c509.o - ${LD} ${LDFLAGS} -o netboot.com ${OBJS} 3c509.o - strip netboot.com - size netboot.com - dd ibs=32 skip=1 if=netboot.com of=${.TARGET} + ${LD} ${LDFLAGS} -o ${.TARGET}.tmp ${OBJS} 3c509.o + strip ${.TARGET}.tmp + size ${.TARGET}.tmp + dd ibs=32 skip=1 if=${.TARGET}.tmp of=${.TARGET} + rm -f ${.TARGET}.tmp .include ----Next_Part(Mon_Sep_15_02:40:05_1997_518)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@imasy.or.jp ume@iabs.hitachi.co.jp http://www.imasy.or.jp/~ume/ ----Next_Part(Mon_Sep_15_02:40:05_1997_518)---- From owner-freebsd-current Sun Sep 14 13:51:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA29826 for current-outgoing; Sun, 14 Sep 1997 13:51:42 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA29813; Sun, 14 Sep 1997 13:51:30 -0700 (PDT) Received: from hurricane.cs.duke.edu (hurricane.cs.duke.edu [152.3.145.1]) by duke.cs.duke.edu (8.8.5/8.8.5) with ESMTP id QAA01316; Sun, 14 Sep 1997 16:51:26 -0400 (EDT) Received: (from gallatin@localhost) by hurricane.cs.duke.edu (8.8.4/8.7.3) id QAA27413; Sun, 14 Sep 1997 16:51:26 -0400 (EDT) Date: Sun, 14 Sep 1997 16:51:26 -0400 (EDT) Message-Id: <199709142051.QAA27413@hurricane.cs.duke.edu> From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Gary Palmer" Cc: Karl Denninger , current@FreeBSD.ORG Subject: Re: Problems? In-Reply-To: <7386.874113565@orion.webspan.net> References: <19970912094231.48481@Jupiter.Mcs.Net> <7386.874113565@orion.webspan.net> X-Mailer: VM 6.32 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Gary Palmer writes: > Karl Denninger wrote in message ID > <19970912094231.48481@Jupiter.Mcs.Net>: > > Hi foolks, > > > > Anyone got an idea what this means? > > > > de1: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) > > de1: abnormal interrupt: transmit underflow (raising TX threshold to 8|512) > > de1: abnormal interrupt: transmit underflow (raising TX threshold to 1024) > > de1: abnormal interrupt: transmit underflow (switching to store-and-forward > > mode > > According to Matt, this is a problem with the PCI bus on the m/b not > being fast enough to handle the data. He says the Natoma is > notoriously slow (which is why I saw the messages too) Actually, the the Natoma is pretty nice. Under heavy load, its true that it might not get DMA's done as quickly as a Triton. But that's not because the Natoma is slow, rather its because the the Natoma is fair. Under heavy load, a Triton will starve the CPU from memory, whereas a Natama will divide the memory bandwidth up pretty much equally between the PCI bus and the CPU. I imagine this would allow the host to post more transmits & make the card fall further behind.. Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 From owner-freebsd-current Sun Sep 14 17:01:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12401 for current-outgoing; Sun, 14 Sep 1997 17:01:55 -0700 (PDT) Received: from hobbes.saturn-tech.com (ianh@drussell.internode.net [198.161.228.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12391 for ; Sun, 14 Sep 1997 17:01:51 -0700 (PDT) Received: from localhost (ianh@localhost) by hobbes.saturn-tech.com (8.8.4/8.8.2) with SMTP id SAA20557 for ; Sun, 14 Sep 1997 18:01:40 -0600 (MDT) Date: Sun, 14 Sep 1997 18:01:40 -0600 (MDT) From: Ian Hungerford To: freebsd-current@freebsd.org Subject: Thread safe libc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In my recent browsings through the -stable and -current trees, I have found (to my immense dismay) that libc is not really thread safe at all. It appears at first glance that stdio & malloc are pretty much covered, but string & net appear to be untouched. I'm willing to do the work here (or assist if somebody's already at it). So if there is a somebody, speak up. :) Also, I run a -stable system, and I can't see my self using -current until I get another box - what are the chances of any patches to -stable libc sliding in a smooth and orderly way into -current? I'll upgrade if I must (threads are somewhat necessary for my current project), but I'd much rather stick with -stable for now. --- Ian From owner-freebsd-current Sun Sep 14 18:21:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17322 for current-outgoing; Sun, 14 Sep 1997 18:21:01 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17315 for ; Sun, 14 Sep 1997 18:20:57 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id SAA05076; Sun, 14 Sep 1997 18:17:41 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd005074; Mon Sep 15 01:17:32 1997 Message-ID: <341C8C87.2781E494@whistle.com> Date: Sun, 14 Sep 1997 18:16:55 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Ian Hungerford CC: freebsd-current@FreeBSD.ORG, johnbi@rdd.neca.nec.com.au Subject: Re: Thread safe libc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk discuss this with john birrel. he's hiding at the moment at: johnbi@rdd.neca.nec.com.au he did most of what's been done so far.. he's likely to say "be my guest" as far as doing more work on this goes, as he's very busy. julian Ian Hungerford wrote: > > In my recent browsings through the -stable and -current trees, I have > found (to my immense dismay) that libc is not really thread safe at all. > It appears at first glance that stdio & malloc are pretty much covered, > but string & net appear to be untouched. I'm willing to do the work here > (or assist if somebody's already at it). So if there is a somebody, speak > up. :) > > Also, I run a -stable system, and I can't see my self using -current until > I get another box - what are the chances of any patches to -stable libc > sliding in a smooth and orderly way into -current? I'll upgrade if I must > (threads are somewhat necessary for my current project), but I'd much > rather stick with -stable for now. > > --- > Ian From owner-freebsd-current Sun Sep 14 19:56:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA22014 for current-outgoing; Sun, 14 Sep 1997 19:56:15 -0700 (PDT) Received: from external.blom.co.id ([208.147.27.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21927 for ; Sun, 14 Sep 1997 19:56:06 -0700 (PDT) From: tm@blom.co.id Received: from blom.co.id by external.blom.co.id with ESMTP (1.39.111.2/16.2) id AA107801621; Mon, 15 Sep 1997 09:47:01 +0700 Received: from blom.co.id by blom.co.id with SMTP (1.40.112.12/16.2) id AA146801993; Mon, 15 Sep 1997 09:53:13 +0700 X-Openmail-Hops: 1 Date: Mon, 15 Sep 97 09:53:05 +0700 Message-Id: In-Reply-To: <199709141627.LAA00166@dyson.iquest.net> Subject: FYI: Interesting IDE-Ultra/33 results Mime-Version: 1.0 To: toor@dyson.iquest.net Cc: current@FreeBSD.ORG Content-Type: text/plain; charset=US-ASCII; name="FYI:" Content-Disposition: inline; filename="FYI:" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 64 512 10475529 24612993 > 64 1024 10412041 39584952 > 64 2048 10250518 56886984 > 64 4096 10361802 68719476 > 64 8192 10299681 78090314 > 64 16384 10336864 85048857 > 64 32768 10238301 88556026 > 64 65536 10324440 89478485 > 128 512 10141599 10494727 > 128 1024 10330648 10494727 > 128 2048 10268899 10481921 > 128 4096 10207884 10559231 > 128 8192 10165603 10552745 > 128 16384 10159591 10559231 > 128 32768 10129639 10552745 > 128 65536 10189720 10598315 How much memory have you got in this machine? Or rather, what is the size of the filesystem cache? Numbers like 89MB/sec reads only tells me that you are testing FreeBSD filesystem cache performance rather than disk speed. I've never studied what FreeBSD does write (and I don't have any FreeBSD systems available at the moment to study it on). How aggressively are they cached? Terje Marthinussen tm@blom.co.id From owner-freebsd-current Sun Sep 14 20:51:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA24679 for current-outgoing; Sun, 14 Sep 1997 20:51:18 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA24672 for ; Sun, 14 Sep 1997 20:51:12 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id WAA00530; Sun, 14 Sep 1997 22:49:07 -0500 (EST) From: "John S. Dyson" Message-Id: <199709150349.WAA00530@dyson.iquest.net> Subject: Re: FYI: Interesting IDE-Ultra/33 results In-Reply-To: from "tm@blom.co.id" at "Sep 15, 97 09:53:05 am" To: tm@blom.co.id Date: Sun, 14 Sep 1997 22:49:07 -0500 (EST) Cc: toor@dyson.iquest.net, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk tm@blom.co.id said: > > > 64 512 10475529 24612993 > > 64 1024 10412041 39584952 > > 64 2048 10250518 56886984 > > 64 4096 10361802 68719476 > > 64 8192 10299681 78090314 > > 64 16384 10336864 85048857 > > 64 32768 10238301 88556026 > > 64 65536 10324440 89478485 > > 128 512 10141599 10494727 > > 128 1024 10330648 10494727 > > 128 2048 10268899 10481921 > > 128 4096 10207884 10559231 > > 128 8192 10165603 10552745 > > 128 16384 10159591 10559231 > > 128 32768 10129639 10552745 > > 128 65536 10189720 10598315 > > How much memory have you got in this machine? Or rather, > what is the size of the filesystem cache? Numbers like > 89MB/sec reads only tells me that you are testing FreeBSD > filesystem cache performance rather than disk speed. > That is expected, of course, but once the cache is overrun, you can see the actual read performance through the cache. The FreeBSD buffer cache size is almost totally dynamic, and is optimized in such a way that there are few odd performance degrading effects (like system becoming very sluggish during only one or two concurrent write operations.) > > I've never studied what FreeBSD does write (and I don't > have any FreeBSD systems available at the moment to study it > on). How aggressively are they cached? > The FreeBSD buffer cache is write through, with some write gathering also. The system tries to gather 64K chunks to write (and is successful much of the time.) There is an -async mount option that loosens the write scheduling, but not quite to the level of Linux. If you look at the 128MB measurements above, you can see that the system actually starts doing reads somewhere between 64MB and 128MB. The cool thing is that I am *really* getting 10MB/sec on an IDE drive!!! The buffer cache performance issues are pretty well understood by the intended audience. (I am running with a little less than 128MB of RAM, FYI.) Not only does the drive measure fast, but it actually seems very fast in actual use. I am now running with 6 EIDE (and 1 SCSI, 2 SCSI CDROM) drives, all PCI BUS interfaced. I think that I will be adding the new support for all of this stuff into the tree right after the middle of the week. Here is another interesting performance result: Command overhead is 188 usec (time_4096 = 317, time_8192 = 446) transfer speed is 3.17146e+07 bytes/sec ^^^^^^^^^^^ Really Ultra/33 rates... It shows that the drive buffer/application transfer rate is 31.7MBytes/sec. Not too awful bad. It would be very interesting now to get one of those really cool Deskstar-5 drives. Those are supposed to be even better. For those who might try to blow off the transfer rate issue, remember that slow transfers can add to the latency of a I/O transfer request. The faster the transfer rate from the drive, the shorter the channel will be busy, and the quicker the total response time can be. As I commented on earlier though, my (limited) experience has shown that Ultra-33 is very sensitive to drive cable length, and once the driver backed off from Ultra-33 to a more sane PIO mode, the errors went away. With the shorter cable, I have not had any errors since. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Sun Sep 14 21:23:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA26732 for current-outgoing; Sun, 14 Sep 1997 21:23:04 -0700 (PDT) Received: from worldcontrol.com ([209.66.69.194]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA26707 for ; Sun, 14 Sep 1997 21:22:54 -0700 (PDT) Received: (qmail 2024 invoked by uid 100); 15 Sep 1997 04:22:39 -0000 Message-ID: <19970914212234.15050@top.mediacity.com> Date: Sun, 14 Sep 1997 21:22:34 -0700 From: Brian Litzinger To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: SKIP, tapechg, Talisman MPEG card data new location Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My website www.mpress.com has moved to www.worldcontrol.com/~brian some of the things FreeBSD types have found interesting there are: Patches to run SKIP-1.00 under FreeBSD-2.2 and 3.0-current tapechg for AMANDA and Archive Python DAT drive under FreeBSD Brian's FreeBSD TM driver for OmniMedia Talisman MPEG Card This site is not yet completely back up, but the pointers are there. The ftp data should be along shortly. -- brian From owner-freebsd-current Sun Sep 14 21:34:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA27503 for current-outgoing; Sun, 14 Sep 1997 21:34:25 -0700 (PDT) Received: from MindBender.serv.net (mindbender.serv.net [205.153.153.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA27491 for ; Sun, 14 Sep 1997 21:34:14 -0700 (PDT) Received: from localhost.HeadCandy.com (localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.8.6/8.7.3) with SMTP id VAA04430; Sun, 14 Sep 1997 21:30:41 -0700 (PDT) Message-Id: <199709150430.VAA04430@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: "John S. Dyson" cc: tm@blom.co.id, current@freebsd.org Subject: Re: FYI: Interesting IDE-Ultra/33 results In-reply-to: Your message of Sun, 14 Sep 97 22:49:07 -0500. <199709150349.WAA00530@dyson.iquest.net> Date: Sun, 14 Sep 1997 21:30:39 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [...] >For those who might try to blow off the transfer rate issue, >remember that slow transfers can add to the latency of a I/O >transfer request. The faster the transfer rate from the drive, the >shorter the channel will be busy, and the quicker the total >response time can be. As I commented on earlier though, my [...] However, there's more than one way to minimize command overhead. Which is why tagged-command-queuing is so important for SCSI performance, allowing multiple commands to be queued with minimal additional overhead. I'm not minimizing the results above -- they are impressive. However, I don't think that particular command overhead test completely accounts for all the subtleties of this issue. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net Contract software development for Windows NT, Windows 95 and Unix. Windows NT and Unix server development in C++ and C. --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Mon Sep 15 00:03:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA06614 for current-outgoing; Mon, 15 Sep 1997 00:03:46 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA06609 for ; Mon, 15 Sep 1997 00:03:41 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id AAA00660; Mon, 15 Sep 1997 00:01:43 -0700 (PDT) Message-Id: <199709150701.AAA00660@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Michael L. VanLoon -- HeadCandy.com" cc: "John S. Dyson" , tm@blom.co.id, current@FreeBSD.ORG Subject: Re: FYI: Interesting IDE-Ultra/33 results In-reply-to: Your message of "Sun, 14 Sep 1997 21:30:39 PDT." <199709150430.VAA04430@MindBender.serv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 00:01:43 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The other issue is error correction... Amancio >From The Desk Of "Michael L. VanLoon -- HeadCandy.com" : > > [...] > >For those who might try to blow off the transfer rate issue, > >remember that slow transfers can add to the latency of a I/O > >transfer request. The faster the transfer rate from the drive, the > >shorter the channel will be busy, and the quicker the total > >response time can be. As I commented on earlier though, my > [...] > > However, there's more than one way to minimize command overhead. > Which is why tagged-command-queuing is so important for SCSI > performance, allowing multiple commands to be queued with minimal > additional overhead. > > I'm not minimizing the results above -- they are impressive. However, > I don't think that particular command overhead test completely > accounts for all the subtleties of this issue. > > ----------------------------------------------------------------------------- > Michael L. VanLoon michaelv@MindBender.serv.net > Contract software development for Windows NT, Windows 95 and Unix. > Windows NT and Unix server development in C++ and C. > > --< Free your mind and your machine -- NetBSD free un*x >-- > NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, > Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... > NetBSD ports in progress: PICA, others... > ----------------------------------------------------------------------------- From owner-freebsd-current Mon Sep 15 02:33:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA17296 for current-outgoing; Mon, 15 Sep 1997 02:33:56 -0700 (PDT) Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.edu.au [130.102.221.173]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA17266 for ; Mon, 15 Sep 1997 02:33:49 -0700 (PDT) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.7/8.6.12) with ESMTP id TAA01215 for ; Mon, 15 Sep 1997 19:39:29 +1000 (EST) Message-Id: <199709150939.TAA01215@mailbox.uq.edu.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: current@freebsd.org Subject: Re: restore seems to be misbehaving In-reply-to: Your message of "Sun, 14 Sep 1997 09:14:41 +0200." <19970914091441.PA51985@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 19:39:28 +1000 From: Stephen Hocking Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Louis A. Mamakos wrote: > > > When I run 'restore -t', I get a bunch of 'resync restore' errors. What's > > strange is that when I run 'dd if=/dev/rst0 bs=20b | restore -t -f -' > > instead, everythings works just fine. > > > > What really puzzles me is that when I ktrace the first case, I notice > > that the read(2) syscall is returning 32K bytes, rather than the 10K bytes > > that I expected: > I was just bitten by this too - repartitioned my hard drive and lost a few files when restoring my /usr/src fs. I'm running with an NCR 810 also. I'll keep the dd trick in mind. The command used to back things up with a large number of QIC-150 tapes was "dump Obf 120000 /dev/rst0 /usr/src". Most puzzling. Stephen From owner-freebsd-current Mon Sep 15 04:14:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA22100 for current-outgoing; Mon, 15 Sep 1997 04:14:08 -0700 (PDT) Received: from freebsd1.cimlogic.com.au ([203.36.2.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA22090 for ; Mon, 15 Sep 1997 04:13:58 -0700 (PDT) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.8.5/8.8.5) id VAA02183; Mon, 15 Sep 1997 21:14:39 GMT From: John Birrell Message-Id: <199709152114.VAA02183@freebsd1.cimlogic.com.au> Subject: Re: Thread safe libc In-Reply-To: <341C8C87.2781E494@whistle.com> from Julian Elischer at "Sep 14, 97 06:16:55 pm" To: julian@whistle.com (Julian Elischer) Date: Mon, 15 Sep 1997 21:14:38 +0000 (GMT) Cc: ianh@saturn-tech.com, freebsd-current@FreeBSD.ORG, johnbi@rdd.neca.nec.com.au X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Julian Elischer wrote: > discuss this with john birrel. > > he's hiding at the moment at: > johnbi@rdd.neca.nec.com.au > > he did most of what's been done so far.. > he's likely to say > "be my guest" as far as doing more work on this goes, as he's very busy. I've only just put my machine back on line after spending the last 4 months doing battle with a nasty mix of OS9, WinNT and custom radio hardware. As has been said on this list before (often by core members), contributions that take us toward a re-entrant and thread-safe libc/libc_r are most welcome. > > julian > > Ian Hungerford wrote: > > > > In my recent browsings through the -stable and -current trees, I have > > found (to my immense dismay) that libc is not really thread safe at all. > > It appears at first glance that stdio & malloc are pretty much covered, > > but string & net appear to be untouched. I'm willing to do the work here > > (or assist if somebody's already at it). So if there is a somebody, speak > > up. :) The net functions require a lot of work because they need to be re-coded in *_r() style, with the traditional functions that use the static variables becoming wrappers around these. Work on the net part of libc should be offered to Garrett Wollman for review, since he holds the networking crown for FreeBSD. > > > > Also, I run a -stable system, and I can't see my self using -current until > > I get another box - what are the chances of any patches to -stable libc > > sliding in a smooth and orderly way into -current? I'll upgrade if I must > > (threads are somewhat necessary for my current project), but I'd much > > rather stick with -stable for now. If you had enough disk space, you could run *both* -current and -stable. > > > > --- > > Ian > Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 From owner-freebsd-current Mon Sep 15 09:29:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA07383 for current-outgoing; Mon, 15 Sep 1997 09:29:09 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07378 for ; Mon, 15 Sep 1997 09:29:07 -0700 (PDT) Received: from watcher.isl.net (ppp-79.isl.net [199.3.25.128]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id JAA11356 for ; Mon, 15 Sep 1997 09:25:35 -0700 (PDT) Received: (from ortmann@localhost) by watcher.isl.net (8.8.7/8.8.5) id LAA01132 for current@freebsd.com; Mon, 15 Sep 1997 11:23:48 -0500 (CDT) From: Daniel Ortmann Message-Id: <199709151623.LAA01132@watcher.isl.net> Subject: ipfw outputs 0's with default numbering To: current@freebsd.com Date: Mon, 15 Sep 1997 11:23:46 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk SUMMARY: Some of the sequence numbers output by ipfw look a bit goofy. PROBLEM: If I do the following ... ipfw -f flush ipfw add 1000 pass all from 127.0.0.1 to 127.0.0.1 ipfw add pass all from ${ip} to ${net}:${mask} Then I get output as follows ... Flushed all rules. 01000 allow ip from 127.0.0.1 to 127.0.0.1 00000 allow ip from 199.3.25.128 to 199.3.25.0/24 00000 allow ip from 199.3.25.0/24 to 199.3.25.128 00000 allow tcp from any to any established ... EXPECTED: But "ipfw list" shows the following ... 01000 allow ip from 127.0.0.1 to 127.0.0.1 01100 allow ip from 199.3.25.128 to 199.3.25.0/24 01200 allow ip from 199.3.25.0/24 to 199.3.25.128 01300 allow tcp from any to any established ... I expected to see the real sequence numbers instead of just 0's. CODE: Here's the area of ipfw.c that looks suspicious to me ... *** ipfw.c Sat Aug 9 17:09:31 1997 --- ipfw_local.c Mon Sep 15 11:19:38 1997 *************** *** 174,180 **** --- 174,182 ---- if (do_resolv) setservent(1/*stayopen*/); + /* ### */ printf("%05u ", chain->fw_number); + /* ### */ if (do_acct) printf("%10lu %10lu ",chain->fw_pcnt,chain->fw_bcnt); *************** *** 787,796 **** --- 789,800 ---- av++; ac--; + /* ### */ /* Rule number */ if (ac && isdigit(**av)) { rule.fw_number = atoi(*av); av++; ac--; } + /* ### */ /* Action */ if (ac == 0) -- Daniel Ortmann 507.288.7732 (h) ortmann@isl.net 2414 30 av NW, #D 507.253.6795 (w) ortmann@vnet.ibm.com Rochester, MN 55901 "PERL: The Swiss Army Chainsaw" From owner-freebsd-current Mon Sep 15 10:22:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10854 for current-outgoing; Mon, 15 Sep 1997 10:22:52 -0700 (PDT) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA10849 for ; Mon, 15 Sep 1997 10:22:47 -0700 (PDT) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.8.7/8.8.7) with ESMTP id KAA14259 for ; Mon, 15 Sep 1997 10:22:44 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.7/8.8.7) with SMTP id KAA07764 for ; Mon, 15 Sep 1997 10:22:44 -0700 (PDT) Date: Mon, 15 Sep 1997 10:22:44 -0700 (PDT) From: Chris Timmons To: freebsd-current@freebsd.org Subject: Make Death w/sig 12 in libcompat Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At first I thought my old always reliable never overclocked vintage P90 had finally given in. Then I reproduced it at work on another always-reliable system, this time a P6/200. I rebuilt my kernel shortly after midnight pdt today and got this on the P90. The P6 machine's kernel is a bit older. No time here at the moment to dig deeper. -Chris ===> libcompat Bad system call - core dumped *** Error code 140 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. pid 20418 (make), uid 0: exited on signal 12 (core dumped) From owner-freebsd-current Mon Sep 15 15:04:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA28230 for current-outgoing; Mon, 15 Sep 1997 15:04:24 -0700 (PDT) Received: from bookcase.com (root@notes.bookcase.com [207.22.115.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA28139 for ; Mon, 15 Sep 1997 15:03:17 -0700 (PDT) Received: from localhost (chadf@localhost) by bookcase.com (8.8.5/8.7.3) with SMTP id SAA08671 for ; Mon, 15 Sep 1997 18:03:15 -0400 (EDT) Date: Mon, 15 Sep 1997 18:03:14 -0400 (EDT) From: "Chad M. Fraleigh" X-Sender: chadf@notes To: current@FreeBSD.ORG Subject: Re: HEADS UP: *tetris* files removed from cvs repository... In-Reply-To: <199709121216.OAA25518@rvc1.informatik.ba-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Sep 1997, Wolfgang Helbig wrote: > > > PS: I'm partial to xtris. "tetris-like-game" is too much to type. 8-). > > > > Agreed, but I prefer Sir-Tet ;-P > > How about ``ANT'' -- ANT Not Tetris? What? Nobody threw in yatc (Yet Another Tetris Clone). -Chad From owner-freebsd-current Mon Sep 15 16:51:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03904 for current-outgoing; Mon, 15 Sep 1997 16:51:11 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA03875 for ; Mon, 15 Sep 1997 16:51:04 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA01386 for current@FreeBSD.ORG; Tue, 16 Sep 1997 01:51:03 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id BAA09072; Tue, 16 Sep 1997 01:43:22 +0200 (MET DST) Message-ID: <19970916014322.SQ08928@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 01:43:22 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: restore seems to be misbehaving References: <19970914091441.PA51985@uriah.heep.sax.de> <199709150939.TAA01215@mailbox.uq.edu.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709150939.TAA01215@mailbox.uq.edu.au>; from Stephen Hocking on Sep 15, 1997 19:39:28 +1000 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Stephen Hocking wrote: > I was just bitten by this too - repartitioned my hard drive and lost a few > files when restoring my /usr/src fs. I'm running with an NCR 810 also. I'll > keep the dd trick in mind. The command used to back things up with a large > number of QIC-150 tapes was "dump Obf 120000 /dev/rst0 /usr/src". Most > puzzling. Uhh -- but QIC 150 tapes (you are using them up to 120 MB only actually) are in a *totally* different boat than the original posting. They are fixed-length blocking with 512 bytes per tape block. They always *must* work, or something is royally screwed. restore will probably claim the tape block size were 10 KB or even 32, but that doesn't matter: if it issues a read(2) with this blocksize, the kernel should read as many tape blocks as required to satisfy the request. Variable-length blocking tapes are vastly different in their behaviour. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Sep 16 00:52:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA02073 for current-outgoing; Tue, 16 Sep 1997 00:52:08 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA02010 for ; Tue, 16 Sep 1997 00:51:57 -0700 (PDT) Received: (qmail 11009 invoked by uid 1000); 16 Sep 1997 07:51:56 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Tue, 16 Sep 1997 00:51:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Make Release Fails... Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Any reason for the following? The hosting system was make worlded the week before: rpcgen -C -c /usr/obj/usr/src/tmp/usr/include/rpcsvc/ypupdate_prot.x -o ypupdate_prot_xdr.c rm -f .depend mkdep -f .depend -a -DYP -I/usr/obj/usr/src/tmp/usr/include/rpcsvc -I/usr/obj/usr/src/tmp/usr/include -I/usr/obj/usr/src/tmp/usr/include klm_prot_xdr.c mount_xdr.c nfs_prot_xdr.c nlm_prot_xdr.c rex_xdr.c rnusers_xdr.c rquota_xdr.c rstat_xdr.c rwall_xdr.c sm_inter_xdr.c spray_xdr.c yppasswd_xdr.c ypxfrd_xdr.c ypupdate_prot_xdr.c /usr/src/lib/librpcsvc/rnusers.c /usr/src/lib/librpcsvc/rstat.c /usr/src/lib/librpcsvc/rwall.c /usr/src/lib/librpcsvc/yp_passwd.c /usr/src/lib/librpcsvc/yp_update.c /usr/src/lib/librpcsvc/publickey.c /usr/src/lib/librpcsvc/secretkey.c /usr/src/lib/librpcsvc/xcrypt.c klm_prot_xdr.c:6: klm_prot.h: No such file or directory mount_xdr.c:6: mount.h: No such file or directory nfs_prot_xdr.c:6: nfs_prot.h: No such file or directory nlm_prot_xdr.c:6: nlm_prot.h: No such file or directory rex_xdr.c:6: rex.h: No such file or directory rnusers_xdr.c:6: rnusers.h: No such file or directory rquota_xdr.c:6: rquota.h: No such file or directory rstat_xdr.c:6: rstat.h: No such file or directory rwall_xdr.c:6: rwall.h: No such file or directory sm_inter_xdr.c:6: sm_inter.h: No such file or directory spray_xdr.c:6: spray.h: No such file or directory yppasswd_xdr.c:6: yppasswd.h: No such file or directory ypxfrd_xdr.c:6: ypxfrd.h: No such file or directory ypupdate_prot_xdr.c:6: ypupdate_prot.h: No such file or directory mkdep: compile failed *** Error code 1 All these files exist both in /usr/include and in the release build area! They also exist in /usr/obj/usr/src/3.0/src/tmp/usr/include, but not in /usr/obj/usr/src/tmp/usr/include, which does not exist at all. This leads me to the conclusion that while make world knows about non-absolute, non-fixed pathnames and actually supports them, make release still belives that the world outside /usr/src does not exist. Now, I'll haste to say that the 27-Aug-97 build did not suffer from this problem. Thanx! --- Sincerely Yours, (Sent on 16-Sep-97, 00:40:27 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 16 01:23:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09993 for current-outgoing; Tue, 16 Sep 1997 01:23:53 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09956 for ; Tue, 16 Sep 1997 01:23:47 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA10728; Tue, 16 Sep 1997 01:23:07 -0700 (PDT) Message-ID: <19970916012306.17827@hydrogen.nike.efn.org> Date: Tue, 16 Sep 1997 01:23:06 -0700 From: John-Mark Gurney To: Simon Shapiro Cc: freebsd-current@FreeBSD.ORG, Bruce Evans Subject: Re: Make Release Fails... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Simon Shapiro on Tue, Sep 16, 1997 at 12:51:56AM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro scribbled this message on Sep 16: > Any reason for the following? The hosting system was make worlded the week > before: > > rpcgen -C -c /usr/obj/usr/src/tmp/usr/include/rpcsvc/ypupdate_prot.x -o > ypupdate_prot_xdr.c > rm -f .depend > mkdep -f .depend -a -DYP -I/usr/obj/usr/src/tmp/usr/include/rpcsvc > -I/usr/obj/usr/src/tmp/usr/include -I/usr/obj/usr/src/tmp/usr/include > klm_prot_xdr.c mount_xdr.c nfs_prot_xdr.c nlm_prot_xdr.c rex_xdr.c > rnusers_xdr.c rquota_xdr.c rstat_xdr.c rwall_xdr.c sm_inter_xdr.c > spray_xdr.c yppasswd_xdr.c ypxfrd_xdr.c ypupdate_prot_xdr.c > /usr/src/lib/librpcsvc/rnusers.c /usr/src/lib/librpcsvc/rstat.c > /usr/src/lib/librpcsvc/rwall.c /usr/src/lib/librpcsvc/yp_passwd.c > /usr/src/lib/librpcsvc/yp_update.c /usr/src/lib/librpcsvc/publickey.c > /usr/src/lib/librpcsvc/secretkey.c /usr/src/lib/librpcsvc/xcrypt.c > klm_prot_xdr.c:6: klm_prot.h: No such file or directory > mount_xdr.c:6: mount.h: No such file or directory > nfs_prot_xdr.c:6: nfs_prot.h: No such file or directory > nlm_prot_xdr.c:6: nlm_prot.h: No such file or directory > rex_xdr.c:6: rex.h: No such file or directory > rnusers_xdr.c:6: rnusers.h: No such file or directory > rquota_xdr.c:6: rquota.h: No such file or directory > rstat_xdr.c:6: rstat.h: No such file or directory > rwall_xdr.c:6: rwall.h: No such file or directory > sm_inter_xdr.c:6: sm_inter.h: No such file or directory > spray_xdr.c:6: spray.h: No such file or directory > yppasswd_xdr.c:6: yppasswd.h: No such file or directory > ypxfrd_xdr.c:6: ypxfrd.h: No such file or directory > ypupdate_prot_xdr.c:6: ypupdate_prot.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > All these files exist both in /usr/include and in the release build area! > They also exist in /usr/obj/usr/src/3.0/src/tmp/usr/include, > but not in /usr/obj/usr/src/tmp/usr/include, which does not exist at all. > > This leads me to the conclusion that while make world knows about > non-absolute, non-fixed pathnames and actually supports them, make release > still belives that the world outside /usr/src does not exist. > > Now, I'll haste to say that the 27-Aug-97 build did not suffer from this > problem. I believe that this will fix it... right now I'm testing it out myself and it looks like it got past were it needed it to be: I think what happened was that some how rgrimes patches made the cwd be the source path instead of the objdir path.. so it wasn't finding them in the local dir, but because the other header files were fixed to do curdir (for source path) we never noticed... Bruce, any objections to this fix? Index: src/include/rpcsvc/Makefile =================================================================== RCS file: /home/ncvs/src/include/rpcsvc/Makefile,v retrieving revision 1.18 diff -c -r1.18 Makefile *** Makefile 1997/08/21 18:33:13 1.18 --- Makefile 1997/09/16 07:49:24 *************** *** 25,31 **** ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \ ${HFILES:S;^;${.CURDIR}/;} \ ${XFILES:S;^;${.CURDIR}/;} \ ! ${HDRS} \ ${DESTDIR}/usr/include/rpcsvc .x.h: --- 25,31 ---- ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \ ${HFILES:S;^;${.CURDIR}/;} \ ${XFILES:S;^;${.CURDIR}/;} \ ! ${HDRS:S;^;${.OBJDIR}/;} \ ${DESTDIR}/usr/include/rpcsvc .x.h: -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Tue Sep 16 01:26:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA10673 for current-outgoing; Tue, 16 Sep 1997 01:26:19 -0700 (PDT) Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.edu.au [130.102.221.173]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA10658 for ; Tue, 16 Sep 1997 01:26:11 -0700 (PDT) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.7/8.6.12) with ESMTP id SAA01105; Tue, 16 Sep 1997 18:29:41 +1000 (EST) Message-Id: <199709160829.SAA01105@mailbox.uq.edu.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: current@freebsd.org Subject: Re: restore seems to be misbehaving In-reply-to: Your message of "Tue, 16 Sep 1997 01:43:22 +0200." <19970916014322.SQ08928@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 18:29:40 +1000 From: Stephen Hocking Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Stephen Hocking wrote: > > > I was just bitten by this too - repartitioned my hard drive and lost a few > > files when restoring my /usr/src fs. I'm running with an NCR 810 also. I'll > > keep the dd trick in mind. The command used to back things up with a large > > number of QIC-150 tapes was "dump Obf 120000 /dev/rst0 /usr/src". Most > > puzzling. > > Uhh -- but QIC 150 tapes (you are using them up to 120 MB only > actually) are in a *totally* different boat than the original posting. > They are fixed-length blocking with 512 bytes per tape block. They > always *must* work, or something is royally screwed. restore will > probably claim the tape block size were 10 KB or even 32, but that > doesn't matter: if it issues a read(2) with this blocksize, the kernel > should read as many tape blocks as required to satisfy the request. > > Variable-length blocking tapes are vastly different in their > behaviour. > Well, that's quite correct, but the bug exhibited exactly the same symptoms (although I've yet to run ktrace to see whats happening). I think that there's something screwy happening, particularly on tape devices been used repeatedly with little or no pause Stephen From owner-freebsd-current Tue Sep 16 01:47:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12139 for current-outgoing; Tue, 16 Sep 1997 01:47:21 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA12122 for ; Tue, 16 Sep 1997 01:46:55 -0700 (PDT) Received: (qmail 28489 invoked by uid 1000); 16 Sep 1997 08:45:57 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970916012306.17827@hydrogen.nike.efn.org> Date: Tue, 16 Sep 1997 01:45:57 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: John-Mark Gurney Subject: Re: Make Release Fails... Cc: Bruce Evans , freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi John-Mark Gurney; On 16-Sep-97 you wrote: ... > :S;^;${.OBJDIR}/; Thanx! --- Sincerely Yours, (Sent on 16-Sep-97, 01:40:18 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 16 01:56:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12518 for current-outgoing; Tue, 16 Sep 1997 01:56:23 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA12512 for ; Tue, 16 Sep 1997 01:56:20 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA16621; Tue, 16 Sep 1997 01:56:04 -0700 (PDT) Message-ID: <19970916015603.51039@hydrogen.nike.efn.org> Date: Tue, 16 Sep 1997 01:56:03 -0700 From: John-Mark Gurney To: John-Mark Gurney Cc: Simon Shapiro , freebsd-current@FreeBSD.ORG, Bruce Evans Subject: Re: Make Release Fails... References: <19970916012306.17827@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970916012306.17827@hydrogen.nike.efn.org>; from John-Mark Gurney on Tue, Sep 16, 1997 at 01:23:06AM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John-Mark Gurney scribbled this message on Sep 16: > Simon Shapiro scribbled this message on Sep 16: > I believe that this will fix it... right now I'm testing it out myself > and it looks like it got past were it needed it to be: nope... this didn't fix it... looking why the newly build headers aren't being installed while the others are (*.x and some *.h)... ok.. hear we go.. it turns out that src/include/Makefile isn't recursing into the subdirs upon a beforeinstall.. before Bruce explicitately wrapped the recursion to limit it to installhdrs.. but now that we have switched to beforeinstall to install the files it wasn't recursing.. try this patch instead (you don't need the other one, it just takes more time, and makes your build output larger ;) ): how is this one Bruce? I'm testing now, but almost possitive this will fix it... Index: Makefile =================================================================== RCS file: /home/ncvs/src/include/Makefile,v retrieving revision 1.64 diff -c -r1.64 Makefile *** Makefile 1997/09/14 03:32:44 1.64 --- Makefile 1997/09/16 08:49:01 *************** *** 66,72 **** beforeinstall: installhdrs ${SHARED} ! .if make(installhdrs) installhdrs: _SUBDIR .endif installhdrs: --- 66,72 ---- beforeinstall: installhdrs ${SHARED} ! .if make(installhdrs) || make(beforeinstall) installhdrs: _SUBDIR .endif installhdrs: -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Tue Sep 16 02:02:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA12959 for current-outgoing; Tue, 16 Sep 1997 02:02:46 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA12954 for ; Tue, 16 Sep 1997 02:02:40 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA25666; Tue, 16 Sep 1997 18:57:18 +1000 Date: Tue, 16 Sep 1997 18:57:18 +1000 From: Bruce Evans Message-Id: <199709160857.SAA25666@godzilla.zeta.org.au> To: gurney_j@efn.org, Shimon@i-Connect.Net Subject: Re: Make Release Fails... Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I believe that this will fix it... right now I'm testing it out myself >and it looks like it got past were it needed it to be: > >I think what happened was that some how rgrimes patches made the cwd be >the source path instead of the objdir path.. so it wasn't finding them >in the local dir, but because the other header files were fixed to do >curdir (for source path) we never noticed... rgrimes broke the `includes' target. One problem is that `installhdrs' (which traverses subdirectories) got replaced by `beforeinstall' (which doesn't), so include/rpcsvc doesn't get installed. This causes various problems. >Bruce, any objections to this fix? Yes, it has nothing to do with the problem. Bruce From owner-freebsd-current Tue Sep 16 02:23:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA13927 for current-outgoing; Tue, 16 Sep 1997 02:23:25 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA13920 for ; Tue, 16 Sep 1997 02:23:19 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id CAA01920; Tue, 16 Sep 1997 02:23:07 -0700 (PDT) Message-ID: <19970916022305.08798@hydrogen.nike.efn.org> Date: Tue, 16 Sep 1997 02:23:05 -0700 From: John-Mark Gurney To: FreeBSD Current Subject: why is pseudo-device log even listed?? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well.. a friend of mine is striping down the kernel and was puzzled why subr_log.c was still compiled even though the pseudo-device log line was removed... it seems that this isn't needed as sys/conf/files says: kern/subr_log.c standard so it's a standard part of the system, not an option.. the line isn't even needed... so, what is the proper fix... make it truely optional by wrapping the file, or just remove the lines from the kernel config files? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Tue Sep 16 02:37:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA14527 for current-outgoing; Tue, 16 Sep 1997 02:37:34 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA14509 for ; Tue, 16 Sep 1997 02:37:17 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA26879; Tue, 16 Sep 1997 19:34:45 +1000 Date: Tue, 16 Sep 1997 19:34:45 +1000 From: Bruce Evans Message-Id: <199709160934.TAA26879@godzilla.zeta.org.au> To: gurney_j@efn.org, gurney_j@resnet.uoregon.edu Subject: Re: Make Release Fails... Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG, Shimon@i-Connect.Net Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >ok.. hear we go.. it turns out that src/include/Makefile isn't recursing >into the subdirs upon a beforeinstall.. before Bruce explicitately >wrapped the recursion to limit it to installhdrs.. but now that we >have switched to beforeinstall to install the files it wasn't recursing.. No, it never recursed for beforeinstall. I limited recursion of installhdrs to that case where installhdrs is being made. >how is this one Bruce? I'm testing now, but almost possitive this will >fix it... It may work, but it is bogus. It would have the same effect as putting everything related back to where it was before rev.1.136 of src/Makefile, but it takes 10-20 lines of code to subvert the beforeinstall target and add the installhdrs targets. The problem (of clobbered timestamps) fixed by rev.1.136 and reintroduced by rev.1.144 is still there. This can probably be fixed better by setting SHARED=symlinks in the environment for the call the make includes for buildworld. Bruce From owner-freebsd-current Tue Sep 16 02:55:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA15210 for current-outgoing; Tue, 16 Sep 1997 02:55:27 -0700 (PDT) Received: from hobbes.saturn-tech.com (ianh@drussell.internode.net [198.161.228.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA15204 for ; Tue, 16 Sep 1997 02:55:24 -0700 (PDT) Received: from localhost (ianh@localhost) by hobbes.saturn-tech.com (8.8.4/8.8.2) with SMTP id DAA03727 for ; Tue, 16 Sep 1997 03:55:45 -0600 (MDT) Date: Tue, 16 Sep 1997 03:55:45 -0600 (MDT) From: Ian Hungerford To: freebsd-current@freebsd.org Subject: Re: Thread safe libc In-Reply-To: <6903.874286472@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 14 Sep 1997, Jordan K. Hubbard wrote: > Why don't you simply use libc_r ? That's what it's there for. :) I suppose I should have mentioned that I was looking at libc_r - there are no _THREAD_SAFE tests in the net subdir (none that do anything, anyway). :) --- Ian From owner-freebsd-current Tue Sep 16 02:55:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA15230 for current-outgoing; Tue, 16 Sep 1997 02:55:33 -0700 (PDT) Received: from helios.dnttm.ru (dnttm.wave.ras.ru [194.85.104.197]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA15205 for ; Tue, 16 Sep 1997 02:55:24 -0700 (PDT) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id NAA08606 for freebsd-current@freebsd.org; Tue, 16 Sep 1997 13:51:38 +0400 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.7/8.8.5) with ESMTP id NAA00917 for ; Tue, 16 Sep 1997 13:53:44 +0400 (MSD) Message-Id: <199709160953.NAA00917@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: freebsd-current@freebsd.org Subject: FTS broken in -current Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 13:53:43 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 'rm -r' doesn't work if the name of directory has slash at the end. dima@tejblum|/usr/home/dima/misc>mkdir rmtest dima@tejblum|/usr/home/dima/misc>touch rmtest/a dima@tejblum|/usr/home/dima/misc>touch rmtest/b dima@tejblum|/usr/home/dima/misc>rm -r rmtest/ rm: rmtest: Operation not permitted rm: rmtest: Operation not permitted rm: rmtest: Directory not empty find -L is also broken. The problem is in the NAPPEND macro (in fts.c). Reverting it to the previous revision fixed the problem. An attempt to make a comment true also probably fixed the problem: --- fts.c.00 Sun Aug 31 13:47:24 1997 +++ fts.c Tue Sep 16 13:16:48 1997 @@ -745,11 +745,11 @@ /* * If not changing directories, reset the path back to original * state. */ if (ISSET(FTS_NOCHDIR)) { - if (cp - 1 > sp->fts_path) + if (len == cur->fts_pathlen) --cp; *cp = '\0'; } /* Dima From owner-freebsd-current Tue Sep 16 06:25:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA23580 for current-outgoing; Tue, 16 Sep 1997 06:25:59 -0700 (PDT) Received: from freebsd1.cimlogic.com.au ([203.36.2.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA23573 for ; Tue, 16 Sep 1997 06:25:54 -0700 (PDT) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.8.5/8.8.5) id XAA04662; Tue, 16 Sep 1997 23:26:52 GMT From: John Birrell Message-Id: <199709162326.XAA04662@freebsd1.cimlogic.com.au> Subject: Re: Thread safe libc In-Reply-To: from Ian Hungerford at "Sep 16, 97 03:55:45 am" To: ianh@saturn-tech.com (Ian Hungerford) Date: Tue, 16 Sep 1997 23:26:51 +0000 (GMT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ian Hungerford wrote: > > > On Sun, 14 Sep 1997, Jordan K. Hubbard wrote: > > > Why don't you simply use libc_r ? That's what it's there for. :) > > I suppose I should have mentioned that I was looking at libc_r - there > are no _THREAD_SAFE tests in the net subdir (none that do anything, > anyway). :) Ian, Your assessment is correct. The net code in libc needs work to add the re-entrant calls which include the extra args to avoid the use of the static variables. And then work is needed to make the traditional functions with the static variables allocate those variables on a per-thread basis so that they behave in the same way they do in a sindle threaded program. > > --- > Ian > Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 From owner-freebsd-current Tue Sep 16 09:01:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA02078 for current-outgoing; Tue, 16 Sep 1997 09:01:02 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02073 for ; Tue, 16 Sep 1997 09:01:00 -0700 (PDT) Received: from adsdevelop.autodebit.com (adsdevelop.autodebit.com [204.50.245.10]) by freefall.freebsd.org (8.8.6/8.8.5) with SMTP id IAA04158 for ; Tue, 16 Sep 1997 08:57:21 -0700 (PDT) Received: by adsdevelop.autodebit.com with Microsoft Exchange (IMC 4.0.837.3) id <01BCC27E.BDE6AB10@adsdevelop.autodebit.com>; Tue, 16 Sep 1997 08:58:46 -0700 Message-ID: From: David Green-Seed To: "'current@freebsd.com'" Subject: CPU coolers Date: Tue, 16 Sep 1997 08:58:45 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Can't remember who was asking... but the Peltier effect coolers are now available for pentium pro CPUs. http://www.computernerd.com/coolspec.htm Dave. From owner-freebsd-current Tue Sep 16 09:51:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA05125 for current-outgoing; Tue, 16 Sep 1997 09:51:59 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA05112 for ; Tue, 16 Sep 1997 09:51:54 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id JAA06759; Tue, 16 Sep 1997 09:51:33 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199709161651.JAA06759@GndRsh.aac.dev.com> Subject: Re: Make Release Fails... In-Reply-To: <19970916015603.51039@hydrogen.nike.efn.org> from John-Mark Gurney at "Sep 16, 97 01:56:03 am" To: gurney_j@resnet.uoregon.edu Date: Tue, 16 Sep 1997 09:51:33 -0700 (PDT) Cc: gurney_j@resnet.uoregon.edu, Shimon@i-Connect.Net, freebsd-current@FreeBSD.ORG, bde@zeta.org.au X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > John-Mark Gurney scribbled this message on Sep 16: > > Simon Shapiro scribbled this message on Sep 16: > > I believe that this will fix it... right now I'm testing it out myself > > and it looks like it got past were it needed it to be: > > nope... this didn't fix it... looking why the newly build headers aren't > being installed while the others are (*.x and some *.h)... > > ok.. hear we go.. it turns out that src/include/Makefile isn't recursing > into the subdirs upon a beforeinstall.. before Bruce explicitately > wrapped the recursion to limit it to installhdrs.. but now that we > have switched to beforeinstall to install the files it wasn't recursing.. I was the one who changed it to beforeinstall in src/Makefile, Jordan has backed that out. This problem should be (and by my buildworld that failed elsewhere last night) fixed. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-current Tue Sep 16 09:55:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA05365 for current-outgoing; Tue, 16 Sep 1997 09:55:44 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA05349 for ; Tue, 16 Sep 1997 09:55:40 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id JAA06772; Tue, 16 Sep 1997 09:55:23 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199709161655.JAA06772@GndRsh.aac.dev.com> Subject: Re: Make Release Fails... In-Reply-To: <199709160934.TAA26879@godzilla.zeta.org.au> from Bruce Evans at "Sep 16, 97 07:34:45 pm" To: bde@zeta.org.au (Bruce Evans) Date: Tue, 16 Sep 1997 09:55:23 -0700 (PDT) Cc: gurney_j@efn.org, gurney_j@resnet.uoregon.edu, bde@zeta.org.au, freebsd-current@FreeBSD.ORG, Shimon@i-Connect.Net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >ok.. hear we go.. it turns out that src/include/Makefile isn't recursing > >into the subdirs upon a beforeinstall.. before Bruce explicitately > >wrapped the recursion to limit it to installhdrs.. but now that we > >have switched to beforeinstall to install the files it wasn't recursing.. > > No, it never recursed for beforeinstall. I limited recursion of > installhdrs to that case where installhdrs is being made. > > >how is this one Bruce? I'm testing now, but almost possitive this will > >fix it... > > It may work, but it is bogus. It would have the same effect as putting > everything related back to where it was before rev.1.136 of src/Makefile, > but it takes 10-20 lines of code to subvert the beforeinstall target > and add the installhdrs targets. The problem (of clobbered timestamps) > fixed by rev.1.136 and reintroduced by rev.1.144 is still there. This > can probably be fixed better by setting SHARED=symlinks in the environment > for the call the make includes for buildworld. Bruce, are we in aggreement then that the includes: target should be changed to ``cd {.CURDIR}/include; ${BMAKE} install'', my error was using ``beforeinstall''. And the wrapping the buildworld call to the includes stuff so that it is ``SHARED=symlinks; cd {.CURDIR}/include; make install''. I'd make a cdiff for it, but the test box is in my home office, and I'm in my real office :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-current Tue Sep 16 10:18:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06737 for current-outgoing; Tue, 16 Sep 1997 10:18:06 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA06708 for ; Tue, 16 Sep 1997 10:17:15 -0700 (PDT) Received: (qmail 18459 invoked by uid 1000); 16 Sep 1997 17:16:41 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 1 (High) Priority: urgent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709160934.TAA26879@godzilla.zeta.org.au> Date: Tue, 16 Sep 1997 10:16:41 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Bruce Evans Subject: Re: Make Release Fails... Another one... Cc: freebsd-current@FreeBSD.ORG, gurney_j@efn.org, gurney_j@resnet.uoregon.edu Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Bruce Evans; On 16-Sep-97 you wrote: ... > It may work, but it is bogus. It would have the same effect as putting > everything related back to where it was before rev.1.136 of > src/Makefile, > but it takes 10-20 lines of code to subvert the beforeinstall target > and add the installhdrs targets. The problem (of clobbered timestamps) > fixed by rev.1.136 and reintroduced by rev.1.144 is still there. This > can probably be fixed better by setting SHARED=symlinks in the > environment > for the call the make includes for buildworld. So, what is the solution? From my simplistic, passive but anxious observant point of view, I cannot build a release anymore. I could on the 27th of August, but no more. Also, just got : ===> usr.sbin/stallion/stlstats cc -O2 -pipe -c /usr/src/usr.sbin/stallion/stlstats/stlstats.c cc -O2 -pipe -o stlstats stlstats.o -lncurses lib_initscr.o: Undefined symbol `_def_prog_mode' referenced from text segment lib_newterm.o: Undefined symbol `_setupterm' referenced from text segment lib_newterm.o: Undefined symbol `_cur_term' referenced from text segment lib_newterm.o: Undefined symbol `_cur_term' referenced from text segment lib_newterm.o: Undefined symbol `_cur_term' referenced from text segment lib_newterm.o: Undefined symbol `_putp' referenced from text segment lib_newterm.o: Undefined symbol `_cur_term' referenced from text segment lib_newterm.o: Undefined symbol `_cur_term' referenced from text segment lib_newterm.o: Undefined symbol `_cur_term' referenced from text segment lib_newterm.o: Undefined symbol `_def_shell_mode' referenced from text segment lib_newterm.o: Undefined symbol `_def_prog_mode' referenced from text segment lib_tstp.o: Undefined symbol `_def_prog_mode' referenced from text segment lib_tstp.o: Undefined symbol `_def_shell_mode' referenced from text segment lib_options.o: Undefined symbol `_cur_term' referenced from text segment lib_options.o: Undefined symbol `_cur_term' referenced from text segment lib_options.o: Undefined symbol `_cur_term' referenced from text segment lib_options.o: More undefined symbol _cur_term refs follow lib_options.o: Undefined symbol `_putp' referenced from text segment lib_options.o: Undefined symbol `_putp' referenced from text segment lib_endwin.o: Undefined symbol `_tparm' referenced from text segment lib_endwin.o: Undefined symbol `_putp' referenced from text segment lib_endwin.o: Undefined symbol `_putp' referenced from text segment lib_endwin.o: Undefined symbol `_putp' referenced from text segment lib_endwin.o: Undefined symbol `_putp' referenced from text segment lib_endwin.o: Undefined symbol `_reset_shell_mode' referenced from text segment lib_beep.o: Undefined symbol `_putp' referenced from text segment lib_beep.o: Undefined symbol `_putp' referenced from text segment lib_beep.o: More undefined symbol _putp refs follow lib_doupdate.o: Undefined symbol `_reset_prog_mode' referenced from text segment lib_doupdate.o: Undefined symbol `_tparm' referenced from text segment lib_doupdate.o: Undefined symbol `_tputs' referenced from text segment lib_doupdate.o: Undefined symbol `_tparm' referenced from text segment lib_doupdate.o: Undefined symbol `_tparm' referenced from text segment lib_doupdate.o: Undefined symbol `_tparm' referenced from text segment lib_mvcur.o: Undefined symbol `_tparm' referenced from text segment lib_vidattr.o: Undefined symbol `_tparm' referenced from text segment lib_vidattr.o: Undefined symbol `_tputs' referenced from text segment lib_vidattr.o: Undefined symbol `_tparm' referenced from text segment lib_vidattr.o: Undefined symbol `_tputs' referenced from text segment lib_vidattr.o: Undefined symbol `_tputs' referenced from text segment lib_vidattr.o: Undefined symbol `_tputs' referenced from text segment lib_vidattr.o: Undefined symbol `_tparm' referenced from text segment lib_vidattr.o: Undefined symbol `_tputs' referenced from text segment lib_vidattr.o: Undefined symbol `_tputs' referenced from text segment lib_vidattr.o: Undefined symbol `_tputs' referenced from text segment lib_vidattr.o: Undefined symbol `_tputs' referenced from text segment lib_vidattr.o: More undefined symbol _tputs refs follow lib_scroll.o: More undefined symbol _tparm refs follow *** Error code 1 --- Sincerely Yours, (Sent on 16-Sep-97, 08:37:58 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 16 14:12:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20211 for current-outgoing; Tue, 16 Sep 1997 14:12:34 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [209.83.205.48]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20200 for ; Tue, 16 Sep 1997 14:12:30 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.7/8.8.5) with ESMTP id QAA11887; Tue, 16 Sep 1997 16:12:07 -0500 (CDT) Message-Id: <199709162112.QAA11887@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: Daniel Ortmann cc: current@FreeBSD.ORG Subject: Re: Does this idea have merit? In-reply-to: Your message of "Sat, 13 Sep 1997 12:39:47 CDT." <199709131739.MAA00426@watcher.isl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 16:12:06 -0500 From: Wm Brian McCane Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Since 'ps' is often run to find > - all processes belonging to a user, > - or all processes with a particular controlling tty, > - or which instances of a binary are running (i.e. how many instances > of 'spice' circuit simulations are running) > > ... would it make sense to enhance procfs to provide /proc/users/, > /proc/users/binaries/, /proc/ttys/, and /proc/binaries/? Under > these dirs we could perhaps have symlinks to the "real" processes. > > (Part of my motivation is to get the information from a scripting > language such as perl ... without writing extensions.) > > On the other hand, maybe I'm missing something basic. Is there > some other way to find out (without forking a /bin/ps): > - the names and process info of all a user's processes? > - the names and process info of all processes? > - which processes are controlled by a given tty? > - which processes have a given uid? You can get the ownership by doing an `ls -l' in /proc. Or use `readdir' and `stat' in perl to get the owner ID. brian From owner-freebsd-current Tue Sep 16 16:24:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26617 for current-outgoing; Tue, 16 Sep 1997 16:24:27 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26609 for ; Tue, 16 Sep 1997 16:24:20 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id QAA18611; Tue, 16 Sep 1997 16:23:46 -0700 (PDT) Message-ID: <19970916162346.60973@hydrogen.nike.efn.org> Date: Tue, 16 Sep 1997 16:23:46 -0700 From: John-Mark Gurney To: "Rodney W. Grimes" Cc: Shimon@i-Connect.Net, freebsd-current@FreeBSD.ORG, bde@zeta.org.au Subject: Re: Make Release Fails... References: <19970916015603.51039@hydrogen.nike.efn.org> <199709161651.JAA06759@GndRsh.aac.dev.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709161651.JAA06759@GndRsh.aac.dev.com>; from Rodney W. Grimes on Tue, Sep 16, 1997 at 09:51:33AM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Rodney W. Grimes scribbled this message on Sep 16: > I was the one who changed it to beforeinstall in src/Makefile, Jordan > has backed that out. This problem should be (and by my buildworld that > failed elsewhere last night) fixed. yep.. I'm pleased to say that my buildworld after the sync of the makefiles allowed buildworld to complete on my 2.2.1-R system.. :) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Tue Sep 16 18:38:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA03792 for current-outgoing; Tue, 16 Sep 1997 18:38:55 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@korea-173.ppp.hooked.net [206.169.225.173]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03782 for ; Tue, 16 Sep 1997 18:38:42 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id SAA03904 for ; Tue, 16 Sep 1997 18:39:12 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Tue, 16 Sep 1997 18:39:10 -0700 (PDT) From: Alex To: current@FreeBSD.ORG Subject: Re: Does this idea have merit? In-Reply-To: <4836.874182884@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Sep 1997, Poul-Henning Kamp wrote: > In message <199709131739.MAA00426@watcher.isl.net>, Daniel Ortmann writes: > > >On the other hand, maybe I'm missing something basic. Is there > >some other way to find out (without forking a /bin/ps): > > cat /proc/*/status | grep ... ? > > Extending the tree in procfs is not for the faint ... It probably is, but one of the things I liked about Linux was the ability to get loads of information about certian drivers by checking the proc fs. How hard would it be to impliment something like that under procfs or say under something else? - alex From owner-freebsd-current Tue Sep 16 20:42:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA10475 for current-outgoing; Tue, 16 Sep 1997 20:42:38 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA10468 for ; Tue, 16 Sep 1997 20:42:35 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id XAA16026; Tue, 16 Sep 1997 23:42:31 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id XAA01582; Tue, 16 Sep 1997 23:42:31 -0400 (EDT) To: Alex cc: current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: Does this idea have merit? In-reply-to: Your message of "Tue, 16 Sep 1997 18:39:10 PDT." Date: Tue, 16 Sep 1997 23:42:30 -0400 Message-ID: <1565.874467750@orion.webspan.net> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alex wrote in message ID : > It probably is, but one of the things I liked about Linux was the ability > to get loads of information about certian drivers by checking the proc fs. > How hard would it be to impliment something like that under procfs or say > under something else? kernfs is the proper place to put non-process related infromation. I am not at all comfortable with the linux idea of sticking everything possible into /proc ... kernfs is the `cleaner' place to put such info if you want to do file style I/O, or of course there is now sysctl, available through a syscall. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-current Tue Sep 16 22:05:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA15396 for current-outgoing; Tue, 16 Sep 1997 22:05:14 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA15366 for ; Tue, 16 Sep 1997 22:04:58 -0700 (PDT) Received: (qmail 2481 invoked by uid 1000); 17 Sep 1997 05:05:20 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 16 Sep 1997 22:05:20 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Alex Subject: Re: Does this idea have merit? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Alex; On 17-Sep-97 you wrote: > > > On Sat, 13 Sep 1997, Poul-Henning Kamp wrote: > > > In message <199709131739.MAA00426@watcher.isl.net>, Daniel Ortmann > > writes: > > > > >On the other hand, maybe I'm missing something basic. Is there > > >some other way to find out (without forking a /bin/ps): > > > > cat /proc/*/status | grep ... ? > > > > Extending the tree in procfs is not for the faint ... > > It probably is, but one of the things I liked about Linux was the > ability > to get loads of information about certian drivers by checking the proc > fs. > How hard would it be to impliment something like that under procfs or > say > under something else? The problem with Linux's /proc is that it is very much a hack. The interface is simply too complex and bloats the kernel too. I implemented, for the DPT driver, a much simpler mechanism, write a command into /dev/dptX (such as ``echo -n "foo" > /dev/dpt0'') and then read form /dev/dptX (such as ``cat < /dev/dpt0''). Gives you the same result, 1/10 or less of the code. I ended up tearing most of it out; Still took too much code in the kernel. In the newest DPT driver, you can acomplish the same with an IOCTL and a trivial utility. Some of our staff really liked the read/write interface. Some could not stand it. Same could be said about /proc; It may be good for certain things, but less for others. I find the fs semantics in the kernel too complex, butt this is just me being an old fart :-) --- Sincerely Yours, (Sent on 16-Sep-97, 21:56:25 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 16 22:13:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA15896 for current-outgoing; Tue, 16 Sep 1997 22:13:44 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@haiti-93.ppp.hooked.net [206.169.228.93]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA15889 for ; Tue, 16 Sep 1997 22:13:32 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id WAA04427; Tue, 16 Sep 1997 22:13:05 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Tue, 16 Sep 1997 22:13:03 -0700 (PDT) From: Alex To: Simon Shapiro cc: current@FreeBSD.ORG Subject: Re: Does this idea have merit? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997, Simon Shapiro wrote: > > Hi Alex; On 17-Sep-97 you wrote: > > > > > > On Sat, 13 Sep 1997, Poul-Henning Kamp wrote: > > > > > In message <199709131739.MAA00426@watcher.isl.net>, Daniel Ortmann > > > writes: > > > > > > >On the other hand, maybe I'm missing something basic. Is there > > > >some other way to find out (without forking a /bin/ps): > > > > > > cat /proc/*/status | grep ... ? > > > > > > Extending the tree in procfs is not for the faint ... > > > > It probably is, but one of the things I liked about Linux was the > > ability > > to get loads of information about certian drivers by checking the proc > > fs. > > How hard would it be to impliment something like that under procfs or > > say > > under something else? > > The problem with Linux's /proc is that it is very much a hack. The > interface is simply too complex and bloats the kernel too. I did kinda get that feeling by looking at it. I still think something like this would be useful in a filesystem, whether devfs, or someotherfs. > I implemented, for the DPT driver, a much simpler mechanism, write a > command into /dev/dptX (such as ``echo -n "foo" > /dev/dpt0'') and then > read form /dev/dptX (such as ``cat < /dev/dpt0''). Gives you the same > result, 1/10 or less of the code. > I ended up tearing most of it out; Still took too much code in the kernel. > In the newest DPT driver, you can acomplish the same with an IOCTL and a > trivial utility. Some of our staff really liked the read/write interface. > Some could not stand it. Same could be said about /proc; It may be good > for certain things, but less for others. I find the fs semantics in the > kernel too complex, butt this is just me being an old fart :-) That's where I think filesystems in an LKM come in handy. - alex From owner-freebsd-current Tue Sep 16 23:17:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20367 for current-outgoing; Tue, 16 Sep 1997 23:17:43 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA20358 for ; Tue, 16 Sep 1997 23:17:40 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id XAA22858; Tue, 16 Sep 1997 23:17:39 -0700 (PDT) Date: Tue, 16 Sep 1997 23:17:39 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709170617.XAA22858@kithrup.com> To: current@freebsd.org Subject: Re: Does this idea have merit? References: Your message of "Tue, 16 Sep 1997 18:39:10 PDT." Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <1565.874467750.kithrup.freebsd.current@orion.webspan.net> Gary writes: >kernfs is the proper place to put non-process related infromation. I >am not at all comfortable with the linux idea of sticking everything >possible into /proc ... kernfs is the `cleaner' place to put such info >if you want to do file style I/O, or of course there is now sysctl, >available through a syscall. I agree. Most of the stuff in Linux' /proc does not belong there -- and /kern is a great place to put things like that. (Making /kern/kernel a symlink to the booted kernel would be a great idea, for example ;).) If you want to add nodes to kernfs, I'm willing to listen. From owner-freebsd-current Wed Sep 17 13:35:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA08567 for current-outgoing; Wed, 17 Sep 1997 13:35:16 -0700 (PDT) Received: from hobbes.saturn-tech.com (ianh@drussell.internode.net [198.161.228.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA08557 for ; Wed, 17 Sep 1997 13:35:12 -0700 (PDT) Received: from localhost (ianh@localhost) by hobbes.saturn-tech.com (8.8.4/8.8.2) with SMTP id OAA06882; Wed, 17 Sep 1997 14:35:18 -0600 (MDT) Date: Wed, 17 Sep 1997 14:35:18 -0600 (MDT) From: Ian Hungerford To: John Birrell cc: freebsd-current@FreeBSD.ORG Subject: Re: Thread safe libc In-Reply-To: <199709162326.XAA04662@freebsd1.cimlogic.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997, John Birrell wrote: > Ian, > > Your assessment is correct. The net code in libc needs work to add the > re-entrant calls which include the extra args to avoid the use of the > static variables. And then work is needed to make the traditional > functions with the static variables allocate those variables on a > per-thread basis so that they behave in the same way they do in a > sindle threaded program. OK, I'm on the job. :) Some clarification is necessary for the second part, though. Should the replacements for statics be allocated using thread specific data (destroyed when the thread terminates) or malloc() (with the caller assuming responsibility for the free() call)? I prefer the first method - the latter is indescribably ugly, and programs that want to pass pointers to these objects between threads should simply use the new _r functions. Just my $.02, of course - I'll implement it, however ugly it ends up needing to be. :) > Regards, > > -- > John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org > CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 --- Ian From owner-freebsd-current Wed Sep 17 16:32:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18446 for current-outgoing; Wed, 17 Sep 1997 16:32:17 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18440 for ; Wed, 17 Sep 1997 16:32:07 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id IAA00695; Thu, 18 Sep 1997 08:59:37 +0930 (CST) Message-Id: <199709172329.IAA00695@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: current@freebsd.org Subject: Re: NFS client locking In-reply-to: Your message of "Fri, 12 Sep 1997 22:09:35 GMT." <199709122209.PAA29030@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Sep 1997 08:59:34 +0930 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I would like to discuss NFS client locking implementation details. [... much theory elided ...] > Comments? For whatever it's worth, it looks sound to me. Do we have any commentary from Doug on this? I think that we'd greatly respect a second opinion from someone with experience in this field. mike From owner-freebsd-current Wed Sep 17 17:24:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21625 for current-outgoing; Wed, 17 Sep 1997 17:24:01 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21599 for ; Wed, 17 Sep 1997 17:23:54 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA19855; Wed, 17 Sep 1997 17:23:33 -0700 (MST) From: Terry Lambert Message-Id: <199709180023.RAA19855@usr04.primenet.com> Subject: Re: Thread safe libc To: ianh@saturn-tech.com (Ian Hungerford) Date: Thu, 18 Sep 1997 00:23:32 +0000 (GMT) Cc: jb@cimlogic.com.au, freebsd-current@FreeBSD.ORG In-Reply-To: from "Ian Hungerford" at Sep 17, 97 02:35:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Some clarification is necessary for the second part, though. Should the > replacements for statics be allocated using thread specific data > (destroyed when the thread terminates) or malloc() (with the caller > assuming responsibility for the free() call)? I prefer the first method - > the latter is indescribably ugly, and programs that want to pass pointers > to these objects between threads should simply use the new _r functions. How do you propose to implement agregate allocation (ie: library open time) of thread local storage? PS: you don't have per thread library attach and detach events. Even if you could clean the crap up in thread_exit(). > Just my $.02, of course - I'll implement it, however ugly it ends up > needing to be. :) Personally, I'd implement it like: In the library: /* * The real getpwent; excuse the crappy name for the function as it * probably should have been since day one. * * Note: you may call this code from either threaded or unthreaded * applications. */ int getpwent_r( struct passwd *usrbuf) { ... { return 1; /* success*/ } return 0; /* failure*/ } In pwd.h: /* * The legacy getpwent; excuse the subsumption of the good name by a * crappy function. The buffer will be instanced each time the function * is inlined. * * Note: do not call this code from a threaded application. */ static __inline struct passwd * getpwent(void) { static struct passwd usrbuf; if( getpwent_r( &userbuf)) return &userbuf; else return NULL; } In this case, getpwent_r() is thread safe, but getpwent() is not (hint: two threads running the same code will get the same static buffer instance). Alternately: 1) In the thread initialization, create keys for all "static" buffers. 2) Initialize the key so you don't have to take the memory hit at the start of life. 3) Allocate the buffer from the heap and use pthread_setspecific() to point to it. 4) Fill in the allocate area with the function result. 5) Return the pointer to the allocated area 6) Realize that a getpwent() call by thread 2 can't have its result passed to thread 1 if it goes out of scope. Example: A) I have a set of work-to-do threads B) I have a client request to start a session C) The client request is handled by starting a session initialization thread. D) The thread allocates from a shared memory segment instead of thread local storage in order to create a client context shared between the worker threads. E) Postinitialization is done by the thread that scheduled the work. F) Oop! The buffer area was destroyed before the postinitialization could copy it because the buffer was allocated in TLS instead of acting like getpwent() is transparent. G) Guess you should have used getpwent_r() and provided your own buffer... H) Hey, I bet that explains all these *_r() functions... So doing it using TLS will cause it to fail erratically in implementation specific ways that are not obvious to the programmer. Alternately, you could define a non-transparent interface, where keys are ference counted (they aren't in pthreads, you would have to write this). Then you coul increment the reference count as part of passing the data between threads, so that when it went out of scope in one thread, it would not be destroyed. you would need to create a key in the target thread to contain the data pointer so the thread_exit() cleanup would still free it. You could call this process "marshalling", and we could all buy: Inside COM Microsoft's Component Object Model Dale Rogerson Microsoft Press ISBN: 1-57231-349-8 And read about how it works, since they use the same TLS model to deal with static buffers and C++ pure-virtual-derived-object instances. Needless to say, I think Thread Local Storage is evil. The only *possible* justifcation is automatic stack growth, and you can do that without TLS as well, if you are clever about it. I would definitely prefer that the user supply the buffers to an *_r() routine (I think these routines should replace the standard ones, since the standard ones are obviously defective, so they don't have the dumb "_r" appendage), and the scoping of data in threads be forthright and obvious to anyone reading the code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 17 17:25:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21762 for current-outgoing; Wed, 17 Sep 1997 17:25:12 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21757 for ; Wed, 17 Sep 1997 17:25:10 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA20055; Wed, 17 Sep 1997 17:25:01 -0700 (MST) From: Terry Lambert Message-Id: <199709180025.RAA20055@usr04.primenet.com> Subject: Re: NFS client locking To: mike@smith.net.au (Mike Smith) Date: Thu, 18 Sep 1997 00:25:00 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: <199709172329.IAA00695@word.smith.net.au> from "Mike Smith" at Sep 18, 97 08:59:34 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I would like to discuss NFS client locking implementation details. > > [... much theory elided ...] > > > Comments? > > For whatever it's worth, it looks sound to me. Do we have any > commentary from Doug on this? I think that we'd greatly respect a > second opinion from someone with experience in this field. I haven't heard from Doug in a while; no one has, AFAIK. But I'd like his comments on it as well as anyone else who wants to throw in their two cents worth. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 17 17:44:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA23110 for current-outgoing; Wed, 17 Sep 1997 17:44:51 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23103 for ; Wed, 17 Sep 1997 17:44:48 -0700 (PDT) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.8.7/8.8.5) id RAA00287 for freebsd-current@freebsd.org; Wed, 17 Sep 1997 17:47:15 -0700 (PDT) From: Steve Kargl Message-Id: <199709180047.RAA00287@troutmask.apl.washington.edu> Subject: netatalk appears broken To: freebsd-current@freebsd.org Date: Wed, 17 Sep 1997 17:47:15 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ladies and Gents, cvsup on 17 Sep 97, make world, followed by kernel build, and rebuilt the netatalk-1.4b2 yields: Sep 17 17:29:05 troutmask afpd[206]: main: atp_open: Protocol not supported During the boot. A kernel of of the following vintage FreeBSD 3.0-CURRENT #0: Tue Aug 12 10:04:55 PDT 1997 works fine. -- Steve finger kargl@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~kargl/sgk.html From owner-freebsd-current Wed Sep 17 17:45:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA23159 for current-outgoing; Wed, 17 Sep 1997 17:45:48 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23154 for ; Wed, 17 Sep 1997 17:45:45 -0700 (PDT) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.8.7/8.8.5) id RAA00306 for freebsd-current@freebsd.org; Wed, 17 Sep 1997 17:48:13 -0700 (PDT) From: Steve Kargl Message-Id: <199709180048.RAA00306@troutmask.apl.washington.edu> Subject: what is boot.help? To: freebsd-current@freebsd.org Date: Wed, 17 Sep 1997 17:48:13 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Subject says it all. -- Steve finger kargl@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~kargl/sgk.html From owner-freebsd-current Wed Sep 17 19:08:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27119 for current-outgoing; Wed, 17 Sep 1997 19:08:43 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27112 for ; Wed, 17 Sep 1997 19:08:40 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id TAA06514; Wed, 17 Sep 1997 19:08:40 -0700 (PDT) Date: Wed, 17 Sep 1997 19:08:40 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709180208.TAA06514@kithrup.com> To: current@freebsd.org Subject: Re: NFS client locking Newsgroups: kithrup.freebsd.current In-Reply-To: <199709122209.PAA29030.kithrup.freebsd.current@usr08.primenet.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199709122209.PAA29030.kithrup.freebsd.current@usr08.primenet.com> you write: >In order to implement this, the common locking code must move out >of the per FS VOP_ADVLOCK() and into the system calls/VFS framework >layer. For what it's worth, I've seen Terry's code to do this and (unless he's gone and changed it again, sly get that he is :)), it was reasonable and not terribly complicated. Mostly grunt work, I think. From owner-freebsd-current Wed Sep 17 19:20:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27690 for current-outgoing; Wed, 17 Sep 1997 19:20:38 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27685 for ; Wed, 17 Sep 1997 19:20:35 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA09075; Wed, 17 Sep 1997 19:12:26 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd009066; Thu Sep 18 02:12:19 1997 Message-ID: <34208DD9.2781E494@whistle.com> Date: Wed, 17 Sep 1997 19:11:37 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Steve Kargl CC: freebsd-current@FreeBSD.ORG Subject: Re: netatalk appears broken References: <199709180047.RAA00287@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Kargl wrote: you are correct. It seems busted. I'll try figure it out. I hadn't tried running atalk on my 3.0 machine for a couple of weeks. I get the same errors that you do. however the atalkd is running and the routes etc seem to be added correctly. > > Ladies and Gents, > > cvsup on 17 Sep 97, make world, followed by kernel build, and > rebuilt the netatalk-1.4b2 yields: > > Sep 17 17:29:05 troutmask afpd[206]: main: atp_open: Protocol not supported > > During the boot. A kernel of of the following vintage > FreeBSD 3.0-CURRENT #0: Tue Aug 12 10:04:55 PDT 1997 > works fine. > > -- > Steve > > finger kargl@troutmask.apl.washington.edu > http://troutmask.apl.washington.edu/~kargl/sgk.html From owner-freebsd-current Wed Sep 17 19:48:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29408 for current-outgoing; Wed, 17 Sep 1997 19:48:37 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29401 for ; Wed, 17 Sep 1997 19:48:25 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id MAA01761; Thu, 18 Sep 1997 12:15:38 +0930 (CST) Message-Id: <199709180245.MAA01761@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Steve Kargl cc: freebsd-current@freebsd.org Subject: Re: what is boot.help? In-reply-to: Your message of "Wed, 17 Sep 1997 17:48:13 MST." <199709180048.RAA00306@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Sep 1997 12:15:38 +0930 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Subject says it all. word:~>cat /boot.help Usage: bios_drive:interface(unit,partition)kernel_name options bios_drive 0, 1, ... interface fd, wd or sd unit 0, 1, ... partition a, c, ... kernel_name name of kernel, or ? for list of files in root directory options -a (ask name) -C (cdrom) -c (userconfig) -D (dual consoles) -d (debug early) -g (gdb) -h (serial console) -P (probe kbd) -r (default root) -s (single user) -v (verbose) Examples: 1:sd(0,a)mykernel boot `mykernel' on the first SCSI drive when one IDE drive is present 1:wd(2,a) boot from the second (secondary master) IDE drive 1:sd(0,a)? list the files in the root directory on the specified drive/unit/partition, and set the default bios_drive, interface, unit and partition -cv boot with the defaults, then run UserConfig to modify hardware parameters (c), and print verbose messages (v) You will find it in /sys/i386/boot/biosboot/boot.help; it probably belongs in /usr/mdec as well. You can replace it with your own text if you prefer; this being why it is in a file (aside from the space saving). mike From owner-freebsd-current Wed Sep 17 23:05:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA09855 for current-outgoing; Wed, 17 Sep 1997 23:05:07 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA09823 for ; Wed, 17 Sep 1997 23:04:52 -0700 (PDT) Received: (qmail 10655 invoked by uid 1000); 18 Sep 1997 06:04:49 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Wed, 17 Sep 1997 23:04:49 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Make Release Build Errors... More... Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk cd /usr/doc && make all distribute DISTDIR=/R/stage/trees ===> FAQ sgmlfmt -f html /usr/doc/FAQ/FAQ.sgml sgmlfmt: not found *** Error code 1 (continuing) sgmlfmt -f latin1 /usr/doc/FAQ/FAQ.sgml sgmlfmt: not found etc., etc., etc... cc -O2 -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/obj/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys -DUC_PRIVATE -DKERN_NO_SYMBOLS -DSAVE_USERCONFIG -c /usr/src/release/sysinstall/cdrom.c /usr/src/release/sysinstall/cdrom.c: In function `mediaInitCDROM': /usr/src/release/sysinstall/cdrom.c:78: warning: passing arg 1 of `mount' makes pointer from integer without a cast gzip -c /usr/src/release/sysinstall/sysinstall.8 > sysinstall.8.gz `all' not remade because of errors. install -c -s -o bin -g bin -m 555 sysinstall /stand install: sysinstall: No such file or directory *** Error code 71 (continuing) install -c -o bin -g bin -m 444 sysinstall.8.gz /usr/share/man/man8 `install' not remade because of errors. rm -rf /R/stage/crunch crunchide -k __crunched_slattach_stub slattach.lo echo "int _crunched_mount_nfs_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >mount_nfs_stub.c cc -O2 -pipe -DCRUNCHED_BINARY -c mount_nfs_stub.c ld -dc -r -o mount_nfs.lo mount_nfs_stub.o /usr/obj//usr/src/sbin/mount_nfs/mount_nfs.o /usr/obj//usr/src/sbin/mount_nfs/getmntopts.o crunchide -k __crunched_mount_nfs_stub mount_nfs.lo `all' not remade because of errors. mv: rename boot_crunch/boot_crunch to /R/stage/crunch/boot: No such file or directory *** Error code 1 (continuing) ... rmdir: des/usr/share/man/man1: Directory not empty rmdir: des/usr/share/man/man3: Directory not empty rmdir: des/usr/share/man/man8: Directory not empty rmdir: des/usr/share/man: Directory not empty rmdir: des/usr/share: Directory not empty rmdir: des/usr: Directory not empty rmdir: des: Directory not empty *** Error code 1 (ignored) mkdir -p /R/stage/dists/bin ( cd /R/stage/trees/bin && tn=`echo bin | tr '[A-Z]' '[a-z]' | cut -c1-8` && echo rolling bin/$tn tarball && tar --exclude CVS --exclude obj --exclude BOOTMFS -cf - . | gzip --no-name -9 -c | split -b 240640 - /R/stage/dists/bin/$tn. && sh /usr/src/release/info.sh /R/stage/dists/bin/$tn > /R/stage/dists/bin/$tn.inf && if [ -f /usr/src/release/scripts/${TD}-install.sh ]; then cp -p /usr/src/release/scripts/${TD}-install.sh /R/stage/dists/bin/install.sh; fi && if [ "/R/stage/trees/bin" != "/usr/src" ]; then mtree -c -i -p /R/stage/trees/bin/. -k gname,md5digest,mode,nlink,uname,size,link,type > /R/stage/dists/bin/$tn.mtree ; else true; fi; (cd /R/stage/dists/bin; rm -f CHECKSUM.MD5; md5 * > CHECKSUM.MD5) ) rolling bin/bin tarball tar: dev/wd0s3: minor number too large; not dumped tar: dev/rwd0s3: minor number too large; not dumped tar: dev/wd0s4: minor number too large; not dumped tar: dev/rwd0s4: minor number too large; not dumped ... cd /R/stage/mfsfd && mkdir -p etc dev mnt stand/help if false ; then gzip -9 < /R/stage/crunch/boot > /R/stage/mfsfd/stand/boot_crunch ; else ln -f /R/stage/crunch/boot /R/stage/mfsfd/stand/boot_crunch ; fi ln: /R/stage/crunch/boot: No such file or directory *** Error code 1 (continuing) test -f /usr/src/release/install.cfg && cp /usr/src/release/install.cfg /R/stage/mfsfd Making the regular boot floppy. *** Error code 1 (ignored) tar --exclude CVS -cf - -C /usr/src/release/sysinstall help | tar xvf - -C /R/stage/mfsfd/stand ln: /R/stage/crunch/fixit: No such file or directory *** Error code 1 (continuing) ( cd /R/stage/fixitfd/dev && sed -e '/^PATH/s/^/#/' /R/stage/trees/bin/dev/MAKE And then /R only has a partially populated stage, but nothing ele. --- Sincerely Yours, (Sent on 17-Sep-97, 22:31:24 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Wed Sep 17 23:51:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12221 for current-outgoing; Wed, 17 Sep 1997 23:51:06 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12197 for ; Wed, 17 Sep 1997 23:51:01 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA26488; Wed, 17 Sep 1997 23:50:52 -0700 (PDT) Message-ID: <19970917235052.49236@hydrogen.nike.efn.org> Date: Wed, 17 Sep 1997 23:50:52 -0700 From: John-Mark Gurney To: Simon Shapiro Cc: freebsd-current@FreeBSD.ORG Subject: Re: Make Release Build Errors... More... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Simon Shapiro on Wed, Sep 17, 1997 at 11:04:49PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro scribbled this message on Sep 17: > cd /usr/doc && make all distribute DISTDIR=/R/stage/trees > ===> FAQ > sgmlfmt -f html /usr/doc/FAQ/FAQ.sgml > sgmlfmt: not found > *** Error code 1 (continuing) > sgmlfmt -f latin1 /usr/doc/FAQ/FAQ.sgml > sgmlfmt: not found did you install this from the ports tree? I believe that textproc/sgmlformat will fix that... the rest I'm not sure about... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Wed Sep 17 23:56:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12751 for current-outgoing; Wed, 17 Sep 1997 23:56:03 -0700 (PDT) Received: from rio.workcover.qld.gov.au (server.workcover.qld.gov.au [203.101.253.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12712 for ; Wed, 17 Sep 1997 23:55:57 -0700 (PDT) Received: from manila.workcover.qld.gov.au (manila-dmz [131.242.84.201]) by rio.workcover.qld.gov.au (8.8.5/8.8.6) with SMTP id QAA08820 for ; Thu, 18 Sep 1997 16:57:54 +1000 (EST) Received: from localhost by manila.workcover.qld.gov.au (8.6.8.1/DEVETIR-0.1) id GAA13989 for ; Thu, 18 Sep 1997 06:57:28 GMT Message-Id: <199709180657.GAA13989@manila.workcover.qld.gov.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: current@freebsd.org Subject: Linux WABI on FreeBSD-current? X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Sep 1997 16:57:27 +1000 From: Stephen Hocking Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anybody tried to run Linux WABI under FreeBSD-current? I'm assuming a kernel with all the USER GDT stuff compiled in of course. Stephen -- The views expressed above are not those of WorkCover Queensland, Australia. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California From owner-freebsd-current Thu Sep 18 00:20:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14453 for current-outgoing; Thu, 18 Sep 1997 00:20:32 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA14448 for ; Thu, 18 Sep 1997 00:20:28 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA05178; Thu, 18 Sep 1997 09:20:27 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA06255; Thu, 18 Sep 1997 09:14:14 +0200 (MET DST) Message-ID: <19970918091414.QH40970@uriah.heep.sax.de> Date: Thu, 18 Sep 1997 09:14:14 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Cc: sgk@troutmask.apl.washington.edu (Steve Kargl) Subject: Re: what is boot.help? References: <199709180048.RAA00306@troutmask.apl.washington.edu> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709180048.RAA00306@troutmask.apl.washington.edu>; from Steve Kargl on Sep 17, 1997 17:48:13 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Steve Kargl wrote: > Subject says it all. /sys/i386/boot/biosboot/boot.help The file that's displayed before the boot prompt, so the message could be made more verbose since it doesn't need to be stored inside the 7.5 KB of the bootstrap. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Sep 18 01:52:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA19756 for current-outgoing; Thu, 18 Sep 1997 01:52:21 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA19751 for ; Thu, 18 Sep 1997 01:52:16 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA27752; Thu, 18 Sep 1997 01:52:13 -0700 (PDT) Message-ID: <19970918015212.63324@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 01:52:13 -0700 From: John-Mark Gurney To: FreeBSD Current Subject: sio aware pnp driver and resource conflict detection Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well... I was wondering if people would like for me to import my changes to make sio a PnP aware driver... I would provide a PnP flag that would prevent the card from being probed... but if I do import this code, I will need to add a temporary fix to the resource system to search attached pnp devices for resource conflicts... (prevent the modem from being attached twice which does happen and causes wierd results)... currently the pnp system doesn't prevent you from doing stupid things like configuring two pnp cards to colid with each other... and I could possibly fix this before the snap comes out... comments? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Sep 18 03:16:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA24081 for current-outgoing; Thu, 18 Sep 1997 03:16:30 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA24068 for ; Thu, 18 Sep 1997 03:16:24 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA09516; Thu, 18 Sep 1997 10:57:57 +0200 From: Luigi Rizzo Message-Id: <199709180857.KAA09516@labinfo.iet.unipi.it> Subject: Re: sio aware pnp driver and resource conflict detection To: gurney_j@resnet.uoregon.edu Date: Thu, 18 Sep 1997 10:57:57 +0200 (MET DST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <19970918015212.63324@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 18, 97 01:51:54 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > well... I was wondering if people would like for me to import my changes > to make sio a PnP aware driver... I would provide a PnP flag that > would prevent the card from being probed... perhaps you can do it the same ways as I did for the sound code, while waiting for the extent stuff to be ready for prime time... > currently the pnp system doesn't prevent you from doing stupid things > like configuring two pnp cards to colid with each other... and I could > possibly fix this before the snap comes out... not sure this is worth the effort, in a manual config should not get in the way of the user's will, however stupid it can be... CHeers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-current Thu Sep 18 03:30:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA25659 for current-outgoing; Thu, 18 Sep 1997 03:30:24 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA25641 for ; Thu, 18 Sep 1997 03:30:19 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id DAA28551; Thu, 18 Sep 1997 03:29:36 -0700 (PDT) Message-ID: <19970918032936.05832@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 03:29:36 -0700 From: John-Mark Gurney To: Luigi Rizzo Cc: freebsd-current@FreeBSD.ORG Subject: Re: sio aware pnp driver and resource conflict detection References: <19970918015212.63324@hydrogen.nike.efn.org> <199709180857.KAA09516@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709180857.KAA09516@labinfo.iet.unipi.it>; from Luigi Rizzo on Thu, Sep 18, 1997 at 10:57:57AM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo scribbled this message on Sep 18: > > well... I was wondering if people would like for me to import my changes > > to make sio a PnP aware driver... I would provide a PnP flag that > > would prevent the card from being probed... > > perhaps you can do it the same ways as I did for the sound code, while > waiting for the extent stuff to be ready for prime time... well... a couple reasons... is because then once the extent stuff is ready for prime time, we will then have to go along and rip all that code out from PnP aware drivers... the only overhead is forcing you to malloc a struct with isa_device as a part.. but then we reclaim this space by reducing the size of struct pnp_device, which each driver has their own copy of it... so in the long run, memory use is actually lower (assuming more pnp drivers than pnp cards)... > > currently the pnp system doesn't prevent you from doing stupid things > > like configuring two pnp cards to colid with each other... and I could > > possibly fix this before the snap comes out... > > not sure this is worth the effort, in a manual config should not get in > the way of the user's will, however stupid it can be... good point.. but the problem is that right now pnp doesn't check for resource conflicts.. so if you config two pnp devices, and then they both probe/attach, they use the same resources.. while that would fail when one is an isa device... what we could do in the meantime is do something like the isa does now and use the reconfig if the attach routing changes the isa_device struct... the quickest fix (I am working on the best fix) would be to teach the attach routine to use the reconfig flag in isa_device, and teach pnp_configure about reconfig so that it will check resources (using haveseen_isadev) before attaching, then if attach returns with reconfig, just do what the isa code does currently in config_isadev_c... any takes for this? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Sep 18 04:00:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA28459 for current-outgoing; Thu, 18 Sep 1997 04:00:45 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA28453 for ; Thu, 18 Sep 1997 04:00:38 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id UAA00302; Thu, 18 Sep 1997 20:23:08 +0930 (CST) Message-Id: <199709181053.UAA00302@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Stephen Hocking cc: current@freebsd.org Subject: Re: Linux WABI on FreeBSD-current? In-reply-to: Your message of "Thu, 18 Sep 1997 16:57:27 +1000." <199709180657.GAA13989@manila.workcover.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Sep 1997 20:23:06 +0930 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Has anybody tried to run Linux WABI under FreeBSD-current? I'm > assuming a kernel with all the USER GDT stuff compiled in of course. Yes. Oh, you mean "did it work?", no. There is one basic problem; the i386_modify_ldt() Linux system call isn't emulated due to the current implementation of its counterparts under FreeBSD. (The code in question uses copyin/copyout to access call arguments.) If you were to take a stab at this (I can provide details on the Linux call interface if you don't have them already), I *think* that much of the rest of it would be quite happy. I know you have some x86 experience, and at least a little time on your hands, so this would be greatly appreciated! mike From owner-freebsd-current Thu Sep 18 05:04:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA01712 for current-outgoing; Thu, 18 Sep 1997 05:04:33 -0700 (PDT) Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA01696 for ; Thu, 18 Sep 1997 05:04:27 -0700 (PDT) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by nasu.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id VAA05091; Thu, 18 Sep 1997 21:02:35 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (KNeCaoGV/scoblmOo8VshE5Up7rxFflx@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id VAA27844; Thu, 18 Sep 1997 21:02:35 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id VAA11921; Thu, 18 Sep 1997 21:08:39 +0900 (JST) Message-Id: <199709181208.VAA11921@zodiac.mech.utsunomiya-u.ac.jp> To: John-Mark Gurney cc: FreeBSD Current , yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: sio aware pnp driver and resource conflict detection In-reply-to: Your message of "Thu, 18 Sep 1997 01:52:13 MST." <19970918015212.63324@hydrogen.nike.efn.org> References: <19970918015212.63324@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 21:08:38 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >well... I was wondering if people would like for me to import my changes >to make sio a PnP aware driver... I would provide a PnP flag that >would prevent the card from being probed... > >but if I do import this code, I will need to add a temporary fix to >the resource system to search attached pnp devices for resource >conflicts... (prevent the modem from being attached twice which >does happen and causes wierd results)... > >currently the pnp system doesn't prevent you from doing stupid things >like configuring two pnp cards to colid with each other... and I could >possibly fix this before the snap comes out... > >comments? I am currently working on extending `moused', `psm', `mse', etc to support modern mice such as MS IntelliMouse. To this end `moused' need to know the type of mouse so that data stream from the mouse can be correctly decoded. I have added a piece of code to `moused' to probe the specified serial port in order to determine the type of mouse by decoding PnP ID string if available. But, because there are so many mice, old and new, which do not support the PnP COM device specification, `moused' has to assume that a mouse is present at the user-specified port anyway. In this case the user must explicitly supply `moused' with the type of mouse. (In 3.0-CURRENT and 2.2-STABLE the user must always tell the type of mouse to `moused'.) Snapshot of my work is found in ftp://ftp.freebsd.org/pub/FreeBSD/incoming/mouse.tar.gz I can send you more recent code if you ask me. Because of the above, I am very much interested in the integral support for PnP serial devices in FreeBSD either at the kernel level or the user-land level. >From the viewpoint of mouse support, I would note the followings: 1. As I have stated, there are so many serial mice which just do not support PnP spec. Moreover, even if a mouse does support the spec, the degree of conformance to the spec varies widely from one mouse to another. It is my finding that some mice conform earlier draft of the spec and it may not give a valid ID string or may not respond to enumeration procedure at all if you strictly follow the current PnP COM device specification ver1.0 (28 Feb 95)! Beware. 2. If serial PnP support is built in at the kernel level, it would mean that now kernel level serial mouse driver will be possible. This is great. But, we need to solve two problems: a. How we can support non-PnP mice with this kernel level serial mouse driver? b. Does such driver have to include its own serial I/O code? Comments? Kazu From owner-freebsd-current Thu Sep 18 06:08:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA04422 for current-outgoing; Thu, 18 Sep 1997 06:08:45 -0700 (PDT) Received: from freebsd1.cimlogic.com.au ([203.36.2.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA04415 for ; Thu, 18 Sep 1997 06:08:35 -0700 (PDT) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.8.5/8.8.5) id XAA08877; Thu, 18 Sep 1997 23:09:30 GMT From: John Birrell Message-Id: <199709182309.XAA08877@freebsd1.cimlogic.com.au> Subject: Re: Thread safe libc In-Reply-To: from Ian Hungerford at "Sep 17, 97 02:35:18 pm" To: ianh@saturn-tech.com (Ian Hungerford) Date: Thu, 18 Sep 1997 23:09:29 +0000 (GMT) Cc: jb@cimlogic.com.au, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ian Hungerford wrote: > OK, I'm on the job. :) Great. > > Some clarification is necessary for the second part, though. Should the > replacements for statics be allocated using thread specific data > (destroyed when the thread terminates) or malloc() (with the caller > assuming responsibility for the free() call)? I prefer the first method - > the latter is indescribably ugly, and programs that want to pass pointers > to these objects between threads should simply use the new _r functions. Like you, I prefer that the replacements for the statics be allocated with thread specific data, then they call the appropriate _r function. This allows the code to behave within each thread as though that thread were the only one. I don't think we should worry too much about how the replacements for the statics behave *between* threads, because a threaded program should really be using the _r functions. > --- > Ian > > Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 From owner-freebsd-current Thu Sep 18 06:32:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA05744 for current-outgoing; Thu, 18 Sep 1997 06:32:32 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA05630 for ; Thu, 18 Sep 1997 06:30:49 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA09800; Thu, 18 Sep 1997 14:14:41 +0200 From: Luigi Rizzo Message-Id: <199709181214.OAA09800@labinfo.iet.unipi.it> Subject: Re: sio aware pnp driver and resource conflict detection To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Date: Thu, 18 Sep 1997 14:14:41 +0200 (MET DST) Cc: gurney_j@resnet.uoregon.edu, freebsd-current@FreeBSD.ORG, yokota@zodiac.mech.utsunomiya-u.ac.jp In-Reply-To: <199709181208.VAA11921@zodiac.mech.utsunomiya-u.ac.jp> from "Kazutaka YOKOTA" at Sep 18, 97 09:08:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I am currently working on extending `moused', `psm', `mse', etc to > support modern mice such as MS IntelliMouse. ... > I have added a piece of code to `moused' to probe the specified serial > port in order to determine the type of mouse by decoding PnP ID string The PnP support which is in -current only refers to the 'ISA PnP' i.e. cards plugged on the ISA bus. I believe you refer to the 'COM PnP' which asks the mouse's type by bit-banging on the RS232 lines. This should probably go into the 'com' or 'sio' driver ? Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-current Thu Sep 18 07:58:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA10988 for current-outgoing; Thu, 18 Sep 1997 07:58:06 -0700 (PDT) Received: from lamb.sas.com (daemon@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA10980 for ; Thu, 18 Sep 1997 07:58:01 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA05585; Thu, 18 Sep 1997 10:57:59 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA23560; Thu, 18 Sep 1997 10:53:43 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA09453; Thu, 18 Sep 1997 10:53:43 -0400 Message-Id: <199709181453.AA09453@iluvatar.unx.sas.com> Subject: vx driver problem at 100T speeds To: freebsd-current@freebsd.org Date: Thu, 18 Sep 1997 10:53:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I have been experiencing problems with nfs on current system(s) for a while and believe I may have narrowed the problem down to the vx driver... (3.0-970911-SNAP is the latest I've tested). In 100T Full Duplex (3com 905 pci , 959 pci card) 100T Half Duplex (3com 905 pci , 959 pci card) the system exhibits a problem of freezing up momentarily and then continuing, sometimes correctly, sometimes with an error. (Not just with nfs, but I'm using nfs almost exclusively, so it shows up the most there). In 10T Half Duplex (3com 905 pci , 959 pci card) the system works correctly, with no errors. In 100T Full Duplex (Intel 10/100 pci card) 100T Half Duplex (Intel 10/100 pci card) the system works correctly. with no errors. We attached a sniffer to the network, and found that the 3com cards are sending bad packets... Approximately 95% of the time, a mount_nfs command will cause a frame to be sent with an incorrect crc. This happens with the 3com card, but not the intel. The sniffer reports a bad crc, and then says that the frame length doesn't match the length given in the header (ie: short frame by 140 bytes). It is ALWAYS 140 bytes short. I've tested 3 different 3com cards: Motherboard 3c905 Adapter pci 3c905 Adapter pci 3c959 They all exhibit the same behaviour. What is the best way to track this down... I have access to the sniffer for the next week or so... Thanks, John -- jwd@NSunx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-current Thu Sep 18 08:35:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA13246 for current-outgoing; Thu, 18 Sep 1997 08:35:16 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA13240 for ; Thu, 18 Sep 1997 08:35:14 -0700 (PDT) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id KAA21298 for ; Thu, 18 Sep 1997 10:35:08 -0500 (CDT) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) id KAA13771; Thu, 18 Sep 1997 10:35:08 -0500 (CDT) Message-ID: <19970918103505.29635@Jupiter.Mcs.Net> Date: Thu, 18 Sep 1997 10:35:05 -0500 From: Karl Denninger To: current@freebsd.org Subject: "Make release" fails Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi folks... Make release is dead. I tried it yesterday after making sure I had supped all the current sources, and this is where it blew chunks... p ./rtermcap cons25 | file2c 'const char termcap_cons25[] = {' ',0};' >> makedevs.tmp ./rtermcap cons25-m | file2c 'const char termcap_cons25_m[] = {' ',0};' >> makedevs.tmp ./rtermcap cons25r | file2c 'const char termcap_cons25r[] = {' ',0};' >> makedevs.tmp ./rtermcap cons25r-m | file2c 'const char termcap_cons25r_m[] = {' ',0};' >> makedevs.tmp ./rtermcap cons25l1 | file2c 'const char termcap_cons25l1[] = {' ',0};' >> makedevs.tmp ./rtermcap cons25l1-m | file2c 'const char termcap_cons25l1_m[] = {' ',0};' >> makedevs.tmp ./rtermcap vt100 | file2c 'const char termcap_vt100[] = {' ',0};' >> makedevs.tmp mv makedevs.tmp makedevs.c make: don't know how to make variable_load.c. Stop *** Error code 2 Stop. *** Error code 1 Stop. Grrr..... :-) Make world ran ok. Any ideas on what's going on here? The last load I built has the bad system loader (where everything is all bunched together) so I wanted to build another one. Thanks in advance! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Thu Sep 18 08:50:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA14247 for current-outgoing; Thu, 18 Sep 1997 08:50:57 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA14234 for ; Thu, 18 Sep 1997 08:50:52 -0700 (PDT) Received: (qmail 13433 invoked by uid 1000); 18 Sep 1997 15:51:13 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970917235052.49236@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 08:51:13 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: John-Mark Gurney Subject: Re: Make Release Build Errors... More... Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi John-Mark Gurney; On 18-Sep-97 you wrote: > Simon Shapiro scribbled this message on Sep 17: > > cd /usr/doc && make all distribute DISTDIR=/R/stage/trees > > ===> FAQ > > sgmlfmt -f html /usr/doc/FAQ/FAQ.sgml > > sgmlfmt: not found > > *** Error code 1 (continuing) > > sgmlfmt -f latin1 /usr/doc/FAQ/FAQ.sgml > > sgmlfmt: not found > > did you install this from the ports tree? I believe that > textproc/sgmlformat will fix that... Again, to insure that the process is repeatable and works as intended, I simply ``cd /usr/src/release; make release > /tmp/release.out 2>&1&''. I do not understand what ``...textproc/sgmlformat will fix that...'' mean :-( Should I add this command to the Makefile at some point? Is it a utility I should have on the system? Sorry, but FreeBSD ha so much in it that I cannot learn it all at once :-( > > the rest I'm not sure about... > > -- > John-Mark Gurney Modem/FAX: +1 541 683 6954 > Cu Networking > > Live in Peace, destroy Micro$oft, support free software, run FreeBSD --- Sincerely Yours, (Sent on 18-Sep-97, 08:15:52 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Thu Sep 18 08:51:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA14264 for current-outgoing; Thu, 18 Sep 1997 08:51:01 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA14246 for ; Thu, 18 Sep 1997 08:50:56 -0700 (PDT) Received: (qmail 13430 invoked by uid 1000); 18 Sep 1997 15:51:13 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Thu, 18 Sep 1997 08:51:13 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Another make release error Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ln -sf machine/varargs.h /usr/include/varargs.h ===> rpcsvc install -C -o bin -g bin -m 444 /usr/src/include/rpcsvc/yp_prot.h /usr/src/include/rpcsvc/ypclnt.h /usr/src/include/rpcsvc/nis_db.h /usr/src/include/rpcsvc/nis_tags.h /usr/src/include/rpcsvc/nislib.h /usr/src/include/rpcsvc/bootparam_prot.x /usr/src/include/rpcsvc/key_prot.x /usr/src/include/rpcsvc/klm_prot.x /usr/src/include/rpcsvc/mount.x /usr/src/include/rpcsvc/nfs_prot.x /usr/src/include/rpcsvc/nlm_prot.x /usr/src/include/rpcsvc/rex.x /usr/src/include/rpcsvc/rnusers.x /usr/src/include/rpcsvc/rquota.x /usr/src/include/rpcsvc/rstat.x /usr/src/include/rpcsvc/rwall.x /usr/src/include/rpcsvc/sm_inter.x /usr/src/include/rpcsvc/spray.x /usr/src/include/rpcsvc/yppasswd.x /usr/src/include/rpcsvc/yp.x /usr/src/include/rpcsvc/ypxfrd.x /usr/src/include/rpcsvc/ypupdate_prot.x /usr/src/include/rpcsvc/nis.x /usr/src/include/rpcsvc/nis_cache.x /usr/src/include/rpcsvc/nis_object.x /usr/src/include/rpcsvc/nis_callback.x /usr/src/include/rpcsvc/crypt.x key_prot.h klm_prot.h mount.h nfs_prot.h nlm_prot.h rex.h rnusers.h rquota.h rstat.h rwall.h sm_inter.h spray.h yppasswd.h yp.h ypxfrd.h ypupdate_prot.h nis.h nis_cache.h nis_callback.h bootparam_prot.h crypt.h /usr/include/rpcsvc + make world "/usr/share/mk/bsd.subdir.mk", line 2: Inconsistent operator for maninstall make: fatal errors encountered -- cannot continue *** Error code 1 I cannot tell what is wrong... :-( --- Sincerely Yours, (Sent on 18-Sep-97, 08:12:39 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Thu Sep 18 10:03:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA19613 for current-outgoing; Thu, 18 Sep 1997 10:03:28 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA19607 for ; Thu, 18 Sep 1997 10:03:25 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id KAA20721; Thu, 18 Sep 1997 10:02:58 -0700 (MST) From: Terry Lambert Message-Id: <199709181702.KAA20721@usr03.primenet.com> Subject: Re: Thread safe libc To: jb@cimlogic.com.au (John Birrell) Date: Thu, 18 Sep 1997 17:02:57 +0000 (GMT) Cc: ianh@saturn-tech.com, jb@cimlogic.com.au, freebsd-current@FreeBSD.ORG In-Reply-To: <199709182309.XAA08877@freebsd1.cimlogic.com.au> from "John Birrell" at Sep 18, 97 11:09:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Like you, I prefer that the replacements for the statics be allocated > with thread specific data, then they call the appropriate _r function. > This allows the code to behave within each thread as though that thread > were the only one. > > I don't think we should worry too much about how the replacements for > the statics behave *between* threads, because a threaded program > should really be using the _r functions. This was the rationale Microsoft gave for not supporting "Free Threading" until VC++ 4.2g, when they introduced the concept of Marshalling TSD (they call it TLS) between threads in nominally the same address space. I truly believe that this is the slippery slope. Unless the design issues are considered up front, we will end up with another historical crock, like library functions which return pointers to static data, or family specific network address manipulation routines, or VFS layers that make VM and other kernel specific calls, or TERMIOS tty revoke handling, or POSIX, etc.. Bogosities unfortunately abound. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 18 13:23:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA03563 for current-outgoing; Thu, 18 Sep 1997 13:23:41 -0700 (PDT) Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA03551 for ; Thu, 18 Sep 1997 13:23:20 -0700 (PDT) Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 03256516.007063A7 ; Thu, 18 Sep 1997 17:27:35 -0300 X-Lotus-FromDomain: VOGA From: "Daniel Sobral" To: freebsd-current@freebsd.org Message-ID: <03256516.006FB32F.00@papagaio.voga.com.br> Date: Thu, 18 Sep 1997 17:24:08 -0300 Subject: XFree on current.freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was trying to install XFree from current, but it would always fail... So I got my tcpdump, ftped to current and... Sysinstall is trying to get a lot of files under XF86331 that are _not_ there, but appear under XF8633 (with XF8633 name, of course). Now, sysinstall _also_ try to get some files from XF8633... is 331 distribution just an update of a few files? *Where* can I correct the names for sysinstall, if that's really the case? Please reply directly to me, as I'm only subscribed to current as digest. From owner-freebsd-current Thu Sep 18 13:24:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA03611 for current-outgoing; Thu, 18 Sep 1997 13:24:02 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA03590 for ; Thu, 18 Sep 1997 13:23:55 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA14497 for freebsd-current@FreeBSD.ORG; Thu, 18 Sep 1997 22:23:52 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id WAA08271; Thu, 18 Sep 1997 22:09:10 +0200 (MET DST) Message-ID: <19970918220910.RO28110@uriah.heep.sax.de> Date: Thu, 18 Sep 1997 22:09:10 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Subject: Re: Make Release Build Errors... More... References: <19970917235052.49236@hydrogen.nike.efn.org> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Sep 18, 1997 08:51:13 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > I do not understand what ``...textproc/sgmlformat will fix that...'' mean > :-( Should I add this command to the Makefile at some point? Is it a > utility I should have on the system? Sorry, but FreeBSD ha so much in it > that I cannot learn it all at once :-( You need to install this port, in order to build the doc tree (which is no longer part of the src tree). You need to be able to build the doc tree in order to make a release (since documentation should still be shipped with releases). Without looking into the Makefile, i would quickly guess that building the doc tree is optional. Did you even look there? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Sep 18 14:47:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09239 for current-outgoing; Thu, 18 Sep 1997 14:47:53 -0700 (PDT) Received: from helios.dnttm.ru (root@dnttm.wave.ras.ru [194.85.104.197]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09134 for ; Thu, 18 Sep 1997 14:44:56 -0700 (PDT) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id BAA08543 for freebsd-current@freebsd.org; Fri, 19 Sep 1997 01:37:50 +0400 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.7/8.8.5) with ESMTP id BAA01100 for ; Fri, 19 Sep 1997 01:41:29 +0400 (MSD) Message-Id: <199709182141.BAA01100@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: freebsd-current@freebsd.org Subject: Yet Another bug in src/Makefile Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 01:41:28 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 'make -DCLOBBER world' will not remove /usr/include. It will remove /usr/obj/usr/src/tmp/usr/include instead... Dima From owner-freebsd-current Thu Sep 18 15:03:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA10801 for current-outgoing; Thu, 18 Sep 1997 15:03:41 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA10793 for ; Thu, 18 Sep 1997 15:03:35 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id PAA00318; Thu, 18 Sep 1997 15:03:23 -0700 (PDT) Message-ID: <19970918150322.03906@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 15:03:22 -0700 From: John-Mark Gurney To: Simon Shapiro Cc: freebsd-current@FreeBSD.ORG Subject: Re: Make Release Build Errors... More... References: <19970917235052.49236@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Simon Shapiro on Thu, Sep 18, 1997 at 08:51:13AM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro scribbled this message on Sep 18: > > Hi John-Mark Gurney; On 18-Sep-97 you wrote: > > Simon Shapiro scribbled this message on Sep 17: > > > cd /usr/doc && make all distribute DISTDIR=/R/stage/trees > > > ===> FAQ > > > sgmlfmt -f html /usr/doc/FAQ/FAQ.sgml > > > sgmlfmt: not found > > > *** Error code 1 (continuing) > > > sgmlfmt -f latin1 /usr/doc/FAQ/FAQ.sgml > > > sgmlfmt: not found > > > > did you install this from the ports tree? I believe that > > textproc/sgmlformat will fix that... > > Again, to insure that the process is repeatable and works as intended, > I simply ``cd /usr/src/release; make release > /tmp/release.out 2>&1&''. > > I do not understand what ``...textproc/sgmlformat will fix that...'' mean > :-( Should I add this command to the Makefile at some point? Is it a > utility I should have on the system? Sorry, but FreeBSD ha so much in it > that I cannot learn it all at once :-( this is a port, do: cvs /tmp cvs co ports/textproc/sgmlformat cd ports/textproc/sgmlformat make all install this of course assumes that you also have the ports tree.. or you can go to ftp.cdrom.com and grab a copy of the package... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Sep 18 15:35:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13356 for current-outgoing; Thu, 18 Sep 1997 15:35:39 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13343 for ; Thu, 18 Sep 1997 15:35:35 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id RAA09701 for current@freebsd.org.; Thu, 18 Sep 1997 17:35:33 -0500 (EST) From: "John S. Dyson" Message-Id: <199709182235.RAA09701@dyson.iquest.net> Subject: FYI: regarding our rfork(2) To: current@freebsd.org Date: Thu, 18 Sep 1997 17:35:33 -0500 (EST) Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am going to be changing our rfork implementation in the following ways: Rename RFMEM to RFSHMEM, implying that we are fully sharing memory. Also implying that we don't support RFMEM in the same way as other OSes might. Add an additional argument to rfork(2) to support specifying a new stack address in the child. This argument is meaningful only if RFSHMEM is specified. This mod will eliminate some potential timing windows when the child is running with the parents stack. It will also eliminate the need for certain "gymnastics" in code that uses rfork with RFSHMEM. I'll be committing the changes tonight, so let me know if anyone has problems with the concept. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Thu Sep 18 15:56:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA14913 for current-outgoing; Thu, 18 Sep 1997 15:56:04 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA14827 for ; Thu, 18 Sep 1997 15:55:59 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id PAA16148; Thu, 18 Sep 1997 15:55:31 -0700 (PDT) To: "Daniel Sobral" cc: freebsd-current@FreeBSD.ORG Subject: Re: XFree on current.freebsd.org In-reply-to: Your message of "Thu, 18 Sep 1997 17:24:08 -0300." <03256516.006FB32F.00@papagaio.voga.com.br> Date: Thu, 18 Sep 1997 15:55:31 -0700 Message-ID: <16144.874623331@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The correct name is now XF86331 and sysinstall had a bogon until this morning which had one location remaining at XF8633. It's fixed now and you should simply try again. Jordan > I was trying to install XFree from current, but it would always fail... So > I got my tcpdump, ftped to current and... > > Sysinstall is trying to get a lot of files under XF86331 that are _not_ > there, but appear under XF8633 (with XF8633 name, of course). Now, > sysinstall _also_ try to get some files from XF8633... is 331 distribution > just an update of a few files? *Where* can I correct the names for > sysinstall, if that's really the case? > > Please reply directly to me, as I'm only subscribed to current as digest. > > From owner-freebsd-current Thu Sep 18 16:29:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17395 for current-outgoing; Thu, 18 Sep 1997 16:29:57 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA17387 for ; Thu, 18 Sep 1997 16:29:52 -0700 (PDT) Received: (qmail 19773 invoked by uid 1000); 18 Sep 1997 23:30:14 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970918220910.RO28110@uriah.heep.sax.de> Date: Thu, 18 Sep 1997 16:30:13 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: (Joerg Wunsch) Subject: Re: Make Release Build Errors... More... Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi J Wunsch; On 18-Sep-97 you wrote: > As Simon Shapiro wrote: > > > I do not understand what ``...textproc/sgmlformat will fix that...'' > > mean > > :-( Should I add this command to the Makefile at some point? Is it a > > utility I should have on the system? Sorry, but FreeBSD ha so much in > > it > > that I cannot learn it all at once :-( > > You need to install this port, in order to build the doc tree (which > is no longer part of the src tree). You need to be able to build the > doc tree in order to make a release (since documentation should still > be shipped with releases). > > Without looking into the Makefile, i would quickly guess that building > the doc tree is optional. Did you even look there? Yup. Looked there and saw one can kill the doc build but not an indication that the port needs to build. As I said, it is installed on the system. I'll try again... > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: > JW11-RIPE > Never trust an operating system you don't have sources for. ;-) --- Sincerely Yours, (Sent on 18-Sep-97, 16:16:49 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Thu Sep 18 16:32:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17563 for current-outgoing; Thu, 18 Sep 1997 16:32:21 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17557; Thu, 18 Sep 1997 16:32:13 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA09735; Thu, 18 Sep 1997 16:23:41 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd009733; Thu Sep 18 23:23:32 1997 Message-ID: <3421B7C9.3F54BC7E@whistle.com> Date: Thu, 18 Sep 1997 16:22:49 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: dyson@FreeBSD.ORG CC: current@FreeBSD.ORG Subject: Re: FYI: regarding our rfork(2) References: <199709182235.RAA09701@dyson.iquest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John S. Dyson wrote: > > I am going to be changing our rfork implementation in the following ways: > > Rename RFMEM to RFSHMEM, implying that we are fully sharing memory. > Also implying that we don't support RFMEM in the same way as other > OSes might. Add an additional argument to rfork(2) to support > specifying a new stack address in the child. This argument is > meaningful only if RFSHMEM is specified. This mod will eliminate > some potential timing windows when the child is running with the > parents stack. It will also eliminate the need for certain > "gymnastics" in code that uses rfork with RFSHMEM. > > I'll be committing the changes tonight, so let me know if anyone > has problems with the concept. well, it makes it incompatible with the rfork in plan 9 What does Linux's clone() call have as arguments..? > > -- > John > dyson@freebsd.org > jdyson@nc.com From owner-freebsd-current Thu Sep 18 16:59:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA19081 for current-outgoing; Thu, 18 Sep 1997 16:59:51 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA19062; Thu, 18 Sep 1997 16:59:35 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id SAA00339; Thu, 18 Sep 1997 18:59:25 -0500 (EST) From: "John S. Dyson" Message-Id: <199709182359.SAA00339@dyson.iquest.net> Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <3421B7C9.3F54BC7E@whistle.com> from Julian Elischer at "Sep 18, 97 04:22:49 pm" To: julian@whistle.com (Julian Elischer) Date: Thu, 18 Sep 1997 18:59:24 -0500 (EST) Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Julian Elischer said: > John S. Dyson wrote: > > > > I am going to be changing our rfork implementation in the following ways: > > > > Rename RFMEM to RFSHMEM, implying that we are fully sharing memory. > > Also implying that we don't support RFMEM in the same way as other > > OSes might. Add an additional argument to rfork(2) to support > > specifying a new stack address in the child. This argument is > > meaningful only if RFSHMEM is specified. This mod will eliminate > > some potential timing windows when the child is running with the > > parents stack. It will also eliminate the need for certain > > "gymnastics" in code that uses rfork with RFSHMEM. > > > > I'll be committing the changes tonight, so let me know if anyone > > has problems with the concept. > > well, it makes it incompatible with the rfork in plan 9 > It is incompatible anyway, that is the reason that I am changing RFMEM to RFSHMEM. If we create a compatible RFMEM, then we can be compatible. > > What does Linux's clone() call have as arguments..? > I don't think that it makes any difference. I am trying to solve a specific problem with RF(SH)MEM that can be fixed a simple way (my proposal), or a significantly more complex way, messing with signal masks, etc. John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Thu Sep 18 17:06:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19646 for current-outgoing; Thu, 18 Sep 1997 17:06:30 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19631; Thu, 18 Sep 1997 17:06:23 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id CAA11932; Fri, 19 Sep 1997 02:12:33 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709190012.CAA11932@ocean.campus.luth.se> Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709182235.RAA09701@dyson.iquest.net> from "John S. Dyson" at "Sep 18, 97 05:35:33 pm" To: dyson@FreeBSD.ORG Date: Fri, 19 Sep 1997 02:12:33 +0200 (CEST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to John S. Dyson: > I am going to be changing our rfork implementation in the following ways: > > Rename RFMEM to RFSHMEM, implying that we are fully sharing memory. > Also implying that we don't support RFMEM in the same way as other > OSes might. Add an additional argument to rfork(2) to support > specifying a new stack address in the child. This argument is > meaningful only if RFSHMEM is specified. This mod will eliminate > some potential timing windows when the child is running with the > parents stack. It will also eliminate the need for certain > "gymnastics" in code that uses rfork with RFSHMEM. > > I'll be committing the changes tonight, so let me know if anyone > has problems with the concept. Sounds good, but I as always I have some nosy questions out of personal interest only: Is rfork() in any way portable enough to even consider keeping it happy in porting software? Is it/should we try to keep it compatible with other BSDs at least? If so: Would be be hard to do a "real" RFMEM too? (Probably not instantly since it is wanted that things fall over from the lack of RFMEM if they are using it. But when they are fixed.) Will it be a problem for compilation if the new argument is not given, or will it be a "..." argument, or something? Thanks for listening... :-) /Mikael From owner-freebsd-current Thu Sep 18 17:44:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22504 for current-outgoing; Thu, 18 Sep 1997 17:44:54 -0700 (PDT) Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA22492 for ; Thu, 18 Sep 1997 17:44:47 -0700 (PDT) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by nasu.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id JAA05464; Fri, 19 Sep 1997 09:41:05 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (p/weqJzV/D2x+SAeeRMzfNmKBQUhFWPW@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id JAA28677; Fri, 19 Sep 1997 09:41:05 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zenith.mech.utsunomiya-u.ac.jp [160.12.42.60]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id JAA26545; Fri, 19 Sep 1997 09:47:09 +0900 (JST) Message-Id: <199709190047.JAA26545@zodiac.mech.utsunomiya-u.ac.jp> To: Luigi Rizzo cc: gurney_j@resnet.uoregon.edu, freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: sio aware pnp driver and resource conflict detection In-reply-to: Your message of "Thu, 18 Sep 1997 14:14:41 +0200." <199709181214.OAA09800@labinfo.iet.unipi.it> References: <199709181214.OAA09800@labinfo.iet.unipi.it> Date: Fri, 19 Sep 1997 09:47:07 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I am currently working on extending `moused', `psm', `mse', etc to >> support modern mice such as MS IntelliMouse. >... >> I have added a piece of code to `moused' to probe the specified serial >> port in order to determine the type of mouse by decoding PnP ID string > >The PnP support which is in -current only refers to the 'ISA PnP' i.e. >cards plugged on the ISA bus. > >I believe you refer to the 'COM PnP' which asks the mouse's type by >bit-banging on the RS232 lines. This should probably go into the 'com' >or 'sio' driver ? Yes, that's right. I thought John-Mark Gurney was refering to that spec. Was I mistaken? Kaz From owner-freebsd-current Thu Sep 18 17:47:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22671 for current-outgoing; Thu, 18 Sep 1997 17:47:21 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA22665 for ; Thu, 18 Sep 1997 17:47:16 -0700 (PDT) Received: (qmail 21180 invoked by uid 1000); 19 Sep 1997 00:47:39 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970918150322.03906@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 17:47:39 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: John-Mark Gurney Subject: Re: Make Release Build Errors... More... Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi John-Mark Gurney; On 18-Sep-97 you wrote: ... > this is a port, do: > cvs /tmp > cvs co ports/textproc/sgmlformat > cd ports/textproc/sgmlformat > make all install ===> sgmlfmt install -c -o bin -g bin -m 444 sgmlfmt.1.gz /usr/local/man/man1 install -c -o bin -g bin -m 555 sgmlfmt /usr/local/bin ***************************************************************** To avoid any confusion with the versions of these tools that might already be installed in your system, after installing this package you may wish move or remove: /usr/bin/sgmlfmt /usr/bin/sgmls /usr/bin/instant /usr/share/sgml/* (all subdirectories) >>-->>> Should I do that? ***************************************************************** ===> Registering installation for sgmlformat-1.4 Warning: "/usr/ports/textproc/docbook" non-existent -- @pkgdep registration incomplete Warning: "/usr/ports/textproc/jade" non-existent -- @pkgdep registration incomplete Warning: "/usr/ports/textproc/linuxdoc" non-existent -- @pkgdep registration incomplete >>-->>> Should I pay any attention to these? --- Sincerely Yours, (Sent on 18-Sep-97, 17:44:20 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Thu Sep 18 18:19:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA24732 for current-outgoing; Thu, 18 Sep 1997 18:19:28 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA24725; Thu, 18 Sep 1997 18:19:20 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id UAA00556; Thu, 18 Sep 1997 20:19:13 -0500 (EST) From: "John S. Dyson" Message-Id: <199709190119.UAA00556@dyson.iquest.net> Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709190012.CAA11932@ocean.campus.luth.se> from Mikael Karpberg at "Sep 19, 97 02:12:33 am" To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Thu, 18 Sep 1997 20:19:13 -0500 (EST) Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg said: > According to John S. Dyson: > > I am going to be changing our rfork implementation in the following ways: > > > > Rename RFMEM to RFSHMEM, implying that we are fully sharing memory. > > Also implying that we don't support RFMEM in the same way as other > > OSes might. Add an additional argument to rfork(2) to support > > specifying a new stack address in the child. This argument is > > meaningful only if RFSHMEM is specified. This mod will eliminate > > some potential timing windows when the child is running with the > > parents stack. It will also eliminate the need for certain > > "gymnastics" in code that uses rfork with RFSHMEM. > > > > I'll be committing the changes tonight, so let me know if anyone > > has problems with the concept. > > Sounds good, but I as always I have some nosy questions out of > personal interest only: > > Is rfork() in any way portable enough to even consider keeping it happy > in porting software? Is it/should we try to keep it compatible with other > BSDs at least? > We are actually doing a pure memory sharing operation. We will be sharing everything, plan 9 doesn't appear to share the stack. In order to support pthreads, (and most thread schemes that I have seen), it is best to allow full access to all of the thread stacks. The 'full sharing' scheme is very fast. > > If so: > Would be be hard to do a "real" RFMEM too? (Probably not instantly since > it is wanted that things fall over from the lack of RFMEM if they are > using it. But when they are fixed.) > We could support the RFMEM as in Plan9, and IMO, that would be better from the standpoint of proper isolation of threads, but that isn't how threads are usually used. > > Will it be a problem for compilation if the new argument is not given, > or will it be a "..." argument, or something? > Shouldn't be a problem, it'll be like 'open(2)', where you can specify 2 or 3 args. > > Thanks for listening... :-) > No problem!!!! -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Thu Sep 18 18:27:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA25430 for current-outgoing; Thu, 18 Sep 1997 18:27:51 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA25412 for ; Thu, 18 Sep 1997 18:27:45 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id SAA01001; Thu, 18 Sep 1997 18:27:01 -0700 (PDT) Message-ID: <19970918182701.49721@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 18:27:01 -0700 From: John-Mark Gurney To: Kazutaka YOKOTA Cc: Luigi Rizzo , freebsd-current@freebsd.org Subject: Re: sio aware pnp driver and resource conflict detection References: <199709181214.OAA09800@labinfo.iet.unipi.it> <199709190047.JAA26545@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709190047.JAA26545@zodiac.mech.utsunomiya-u.ac.jp>; from Kazutaka YOKOTA on Fri, Sep 19, 1997 at 09:47:07AM +0900 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Kazutaka YOKOTA scribbled this message on Sep 19: > >> I am currently working on extending `moused', `psm', `mse', etc to > >> support modern mice such as MS IntelliMouse. > >... > >> I have added a piece of code to `moused' to probe the specified serial > >> port in order to determine the type of mouse by decoding PnP ID string > > > >The PnP support which is in -current only refers to the 'ISA PnP' i.e. > >cards plugged on the ISA bus. > > > >I believe you refer to the 'COM PnP' which asks the mouse's type by > >bit-banging on the RS232 lines. This should probably go into the 'com' > >or 'sio' driver ? > > Yes, that's right. I thought John-Mark Gurney was refering to that > spec. Was I mistaken? yes you are mistaken.. the support I'm talking about is supporting PnP modems to automaticly bind to the sio driver.. and reading their possibly unusual configurations from the config... I ran a modem at 0x280/11 with the new PnP-aware driver... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Sep 18 18:30:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA25834 for current-outgoing; Thu, 18 Sep 1997 18:30:57 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA25821 for ; Thu, 18 Sep 1997 18:30:52 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id SAA01014; Thu, 18 Sep 1997 18:30:39 -0700 (PDT) Message-ID: <19970918183039.50286@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 18:30:39 -0700 From: John-Mark Gurney To: Simon Shapiro Cc: freebsd-current@FreeBSD.ORG Subject: Re: Make Release Build Errors... More... References: <19970918150322.03906@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Simon Shapiro on Thu, Sep 18, 1997 at 05:47:39PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro scribbled this message on Sep 18: > > this is a port, do: > > cvs /tmp > > cvs co ports/textproc/sgmlformat > > cd ports/textproc/sgmlformat > > make all install > > ===> sgmlfmt > install -c -o bin -g bin -m 444 sgmlfmt.1.gz /usr/local/man/man1 > install -c -o bin -g bin -m 555 sgmlfmt /usr/local/bin > ***************************************************************** > To avoid any confusion with the versions of these tools that > might already be installed in your system, after installing this > package you may wish move or remove: > > /usr/bin/sgmlfmt > /usr/bin/sgmls > /usr/bin/instant > /usr/share/sgml/* (all subdirectories) > > > >>-->>> Should I do that? well.. considering that /usr/bin/sgmlfmt doesn't exist.. the others probably won't either.. but you might just make sure that they don't exist... > ***************************************************************** > ===> Registering installation for sgmlformat-1.4 > Warning: "/usr/ports/textproc/docbook" non-existent -- @pkgdep registration > incomplete > Warning: "/usr/ports/textproc/jade" non-existent -- @pkgdep registration > incomplete > Warning: "/usr/ports/textproc/linuxdoc" non-existent -- @pkgdep > registration incomplete > > >>-->>> Should I pay any attention to these? you probably need them as they contain the definitions that sgmlfmt uses... so you probably should install those too... I'm not sure exactly what was needed as I had built/installed jade before it was a port... so my system still works (for building a web mirror)... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Sep 18 19:40:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00689 for current-outgoing; Thu, 18 Sep 1997 19:40:26 -0700 (PDT) Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00682 for ; Thu, 18 Sep 1997 19:40:19 -0700 (PDT) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by nasu.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id LAA05563; Fri, 19 Sep 1997 11:01:37 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (+vUFCXYsR+m+JAWLKoIi5mWz7BAhQ349@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id LAA28467; Fri, 19 Sep 1997 11:01:36 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zenith.mech.utsunomiya-u.ac.jp [160.12.42.60]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id LAA27657; Fri, 19 Sep 1997 11:07:41 +0900 (JST) Message-Id: <199709190207.LAA27657@zodiac.mech.utsunomiya-u.ac.jp> To: John-Mark Gurney cc: Kazutaka YOKOTA , Luigi Rizzo , freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: sio aware pnp driver and resource conflict detection In-reply-to: Your message of "Thu, 18 Sep 1997 18:27:01 MST." <19970918182701.49721@hydrogen.nike.efn.org> References: <199709181214.OAA09800@labinfo.iet.unipi.it> <199709190047.JAA26545@zodiac.mech.utsunomiya-u.ac.jp> <19970918182701.49721@hydrogen.nike.efn.org> Date: Fri, 19 Sep 1997 11:07:39 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk $@2#ED!w1'ET5\$G$9!#(J >Kazutaka YOKOTA scribbled this message on Sep 19: >> >> I am currently working on extending `moused', `psm', `mse', etc to >> >> support modern mice such as MS IntelliMouse. >> >... >> >> I have added a piece of code to `moused' to probe the specified serial >> >> port in order to determine the type of mouse by decoding PnP ID string >> > >> >The PnP support which is in -current only refers to the 'ISA PnP' i.e. >> >cards plugged on the ISA bus. >> > >> >I believe you refer to the 'COM PnP' which asks the mouse's type by >> >bit-banging on the RS232 lines. This should probably go into the 'com' >> >or 'sio' driver ? >> >> Yes, that's right. I thought John-Mark Gurney was refering to that >> spec. Was I mistaken? > >yes you are mistaken.. the support I'm talking about is supporting >PnP modems to automaticly bind to the sio driver.. and reading their >possibly unusual configurations from the config... I ran a modem at >0x280/11 with the new PnP-aware driver... OK, I know understand you are refering to _internal_ modem cards (for which support for the COM PnP defined in "Play and Play External COM device Sepecification" is not necessary). Kazu From owner-freebsd-current Thu Sep 18 20:23:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA03022 for current-outgoing; Thu, 18 Sep 1997 20:23:37 -0700 (PDT) Received: from eyelab.psy.msu.edu (eyelab.psy.msu.edu [35.8.64.179]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA03016 for ; Thu, 18 Sep 1997 20:23:34 -0700 (PDT) Received: from default (pm157-22.dialip.mich.net [35.9.15.33]) by eyelab.psy.msu.edu (8.8.6/8.8.5) with SMTP id XAA13023 for ; Thu, 18 Sep 1997 23:16:13 -0400 (EDT) Message-Id: <3.0.3.32.19970918232044.007dce30@eyelab.msu.edu> X-Sender: root@eyelab.msu.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 18 Sep 1997 23:20:44 -0400 To: freebsd-current@freebsd.org From: Gary Schrock Subject: XFree86 3.3.1 missing on current.freebsd.org? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Looking in the current/XF86331 dir it looks like there's a bunch of files missing when you compare it to the XF8633 dir, or to the releng/XF86331 dir. There's only about half to 1/3 the files there, and all the ones needed to install are missing. My appologies if this has already been asked. Gary Schrock root@eyelab.msu.edu From owner-freebsd-current Thu Sep 18 21:21:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA07575 for current-outgoing; Thu, 18 Sep 1997 21:21:40 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA07562 for ; Thu, 18 Sep 1997 21:21:33 -0700 (PDT) Received: (qmail 22318 invoked by uid 1000); 19 Sep 1997 04:21:55 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [p0] on FreeBSD X-Priority: 1 (High) Priority: urgent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Thu, 18 Sep 1997 21:21:55 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Make Release - Is there anything I can do to help? Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am really confused. On the 27th of August we had a perfect build. and we made a release. Now, things that were NOT broken then, are borken now. Is there anything I can do to help? What is the review process for checking in changes? Maybe I can help by testing certain things to make sure they, at least compile? I have several machines here and will be more than happy to help in any way I can. I cannot comment much on the last few problems I reported as now I have a new, earlier breakage. the only comment is that sgmlfmt was NOT missing from my system, but is missing from the release build area, and thus reported missing. I did install all the pieces it was recommended to install. Anyway, here is where it fails tonight: ===> share/timedef/data for l in da_DK.ISO_8859-1 de_AT.ISO_8859-1 de_DE.ISO_8859-1 en_GB.ISO_8859-1 en_US.ISO_8859-1 fr_FR.ISO_8859-1 hr_HR.ISO_8859-2 is_IS.ISO_8859-1 ja_JP.SJIS it_IT.ISO_8859-1 ko_KR.EUC no_NO.ISO_8859-1 pt_PT.ISO_8859-1 ru_SU.CP866 ru_SU.KOI8-R; do install -c -m 644 -o bin -g bin $l.out /Targets/3.0-970918-SNAP/usr/share/locale/$l/LC_TIME; done install: ja_JP.SJIS.out: No such file or directory *** Error code 71 The source files EXIST, in my CVS tree, in my checkout are and in the release build area. The target is NOT. again, there has been no change in our procedure, short of doing a make installworld yesterday at 0830, after a successfull make buildworld the night before. I am being so defensive, as half the responses I get to these postings are sarcastic comments about my wits. I am old and slow, but belive that 5 = 5 and never 4 (meaning, if I followed a procedure on Wednesday and changed nothing in it, it should also run on Friday. Thanx, and please let me know how I can help. --- Sincerely Yours, (Sent on 18-Sep-97, 21:03:39 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Thu Sep 18 21:36:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA08584 for current-outgoing; Thu, 18 Sep 1997 21:36:01 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA08564 for ; Thu, 18 Sep 1997 21:35:55 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id VAA01406; Thu, 18 Sep 1997 21:34:46 -0700 (PDT) Message-ID: <19970918213446.00164@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 21:34:46 -0700 From: John-Mark Gurney To: Dmitrij Tejblum Cc: freebsd-current@FreeBSD.ORG Subject: Re: Yet Another bug in src/Makefile References: <199709182141.BAA01100@tejblum.dnttm.rssi.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709182141.BAA01100@tejblum.dnttm.rssi.ru>; from Dmitrij Tejblum on Fri, Sep 19, 1997 at 01:41:28AM +0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dmitrij Tejblum scribbled this message on Sep 19: > 'make -DCLOBBER world' will not remove /usr/include. It will remove > /usr/obj/usr/src/tmp/usr/include instead... why should it remove /usr/include?? /usr/include is not used for the building of the resulting binaries install.. why not do a rm -rf / if you want to clean out the area your installing to... :) of course there is good argument that the installed to area should be clean to prevent old files from contaminating a setup... but if we start to clean out /usr/include, we should also do /{bin,sbin} /usr/{bin,share,sbin,lib,libexec} and any others that get installed... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Sep 18 22:18:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA11909 for current-outgoing; Thu, 18 Sep 1997 22:18:34 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA11901; Thu, 18 Sep 1997 22:18:29 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id XAA12941; Thu, 18 Sep 1997 23:18:21 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id XAA16454; Thu, 18 Sep 1997 23:18:19 -0600 (MDT) Date: Thu, 18 Sep 1997 23:18:19 -0600 (MDT) Message-Id: <199709190518.XAA16454@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "John S. Dyson" Cc: karpen@ocean.campus.luth.se (Mikael Karpberg), dyson@freebsd.org, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709190119.UAA00556@dyson.iquest.net> References: <199709190012.CAA11932@ocean.campus.luth.se> <199709190119.UAA00556@dyson.iquest.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > We are actually doing a pure memory sharing operation. We will be sharing > everything, plan 9 doesn't appear to share the stack. In order to support > pthreads, (and most thread schemes that I have seen), it is best to allow > full access to all of the thread stacks. Forgive me for being naive, but in all of my experiences with threads (not much, but lots lately with Java), it seems that sharing the stack is asking for nothing but trouble. If you need to share memory, allocate a 'global' shared memory bank that everyone can use, and use it. >From where I stand, sharing thread's stacks buys you nothing but problems worse than the malloc/free problems we're talking about. :( (I've got enough problems with the stupid race conditions with AWT in Java.) Nate From owner-freebsd-current Thu Sep 18 22:19:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA11985 for current-outgoing; Thu, 18 Sep 1997 22:19:30 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA11980 for ; Thu, 18 Sep 1997 22:19:28 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA11463; Thu, 18 Sep 1997 22:19:00 -0700 (MST) From: Terry Lambert Message-Id: <199709190519.WAA11463@usr05.primenet.com> Subject: Re: Yet Another bug in src/Makefile To: gurney_j@resnet.uoregon.edu Date: Fri, 19 Sep 1997 05:19:00 +0000 (GMT) Cc: dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG In-Reply-To: <19970918213446.00164@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 18, 97 09:34:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 'make -DCLOBBER world' will not remove /usr/include. It will remove > > /usr/obj/usr/src/tmp/usr/include instead... > > why should it remove /usr/include?? /usr/include is not used for the > building of the resulting binaries install.. why not do a rm -rf / > if you want to clean out the area your installing to... :) This is false. The build for libkvm references outside the source tree (specifically, an absolute reference via -I). This was why I hacked the symbolic links for multiple kernel tree builds (earlier posting). There are other builds which also reference out of the build tree; anything which references or , in particular, references /usr/include. A reference to can't be resolved without /usr/include/ since it refers to the postinstalled headers from /usr/src/sys/i386/include/ into /usr/include/machine/. The , , <*fs/*>, , and references are all in this boat, as well as others from package/base installation (, etc.), if installed. > of course there is good argument that the installed to area should > be clean to prevent old files from contaminating a setup... but > if we start to clean out /usr/include, we should also do /{bin,sbin} > /usr/{bin,share,sbin,lib,libexec} and any others that get installed... The argument is that the installed area should never be used for system build, since you may be building a cross-environment. You either need to build the machine link as part of the build, or you need variant symlinks (whole other kettle of fish) to deal with the architecture variant headers for cross-builds. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 18 22:28:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA12751 for current-outgoing; Thu, 18 Sep 1997 22:28:39 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA12746 for ; Thu, 18 Sep 1997 22:28:36 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id WAA01581; Thu, 18 Sep 1997 22:28:30 -0700 (PDT) Message-ID: <19970918222829.18729@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 22:28:29 -0700 From: John-Mark Gurney To: Terry Lambert Cc: dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG Subject: Re: Yet Another bug in src/Makefile References: <19970918213446.00164@hydrogen.nike.efn.org> <199709190519.WAA11463@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709190519.WAA11463@usr05.primenet.com>; from Terry Lambert on Fri, Sep 19, 1997 at 05:19:00AM +0000 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert scribbled this message on Sep 19: > > > 'make -DCLOBBER world' will not remove /usr/include. It will remove > > > /usr/obj/usr/src/tmp/usr/include instead... > > > > why should it remove /usr/include?? /usr/include is not used for the > > building of the resulting binaries install.. why not do a rm -rf / > > if you want to clean out the area your installing to... :) > > This is false. The build for libkvm references outside the source tree > (specifically, an absolute reference via -I). This was why I hacked > the symbolic links for multiple kernel tree builds (earlier posting). are you sure... my tree reads: LIB= kvm CFLAGS+=-DLIBC_SCCS -I${.CURDIR}/../../sys last I checked, this isn't out of the src tree... > There are other builds which also reference out of the build tree; > anything which references or , in particular, > references /usr/include. A reference to can't be can you show me these mythical references to /usr/include?? I reciently committed a bunch of changes to fix improper use of -I/sys... > resolved without /usr/include/ since it refers to the postinstalled > headers from /usr/src/sys/i386/include/ into /usr/include/machine/. > The , , <*fs/*>, , and references are > all in this boat, as well as others from package/base installation > (, etc.), if installed. ok.. then why does my build tree /usr/obj/a/home/johng/FreeBSD-checkout/current/src/tmp/usr/include, include ALL of the things you listed above?? > > of course there is good argument that the installed to area should > > be clean to prevent old files from contaminating a setup... but > > if we start to clean out /usr/include, we should also do /{bin,sbin} > > /usr/{bin,share,sbin,lib,libexec} and any others that get installed... > > The argument is that the installed area should never be used for > system build, since you may be building a cross-environment. umm... this isn't the case Terry... when was the last time you built world on a -current machine w/o your local patches?? > You either need to build the machine link as part of the build, or you > need variant symlinks (whole other kettle of fish) to deal with the > architecture variant headers for cross-builds. see above... it's already happened... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Sep 18 23:10:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA15711 for current-outgoing; Thu, 18 Sep 1997 23:10:41 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA15704; Thu, 18 Sep 1997 23:10:34 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id BAA00804; Fri, 19 Sep 1997 01:10:23 -0500 (EST) From: "John S. Dyson" Message-Id: <199709190610.BAA00804@dyson.iquest.net> Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709190518.XAA16454@rocky.mt.sri.com> from Nate Williams at "Sep 18, 97 11:18:19 pm" To: nate@mt.sri.com (Nate Williams) Date: Fri, 19 Sep 1997 01:10:23 -0500 (EST) Cc: karpen@ocean.campus.luth.se, dyson@freebsd.org, current@freebsd.org Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams said: > > We are actually doing a pure memory sharing operation. We will be sharing > > everything, plan 9 doesn't appear to share the stack. In order to support > > pthreads, (and most thread schemes that I have seen), it is best to allow > > full access to all of the thread stacks. > > Forgive me for being naive, but in all of my experiences with threads > (not much, but lots lately with Java), it seems that sharing the stack > is asking for nothing but trouble. If you need to share memory, > allocate a 'global' shared memory bank that everyone can use, and use > it. > I don't disagree with what you are saying, however, we need to be able to have full access to the stacks in every thread. Of course, we would be wise to create guard page(s) between stacks. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Thu Sep 18 23:38:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA17847 for current-outgoing; Thu, 18 Sep 1997 23:38:00 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17842 for ; Thu, 18 Sep 1997 23:37:55 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id XAA21941; Thu, 18 Sep 1997 23:37:58 -0700 (PDT) To: Gary Schrock cc: freebsd-current@FreeBSD.ORG Subject: Re: XFree86 3.3.1 missing on current.freebsd.org? In-reply-to: Your message of "Thu, 18 Sep 1997 23:20:44 EDT." <3.0.3.32.19970918232044.007dce30@eyelab.msu.edu> Date: Thu, 18 Sep 1997 23:37:58 -0700 Message-ID: <21937.874651078@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You're right - d'oh! I'm fixing it now, thanks for pointing it out! Jordan > Looking in the current/XF86331 dir it looks like there's a bunch of files > missing when you compare it to the XF8633 dir, or to the releng/XF86331 > dir. There's only about half to 1/3 the files there, and all the ones > needed to install are missing. > > My appologies if this has already been asked. > > > Gary Schrock > root@eyelab.msu.edu > From owner-freebsd-current Thu Sep 18 23:41:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18108 for current-outgoing; Thu, 18 Sep 1997 23:41:19 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (ala-ca26-26.ix.netcom.com [207.93.42.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18103 for ; Thu, 18 Sep 1997 23:41:16 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.7/8.6.9) id XAA10786; Thu, 18 Sep 1997 23:41:06 -0700 (PDT) Date: Thu, 18 Sep 1997 23:41:06 -0700 (PDT) Message-Id: <199709190641.XAA10786@silvia.HIP.Berkeley.EDU> To: tlambert@primenet.com CC: gurney_j@resnet.uoregon.edu, dima@tejblum.dnttm.rssi.ru, freebsd-current@freebsd.org In-reply-to: <199709190519.WAA11463@usr05.primenet.com> (message from Terry Lambert on Fri, 19 Sep 1997 05:19:00 +0000 (GMT)) Subject: Re: Yet Another bug in src/Makefile From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * There are other builds which also reference out of the build tree; * anything which references or , in particular, * references /usr/include. A reference to can't be * resolved without /usr/include/ since it refers to the postinstalled * headers from /usr/src/sys/i386/include/ into /usr/include/machine/. * The , , <*fs/*>, , and references are * all in this boat, as well as others from package/base installation * (, etc.), if installed. Terry, you have absolutely no idea what you're talking about. It's amazing how you could miss every single one of the discussions on this topic in -current, -stable, -hackers and -committers in the past few months. Satoshi (the proud author of the "new world" patch) From owner-freebsd-current Thu Sep 18 23:43:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18277 for current-outgoing; Thu, 18 Sep 1997 23:43:31 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (ala-ca26-26.ix.netcom.com [207.93.42.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18272 for ; Thu, 18 Sep 1997 23:43:27 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.7/8.6.9) id XAA10791; Thu, 18 Sep 1997 23:43:20 -0700 (PDT) Date: Thu, 18 Sep 1997 23:43:20 -0700 (PDT) Message-Id: <199709190643.XAA10791@silvia.HIP.Berkeley.EDU> To: gurney_j@resnet.uoregon.edu CC: dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG In-reply-to: <19970918213446.00164@hydrogen.nike.efn.org> (message from John-Mark Gurney on Thu, 18 Sep 1997 21:34:46 -0700) Subject: Re: Yet Another bug in src/Makefile From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * why should it remove /usr/include?? /usr/include is not used for the * building of the resulting binaries install.. why not do a rm -rf / * if you want to clean out the area your installing to... :) * * of course there is good argument that the installed to area should * be clean to prevent old files from contaminating a setup... but * if we start to clean out /usr/include, we should also do /{bin,sbin} * /usr/{bin,share,sbin,lib,libexec} and any others that get installed... I agree with you, but the comments at the top of src/Makefile say otherwise. Should we just nuke the CLOBBER option entirely, or change the rules so it will actually delete /usr/include/*? Satoshi From owner-freebsd-current Thu Sep 18 23:47:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18474 for current-outgoing; Thu, 18 Sep 1997 23:47:31 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18464; Thu, 18 Sep 1997 23:47:24 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA20281; Thu, 18 Sep 1997 23:39:22 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd020279; Fri Sep 19 06:39:17 1997 Date: Thu, 18 Sep 1997 23:38:33 -0700 (PDT) From: Julian Elischer To: Nate Williams cc: "John S. Dyson" , Mikael Karpberg , dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709190518.XAA16454@rocky.mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk All the processes running the threads need to be able to see all the stacks because the threads can migrate between the processes. Remember, we are trying to emulate threads running in a single address space/process, so we need to share ALL of the address space.. On Thu, 18 Sep 1997, Nate Williams wrote: > > We are actually doing a pure memory sharing operation. We will be sharing > > everything, plan 9 doesn't appear to share the stack. In order to support > > pthreads, (and most thread schemes that I have seen), it is best to allow > > full access to all of the thread stacks. > > Forgive me for being naive, but in all of my experiences with threads > (not much, but lots lately with Java), it seems that sharing the stack > is asking for nothing but trouble. If you need to share memory, > allocate a 'global' shared memory bank that everyone can use, and use > it. > > From where I stand, sharing thread's stacks buys you nothing but > problems worse than the malloc/free problems we're talking about. :( > > (I've got enough problems with the stupid race conditions with AWT in > Java.) > > > > Nate > From owner-freebsd-current Thu Sep 18 23:59:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA19440 for current-outgoing; Thu, 18 Sep 1997 23:59:59 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA19433 for ; Thu, 18 Sep 1997 23:59:54 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA01884; Thu, 18 Sep 1997 23:59:49 -0700 (PDT) Message-ID: <19970918235949.11133@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 23:59:49 -0700 From: John-Mark Gurney To: Satoshi Asami Cc: dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG Subject: Re: Yet Another bug in src/Makefile References: <19970918213446.00164@hydrogen.nike.efn.org> <199709190643.XAA10791@silvia.HIP.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709190643.XAA10791@silvia.HIP.Berkeley.EDU>; from Satoshi Asami on Thu, Sep 18, 1997 at 11:43:20PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Satoshi Asami scribbled this message on Sep 18: > * why should it remove /usr/include?? /usr/include is not used for the > * building of the resulting binaries install.. why not do a rm -rf / > * if you want to clean out the area your installing to... :) > * > * of course there is good argument that the installed to area should > * be clean to prevent old files from contaminating a setup... but > * if we start to clean out /usr/include, we should also do /{bin,sbin} > * /usr/{bin,share,sbin,lib,libexec} and any others that get installed... > > I agree with you, but the comments at the top of src/Makefile say > otherwise. Should we just nuke the CLOBBER option entirely, or change > the rules so it will actually delete /usr/include/*? how about moving CLOBBER into the install target of src/include/Makefile, then it will work at the proper level... and will work properly (with DESTDIR="") when install runs in the inclues dir... and probably should rename it to CLOBBERINCLUDES :) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Fri Sep 19 00:39:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21754 for current-outgoing; Fri, 19 Sep 1997 00:39:59 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA21749; Fri, 19 Sep 1997 00:39:55 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA20321; Fri, 19 Sep 1997 09:39:52 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA12668; Fri, 19 Sep 1997 09:32:36 +0200 (MET DST) Message-ID: <19970919093236.ZY41455@uriah.heep.sax.de> Date: Fri, 19 Sep 1997 09:32:36 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Cc: Shimon@i-Connect.Net (Simon Shapiro), julian@FreeBSD.ORG Subject: Re: Make Release - Is there anything I can do to help? References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Sep 18, 1997 21:21:55 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > ===> share/timedef/data > for l in da_DK.ISO_8859-1 de_AT.ISO_8859-1 de_DE.ISO_8859-1 > en_GB.ISO_8859-1 en_US.ISO_8859-1 fr_FR.ISO_8859-1 hr_HR.ISO_8859-2 > is_IS.ISO_8859-1 ja_JP.SJIS it_IT.ISO_8859-1 ko_KR.EUC > no_NO.ISO_8859-1 pt_PT.ISO_8859-1 ru_SU.CP866 ru_SU.KOI8-R; do > install -c -m 644 -o bin -g bin $l.out > /Targets/3.0-970918-SNAP/usr/share/locale/$l/LC_TIME; done > install: ja_JP.SJIS.out: No such file or directory > *** Error code 71 Looks like Julian forgot to commit the related mtree file change. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Sep 19 01:12:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA23857 for current-outgoing; Fri, 19 Sep 1997 01:12:54 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA23851 for ; Fri, 19 Sep 1997 01:12:48 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id RAA07637; Fri, 19 Sep 1997 17:59:33 +1000 Date: Fri, 19 Sep 1997 17:59:33 +1000 From: Bruce Evans Message-Id: <199709190759.RAA07637@godzilla.zeta.org.au> To: asami@cs.berkeley.edu, gurney_j@resnet.uoregon.edu Subject: Re: Yet Another bug in src/Makefile Cc: dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > * of course there is good argument that the installed to area should > * be clean to prevent old files from contaminating a setup... but > * if we start to clean out /usr/include, we should also do /{bin,sbin} > * /usr/{bin,share,sbin,lib,libexec} and any others that get installed... > >I agree with you, but the comments at the top of src/Makefile say >otherwise. I agree too. Perhaps the mtree database (bin.mtree in releases) provides enough information to clean up standard binary directories, and packages should use an mtree database instead of a home made format. >Should we just nuke the CLOBBER option entirely, or change >the rules so it will actually delete /usr/include/*? Don't nuke it. It works as intended for `make includes' run separately from `make world'. (`make includes' itself doesn't run quite as intended. It is missing a few directories in 2.2 and has some problems with libss in all versions. Using CLOBBER with `make includes' in 2.2 ensures a few missing includes unless `make install' is run later to install everything :-).) Bruce From owner-freebsd-current Fri Sep 19 04:29:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA05138 for current-outgoing; Fri, 19 Sep 1997 04:29:56 -0700 (PDT) Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA05125 for ; Fri, 19 Sep 1997 04:29:53 -0700 (PDT) Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 03256517.003F8FD4 ; Fri, 19 Sep 1997 08:34:15 -0300 X-Lotus-FromDomain: VOGA From: "Daniel Sobral" To: freebsd-current@freebsd.org Message-ID: <03256517.003F1E7B.00@papagaio.voga.com.br> Date: Fri, 19 Sep 1997 08:30:43 -0300 Subject: Re: XFree on current.freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > You should use the extract (come with XF331) to install the XFree86-3.3.1. That's beside the point. Sysinstall ought to be able to install XFree, that's the point. And, yesterday, it wasn't. From owner-freebsd-current Fri Sep 19 05:18:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA07478 for current-outgoing; Fri, 19 Sep 1997 05:18:16 -0700 (PDT) Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA07472 for ; Fri, 19 Sep 1997 05:18:13 -0700 (PDT) Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 03256517.004400CD ; Fri, 19 Sep 1997 09:22:46 -0300 X-Lotus-FromDomain: VOGA From: "Daniel Sobral" To: freebsd-current@freebsd.org Message-ID: <03256517.004392AB.00@papagaio.voga.com.br> Date: Fri, 19 Sep 1997 09:19:17 -0300 Subject: Bug? Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have noticed a very strange behavior with sysinstall. Whenever I select a custom distribution of XFree to be installed, 2.1 compatibility gets selected as well! Is this a bug or just an un(clearly)documented feature? From owner-freebsd-current Fri Sep 19 06:32:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA11869 for current-outgoing; Fri, 19 Sep 1997 06:32:01 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA11851 for ; Fri, 19 Sep 1997 06:31:57 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id GAA24006; Fri, 19 Sep 1997 06:32:05 -0700 (PDT) To: "Daniel Sobral" cc: freebsd-current@FreeBSD.ORG Subject: Re: Bug? In-reply-to: Your message of "Fri, 19 Sep 1997 09:19:17 -0300." <03256517.004392AB.00@papagaio.voga.com.br> Date: Fri, 19 Sep 1997 06:32:05 -0700 Message-ID: <24003.874675925@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have noticed a very strange behavior with sysinstall. Whenever I select a > custom distribution of XFree to be installed, 2.1 compatibility gets > selected as well! Is this a bug or just an un(clearly)documented feature? Undocumented feature. Jordan From owner-freebsd-current Fri Sep 19 07:18:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14594 for current-outgoing; Fri, 19 Sep 1997 07:18:09 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14587 for ; Fri, 19 Sep 1997 07:18:03 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id KAA28139; Fri, 19 Sep 1997 10:17:57 -0400 (EDT) Date: Fri, 19 Sep 1997 10:17:57 -0400 (EDT) From: Garrett Wollman Message-Id: <199709191417.KAA28139@khavrinen.lcs.mit.edu> To: "John S. Dyson" Cc: current@FreeBSD.ORG Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709190119.UAA00556@dyson.iquest.net> References: <199709190012.CAA11932@ocean.campus.luth.se> <199709190119.UAA00556@dyson.iquest.net> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > We are actually doing a pure memory sharing operation. We will be sharing > everything, plan 9 doesn't appear to share the stack. In order to support > pthreads, (and most thread schemes that I have seen), it is best to allow > full access to all of the thread stacks. The 'full sharing' scheme is very > fast. We ought to emulate SGI's sproc(2) system call as well, which does essentially the same thing. It has the useful feature that it takes as an argument the address of a function to call, and does all the stack creation magic internally before calling same. So, the inner loop of a program I wrote a long time ago on an SGI looks like this: void do_sproc(volatile int *manyRows[]) { int pids[MAXPROCS]; struct info infos[MAXPROCS]; int i; double aval = curA; for(i=0; i < nprocs - 1; i++,aval -= aincr) { infos[i].row = manyRows[i]; infos[i].curA = aval; pids[i] = sproc(doit,PR_SALL,(void *)&infos[i]); } real_doit(aval,manyRows[i]); /* * We know we started (nprocs - 1) kids, so we wait for (nprocs - 1) kids * to die. */ for(i=0; i < nprocs - 1; i++) { (void)wait((int *)0); } } The prototype is: int sproc(void (*func)(void *arg), unsigned what, ... /* void */); int sprocsp(void (*func)(void *arg, size_t stklen), unsigned what, void *arg, caddr_t sp /* 0 == auto */, size_t maxstklen); There is also a related function: int prctl(pid_t pid, unsigned what, ...); which manages some process-related behavior. The particularly interesting values of `what' for sproc are: PR_SADDR (== RFMEM) PR_SFD (== RFFDG) PR_SDIR (== like RFFDG but for curdir/rootdir) PR_SUMASK (== like RFFDG but for umask) PR_SULIMIT (== like RFFDG but for resource limits) PR_SID (== like RFFDG but for credentials) PR_SALL (== all of the above) There are additionally a couple of of flags, PR_BLOCK (used to provide vfork-like behavior, if I read the man page right) and PR_NOLIBC (which disables the C library thread support for the new child). The prctl(2) system call has a couple of potentially interesting options and a lot of boring ones. The potentially interesting ones are PR_SETEXITSIG (which selects either standard POSIX exit(2) behavior, or causes each share to get a specified signal if the named process exits), and PR_TERMCHILD (which causes children of the caller to receive a SIGHUP if the parent exits). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Fri Sep 19 07:41:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA15862 for current-outgoing; Fri, 19 Sep 1997 07:41:57 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA15857 for ; Fri, 19 Sep 1997 07:41:53 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id HAA05896; Fri, 19 Sep 1997 07:41:17 -0700 (MST) From: Terry Lambert Message-Id: <199709191441.HAA05896@usr07.primenet.com> Subject: Re: Yet Another bug in src/Makefile To: asami@cs.berkeley.edu (Satoshi Asami) Date: Fri, 19 Sep 1997 14:41:17 +0000 (GMT) Cc: tlambert@primenet.com, gurney_j@resnet.uoregon.edu, dima@tejblum.dnttm.rssi.ru, freebsd-current@freebsd.org In-Reply-To: <199709190641.XAA10786@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Sep 18, 97 11:41:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * There are other builds which also reference out of the build tree; > * anything which references or , in particular, > * references /usr/include. A reference to can't be > * resolved without /usr/include/ since it refers to the postinstalled > * headers from /usr/src/sys/i386/include/ into /usr/include/machine/. > * The , , <*fs/*>, , and references are > * all in this boat, as well as others from package/base installation > * (, etc.), if installed. > > Terry, you have absolutely no idea what you're talking about. It's > amazing how you could miss every single one of the discussions on this > topic in -current, -stable, -hackers and -committers in the past few > months. I am not talking about ports. Feel free to tell me how, other than making changes to the default arrangement of files, I can build multiple kernel environments. I tend to build a lot of kernel environments, and that means rebuilding libkvm, w, ps, who, netstat, arp, ifconfig, mount, mount_*, and a grundle of other things which depend on kernel "interfaces" exported through /dev/kmem. In order to do this, I have to change the way the build works locally, starting with a lot of symbolic links (which I documented in the discussion you are referencing), but not only symbolic links. I do not *want* to do a "build world" in order to do this. I am *only* changing my kernel, and I want to *only* change things that depend on my kernel (and there are too many of those to suit me, too). I do not want to change out the majority of my build environment for standard programs which are not affected by kernel changes. I sure as hell do not want to rebuild "more", or even do a make install in /usr/src/include. I want to buildd the *absolute* minimum for the delta I am playing with -- and not *one file* more or less than that. I find it really surprising that you can in any way believe a reference to a file can be in any way satisfied by the contents of /usr/src/sys/i386/include, save for me doing a rebuild of my /usr/include directory. Even if I were to do a "-I/usr/src/sys/i386/include" on the compilation command line, it would do me no good: there is no subdirectory named "machine" where the *right* include files may be found. Now you may argue, as I did, that you can create a symlink tree in /usr/include in order to deal with this, one of which would be: ln -s /sys/i386/include /usr/include/machine However, this fails to account for cross-build environments for things like the DEC Alpha and the HP345, which though they do not yet run a pure FreeBSD kernel, can nevertheless be cross-built on a suitably munged-away-from-the-supposedly-correct-defaults FreeBSD system. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 08:15:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17714 for current-outgoing; Fri, 19 Sep 1997 08:15:28 -0700 (PDT) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17708 for ; Fri, 19 Sep 1997 08:15:26 -0700 (PDT) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id JAA04986; Fri, 19 Sep 1997 09:15:04 -0600 (MDT) From: Kenneth Merry Message-Id: <199709191515.JAA04986@pluto.plutotech.com> Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709191417.KAA28139@khavrinen.lcs.mit.edu> from Garrett Wollman at "Sep 19, 97 10:17:57 am" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Fri, 19 Sep 1997 09:15:04 -0600 (MDT) Cc: toor@dyson.iquest.net, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman wrote... > < said: > > > We are actually doing a pure memory sharing operation. We will be sharing > > everything, plan 9 doesn't appear to share the stack. In order to support > > pthreads, (and most thread schemes that I have seen), it is best to allow > > full access to all of the thread stacks. The 'full sharing' scheme is very > > fast. > > We ought to emulate SGI's sproc(2) system call as well, which does > essentially the same thing. It has the useful feature that it takes > as an argument the address of a function to call, and does all the > stack creation magic internally before calling same. So, the inner > loop of a program I wrote a long time ago on an SGI looks like this: I agree with Garrett... I've done coding under IRIX, and sproc() definitely is a handy system call. The ability to specify a function pointer for the main routine of the thread is especially nice. Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-current Fri Sep 19 09:05:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20959 for current-outgoing; Fri, 19 Sep 1997 09:05:34 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20941; Fri, 19 Sep 1997 09:05:20 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id KAA17322; Fri, 19 Sep 1997 10:04:19 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA19167; Fri, 19 Sep 1997 10:04:17 -0600 (MDT) Date: Fri, 19 Sep 1997 10:04:17 -0600 (MDT) Message-Id: <199709191604.KAA19167@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dyson@freebsd.org Cc: nate@mt.sri.com (Nate Williams), karpen@ocean.campus.luth.se, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709190610.BAA00804@dyson.iquest.net> References: <199709190518.XAA16454@rocky.mt.sri.com> <199709190610.BAA00804@dyson.iquest.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John S. Dyson writes: [ New shared everything call being added ] I wrote: > > it seems that sharing the stack > > is asking for nothing but trouble. John responds: > I don't disagree with what you are saying, however, we need to be able > to have full access to the stacks in every thread. Of course, we would > be wise to create guard page(s) between stacks. Why do we need to have access to the stack? Is it *only* for the thread 'kernel' that runs in user-land that does the 'context-switching' between the threads, or will each thread have access to another thread's stack. I can definitely see the need for the former, but *NOT* the latter. The great strength about Unix is that another 'process' can'tt muck with another 'processes' easily, and with threads I'd like to see this taken to whatever extreme as possible given the constraints of implementation. Nate From owner-freebsd-current Fri Sep 19 09:27:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22426 for current-outgoing; Fri, 19 Sep 1997 09:27:31 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22420 for ; Fri, 19 Sep 1997 09:27:23 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id JAA10533; Fri, 19 Sep 1997 09:26:43 -0700 (MST) From: Terry Lambert Message-Id: <199709191626.JAA10533@usr07.primenet.com> Subject: Re: Yet Another bug in src/Makefile To: gurney_j@resnet.uoregon.edu Date: Fri, 19 Sep 1997 16:26:42 +0000 (GMT) Cc: tlambert@primenet.com, dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG In-Reply-To: <19970918222829.18729@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 18, 97 10:28:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This is false. The build for libkvm references outside the source tree > > (specifically, an absolute reference via -I). This was why I hacked > > the symbolic links for multiple kernel tree builds (earlier posting). > > are you sure... my tree reads: > LIB= kvm > CFLAGS+=-DLIBC_SCCS -I${.CURDIR}/../../sys > > last I checked, this isn't out of the src tree... Consider: # rm /sys # ln -s /sys /usr/src/sys # mv /usr/src /usr/src-release # mkdir /usr/src # cd /usr/src-release # sh # for i in * > do > ln -s /usr/src-release/$i /usr/src/$i > done # exit # cd /usr/src # rm sys # ln -s /b/src-current/sys sys Now build libkvm. Note that "-I${.CURDIR}/../../sys" refers to the directory: /usr/src-release/sys And not the correct directory: /b/src-current/sys ...in other words, the libkvm is always built relative to the location of the libkvm source files, rather than the location of the build source files. Changing "-I${.CURDIR}/../../sys" to "-I/sys" fixes this problem, but in a sort of not very bright way. It resolves the local build issues, but not the architecture variant issues. Before you jump in here, note that I do not *want* multiple copies of the libkvm sources; I want to apply the same libkvm sources to build from seperate sets of header files. The only reason I need to do this is because of the idiotic historical precedent of using /dev/kmem as if it were a valid interface mechanism (it's not). You have dealt with the "cross build world in a completely seperate source tree" issue. This is not an issue I'm interested in having dealt with: I'm not interested in maintaining multiple completely seperate source trees with mostly identical code. The only good reason for encouraging *that* arrangement would be if I were a disk manufacturer. My cross build issues are typically faced in an NFS mounted source tree on another architecture, in any case, since the GNU tools are very poorly acquanted with the idea of cross-build environments. Witness the use of internal cpp instead of external cpp for preprocessing, and witness the hard-coded strings like "-Di386", "-Acpu(i386)", and "-Amachine(i386)" in the external cpp. Also the lack of a unified "cc" front-end that accepts seperate targets on the basis of processor rather than processor and architecture (ie: the old NCR "-target" option vs. the GCC "-b "). Witness also the compiled in "-D__FreeBSD__=3" and "-Asystem(FreeBSD)"; the first makes it impossible to cross build a version 3 FreeBSD on a version 2 FreeBSD system, mostly because of if_de.c's used of __FreeBSD__ version testing. Both make it difficult to build Net/OpenBSD on a FreeBSD box, without an entire duplication of GNU tools for the "different" target -- which differs only in these values. Furthermore, the version identification crap being compiled in means that for cross-support of older FreeBSD systems, I either have to hack up the default Makefiles to undefine the intrinsics and redefine them to the proper values for the target, or I must run the most recent version on my buuld machine. This means I can use my fastest machine for a stable platform, or I can use it for -current, but I can't use it to build -current if I use it for a stable platform. > > There are other builds which also reference out of the build tree; > > anything which references or , in particular, > > references /usr/include. A reference to can't be > > can you show me these mythical references to /usr/include?? I reciently > committed a bunch of changes to fix improper use of -I/sys... This does nothing for "#include ", for example, since there is not a "machine" subdirectory of "/sys". Or of the source tree dependent and symbolic link ignorant version, "${.CURDIR}/../../sys". Try the following: # cd /usr/include/sys # grep "#include > resolved without /usr/include/ since it refers to the postinstalled > > headers from /usr/src/sys/i386/include/ into /usr/include/machine/. > > The , , <*fs/*>, , and references are > > all in this boat, as well as others from package/base installation > > (, etc.), if installed. > > ok.. then why does my build tree > /usr/obj/a/home/johng/FreeBSD-checkout/current/src/tmp/usr/include, > include ALL of the things you listed above?? Because you foolishly waste time rebuilding the entire world, instead of just the pieces impacted by the kernel changes you are currently working on? The fact that you have a temporary copy of an include directory is an indicator that not all is right with the world. You may have resolved the cross-build issues locally, but you have not resolved the local modification build issues at the same time. Part of this is resolvable with: # cd /usr/include # rm -rf machine # ln -s /sys/i386/include machine # rm -rf sys # ln -s /sys/sys sys ...which presumes that you put the symbolic links in /usr/src back to /usr/src/release before building non-kernel pieces. But this can't resolve the /usr/include/vm stuff, for example, because /sys/vm is unsuitable for linking, containing, as it does, C sources as well as header files. Most of the net code is the same. The rpc headers are generated, and provide other, colorful versioning issues that need to be dealt with. The FS headers are another issue, since they are used in the mount code, and included from an installed location instead of a source location. They, too, are unsuitable for linking. Etc.. Even the "ln -s /sys/i386/include machine" link is not very satisfactory because of the architectural dependence it engenders. In order to have a working cross environment, you have to toggle the "i386" piece on a case-by-case-basis. At best, I can have an enviroment toggling function which resets a large number of links, and does not properly address issues of kernel changes to much of the network code, and exposes the vm C sources in an undesirable way. > > > of course there is good argument that the installed to area should > > > be clean to prevent old files from contaminating a setup... but > > > if we start to clean out /usr/include, we should also do /{bin,sbin} > > > /usr/{bin,share,sbin,lib,libexec} and any others that get installed... > > > > The argument is that the installed area should never be used for > > system build, since you may be building a cross-environment. > > umm... this isn't the case Terry... when was the last time you built > world on a -current machine w/o your local patches?? I don't build world. That's one of my points, isn't it? If I am hacking the proc struct, I don't *need* to rebuild the world. Nor should I be required to do so in order to hack the proc struct. I should only be required to rebuild those things (and *ONLY* those things) which are affected by changes to the proc struct. Waiting (at best case) several hours to see if changes are correct is a *HUGE* bottleneck, and not one I'm willing to accept! > > You either need to build the machine link as part of the build, or you > > need variant symlinks (whole other kettle of fish) to deal with the > > architecture variant headers for cross-builds. > > see above... it's already happened... As I said above. You have dealt with the "cross build world in a completely seperate source tree" issue. This is not a very globally useful issue; at least it is not very useful for me. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 11:32:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29248 for current-outgoing; Fri, 19 Sep 1997 11:32:14 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29241 for ; Fri, 19 Sep 1997 11:32:10 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id LAA11177; Fri, 19 Sep 1997 11:30:29 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199709191830.LAA11177@GndRsh.aac.dev.com> Subject: Re: Yet Another bug in src/Makefile In-Reply-To: <19970918213446.00164@hydrogen.nike.efn.org> from John-Mark Gurney at "Sep 18, 97 09:34:46 pm" To: gurney_j@resnet.uoregon.edu Date: Fri, 19 Sep 1997 11:30:29 -0700 (PDT) Cc: dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Dmitrij Tejblum scribbled this message on Sep 19: > > 'make -DCLOBBER world' will not remove /usr/include. It will remove > > /usr/obj/usr/src/tmp/usr/include instead... > > why should it remove /usr/include?? /usr/include is not used for the Because the original Author of -DCLOBBER specifically wrote it to destroy the /usr/include tree to make sure that no OLD cruft was left behind in there. > building of the resulting binaries install.. why not do a rm -rf / > if you want to clean out the area your installing to... :) The installworld target of src/Makefile now needs the following added to it: .if defined(CLOBBER) rm -rf ${DESTDIR}/usr/include .endif > of course there is good argument that the installed to area should > be clean to prevent old files from contaminating a setup... but > if we start to clean out /usr/include, we should also do /{bin,sbin} > /usr/{bin,share,sbin,lib,libexec} and any others that get installed... > > -- > John-Mark Gurney Modem/FAX: +1 541 683 6954 > Cu Networking > > Live in Peace, destroy Micro$oft, support free software, run FreeBSD > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-current Fri Sep 19 11:38:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29612 for current-outgoing; Fri, 19 Sep 1997 11:38:35 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29605 for ; Fri, 19 Sep 1997 11:38:31 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id LAA11195; Fri, 19 Sep 1997 11:36:31 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199709191836.LAA11195@GndRsh.aac.dev.com> Subject: Re: Yet Another bug in src/Makefile In-Reply-To: <199709190641.XAA10786@silvia.HIP.Berkeley.EDU> from Satoshi Asami at "Sep 18, 97 11:41:06 pm" To: asami@cs.berkeley.edu (Satoshi Asami) Date: Fri, 19 Sep 1997 11:36:31 -0700 (PDT) Cc: tlambert@primenet.com, gurney_j@resnet.uoregon.edu, dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ... > Satoshi (the proud author of the "new world" patch) Rod (the not so happy author of the orignal ``world'' target dating back to 386BSD Patchkit days) about the number of functions broken in the ``new world'' patch :-(. Please add: .if defined(CLOBBER) rm -r ${DESTDIR}/usr/include .endif to the installworld: target. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-current Fri Sep 19 11:39:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29647 for current-outgoing; Fri, 19 Sep 1997 11:39:09 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29641 for ; Fri, 19 Sep 1997 11:39:07 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id LAA03586; Fri, 19 Sep 1997 11:38:48 -0700 (PDT) Message-Id: <199709191838.LAA03586@rah.star-gate.com> To: Simon Shapiro cc: freebsd-current@FreeBSD.ORG Subject: Re: Make Release - Is there anything I can do to help? In-reply-to: Your message of "Thu, 18 Sep 1997 21:21:55 PDT." Date: Fri, 19 Sep 1997 11:38:48 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Relax, we are having problems right now and I don't think that this is our typical status quo. Several binaries have been affected like rpcgen if I compile it statically it works okay the same goes with telnetd . I have cvsup the system several times this week and my last one was last nite. Amancio P.S.: Oridnarily, I wait for the build procedure to be flush out however I was forced to update my system due to select->poll checking >From The Desk Of Simon Shapiro : > I am really confused. On the 27th of August we had a perfect build. and we > made a release. Now, things that were NOT broken then, are borken now. > Is there anything I can do to help? What is the review process for > checking in changes? Maybe I can help by testing certain things to make > sure they, at least compile? I have several machines here and will be more > than happy to help in any way I can. > > I cannot comment much on the last few problems I reported as now I have a > new, earlier breakage. the only comment is that sgmlfmt was NOT missing > from my system, but is missing from the release build area, and thus > reported missing. I did install all the pieces it was recommended to > install. > > Anyway, here is where it fails tonight: > > ===> share/timedef/data > for l in da_DK.ISO_8859-1 de_AT.ISO_8859-1 de_DE.ISO_8859-1 > en_GB.ISO_8859-1 en_US.ISO_8859-1 fr_FR.ISO_8859-1 hr_HR.ISO_8859-2 > is_IS.ISO_8859-1 ja_JP.SJIS it_IT.ISO_8859-1 ko_KR.EUC > no_NO.ISO_8859-1 pt_PT.ISO_8859-1 ru_SU.CP866 ru_SU.KOI8-R; do > install -c -m 644 -o bin -g bin $l.out > /Targets/3.0-970918-SNAP/usr/share/locale/$l/LC_TIME; done > install: ja_JP.SJIS.out: No such file or directory > *** Error code 71 > > The source files EXIST, in my CVS tree, in my checkout are and in the > release build area. The target is NOT. again, there has been no change in > our procedure, short of doing a make installworld yesterday > at 0830, after a successfull make buildworld the night before. > > I am being so defensive, as half the responses I get to these postings are > sarcastic comments about my wits. I am old and slow, but belive that 5 = 5 > and never 4 (meaning, if I followed a procedure on Wednesday and changed > nothing in it, it should also run on Friday. > > Thanx, and please let me know how I can help. > > --- > > > Sincerely Yours, (Sent on 18-Sep-97, 21:03:39 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Fri Sep 19 11:40:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29788 for current-outgoing; Fri, 19 Sep 1997 11:40:22 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29783 for ; Fri, 19 Sep 1997 11:40:18 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id LAA11204; Fri, 19 Sep 1997 11:38:36 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199709191838.LAA11204@GndRsh.aac.dev.com> Subject: Re: Yet Another bug in src/Makefile In-Reply-To: <199709190643.XAA10791@silvia.HIP.Berkeley.EDU> from Satoshi Asami at "Sep 18, 97 11:43:20 pm" To: asami@cs.berkeley.edu (Satoshi Asami) Date: Fri, 19 Sep 1997 11:38:36 -0700 (PDT) Cc: gurney_j@resnet.uoregon.edu, dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > * why should it remove /usr/include?? /usr/include is not used for the > * building of the resulting binaries install.. why not do a rm -rf / > * if you want to clean out the area your installing to... :) > * > * of course there is good argument that the installed to area should > * be clean to prevent old files from contaminating a setup... but > * if we start to clean out /usr/include, we should also do /{bin,sbin} > * /usr/{bin,share,sbin,lib,libexec} and any others that get installed... > > I agree with you, but the comments at the top of src/Makefile say > otherwise. Should we just nuke the CLOBBER option entirely, or change > the rules so it will actually delete /usr/include/*? > CHANGE THE RULES. This was done to remove old cruft that the current source tree knows nothing about from /usr/include. The only way to insure that is to remove it all and install into a clean tree. For example if my FreeBSD 1.1 had some header installed in /usr/include that is not even known to FreeBSD 2.2 it would get left behind now by a make -DCLOBBER world. The whole reason that CLOBBER existed was to make sure that /usr/lib and /usr/include don't have old stuff left around in them. See other mail for added section to installworld: target. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-current Fri Sep 19 11:48:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00386 for current-outgoing; Fri, 19 Sep 1997 11:48:52 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00373; Fri, 19 Sep 1997 11:48:34 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id NAA02645; Fri, 19 Sep 1997 13:48:22 -0500 (EST) From: "John S. Dyson" Message-Id: <199709191848.NAA02645@dyson.iquest.net> Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709191604.KAA19167@rocky.mt.sri.com> from Nate Williams at "Sep 19, 97 10:04:17 am" To: nate@mt.sri.com (Nate Williams) Date: Fri, 19 Sep 1997 13:48:22 -0500 (EST) Cc: dyson@FreeBSD.ORG, nate@mt.sri.com, karpen@ocean.campus.luth.se, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams said: > John S. Dyson writes: > [ New shared everything call being added ] > > I wrote: > > > it seems that sharing the stack > > > is asking for nothing but trouble. > > John responds: > > > I don't disagree with what you are saying, however, we need to be able > > to have full access to the stacks in every thread. Of course, we would > > be wise to create guard page(s) between stacks. > > Why do we need to have access to the stack? Is it *only* for the thread > 'kernel' that runs in user-land that does the 'context-switching' > between the threads, or will each thread have access to another thread's > stack. I can definitely see the need for the former, but *NOT* the > latter. > Actually, both need it. Otherwise, we will be incompatible with the rest of the world. > > The great strength about Unix is that another 'process' can'tt muck with > another 'processes' easily, and with threads I'd like to see this taken > to whatever extreme as possible given the constraints of implementation. > The threads are a different issue. I don't disagree with the threads stacks being isolated for philosophical reasons -- however it is just wrong from a compatibility standpoint. If we had a type of thread that had isolated stacks, it would be nice, but that is a different exercise. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Fri Sep 19 12:56:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA03927 for current-outgoing; Fri, 19 Sep 1997 12:56:53 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA03915; Fri, 19 Sep 1997 12:56:44 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA18866; Fri, 19 Sep 1997 13:56:25 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA20377; Fri, 19 Sep 1997 13:56:23 -0600 (MDT) Date: Fri, 19 Sep 1997 13:56:23 -0600 (MDT) Message-Id: <199709191956.NAA20377@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "John S. Dyson" Cc: nate@mt.sri.com (Nate Williams), dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709191848.NAA02645@dyson.iquest.net> References: <199709191604.KAA19167@rocky.mt.sri.com> <199709191848.NAA02645@dyson.iquest.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John S. Dyson writes: > Nate Williams said: > > John S. Dyson writes: > > [ New shared everything call being added ] > > > > I wrote: > > > > it seems that sharing the stack > > > > is asking for nothing but trouble. > > > > John responds: > > > > > I don't disagree with what you are saying, however, we need to be able > > > to have full access to the stacks in every thread. Of course, we would > > > be wise to create guard page(s) between stacks. > > > > Why do we need to have access to the stack? Is it *only* for the thread > > 'kernel' that runs in user-land that does the 'context-switching' > > between the threads, or will each thread have access to another thread's > > stack. I can definitely see the need for the former, but *NOT* the > > latter. > > Actually, both need it. Otherwise, we will be incompatible with the rest > of the world. Sean Fagan and I have been having an off-line discussion, and I know understand the reasons for doing it this way. However, although I understand the reasons, I can also see where doing so makes it *much* more difficult to write 'correct' threaded programs, where I define correct as the ability to run w/out stepping on yourself in *all* cases. Note, I said difficult, not impossible. I now understand many of the design decisions behind why Java does thing the way that it does. (Not too say that it's the best solution, but I do think they did a *lot* of things right.) > > The great strength about Unix is that another 'process' can'tt muck with > > another 'processes' easily, and with threads I'd like to see this taken > > to whatever extreme as possible given the constraints of implementation. > > The threads are a different issue. I don't disagree with the threads > stacks being isolated for philosophical reasons -- however it is just > wrong from a compatibility standpoint. If we had a type of thread > that had isolated stacks, it would be nice, but that is a different > exercise. One that would be worthwhile, IMHO. :) :) :) Nate From owner-freebsd-current Fri Sep 19 13:28:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA05915 for current-outgoing; Fri, 19 Sep 1997 13:28:08 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA05896; Fri, 19 Sep 1997 13:27:58 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id NAA01303; Fri, 19 Sep 1997 13:27:46 -0700 (MST) From: Terry Lambert Message-Id: <199709192027.NAA01303@usr03.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: toor@dyson.iquest.net (John S. Dyson) Date: Fri, 19 Sep 1997 20:27:45 +0000 (GMT) Cc: nate@mt.sri.com, dyson@FreeBSD.ORG, karpen@ocean.campus.luth.se, current@FreeBSD.ORG In-Reply-To: <199709191848.NAA02645@dyson.iquest.net> from "John S. Dyson" at Sep 19, 97 01:48:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The great strength about Unix is that another 'process' can'tt muck with > > another 'processes' easily, and with threads I'd like to see this taken > > to whatever extreme as possible given the constraints of implementation. > > The threads are a different issue. I don't disagree with the threads > stacks being isolated for philosophical reasons -- however it is just > wrong from a compatibility standpoint. Exactly so. If you want this protection, implement using processes instead of threads. The problem is that I may pass auto variables between threads: /* one of many threads with work to be done*/ thread1() { struct req my_request; my_request.x = ...; my_request.y = ...; do_requeust( &my_request); ... } /* block calling thread until request completed*/ do_request( struct req *preq) { ... enqueue( preq); ... while( preq->status != REQ_COMPLETE) YIELD; } /* lives only to service requests*/ thread2() { struct req *preq; for(;;) { /* spin to get next work item*/ while( ( preq = dequeue()) == NULL) YIELD; /* service work item*/ ... /* mark work item completed*/ preq->status = REQ_COMPLETE; } } I might do this, for example, if my work items were DNS lookups, etc., which had to be accomplished serially, or with some maximum concurrency (say I start no more than 3 thread2's, and 10's of thread1's) because of load characteristics. In any case, if thread2 did not have access to thread1's stack, the first time it tried to dereference preq, one of two things would happen: 1) It would segfault because the page wasn't mapped for thread2 2) It would dereference data from thread2's stack or thread local storage instead of thread1's stack, because that's the only way a page would be mapped there in thread2's address space. Either of these is bad. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 13:32:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA05915 for current-outgoing; Fri, 19 Sep 1997 13:28:08 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA05896; Fri, 19 Sep 1997 13:27:58 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id NAA01303; Fri, 19 Sep 1997 13:27:46 -0700 (MST) From: Terry Lambert Message-Id: <199709192027.NAA01303@usr03.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: toor@dyson.iquest.net (John S. Dyson) Date: Fri, 19 Sep 1997 20:27:45 +0000 (GMT) Cc: nate@mt.sri.com, dyson@FreeBSD.ORG, karpen@ocean.campus.luth.se, current@FreeBSD.ORG In-Reply-To: <199709191848.NAA02645@dyson.iquest.net> from "John S. Dyson" at Sep 19, 97 01:48:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The great strength about Unix is that another 'process' can'tt muck with > > another 'processes' easily, and with threads I'd like to see this taken > > to whatever extreme as possible given the constraints of implementation. > > The threads are a different issue. I don't disagree with the threads > stacks being isolated for philosophical reasons -- however it is just > wrong from a compatibility standpoint. Exactly so. If you want this protection, implement using processes instead of threads. The problem is that I may pass auto variables between threads: /* one of many threads with work to be done*/ thread1() { struct req my_request; my_request.x = ...; my_request.y = ...; do_requeust( &my_request); ... } /* block calling thread until request completed*/ do_request( struct req *preq) { ... enqueue( preq); ... while( preq->status != REQ_COMPLETE) YIELD; } /* lives only to service requests*/ thread2() { struct req *preq; for(;;) { /* spin to get next work item*/ while( ( preq = dequeue()) == NULL) YIELD; /* service work item*/ ... /* mark work item completed*/ preq->status = REQ_COMPLETE; } } I might do this, for example, if my work items were DNS lookups, etc., which had to be accomplished serially, or with some maximum concurrency (say I start no more than 3 thread2's, and 10's of thread1's) because of load characteristics. In any case, if thread2 did not have access to thread1's stack, the first time it tried to dereference preq, one of two things would happen: 1) It would segfault because the page wasn't mapped for thread2 2) It would dereference data from thread2's stack or thread local storage instead of thread1's stack, because that's the only way a page would be mapped there in thread2's address space. Either of these is bad. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 14:04:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08580 for current-outgoing; Fri, 19 Sep 1997 14:04:50 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA08565; Fri, 19 Sep 1997 14:04:41 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id PAA19303; Fri, 19 Sep 1997 15:04:34 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA20740; Fri, 19 Sep 1997 15:04:29 -0600 (MDT) Date: Fri, 19 Sep 1997 15:04:29 -0600 (MDT) Message-Id: <199709192104.PAA20740@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: toor@dyson.iquest.net (John S. Dyson), nate@mt.sri.com, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709192027.NAA01303@usr03.primenet.com> References: <199709191848.NAA02645@dyson.iquest.net> <199709192027.NAA01303@usr03.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The problem is that I may pass auto variables between threads: Then you have problems. > /* one of many threads with work to be done*/ > thread1() > { > struct req my_request; > > my_request.x = ...; > my_request.y = ...; > > do_requeust( &my_request); > > ... > } > > /* block calling thread until request completed*/ > do_request( struct req *preq) > { > ... > enqueue( preq); > ... > while( preq->status != REQ_COMPLETE) > YIELD; > } > > > /* lives only to service requests*/ > thread2() > { > struct req *preq; > > for(;;) { > /* spin to get next work item*/ > while( ( preq = dequeue()) == NULL) > YIELD; > > /* service work item*/ > ... > > /* mark work item completed*/ > preq->status = REQ_COMPLETE; > } > } I would argue that this program has many problems, waiting to happen that could be partially avoided by not using the stack. But, as Sean already pointed out to me many times, "that's the way things work in C, and we need to be backwards compatible". Why not allocate your struct req from the heap, which avoids someone reading/writing bogus data on your stack, thus corrupting it. Then again, I guess you could argue that *IFF* your stack gets corrupted, you'll know you're over-writing memory a heck of a lot quicker. :) In any case, I'm convinced that it's necessary in order to fully support C-Threads. Nate From owner-freebsd-current Fri Sep 19 14:30:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10266 for current-outgoing; Fri, 19 Sep 1997 14:30:49 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10261; Fri, 19 Sep 1997 14:30:38 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA05946; Fri, 19 Sep 1997 14:30:18 -0700 (MST) From: Terry Lambert Message-Id: <199709192130.OAA05946@usr06.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: nate@mt.sri.com (Nate Williams) Date: Fri, 19 Sep 1997 21:30:17 +0000 (GMT) Cc: tlambert@primenet.com, toor@dyson.iquest.net, nate@mt.sri.com, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org In-Reply-To: <199709192104.PAA20740@rocky.mt.sri.com> from "Nate Williams" at Sep 19, 97 03:04:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The problem is that I may pass auto variables between threads: > > Then you have problems. Heh. But am I violating any principles? 8-). > I would argue that this program has many problems, waiting to happen > that could be partially avoided by not using the stack. But, as Sean > already pointed out to me many times, "that's the way things work in C, > and we need to be backwards compatible". Yep; "Intel: We put the 'backwards' in 'backwards compatible'". 8-). > Why not allocate your struct req from the heap, which avoids someone > reading/writing bogus data on your stack, thus corrupting it. Then > again, I guess you could argue that *IFF* your stack gets corrupted, > you'll know you're over-writing memory a heck of a lot quicker. :) Well, it's not really any better for a program to write bogus stuff on my heap. 8-). If we're assuming that the program is doing bogus stuff, then we've got to say that the results of running the program are undefined. > In any case, I'm convinced that it's necessary in order to fully support > C-Threads. Stacks in seperate address spaces are needed to fully support C-Threads? You can't just say interesting stuff like that, and then not tell us why! 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 14:45:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA11463 for current-outgoing; Fri, 19 Sep 1997 14:45:47 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA11456; Fri, 19 Sep 1997 14:45:37 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id PAA19620; Fri, 19 Sep 1997 15:45:21 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA20992; Fri, 19 Sep 1997 15:45:18 -0600 (MDT) Date: Fri, 19 Sep 1997 15:45:18 -0600 (MDT) Message-Id: <199709192145.PAA20992@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), toor@dyson.iquest.net, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709192130.OAA05946@usr06.primenet.com> References: <199709192104.PAA20740@rocky.mt.sri.com> <199709192130.OAA05946@usr06.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > In any case, I'm convinced that it's necessary in order to fully support > > C-Threads. > > Stacks in seperate address spaces are needed to fully support C-Threads? I'm convinced that you must *fully* share thread stacks in order to be backwards compatible for C-Threads. You don't *have* to do that, but then we're no longer backwards compatible. Nate From owner-freebsd-current Fri Sep 19 15:10:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA12669 for current-outgoing; Fri, 19 Sep 1997 15:10:25 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA12659 for ; Fri, 19 Sep 1997 15:10:20 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA08418; Fri, 19 Sep 1997 15:10:17 -0700 (MST) From: Terry Lambert Message-Id: <199709192210.PAA08418@usr06.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: nate@mt.sri.com (Nate Williams) Date: Fri, 19 Sep 1997 22:10:13 +0000 (GMT) Cc: current@FreeBSD.ORG In-Reply-To: <199709191956.NAA20377@rocky.mt.sri.com> from "Nate Williams" at Sep 19, 97 01:56:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm going to reorder this so I can ask something in context... > > The threads are a different issue. I don't disagree with the threads > > stacks being isolated for philosophical reasons -- however it is just > > wrong from a compatibility standpoint. If we had a type of thread > > that had isolated stacks, it would be nice, but that is a different > > exercise. > > One that would be worthwhile, IMHO. :) :) :) The idea of a seperate stack address space mapping for threads has one *major* benefit: the ability to auto-grow threads stacks without resorting to guard pages, statistical protection, and a signal handler that know a lot about sigcontext. The POSIX threading, however, assumes you preallocate (presumably, allocating it out of the heap), and then provide a stack for each thread at the time it is started. So for POSIX threading, this is not necessary. Note: lack of auto-stack growth is one of the worst aspects of POSIX threading, and, IMO, renders it very difficult to use. On the other hand, there's not a lot of reason to not implement the more complex guard-page based mechanisms for auto-stack growth. The benefits over a seperate mapping are that thread context switches between threads in a given process(/kernel schedulable context/kernel thread) are lighter weight, and that auto variables may be passed between threads. This is a significant benefit, which I'm reluctant to give up: the point of using threads as opposed to processes with a shared memory segment and a shared descriptor table is reduced context switch overhead. It is, in fact, the *only* benefit to using threads instead of that architecture. Even so, there are consequences to using threads that are frequently overlooked: o Given N processes on a system, and M threads of execution for a given service you want to run in addition to this, a threaded implementation competes for quantum as 1:(N+1), while a multiple process implementation competes for quantum as M:(N+M). On a heavily loaded system, this means that a multiple process implementation will get a larger share of the available quantum, and will thus complete sooner. o In Solaris and SVR4 kernel threading, where there are M user threads bound to N kernel threads, when M > N, suffers the same unfair competition by program counters for any scheduler alloted quantum. The SVR4/Solaris answer to this problem is to have the application run in a different scheduling class, where it can specify the amount of quantum consumers it wants to compete as with other processes. This is an unsatisfying soloution, mostly because kernel threads block on blocking calls from user threads. This means that I can only ever have N blocking calls outstanding, and a total of (M-N) threads, which are ready to run will not get quantum, regardless of the scheduling class used. It's also unsatisfying from the perspective that I have to give away my quantum and take a kernel context switch in return for the kernel allowing me to make a system call. I think that the only way to satisfactorily address these issues is to allow user threads to migrate between kernel schedulable entities. The kernel schedulable entites are there both to compete for quantum, and to provide SMP scalability, such that seperate user threads from a given application can be scheduled to run concurrently on multiple CPUs. There are additional complex issues of "when do I give away a quantum that the scheduler gave me, and what do I get in return" which are best addressed with call conversion and a cooperative user space scheduling component (think of it from the ideal that "the scheduler gave the quantum to the application, not to the thread"... "once the scheduler gives me a quantum, it's *my* damn quantum!"). > However, although I > understand the reasons, I can also see where doing so makes it *much* > more difficult to write 'correct' threaded programs, where I define > correct as the ability to run w/out stepping on yourself in *all* > cases. Note, I said difficult, not impossible. The cases where you might step on yourself are error cases, so far as I can see. I think that any case where there is an error, it doesn't matter how the error exhibits, your results are suspect. Here's the question: Maybe what you really mean is that a blown stack that doesn't cause an immediate error is harder to detect than a SIGBUS? I think we can agree that this is true. 8-). So it may be harder to initially develop correct code with more pages mapped. On the other hand, it's statistically likely that if the program goes off in the weeds for a memory reference, it will get an umapped page rather than some other threads stack. I think this is an acceptable risk for increased performance without the need for address space remapping on thread context switches, and for working around the scheduling-related overhead issues. After all, lower overhead is what prompted us to use threads in the first place; we must expect to pay for the tradeoff somewhere. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 15:11:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA12764 for current-outgoing; Fri, 19 Sep 1997 15:11:57 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA12742; Fri, 19 Sep 1997 15:11:40 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA08475; Fri, 19 Sep 1997 15:11:30 -0700 (MST) From: Terry Lambert Message-Id: <199709192211.PAA08475@usr06.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: nate@mt.sri.com (Nate Williams) Date: Fri, 19 Sep 1997 22:11:29 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, toor@dyson.iquest.net, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org In-Reply-To: <199709192145.PAA20992@rocky.mt.sri.com> from "Nate Williams" at Sep 19, 97 03:45:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > In any case, I'm convinced that it's necessary in order to fully support > > > C-Threads. > > > > Stacks in seperate address spaces are needed to fully support C-Threads? > > I'm convinced that you must *fully* share thread stacks in order to > be backwards compatible for C-Threads. You don't *have* to do that, but > then we're no longer backwards compatible. OK... I had a bit of pronoun trouble with "it's" there. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 15:28:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13987 for current-outgoing; Fri, 19 Sep 1997 15:28:41 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13977 for ; Fri, 19 Sep 1997 15:28:34 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id QAA19860; Fri, 19 Sep 1997 16:28:32 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA21185; Fri, 19 Sep 1997 16:28:30 -0600 (MDT) Date: Fri, 19 Sep 1997 16:28:30 -0600 (MDT) Message-Id: <199709192228.QAA21185@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709192210.PAA08418@usr06.primenet.com> References: <199709191956.NAA20377@rocky.mt.sri.com> <199709192210.PAA08418@usr06.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The benefits [ of shared mapping of stacks ] over a seperate mapping > are that thread context switches between threads in a given > process(/kernel schedulable context/kernel thread) are lighter weight, > and that auto variables may be passed between threads. Thread context aren't *that* much different. You're already doing the register savings/restores, what's one more register? (The stack is pointed to by a register, right?) You still have the ability to share the heap and any static/global data in your program, which is IMHO a big deal with threads, since it saves on the context switch. > > understand the reasons, I can also see where doing so makes it *much* > > more difficult to write 'correct' threaded programs, where I define > > correct as the ability to run w/out stepping on yourself in *all* > > cases. Note, I said difficult, not impossible. > > The cases where you might step on yourself are error cases, so far as > I can see. I think that any case where there is an error, it doesn't > matter how the error exhibits, your results are suspect. True, but no matter how smart you are, you will produce buggy code. And, anything that helps you avoid writing buggy code is your friend. I consider myself smarter than the average bear, and writing 'significant' threaded programs is a hard problem, especially when it involves user interfaces where you have one thread getting data from the user, and another thread operating on that data. The chance of the threads walking all over each other are significant, and hard to avoid. This, coupled with the fact that we're also doing *lots* of communications means that we have lots of threads doing lots of different 'work', and they all have to be protected from one another. In theory this sounds real easy, but in reality it's much harder than it looks, since doing things 'easily' means requiring too many locks around data. So, you end up with a solution that's complex, but fast. When you throw into the mix the possibilities of not knowing whether or not your data is on the heap or from a stack, and things start to get *real* interesting with regards to memory allocation. What/when/how do you deal with allocated data, that many 'threads' can share? Who cleans up? As any C programmer knows, finding dynamic memory allocation bugs are one of the *hardest* and most common mistakes made, even by folks who really know what they are doing. When coupled with threads it gives you a wonderful ability to hang yourself even faster. :) Is it an acceptable risk for performance? Sure, but the fact of the matter is that very few people are able to keep all of the balls in the air correctly w/out them falling down around them. And, too many people think they can do it, but really can't. :( Nate From owner-freebsd-current Fri Sep 19 17:07:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19850 for current-outgoing; Fri, 19 Sep 1997 17:07:28 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19836 for ; Fri, 19 Sep 1997 17:07:23 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA21261; Fri, 19 Sep 1997 17:07:20 -0700 (MST) From: Terry Lambert Message-Id: <199709200007.RAA21261@usr04.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: nate@mt.sri.com (Nate Williams) Date: Sat, 20 Sep 1997 00:07:16 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, current@freebsd.org In-Reply-To: <199709192228.QAA21185@rocky.mt.sri.com> from "Nate Williams" at Sep 19, 97 04:28:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Thread context aren't *that* much different. You're already doing the > register savings/restores, what's one more register? (The stack is > pointed to by a register, right?) And a page table entry, if the stack address spaces are seperate. If there isn't a different page table entry per thread for the stack, then I don't understand what you mean by "seperate". 8-(. > > The cases where you might step on yourself are error cases, so far as > > I can see. I think that any case where there is an error, it doesn't > > matter how the error exhibits, your results are suspect. > > True, but no matter how smart you are, you will produce buggy code. > And, anything that helps you avoid writing buggy code is your friend. Agreed, to the extent that it doesn't make the tools useless for their intended purpose; for threads, this is light-weight context switches (primary) and resource sharing (secondary). A mode where you could run on seperate stack address spaces, but which didn't require you to do so, would be a good idea for developement and testing (but not deployment). [ ... ] > Is it an acceptable risk for performance? Sure, but the fact of the > matter is that very few people are able to keep all of the balls in the > air correctly w/out them falling down around them. And, too many people > think they can do it, but really can't. :( I still don't see how you can thread context switch without changing the process address space map if one threads stack is not supposed to be available in the address space of another thread. And that's where the higher overhead (and "data marshalling" issues) comes from. Actually, for a loaded system, we haven't discussed the kernel threading case where a blocking call is made on one kernel thread. There's nothing to guarantee that the context switch that results will favor another kernel thread in the same process, even if the call that caused the context switch occurred very early in the quantum. And even if you implement "quantum affinity" for kernel threads in a given process to *actually* reduce the context switch overhead (instead of just *theoretically* doing it), then you've only introduced additional race issues, where a multithreaded process favors itself to the point of starving other processes. In other words, eventually a preemptive multitasking system has to context switch. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 18:05:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA22710 for current-outgoing; Fri, 19 Sep 1997 18:05:24 -0700 (PDT) Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA22704; Fri, 19 Sep 1997 18:05:16 -0700 (PDT) Received: from radio.ipsilon.com (radio.Ipsilon.COM [205.226.28.3]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA10065; Fri, 19 Sep 1997 18:03:01 -0700 Message-ID: <34232181.718FFBF0@ipsilon.com> Date: Fri, 19 Sep 1997 18:06:09 -0700 From: Joe Eykholt Organization: Ipsilon Software Engineering X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: Nate Williams CC: Terry Lambert , toor@dyson.iquest.net, dyson@FreeBSD.ORG, karpen@ocean.campus.luth.se, current@FreeBSD.ORG Subject: Re: FYI: regarding our rfork(2) References: <199709192104.PAA20740@rocky.mt.sri.com> <199709192130.OAA05946@usr06.primenet.com> <199709192145.PAA20992@rocky.mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk An aspect of sharing stacks that I didn't see mentioned is that it's more efficient from an implementation viewpoint for all threads to use the same virtual address space. I don't think we should impose unnecessary requirements without considering what would be lost in efficiency. If threads are to be truly light-weight, and you want the ability to run threads from the same process on different processors, then you'll want the two processors to use the identical virtual space for that process. Otherwise the kernel will need to duplicate most of the page directory in order to have some pages mapped differently in different threads. ... that'll be almost as expensive as separate processes. On a single processor, it'll mean doing a VM context switch when switching between threads on the same processor. Joe From owner-freebsd-current Fri Sep 19 20:15:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA28911 for current-outgoing; Fri, 19 Sep 1997 20:15:11 -0700 (PDT) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA28902 for ; Fri, 19 Sep 1997 20:15:08 -0700 (PDT) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id WAA02980; Fri, 19 Sep 1997 22:15:03 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id WAA15250; Fri, 19 Sep 1997 22:14:32 -0500 Message-ID: <19970919221431.23526@right.PCS> Date: Fri, 19 Sep 1997 22:14:31 -0500 From: Jonathan Lemon To: Terry Lambert Cc: Nate Williams , current@FreeBSD.ORG Subject: Re: FYI: regarding our rfork(2) References: <199709191956.NAA20377@rocky.mt.sri.com> <199709192210.PAA08418@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199709192210.PAA08418@usr06.primenet.com>; from Terry Lambert on Sep 09, 1997 at 10:10:13PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 09, 1997 at 10:10:13PM +0000, Terry Lambert wrote: > This is an unsatisfying soloution, mostly because kernel > threads block on blocking calls from user threads. This > means that I can only ever have N blocking calls outstanding, > and a total of (M-N) threads, which are ready to run will > not get quantum, regardless of the scheduling class used. What about other kernel/user thread implementations? Eg: scheduler activations, as put forth by Anderson, et.al. From what they describe, there is no limit to the number of blocking calls a user-level process can make. Unfortunately, I feel that they have glossed over some of the implementation details in their paper, making it difficult to evaluate. -- Jonathan From owner-freebsd-current Fri Sep 19 21:20:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA02199 for current-outgoing; Fri, 19 Sep 1997 21:20:17 -0700 (PDT) Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA02193 for ; Fri, 19 Sep 1997 21:20:11 -0700 (PDT) Received: (from sjr@localhost) by istari.home.net (8.8.7/8.8.6) id AAA00807 for freebsd-current@FreeBSD.ORG; Sat, 20 Sep 1997 00:20:05 -0400 (EDT) Date: Sat, 20 Sep 1997 00:20:05 -0400 (EDT) From: "Stephen J. Roznowski" Message-Id: <199709200420.AAA00807@istari.home.net> To: freebsd-current@FreeBSD.ORG Subject: PnP problem with dset (when pnp0 not in kernel)? Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think that I've run into a problem with the new PnP support. I don't have a "controller pnp0" line in my kernel, and when I try to build sbin/dset/dset.c, I get errors that `struct pnp_cinfo' isn't defined... -SR From owner-freebsd-current Fri Sep 19 21:54:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA03579 for current-outgoing; Fri, 19 Sep 1997 21:54:13 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.69]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA03522; Fri, 19 Sep 1997 21:52:25 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.7/8.7.3) id XAA27856; Fri, 19 Sep 1997 23:52:06 -0500 (CDT) Message-ID: <19970919235205.10870@my.domain> Date: Fri, 19 Sep 1997 23:52:05 -0500 From: Tom Jackson To: FreeBSD Current Cc: jdp@freebsd.org, bde@freebsd.org Subject: sys/mount.h breaks mod3lib build Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been adding a new drive and also getting started using cvsup. Around the 12th I built the repository (before the disk add). Had some troubles after the drive add with cvsup dying while downloading. After the 16th commit of the changes to sys/mount.h I deleted cvsup and tried to rebuild. It failed in the m3core section mentioning prototype error with mount.h. Restored mount.h to the 12th taped version and m3lib built fine and the download with worked just great. I haven't looked into this any further. Spent a lot of wasted time trying to figure out how I corrupted my system :( Tom From owner-freebsd-current Fri Sep 19 22:18:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA05339 for current-outgoing; Fri, 19 Sep 1997 22:18:05 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA05330 for ; Fri, 19 Sep 1997 22:17:58 -0700 (PDT) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xCHv6-00068k-00; Fri, 19 Sep 1997 23:17:28 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.7/8.8.3) with ESMTP id XAA25782 for ; Fri, 19 Sep 1997 23:17:08 -0600 (MDT) Message-Id: <199709200517.XAA25782@harmony.village.org> To: current@freebsd.org Subject: Makefile broken Date: Fri, 19 Sep 1997 23:17:08 -0600 From: Warner Losh Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk /usr/usr.sbin/Makefile is missing a \ at the end of the line that has netstat in it. I have fixed this problem, but those people that try to do a make world with the latest CTM will find that it fails for them. Warner From owner-freebsd-current Fri Sep 19 22:19:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA05404 for current-outgoing; Fri, 19 Sep 1997 22:19:51 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA05388 for ; Fri, 19 Sep 1997 22:19:28 -0700 (PDT) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xCHwh-00068r-00; Fri, 19 Sep 1997 23:19:07 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.7/8.8.3) with ESMTP id XAA26686 for ; Fri, 19 Sep 1997 23:18:46 -0600 (MDT) Message-Id: <199709200518.XAA26686@harmony.village.org> To: current@freebsd.org Subject: fetch dumping core on http Date: Fri, 19 Sep 1997 23:18:46 -0600 From: Warner Losh Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've noticed that fetch seems to be dumping core on any URL that has http in it. Has anybody else seen this? Should I try to track it down, or do I just need a newer fetch? I'm rebuilding the world right now (for other reasons) and thought I'd ask about this minor annoyance. Warner From owner-freebsd-current Fri Sep 19 22:39:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA07881 for current-outgoing; Fri, 19 Sep 1997 22:39:08 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA07874 for ; Fri, 19 Sep 1997 22:39:05 -0700 (PDT) Received: (qmail 23822 invoked by uid 1000); 20 Sep 1997 05:39:27 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Fri, 19 Sep 1997 22:39:27 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: An important Note on Make Release Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have been reporting a host of problems in ``make release''. Please make a note that ``make buildworld'' followed by ``make installworld'' work just fine off the same CVS tree. --- Sincerely Yours, (Sent on 19-Sep-97, 22:36:54 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Fri Sep 19 22:39:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA07928 for current-outgoing; Fri, 19 Sep 1997 22:39:19 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA07909 for ; Fri, 19 Sep 1997 22:39:13 -0700 (PDT) Received: (qmail 23813 invoked by uid 1000); 20 Sep 1997 05:39:27 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709191838.LAA03586@rah.star-gate.com> Date: Fri, 19 Sep 1997 22:39:27 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Amancio Hasty Subject: Re: Make Release - Is there anything I can do to help? Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Amancio Hasty; On 19-Sep-97 you wrote: > Relax, we are having problems right now and I don't think that > this is our typical status quo. Oh, I am very relaxed :-) I just offered to help in any way I can. --- Sincerely Yours, (Sent on 19-Sep-97, 22:27:26 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Fri Sep 19 22:39:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA07947 for current-outgoing; Fri, 19 Sep 1997 22:39:21 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA07908 for ; Fri, 19 Sep 1997 22:39:13 -0700 (PDT) Received: (qmail 23811 invoked by uid 1000); 20 Sep 1997 05:39:27 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709192210.PAA08418@usr06.primenet.com> Date: Fri, 19 Sep 1997 22:39:27 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Terry Lambert Subject: Re: FYI: regarding our rfork(2) Cc: current@FreeBSD.ORG, (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In response/addition to Terry's excellent analysis, not knowing much about implementation details, etc., let me briefly describe what I belive to be typical multithreaded application: We have an RDBMS server which participates in ocmpletion of telephone calls. The way it essentially works is this: The telephone equipment passes the server a piece of data. We compute something on the data, make a database access and send a reply. We need to do this about 30-200 times per second, and since most people hate to hear ``dead air'' when they dial a phone number, we also have to repond rapidly. The original design (which worked well on Slowlaris and Linux) was to have a listner thread waiting for requests. and a group of ``worker threads'' which sit and wait for work to be done. When a request arrives, it is handed to a worker thread and the master thread goes back to listening for more requests. the worker thread does what it does, replies to the requestor and then goes back into a queue, waiting for the next call to serve. We tried the approach of spawning new threads on demand but this is simply too slow. When we decided to go with FreeBSD on this project, the first task was to port the server. After about three weeks of hassle, we gave up. Even when the incompatabilities with Posix were accounted for, we had never been able to get more than aboout 400,000 calls processed before the thing will lock up. Our call rate, on a Pentium-90 went from 43/sec (Linux) to 14/Sec (FreeBSD-2.2). We then decided to toss the multithreading and re-build the server as multi-process. Same concept but having separate processes, using shared memory to comunicate. The result? Throughput went up to about 140/sec, and reliability is excellent; We have aborted a load test after two weeks of runtime. Why the story? Although multi-threading sounds good for certain things, when you compare it to the traditional Unix model, it really has very little benefit. Even in performance. What we gain instead is the need/requirement to ``play O/S'' in the user program (or library); If you remember, I started this thread with a very, very simple program; In an endless loop, fork. If you are the child, exit, if you are the parent, loop again. There is NOTHING syntatically or semantically wrong with this program. It domes something very basic to Unix but still crashes immediately. When I asked for help, I was shown a list of reasons what was wrong with my program. Chief amoung them was that I did not take the care to allocate a separate stack for each process. I plowed my greying memory and virtually any C and Unix specification, looking for a facility to manage my program's stack. I then went back to some of the original papers on C, and lo and behold, one of the main attractions was the ELIMINATION of the need to track, manipulate and manage the stack. Ask 10 GOOD C programmers, and 9 will mumble something about the stack being where local variables and arguments reside. One of the 9 maybe even knows how to increase its size at compile or run time. Only one of the original 10 will know how to actually do something useful about the stack in a running program. And this one is probably a participant in this thread :-) (Not me, I just read these and go ``wow!''). My two cents worht of opinion; If we want to maintain Unix in the spirit and make FreeBSD useful to a large audience of programmers, keep the original semantics. If I want a messy, complex, tricky environment (multi threading included), I can use NiceTry and get about half my management very, very happy (``now we are as mediocre as anyone else''). But this is just a biased opinion. Where I would LOVE to have more than one thread is in the kernel. --- Sincerely Yours, (Sent on 19-Sep-97, 21:59:17 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Fri Sep 19 22:58:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA09778 for current-outgoing; Fri, 19 Sep 1997 22:58:12 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA09773 for ; Fri, 19 Sep 1997 22:58:10 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA20208; Fri, 19 Sep 1997 22:58:02 -0700 (MST) From: Terry Lambert Message-Id: <199709200558.WAA20208@usr02.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: jlemon@americantv.com (Jonathan Lemon) Date: Sat, 20 Sep 1997 05:58:01 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <19970919221431.23526@right.PCS> from "Jonathan Lemon" at Sep 19, 97 10:14:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This is an unsatisfying soloution, mostly because kernel > > threads block on blocking calls from user threads. This > > means that I can only ever have N blocking calls outstanding, > > and a total of (M-N) threads, which are ready to run will > > not get quantum, regardless of the scheduling class used. > > What about other kernel/user thread implementations? Eg: scheduler > activations, as put forth by Anderson, et.al. From what they describe, > there is no limit to the number of blocking calls a user-level process > can make. Unfortunately, I feel that they have glossed over some of the > implementation details in their paper, making it difficult to evaluate. Yes. To "ungloss": A simple version of activations can be had by having a split call context, and utilizing an async call gate, with markers. An async call gate with markers means that there is an alternate gate for all system calls. In the case that the system call won't block, the call proceeds normally to completion (getpid()). In the cass that the call would block (it has a marker in the sysent[} structure tagging it as a potentially blocking call), the call proceeds normally, until such time as it would block. If it doesn't block, then it proceeds normally to completion (read() with the page in core). If it blocks, then you pull a "call context record" off a freelist, and point to the process environment, so it can be restored on call completion (read() with the page not in core, etc.). This "call context record" contains the kernel stack for the call; you replace the process stack with the call stack, and return to the caller on the new kernel stack with "EASYNC" to flag that the call was queued rather than completed. The actual return from the call is abrogated to be an error indication. All out-of-band returns are disallowed: an extra 0th parameter is inserted before the actuall call arguments to pass a pointer that is set to "NULL" if the call completes, and the address of the context if it's queued. Ideally, the call gate sets this to NULL in user space before calling. This os OK, since only one call entry on the proc will exist simultaneously for a given kernel schedulable entity (process/kernel thread/whatever). In the kernel, the sleep is scheduled on the original stack and the context record, as a "context sleep". The "EASYNC" can be treated by the cooperative user space scheduler as an "activation" in the Anderson sense, but has slightly simplified semantics because of the reduced conditions under which kernel code must call back to user space. Unlike the activations described in the Anderson paper, there are no calls from kernel to user space. An "EASYNC" return is a request to the user space scheduler to schedule another thread. When the queued call completes, it uses the context record to update the user data. Since it has the original kernel stack at the time of the call that went async, it can complete it's output. It does this by storing the return value(s) in the context record, and doing copyouts, if necessary, to user parameters. Because the context points to the user process, the page table data is available for this to be successful. It then queues the completed context record on the processes "completed" list, hung off the proc struct. Now the tricky part: notifying the user process that an async gated call has completed. Typically, completion notification (and an "activation" for the thread waiting for the event) wants to occur: 1) When another call has been made and gone "EASYNC". This case can be handled by another error return, "EASYNCDONE", which both notifies that the current call has gone async, that there are one or more completed async calls that want to have their status reaped (ie: pending "activations"). A seperate call is used to return the queued completion contexts to user space. 2) When another call has been made that *won't* go async. This requires a "fake completion". To do this, "EASYNCSYNC" is returned on call completion, even though the call has not gone async. The context record pointer returned is fake; it's only purpose is to provide access to the return values from the completed call. But in so doing, the user space scheduler receives an "activation" for other async calls which have subsequently completed. The same call is used to reap the status as in step #1, using the fake context. Additional contexts are reaped as necessary. 3) When all user threads are blocking. Typically, this is handled by queueing the blocking operation on a context, as normal, but then *not* returning to user space until a completion has been queued on the process: ie: actually sleeping the process. To recover from this, the first call to return returns "EASYNCSYNC" and recoveres as if it were a non-blocking call providing an "activation" for prior blocking calls, as in #2, above. In other words, the process blocks with an effective "poll" or "select" on completion events. This saves an additional call analogous to "aiowait". An analogous call to "aiocancel" is not necessary; normal signal and kernel process termination is in effect. This is actually the reason I tend to recommend an async call gate whenever kernel threading comes up... probably this wasn't very obvious to most people until now; it might have looked as if I had gone off at an oblique angle with no justification... 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 19 23:27:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA13663 for current-outgoing; Fri, 19 Sep 1997 23:27:14 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA13658 for ; Fri, 19 Sep 1997 23:27:11 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id XAA21428; Fri, 19 Sep 1997 23:27:07 -0700 (MST) From: Terry Lambert Message-Id: <199709200627.XAA21428@usr02.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: Shimon@i-Connect.Net (Simon Shapiro) Date: Sat, 20 Sep 1997 06:27:06 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG, nate@mt.sri.com In-Reply-To: from "Simon Shapiro" at Sep 19, 97 10:39:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The original design (which worked well on Slowlaris and Linux) was to have > a listner thread waiting for requests. and a group of ``worker threads'' > which sit and wait for work to be done. When a request arrives, it is > handed to a worker thread and the master thread goes back to listening for > more requests. the worker thread does what it does, replies to the > requestor and then goes back into a queue, waiting for the next call to > serve. This was the model I used when I did the process architecture for the "Pathworks for VMS (NetWare)" product. It worked well for VMS because: (1) most VMS machines weren't SMP capable, (2) AST overhead is *vastly* lower than context switch overhead in VMS (the threading was a call-conversion implementation using AST's, more like SunOS 4.x's liblwp than pthreads: aioread/write beats non-blocking I/O for call concurrency), and (3) VMS didn't have a file system cache. The library code that implements the FS cache on the current VMS came out of our project. > We tried the approach of spawning new threads on demand but this is simply > too slow. The thread-per-client model is flawed in a *lot* of ways that the "work to do engine" model is not. 8-). > Our call rate, on a Pentium-90 went from 43/sec (Linux) to 14/Sec > (FreeBSD-2.2). We then decided to toss the multithreading and re-build the > server as multi-process. Same concept but having separate processes, using > shared memory to comunicate. > > The result? Throughput went up to about 140/sec, and reliability is > excellent; We have aborted a load test after two weeks of runtime. You should be able to obtain the same wins under Linux; if you are still using it, I recommend converting it, as well. I would be *very* interested in knowing what your Solaris rate was, considering the high context switch overhead for blocking kernel calls... I assume you ran the same number of kernel and usre threads, and used the "tightly bound" relationship model? If I were a betting person, I'd bet "more than 43 and less than 140". > Why the story? Although multi-threading sounds good for certain things, > when you compare it to the traditional Unix model, it really has very > little benefit. Even in performance. > > What we gain instead is the need/requirement to ``play O/S'' in the user > program (or library); This is not entirely fair. "Real threading" will gain you concurrency wins. I don't think the pthreads implementation under FreeBSD really qualifies as "real threading". Using async I/O with aioread/write/wait/cancel will yeild significantly higher concurrency than using non-blocking descriptors and select. This is because AIO will schedule the work, and non-blocking descriptors and select will only tell you when it is possible to schedule the work without blocking. The difference is the latency between the time that work is scheduled, and the time it completes. I am a firm believer in async call gates, either via aioread/aiowrite, or a formal alternate gate that may apply to all system calls. Some optimizations are possible to reduce reaping latency (namely tagging) for calls that can run to completion without sleeping. Probably the majority of your performance win was related to increased concurrency of the calls in the multiple process case. Unless the system was seriously loaded with other tasks (unlikely for such a dedicated use), the performance losses were not quantum-competition releated, but concurrency related. Of course, I could be wrong, and the box could be your main www server as well as your phone switch... 8-). > My two cents worht of opinion; If we want to maintain Unix in the spirit > and make FreeBSD useful to a large audience of programmers, keep the > original semantics. If I want a messy, complex, tricky environment (multi > threading included), I can use NiceTry and get about half my management > very, very happy (``now we are as mediocre as anyone else''). > But this is just a biased opinion. > > Where I would LOVE to have more than one thread is in the kernel. Kernel threading, unless the user programs using the async call gate themselves, in the same way that users can program with aio* on SunOS and SVR4, is the only mechanism capable of supporting SMP scalability in the context of a single process. In the user-async programming case, kernel contexts, be they aio contexts or async call gate contexts, can be scheduled to run on different CPUs. But threading is an easier model to grasp for doing concurrent work than interleaved system calls. I think it would be a mistake to not abstract the issues in overlapped prgramming to a procedural interface -- in other words, a user space threads implementation. Not everyone can think in terms of concurrent soloutions for programming problems. Those who can are the people who write threads libraries because it makes your brain itch to think that way too long... or they are entirely warped by the ordeal and become professional mathematicians; mostly topologists and group theorists. 8-) 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Sep 20 01:07:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29814 for current-outgoing; Sat, 20 Sep 1997 01:07:04 -0700 (PDT) Received: from MindBender.serv.net (mindbender.serv.net [205.153.153.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA29773; Sat, 20 Sep 1997 01:06:45 -0700 (PDT) Received: from localhost.HeadCandy.com (localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.8.6/8.7.3) with SMTP id BAA21983; Sat, 20 Sep 1997 01:06:08 -0700 (PDT) Message-Id: <199709200806.BAA21983@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: toor@dyson.iquest.net (John S. Dyson), nate@mt.sri.com, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-reply-to: Your message of Fri, 19 Sep 97 20:27:45 -0000. <199709192027.NAA01303@usr03.primenet.com> Date: Sat, 20 Sep 1997 01:06:02 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been following all this with slight interest, but thought I should contribute in this case... >> > The great strength about Unix is that another 'process' can'tt muck with >> > another 'processes' easily, and with threads I'd like to see this taken >> > to whatever extreme as possible given the constraints of implementation. >> The threads are a different issue. I don't disagree with the threads >> stacks being isolated for philosophical reasons -- however it is just >> wrong from a compatibility standpoint. >Exactly so. If you want this protection, implement using processes >instead of threads. >The problem is that I may pass auto variables between threads: I believe this is Just Plain Wrong. Auto variables inside a function call are local to that specific instance of that function. Since a specific instance of a function is instantiated on a specific thread of execution, that means the local auto-variables have a scope local to that specific thread, as well. To assume there is a need to consider otherwise is to needlessly complicate a clean paradigm. If state needs to be kept among multiple threads, it should be done so globally (or better, in a "global" namespace or class specificly for this purpose). >I might do this, for example, if my work items were DNS lookups, etc., >which had to be accomplished serially, or with some maximum concurrency >(say I start no more than 3 thread2's, and 10's of thread1's) because >of load characteristics. This would be better accomplished with global metephores, critical sections, and/or mutexes. Or, as stated above, metephores, critical sections, and/or mutexes stored in a global namespace or class specifically for this purpose. Of course, this assumes that such primitives are even available, which they are not in standard libc. But neither are threads, indicating additional libraries are already in use. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net Contract software development for Windows NT, Windows 95 and Unix. Windows NT and Unix server development in C++ and C. --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Sat Sep 20 01:26:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA03930 for current-outgoing; Sat, 20 Sep 1997 01:26:48 -0700 (PDT) Received: from MindBender.serv.net (mindbender.serv.net [205.153.153.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA03905; Sat, 20 Sep 1997 01:26:41 -0700 (PDT) Received: from localhost.HeadCandy.com (localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.8.6/8.7.3) with SMTP id BAA22114; Sat, 20 Sep 1997 01:26:06 -0700 (PDT) Message-Id: <199709200826.BAA22114@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Joe Eykholt cc: Nate Williams , Terry Lambert , toor@dyson.iquest.net, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-reply-to: Your message of Fri, 19 Sep 97 18:06:09 -0700. <34232181.718FFBF0@ipsilon.com> Date: Sat, 20 Sep 1997 01:26:06 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >An aspect of sharing stacks that I didn't see mentioned is >that it's more efficient from an implementation viewpoint for >all threads to use the same virtual address space. >I don't think we should impose unnecessary requirements without >considering what would be lost in efficiency. > >If threads are to be truly light-weight, and you want the ability >to run threads from the same process on different processors, then >you'll want the two processors to use the identical virtual space >for that process. Otherwise the kernel will need to duplicate most of >the page directory in order to have some pages mapped differently >in different threads. ... that'll be almost as expensive as separate >processes. On a single processor, it'll mean doing a VM context >switch when switching between threads on the same processor. I agree to the point where we agree on the term for "virtual address space". When doing so, I am referring specifically to the heap and any memmory-mapped regions. I don't consider the stack to be part of that designation, at least for this specific case. This means that all threads in the process should share the same "virtual address space" for the lifetime of the process. Furthermore, their stacks should be functionally identical at the time the thread is created, and should be able to change separately, from that point forward. Similar to the case of how a child process state is set up right after a fork. This also means that any auto variables created on the stack by a functional call in one stack are local in scope and paradigm to that thread. They might actually be physically accessible from other threads in the process because of the physical implementation of the threading library, but that should be considered not-guaranteed, and a design no-no for this paradigm. I say "functionally identical" for the stacks because all threads that return from their initial start-time function should cleanly exit that thread context. In almost all cases that will not be the function "main()" except for the initial thread that started the process. My 3 or 4 cents... ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net Contract software development for Windows NT, Windows 95 and Unix. Windows NT and Unix server development in C++ and C. --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Sat Sep 20 06:46:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA05594 for current-outgoing; Sat, 20 Sep 1997 06:46:46 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA05589; Sat, 20 Sep 1997 06:46:27 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA25914; Sat, 20 Sep 1997 23:42:11 +1000 Date: Sat, 20 Sep 1997 23:42:11 +1000 From: Bruce Evans Message-Id: <199709201342.XAA25914@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.ORG, toj@gorilla.net Subject: Re: sys/mount.h breaks mod3lib build Cc: bde@FreeBSD.ORG, jdp@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >dying while downloading. After the 16th commit of the changes >to sys/mount.h I deleted cvsup and tried to rebuild. It failed >in the m3core section mentioning prototype error with mount.h. >Restored mount.h to the 12th taped version and m3lib built fine >and the download with worked just great. I haven't looked into >this any further. mount(2) has taken a `const char *name' arg since 1997/02/10 when Lite2 was merged, but the prototype was left wrong for backwards compatibility until 1997/09/16. Apparently m3lib still uses the old version. This works if it compiles because of crufty binary compatibility code in the kernel. Bruce From owner-freebsd-current Sat Sep 20 09:23:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA13168 for current-outgoing; Sat, 20 Sep 1997 09:23:37 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA13156 for ; Sat, 20 Sep 1997 09:23:33 -0700 (PDT) Received: from rhiannon.scsn.net ([208.133.153.55]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-41950U6000L1100S0) with ESMTP id AAA193 for ; Sat, 20 Sep 1997 12:24:28 -0400 Received: (from root@localhost) by rhiannon.scsn.net (8.8.7/8.8.5) id MAA02623; Sat, 20 Sep 1997 12:23:27 -0400 (EDT) Message-ID: <19970920122326.45564@scsn.net> Date: Sat, 20 Sep 1997 12:23:26 -0400 From: "Donald J. Maddox" To: current@FreeBSD.ORG Subject: Problems with -current ppp Reply-To: dmaddox@scsn.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Some of the recent changes to PPP seem to have broken it for me... Since I haven't seen any messages from others experiencing the same problems, I have to assume that something in my configuration is causing the problem, but for the life of me, I cannot figure out what it is. Here's the relevant info: # ppp -auto scsn Sep 20 10:08:22 rhiannon ppp[156]: Error: Tcp: Can't open socket 3000: No password in ppp.secret So, it is impossible to telnet to port 3000 to control PPP. If I create an /etc/ppp/ppp.secret for test purposes, ppp can open port 3000, but that's not what I want, because then only a very small handful of ppp's control commands are available. The Config Files: ----------------- /etc/ppp/ppp.conf ----------------- # # Default setup. Executed always when PPP is invoked. # default: set log +lcp +lqm +phase +chat +command +connect +carrier +link set device /dev/cuaa1 set timeout 0 set speed 115200 set ctsrts on set parity none set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" scsn: disable lqr deny lqr disable pred1 deny pred1 set redial 1 1000 set reconnect 1 1000 set phone 7790055 set login "TIMEOUT 20 ogin: word: " set ifaddr 0.0.0.0/0 206.25.246.43/0 255.255.255.255 delete ALL add 0 0 HISADDR =========================================================================== ------------------- /etc/ppp/ppp.linkup ------------------- MYADDR: delete ALL add 0 0 HISADDR add MYADDR 255.255.255.255 127.0.0.1 =========================================================================== I can't see anything above that should be forcing password authorization. The above worked fine until some recent changes to ppp (I wish I could be more specific :-( The problem started about a week or two ago.) I do a 'make world' almost every day, but the problem persists. Anybody got a clue for me? From owner-freebsd-current Sat Sep 20 10:03:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA15558 for current-outgoing; Sat, 20 Sep 1997 10:03:27 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA15553 for ; Sat, 20 Sep 1997 10:03:22 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id KAA10880; Sat, 20 Sep 1997 10:03:14 -0700 (PDT) Message-Id: <199709201703.KAA10880@rah.star-gate.com> To: Simon Shapiro cc: freebsd-current@FreeBSD.ORG Subject: Re: Make Release - Is there anything I can do to help? In-reply-to: Your message of "Fri, 19 Sep 1997 22:39:27 PDT." Date: Sat, 20 Sep 1997 10:03:14 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What I am doing over to attemp to resolve the problem that I am having is to back out all the recent changes by supping a snapshot of the tree of 9/10/97. Thats is before the poll check ins from the multimedia mailing list I didn't receive any complaints till after the poll check in . This is not to say that the poll check in is the culprit rather my last known point of a working -current. Cheers, Amancio >From The Desk Of Simon Shapiro : > > Hi Amancio Hasty; On 19-Sep-97 you wrote: > > > Relax, we are having problems right now and I don't think that > > this is our typical status quo. > > Oh, I am very relaxed :-) > I just offered to help in any way I can. > > --- > > > Sincerely Yours, (Sent on 19-Sep-97, 22:27:26 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Sat Sep 20 11:10:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA19532 for current-outgoing; Sat, 20 Sep 1997 11:10:56 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@spain-8.ppp.hooked.net [206.169.228.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA19524 for ; Sat, 20 Sep 1997 11:10:53 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id LAA00709 for ; Sat, 20 Sep 1997 11:11:10 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 20 Sep 1997 11:11:10 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: current@freebsd.org Subject: Re: Problems with -current ppp In-Reply-To: <19970920122326.45564@scsn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 20 Sep 1997, Donald J. Maddox wrote: > > Some of the recent changes to PPP seem to have broken it for me... > Since I haven't seen any messages from others experiencing the same > problems, I have to assume that something in my configuration is > causing the problem, but for the life of me, I cannot figure out what > it is. Here's the relevant info: > > # ppp -auto scsn > Sep 20 10:08:22 rhiannon ppp[156]: Error: Tcp: Can't open socket 3000: No password in ppp.secret > > So, it is impossible to telnet to port 3000 to control PPP. If I create > an /etc/ppp/ppp.secret for test purposes, ppp can open port 3000, but that's > not what I want, because then only a very small handful of ppp's control > commands are available. In your ppp.secret create a line like this hostname password once you telnet into port 3000 type passwd password, and you'll get access to everything. Once I got past that, I've still had a lot of problem with ppp -ddial. - alex From owner-freebsd-current Sat Sep 20 11:58:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21763 for current-outgoing; Sat, 20 Sep 1997 11:58:03 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21758 for ; Sat, 20 Sep 1997 11:58:01 -0700 (PDT) Received: from ppp132.coladlp2.scsn.net ([208.133.153.132]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-41950U6000L1100S0) with ESMTP id AAA211; Sat, 20 Sep 1997 14:58:58 -0400 Received: (from root@localhost) by ppp132.coladlp2.scsn.net (8.8.7/8.8.5) id OAA03175; Sat, 20 Sep 1997 14:57:54 -0400 (EDT) Message-ID: <19970920145753.25511@coladlp2.scsn.net> Date: Sat, 20 Sep 1997 14:57:53 -0400 From: "Donald J. Maddox" To: Alex Cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp Reply-To: dmaddox@scsn.net References: <19970920122326.45564@scsn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Alex on Sat, Sep 20, 1997 at 11:11:10AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 20, 1997 at 11:11:10AM -0700, Alex wrote: > > # ppp -auto scsn > > Sep 20 10:08:22 rhiannon ppp[156]: Error: Tcp: Can't open socket 3000: No password in ppp.secret > > > > So, it is impossible to telnet to port 3000 to control PPP. If I create > > an /etc/ppp/ppp.secret for test purposes, ppp can open port 3000, but that's > > not what I want, because then only a very small handful of ppp's control > > commands are available. > > In your ppp.secret create a line like this > hostname password > once you telnet into port 3000 type passwd password, and you'll get access > to everything. Once I got past that, I've still had a lot of problem with > ppp -ddial. > Thanks. I was really hoping there was some magic that would make typing a password unnecessary, like before, but you can't win 'em all, eh :-( From owner-freebsd-current Sat Sep 20 12:41:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA23527 for current-outgoing; Sat, 20 Sep 1997 12:41:22 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA23522 for ; Sat, 20 Sep 1997 12:41:19 -0700 (PDT) Received: from mailhost.sdsp.mc.xerox.com ([13.231.132.18]) by alpha.xerox.com with SMTP id <51941(4)>; Sat, 20 Sep 1997 12:40:47 PDT Received: from gnu.sdsp.mc.xerox.com (gnu.sdsp.mc.xerox.com [13.231.133.90]) by mailhost.sdsp.mc.xerox.com (8.8.5/8.8.5) with SMTP id PAA23801 for ; Sat, 20 Sep 1997 15:39:45 -0400 (EDT) Received: by gnu.sdsp.mc.xerox.com (4.1/client-1.3) id AA18159; Sat, 20 Sep 97 15:39:44 EDT Message-Id: <9709201939.AA18159@gnu.sdsp.mc.xerox.com> To: freebsd-current@freebsd.org Subject: running binutils 2.8, elf support? Date: Sat, 20 Sep 1997 12:39:44 PDT From: "Marty Leisner" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In 2.*, I recall I built binutils and thinks like nm and size ran (but not ld). Is there a way to crosscompile on linux for freebsd? I understand freebsd supports ELF. Can I run the linux/elf gcc/as/ld with the write specs file (i.e. libraries and header files) to generate freebsd binaries? I looked on www.freebsd.org, and couldn't come up with anything useful... 1) what do I need 2) can I have some elf binaries I can try out? I didn't see any meaningful information in the handbook or FAQ sheet... (did I miss something?) marty leisner@sdsp.mc.xerox.com Don't confuse education with schooling. Milton Friedman to Yogi Berra From owner-freebsd-current Sat Sep 20 13:41:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA25762 for current-outgoing; Sat, 20 Sep 1997 13:41:38 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA25755 for ; Sat, 20 Sep 1997 13:41:34 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id WAA04762; Sat, 20 Sep 1997 22:39:35 +0200 (MEST) From: Søren Schmidt Message-Id: <199709202039.WAA04762@sos.freebsd.dk> Subject: Re: running binutils 2.8, elf support? In-Reply-To: <9709201939.AA18159@gnu.sdsp.mc.xerox.com> from Marty Leisner at "Sep 20, 97 12:39:44 pm" To: leisner@sdsp.mc.xerox.com (Marty Leisner) Date: Sat, 20 Sep 1997 22:39:35 +0200 (MEST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Marty Leisner who wrote: > > Is there a way to crosscompile on linux for freebsd? Dunno... > I understand freebsd supports ELF. Yes, the kernel support is there, the runtime linker etc is missing. > > Can I run the linux/elf gcc/as/ld with the write specs > file (i.e. libraries and header files) to generate freebsd > binaries? > > I looked on www.freebsd.org, and couldn't come up with > anything useful... > 1) what do I need > 2) can I have some elf binaries I can try out? > > I didn't see any meaningful information in the handbook or FAQ > sheet... (did I miss something?) Not really, but there is work underways to make FreeBSD convert to ELF. Peter Wemm, John Poltra and Myself have been working on this lately, and we have our test systems running all ELF, so it not that far away... It wont happen overnight though, as there are ALOT of details that needs to be sorted out, before we attempt to "morphe" -current into ELF. It will happen though, but I can't give you a time frame just yet, neither how its going to be done. I can however guarantie that we will go for a method, that causes the least possible pain for our -current users, but remember -current is bleeding edge, and sometimes the edge is not exactly userfriendly... Please be patient, we are working on this as fast as we can... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Sat Sep 20 13:50:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA26307 for current-outgoing; Sat, 20 Sep 1997 13:50:03 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA26269; Sat, 20 Sep 1997 13:49:54 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id NAA23258; Sat, 20 Sep 1997 13:48:26 -0700 (MST) From: Terry Lambert Message-Id: <199709202048.NAA23258@usr07.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: michaelv@MindBender.serv.net (Michael L. VanLoon -- HeadCandy.com) Date: Sat, 20 Sep 1997 20:48:26 +0000 (GMT) Cc: tlambert@primenet.com, toor@dyson.iquest.net, nate@mt.sri.com, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org In-Reply-To: <199709200806.BAA21983@MindBender.serv.net> from "Michael L. VanLoon -- HeadCandy.com" at Sep 20, 97 01:06:02 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Exactly so. If you want this protection, implement using processes > >instead of threads. > >The problem is that I may pass auto variables between threads: > > I believe this is Just Plain Wrong. Auto variables inside a function > call are local to that specific instance of that function. Since a > specific instance of a function is instantiated on a specific thread > of execution, that means the local auto-variables have a scope local > to that specific thread, as well. To assume there is a need to > consider otherwise is to needlessly complicate a clean paradigm. > > >I might do this, for example, if my work items were DNS lookups, etc., > >which had to be accomplished serially, or with some maximum concurrency > >(say I start no more than 3 thread2's, and 10's of thread1's) because > >of load characteristics. > > This would be better accomplished with global metephores, critical > sections, and/or mutexes. Or, as stated above, metephores, critical > sections, and/or mutexes stored in a global namespace or class > specifically for this purpose. > > Of course, this assumes that such primitives are even available, which > they are not in standard libc. But neither are threads, indicating > additional libraries are already in use. By this logic, I should not call functions with non-global arguments when doing normal C programming. 8-). The question is whether or not you can conceive of a procedural interface where another thread does the required work. I can easily... and you should be able to as well. Say there's a task that requires you to do a DNS lookup and a lengthy initialization, where order is not important, followed by some network activity using the initialization and the DNS data. You could conceive that this might be implemented as something like: thread2() thread1() { { for(;;) { start_dns_lookup() ---> wait_for_request() /* start long initialization*/ make_dns_call() for(i = 0; i < MAXINIT; i++) /* wait DNS response*/ init_func( i); /* long init complete*/ wait_dns_lookup_complete() /* call returned*/ <--- signal_dns_complete() /* continue processing*/ } ... } } This lets the initialization and the DNS lookup proceed concurrently. The intent of threads is also to allow greater concurrency; it's not just to logically seperate groups of operations in an overall task by using different program counters. Because the act scheduled on the other thread is synchronized with the first thread, ther data pass from thread1 to thread2 by start_dns_lookup() is never in scope in thread2 and not in scope in thread one. This means it can e auto, or locally allocated, or whatever. There is no topological difference between allocating the storage off the stack, or allocating the storage off the stack, and then storing the pointer to the storage from the heap in a pointer variable -- it being allocated off the stack. 8-). This type of inter-thread cll is expected. If it were not, there would be no need for thread synchronization primitives. > If state needs to be kept among multiple threads, it should be done so > globally (or better, in a "global" namespace or class specificly for > this purpose). Since all stacks exist in the process address space, both stack and heap are global to all threads. The only relevent issue here is whether or not, when a buffer is passed out of scope, the sope that passed it remains intact until the out of scope operation is completed. With the failure case you are afraid of, I can cause the failure with a malloc'ed buffer as well: thread2() thread1() { { char *q = "hello world"; char *p = malloc( 20); for(;;) { send_buffer_to_thread_2() wait_for_buffer() /* XXX*/ ... ... ... strcpy( p, q); } } /* YYY*/ printf( "%s\n", p); free( p); } Say I get rid of from "XXX" to "YYY" in thread1. I now have a race between the deallocation and descoping of the buffer thread 2 is about to write to, and the act of thread 2 writing it. I also have a race between the printf() and the strcpy(). This means I can't safely assume the scheduler will act one way or the other (I can't anyway, but I might have done so in testing). Now say you want to make a "failure limitation" argument. The argument fails on the grounds that, after going out of scope in thread1, the area that will be written to by thread2 could have been reused by another thread. You can't make the argument that only thread1 is in danger of produsing erroneous results. So the failure case you are afraid of is not related to heap vs. stack allocation, it's related to inter-thread synchronization. Whether the buffer was on the heap or the stack is irrelevant. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Sep 20 14:00:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26851 for current-outgoing; Sat, 20 Sep 1997 14:00:24 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26827; Sat, 20 Sep 1997 14:00:09 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id NAA23483; Sat, 20 Sep 1997 13:58:44 -0700 (MST) From: Terry Lambert Message-Id: <199709202058.NAA23483@usr07.primenet.com> Subject: Re: FYI: regarding our rfork(2) To: michaelv@MindBender.serv.net (Michael L. VanLoon -- HeadCandy.com) Date: Sat, 20 Sep 1997 20:58:43 +0000 (GMT) Cc: jre@ipsilon.com, nate@mt.sri.com, tlambert@primenet.com, toor@dyson.iquest.net, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org In-Reply-To: <199709200826.BAA22114@MindBender.serv.net> from "Michael L. VanLoon -- HeadCandy.com" at Sep 20, 97 01:26:06 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I agree to the point where we agree on the term for "virtual address > space". When doing so, I am referring specifically to the heap and > any memmory-mapped regions. I don't consider the stack to be part of > that designation, at least for this specific case. How do you manage the seperation of a stack virtual address space at the time you do a thread context switch, without adding overhead simply to obtain this seperation? > This means that all threads in the process should share the same > "virtual address space" for the lifetime of the process. Furthermore, > their stacks should be functionally identical at the time the thread > is created, and should be able to change separately, from that point > forward. Similar to the case of how a child process state is set up > right after a fork. "Copy on write stacks"? This increases thread context switch overhead. If you are going to do this, why use threads? If you are on a locaded system, and you use a purely kernel threaded paradigm (this seperation requires a kernel component as descriptor for each of the threads stacks), there is no guarantee that when you give up your quantum, another thread in the same process will get the next quantum. This means that your thread context switch overhead has just grown to be nearly statistically identical to process context switch overhead. > This also means that any auto variables created on the stack by a > functional call in one stack are local in scope and paradigm to that > thread. They might actually be physically accessible from other > threads in the process because of the physical implementation of the > threading library, but that should be considered not-guaranteed, and a > design no-no for this paradigm. If you do not impose seperate stack descriptors, then you can use either a pure usesr space call conversion mechanism, or you can use a cooperative scheduler mechanism, either of which will permit more efficient use of a quantum and significantly reduced process context switch overhead. But the rationale for stack seperation is the incorrectly behaved thread not causing all threads to fail. Forgetting for a moment that, if a single thread breaks, your entire task is broken (by definition), a "wild thread" that you are attempting to protect other threads from by seperation of stacks, doesn't care where in the address space it stomps. Your other threads stacks are not sacrosanct, and you have failed to achieve the protection you set out to achieve when you seperated the stacks. You have not even achieved the scoping protction you claim to want to achieve (see previous posting, with "concurrent DNS lookup" example). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Sep 20 15:13:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29565 for current-outgoing; Sat, 20 Sep 1997 15:13:54 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29559 for ; Sat, 20 Sep 1997 15:13:50 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA01350; Sat, 20 Sep 1997 15:11:06 -0700 (MST) From: Terry Lambert Message-Id: <199709202211.PAA01350@usr02.primenet.com> Subject: Re: running binutils 2.8, elf support? To: sos@sos.freebsd.dk (Søren Schmidt) Date: Sat, 20 Sep 1997 22:11:05 +0000 (GMT) Cc: leisner@sdsp.mc.xerox.com, freebsd-current@FreeBSD.ORG In-Reply-To: <199709202039.WAA04762@sos.freebsd.dk> from "Søren Schmidt" at Sep 20, 97 10:39:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Not really, but there is work underways to make FreeBSD convert > to ELF. Peter Wemm, John Poltra and Myself have been working on > this lately, and we have our test systems running all ELF, so > it not that far away... Including the booting kernel? Any of them SMP? I ran into problems when I tried to build an ELF SMP kernel with John's original (28 bytes shy of filling the space) dual ELF/a.out boot blocks. > It wont happen overnight though, as there are ALOT of details > that needs to be sorted out, before we attempt to "morphe" > -current into ELF. Anything I can do? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Sep 20 17:06:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA03371 for current-outgoing; Sat, 20 Sep 1997 17:06:09 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03361 for ; Sat, 20 Sep 1997 17:06:03 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id XAA20353; Sat, 20 Sep 1997 23:56:56 +0100 (BST) Message-Id: <199709202256.XAA20353@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Alex cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-reply-to: Your message of "Sat, 20 Sep 1997 11:11:10 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Sep 1997 23:56:56 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In your ppp.secret create a line like this > hostname password > once you telnet into port 3000 type passwd password, and you'll get access > to everything. Once I got past that, I've still had a lot of problem with > ppp -ddial. What sort of problems ? > - alex > -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Sat Sep 20 19:35:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08480 for current-outgoing; Sat, 20 Sep 1997 19:35:59 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08475 for ; Sat, 20 Sep 1997 19:35:55 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA24601; Sat, 20 Sep 1997 19:36:14 -0700 (PDT) To: dmaddox@scsn.net cc: Alex , current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-reply-to: Your message of "Sat, 20 Sep 1997 14:57:53 EDT." <19970920145753.25511@coladlp2.scsn.net> Date: Sat, 20 Sep 1997 19:36:13 -0700 Message-ID: <24597.874809373@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Thanks. I was really hoping there was some magic that would make > typing a password unnecessary, like before, but you can't win 'em all, eh :-( Not and have any semblance of security on your ppp line, no. ;-) Jordan From owner-freebsd-current Sat Sep 20 20:10:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA09723 for current-outgoing; Sat, 20 Sep 1997 20:10:08 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09716 for ; Sat, 20 Sep 1997 20:10:03 -0700 (PDT) Received: from ppp132.coladlp2.scsn.net ([208.133.153.132]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-41950U6000L1100S0) with ESMTP id AAA149; Sat, 20 Sep 1997 23:11:05 -0400 Received: (from root@localhost) by ppp132.coladlp2.scsn.net (8.8.7/8.8.5) id XAA04012; Sat, 20 Sep 1997 23:09:54 -0400 (EDT) Message-ID: <19970920230953.49189@coladlp2.scsn.net> Date: Sat, 20 Sep 1997 23:09:53 -0400 From: "Donald J. Maddox" To: "Jordan K. Hubbard" Cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp Reply-To: dmaddox@scsn.net References: <19970920145753.25511@coladlp2.scsn.net> <24597.874809373@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <24597.874809373@time.cdrom.com>; from Jordan K. Hubbard on Sat, Sep 20, 1997 at 07:36:13PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 20, 1997 at 07:36:13PM -0700, Jordan K. Hubbard wrote: > > Thanks. I was really hoping there was some magic that would make > > typing a password unnecessary, like before, but you can't win 'em all, eh :-( > > Not and have any semblance of security on your ppp line, no. ;-) > > Jordan Well, this is a one-user box, so that's not really a concern. In any case, Brian informed me in private mail of a neat little trick to accomplish what I wanted. From owner-freebsd-current Sat Sep 20 21:26:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA12405 for current-outgoing; Sat, 20 Sep 1997 21:26:03 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA12400 for ; Sat, 20 Sep 1997 21:26:00 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id VAA29677; Sat, 20 Sep 1997 21:26:22 -0700 (PDT) To: dmaddox@scsn.net cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-reply-to: Your message of "Sat, 20 Sep 1997 23:09:53 EDT." <19970920230953.49189@coladlp2.scsn.net> Date: Sat, 20 Sep 1997 21:26:21 -0700 Message-ID: <29665.874815981@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sat, Sep 20, 1997 at 07:36:13PM -0700, Jordan K. Hubbard wrote: > > > Thanks. I was really hoping there was some magic that would make > > > typing a password unnecessary, like before, but you can't win 'em all, eh :-( > > > > Not and have any semblance of security on your ppp line, no. ;-) > > > > Jordan > > Well, this is a one-user box, so that's not really a concern. In any case, > Brian informed me in private mail of a neat little trick to accomplish what > I wanted. Tell me your IP address and the hours when you're generally on and surfing. I'll show you how "one user" that box is. ;-) Jordan From owner-freebsd-current Sat Sep 20 22:10:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA14129 for current-outgoing; Sat, 20 Sep 1997 22:10:59 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@tibet-34.ppp.hooked.net [206.80.9.162]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA14124 for ; Sat, 20 Sep 1997 22:10:54 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id WAA00565; Sat, 20 Sep 1997 22:11:02 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 20 Sep 1997 22:11:00 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: Brian Somers cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-Reply-To: <199709202256.XAA20353@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 20 Sep 1997, Brian Somers wrote: > > In your ppp.secret create a line like this > > hostname password > > once you telnet into port 3000 type passwd password, and you'll get access > > to everything. Once I got past that, I've still had a lot of problem with > > ppp -ddial. > > What sort of problems ? A while back after all this password (and other I guess) stuff was commited, I would be getting unable to open port 3000 messages, and now with the same script that I use, I must wait for ppp to dial my isp then hit ctrl c to "kill" it, it will then be able to connect. If I don't it the remote modem drops carrier after a while, and ppp hangs. - alex