From owner-freebsd-hackers Sun Apr 26 00:06:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA03816 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 00:06:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA03795 for ; Sun, 26 Apr 1998 00:05:56 -0700 (PDT) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id AAA07983; Sun, 26 Apr 1998 00:06:04 -0700 (PDT) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd007981; Sun Apr 26 00:06:02 1998 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id AAA27466; Sun, 26 Apr 1998 00:05:53 -0700 (PDT) From: Ulf Zimmermann Message-Id: <199804260705.AAA27466@Gatekeeper.Alameda.net> Subject: Re: Tips needed about dynamic device registering In-Reply-To: from Julian Elischer at "Apr 25, 98 11:46:02 pm" To: julian@whistle.com (Julian Elischer) Date: Sun, 26 Apr 1998 00:05:53 -0700 (PDT) Cc: ulf@Alameda.net, hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Sat, 25 Apr 1998, Ulf Zimmermann wrote: > > > I need some tips how I should go ahead and register dynamic on boot time > > disk drive device, simular like "device sd0". The raid controller I am > > working on can have up to 32 "drives", which have mainly a read block > > and a write block function. > > > > DEVFS would probably one way, but I am also interested in doing it without > > DEVFS. > As the devfs person I agree devfs is the way, but you probably want this > to run on 2.2.x as well. > > can you describe what you want to do with an example? > I don't exactly understand your question. > (I can think of several possible meanings) > > as I wrote sd.c I can probably help if I knew what you wanted to know. Basic this: Device myx.ctl or so, gives a control interface, which allows talking with the controller, so that for example a rebuild of a RAID drive can be initiated or a new system drive can be added. Then x sd type devices, where maybe the minor number is based on the controller unit (1 to 4 controllers) and the number of the system drive. Something like this: Major myx Minor 0 = 1. Controller, 1. system drive Major myx Minor 1 = 1. Controller, 2. system drive ... Major myx Minor 31 = 1. Controller, 32. system drive Major myx Minor 32 = 2. Controller, 1. system drive ... Major myx Minor 127 = 4. Controller, 32. system drive This would provide garantied number, based on the controller and system drive number and someone would have space to online add disk capacity. > > julian > > > > > Ulf. > > > > --------------------------------------------------------------------- > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 00:50:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA09689 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 00:50:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA09667; Sun, 26 Apr 1998 00:50:41 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id AAA20244; Sun, 26 Apr 1998 00:50:34 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd020241; Sun Apr 26 00:50:32 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id AAA00666; Sun, 26 Apr 1998 00:50:25 -0700 (MST) From: Terry Lambert Message-Id: <199804260750.AAA00666@usr05.primenet.com> Subject: Re: threads performance To: ccsanady@friley585.res.iastate.edu (Chris Csanady) Date: Sun, 26 Apr 1998 07:50:25 +0000 (GMT) Cc: jb@cimlogic.com.au, dyson@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199804260013.TAA09376@friley585.res.iastate.edu> from "Chris Csanady" at Apr 25, 98 07:13:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not sure how related this is, but has any thought been given to using > an async call gate? Yes. I first suggested it in July 1994. I don't claim "prior art", though; the idea was VMS's, I believe. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 00:51:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA09752 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 00:51:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.ic.dk (qmailr@mail.ic.dk [194.255.107.174]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA09743 for ; Sun, 26 Apr 1998 00:51:00 -0700 (PDT) (envelope-from jacob@jblhome.ping.dk) Received: (qmail 9089 invoked from network); 26 Apr 1998 07:50:57 -0000 Received: from ic1.ic-local (HELO ic1.ic.dk) (192.168.65.12) by ic4.ic.dk with SMTP; 26 Apr 1998 07:50:57 -0000 Received: from jblhome by ic1.ic.dk with UUCP id AA11844 (5.65c8/IDA-1.4.4j); Sun, 26 Apr 1998 09:49:42 +0200 Received: (from jacob@localhost) by pippin.jblhome.ping.dk (8.8.8/8.8.8) id JAA01279; Sun, 26 Apr 1998 09:53:39 +0200 (CEST) (envelope-from jacob) To: Terry Lambert Cc: mike@smith.net.au (Mike Smith), cshenton@it.hq.nasa.gov, archie@whistle.com, hackers@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. References: <199804180834.BAA08866@usr01.primenet.com> From: Jacob Bohn Lorensen Date: 26 Apr 1998 09:53:37 +0200 In-Reply-To: Terry Lambert's message of Sat, 18 Apr 1998 08:34:11 +0000 (GMT) Message-Id: <87hg3h2f3y.fsf@pippin.jblhome.ping.dk> Lines: 31 X-Mailer: Gnus v5.3/Emacs 19.34 X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: > > > > > The way UNIX piles random configuration information all into > > > > > /etc has always bugged the crap out of me. Ideally, /etc > Basically, it's a big cache coherency problem; all the data that > gets changed and results in the wrong thing happening is "cached" in > the program doing the wrong thing. So what we need is, maybe a new signal? SIGCONF? by default it is ignored. Processes that need to know when configuration changes, can establish a handler for this signal and ``do the right thing'' when ip address et al changes. (sounds a lot like the SIGHUP convention, although a bit more structured). I guess another syscall might come in handy too: ``please notify when this-and-that registry values change'', i.e. sigconf_mask(). Maybe we need to be able to select()/poll() on registry changes as well. With such a mechanism in place, we can start converting userland programs to actually use it. It may actually prove to be not so difficult---many programs already have re-read-configuration handlers for SIGHUP. Jacob -- Jacob Lorensen; Mosebuen 33, 1.; DK-2820 Gentofte, Denmark; +45-31560401 PGP ID = E596F0B5; PGP Fingerprint = 1E8726467436DC4A 723B6678C5AD9E71 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 00:56:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA11081 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 00:56:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA11073 for ; Sun, 26 Apr 1998 00:56:48 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id AAA29690; Sun, 26 Apr 1998 00:56:45 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd029676; Sun Apr 26 00:56:35 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id AAA00835; Sun, 26 Apr 1998 00:56:22 -0700 (MST) From: Terry Lambert Message-Id: <199804260756.AAA00835@usr05.primenet.com> Subject: Re: Speaking of packaging tools.. To: mike@smith.net.au (Mike Smith) Date: Sun, 26 Apr 1998 07:56:22 +0000 (GMT) Cc: eivind@yes.no, garbanzo@hooked.net, hackers@FreeBSD.ORG In-Reply-To: <199804260315.UAA01783@antipodes.cdrom.com> from "Mike Smith" at Apr 25, 98 08:15:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Neat - but do we really want to go in the direction of packages that > > can contain trojans? Personally I wouldn't like running a > > self-extracting archive, at least... > > We already have them. Part of the notes I formulated on the scheme that > came out of the last round of discussions deals with the concept of a > set of security models and some basic trust-related items to handle > packages which need to do processing work subsequent to installation. > > It was fairly clear from some observation that this processing could > not always be eliminated. 8( Satoshi probably does not want to become an X.509 certificate authority using 128 bit MD5 checksums. But if he does, the RSA MD5 code is under a BSD-like license, and is exportable, being a hash, and Diffie-Helman is recently off patent. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 01:17:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA15010 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 01:17:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA14997 for ; Sun, 26 Apr 1998 01:17:09 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA05376; Sun, 26 Apr 1998 01:16:26 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd005372; Sun Apr 26 08:16:21 1998 Date: Sun, 26 Apr 1998 01:10:55 -0700 (PDT) From: Julian Elischer To: Ulf Zimmermann cc: hackers@FreeBSD.ORG Subject: Re: Tips needed about dynamic device registering In-Reply-To: <199804260705.AAA27466@Gatekeeper.Alameda.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 26 Apr 1998, Ulf Zimmermann wrote: > Basic this: > > Device myx.ctl or so, gives a control interface, which allows > talking with the controller, so that for example a rebuild of a RAID > drive can be initiated or a new system drive can be added. > > Then x sd type devices, where maybe the minor number is based on the > controller unit (1 to 4 controllers) and the number of the system drive. > Something like this: > > Major myx Minor 0 = 1. Controller, 1. system drive > Major myx Minor 1 = 1. Controller, 2. system drive > ... > Major myx Minor 31 = 1. Controller, 32. system drive > Major myx Minor 32 = 2. Controller, 1. system drive > ... > Major myx Minor 127 = 4. Controller, 32. system drive > > This would provide garantied number, based on the controller > and system drive number and someone would have space to online > add disk capacity. The minor number is a 24 bit value. it is perculiar in that in a dev_t it is 24 bits made up of 16 bits and 8 bits which are NOT CONTIGUOUS. however you may divide them up any way you feel. If you use the diskslice stuff that bruce wrote, (as in the present sd.c and wd.c) you will need to stick with the layout in disklabel.h (shown below). TYPE is basically unused I think. you could use the lower 5 UNIT bits for your 'system drive #' and the upper UNIT bits for the controller. OR you could use the TYPE bits.. present practice is to use the top TYPE bit to indicate a control (.ctl) device. These bits are made in the filesysteme by MAKEDEV and defined by a combination of these macro's and your code. that's all there is to it.. DEVFS makes this whole question GO AWAY. it handles it all for you. /* 3 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 _________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ----------------------------------------------------------------- | TYPE |UNIT_2 | SLICE | MAJOR? | UNIT |PART | ----------------------------------------------------------------- */ #define dkmakeminor(unit, slice, part) \ (((slice) << 16) | (((unit) & 0x1e0) << 16) |\ (((unit) & 0x1f) << 3) | (part)) #define dkmodpart(dev, part) (((dev) & ~(dev_t)7) | (part)) #define dkmodslice(dev, slice) (((dev) & ~(dev_t)0x1f0000) | ((slice) << 16)) #define dkpart(dev) (minor(dev) & 7) #define dkslice(dev) ((minor(dev) >> 16) & 0x1f) #define dktype(dev) ((minor(dev) >> 25) & 0x7f) #define dkunit(dev) ((((dev) >> 16) & 0x1e0) | (((dev) >> 3) & 0x1f)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 01:48:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA18926 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 01:48:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA18918 for ; Sun, 26 Apr 1998 01:48:24 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yTMhb-0004XE-00; Sun, 26 Apr 1998 01:22:23 -0700 Date: Sun, 26 Apr 1998 01:22:21 -0700 (PDT) From: Tom To: Christoph Toshok cc: freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 25 Apr 1998, Christoph Toshok wrote: > Are there any plans to address the performance of threads in the > coming weeks/months? The fact that NSPR can drop 21 seconds off the > runtime (in this very contrived example) makes me think that there is > a lot going on in libc_r that is suboptimal, but perhaps there is just > no other way to implement things so they conform to the posix spec. Even mit-pthreads on a 2.2.6 system is faster than libc_r (using the tests in mysql as a comparison). The weird part is that the amount of CPU time accumulated is very similar, libc_r just takes more real time. Makes me think that something in libc_r just sleeps once and while... Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 02:16:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA21304 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 02:14:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iq.org (proff@polysynaptic.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA21118 for ; Sun, 26 Apr 1998 02:11:40 -0700 (PDT) (envelope-from proff@iq.org) Received: (qmail 10048 invoked by uid 110); 26 Apr 1998 09:11:33 -0000 To: marc@bowtie.nl cc: billm@suburbia.net Subject: Re: math library cc: freebsd-hackers@freebsd.org References: <199804240642.IAA21344@bowtie.nl> From: Julian Assange Date: 26 Apr 1998 19:11:32 +1000 In-Reply-To: Marc van Kempen's message of "Fri, 24 Apr 1998 08:42:52 +0200" Message-ID: Lines: 53 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@freebsd.org Precedence: bulk X-Loop: FreeBSD.ORG Marc van Kempen writes: > Hi Julian, > > I hope you don't mind me asking this question, but I found an > elaborate article of yours about optimal math performance, > posted to freebsd-hackers. > > What is the current status on getting optimal math performance? > Did you manage to get the same performance as Linux has? > > In a simple test program I still see a difference of about 9%. > (in favor of Linux :-() > > Regards, > Marc. 9% - that's nothing :) I was seeing close to 100% difference. FreeBSD has two maths libraries. The original CSRG library, and libmsun (/usr/src/msun). The latter has become the default FreeBSD maths library (although, I'm not sure as of when). libmsun has been extensively tested to confirm correct calculation in a variety of pathological circumstances. The 9% difference you are seeing is probably related to this. I would NOT trust the linux libm for ANY scientific calculation. I ported the linux libm to FreeBSD because of the 100% difference in speed I was seeing during the rendering phase of a scientific visualisation project I was working on. Rendering is not a process especially prone to error amplification or pathological conditions, yet I was seeing a clear difference in results between the two libraries - so much so that I was unable to use Linux and FreeBSD boxes together in a distributed rendering environment. Often results like this can be attributed to machines with different fp word-lengths, or random number generators, (assuming an iterative process), but both the linux and FreeBSD machines were 586's, running my own PRN generation code. If you have a very tight inner loop and you *understand the constraints of the 387*, you are probably best off re-writing the loop in 387 code, or breaking the inner loop out into a .c file of its own and compiling it with --fast-math (and possibly --fancy-math-387). This essentially inlines a number of libm functions at the expensive of having them behave like a 3 year old child with an abacus). billm@suburbia.net wrote the linux (used elsewhere too) floating point emulator code (note emulator, not libm). He may have something to say on this matter. Cheers, Julian. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 03:25:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA11720 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 03:07:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA10423 for ; Sun, 26 Apr 1998 02:57:15 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id CAA06772; Sun, 26 Apr 1998 02:53:14 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd006768; Sun Apr 26 09:53:09 1998 Date: Sun, 26 Apr 1998 02:47:44 -0700 (PDT) From: Julian Elischer To: Tom cc: Christoph Toshok , freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG try KTRACEing the two versions. I'll bet you'll see the difference immediatly. On Sun, 26 Apr 1998, Tom wrote: > > On 25 Apr 1998, Christoph Toshok wrote: > > > Are there any plans to address the performance of threads in the > > coming weeks/months? The fact that NSPR can drop 21 seconds off the > > runtime (in this very contrived example) makes me think that there is > > a lot going on in libc_r that is suboptimal, but perhaps there is just > > no other way to implement things so they conform to the posix spec. > > Even mit-pthreads on a 2.2.6 system is faster than libc_r (using the > tests in mysql as a comparison). > > The weird part is that the amount of CPU time accumulated is very > similar, libc_r just takes more real time. Makes me think that something > in libc_r just sleeps once and while... > > Tom > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 04:10:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA19401 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 04:08:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA17639 for ; Sun, 26 Apr 1998 03:59:37 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id NAA10393 for freebsd-hackers@freefall.cdrom.com; Sun, 26 Apr 1998 13:04:52 +0200 (MEST) (envelope-from kuku) Date: Sun, 26 Apr 1998 13:04:52 +0200 (MEST) From: Christoph Kukulies Message-Id: <199804261104.NAA10393@gilberto.physik.RWTH-Aachen.DE> To: freebsd-hackers@freefall.FreeBSD.org Subject: closed reports reading Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had two gnats reports filed in in the past which seem to be gone and it escaped me under which comments they have been closed. Looking into the GNATS database on www.freebsd.org doesn't show them to me even when I check "Closed reports too". How can I trace back the history of these reports? -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 08:50:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA12150 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 08:46:02 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ntu-kpi.kiev.ua (root@ntu-kpi.kiev.ua [195.178.136.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10590 for ; Sun, 26 Apr 1998 08:34:17 -0700 (PDT) (envelope-from lx@hosix.ntu-kpi.kiev.ua) Received: from fobos.ntu-kpi.kiev.ua (fobos.ntu-kpi.kiev.ua [10.100.0.6]) by ntu-kpi.kiev.ua (8.8.8/8.7.3) with ESMTP id SAA06128 for ; Sun, 26 Apr 1998 18:33:34 +0300 (EEST) Received: from hosix.ntu-kpi.kiev.ua (lx.hosix.ntu-kpi.kiev.ua [10.100.23.72]) by fobos.ntu-kpi.kiev.ua (unknown/censored) with ESMTP id SAA00455 for ; Sun, 26 Apr 1998 18:33:34 +0300 (EEST) Received: (from lx@localhost) by hosix.ntu-kpi.kiev.ua (8.8.8/8.8.7) id SAA01970; Sun, 26 Apr 1998 18:33:33 +0300 (EEST) (envelope-from lx) Message-ID: <19980426183333.38119@hosix.ntu-kpi.kiev.ua> Date: Sun, 26 Apr 1998 18:33:33 +0300 From: Alexander Matey To: freebsd-hackers@FreeBSD.ORG Subject: Static ARP (IFF_NOARP usage in ethernet interfaces) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=ew6BAiZeqk4r7MaW X-Mailer: Mutt 0.88e Organization: Hostel #6, NTUU /KPI/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Hi! I'd like to discuss the usage of IFF_NOARP flag in if_ether.c -- the place where ethernet arp is implemented. One time I've tried to make arp work in static mode on an ethernet interface. Static arp here should be understood as a mode where all who-has requests from outside are ignored and similar requests from our host are not broadcasted. However you're still able to manage arp table manually by the help of arp(8). This was what I needed. But all my tries to disable arp requests/replies on a particular ethernet interface have failed (ifconfig xxx -arp). IFF_NOARP flag seemed to be ignored, so I decided to look through kernel sources (FreeBSD 2.2.6- RELEASE). I've realized that the only place where IFF_NOARP have been used was netatalk/aarp.c -- appletalk arp implementation. Therefore I've done a patch for if_ether.c which takes into account the state of IFF_NOARP flag and completely disables arp requests and replies on a particular ethernet interface. If kernel is compiled with -DARP_HACK it changes the behavior of -arp option to answering who-has queries but leaves broadcasting of these queries from our side disabled. Is it possible to commit these changes to -stable (maybe -current) branches ? I think it would be of use to people. Any suggestions will be appreciated. Attached. bye, lx. --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-aa --- /sys/netinet/if_ether.c.org Wed May 14 19:43:56 1997 +++ /sys/netinet/if_ether.c Sun Apr 26 16:47:25 1998 @@ -277,8 +277,14 @@ register struct ether_header *eh; register struct ether_arp *ea; struct sockaddr sa; +/* PATCH BEGIN -lx- */ + if((ac->ac_if.if_flags & IFF_NOARP) != 0) { + return; + } +/* PATCH END */ + if ((m = m_gethdr(M_DONTWAIT, MT_DATA)) == NULL) return; m->m_len = sizeof(*ea); m->m_pkthdr.len = sizeof(*ea); @@ -353,8 +359,14 @@ sdl->sdl_family == AF_LINK && sdl->sdl_alen != 0) { bcopy(LLADDR(sdl), desten, sdl->sdl_alen); return 1; } +/* PATCH BEGIN -lx- */ + if((ac->ac_if.if_flags & IFF_NOARP) != 0) { + m_freem(m); + return (0); + } +/* PATCH END */ /* * There is an arptab entry, but no ethernet address * response yet. Replace the held mbuf with this * latest one. @@ -399,8 +411,13 @@ splx(s); if (m == 0 || (m->m_flags & M_PKTHDR) == 0) panic("arpintr"); if (m->m_len >= sizeof(struct arphdr) && +/* PATCH BEGIN -lx- */ +#ifndef ARP_HACK + (m->m_pkthdr.rcvif->if_flags & IFF_NOARP) == 0 && +#endif +/* PATCH END */ (ar = mtod(m, struct arphdr *)) && ntohs(ar->ar_hrd) == ARPHRD_ETHER && m->m_len >= sizeof(struct arphdr) + 2 * ar->ar_hln + 2 * ar->ar_pln) @@ -481,8 +498,16 @@ ea->arp_sha, ":", inet_ntoa(isaddr)); itaddr = myaddr; goto reply; } + +/* PATCH BEGIN -lx- */ +#ifdef ARP_HACK + if ((ac->ac_if.if_flags & IFF_NOARP) != 0) { + goto reply; + } +#endif +/* PATCH END */ la = arplookup(isaddr.s_addr, itaddr.s_addr == myaddr.s_addr, 0); if (la && (rt = la->la_rt) && (sdl = SDL(rt->rt_gateway))) { if (sdl->sdl_alen && bcmp((caddr_t)ea->arp_sha, LLADDR(sdl), sdl->sdl_alen)) --ew6BAiZeqk4r7MaW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 09:43:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16899 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 09:33:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16769 for ; Sun, 26 Apr 1998 09:30:14 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from gnipahellir.ifi.uio.no (2602@gnipahellir.ifi.uio.no [129.240.64.86]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id SAA18742; Sun, 26 Apr 1998 18:30:09 +0200 (MET DST) Received: (from dag-erli@localhost) by gnipahellir.ifi.uio.no ; Sun, 26 Apr 1998 18:30:08 +0200 (MET DST) Mime-Version: 1.0 To: Alfred Perlstein Cc: Hans Huebner , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover References: Organization: Gutteklubben Terrasse / KRST / PUMS / YASMW X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-Stop-Spam: http://www.cauce.org From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 26 Apr 1998 18:30:07 +0200 In-Reply-To: Alfred Perlstein's message of "Sat, 25 Apr 1998 09:42:56 +0000 (GMT)" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: > a combination of MX records (DNS), proper NIS slave servers and DNS > secondaries should take care of your problem. Afaik, the MAC level > address is burnt into the card. Yes, but that is not significant, because the Ethernet headers are constructed in software, so you could in theory tell the link layer driver to use a different MAC address; but then you'd have to run in promiscuous mode constantly and sort packets in software, because there's (generally) no way to tell the NIC to use a different address, so it'd discard packets bearing your (fake) MAC address as destination address. -- Noone else has a .sig like this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 11:02:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26059 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 10:54:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA24477 for ; Sun, 26 Apr 1998 10:41:58 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA11748 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Sun, 26 Apr 1998 19:41:29 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.7/8.6.12) id MAA21807; Sun, 26 Apr 1998 12:55:46 +0200 (MET DST) From: Wilko Bulte Message-Id: <199804261055.MAA21807@yedi.iaf.nl> Subject: Re: FreeBSD HA configuration / Ethernet address takeover In-Reply-To: from Hans Huebner at "Apr 26, 98 00:52:12 am" To: hans@artcom.de (Hans Huebner) Date: Sun, 26 Apr 1998 12:55:46 +0200 (MET DST) Cc: mike@smith.net.au, freebsd-hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Hans Huebner wrote... > Hello again, > > On Sat, 25 Apr 1998, Mike Smith wrote: > > In your case, if you know the adapter(s) you're using, you could add > > code to allow the change to be made. This would involve implementing > > the SIOCGIFHWADDR and SIOCSIFHWADDR (get/set hardware address) socket > > ioctls, which would be relatively simple. > I looked at the DE21040 documentation and found out that you're right. I > also found out that this particular Ethernet chip allows for multiple MAC You will probably find that all (well...) DEC ethernetcards / chips can do so. At least the ones that are supported in DECnet environments. DECnet changes the MAC address (don't ask me why) of the card. W/ _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW: http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 12:36:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06660 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 12:21:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dt050n33.san.rr.com (@dt050n33.san.rr.com [204.210.31.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06355 for ; Sun, 26 Apr 1998 12:19:09 -0700 (PDT) (envelope-from Studded@san.rr.com) Received: from san.rr.com (Studded@localhost [127.0.0.1]) by dt050n33.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA11852; Sun, 26 Apr 1998 12:18:47 -0700 (PDT) (envelope-from Studded@san.rr.com) Message-ID: <35438897.4CF24E7@san.rr.com> Date: Sun, 26 Apr 1998 12:18:47 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE-0420 i386) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: "John S. Dyson" , freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance References: <3679.893531204@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan K. Hubbard wrote: > > > The issue of kernel threads is on my plate, I have been *ordered* > > I think he was still wanting to know (and I'm darn curious myself) > why our *user* threads are so slow in comparison to the user thread > packages on other platforms. I'm not saying kernel threads aren't > neat or needed, I'm just wondering what specific performance bogon > we're suffering from in userland which makes it so? This is in support of the importance of getting some kind of well-performing threads into -Stable as soon as practically possible. One of my repeat customers who has been very happy with FreeBSD in the past is developing a new Unix port of one of his very successful programs. He asked me about FreeBSD's thread support and I told him (honestly at the time) that I didn't know much about it but I'd set him up an account on my -Stable box at home and let him test his stuff. To say he was dissatisfied is an understatement. :-/ The short version is that for this app he is probably going to recommend Linux on the low end because they have (from what I understand) pretty good kernel threads support already and Irix on the high end. Please don't think I'm being critical (about this anyway :). I know all the reasons why this hasn't happened yet. I'm just trying to offer a solid data point that shows how important it is. Doug -- *** Chief Operations Officer, DALnet IRC network *** *** Proud designer and maintainer of the world's largest Internet *** Relay Chat server with 5,328 simultaneous connections. *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 12:58:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10692 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 12:57:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10289 for ; Sun, 26 Apr 1998 12:54:41 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA14963; Sun, 26 Apr 1998 12:45:07 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd014956; Sun Apr 26 19:45:05 1998 Date: Sun, 26 Apr 1998 12:39:38 -0700 (PDT) From: Julian Elischer To: Alexander Matey cc: freebsd-hackers@FREEBSD.ORG Subject: Re: Static ARP (IFF_NOARP usage in ethernet interfaces) In-Reply-To: <19980426183333.38119@hosix.ntu-kpi.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FREEBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I see no technical reason against this but I'm curious why one would want to do this.. I can't imagine a single reason for not wanting to do arp.. On Sun, 26 Apr 1998, Alexander Matey wrote: > Hi! > > I'd like to discuss the usage of IFF_NOARP flag in if_ether.c -- the > place where ethernet arp is implemented. > One time I've tried to make arp work in static mode on an ethernet > interface. Static arp here should be understood as a mode where all who-has > requests from outside are ignored and similar requests from our host are not > broadcasted. However you're still able to manage arp table manually by the > help of arp(8). This was what I needed. > But all my tries to disable arp requests/replies on a particular > ethernet interface have failed (ifconfig xxx -arp). IFF_NOARP flag seemed > to be ignored, so I decided to look through kernel sources (FreeBSD 2.2.6- > RELEASE). I've realized that the only place where IFF_NOARP have been used > was netatalk/aarp.c -- appletalk arp implementation. > Therefore I've done a patch for if_ether.c which takes into account > the state of IFF_NOARP flag and completely disables arp requests and replies > on a particular ethernet interface. If kernel is compiled with -DARP_HACK it > changes the behavior of -arp option to answering who-has queries but leaves > broadcasting of these queries from our side disabled. > Is it possible to commit these changes to -stable (maybe -current) > branches ? I think it would be of use to people. > Any suggestions will be appreciated. > > Attached. > > bye, lx. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 13:00:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11091 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 12:59:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10481 for ; Sun, 26 Apr 1998 12:56:19 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id OAA19235 for ; Sun, 26 Apr 1998 14:55:21 -0400 (EDT) Date: Sun, 26 Apr 1998 14:55:21 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@localhost To: FreeBSD-hackers@FREEBSD.ORG Subject: network problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FREEBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Trying to get past a network problem, and I have to ask a couple of questions. I am trying to get my FreeBSD smp machine, picnic, to talk to my NetBSD DECserver (jaunt), and I am seeing some things I don't understand. I can ping jaunt from picnic, but not picnic from jaunt. When I try to use some network thing like telnet or ftp on picnic to talk to jaunt, I get the same thing every time: picnic:/usr2/chuckr/descent:203 >telnet jaunt Trying 206.246.122.119... telnet: Unable to connect to remote host: Permission denied I tried wrapping that in truss to see what's failing, and it's the connect call, with EACCESS. That's only supposed to happen to unix domain sockets (according to the man page) and since this is a inet socket, that's kinda confusing. Can anyone give me any hints as to what I could do next to troubleshoot this? Thanks. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 13:54:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14143 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 13:30:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13663 for ; Sun, 26 Apr 1998 13:24:31 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id QAA04313; Sun, 26 Apr 1998 16:23:50 -0400 (EDT) Date: Sun, 26 Apr 1998 16:23:50 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Studded cc: freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance In-Reply-To: <35438897.4CF24E7@san.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Speaking of threads, we're trying to get a solid db server running based on mysql for various web clients. MySQL depends on a good pthreads implementation. Currently we're using an old snap of -current, for both SMP and pthreads (which I don't believe were in 2.2 at the time). We're running into alot of problems with the server hanging or just giving really poor performance. We are talking to the author of mysql about getting commercial support, but he's not terribly keen on FBSD; he seems to like Linux and Solaris... :( Any recommendations on what to do to get the best performance here? I'd give up a CPU if I could get more stability and an easier target for Monty to troubleshoot on. Anyone else here use mysql? Any opinions? Should I try again with MIT-pthreads? Thanks, Charles To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 14:37:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20517 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 14:18:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA16699 for ; Sun, 26 Apr 1998 13:52:43 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yTXzw-0004vj-00; Sun, 26 Apr 1998 13:26:04 -0700 Date: Sun, 26 Apr 1998 13:25:16 -0700 (PDT) From: Tom To: Chuck Robey cc: FreeBSD-hackers@FreeBSD.ORG Subject: Re: network problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 26 Apr 1998, Chuck Robey wrote: > telnet: Unable to connect to remote host: Permission denied Incorrect ipfw configuration, at least for your requirements anyhow. This does not belong on freebsd-hackers. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 14:38:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21791 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 14:28:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18577 for ; Sun, 26 Apr 1998 14:04:35 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA23088; Sun, 26 Apr 1998 14:04:33 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd023025; Sun Apr 26 14:04:25 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA24424; Sun, 26 Apr 1998 14:04:22 -0700 (MST) From: Terry Lambert Message-Id: <199804262104.OAA24424@usr05.primenet.com> Subject: Re: threads performance To: Studded@san.rr.com (Studded) Date: Sun, 26 Apr 1998 21:04:22 +0000 (GMT) Cc: jkh@time.cdrom.com, toor@dyson.iquest.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <35438897.4CF24E7@san.rr.com> from "Studded" at Apr 26, 98 12:18:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is in support of the importance of getting some kind of > well-performing threads into -Stable as soon as practically possible. > One of my repeat customers who has been very happy with FreeBSD in the > past is developing a new Unix port of one of his very successful > programs. He asked me about FreeBSD's thread support and I told him > (honestly at the time) that I didn't know much about it but I'd set him > up an account on my -Stable box at home and let him test his stuff. 1) What version of -stable were you running? 2) Was it before or after Jeremy Allison's and my patches were committed? If before, you need the patched version of the libc_r code to have any chance of it working at all. 3) Is he using C++? If so, he must use FSF g++ 2.8.x or better with Jeremy's patches to libgcc.a to make exceptions work with threads (the patches were committed to the g++ port, I believe). 4) Is he depending on the C++ STL? If so, he needs the one from the Moscow Center for SPARC Computing, and he needs some additional patches (that haven't been committed, since STL is not widely supported in FreeBSD) to make it work with a Draft 4 pthreads (specifically, STL assumes that you can statically initialize mutexes, which is wrong). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 14:48:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24049 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 14:46:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23983 for ; Sun, 26 Apr 1998 14:45:27 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ([139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IWCU78NEO000005B@gatekeeper.alcatel.com.au> for hackers@FreeBSD.ORG; Mon, 27 Apr 1998 07:44:48 +1000 Received: from cbd.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #U2695) with ESMTP id <01IWCU75LX5CB4W21T@cim.alcatel.com.au> for hackers@FreeBSD.ORG; Mon, 27 Apr 1998 07:44:44 +1000 Received: from gsms01.alcatel.com.au by cbd.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IWCU720RC0AZTOVP@cbd.alcatel.com.au> for hackers@FreeBSD.ORG; Mon, 27 Apr 1998 07:44:38 +1100 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id HAA29582 for hackers@FreeBSD.ORG; Mon, 27 Apr 1998 07:44:37 +1000 (EST) Date: Mon, 27 Apr 1998 07:44:37 +1000 (EST) From: Peter Jeremy Subject: Re: VM architecture (was Re: Protected mode instructions which reduce to noop.) To: hackers@FreeBSD.ORG Message-id: <199804262144.HAA29582@gsms01.alcatel.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 23 Apr 1998 09:19:30 -0700 (PDT), patl@phoenix.volant.org wrote: >Subject: >From the context, I assumed that he was reffering to IBM's >mainframe system. (Originally VM/370 IIRC.) The origin was CP-67, although I'm not sure if that was a generally released product. On Thu, 23 Apr 1998 12:32:48 -0400 (EDT), "David E. Cross" wrote: > Intel, in their infinite wisdom, >decided that certain privledged instructions, if executed in an >unprivledged state, would not trap, but rather reduce to a NOP. According to my 486 reference manual, all privileged instructions cause an exception if executed in unpriviledged mode. What could cause a problem is that various bits in EFLAGS (IF comes to mind, but there may be others) can only be written in supervisor mode. Attempts to change these bits in user mode are just ignored (with no traps). The only other thing I can think of is confusion regarding `LOCK', which was priviledged on the 386, but became non-priviledged on the 486 (and presumably above). It's behaviour was also changed so that it became a NO-OP if used as a prefix on an inappropriate instruction (ie one that didn't do a memory RMW). Note that `virtual-86' mode provides a start. I don't think it's capable of supporting the full protected-mode environment though. On Fri, 24 Apr 1998 06:22:59 +0000 (GMT), Terry Lambert wrote: >The IBM VM architecture is logically complete -- that is, nearly all >of the instruction emulation implementation is in hardware, The VM kernel needs to provide a `virtual supervisor' mode. This can be quite expensive in software, so IBM provided microcode assist units which effectively made `virtual supervisor' mode part of the hardware machine mode. Pity that modern microprocessors don't have writable microcode. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 15:05:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25216 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 14:58:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24997 for ; Sun, 26 Apr 1998 14:56:13 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id VAA29790; Sun, 26 Apr 1998 21:56:10 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA29326; Sun, 26 Apr 1998 23:56:10 +0200 (MET DST) Message-ID: <19980426235610.22010@follo.net> Date: Sun, 26 Apr 1998 23:56:10 +0200 From: Eivind Eklund To: Julian Elischer , Alexander Matey Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Static ARP (IFF_NOARP usage in ethernet interfaces) References: <19980426183333.38119@hosix.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Julian Elischer on Sun, Apr 26, 1998 at 12:39:38PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 26, 1998 at 12:39:38PM -0700, Julian Elischer wrote: > I see no technical reason against this but > I'm curious why one would want to do this.. I can't imagine > a single reason for not wanting to do arp.. Security. You want to be able to force a particular MAC address to match a particular IP address, so people can't come with a different computer and take over the IP address of a known computer. Of course, with today's programmable ethernet cards, you also have to keep the MAC address secret for this strategy to be effective. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 15:19:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27469 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 15:16:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27288 for ; Sun, 26 Apr 1998 15:14:24 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id PAA21362; Sun, 26 Apr 1998 15:14:14 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: spork cc: Studded , freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance In-reply-to: Your message of "Sun, 26 Apr 1998 16:23:50 EDT." Date: Sun, 26 Apr 1998 15:14:14 -0700 Message-ID: <21358.893628854@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Any recommendations on what to do to get the best performance here? I'd > give up a CPU if I could get more stability and an easier target for Monty > to troubleshoot on. Anyone else here use mysql? Any opinions? Should I > try again with MIT-pthreads? It might give us a good data point. Hmmm... I wonder if John Birrell would be willing to hack performance issues in libc_r for money? :-) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 15:42:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26847 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 15:10:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dt050n33.san.rr.com (@dt050n33.san.rr.com [204.210.31.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21625 for ; Sun, 26 Apr 1998 14:26:53 -0700 (PDT) (envelope-from Studded@san.rr.com) Received: from san.rr.com (Studded@localhost [127.0.0.1]) by dt050n33.san.rr.com (8.8.8/8.8.8) with ESMTP id OAA06820; Sun, 26 Apr 1998 14:26:50 -0700 (PDT) (envelope-from Studded@san.rr.com) Message-ID: <3543A699.21C847E3@san.rr.com> Date: Sun, 26 Apr 1998 14:26:49 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE-0420 i386) MIME-Version: 1.0 To: Terry Lambert CC: freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance References: <199804262104.OAA24424@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > This is in support of the importance of getting some kind of > > well-performing threads into -Stable as soon as practically possible. > > One of my repeat customers who has been very happy with FreeBSD in the > > past is developing a new Unix port of one of his very successful > > programs. He asked me about FreeBSD's thread support and I told him > > (honestly at the time) that I didn't know much about it but I'd set him > > up an account on my -Stable box at home and let him test his stuff. > > 1) What version of -stable were you running? Whatever was in the repository on February 17th. I was cvsup'ing and building daily during that time period and I know that's the day he did the tests. > 2) Was it before or after Jeremy Allison's and my patches were > committed? If before, you need the patched version of the > libc_r code to have any chance of it working at all. I'm not sure, does the date above help you? > 3) Is he using C++? If so, he must use FSF g++ 2.8.x or better > with Jeremy's patches to libgcc.a to make exceptions work > with threads (the patches were committed to the g++ port, I > believe). Yes, he's using C++. I know he didn't use that version of g++ since I don't have it on my system. I also can't answer your last question, but with your permission I'll forward your post to him and ask if he's interested in working on this again. I can't discuss details of a client's project obviously, but I will say that I'm very interested in keeping him happy and it would be good for freebsd too, so I'm willing to do some legwork on this if there's hope of real progress. Thanks for your reply, Doug -- *** Chief Operations Officer, DALnet IRC network *** *** Proud designer and maintainer of the world's largest Internet *** Relay Chat server with 5,328 simultaneous connections. *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 15:43:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26640 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 15:10:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24080 for ; Sun, 26 Apr 1998 14:47:00 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA03682; Sun, 26 Apr 1998 14:46:59 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd003669; Sun Apr 26 14:46:53 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA05773; Sun, 26 Apr 1998 14:46:52 -0700 (MST) From: Terry Lambert Message-Id: <199804262146.OAA05773@usr02.primenet.com> Subject: Re: threads performance To: Studded@san.rr.com (Studded) Date: Sun, 26 Apr 1998 21:46:52 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <3543A699.21C847E3@san.rr.com> from "Studded" at Apr 26, 98 02:26:49 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 1) What version of -stable were you running? > > Whatever was in the repository on February 17th. I was cvsup'ing and > building daily during that time period and I know that's the day he did > the tests. > > > 2) Was it before or after Jeremy Allison's and my patches were > > committed? If before, you need the patched version of the > > libc_r code to have any chance of it working at all. > > I'm not sure, does the date above help you? Not really; it'd help Julian know, but I think the commits were in March, but I can't be sure about it, since I didn't do the commits. > > 3) Is he using C++? If so, he must use FSF g++ 2.8.x or better > > with Jeremy's patches to libgcc.a to make exceptions work > > with threads (the patches were committed to the g++ port, I > > believe). > > Yes, he's using C++. I know he didn't use that version of g++ since I > don't have it on my system. I don't know if Linux had it then, either. He may not be depending on the exceptions working wit threads. Note that they won't work on Linux, either. The EGCS compiler will work, but only if, at build time, you choose to include threads overhead in all programs, regardless of whether or not they actually use threads (a terrible design decision, IMO). > I also can't answer your last question, [ ... about STL usage ... ] > but > with your permission I'll forward your post to him and ask if he's > interested in working on this again. Go ahead; no problem. Anything anyone posts in a public forum without a limiting copyright implicitly cedes first publication rights. I couldn't stop you if I wanted to (and I don't). 8-). PS: if he is using STL, he should be using the Moscow code in any case; it's the SGI/HP code, with portability and other fixes; it's really the best STL out there, and it has explicit support for Linux, since the Linux C++ library implementations are kind of messed up due to reuse of parts of libio. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 16:52:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06415 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 16:36:26 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04228 for ; Sun, 26 Apr 1998 16:11:26 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id JAA14150; Mon, 27 Apr 1998 09:10:43 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199804262310.JAA14150@cimlogic.com.au> Subject: Re: threads performance In-Reply-To: <199804262104.OAA24424@usr05.primenet.com> from Terry Lambert at "Apr 26, 98 09:04:22 pm" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 27 Apr 1998 09:10:43 +1000 (EST) Cc: hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > 4) Is he depending on the C++ STL? If so, he needs the one > from the Moscow Center for SPARC Computing, and he needs > some additional patches (that haven't been committed, since > STL is not widely supported in FreeBSD) to make it work > with a Draft 4 pthreads (specifically, STL assumes that you > can statically initialize mutexes, which is wrong). FWIW, -current has support for static mutexes (draft 10). To fix the performance problem that people are seeing, I'll fix the signal handling to use a single set of sigactions for the process (as POSIX says) and dispatch signals immediately without using a thread as the signal handler (this was a bad idea from the beginning, but it was coded before the standard was released). This will mean that a signal handler won't need to call any functions which require locks, so these can be changed to simple spinlocks (with sched_yield) instead of using the (kernel) sigmask to make things atomic. It is the repeated calls to change (or check) the sigmask that are the killer as far as I can tell, but it depends on what the application is doing as to whether they get noticed. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 16:54:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06499 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 16:37:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terror.hungry.com (toshok@terror.hungry.com [199.181.107.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA02236 for ; Sun, 26 Apr 1998 15:52:23 -0700 (PDT) (envelope-from toshok@Hungry.COM) Received: (from toshok@localhost) by terror.hungry.com (8.9.0.Beta5/8.9.0.Beta5) id PAA27475; Sun, 26 Apr 1998 15:52:22 -0700 (PDT) To: freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance References: <199804260617.XAA27669@usr05.primenet.com> From: Christoph Toshok Date: 26 Apr 1998 15:52:21 -0700 In-Reply-To: tlambert@primenet.com's message of 25 Apr 1998 23:23:14 -0700 Message-ID: Lines: 93 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG tlambert@primenet.com (Terry Lambert) writes: > > > I'm working on japhar (the hungry java vm) and I'm primarily using > > freebsd for my work. One of the central "features" of japhar is that > > it uses platform's thread library -- pthreads on freebsd and linux, > > cthreads on nextstep and the hurd. > > > > On freebsd the performance is just abysmal. Really, it's *awful*. > > Just for kicks, I ported the thread api to NSPR (Netscape's Portable > > Runtime) and the runtime for javac compiling a trivial .java file > > drops from 39 seconds to 18 seconds. > > > This is a long post; sorry about that. Please read the whole thing; > I give a couple of possible causes for the problem, analysis, fixes > and workarounds, an analysis of why you are probably getting the > NSPR vs. pthreads results you are seeing, and an analysis of why > they mean that kernel threads probably wouldn't help in two of the > three possible root causes. > > -- 1 -- > > I'll assume you are running FreeBSD 2.2.6 or -current, since the > pthreads before those releases is not Draft 4 compliant, and you > should. If not, it may just be that you are using a buggy libc_r. yup. running 2.2.6 (well, post 2.2.6 -stable). > -- 2 -- > > More likely you are doing a compute intensive task, it's not > explicitly calling pthread_yield(), and other threads are not > running concurrently. but that's just it - the program (at least in this instance) isn't running multiple threads at all. > The pthreads implementation is a call conversion implemenetation. It > takes blocking calls and converts them into non-blocking calls plus a > context switch. right, this is exactly what NSPR does as well. > -- 3 -- > > The next most likely thing is that you are doing the same broken thing > the LDAP implementors did in their code. The problem is that it's not > obviously broken, so it's hard to steer clear of it. > > What they did was use getdtablesize(2) and/or sysctl(3) to get the > maximum possible number of fd's, and then pass that as the first > argument to select. > > The number was larger than FD_SETSIZE, and, as a result, select(2) > was returning "true" for the fd's off in space (some of which, when > dereferenced, pointed to 0, 1,and 2 as far as the kernel could tell). nope, nothing like this in japhar. > > The fact that NSPR can drop 21 seconds off the > > runtime (in this very contrived example) makes me think that there is > > a lot going on in libc_r that is suboptimal, but perhaps there is just > > no other way to implement things so they conform to the posix spec. > > The fact that NSPR can drop 21 seconds off the runtime means that > threading is not your bottleneck, and that kernel threads would > probably help, but only because the code is badly behaved. I'm about to delve into libc_r... the only thing I can think of that may be causing this disparity is the signal mask modification foo. I can only presume it's being invoked much more often than is necessary. There really is just no other explanation for the large difference in speed. I mean, HelloWorld.class runs about twice as fast on NSPR as libc_r. > NSPR can't implement kernel services that aren't there in the base > OS. That means that the best it can do is to build upon what's > already there. right. NSPR uses a scheme very similar to libc_r's (setjmp/longjmp) to implement threads on freebsd. > Most likely, you either have a run-away program (because of the select() > coding error or a similar problem), OR the NSPR implementation is making > explicit yield calls that the native implementation doesn't because it > assumes a kernel implementation of pthreads. nope. neither. I mean, NSPR might be making explicit yield calls, but those would only serve to slow things down in the single threaded case. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 17:29:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07907 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 16:48:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kaleb.keithley.belmont.ma.us (horizon4.camb.opengroup.org [130.105.39.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06727 for ; Sun, 26 Apr 1998 16:39:52 -0700 (PDT) (envelope-from k.#nojunk#keithley@opengroup.org) Received: from kaleb.keithley.belmont.ma.us (localhost [127.0.0.1]) by kaleb.keithley.belmont.ma.us (8.8.8/8.8.8) with SMTP id TAA00313 for ; Sun, 26 Apr 1998 19:46:19 -0400 (EDT) (envelope-from k.#nojunk#keithley@opengroup.org) Message-ID: <3543C749.167EB0E7@opengroup.org> Date: Sun, 26 Apr 1998 19:46:17 -0400 From: "Kaleb S. KEITHLEY" Organization: The Open Group X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 3.0-980311-SNAP i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: 3.0-980311-SNAP "upgrade" post mortem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, After being reasonably happy with the 3.0-971225-SNAP I decided to give the newest snap a try. Some general comments FYI and for your consideration. First I tried to upgrade, but the new snap didn't like the superblocks in my filesystems. Nothing in any of the .TXT files warned me about this. The only apparent solution was to newfs all my partitions. After that I fell back to a clean install, having lost the contents of my disks. That's okay, I didn't have anything that I couldn't restore (with a days worth of effort). Still it was surpising that the new snap didn't like my file systems. They'd fsck'ed fine under the prior snap. Oh, BTW, the new snap could mount the old / (as root_device, read-only) just fine, but when it tried to remount it read-write then it would fail. Second, my machine has two IDE controllers: controller 0 has a disk and the CD-ROM drive on it, controller 1 has another disk on it. Here's what mount says: /dev/wd0s2a on / /dev/wd0s2f on /usr /dev/wd0s2e on /var /dev/wd2s1f on /usr/X11 But at boot time I get this message: /kernel: changing root device to wd0s3a Slice 1 (wd0s1) is an OS/2 HPFS partition. Fdisk agrees that there's no partition/slice 3 or 4. Why does this message not say wd0s1a? Third, on all prior releases, including the prior snap, I could set my default route at boot in /etc/rc.network (route add default 130.105.39.20) and it would "stick" until such time as I brought up my ppp link. This doesn't work anymore. Should it? It is/was convenient. Using "add default HISADDR" in the ppp.conf doesn't work either as it tries to set it before the link is up, and that's no better than setting it at boot. -- Kaleb S. KEITHLEY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 17:33:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11981 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 17:27:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11524 for ; Sun, 26 Apr 1998 17:23:48 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id KAA14266; Mon, 27 Apr 1998 10:22:46 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199804270022.KAA14266@cimlogic.com.au> Subject: Re: threads performance In-Reply-To: <21358.893628854@time.cdrom.com> from "Jordan K. Hubbard" at "Apr 26, 98 03:14:14 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 27 Apr 1998 10:22:46 +1000 (EST) Cc: spork@super-g.com, Studded@san.rr.com, freebsd-hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan K. Hubbard wrote: > It might give us a good data point. Hmmm... I wonder if John Birrell > would be willing to hack performance issues in libc_r for money? :-) Well I wouldn't mind some money, but the truth is that I'm working on it anyway. (Damn, shot myself in the foot again!). I was working on locking things for use with kernel threads. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 18:44:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19401 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 18:42:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19136 for ; Sun, 26 Apr 1998 18:39:53 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id SAA01364; Sun, 26 Apr 1998 18:39:51 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Kaleb S. KEITHLEY" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 3.0-980311-SNAP "upgrade" post mortem In-reply-to: Your message of "Sun, 26 Apr 1998 19:46:17 EDT." <3543C749.167EB0E7@opengroup.org> Date: Sun, 26 Apr 1998 18:39:50 -0700 Message-ID: <1360.893641190@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > First I tried to upgrade, but the new snap didn't like the superblocks > in my filesystems. Nothing in any of the .TXT files warned me about > this. The only apparent solution was to newfs all my partitions. After That's bizarre - I've heard of no one else with such a problem. Are you positive it was the superblocks it didn't like? > like my file systems. They'd fsck'ed fine under the prior snap. Oh, BTW, > the new snap could mount the old / (as root_device, read-only) just > fine, but when it tried to remount it read-write then it would fail. And this was most definitely *not* the problem described in: ftp://ftp.freebsd.org/pub/FreeBSD/2.2.6-RELEASE/ERRATA.TXT ? Just making sure here before we go off on a chase. > But at boot time I get this message: > > /kernel: changing root device to wd0s3a You must have upgraded to a 3.0 SNAP that's still not entirely current. This cosmetic bogon was fixed last month sometime. > Third, on all prior releases, including the prior snap, I could set my > default route at boot in /etc/rc.network (route add default > 130.105.39.20) and it would "stick" until such time as I brought up my > ppp link. This doesn't work anymore. Should it? It is/was convenient. I don't think it should, if it's the tun0 device you're really talking about here. > Using "add default HISADDR" in the ppp.conf doesn't work either as it > tries to set it before the link is up, and that's no better than setting > it at boot. Which is why you put it in /etc/ppp/ppp.linkup Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 18:50:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19972 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 18:49:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19854 for ; Sun, 26 Apr 1998 18:47:02 -0700 (PDT) (envelope-from andrew@zeta.org.au) Received: from gurney.reilly.home (d13.syd2.zeta.org.au [203.26.11.13]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id LAA06098; Mon, 27 Apr 1998 11:41:11 +1000 Received: (from andrew@localhost) by gurney.reilly.home (8.8.8/8.8.5) id KAA14812; Mon, 27 Apr 1998 10:43:00 +1000 (EST) From: Andrew Reilly Message-Id: <199804270043.KAA14812@gurney.reilly.home> Date: Mon, 27 Apr 1998 10:43:00 +1000 (EST) Subject: Re: Context switch time To: gurney_j@resnet.uoregon.edu cc: gurney_j@efn.org, robert@cyrus.watson.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19980425034313.55993@hydrogen.nike.efn.org> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 25 Apr, John-Mark Gurney wrote: > as far as context switching goes... that is a difficult subject... Stanford > did a paper comparing a few os's on context switch time and found that > Linux was able to get about 10ms switch time, but this assumed that you > had only a couple active processes... as soon as you went above 10 active > processes the context switch time grew to be >100ms, while FreeBSD pretty > much maintained a steady 100ms switch time for even 1k processes, while > linux grew to >700ms... (these numbers are from the top of my head) One would hope that they're us times, rather than ms? -- Andrew "The steady state of disks is full." -- Ken Thompson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 20:42:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA01012 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 20:41:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00944 for ; Sun, 26 Apr 1998 20:40:15 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id XAA23095; Sun, 26 Apr 1998 23:39:13 -0400 (EDT) Date: Sun, 26 Apr 1998 23:39:13 -0400 (EDT) From: "Matthew N. Dodd" To: Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= cc: Alfred Perlstein , Hans Huebner , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 26 Apr 1998, Dag-Erling Coidan [iso-8859-1] Smørgrav wrote: > Yes, but that is not significant, because the Ethernet headers are > constructed in software, so you could in theory tell the link layer > driver to use a different MAC address; but then you'd have to run in > promiscuous mode constantly and sort packets in software, because > there's (generally) no way to tell the NIC to use a different address, > so it'd discard packets bearing your (fake) MAC address as destination > address. I've got an ethernet card here that allows an arbitrary number (well arbitrary to no more than 16) number of MAC addresses. Fairly nifty. I'm kind of puzzled at how this would be integrated with the SIOCGHWADDR/SIOCSHWADDR calls as you might also need a way of determining which hadware address to set/get :) /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 21:04:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03955 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 21:02:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mozart.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03904 for ; Sun, 26 Apr 1998 21:01:58 -0700 (PDT) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by mozart.canonware.com (8.8.8/8.8.7) with SMTP id UAA00822; Sun, 26 Apr 1998 20:59:23 -0700 (PDT) (envelope-from jasone@canonware.com) X-Authentication-Warning: mozart.canonware.com: jasone owned process doing -bs Date: Sun, 26 Apr 1998 20:59:22 -0700 (PDT) From: Jason Evans To: John Birrell cc: hackers@FreeBSD.ORG Subject: Re: threads performance In-Reply-To: <199804262310.JAA14150@cimlogic.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, John Birrell wrote: > To fix the performance problem that people are seeing, I'll fix > the signal handling to use a single set of sigactions for the process > (as POSIX says) and dispatch signals immediately without using a > thread as the signal handler (this was a bad idea from the beginning, > but it was coded before the standard was released). Yay! Thanks for working on this, John. Jason Jason Evans Email: [jasone@canonware.com] Web: [http://www.canonware.com/~jasone] Home phone: [(650) 856-8204] Work phone: [(408) 774-8007] Quote: ["Invention is 1% inspiration and 99% perspiration" - Thomas Edison] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 22:58:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA21170 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 22:58:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from emu.melbpc.org.au (emu.melbpc.org.au [203.12.152.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21154 for ; Sun, 26 Apr 1998 22:58:05 -0700 (PDT) (envelope-from billm@melbpc.org.au) Received: from melbpc.org.au (root@dingo16.melbpc.org.au [203.12.157.16]) by emu.melbpc.org.au (8.8.7/8.8.6) with ESMTP id PAA29953; Mon, 27 Apr 1998 15:57:44 +1000 (EST) Received: (from melbpc@localhost) by melbpc.org.au (8.8.8/8.8.8/Debian/GNU) id NAA01120; Mon, 27 Apr 1998 13:09:34 +1000 From: Bill Metzenthen Message-Id: <199804270309.NAA01120@melbpc.org.au> Subject: Re: math library To: proff@iq.org, marc@bowtie.nl, freebsd-hackers@FreeBSD.ORG Date: Mon, 27 Apr 1998 13:09:33 +1000 (EST) Reply-To: billm@melbpc.org.au X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Assange wrote: > libmsun has been extensively tested to confirm correct calculation in > a variety of pathological circumstances. The 9% difference you are seeing > is probably related to this. I would NOT trust the linux libm for ANY > scientific calculation. Linux is moving to glibc. I feel sure that the people working on glibc would appreciate any contribution to improving their libm. > I ported the linux libm to FreeBSD because of the 100% difference in > speed I was seeing during the rendering phase of a scientific > visualisation project I was working on. Rendering is not a process > especially prone to error amplification or pathological conditions, > yet I was seeing a clear difference in results between the two > libraries - so much so that I was unable to use Linux and FreeBSD > boxes together in a distributed rendering environment. Often results > like this can be attributed to machines with different fp word-lengths, > or random number generators, (assuming an iterative process), but both > the linux and FreeBSD machines were 586's, running my own PRN > generation code. My observation of messages appearing in the newsgroups is that the reasons for such differences can often be traced back to the precision setting which is used for the x87 FPU on Linux. The commonly used start-up code on Linux currently (and has for some time) sets the FPU to 64 bit precision. Some other x86 operating systems use 53 bits. This will lead to different results -- independent of the quality of the libm implementation. Whether you get "better" results with one precision setting or the other depends upon: (1) what you define as "better" -- pseudo-religious arguments can enter here, and (2) the particular code and data which you try. I once issued a challenge to the 53 bit school to show that their approach gave "better" results for most computations, but I saw not one attempt at an answer. To be fair, few people probably saw my message. It is possible (under C, etc) for a programmer to set the precision (e.g. to 53 bits) for his own programs. The code which I have on my web pages on suburbia.net makes this easy to do for C on Linux (not that it is difficult to do anyway). Cheers, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 23:17:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA23878 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 23:17:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kaleb.keithley.belmont.ma.us (horizon4.camb.opengroup.org [130.105.39.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA23873 for ; Sun, 26 Apr 1998 23:17:11 -0700 (PDT) (envelope-from k.#nojunk#keithley@opengroup.org) Received: from kaleb.keithley.belmont.ma.us (localhost [127.0.0.1]) by kaleb.keithley.belmont.ma.us (8.8.8/8.8.8) with SMTP id CAA06393 for ; Mon, 27 Apr 1998 02:23:41 -0400 (EDT) (envelope-from k.#nojunk#keithley@opengroup.org) Message-ID: <3544246C.2781E494@opengroup.org> Date: Mon, 27 Apr 1998 02:23:40 -0400 From: "Kaleb S. KEITHLEY" Organization: The Open Group X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 3.0-980311-SNAP i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: 3.0-980311-SNAP "upgrade" post mortem References: <1360.893641190@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan K. Hubbard wrote: > > > First I tried to upgrade, but the new snap didn't like the superblocks > > in my filesystems. Nothing in any of the .TXT files warned me about > > this. The only apparent solution was to newfs all my partitions. After > > That's bizarre Yes, I thought so too. I'll be happy to provide any additional information for anyone who might be interested. > - I've heard of no one else with such a problem. You heard it here first. :-} > Are you > positive it was the superblocks it didn't like? Yup. When I started with the upgrade I was careful to toggle the newfs bits "off" in the fdisk/disklabel. I only told it about my wd0s2x partitions, with the expectation that when the upgrade was done I'd reboot with the saved fstab and my wd2s1 disk would be okay. As the upgrade proceeded it wouldn't mount the wd0s2x partitions (tried mounting them by hand in the emergency holographic shell and got the bad superblock error) and thus it couldn't backup my /etc before proceeding. (The install process gave me the "option" of treating this as a serious failure and aborting. Don't know what it would have done if I hadn't aborted.) So I proceeded to do a clean install, being careful to never touch wd2s1 and after all was said and done, when I tried mounting wd2s1f by hand, or fscking it, I got the bad superblock error on it too. (BTW, What's the fdisk/disklabel utility that's on the boot floppy, and why can't the "real" fdisk and disklabel utilities be replaced with that?) > > > like my file systems. They'd fsck'ed fine under the prior snap. Oh, BTW, > > the new snap could mount the old / (as root_device, read-only) just > > fine, but when it tried to remount it read-write then it would fail. > > And this was most definitely *not* the problem described in: > > ftp://ftp.freebsd.org/pub/FreeBSD/2.2.6-RELEASE/ERRATA.TXT ? > > Just making sure here before we go off on a chase. I went from 2.2.2-RELEASE to the 3.0-971225-SNAP without any problem. I don't really remember what the remount error was at this point, but that may well have been the problem. For instance in single-user mode I tried `mount -u /` and a bunch of other things which are getting hazy, but I'd wager I never tried `mount -u /dev/wd0s2a /'. I probably only used the old wd0a "compatibility" name. But that definitely wasn't the problem with mounting any of the other partitions. > > > But at boot time I get this message: > > > > /kernel: changing root device to wd0s3a > > You must have upgraded to a 3.0 SNAP that's still not entirely current. > This cosmetic bogon was fixed last month sometime. I did qualify it as the 3.0-980311-SNAP. That was, and still is the only snap that's on ftp.cdrom.com/ftp.freebsd.org. Is there a newer snap somewhere else? What file or files should I get from -current to make this bogon go away? (Or do I have to go on a search-and-destroy mission in the kernel sources? :-) > > > Third, on all prior releases, including the prior snap, I could set my > > default route at boot in /etc/rc.network (route add default > > 130.105.39.20) and it would "stick" until such time as I brought up my > > ppp link. This doesn't work anymore. Should it? It is/was convenient. > > I don't think it should, if it's the tun0 device you're really talking > about here. > > > Using "add default HISADDR" in the ppp.conf doesn't work either as it > > tries to set it before the link is up, and that's no better than setting > > it at boot. > > Which is why you put it in /etc/ppp/ppp.linkup Yes, that sounds like just the thing. Thank you. -- Kaleb S. KEITHLEY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 23:28:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA26153 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 23:28:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26147 for ; Sun, 26 Apr 1998 23:28:54 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id XAA27185; Sun, 26 Apr 1998 23:28:15 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma027183; Sun Apr 26 23:28:14 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id XAA28527; Sun, 26 Apr 1998 23:28:14 -0700 (PDT) From: Archie Cobbs Message-Id: <199804270628.XAA28527@bubba.whistle.com> Subject: Re: FreeBSD HA configuration / Ethernet address takeover In-Reply-To: <199804251913.MAA00572@antipodes.cdrom.com> from Mike Smith at "Apr 25, 98 12:13:57 pm" To: mike@smith.net.au (Mike Smith) Date: Sun, 26 Apr 1998 23:28:13 -0700 (PDT) Cc: hans@artcom.de, freebsd-hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith writes: > > Looking at the ifconfig manpage, I could not find a general way to set a > > Ethernet card's MAC address. Is there a documented solution to this > > problem? If not, would adding such functionality be problematic? > > Many network adapters sold into the PC market do not allow the MAC > address to be changed from the factory-assigned value. Because of > this, FreeBSD does not offer the facility to change the address (as it > wouldn't be a general solution). But for those cards that don't support it, FreeBSD could "spoof" it by putting the card in promiscuous mode and filtering destination Ethernet address in software. Although inefficient, it would work.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 26 23:50:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA29446 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 23:50:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.artcom.de ([192.76.129.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA29374 for ; Sun, 26 Apr 1998 23:50:27 -0700 (PDT) (envelope-from hans@artcom.de) Received: from transrapid.artcom.de by mail.artcom.de with smtp id m0yThji-000008C; Mon, 27 Apr 1998 08:49:58 +0200 (MEST) Date: Mon, 27 Apr 1998 08:49:58 +0200 (MEST) From: Hans Huebner Reply-To: Hans Huebner To: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 26 Apr 1998, Matthew N. Dodd wrote: > I've got an ethernet card here that allows an arbitrary number (well > arbitrary to no more than 16) number of MAC addresses. Fairly nifty. > I'm kind of puzzled at how this would be integrated with the > SIOCGHWADDR/SIOCSHWADDR calls as you might also need a way of determining > which hadware address to set/get :) After thinking about this for a weekend, I've come to the conclusion that multiple ethernet addresses for one logical ethernet interface would not be a good idea: Not only would it complicate many utility programs, it would also add ambiguity to the many-to-one mapping of an IP address to an Ethernet address. If multiple logical Ethernet interfaces on one physical interface would be needed, that should be implemented by adding the notion of multiple logical interfaces attachable to one physical interface. Solaris does it like that, and I found the approach consistent and straightforward: Instead of defining additional IP addresses for one interface, you clone the primary interface and get an additional, logical ethernet interface which can be configured using ifconfig similar to a real interface. Such a logical interface would also be the right place to assign another hardware address to an IP address, if the ethernet adapter supports that. I'm unsure whether Solaris supports that, though. This leaves the question whether the SIOC[GS]IFHWADDR ioctl's should be implemented the way Linux does this, that is: unsigned char hwaddr[6]; set address: ioctl(sockfd, SIOCGIFHWADDR, hwaddr); get address: ioctl(sockfs, SIOCSIFHWADDR, hwaddr); Comments anyone? -Hans P.S.: Please people. Stop trying to tell me that my approach is stupid. I know that there are application level redundancy mechanisms, and I also know how to configure some of them. I still want to do it like this for several reasons, and others seem to be interested in a way to change hardware addresses as well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 00:08:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA04128 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 00:08:02 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA04079 for ; Mon, 27 Apr 1998 00:07:55 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id AAA00337; Mon, 27 Apr 1998 00:07:54 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd000329; Mon Apr 27 00:07:50 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id AAA02669; Mon, 27 Apr 1998 00:07:46 -0700 (MST) From: Terry Lambert Message-Id: <199804270707.AAA02669@usr09.primenet.com> Subject: Re: threads performance To: jasone@canonware.com (Jason Evans) Date: Mon, 27 Apr 1998 07:07:46 +0000 (GMT) Cc: jb@cimlogic.com.au, hackers@FreeBSD.ORG In-Reply-To: from "Jason Evans" at Apr 26, 98 08:59:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 27 Apr 1998, John Birrell wrote: > > To fix the performance problem that people are seeing, I'll fix > > the signal handling to use a single set of sigactions for the process > > (as POSIX says) and dispatch signals immediately without using a > > thread as the signal handler (this was a bad idea from the beginning, > > but it was coded before the standard was released). > > Yay! Thanks for working on this, John. Please use ACAP as one of your test programs. I think I can provide (or get Jeremy to provide) the patches to ACAP to make it work on FreeBSD. As far as I know, we have the only ACAP that runs under g++. The main problem will be running it interactively and seeing if ^C works. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 00:13:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA04960 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 00:13:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA04952 for ; Mon, 27 Apr 1998 00:13:53 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id RAA15123; Mon, 27 Apr 1998 17:13:14 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199804270713.RAA15123@cimlogic.com.au> Subject: Re: threads performance In-Reply-To: <199804270707.AAA02669@usr09.primenet.com> from Terry Lambert at "Apr 27, 98 07:07:46 am" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 27 Apr 1998 17:13:13 +1000 (EST) Cc: jasone@canonware.com, jb@cimlogic.com.au, hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > Please use ACAP as one of your test programs. Do you mean me or Jason? Sorry for having to ask that, but you sent the reply to Jason's mail. I'm so easily confused. 8-) > I think I can provide (or get Jeremy to provide) the patches to > ACAP to make it work on FreeBSD. Please. > > As far as I know, we have the only ACAP that runs under g++. > > The main problem will be running it interactively and seeing if > ^C works. I'll do this with -current first, but there should be no problems with 2.2.X eventually. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 00:47:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA10151 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 00:47:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA10140 for ; Mon, 27 Apr 1998 00:47:06 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA26213 for ; Mon, 27 Apr 1998 00:43:45 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd026211; Mon Apr 27 07:43:45 1998 Date: Mon, 27 Apr 1998 00:38:19 -0700 (PDT) From: Julian Elischer To: hackers@FreeBSD.ORG Subject: RFC: IPFW/DIVERT change suggestion. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When we write the DIVERT facility we made a rather foolish design decision and I'd like to suggest a change that would alter the semantics of DIVERT/IPFW to fix it.. here is the problem: If you divert a packet out to a utility (e.g.NATD) then when it re-injects the packet, it is given an 'immunity' to that firewall rule, so that it won't be REDIVERTED again. this is because reinjected packets are resubmitted to the firewall. This precludes the use of more than one DIVERT filter. consider: A packet is diverted by rule 100 to utility A (e.g. natd). On reinjection, it bypassed rule 100 and is diverted at rule 200 to utility Y (e.g. cryptd). On reinjection again, it has lost it's Immunity to rule 100 so it's diverted to utility X (which will probably throw it away). Either one of the filters will discard it, or it will enter an infinite loop. What can we do about this? 1/ change the semantics of reinjection so that the number presently used to indicate the rule to be immune to, is interpretted as the rule after which processing should restart. '1' would indicate "start again at the beginning. returning the same number as reported by the utility on reception (we would report the rule number rather than the port number) would make processing restart at the next rule after the divert. By specifying the correct number you could make processed packets jump into a special set of rules (for example). All present programs need to set the value to that they received, which they transparently pass because if they didn't they would get rediversion. thus all existing programs would get teh behaviour of continuing the examination of packets at the next rule after the divert. This does tie ipfw and divert closer together. 2/ remember the last N packets diverted, and assign each an ID which can be associated with the returned packet, and which could be use to track where in the filter it was. (I'm not crazy about this one, but it could be done) The ONE positive point for this would be that it might be possible to store a 'stack' for each packet so that we could add 'gosub' (heh) to ipfw.. (just seeing if you're reading) (any other ideas?) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 01:01:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA12853 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 01:01:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA12839 for ; Mon, 27 Apr 1998 01:01:30 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id BAA02840; Mon, 27 Apr 1998 01:01:30 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Kaleb S. KEITHLEY" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 3.0-980311-SNAP "upgrade" post mortem In-reply-to: Your message of "Mon, 27 Apr 1998 02:23:40 EDT." <3544246C.2781E494@opengroup.org> Date: Mon, 27 Apr 1998 01:01:29 -0700 Message-ID: <2835.893664089@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > saved fstab and my wd2s1 disk would be okay. As the upgrade proceeded it > wouldn't mount the wd0s2x partitions (tried mounting them by hand in the > emergency holographic shell and got the bad superblock error) and thus > it couldn't backup my /etc before proceeding. (The install process gave Hmmmm! Extreme oddness. > (BTW, What's the fdisk/disklabel utility that's on the boot floppy, and > why can't the "real" fdisk and disklabel utilities be replaced with > that?) Tradition. :) You could always make little function aliases for /stand/sysinstall's internal functions, of course, ala: fdisk() { /stand/sysinstall diskPartitionEditor } disklabel { /stand/sysinstall diskLabelEditor } I suppose... > I did qualify it as the 3.0-980311-SNAP. That was, and still is the only > snap that's on ftp.cdrom.com/ftp.freebsd.org. Is there a newer snap > somewhere else? What file or files should I get from -current to make ftp://current.freebsd.org/pub/FreeBSD/ Always contains the very latest snaps for both 3.0 and 2.2 branches. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 01:08:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA14194 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 01:08:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zyqad.co.uk (zyqad.demon.co.uk [158.152.135.161]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA14144; Mon, 27 Apr 1998 01:08:17 -0700 (PDT) (envelope-from john@zyqad.co.uk) Received: from localhost by zyqad.co.uk; (5.65/1.1.8.2/21Apr95-0317PM) id AA19035; Mon, 27 Apr 1998 08:56:48 +0100 Message-Id: <9804270756.AA19035@zyqad.co.uk> To: freebsd-questions@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Euro key ? In-Reply-To: Your message of "Wed, 22 Apr 98 08:28:20 EDT." <353DE264.2F1CF0FB@opengroup.org> Date: Mon, 27 Apr 98 08:56:48 +0100 From: "John Richards" X-Mts: smtp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG All, You are all making far too much of all this. Once all the european countries are in the Euro we can replace the local currency, symbol keycode 243 in UK, with the Euro symbol and everything works out OK. National currencies will hopefully then cease to exist - despite our Euro-sceptics and the banks will be unable to fleece on every currency exchange. Of course for those countries that don't have a special currency sign they can just replace the British one - once we join up! > remy@synx.com wrote: > > On 22 Apr, Soren Schmidt wrote: > > > In reply to Walter Hafner who wrote: > > >> The symbol for the Euro... > > > > > > Yeah but where is it in the iso8859-1 page ?? > > > > No hurry. Let's wait to see what funny code the Wxx will return, put it > > on keyboard mapping, and let European users fontedit the X fonts to have > > things match. > > Editing ISO8859-x fonts is far from the right thing to do. > > Making X display the Euro glyph is easy, but there are larger problems > than X. > > For example, if you fontedit your ISO8859-x fonts to change the currency > glyph (code point 0xa4) to the Euro glyph, that'll make it possible for > things to look nice on your screen, but then you're not going to get the > same thing on a piece of paper when you print that file. > > ISO needs to do two things. First they need to define an ISO2022 escape > sequence that you can use switch to a codeset that defines the Euro. > Second, they need to define that new codeset that contains the Euro, and > all the other miscellaneous currency characters, e.g. that are defined > in Unicode/ISO10646 but not in any other character set. (Perhaps they've > already done this?) > > I already have a query in to ISO about those two things. Whether they > can act quickly enough to produce something usable is a different > question. Perhaps I presume too much when I think that there's a risk > that they'll come back and say "it's in Unicode, use Unicode." Is > everyone ready to switch en mass to Unicode? > > In the mean time the X11 specifications and the Sample Implementation > are being augmented with new keysyms, one or more new fonts, and a > non-standard escape sequence to switch between codesets. Once ISO > defines a standard escape sequence then the SI will be changed > accordingly. > > (Now the rest of the world gets to learn how to deal with codeset > switching, which the Japanese have been doing for years. All thanks to > the Euro. :-) > > -- > > Kaleb S. KEITHLEY > X Architect, The Open Group X Project Team > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message Bye John (Play Violin & Ride Bike - but not at the same time) ******************************************************************************* John Richards * email : john@zyqad.co.uk Zyqad Ltd, * John.E.Richards@Aspentech.com Suite 25, The Business Park, * Technology Drive, Beeston * tel : +44 115 922 0820 NOTTINGHAM. NG9 2ND. * fax : +44 115 967 8374 ******************************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 02:01:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA22796 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 02:01:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA22784 for ; Mon, 27 Apr 1998 02:01:05 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id LAA00232; Mon, 27 Apr 1998 11:01:00 +0200 (MET DST) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Mon, 27 Apr 1998 11:00:59 +0200 (MET DST) Mime-Version: 1.0 To: "Matthew N. Dodd" Cc: "Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= =?iso-8859-1?Q?=2C?= Alfred Perlstein" , Hans Huebner , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover References: Organization: Gutteklubben Terrasse / KRST / PUMS / YASMW X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-Stop-Spam: http://www.cauce.org From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 27 Apr 1998 11:00:58 +0200 In-Reply-To: "Matthew N. Dodd"'s message of "Sun, 26 Apr 1998 23:39:13 -0400 (EDT)" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Matthew N. Dodd" writes: > I'm kind of puzzled at how this would be integrated with the > SIOCGHWADDR/SIOCSHWADDR calls as you might also need a way of determining > which hadware address to set/get :) No. You can set any arbitrary MAC address, but it will make a heavy impact on network performance, since much of what is usually done in hardware (discarding packets not meant for you) will have to be done in software. -- Noone else has a .sig like this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 02:08:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA24237 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 02:08:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA24222 for ; Mon, 27 Apr 1998 02:08:12 -0700 (PDT) (envelope-from erakupa@kk.etx.ericsson.se) Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-1.12) with SMTP id LAA04530 for ; Mon, 27 Apr 1998 11:07:19 +0200 (MET DST) Received: from kk662.kk.etx.ericsson.se by kkb3 (SMI-8.6/LME-2.2.6) id LAA04237; Mon, 27 Apr 1998 11:06:57 +0200 From: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) Received: by kk662.kk.etx.ericsson.se (SMI-8.6/client-1.6) id LAA08665; Mon, 27 Apr 1998 11:06:58 +0200 Date: Mon, 27 Apr 1998 11:06:58 +0200 Message-Id: <199804270906.LAA08665@kk662.kk.etx.ericsson.se> To: hackers@FreeBSD.ORG Subject: how to get number of instructions in a prg X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What is the easiest way to count the number of assembler instructions in a program? In gdb there is the "disassemble function-name" command, but it disassembles only the given function. One could of course call this several times and each time count the lines, but since a program can have several hundred small sub-functions, this method is not the best... Thanks in advance, Martti To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 02:30:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA27965 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 02:30:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA27928 for ; Mon, 27 Apr 1998 02:30:04 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yTjpI-0005PZ-00; Mon, 27 Apr 1998 02:03:52 -0700 Date: Mon, 27 Apr 1998 02:03:51 -0700 (PDT) From: Tom To: spork cc: Studded , freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 26 Apr 1998, spork wrote: > to troubleshoot on. Anyone else here use mysql? Any opinions? Should I > try again with MIT-pthreads? mit-pthreads is quite solid on FreeBSD 2.2.6-stable, and a bit faster than libc_r at the current time... mysql plus the libc_r in the latest -stable works ok, but is a bit slower, and "mysqladmin shutdown" does not work. All test complete ok though. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 03:06:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA04342 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 03:06:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA04330 for ; Mon, 27 Apr 1998 03:06:04 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA24696; Mon, 27 Apr 1998 10:28:35 +0200 From: Luigi Rizzo Message-Id: <199804270828.KAA24696@labinfo.iet.unipi.it> Subject: Re: RFC: IPFW/DIVERT change suggestion. To: julian@whistle.com (Julian Elischer) Date: Mon, 27 Apr 1998 10:28:35 +0200 (MET DST) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Apr 27, 98 00:38:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > When we write the DIVERT facility we made a rather foolish design decision > and I'd like to suggest a change that would alter the semantics > of DIVERT/IPFW to fix it.. same conclusion here... > What can we do about this? i think the most reasonable view of the "divert" process is to see it as a graph where a pkt is forwarded. So we need to associate a set of rules to each node of the graph, and a matching rule also needs to specify the 'destination' node where to restart processing. So i would add a parameter to divert-like rules where you specify the next rule to continue processing. In a sense, this is similar to the first approach you propose, except that the 'destination' can be interpreted as a "jump". (there is no need to modify simple actions like allow/deny since the decision is final.) > would be that it might be possible to store a 'stack' for each packet > so that we could add 'gosub' (heh) to ipfw.. (just seeing if you're > reading) don't like the idea of 'subroutines' very much, i doubt it would be of much use in practice, and lot of work to implement it. 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/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 03:50:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA12586 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 03:50:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA12580 for ; Mon, 27 Apr 1998 03:50:15 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id DAA28913; Mon, 27 Apr 1998 03:45:04 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028894; Mon Apr 27 10:45:03 1998 Date: Mon, 27 Apr 1998 03:39:36 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: RFC: IPFW/DIVERT change suggestion. In-Reply-To: <199804270828.KAA24696@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, Luigi Rizzo wrote: > > i think the most reasonable view of the "divert" process is to see > it as a graph where a pkt is forwarded. So we need to associate > a set of rules to each node of the graph, and a matching rule also > needs to specify the 'destination' node where to restart processing. The trouble with this approach is that the filter program needs to be able to specify where to go, as it might generate 2 packets from one incoming (imagine a compression filter). Also where would you store that information while the packet is out in user-land? This what why I suggested keeping info in the kernel for the last N packets (option 2). But I'm not crazy about that idea. > > So i would add a parameter to divert-like rules where you specify > the next rule to continue processing. > In a sense, this is similar to the first approach you propose, except > that the 'destination' can be interpreted as a "jump". > (there is no need to modify simple actions like allow/deny since the > decision is final.) what about a filter that looks at packets and makes a decision to send it back to one of 2 differnt rules? > > > would be that it might be possible to store a 'stack' for each packet > > so that we could add 'gosub' (heh) to ipfw.. (just seeing if you're > > reading) > > don't like the idea of 'subroutines' very much, i doubt it would be > of much use in practice, and lot of work to implement it. you would also need local variables etc. it would become a whole language.. :-b ipfw-basic ;-) (someone would write a fortran compiler in it..) I've done 99% of a IPFW/divert using daemon that watches incoming traffic and tries to slow down sessions that look like they are monopolising the link. I should have it running tomorrow sometime. Re: dummynet: I'm not sure that providing queueing for TCP streams will provide an efficient manner of flow control. you eventually will need to drop a packet to get a window-size down to a size you like, other wise you will end up having to store a whole window's worth of data (16K on average I guess) for every TCP session. How do your results look for incoming control? what do you use for policy? (which sessions get what bandwidth?) Our BW limiter is basically similar to the scheduler in that long-running sessions get lower priority and sessions that have unused allocations get a higher priority when they eventually get data. The aim is to keep interactive response while allowing FTPs to continue at reduced throughput in the background. each 'tick' priorities are re-evaluated. presently it's a user mode daemon fro testing using DIVERT. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 04:22:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA17370 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 04:22:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id EAA17332 for ; Mon, 27 Apr 1998 04:22:03 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA24888; Mon, 27 Apr 1998 11:41:33 +0200 From: Luigi Rizzo Message-Id: <199804270941.LAA24888@labinfo.iet.unipi.it> Subject: Re: RFC: IPFW/DIVERT change suggestion. To: julian@whistle.com (Julian Elischer) Date: Mon, 27 Apr 1998 11:41:33 +0200 (MET DST) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Apr 27, 98 03:39:17 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > i think the most reasonable view of the "divert" process is to see > > it as a graph where a pkt is forwarded. So we need to associate ... > The trouble with this approach is that the filter program needs to be able > to specify where to go, as it might generate 2 packets from one incoming > > Also where would you store that information while the packet is out in > user-land? This what why I suggested keeping info in the kernel > for the last N packets (option 2). But I'm not crazy about that idea. i don't see the problem. In any case the pointer to the rule that you wanted to add to the mbuf header does the job nicely, it seems to me. > what about a filter that looks at packets and makes a decision to send it > back to one of 2 differnt rules? this is exactly it: one rule is the next in numeric order, the other one is the one specified by the rule. > How do your results look for incoming control? > what do you use for policy? (which sessions get what bandwidth?) dummynet was written for testing purposes, not for bw policing. But it has bounded size buffers so packets are dropped after a while. 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/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 05:01:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA24413 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 05:01:26 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA24400 for ; Mon, 27 Apr 1998 05:01:18 -0700 (PDT) (envelope-from hans@news.IAEhv.nl) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 4054 on Mon, 27 Apr 1998 12:01:08 GMT; id MAA04054 efrom: hans; eto: UNKNOWN Received: by truk.brandinnovators.com (8.8.7/BI96070101) for id NAA03971; Mon, 27 Apr 1998 13:55:43 +0200 (CEST) Message-Id: <199804271155.NAA03971@truk.brandinnovators.com> From: hans@brandinnovators.com (Hans Zuidam) Subject: Re: how to get number of instructions in a prg In-Reply-To: <199804270906.LAA08665@kk662.kk.etx.ericsson.se> from ETX-B-SL Martti Kuparinen at "Apr 27, 98 11:06:58 am" To: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) Date: Mon, 27 Apr 1998 13:55:43 +0200 (CEST) Cc: hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ETX-B-SL Martti Kuparinen wrote: > What is the easiest way to count the number of assembler instructions > in a program? Hmmmm... what about: objdump --disassemble file | wc -l minus 4 header lines. (objdump is in the GNU binutils toolset, sadly not in ports...) Hope this helps, Hans -- H. Zuidam E-Mail: hans@brandinnovators.com Brand Innovators B.V. P-Mail: P.O. Box 1377 de Pinckart 54 5602 BJ Eindhoven, The Netherlands 5674 CC Nuenen Tel. +31 40 2631134, Fax. +31 40 2831138 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 05:09:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA25918 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 05:09:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ntu-kpi.kiev.ua (root@ntu-kpi.kiev.ua [195.178.136.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA25905 for ; Mon, 27 Apr 1998 05:09:20 -0700 (PDT) (envelope-from lx@hosix.ntu-kpi.kiev.ua) Received: from fobos.ntu-kpi.kiev.ua (fobos.ntu-kpi.kiev.ua [10.100.0.6]) by ntu-kpi.kiev.ua (8.8.8/8.7.3) with ESMTP id PAA19421; Mon, 27 Apr 1998 15:05:21 +0300 (EEST) Received: from hosix.ntu-kpi.kiev.ua (lx.hosix.ntu-kpi.kiev.ua [10.100.23.72]) by fobos.ntu-kpi.kiev.ua (unknown/censored) with ESMTP id PAA07689; Mon, 27 Apr 1998 15:05:20 +0300 (EEST) Received: (from lx@localhost) by hosix.ntu-kpi.kiev.ua (8.8.8/8.8.7) id PAA00389; Mon, 27 Apr 1998 15:05:20 +0300 (EEST) (envelope-from lx) Message-ID: <19980427150520.39431@hosix.ntu-kpi.kiev.ua> Date: Mon, 27 Apr 1998 15:05:20 +0300 From: Alexander Matey To: Eivind Eklund , Julian Elisher Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Static ARP (IFF_NOARP usage in ethernet interfaces) References: <19980426183333.38119@hosix.ntu-kpi.kiev.ua> <19980426235610.22010@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <19980426235610.22010@follo.net>; from Eivind Eklund on Sun, Apr 26, 1998 at 11:56:10PM +0200 Organization: Hostel #6, NTUU /KPI/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 26, 1998 at 11:56:10PM +0200, Eivind Eklund wrote: > > I see no technical reason against this but > > I'm curious why one would want to do this.. I can't imagine > > a single reason for not wanting to do arp.. > > Security. You want to be able to force a particular MAC address to > match a particular IP address, so people can't come with a different > computer and take over the IP address of a known computer. Yes, security. I my situation it stands for about 50 computers on 4 ethernet subnets, some of them do have internet access while the others don't. bye, lx. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 05:28:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA29128 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 05:28:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ceia.nordier.com (m1-30-dbn.dial-up.net [196.34.155.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA29111 for ; Mon, 27 Apr 1998 05:28:34 -0700 (PDT) (envelope-from rnordier@iafrica.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.8/8.6.12) id OAA00569; Mon, 27 Apr 1998 14:26:15 +0200 (SAT) From: Robert Nordier Message-Id: <199804271226.OAA00569@ceia.nordier.com> Subject: Re: how to get number of instructions in a prg In-Reply-To: <199804270906.LAA08665@kk662.kk.etx.ericsson.se> from ETX-B-SL Martti Kuparinen at "Apr 27, 98 11:06:58 am" To: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) Date: Mon, 27 Apr 1998 14:26:12 +0200 (SAT) Cc: hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ETX-B-SL Martti Kuparinen wrote: > What is the easiest way to count the number of assembler instructions > in a program? > > In gdb there is the "disassemble function-name" command, but it > disassembles only the given function. One could of course call this > several times and each time count the lines, but since a program can > have several hundred small sub-functions, this method is not the best... Many compilers will output assembler language if required. So, if you're working from source code, something along the following lines would work: cc -S hello.c grep -c '^[[:space:]]\{1,\}[a-z]' hello.s If you working from binaries, you could find yourself a disassembler such as ndisasm (see nasm in the ports collection). However, because disassemblers can't easily distinguish between code and data (and library code is included, etc), you'd have to work hard to get accurate figures. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 05:39:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA00597 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 05:39:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kris.wpi.edu (kris.WPI.EDU [130.215.64.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA00583 for ; Mon, 27 Apr 1998 05:39:35 -0700 (PDT) (envelope-from rick@kris.wpi.edu) Received: (from rick@localhost) by kris.wpi.edu (8.8.5/8.8.5) id IAA10478; Mon, 27 Apr 1998 08:44:05 -0400 (EDT) From: "Rick C. Petty" Message-Id: <199804271244.IAA10478@kris.wpi.edu> Subject: Re: how to get number of instructions in a prg In-Reply-To: <199804270906.LAA08665@kk662.kk.etx.ericsson.se> from ETX-B-SL Martti Kuparinen at "Apr 27, 98 11:06:58 am" To: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) Date: Mon, 27 Apr 1998 08:44:05 -0400 (EDT) Cc: hackers@FreeBSD.ORG X-Files: Trust no one! X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What is the easiest way to count the number of assembler instructions > in a program? > > In gdb there is the "disassemble function-name" command, but it > disassembles only the given function. One could of course call this > several times and each time count the lines, but since a program can > have several hundred small sub-functions, this method is not the best... What's wrong with compiling (under gcc) with the -S option, then "wc -l *.s"? That's what I use. --Rick C. Petty, aka Snoopy mailto: rick@kris.wpi.edu ----------------------------------------------------------------------- C/C++/DBMS/SQL/Perl/Java/HTML http://kris.wpi.edu/~rick/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 07:00:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA16313 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 07:00:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA16253 for ; Mon, 27 Apr 1998 07:00:13 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA02509; Mon, 27 Apr 1998 09:59:36 -0400 Date: Mon, 27 Apr 1998 09:59:36 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@FreeBSD.ORG Subject: for your viewing pleasure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG www.sarnoff.com:8000, go down the metacomputing link. See the new cluster. ron Ron Minnich |Java: an operating-system-independent, rminnich@sarnoff.com |architecture-independent programming language (609)-734-3120 |for Windows/95 and Windows/NT on the Pentium ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 07:46:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA25280 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 07:46:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA25237 for ; Mon, 27 Apr 1998 07:46:31 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id KAA29392; Mon, 27 Apr 1998 10:41:46 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Mon, 27 Apr 1998 10:41:45 -0400 (EDT) From: "David E. Cross" To: Alexander Matey cc: Eivind Eklund , Julian Elisher , freebsd-hackers@FreeBSD.ORG Subject: Re: Static ARP (IFF_NOARP usage in ethernet interfaces) In-Reply-To: <19980427150520.39431@hosix.ntu-kpi.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, Alexander Matey wrote: > On Sun, Apr 26, 1998 at 11:56:10PM +0200, Eivind Eklund wrote: > > > I see no technical reason against this but > > > I'm curious why one would want to do this.. I can't imagine > > > a single reason for not wanting to do arp.. > > > > Security. You want to be able to force a particular MAC address to > > match a particular IP address, so people can't come with a different > > computer and take over the IP address of a known computer. > > Yes, security. I my situation it stands for about 50 computers on 4 > ethernet subnets, some of them do have internet access while the others > don't. > That does not seem like much of an obstacle to overcome, on most ethernet cards you can over-ride the MAC address of the card. All you need to do is DOS the other machine into obblivion, change your MAC, ifconfig for his IP address, and do a broadcast ping to reset any switches that may be in the network.. (you are still hosed if you have a hub with security though) -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 09:01:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09455 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 09:01:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA09431 for ; Mon, 27 Apr 1998 09:00:55 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id MAA24726 for ; Mon, 27 Apr 1998 12:00:48 -0400 (EDT) Date: Mon, 27 Apr 1998 12:00:48 -0400 (EDT) From: Snob Art Genre To: hackers@FreeBSD.ORG Subject: Whom to contact? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Following a discussion with John Dyson about which programs are most optimally linked shared/static, I am trying to contact the maintainers of various pieces of code to advise them that they may be linking suboptimally. For ports this is trivial, as I can pull MAINTAINER from the Makefile, but how do I determine this for various parts of the base system? Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 09:25:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA14558 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 09:25:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA14547; Mon, 27 Apr 1998 09:25:31 -0700 (PDT) (envelope-from dirk.vangulik@jrc.it) Received: from elec.isei.jrc.it (elec.jrc.it [139.191.71.132]) by mrelay.jrc.it (LMC5688) with SMTP id SAA18897; Mon, 27 Apr 1998 18:25:26 +0200 (MET DST) Received: from elect6 by elec.isei.jrc.it (4.1/EI-3.0m) id AA21928; Mon, 27 Apr 98 18:25:34 +0200 Posted-Date: Mon, 27 Apr 1998 18:21:49 +0200 (MET DST) Date: Mon, 27 Apr 1998 18:21:49 +0200 (MET DST) From: Dirk-Willem van Gulik X-Sender: dirkx@elect6 Reply-To: Dirk-Willem van Gulik To: freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Cc: dirk.vangulik@jrc.it Subject: VAIO 505 and FreeBSD 2.2.5/PAO In-Reply-To: <199804271605.JAA10308@hub.freebsd.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks to all who have helped me in the last few days; and to make up for all your time I wasted; I've put all your tips and tricks onto http://www.webweaving.org/vaio/ which is a rough and ready guide to getting FreeBSD-2.2.x, PAO and X11 to work on a VAIO-505 (when you have just the Japanese manuals to guide you...:-) Tx! Dw. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 09:27:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15023 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 09:27:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ntu-kpi.kiev.ua (ntu-kpi.kiev.ua [195.178.136.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA14526 for ; Mon, 27 Apr 1998 09:25:05 -0700 (PDT) (envelope-from lx@hosix.ntu-kpi.kiev.ua) Received: from fobos.ntu-kpi.kiev.ua (fobos.ntu-kpi.kiev.ua [10.100.0.6]) by ntu-kpi.kiev.ua (8.8.8/8.7.3) with ESMTP id TAA29242; Mon, 27 Apr 1998 19:19:50 +0300 (EEST) Received: from hosix.ntu-kpi.kiev.ua (lx.hosix.ntu-kpi.kiev.ua [10.100.23.72]) by fobos.ntu-kpi.kiev.ua (unknown/censored) with ESMTP id TAA10420; Mon, 27 Apr 1998 19:19:50 +0300 (EEST) Received: (from lx@localhost) by hosix.ntu-kpi.kiev.ua (8.8.8/8.8.7) id TAA00970; Mon, 27 Apr 1998 19:18:39 +0300 (EEST) (envelope-from lx) Message-ID: <19980427191839.32584@hosix.ntu-kpi.kiev.ua> Date: Mon, 27 Apr 1998 19:18:39 +0300 From: Alexander Matey To: "David E. Cross" Cc: Eivind Eklund , Julian Elisher , freebsd-hackers@FreeBSD.ORG Subject: Re: Static ARP (IFF_NOARP usage in ethernet interfaces) References: <19980427150520.39431@hosix.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from David E. Cross on Mon, Apr 27, 1998 at 10:41:45AM -0400 Organization: Hostel #6, NTUU /KPI/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 27, 1998 at 10:41:45AM -0400, David E. Cross wrote: > > > > I see no technical reason against this but > > > > I'm curious why one would want to do this.. I can't imagine > > > > a single reason for not wanting to do arp.. > > > > > > Security. You want to be able to force a particular MAC address to > > > match a particular IP address, so people can't come with a different > > > computer and take over the IP address of a known computer. > > > > Yes, security. I my situation it stands for about 50 computers on 4 > > ethernet subnets, some of them do have internet access while the others > > don't. > > That does not seem like much of an obstacle to overcome, on most ethernet > cards you can over-ride the MAC address of the card. All you need to do > is DOS the other machine into obblivion, change your MAC, ifconfig for his > IP address, and do a broadcast ping to reset any switches that may be in > the network.. (you are still hosed if you have a hub with security though) I know it, David. But being with it means being secured better. If it takes almost no pain and is already implemented in FreeBSD appletalk arp then why do not implement it in ethernet arp ? Moreover, if I run into -arp parameter in ifconfig(8) and then discover that it doesn't work - I will certainly find it abnormal. And I think it's time to stop this discussion. It would be more interesting to hear the final verdict on this stuff. bye, lx. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 09:33:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16756 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 09:33:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16746 for ; Mon, 27 Apr 1998 09:33:11 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id MAA21990; Mon, 27 Apr 1998 12:32:17 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by dignus.com (8.8.5/8.8.5) with ESMTP id JAA08571; Mon, 27 Apr 1998 09:49:40 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.7/8.6.9) id JAA19787; Mon, 27 Apr 1998 09:25:17 -0400 (EDT) Date: Mon, 27 Apr 1998 09:25:17 -0400 (EDT) From: Thomas David Rivers Message-Id: <199804271325.JAA19787@lakes.dignus.com> To: erakupa@kk.etx.ericsson.se, hackers@FreeBSD.ORG Subject: Re: how to get number of instructions in a prg Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What is the easiest way to count the number of assembler instructions > in a program? If you can recompile the program, simply add the -S flag onto gcc. This will have it "leave around" it's assembly source. Then, you can readily us 'wc' on that assembly source to get the number of lines, which will be a good approximation to the number of instructions... - Dave Rivers - > > In gdb there is the "disassemble function-name" command, but it > disassembles only the given function. One could of course call this > several times and each time count the lines, but since a program can > have several hundred small sub-functions, this method is not the best... > > Thanks in advance, > > Martti > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 12:49:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA23029 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 12:49:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA22858 for ; Mon, 27 Apr 1998 12:48:19 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA23096 for ; Mon, 27 Apr 1998 15:47:48 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.8.8/8.8.8) with ESMTP id PAA00614 for ; Mon, 27 Apr 1998 15:47:46 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199804271947.PAA00614@bmcgover-pc.cisco.com> To: hackers@FreeBSD.ORG Subject: "Group" value for _IO* routines... Date: Mon, 27 Apr 1998 15:47:45 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was just looking at http://www.freebsd.org/tutorials/ddwg/ddwg5.html, and looking at the ioctl section (as I'll be defining my own IOCTL operations in the near future for a driver I'm working on. The question I have is whether there is a "standard" for the group portion of these functions? In scanning through the header files on the system, it appears there are some overlaps.... Any input on how to select the 'best' or 'correct' group is most welcome... -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 13:34:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA01333 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 13:34:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA01315 for ; Mon, 27 Apr 1998 13:34:38 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id QAA04531 for ; Mon, 27 Apr 1998 16:34:31 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Mon, 27 Apr 1998 16:34:31 -0400 (EDT) From: "David E. Cross" To: freebsd-hackers@FreeBSD.ORG Subject: SIGDANGER Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was recenlty shown AIX's SIGDANGER (33). It is a signal that the kernel issues to [some] running processes when it gets dangerously low on space, by default SIGDANGER causes programs to die, freeing up memory, system critical processes and server processes woulf be compiled to ignore SIGDANGER. This seems like a very good idea, could it be done in FreeBSD? I remember someone talking about changing the signal structs to be an array of INTs, instead of just an int to accomidate more than 32 signals. Thoughts? -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 14:23:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA11281 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 14:23:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from toth.ferginc.com (toth.ferginc.com [205.139.23.69]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA11250 for ; Mon, 27 Apr 1998 14:23:05 -0700 (PDT) (envelope-from branson@toth.ferginc.com) Received: (from branson@localhost) by toth.ferginc.com (You_Can/Keep_Guessing) id RAA22258; Mon, 27 Apr 1998 17:22:23 -0400 (EDT) Message-ID: <19980427172223.36203@toth.FergInc.com> Date: Mon, 27 Apr 1998 17:22:23 -0400 From: Branson Matheson To: freebsd-hackers@FreeBSD.ORG Subject: Unix vs NT Reply-To: Branson.Matheson@FergInc.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 Organization: Ferguson Enterprises, Inc. X-Operating-System: FreeBSD 2.2.5-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thought I would forward this for those that want a comparasion to give to their management. We are dealing with this particular demon ( daemon ) right now and I have found this paper to be helpful. http://kirch.net/unix-nt.html - branson ------------------------------------------------------------------------------- Branson Matheson " If you are falling off of a mountain, Unix System Administrator You may as well try to fly." Ferguson Enterprises, Inc. - Delenn, Minbari Ambassador ( $statements = ) !~ /Corporate Opinion/; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 14:25:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA11967 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 14:25:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA11945 for ; Mon, 27 Apr 1998 14:25:12 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Mon Apr 27 16:25 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id QAA11065 for ; Mon, 27 Apr 1998 16:25:05 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Mon, 27 Apr 1998 17:24:28 -0400 Message-ID: To: freebsd-hackers@FreeBSD.ORG, dec@phoenix.its.rpi.edu Subject: RE: SIGDANGER Date: Mon, 27 Apr 1998 17:24:26 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ---------- > From: David E. Cross[SMTP:dec@phoenix.its.rpi.edu] > > I was recenlty shown AIX's SIGDANGER (33). It is a signal that the > kernel > issues to [some] running processes when it gets dangerously low on > space, > by default SIGDANGER causes programs to die, freeing up memory, system > critical processes and server processes woulf be compiled to ignore > SIGDANGER. This seems like a very good idea, could it be done in > FreeBSD? > I remember someone talking about changing the signal structs to be an > array of INTs, instead of just an int to accomidate more than 32 > signals. > I guess, it it not applicable to BSD. If FreeBSD uses the same space allocation method that is described in the devil book, it will not allow a process to start if it does not have enough swap space. On the other hand, AIX does speculate and can end up with swap space shortage at any point of time, not only in fork/exec/mmap/sbrk code. -Serge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 15:31:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26573 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 15:31:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26550 for ; Mon, 27 Apr 1998 15:30:51 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id RAA01545; Mon, 27 Apr 1998 17:30:38 -0500 (EST) (envelope-from toor) Message-Id: <199804272230.RAA01545@dyson.iquest.net> Subject: Re: SIGDANGER In-Reply-To: from "David E. Cross" at "Apr 27, 98 04:34:31 pm" To: dec@phoenix.its.rpi.edu (David E. Cross) Date: Mon, 27 Apr 1998 17:30:38 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David E. Cross said: > I was recenlty shown AIX's SIGDANGER (33). It is a signal that the kernel > issues to [some] running processes when it gets dangerously low on space, > by default SIGDANGER causes programs to die, freeing up memory, system > critical processes and server processes woulf be compiled to ignore > SIGDANGER. This seems like a very good idea, could it be done in FreeBSD? > I remember someone talking about changing the signal structs to be an > array of INTs, instead of just an int to accomidate more than 32 signals. > We do need to adopt an extended signal set, and I think that someone else has already developed it. SIGDANGER could be valuable. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 16:01:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02659 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 16:01:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02652 for ; Mon, 27 Apr 1998 16:01:44 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id WAA13742; Mon, 27 Apr 1998 22:38:21 +0100 (BST) (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199804272138.WAA13742@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: RFC: IPFW/DIVERT change suggestion. In-reply-to: Your message of "Mon, 27 Apr 1998 00:38:19 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Apr 1998 22:38:20 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > What can we do about this? > 1/ change the semantics of reinjection so that the number presently used > to indicate the rule to be immune to, is interpretted as the rule after > which processing should restart. '1' would indicate "start again at the > beginning. returning the same number as reported by the utility on > reception (we would report the rule number rather than the port number) > would make processing restart at the next rule after the divert. > > By specifying the correct number you could make processed packets jump > into a special set of rules (for example). > > All present programs need to set the value to that they received, > which they transparently pass because if they didn't they would > get rediversion. thus all existing programs would get teh behaviour > of continuing the examination of packets at the next rule after the > divert. > > This does tie ipfw and divert closer together. [.....] I suspect this is the best approach, and is really IMHO a more intuitive thing, however we've gotta be careful about the breakages :-) I've been considering the tun device in this respect too. Currently, it only transports IP. If we want to support anything else (such as IPX etc), we need some sort of struct rawheader { int sa_family; int len; u_char data[4]; }; struct rawheader_divert { int sa_family; int len; int ruleno; } struct rawheaer_tun { int sa_family; int len; } In order to dodge breaking existing stuff, I suspect a RAWHEADER ioctl should be available - passed a value of 1 or 0 for "on" or "off". The default is "off" where you get no rawheader and behaviour is as it currently is. "on" supplies rawheader structs for software that knows what they are. > (any other ideas?) > > julian -- Brian , , Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 16:06:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03910 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 16:06:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03881 for ; Mon, 27 Apr 1998 16:06:49 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id QAA11748; Mon, 27 Apr 1998 16:04:26 -0700 (PDT) Message-Id: <199804272304.QAA11748@implode.root.com> To: Alexander Matey cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Static ARP (IFF_NOARP usage in ethernet interfaces) In-reply-to: Your message of "Mon, 27 Apr 1998 19:18:39 +0300." <19980427191839.32584@hosix.ntu-kpi.kiev.ua> From: David Greenman Reply-To: dg@root.com Date: Mon, 27 Apr 1998 16:04:26 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And I think it's time to stop this discussion. It would be more >interesting to hear the final verdict on this stuff. This isn't a final verdict, but I think an interface flag to disable ARP would be useful and has near zero cost. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 17:23:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17931 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 17:23:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dns.ida.net (mail.ida.net [204.228.203.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17813 for ; Mon, 27 Apr 1998 17:22:59 -0700 (PDT) (envelope-from muck@ida.net) Received: from falcon.hinterlands.com (tc-pt1-10.ida.net [208.141.181.19]) by dns.ida.net (8.8.7/8.8.7) with SMTP id SAA09240 for ; Mon, 27 Apr 1998 18:16:01 -0600 (MDT) Message-ID: <354521A0.59E2B600@ida.net> Date: Mon, 27 Apr 1998 18:24:00 -0600 From: Mike X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Custom Kernel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Would it be safe to remove all devices from my custom kernel config file except those shown by dmesg? Does dmesg show all devices that are in the kernel config file? Also, on an unrelated question, wine keeps on core dumping on me saying bad system call. Dmesg says it was trying to use non present SYSVSEM. I assume this is because it SYSVSEM is something found only on Linux systems? Thanks. Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 17:34:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA20423 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 17:34:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19535 for ; Mon, 27 Apr 1998 17:30:31 -0700 (PDT) (envelope-from witr@spooky.rwwa.com) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.8.7/8.8.7) with ESMTP id UAA06099 for ; Mon, 27 Apr 1998 20:30:38 -0400 (EDT) (envelope-from witr@spooky.rwwa.com) Message-Id: <199804280030.UAA06099@spooky.rwwa.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-reply-to: Your message of "Mon, 27 Apr 1998 17:30:38 CDT." <199804272230.RAA01545@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Apr 1998 20:30:38 -0400 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dyson@freebsd.org said: :- We do need to adopt an extended signal set, and I think that someone :- else has already developed it. SIGDANGER could be valuable. I've always considered this to be one of the most brain dead mis features of AIX, since it invariably picks the process you least want have killed, like the compiler that doing part of your three-hour integration build. Or your emacs. Please don't add this to freebsd. --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 18:48:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05395 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 18:48:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from d183-205.uoregon.edu (d183-205.uoregon.edu [128.223.183.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05378 for ; Mon, 27 Apr 1998 18:48:27 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by d183-205.uoregon.edu (8.8.7/8.8.7) id SAA20043; Mon, 27 Apr 1998 18:48:05 -0700 (PDT) Message-ID: <19980427184804.47570@hydrogen.nike.efn.org> Date: Mon, 27 Apr 1998 18:48:04 -0700 From: John-Mark Gurney To: Mike Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Custom Kernel References: <354521A0.59E2B600@ida.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <354521A0.59E2B600@ida.net>; from Mike on Mon, Apr 27, 1998 at 06:24:00PM -0600 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike scribbled this message on Apr 27: the web pages should answer these questions... if not, then freebsd-questions is MUCH better list for these types of questions than freebsd-hackers... -hackers is for technical discussions... > Would it be safe to remove all devices from my custom kernel config file > except those shown by dmesg? Does dmesg show all devices that are in > the kernel config file? yes... > Also, on an unrelated question, wine keeps on core dumping on me saying > bad system call. Dmesg says it was trying to use non present SYSVSEM. > > I assume this is because it SYSVSEM is something found only on Linux > systems? no, you need to recompile your kernel with the SYSVSEM option in it.. -- John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 19:10:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA10493 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 19:10:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA10474 for ; Mon, 27 Apr 1998 19:10:41 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id TAA12808; Mon, 27 Apr 1998 19:10:35 -0700 (PDT) Message-Id: <199804280210.TAA12808@implode.root.com> To: Mike cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Custom Kernel In-reply-to: Your message of "Mon, 27 Apr 1998 18:24:00 MDT." <354521A0.59E2B600@ida.net> From: David Greenman Reply-To: dg@root.com Date: Mon, 27 Apr 1998 19:10:35 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Would it be safe to remove all devices from my custom kernel config file >except those shown by dmesg? Does dmesg show all devices that are in >the kernel config file? > >Also, on an unrelated question, wine keeps on core dumping on me saying >bad system call. Dmesg says it was trying to use non present SYSVSEM. > >I assume this is because it SYSVSEM is something found only on Linux >systems? It's a kernel option that isn't enabled by default. "options SYSVSEM". -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 19:12:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11130 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 19:12:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mozart.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA11102 for ; Mon, 27 Apr 1998 19:12:43 -0700 (PDT) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by mozart.canonware.com (8.8.8/8.8.7) with SMTP id TAA03298; Mon, 27 Apr 1998 19:08:48 -0700 (PDT) (envelope-from jasone@canonware.com) X-Authentication-Warning: mozart.canonware.com: jasone owned process doing -bs Date: Mon, 27 Apr 1998 19:08:47 -0700 (PDT) From: Jason Evans To: Robert Withrow cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <199804280030.UAA06099@spooky.rwwa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, Robert Withrow wrote: > dyson@freebsd.org said: > :- We do need to adopt an extended signal set, and I think that someone > :- else has already developed it. SIGDANGER could be valuable. > > I've always considered this to be one of the most brain dead > mis features of AIX, since it invariably picks the process you > least want have killed, like the compiler that doing part > of your three-hour integration build. Or your emacs. Please > don't add this to freebsd. Sounds to me like a configuration problem, not a design problem. Jason Jason Evans Email: [jasone@canonware.com] Web: [http://www.canonware.com/~jasone] Home phone: [(650) 856-8204] Work phone: [(408) 774-8007] Quote: ["Invention is 1% inspiration and 99% perspiration" - Thomas Edison] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 19:13:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11274 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 19:13:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA11123 for ; Mon, 27 Apr 1998 19:12:53 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id CAA17162; Tue, 28 Apr 1998 02:11:32 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA16041; Tue, 28 Apr 1998 04:11:32 +0200 (MET DST) Message-ID: <19980428041132.27403@follo.net> Date: Tue, 28 Apr 1998 04:11:32 +0200 From: Eivind Eklund To: Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <199804272230.RAA01545@dyson.iquest.net> <199804280030.UAA06099@spooky.rwwa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199804280030.UAA06099@spooky.rwwa.com>; from Robert Withrow on Mon, Apr 27, 1998 at 08:30:38PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 27, 1998 at 08:30:38PM -0400, Robert Withrow wrote: > > dyson@freebsd.org said: > :- We do need to adopt an extended signal set, and I think that someone > :- else has already developed it. SIGDANGER could be valuable. > > I've always considered this to be one of the most brain dead > mis features of AIX, since it invariably picks the process you > least want have killed, like the compiler that doing part > of your three-hour integration build. Or your emacs. Please > don't add this to freebsd. This already is in FreeBSD. We already have memory overcommit. I think SIGDANGER is a neat way of allowing some processes to avoid being killed - e.g, I'd add this to my X-server, as I'd much rather loose my Netscape than my X-server _and_ my Netscape... Of course, what I'd _really_ like is some way for the processes that get SIGDANGER to signal that they're going to return buffer memory, and a way for a process to tell that it _want_ those SIGDANGERs. Boy - we're approaching my Amiga every day *grin*. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 19:47:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA16925 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 19:47:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yard-sale.village.org (ys2.village.org [204.144.255.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA16884 for ; Mon, 27 Apr 1998 19:46:57 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony.village.org [10.0.0.6] by yard-sale.village.org with esmtp (Exim 1.82 #1) id 0yU0Pl-0004yF-00; Mon, 27 Apr 1998 20:46:37 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id UAA03021 for ; Mon, 27 Apr 1998 20:46:13 -0600 (MDT) Message-Id: <199804280246.UAA03021@harmony.village.org> To: hackers@FreeBSD.ORG Subject: ctm question Date: Mon, 27 Apr 1998 20:46:13 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK. I have a ctm archive that was partially applied when the power went away. It appears from the ctm_status file to have been applied, but in reality it wasn't. This CTM file was huge (the recent 2.2.6 mark going down), so there are boatloads of files impacted. Is there some simple option to ctm that says "look, do the best you can, don't touch those things that whose md5 doesn't match, but do touch those that do" so that I have at least a hope of restoring my local CVS tree w/o having to fetch the latest all snapshot. I looked in the manual, but didn't see anything. I'm doing a binary search right now with -e options, but that is really painful... Thanks for any aid you might be able to render... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 19:49:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA17345 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 19:49:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yard-sale.village.org (ys2.village.org [204.144.255.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA17335 for ; Mon, 27 Apr 1998 19:49:45 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony.village.org [10.0.0.6] by yard-sale.village.org with esmtp (Exim 1.82 #1) id 0yU0Sm-0004yH-00; Mon, 27 Apr 1998 20:49:44 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id UAA05523; Mon, 27 Apr 1998 20:49:09 -0600 (MDT) Message-Id: <199804280249.UAA05523@harmony.village.org> To: "Matthew N. Dodd" Subject: Re: National Semi SONIC DP83932 support? Cc: Mike Smith , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 25 Apr 1998 23:48:23 EDT." References: Date: Mon, 27 Apr 1998 20:49:09 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Matthew N. Dodd" writes: : > It's a SONIC, as the label says. Not 8390x compatible as such, no. : So a new driver would be needed? Or at least a port of a driver.... I believe that OpenBSD/arc has a driver that I think was derived from one of the OpenBSD/NetBSD mac ports. I don't know how hard that would be to port to FreeBSD. NatSemi also has the data sheets up on their web site.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 19:54:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18248 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 19:54:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yard-sale.village.org (ys2.village.org [204.144.255.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA18187 for ; Mon, 27 Apr 1998 19:53:51 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony.village.org [10.0.0.6] by yard-sale.village.org with esmtp (Exim 1.82 #1) id 0yU0Wg-0004yO-00; Mon, 27 Apr 1998 20:53:46 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id UAA07769; Mon, 27 Apr 1998 20:53:22 -0600 (MDT) Message-Id: <199804280253.UAA07769@harmony.village.org> To: Mike Subject: Re: Custom Kernel Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 27 Apr 1998 18:24:00 MDT." <354521A0.59E2B600@ida.net> References: <354521A0.59E2B600@ida.net> Date: Mon, 27 Apr 1998 20:53:22 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <354521A0.59E2B600@ida.net> Mike writes: : Would it be safe to remove all devices from my custom kernel config file : except those shown by dmesg? Does dmesg show all devices that are in : the kernel config file? Mostly. There are some devices that are required. I think npx is the only one, but is is shown by dmesg. : I assume this is because it SYSVSEM is something found only on Linux : systems? No, it is found on FreeBSD as well. Just add the proper option for it (found in LINT and now more recently in GENERIC). Generally it is used for X programs that want to share bitmaps, but other things do sometimes use it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 20:07:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20755 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 20:07:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA20580 for ; Mon, 27 Apr 1998 20:06:39 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id XAA11023; Mon, 27 Apr 1998 23:05:57 -0400 (EDT) Date: Mon, 27 Apr 1998 23:05:55 -0400 (EDT) From: "Matthew N. Dodd" To: Warner Losh cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: National Semi SONIC DP83932 support? In-Reply-To: <199804280249.UAA05523@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, Warner Losh wrote: > Or at least a port of a driver.... I believe that OpenBSD/arc has a > driver that I think was derived from one of the OpenBSD/NetBSD mac > ports. I don't know how hard that would be to port to FreeBSD. As I see... I'll see what the driver looks like. > NatSemi also has the data sheets up on their web site.... Yep. I've got 'em printing up right now. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 20:07:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20784 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 20:07:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA20565 for ; Mon, 27 Apr 1998 20:06:31 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id WAA01841; Mon, 27 Apr 1998 22:04:58 -0400 (EDT) Date: Mon, 27 Apr 1998 22:04:58 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@localhost To: Warner Losh cc: hackers@FreeBSD.ORG Subject: Re: ctm question In-Reply-To: <199804280246.UAA03021@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, Warner Losh wrote: > > OK. I have a ctm archive that was partially applied when the power > went away. It appears from the ctm_status file to have been applied, > but in reality it wasn't. This CTM file was huge (the recent 2.2.6 > mark going down), so there are boatloads of files impacted. Is there > some simple option to ctm that says "look, do the best you can, don't > touch those things that whose md5 doesn't match, but do touch those > that do" so that I have at least a hope of restoring my local CVS tree > w/o having to fetch the latest all snapshot. > > I looked in the manual, but didn't see anything. I'm doing a binary > search right now with -e options, but that is really painful... > > Thanks for any aid you might be able to render... Got just what you want, Warner ... here's a cut'n'paste copy of a post from about a month ago: cmtmd5 and ctmindex, an alternative to ctm(1) --------------------------------------------- see http://www.hclb.demon.co.uk/freebsd/ for fuller details and a zip file to download. Download ctmmd5 ctmmd5 and ctmindex are two programs which operate together to replace ctm(1). ctmindex takes a delta and creates an index file from it. The index file in then fed via stdin to ctmmd5 which tests the md5 checksum of the files listed in the index and applies any patches it can to them. ctmmd5 is much less fussy about broken source files than is ctm(1). It can also use any files it finds on a cdrom or elsewhere on your disks. If ctmmd5 fails to patch a file it will generate a shell script which can be used to ftp a replacement from one of the FreeBSD ftp sites. WHY USE CTNINDEX and CTMMD5? ctmindex and ctmmd5 come into their own if you have a source tree which ctm(1) refuses to touch. Once this happens it can often be extremely difficult and tedious to get the source tree into a state which ctm(1) will work on. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 20:33:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25782 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 20:33:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA25752 for ; Mon, 27 Apr 1998 20:33:02 -0700 (PDT) (envelope-from atf3r@cs.virginia.edu) Received: from ares.cs.virginia.edu by mail.virginia.edu id aa05594; 27 Apr 98 23:32 EDT Received: from mamba.cs.Virginia.EDU (mamba-fo.cs.Virginia.EDU [128.143.136.18]) by ares.cs.Virginia.EDU (8.8.5/8.8.5) with ESMTP id XAA19138; Mon, 27 Apr 1998 23:32:56 -0400 (EDT) Received: from localhost (atf3r@localhost) by mamba.cs.Virginia.EDU (8.7.5/8.7.3) with SMTP id XAA07679; Mon, 27 Apr 1998 23:32:56 -0400 (EDT) X-Authentication-Warning: mamba.cs.Virginia.EDU: atf3r owned process doing -bs Date: Mon, 27 Apr 1998 23:32:55 -0400 (EDT) From: "Adrian T. Filipi-Martin" Reply-To: Adrian Filipi-Martin To: "David E. Cross" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, David E. Cross wrote: > I was recenlty shown AIX's SIGDANGER (33). It is a signal that the kernel > issues to [some] running processes when it gets dangerously low on space, > by default SIGDANGER causes programs to die, freeing up memory, system > critical processes and server processes woulf be compiled to ignore > SIGDANGER. This seems like a very good idea, could it be done in FreeBSD? > I remember someone talking about changing the signal structs to be an > array of INTs, instead of just an int to accomidate more than 32 signals. > > Thoughts? I always thought SIGDANGER was considered the worst of all bad ideas. It greatly reduces determinism because when you over allocate memory and then discover that you are short on memory the process that is SIGDANGERED is randomly chosen randomly from the offending process group. It may not even be a process that improves the situation when dead. The best example of this was create 50 of the following processes: /* sleeper.c */ #include int main() { for(;;) sleep(30); return 0; } Then run the following: /* danger.c */ #include const int TwoGB = 2*1024*1024*1024; const int TwoMB = 2*1024*1024; int main() { char *p = (char *) malloc (TwoGB); for (i = 0; i < TwoGB; i += TwoMB) p[i] = 0; return 0; } When I ran this basic example on an AIX box years ago, a buch of the sleepers get killed before the danger process does. Why kill them? They have only minimal resources allocated. I believe it also breaks the POSIX definition of malloc(3), if I am not mistaken. Perhaps IBM had this ammended after introducing this misfeature. Caveat: I haven't messed with AIX boxes in a few years, so things may have improved, but I am naturally pessimistic when it comes to vendors fixing "great ideas". Adrian -- adrian@virginia.edu ---->>>>| If I were stranded on a desert island, and System Administrator --->>>| I could only have one OS for my computer, Neurosurgical Visualization Lab ->>| it would be FreeBSD. Think about it..... http://www.nvl.virginia.edu/ ->| http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 21:41:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA09552 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 21:41:26 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yard-sale.village.org (ys2.village.org [204.144.255.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA09496 for ; Mon, 27 Apr 1998 21:41:17 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony.village.org [10.0.0.6] by yard-sale.village.org with esmtp (Exim 1.82 #1) id 0yU2Ci-00051r-00; Mon, 27 Apr 1998 22:41:16 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id WAA00423; Mon, 27 Apr 1998 22:40:51 -0600 (MDT) Message-Id: <199804280440.WAA00423@harmony.village.org> To: Chuck Robey Subject: Re: ctm question Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 27 Apr 1998 22:04:58 EDT." References: Date: Mon, 27 Apr 1998 22:40:50 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Chuck Robey writes: : Got just what you want, Warner ... here's a cut'n'paste copy of a post : from about a month ago: : : : cmtmd5 and ctmindex, an alternative to ctm(1) Hmmmm. I just finished by binary search when this came in. :-( BTW, is anybody else getting cvs [server aborted]: can not realloc xxxxxx bytes when they are trying to update share/dict/web2? I see this when I'm tyring to grab the RELENG_2_2 branch. It is the only file in the whole three that barfs for me. This is true even with with the freshest make world I can grab (from a ctm of earlier today). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 21:55:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA12241 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 21:55:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA12231 for ; Mon, 27 Apr 1998 21:54:53 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id AAA14944 for ; Tue, 28 Apr 1998 00:54:52 -0400 (EDT) Date: Tue, 28 Apr 1998 00:54:52 -0400 (EDT) From: "Matthew N. Dodd" To: hackers@FreeBSD.ORG Subject: Re: National Semi SONIC DP83932 support? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [forgot to cc the list] On Mon, 27 Apr 1998, Warner Losh wrote: > Yes, the PICAs have these things built into them.... I'm not sure how > easy/hard it would be to port. They live at a memory address on the > arc port, built into the motherboard.... NS appears to have all the chipset doc available, a reference driver for PC/TCP, and an Application Note about the very card I hapen to have (SONIC+PLX). In addition NetBSD/m68k and NetBSD/pica have drivers, and of course OpenBSD probably has a few small differences. I'm not too sure the NetBSD driver does the right thing but I suppose a working driver is better than no driver at all. This card appears to use the same sort of buffer list management that the TI ThunderLAN chips do. I'm really going to have to shelve this and get back to token-ring stuff as this is yet another example of weird ass hardware that only I have a desire to use. I'll see if I can dig up an ISA example as going through the effort of porting a driver for just an EISA card would probably be a waste of effort. Anyone know of an ISA card (or PCI?) that uses the SONIC chip? /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 21:55:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA12293 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 21:55:02 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA12234 for ; Mon, 27 Apr 1998 21:54:54 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id XAA03316; Mon, 27 Apr 1998 23:53:35 -0500 (EST) (envelope-from toor) Message-Id: <199804280453.XAA03316@dyson.iquest.net> Subject: Re: SIGDANGER In-Reply-To: <199804280030.UAA06099@spooky.rwwa.com> from Robert Withrow at "Apr 27, 98 08:30:38 pm" To: witr@rwwa.com (Robert Withrow) Date: Mon, 27 Apr 1998 23:53:35 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Withrow said: > > dyson@freebsd.org said: > :- We do need to adopt an extended signal set, and I think that someone > :- else has already developed it. SIGDANGER could be valuable. > > I've always considered this to be one of the most brain dead > mis features of AIX, since it invariably picks the process you > least want have killed, like the compiler that doing part > of your three-hour integration build. Or your emacs. Please > don't add this to freebsd. > When virtual memory gets low, FreeBSD will kill processes anyway :-(. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 22:08:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA14945 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 22:08:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA14828; Mon, 27 Apr 1998 22:07:54 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id BAA15059; Tue, 28 Apr 1998 01:07:54 -0400 (EDT) Date: Tue, 28 Apr 1998 01:07:54 -0400 (EDT) From: "Matthew N. Dodd" To: "John S. Dyson" cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <199804272230.RAA01545@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, John S. Dyson wrote: > We do need to adopt an extended signal set, and I think that someone > else has already developed it. SIGDANGER could be valuable. Mmmm... SIGDANGERWILLROBINSON Hows that for an extended signal. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 22:25:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA18355 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 22:25:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA18270 for ; Mon, 27 Apr 1998 22:24:52 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id WAA07368; Mon, 27 Apr 1998 22:24:41 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Adrian Filipi-Martin cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-reply-to: Your message of "Mon, 27 Apr 1998 23:32:55 EDT." Date: Mon, 27 Apr 1998 22:24:41 -0700 Message-ID: <7364.893741081@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I always thought SIGDANGER was considered the worst of all bad > ideas. It greatly reduces determinism because when you over allocate > memory and then discover that you are short on memory the process that is > SIGDANGERED is randomly chosen randomly from the offending process group. > It may not even be a process that improves the situation when dead. Argh.. You and everyone else arguing from this angle are all seriously missing the point here! A process can already be randomly selected for KAL-007 treatment due to resource limitations under the current scheme and it's something which has been true for literally years now - see some of Terry's old rants on the evils of memory over-commit if you want to revisit that old dead-horse topic and find out why things are the way they are today. All the SIGDANGER (Will Robinson) signal is meant to do is give a process a little _warning_ before it's chosen as the designated sacrifice for the evening and terminated in an untimely fashion. I don't think the question here is "is this a good idea" - it's a perfectly reasonable idea and one which has been proposed before. The question here is really "what are the proposed semantics of this mechanism?", e.g. how long do you wait from the time you SIGDANGER the process and actually shoot it down, and what happens if you're also critically short of resources and don't have much time to wait? Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 23:03:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA25936 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 23:03:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA25922 for ; Mon, 27 Apr 1998 23:03:07 -0700 (PDT) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id IAA24211; Tue, 28 Apr 1998 08:03:03 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id IAA19498; Tue, 28 Apr 1998 08:03:00 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804280603.IAA19498@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh cc: hackers@FreeBSD.ORG Subject: Re: ctm question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Apr 1998 08:02:59 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > OK. I have a ctm archive that was partially applied when the power > went away. It appears from the ctm_status file to have been applied, > but in reality it wasn't. This CTM file was huge (the recent 2.2.6 > mark going down), so there are boatloads of files impacted. Is there > some simple option to ctm that says "look, do the best you can, don't > touch those things that whose md5 doesn't match, but do touch those > that do" so that I have at least a hope of restoring my local CVS tree > w/o having to fetch the latest all snapshot. You are SOL. A partially applied CTM delta breaks everything :-( Sorry! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 23:03:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA26066 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 23:03:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26030 for ; Mon, 27 Apr 1998 23:03:47 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id XAA08249; Mon, 27 Apr 1998 23:03:17 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma008245; Mon Apr 27 23:02:51 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id XAA05113; Mon, 27 Apr 1998 23:02:51 -0700 (PDT) From: Archie Cobbs Message-Id: <199804280602.XAA05113@bubba.whistle.com> Subject: Re: Whom to contact? In-Reply-To: from Snob Art Genre at "Apr 27, 98 12:00:48 pm" To: benedict@echonyc.com (Snob Art Genre) Date: Mon, 27 Apr 1998 23:02:51 -0700 (PDT) Cc: hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Snob Art Genre writes: > Following a discussion with John Dyson about which programs are most > optimally linked shared/static, I am trying to contact the maintainers > of various pieces of code to advise them that they may be linking > suboptimally. > > For ports this is trivial, as I can pull MAINTAINER from the Makefile, > but how do I determine this for various parts of the base system? cvs log? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 23:06:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA26932 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 23:06:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yard-sale.village.org (ys2.village.org [204.144.255.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA26875 for ; Mon, 27 Apr 1998 23:06:41 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony.village.org [10.0.0.6] by yard-sale.village.org with esmtp (Exim 1.82 #1) id 0yU3XM-00054t-00; Tue, 28 Apr 1998 00:06:40 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id AAA01869; Tue, 28 Apr 1998 00:06:16 -0600 (MDT) Message-Id: <199804280606.AAA01869@harmony.village.org> To: Mark Murray Subject: Re: ctm question Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 28 Apr 1998 08:02:59 +0200." <199804280603.IAA19498@greenpeace.grondar.za> References: <199804280603.IAA19498@greenpeace.grondar.za> Date: Tue, 28 Apr 1998 00:06:16 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199804280603.IAA19498@greenpeace.grondar.za> Mark Murray writes: : You are SOL. A partially applied CTM delta breaks everything :-( I'm thinking about hacking ctm to have a mode that ignores the delta if the md5 already matches the new md5 in the ctm package. That way if there is a mismatch with the old one, it will try to apply it, keep quiet about the ones that are up to date and whine (but not die) if there is one that doesn't match either of the md5's. This would let me recover from 95% of the partially applied CTM delta problems I've run into over the years. It would at least let me KNOW what is corrupted and take whatever action I need to to recover. I've not even looked at the code, nor at the ctmmd5 stuff that chuck pointed me at. Would there be any interest in this? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 23:10:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27786 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 23:10:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from USC-FW.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27780 for ; Mon, 27 Apr 1998 23:10:27 -0700 (PDT) (envelope-from Michael.Schuster@utimaco.co.at) Received: (from uucp@localhost) by USC-FW.utimaco.co.at (8.8.8/8.8.8) id IAA09386 for ; Tue, 28 Apr 1998 08:07:37 +0200 (CEST) (envelope-from Michael.Schuster@utimaco.co.at) Received: from ns1.int.utimaco.co.at(10.1.0.254) by USC-FW.utimaco.co.at via smap (V2.0) id xma009384; Tue, 28 Apr 98 08:07:08 +0200 Received: from utimaco.co.at (ultra1.int.utimaco.co.at [10.1.0.32]) by safeconcept.int.utimaco.co.at (8.8.5/8.8.5) with ESMTP id IAA27093 for ; Tue, 28 Apr 1998 08:07:05 +0200 (CEST) Message-ID: <35457207.3E5910A1@utimaco.co.at> Date: Tue, 28 Apr 1998 08:07:03 +0200 From: Michael Schuster Organization: Utimaco Safe Concept GmbH. Linz Austria X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Re: network problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > I can ping jaunt from picnic, but not picnic from jaunt. When I try to > use some network thing like telnet or ftp on picnic to talk to jaunt, I > get the same thing every time: I've seen this happen when the second machine (jaunt in your case) has a problem with name/address resolution. This does sound a bit mysterious, I know, but my experience is that once all network and IP numbers are properly configured, this would go away (provided there's no other reason (firewall, etc.) for this). BTW, this is not strictly a FreeBSD problem, I encountered this on Solaris after our internal network was restructured. On Solaris, these are placed I'd look: in /etc: resolv.conf, hosts, net*, hostname.*, defaultdomain OTOH: > telnet: Unable to connect to remote host: Permission denied /etc/inetd.conf on picnic? (This is the obvious one, I know, but one sometimes misses those for just that reason :-) -- Michael Schuster To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 23:26:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA00865 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 23:26:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA00859 for ; Mon, 27 Apr 1998 23:26:02 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.0.Beta6/frmug-2.3/nospam) with UUCP id IAA06655; Tue, 28 Apr 1998 08:25:59 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.9.0.Beta4/keltia-2.14/nospam) id HAA09020; Tue, 28 Apr 1998 07:54:29 +0200 (CEST) (envelope-from roberto) Message-ID: <19980428075429.A8984@keltia.freenix.fr> Date: Tue, 28 Apr 1998 07:54:29 +0200 From: Ollivier Robert To: hackers@FreeBSD.ORG Cc: Warner Losh Subject: Re: ctm question Mail-Followup-To: hackers@FreeBSD.ORG, Warner Losh References: <199804280246.UAA03021@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.3i In-Reply-To: <199804280246.UAA03021@harmony.village.org>; from Warner Losh on Mon, Apr 27, 1998 at 08:46:13PM -0600 X-Operating-System: FreeBSD 3.0-CURRENT ctm#4245 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Warner Losh: > touch those things that whose md5 doesn't match, but do touch those > that do" so that I have at least a hope of restoring my local CVS tree > w/o having to fetch the latest all snapshot. Use CVSup from ctm.freebsd.org, it is updated by CTM so you're sure it is synchronised. Its main problem is that it doesn't maintain the .ctm_status file. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #8: Tue Apr 21 02:45:53 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 27 23:27:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA01181 for freebsd-hackers-outgoing; Mon, 27 Apr 1998 23:27:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA01173 for ; Mon, 27 Apr 1998 23:27:30 -0700 (PDT) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id IAA24877; Tue, 28 Apr 1998 08:27:28 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id IAA19626; Tue, 28 Apr 1998 08:27:28 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804280627.IAA19626@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh cc: hackers@FreeBSD.ORG Subject: Re: ctm question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Apr 1998 08:27:27 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message <199804280603.IAA19498@greenpeace.grondar.za> Mark Murray writes: > : You are SOL. A partially applied CTM delta breaks everything :-( > > I'm thinking about hacking ctm to have a mode that ignores the delta > if the md5 already matches the new md5 in the ctm package. That way > if there is a mismatch with the old one, it will try to apply it, keep > quiet about the ones that are up to date and whine (but not die) if > there is one that doesn't match either of the md5's. This would let > me recover from 95% of the partially applied CTM delta problems I've > run into over the years. It would at least let me KNOW what is > corrupted and take whatever action I need to to recover. Probably a good way to do this would be to extend the -F (Force) option. > I've not even looked at the code, nor at the ctmmd5 stuff that chuck > pointed me at. Would there be any interest in this? Well, it burnt me a couple of times, so yes! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 00:37:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA13359 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 00:37:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA13321 for ; Tue, 28 Apr 1998 00:37:40 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id CAA02477; Tue, 28 Apr 1998 02:36:16 -0400 (EDT) Date: Tue, 28 Apr 1998 02:36:16 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@localhost To: Michael Schuster cc: hackers@FreeBSD.ORG Subject: Re: network problem In-Reply-To: <35457207.3E5910A1@utimaco.co.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, Michael Schuster wrote: > Chuck Robey wrote: > > I can ping jaunt from picnic, but not picnic from jaunt. When I try to > > use some network thing like telnet or ftp on picnic to talk to jaunt, I > > get the same thing every time: > > I've seen this happen when the second machine (jaunt in your case) has a > problem with name/address resolution. This does sound a bit mysterious, > I know, but my experience is that once all network and IP numbers are > properly configured, this would go away (provided there's no other > reason (firewall, etc.) for this). > BTW, this is not strictly a FreeBSD problem, I encountered this on > Solaris after our internal network was restructured. > > On Solaris, these are placed I'd look: in /etc: resolv.conf, hosts, > net*, hostname.*, defaultdomain Thanks, it cleared up after a reboot.... I should have done a route flush after I thought I had it all right, and then redo the ifconfigs again. I had it right but had the routing so confused it didn't know it. > > > OTOH: > > > telnet: Unable to connect to remote host: Permission denied > > /etc/inetd.conf on picnic? (This is the obvious one, I know, but one > sometimes misses those for just that reason :-) > > -- > Michael Schuster > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 00:42:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14476 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 00:42:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA14350 for ; Tue, 28 Apr 1998 00:42:01 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id CAA02481; Tue, 28 Apr 1998 02:39:13 -0400 (EDT) Date: Tue, 28 Apr 1998 02:39:12 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@localhost To: Ollivier Robert cc: hackers@FreeBSD.ORG, Warner Losh Subject: Re: ctm question In-Reply-To: <19980428075429.A8984@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, Ollivier Robert wrote: > According to Warner Losh: > > touch those things that whose md5 doesn't match, but do touch those > > that do" so that I have at least a hope of restoring my local CVS tree > > w/o having to fetch the latest all snapshot. > > Use CVSup from ctm.freebsd.org, it is updated by CTM so you're sure it is > synchronised. Its main problem is that it doesn't maintain the .ctm_status > file. Why not? It seems that would make re-syncing the ctm damn near impossible ... > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 3.0-CURRENT #8: Tue Apr 21 02:45:53 CEST 1998 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 00:55:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA16949 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 00:55:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from idiom.com (idiom.com [140.174.82.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA16929 for ; Tue, 28 Apr 1998 00:55:47 -0700 (PDT) (envelope-from muir@idiom.com) Received: (from muir@localhost) by idiom.com (8.8.7/8.8.5) id AAA11300; Tue, 28 Apr 1998 00:55:47 -0700 (PDT) Date: Tue, 28 Apr 1998 00:55:47 -0700 (PDT) From: David Muir Sharnoff Message-Id: <199804280755.AAA11300@idiom.com> To: freebsd-hackers@FreeBSD.ORG Subject: Routing problem that I need solved. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My fellow FreeBSD addicts, I've got a kernel mod that I need done. I could probably do it myself, but I would much prefer not to as I've got other fish to fry. I've also got slightly more money than time. I can afford to $2,000 as a thank-you if someone does this. Idiom is now multi-homed. Idiom has three sets of IP addresses: 1: addresses that can only be routed through BEST.COM 2: addresses that can only be routed through ABOVE.NET 3: addresses that can be routed through either BEST.COM or ABOVE.NET Most addresses are type 3 (routed through both). For reliability, it's important to keep a few key services using type 1 and type 2 addresses. For example, the two primary nameservers: ns.idiom.com uses a type 1 address and ns2.idiom.com uses a type 2 address. That provides some reliability for the incomming traffic. What I would like is to make sure that at least some of the outgoing traffic is symmetrical. If a packet is coming _from_ a type 1 address, then it should be routed out through BEST.COM. If it's coming from a type 2 address then it should be routed out through ABOVE.NET. I run OSPF internally, so the routing situation tends to be a bit dynamic. As many utilities as possible should reply using the address they were contacted on. DNS, radius, etc. That's a separate problem though. My solution to this would be to create another ipfw rule: "route through" Example of usage: # skip over packets that are inbound. ipfw add 100 skipto 200 all from any to 140.174.82/24 # type 1 ipfw add 110 skipto 200 all from any to 209.66.121/24 # type 2 ipfw add 120 skipto 200 all from any to 209.157.64/19 # type 3 # selectively route type 1 and type 2 outbound ipfw add 140 pass through 140.174.37.21 all from 140.174.82/24 to any ipfw add 150 pass through 209.66.121.1 all from 209.66.121/24 to any The semantics of "pass through" are that the next hop for the packet will be chosen as if it were bound for the address given. The same rule can be deployed throughout my network. There's one other detail that would help things: make the skipto rule fast. Right now the skipto rule does a linear search. I know that $2k is not much money for tricky kernel work, but it's what I can afford for this. Cisco routers can do routing based on the source address. I use -STABLE. I need a solution that's fit for production use and also fit for inclusion in -STABLE. Thanks, -Dave To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 02:33:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA05620 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 02:33:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from vorbis.noc.easynet.net (qmailr@vorbis.noc.easynet.net [195.40.1.254]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA05588 for ; Tue, 28 Apr 1998 02:33:41 -0700 (PDT) (envelope-from chrisy@vorbis.noc.easynet.net) Received: (qmail 26633 invoked by uid 1943); 28 Apr 1998 09:33:38 -0000 Message-ID: <19980428103338.19612@flix.net> Date: Tue, 28 Apr 1998 10:33:38 +0100 From: Chrisy Luke To: David Muir Sharnoff Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Routing problem that I need solved. References: <199804280755.AAA11300@idiom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199804280755.AAA11300@idiom.com>; from David Muir Sharnoff on Tue, Apr 28, 1998 at 12:55:47AM -0700 Organization: The Flirble Internet Exchange X-URL: http://www.flix.net/ X-FTP: ftp://ftp.flirble.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Muir Sharnoff wrote (on Apr 28): > ipfw add 140 pass through 140.174.37.21 all from 140.174.82/24 to any > ipfw add 150 pass through 209.66.121.1 all from 209.66.121/24 to any > > The semantics of "pass through" are that the next hop for the packet > will be chosen as if it were bound for the address given. The same rule > can be deployed throughout my network. I see what you're trying to achieve. It should be simple to do - though there will be a penalty hit (although small on a router with only a few routes) since it will already have scanned the routing tree for a next hop based on destination. But that's swings-n-roundabouts. First of all you'd need to pass a pointer to "dst" from netinet/ip_output.c::ip_output() in the calls to ip_fw_chk(). Then you would need a bit of code in netinet/ip_fw.c::ip_fw_chk() in the switch (f->fw_flg & IP_FW_F_COMMAND) when it matches a rule to modifiy the newly passwd "dst" variable. This doesn't require anything like a new checksum because it's not stored in the packet. The kernel then goes and arpresolves "dst" for forwarding to a MAC address. This would achieve it precisely, with the extra logic to get the rule into the table in the first place, of course. I was planning on doing something very similar anyway - this is basically a "forward on FW rule" engine, so you could forward to addresses based on TCP port, etc. Except I was going to do a multipath one, of course. :-) Since there's interest, I'll have a go at it today... Chris. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org. == Head of Systems for Easynet Group PLC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 02:46:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA07862 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 02:46:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA07853 for ; Tue, 28 Apr 1998 02:46:36 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id FAA60028 for ; Tue, 28 Apr 1998 05:46:35 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: References: Date: Tue, 28 Apr 1998 05:49:56 -0400 To: freebsd-hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: SIGDANGER Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:32 PM -0400 4/27/98, Adrian T. Filipi-Martin wrote: >On Mon, 27 Apr 1998, David E. Cross wrote: > >> I was recently shown AIX's SIGDANGER (33). It is a signal that the kernel >> issues to [some] running processes when it gets dangerously low on space, >> by default SIGDANGER causes programs to die, freeing up memory, system >> critical processes and server processes would be compiled to ignore >> SIGDANGER. This seems like a very good idea, could it be done in >> FreeBSD? > > I always thought SIGDANGER was considered the worst of all bad > ideas. It greatly reduces determinism because when you over allocate > memory and then discover that you are short on memory the process that > is SIGDANGERED is randomly chosen randomly from the offending process > group. It may not even be a process that improves the situation when > dead. If you have a system which does overallocate, you're going to randomly pick processes to kill. Or maybe the system will even make a pretty good guess at what to kill. That is a true statement with or without SIGDANGER. The question is, will there be any way for some critical process (system daemons, the X-server, whatever) to tell the system "No, don't kill me, try to kill someone else first!". The example you give isn't particularly interesting, as I (as a system administrator) don't really care if any or all of those pittly little processes ( :-) ) get killed. I may, however, be very unhappy if sshd or the main lpd process gets killed just because they *happen* to be the process which requests memory at the wrong time while you're running that "danger.c" program. - - - Of course, the next question is how this should work. I don't know enough about AIX, but when I went to add this in a program of mine, the first thing I thought of was "okay, great, now how do I tell whether my signal-handler is doing the right thing?". Sure, I could send it a sigdanger, but that wouldn't cause it to be called while the system really is low on memory. And if I run my own danger.c program to force a (test) system to be low on memory, how do I make sure the system will try to kill the program I'm testing? So, if SIGDANGER support is added to FreeBSD, it may also be amusing if a process could tell the kernel "try to kill me first, if you're every running out of memory". Really I want that for testing, but now that I think of it, that option might be useful in real-life programs too. Say I'm running some real-world background job that I don't really care about (such as the recent DESchall client, or any similar "idle cycle" program). If the machine is running out of memory, I'd want to see that client die first, because I *know* nothing depends on it... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 04:16:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA24330 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 04:16:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from golem.belabm.by (root@golem.belabm.by [194.226.122.185]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA24250 for ; Tue, 28 Apr 1998 04:16:23 -0700 (PDT) (envelope-from scaner@belabm.by) Received: from belabm.by ([194.226.122.183]) by golem.belabm.by (8.8.7/8.8.4) with ESMTP id NAA28791; Tue, 28 Apr 1998 13:52:53 +0300 Message-ID: <3545B47A.5AABF3AC@belabm.by> Date: Tue, 28 Apr 1998 13:50:34 +0300 From: Eugene Vedistchev Reply-To: scaner@belabm.by Organization: Global One in Belarus X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: David Muir Sharnoff CC: "freebsd-hackers@FreeBSD.ORG" Subject: Re: Routing problem that I need solved. References: <199804280755.AAA11300@idiom.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Have you seen IP-Filter ? check http://cheops.anu.edu.au/~avalon/ and http://cheops.anu.edu.au/~avalon/examples.html#redirection David Muir Sharnoff wrote: > > My fellow FreeBSD addicts, I've got a kernel mod that I need done. > I could probably do it myself, but I would much prefer not to as > I've got other fish to fry. I've also got slightly more money than > time. I can afford to $2,000 as a thank-you if someone does this. > > Idiom is now multi-homed. Idiom has three sets of IP addresses: > 1: addresses that can only be routed through BEST.COM > 2: addresses that can only be routed through ABOVE.NET > 3: addresses that can be routed through either BEST.COM or ABOVE.NET > > Most addresses are type 3 (routed through both). For reliability, > it's important to keep a few key services using type 1 and type 2 > addresses. For example, the two primary nameservers: ns.idiom.com > uses a type 1 address and ns2.idiom.com uses a type 2 address. > > That provides some reliability for the incomming traffic. What I > would like is to make sure that at least some of the outgoing traffic > is symmetrical. > > If a packet is coming _from_ a type 1 address, then it should be > routed out through BEST.COM. If it's coming from a type 2 address then it > should be routed out through ABOVE.NET. > > I run OSPF internally, so the routing situation tends to be a bit > dynamic. > > As many utilities as possible should reply using the address they were > contacted on. DNS, radius, etc. That's a separate problem though. > > My solution to this would be to create another ipfw rule: "route through" > > Example of usage: > > # skip over packets that are inbound. > > ipfw add 100 skipto 200 all from any to 140.174.82/24 # type 1 > ipfw add 110 skipto 200 all from any to 209.66.121/24 # type 2 > ipfw add 120 skipto 200 all from any to 209.157.64/19 # type 3 > > # selectively route type 1 and type 2 outbound > > ipfw add 140 pass through 140.174.37.21 all from 140.174.82/24 to any > ipfw add 150 pass through 209.66.121.1 all from 209.66.121/24 to any > > The semantics of "pass through" are that the next hop for the packet > will be chosen as if it were bound for the address given. The same rule > can be deployed throughout my network. > > There's one other detail that would help things: make the skipto rule fast. > Right now the skipto rule does a linear search. > > I know that $2k is not much money for tricky kernel work, but it's > what I can afford for this. Cisco routers can do routing based on > the source address. > > I use -STABLE. I need a solution that's fit for production use and > also fit for inclusion in -STABLE. > > Thanks, > > -Dave > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 04:19:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA25171 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 04:19:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA25158 for ; Tue, 28 Apr 1998 04:19:25 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id HAA15376; Tue, 28 Apr 1998 07:19:17 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Tue, 28 Apr 1998 07:19:16 -0400 (EDT) From: "David E. Cross" To: "Jordan K. Hubbard" cc: Adrian Filipi-Martin , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <7364.893741081@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, Jordan K. Hubbard wrote: > All the SIGDANGER (Will Robinson) signal is meant to do is give a hehe ;) > I don't think the question here is "is this a good idea" - it's a > perfectly reasonable idea and one which has been proposed before. The > question here is really "what are the proposed semantics of this > mechanism?", e.g. how long do you wait from the time you SIGDANGER the > process and actually shoot it down, and what happens if you're also > critically short of resources and don't have much time to wait? > My understanding of this was that it shotguned a set of processes all with SIGDANGER, at least some of them should die.... or,the kernel can tell if a process is ignoring SIGDNAGER (which would be the easiest way for a process to handle it), and would use that as a flag for those to be the highest priority processes. Processes that are using their own handler would be second, and those using the default handler would be first choice. (So don't use SIGDANGER as a signal, per-se, but as a flag to the kernel 'it is OK to kill me'). As per memory overcomitment, I do not see this as an issue, I can still run out of memory even if I am not over commited (say netscape went berkerk or whatever). I think thet in situation where the system is starting to page (or heavily paging) SIGDANER [Will Robinson] would be a usefull tool. -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 04:24:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA26234 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 04:24:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA26221 for ; Tue, 28 Apr 1998 04:24:39 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.7/8.8.4) with UUCP id MAA06786 for freebsd.org!hackers; Tue, 28 Apr 1998 12:23:22 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Tue, 28 Apr 1998 12:14:45 +0100 (BST) X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Apr 1998 12:18:32 +0100 To: hackers@FreeBSD.ORG From: Bob Bishop Subject: Wow! Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Solaris calls Hotmail shots for Microsoft > > Microsoft has decided to get the hots for Sun and is using Solaris to > run its acclaimed Hotmail web-based e-mail service instead of NT. > > The software giant has attempted to exchange the Sun/Solaris > infrastructure of Hotmail with NT since buying it in December 1997. > However, the demands of supporting 10 million users reportedly proved > too great for NT, and Solaris was reinstated. > > In a leaked report, sources close to Hotmail said: "... its whole mail > server infrastructure is Solaris. NT couldn't handle it. On the web > server, they're running MP Pentiums and Apache on FreeBSD. They're ^^^^^^^^^^^^^^^^^^ > moving to Solaris for threads. The engineering team did its best to run ^^^^^^^^^^^^^^^^^ > NT - and failed. The issue's being escalated." > > Hotmail is running Apache's /1.2.1 web server which is not available for > NT due to technical difficulties. A statement on Apache's website > states: "The road to Windows NT has not been a pretty one. Several > attempts have been made, both by Apache Group members and outside folks, > but due to a lack of stability and a clear consensus on how to manage a > true cross-platform development project, NT is not yet a standard > platform supported by Apache." > > Microsoft is currently recruiting engineers for Hotmail, but NT > specialists need not apply. Hotmail's website lists vacancies for an > operations software engineer and a QA engineer - and the common > requirement is for Unix experience. > > Judy Gibbons, director of the Microsoft Network, was unaware of the > hardware behind Hotmail, but said: "We looked at all the on-line mail > services and Hotmail was far and away the best. It has the most proven > and scalable architecture." > > First appeared in Network News, 22-April - 1998 -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 04:33:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA28501 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 04:33:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA28477 for ; Tue, 28 Apr 1998 04:33:39 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.7] (user7.dataplex.net [208.2.87.7]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id GAA10678; Tue, 28 Apr 1998 06:32:41 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: References: <19980428075429.A8984@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Apr 1998 06:26:11 -0500 To: Chuck Robey From: Richard Wackerbarth Subject: Re: ctm question Cc: Ollivier Robert , hackers@FreeBSD.ORG, Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:39 AM -0500 4/28/98, Chuck Robey wrote: >On Tue, 28 Apr 1998, Ollivier Robert wrote: > >> According to Warner Losh: >> > touch those things that whose md5 doesn't match, but do touch those >> > that do" so that I have at least a hope of restoring my local CVS tree >> > w/o having to fetch the latest all snapshot. >> >> Use CVSup from ctm.freebsd.org, it is updated by CTM so you're sure it is >> synchronised. Its main problem is that it doesn't maintain the .ctm_status >> file. > >Why not? It seems that would make re-syncing the ctm damn near >impossible ... Not really. You know that it is synced to some recent ctm update. (Actually, it is synced the the ctm-cvs feed. Not every cvs update affects each branch feed.) Just look at the past update or two and see if it has already been applied. When you find the last one which was applied, you are in business. Perhaps an easier way would be to CVSup to update your tree. Then insert a .ctm_status file that is known to be a bit too early. Try to apply the update stream. As each update fails, bump the number in .ctm_status and try the next one. I venture to quess that you will need only one or two "false starts". You will probably have to wait for the next update to arrive before you find one to apply. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 05:39:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA09865 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 05:39:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA09854 for ; Tue, 28 Apr 1998 05:39:13 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id IAA16011; Tue, 28 Apr 1998 08:39:03 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Tue, 28 Apr 1998 08:39:02 -0400 (EDT) From: "David E. Cross" To: Bob Bishop cc: hackers@FreeBSD.ORG Subject: Re: Wow! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, Bob Bishop wrote: > > server, they're running MP Pentiums and Apache on FreeBSD. They're > ^^^^^^^^^^^^^^^^^^ > > moving to Solaris for threads. The engineering team did its best to run > ^^^^^^^^^^^^^^^^^ Hmm..... perhaps we should get better thread support? -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 05:40:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA10139 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 05:40:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA09980; Tue, 28 Apr 1998 05:39:57 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id HAA11976; Tue, 28 Apr 1998 07:38:41 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id HAA26656; Tue, 28 Apr 1998 07:38:41 -0500 (CDT) Message-ID: <19980428073841.05698@mcs.net> Date: Tue, 28 Apr 1998 07:38:41 -0500 From: Karl Denninger To: dyson@FreeBSD.ORG Cc: Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199804280453.XAA03316@dyson.iquest.net>; from John S. Dyson on Mon, Apr 27, 1998 at 11:53:35PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 27, 1998 at 11:53:35PM -0500, John S. Dyson wrote: > Robert Withrow said: > > > > dyson@freebsd.org said: > > :- We do need to adopt an extended signal set, and I think that someone > > :- else has already developed it. SIGDANGER could be valuable. > > > > I've always considered this to be one of the most brain dead > > mis features of AIX, since it invariably picks the process you > > least want have killed, like the compiler that doing part > > of your three-hour integration build. Or your emacs. Please > > don't add this to freebsd. > > > When virtual memory gets low, FreeBSD will kill processes anyway :-(. > > -- > John | Never try to teach a pig to sing, > dyson@freebsd.org | it just makes you look stupid, > jdyson@nc.com | and it irritates the pig. Well, now wait a minute.. SIGDANGER is useful if properly trapped and handled. I'd like to see if supported with the default to be "ignore" (ie: you have to ASK for it to be delivered and processed). I've used this feature on AIX to avoid kernel deadload/death conditions in mission-critical processes. Yes, I agree that AIX is somewhat f*fd in the way it handles it, but the feature itself is quite nice. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 06:03:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14637 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 06:03:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from vorbis.noc.easynet.net (qmailr@vorbis.noc.easynet.net [195.40.1.254]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA14630 for ; Tue, 28 Apr 1998 06:03:19 -0700 (PDT) (envelope-from chrisy@vorbis.noc.easynet.net) Received: (qmail 6049 invoked by uid 1943); 28 Apr 1998 13:03:14 -0000 Message-ID: <19980428140313.12655@flix.net> Date: Tue, 28 Apr 1998 14:03:13 +0100 From: Chrisy Luke To: scaner@belabm.by Cc: David Muir Sharnoff , "freebsd-hackers@FreeBSD.ORG" Subject: Re: Routing problem that I need solved. References: <199804280755.AAA11300@idiom.com> <3545B47A.5AABF3AC@belabm.by> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <3545B47A.5AABF3AC@belabm.by>; from Eugene Vedistchev on Tue, Apr 28, 1998 at 01:50:34PM +0300 Organization: The Flirble Internet Exchange X-URL: http://www.flix.net/ X-FTP: ftp://ftp.flirble.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eugene Vedistchev wrote (on Apr 28): > Have you seen IP-Filter ? > check http://cheops.anu.edu.au/~avalon/ > and http://cheops.anu.edu.au/~avalon/examples.html#redirection This won't solve his precise problem, however, which is one of a client machine determining onto which network to forward information, but not necessarily using a directly attached next-hop - so it *needs* to do real routing [tm] etc. I've almost done it (kernel building as I type :-) with the ipfw package built into FreeBSD. I'm also making it work with multipath stuff - I was going to anyway, since I can then use the ipfw engine to implement persistant-route multipath, where you cache the next-hop found for a given source address and keep it for a while (before expiring it if not used for "n" seconds). You could then use this for a scalable transparent web proxy. One or two multipath routers in front of one or two or more web proxies with appropriate configs. You'd need an application that periodically scanned the proxies to make sure they're alive and do appropricate actions. I fully intend deploying this (and will of course make FreeBSD a strong competitor against the likes of Inktomi, NetApp and Mirror Image et al). I might even go so far as implementing the TCP divert that this would require in ipfw, which at the moment it lacks, although the bitmask on ipfw commands means this may be difficult to squeeze in... at least it would all be in one package. In any case, I'm not wild about the way ipfilter does it. Chris. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org. == Head of Systems for Easynet Group PLC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 06:11:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16634 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 06:11:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA16623 for ; Tue, 28 Apr 1998 06:11:47 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id JAA18861; Tue, 28 Apr 1998 09:11:27 -0400 (EDT) Date: Tue, 28 Apr 1998 09:11:27 -0400 (EDT) From: "Matthew N. Dodd" To: David Muir Sharnoff cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Routing problem that I need solved. In-Reply-To: <199804280755.AAA11300@idiom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Check out Vixie's ifdefault patches. On Tue, 28 Apr 1998, David Muir Sharnoff wrote: > > My fellow FreeBSD addicts, I've got a kernel mod that I need done. > I could probably do it myself, but I would much prefer not to as > I've got other fish to fry. I've also got slightly more money than > time. I can afford to $2,000 as a thank-you if someone does this. > > > Idiom is now multi-homed. Idiom has three sets of IP addresses: > 1: addresses that can only be routed through BEST.COM > 2: addresses that can only be routed through ABOVE.NET > 3: addresses that can be routed through either BEST.COM or ABOVE.NET > > Most addresses are type 3 (routed through both). For reliability, > it's important to keep a few key services using type 1 and type 2 > addresses. For example, the two primary nameservers: ns.idiom.com > uses a type 1 address and ns2.idiom.com uses a type 2 address. > > That provides some reliability for the incomming traffic. What I > would like is to make sure that at least some of the outgoing traffic > is symmetrical. > > If a packet is coming _from_ a type 1 address, then it should be > routed out through BEST.COM. If it's coming from a type 2 address then it > should be routed out through ABOVE.NET. > > I run OSPF internally, so the routing situation tends to be a bit > dynamic. > > As many utilities as possible should reply using the address they were > contacted on. DNS, radius, etc. That's a separate problem though. > > My solution to this would be to create another ipfw rule: "route through" > > Example of usage: > > # skip over packets that are inbound. > > ipfw add 100 skipto 200 all from any to 140.174.82/24 # type 1 > ipfw add 110 skipto 200 all from any to 209.66.121/24 # type 2 > ipfw add 120 skipto 200 all from any to 209.157.64/19 # type 3 > > # selectively route type 1 and type 2 outbound > > ipfw add 140 pass through 140.174.37.21 all from 140.174.82/24 to any > ipfw add 150 pass through 209.66.121.1 all from 209.66.121/24 to any > > The semantics of "pass through" are that the next hop for the packet > will be chosen as if it were bound for the address given. The same rule > can be deployed throughout my network. > > There's one other detail that would help things: make the skipto rule fast. > Right now the skipto rule does a linear search. > > I know that $2k is not much money for tricky kernel work, but it's > what I can afford for this. Cisco routers can do routing based on > the source address. > > I use -STABLE. I need a solution that's fit for production use and > also fit for inclusion in -STABLE. > > Thanks, > > -Dave > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 06:23:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19018 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 06:23:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles357.castles.com [208.214.167.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA18989 for ; Tue, 28 Apr 1998 06:23:33 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id FAA00998; Tue, 28 Apr 1998 05:20:22 -0700 (PDT) Message-Id: <199804281220.FAA00998@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Warner Losh cc: "Matthew N. Dodd" , Mike Smith , hackers@FreeBSD.ORG Subject: Re: National Semi SONIC DP83932 support? In-reply-to: Your message of "Mon, 27 Apr 1998 20:49:09 MDT." <199804280249.UAA05523@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Apr 1998 05:20:21 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message "Matthew N. Dodd" writes: > : > It's a SONIC, as the label says. Not 8390x compatible as such, no. > : So a new driver would be needed? > > Or at least a port of a driver.... I believe that OpenBSD/arc has a > driver that I think was derived from one of the OpenBSD/NetBSD mac > ports. I don't know how hard that would be to port to FreeBSD. MacBSD certainly does have SONIC drivers, yes. The real challenge would be working out the differences in interface. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 07:31:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA25723 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 06:56:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dns.ida.net (mail.ida.net [204.228.203.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA25503 for ; Tue, 28 Apr 1998 06:55:57 -0700 (PDT) (envelope-from muck@ida.net) Received: from falcon.hinterlands.com (pm-pt2-24.ida.net [198.60.251.233]) by dns.ida.net (8.8.7/8.8.7) with SMTP id HAA00996; Tue, 28 Apr 1998 07:48:59 -0600 (MDT) Message-ID: <3545E011.41C67EA6@ida.net> Date: Tue, 28 Apr 1998 07:56:33 -0600 From: Mike X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: John-Mark Gurney CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Custom Kernel References: <354521A0.59E2B600@ida.net> <19980427184804.47570@hydrogen.nike.efn.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John-Mark Gurney wrote: > > Mike scribbled this message on Apr 27: > > the web pages should answer these questions... if not, then > freebsd-questions is MUCH better list for these types of questions than > freebsd-hackers... -hackers is for technical discussions... Perhaps I should've phrased my question better. I wasn't interested in technical help for wine, I was curious as to what SYSVSEM was. I would consider that general technical discussion. Nowhere in my message did I beg and plead for some help getting wine to work. Am I sorry for violating the sanctity of your precious list? No. Thanks to all those who responded, though. Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 08:30:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA15031 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 08:30:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from soccer.inetspace.com (soccer.inetspace.com [206.50.163.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA15018 for ; Tue, 28 Apr 1998 08:30:42 -0700 (PDT) (envelope-from kgor@soccer.inetspace.com) Received: (from kgor@localhost) by soccer.inetspace.com (8.8.7/8.8.7) id KAA02000; Tue, 28 Apr 1998 10:29:17 -0500 (CDT) (envelope-from kgor) Date: Tue, 28 Apr 1998 10:29:17 -0500 (CDT) Message-Id: <199804281529.KAA02000@soccer.inetspace.com> From: "Kent S. Gordon" To: imp@village.org CC: chuckr@glue.umd.edu, hackers@FreeBSD.ORG In-reply-to: <199804280440.WAA00423@harmony.village.org> (message from Warner Losh on Mon, 27 Apr 1998 22:40:50 -0600) Subject: Re: ctm question Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "imp" == Warner Losh writes: > In message > Chuck Robey writes: : Got just what you want, Warner ... here's > a cut'n'paste copy of a post : from about a month ago: : : : > cmtmd5 and ctmindex, an alternative to ctm(1) > Hmmmm. I just finished by binary search when this came in. :-( > BTW, is anybody else getting cvs [server aborted]: can not > realloc xxxxxx bytes when they are trying to update > share/dict/web2? I see this when I'm tyring to grab the > RELENG_2_2 branch. It is the only file in the whole three that > barfs for me. This is true even with with the freshest make > world I can grab (from a ctm of earlier today). I had this problem until I allowed for move memory usage by cvs. I would check the login classes used by both the cvs server and the client. diff of multiple megabyte files can take a lot of memory. > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org with > "unsubscribe freebsd-hackers" in the body of the message -- Kent S. Gordon Architect iNetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 08:36:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16557 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 08:36:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yard-sale.village.org (ys2.village.org [204.144.255.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA16547 for ; Tue, 28 Apr 1998 08:36:03 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony.village.org [10.0.0.6] by yard-sale.village.org with esmtp (Exim 1.82 #1) id 0yUCQI-0005Id-00; Tue, 28 Apr 1998 09:35:58 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id JAA04240; Tue, 28 Apr 1998 09:35:38 -0600 (MDT) Message-Id: <199804281535.JAA04240@harmony.village.org> To: "Kent S. Gordon" Subject: Re: ctm question Cc: chuckr@glue.umd.edu, hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 28 Apr 1998 10:29:17 CDT." <199804281529.KAA02000@soccer.inetspace.com> References: <199804281529.KAA02000@soccer.inetspace.com> Date: Tue, 28 Apr 1998 09:35:38 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199804281529.KAA02000@soccer.inetspace.com> "Kent S. Gordon" writes: : I had this problem until I allowed for move memory usage by cvs. I : would check the login classes used by both the cvs server and the : client. diff of multiple megabyte files can take a lot of memory. Give that man a cigar! That did the trick for me. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 08:46:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA18752 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 08:46:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA18742 for ; Tue, 28 Apr 1998 08:46:08 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id LAA27269; Tue, 28 Apr 1998 11:45:58 -0400 (EDT) Date: Tue, 28 Apr 1998 11:45:57 -0400 (EDT) From: Snob Art Genre To: Archie Cobbs cc: hackers@FreeBSD.ORG Subject: Re: Whom to contact? In-Reply-To: <199804280602.XAA05113@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 Apr 1998, Archie Cobbs wrote: > Snob Art Genre writes: > > For ports this is trivial, as I can pull MAINTAINER from the Makefile, > > but how do I determine this for various parts of the base system? > > cvs log? Thanks, but could you give a more detailed answer? I am not wise in the ways of CVS. Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 09:18:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA26373 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 09:18:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA26234; Tue, 28 Apr 1998 09:17:56 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id MAA18518; Tue, 28 Apr 1998 12:17:40 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Tue, 28 Apr 1998 12:17:40 -0400 (EDT) From: "David E. Cross" To: Karl Denninger cc: dyson@FreeBSD.ORG, Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <19980428073841.05698@mcs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, Karl Denninger wrote: > Well, now wait a minute.. > > SIGDANGER is useful if properly trapped and handled. I'd like to see if > supported with the default to be "ignore" (ie: you have to ASK for it to > be delivered and processed). May I ask what good is it if it is ignored by default???? Default should be as it is on AIX, to terminate the process. In general you care more about system processes than user procs, so I would "make world" on my system if this got added, with all the system procs having a one line addition in main() to ignore the signal, and I would be ready to go. -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 09:58:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06216 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 09:58:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hacker.cybernet.com (hacker.cybernet.com [192.245.33.142]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06203 for ; Tue, 28 Apr 1998 09:58:03 -0700 (PDT) (envelope-from msuarez@cybernet.com) Received: from hacker.cybernet.com (localhost [127.0.0.1]) by hacker.cybernet.com (8.8.8/8.8.8) with ESMTP id MAA18214 for ; Tue, 28 Apr 1998 12:58:08 -0400 (EDT) (envelope-from msuarez@cybernet.com) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.2.p0.FreeBSD:980428125808:18166=_" Date: Tue, 28 Apr 1998 12:58:08 -0400 (EDT) Reply-To: msuarez@cybernet.com Organization: Cybernet Systems Corp. (734) 668-2567 From: "Michael A. Suarez" To: FreeBSD Hackers Subject: Kernel Programming Question Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.2.p0.FreeBSD:980428125808:18166=_ Content-Type: text/plain; charset=us-ascii I am trying to make a kernel hack that does the following: If the high bit of the text segment size is set, which in any normal circumstance would be very unlikely, when that executable is loaded, a md5 checksum would be generated and stored in the proc structure of that running executable. I use the p_pad1 and p_pad2 elements of the proc structure to store upto 6 bytes of the calculated checksum. (Yes, I know this is a real hack, but I only need it for this one machine's kernel). I have coded it to the point that the checksum calculations occur if the high-bit is set. Essentially I have modified the imgact_aout to notice the high-bit is set and then set proc->p_pad1[0]=1 if it was. Then in kern_exec, I read through the executable file and, currently, only calculate and print the sum. The problem is that it only works about half the time. It fails when trying to read the file on the vn_rdwr call. It fails by simply hanging the processes, vn_rdwr does not return. If I look at the process list, the process is hung in the DV+ state. Also, the system is somewhat flakey after that. When it works, however, it calculates the sum and continues to execute the program without a hitch. I have included both the imgact_aout changes and the kern_exec changes. These are from the 2.2.2 source tree. If anyone has any suggestions, I would be very happy to hear them. Thanks, Michael msuarez@cybernet.com --_=XFMail.1.2.p0.FreeBSD:980428125808:18166=_ Content-Disposition: attachment; filename="kern_exec.c" Content-Transfer-Encoding: base64 Content-Description: kern_exec.c Content-Type: application/octet-stream; name=kern_exec.c; SizeOnDisk=16865 LyoKICogQ29weXJpZ2h0IChjKSAxOTkzLCBEYXZpZCBHcmVlbm1hbgogKiBBbGwgcmlnaHRzIHJl c2VydmVkLgogKgogKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5 IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHBy b3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCiAqIGFyZSBtZXQ6CiAqIDEuIFJl ZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJp Z2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dp bmcgZGlzY2xhaW1lci4KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2Yg Y29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1 bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJp YnV0aW9uLgogKgogKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5E IENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECiAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FS UkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQogKiBJTVBMSUVEIFdB UlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRQogKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1Ig T1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQogKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElO Q0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAogKiBEQU1BR0VT IChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVU RSBHT09EUwogKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9S IEJVU0lORVNTIElOVEVSUlVQVElPTikKICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVP UlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKICogTElBQklMSVRZ LCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4g QU5ZIFdBWQogKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklT RUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCiAqIFNVQ0ggREFNQUdFLgogKgogKgkkSWQ6IGtlcm5f ZXhlYy5jLHYgMS40IDE5OTgvMDQvMjcgMTQ6MjU6NDUgbXN1YXJleiBFeHAgbXN1YXJleiAkCiAq LwoKI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgojaW5jbHVkZSA8c3lzL3N5c3RtLmg+CiNpbmNsdWRl IDxzeXMvc3lzcHJvdG8uaD4KI2luY2x1ZGUgPHN5cy9zaWduYWx2YXIuaD4KI2luY2x1ZGUgPHN5 cy9rZXJuZWwuaD4KI2luY2x1ZGUgPHN5cy9tb3VudC5oPgojaW5jbHVkZSA8c3lzL2ZpbGVkZXNj Lmg+CiNpbmNsdWRlIDxzeXMvZmNudGwuaD4KI2luY2x1ZGUgPHN5cy9hY2N0Lmg+CiNpbmNsdWRl IDxzeXMvZXhlYy5oPgojaW5jbHVkZSA8c3lzL2ltZ2FjdC5oPgojaW5jbHVkZSA8c3lzL2ltZ2Fj dF9lbGYuaD4KI2luY2x1ZGUgPHN5cy93YWl0Lmg+CiNpbmNsdWRlIDxzeXMvcHJvYy5oPgojaW5j bHVkZSA8c3lzL21hbGxvYy5oPgojaW5jbHVkZSA8c3lzL25hbWVpLmg+CiNpbmNsdWRlIDxzeXMv c3lzZW50Lmg+CiNpbmNsdWRlIDxzeXMvc2htLmg+CiNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiNp bmNsdWRlIDxzeXMvdm5vZGUuaD4KI2luY2x1ZGUgPHN5cy9idWYuaD4KCiNpbmNsdWRlIDx2bS92 bS5oPgojaW5jbHVkZSA8dm0vdm1fcGFyYW0uaD4KI2luY2x1ZGUgPHZtL3ZtX3Byb3QuaD4KI2lu Y2x1ZGUgPHZtL2xvY2suaD4KI2luY2x1ZGUgPHZtL3BtYXAuaD4KI2luY2x1ZGUgPHZtL3ZtX21h cC5oPgojaW5jbHVkZSA8dm0vdm1fa2Vybi5oPgojaW5jbHVkZSA8dm0vdm1fZXh0ZXJuLmg+CiNp bmNsdWRlIDx2bS92bV9vYmplY3QuaD4KCiNpbmNsdWRlIDxtYWNoaW5lL3JlZy5oPgoKc3RhdGlj IGludCAqZXhlY19jb3B5b3V0X3N0cmluZ3MgX19QKChzdHJ1Y3QgaW1hZ2VfcGFyYW1zICopKTsK CnN0YXRpYyBpbnQgZXhlY19jaGVja19wZXJtaXNzaW9ucyhzdHJ1Y3QgaW1hZ2VfcGFyYW1zICop OwoKLyoKICogWFhYIHRyb3VibGUgaGVyZSBpZiBzaXplb2YoY2FkZHJfdCkgIT0gc2l6ZW9mKGlu dCksIG90aGVyIHBhcnRzCiAqIG9mIHRoZSBzeXNjdGwgY29kZSBhbHNvIGFzc3VtZXMgdGhpcywg YW5kIHNpemVvZihpbnQpID09IHNpemVvZihsb25nKS4KICovCnN0YXRpYyBzdHJ1Y3QgcHNfc3Ry aW5ncyAqcHNfc3RyaW5ncyA9IFBTX1NUUklOR1M7ClNZU0NUTF9JTlQoX2tlcm4sIEtFUk5fUFNf U1RSSU5HUywgcHNfc3RyaW5ncywgMCwgJnBzX3N0cmluZ3MsIDAsICIiKTsKCnN0YXRpYyBjYWRk cl90IHVzcnN0YWNrID0gKGNhZGRyX3QpVVNSU1RBQ0s7ClNZU0NUTF9JTlQoX2tlcm4sIEtFUk5f VVNSU1RBQ0ssIHVzcnN0YWNrLCAwLCAmdXNyc3RhY2ssIDAsICIiKTsKCi8qCiAqIGV4ZWNzd19z ZXQgaXMgY29uc3RydWN0ZWQgZm9yIHVzIGJ5IHRoZSBsaW5rZXIuICBFYWNoIG9mIHRoZSBpdGVt cwogKiBpcyBhIHBvaW50ZXIgdG8gYSBgY29uc3Qgc3RydWN0IGV4ZWNzdycsIGhlbmNlIHRoZSBk b3VibGUgcG9pbnRlciBoZXJlLgogKi8Kc3RhdGljIGNvbnN0IHN0cnVjdCBleGVjc3cgKipleGVj c3cgPSAKCShjb25zdCBzdHJ1Y3QgZXhlY3N3ICoqKSZleGVjc3dfc2V0LmxzX2l0ZW1zWzBdOwoK I2lmbmRlZiBfU1lTX1NZU1BST1RPX0hfCnN0cnVjdCBleGVjdmVfYXJncyB7CiAgICAgICAgY2hh ciAgICAqZm5hbWU7IAogICAgICAgIGNoYXIgICAgKiphcmd2OwogICAgICAgIGNoYXIgICAgKipl bnZ2OyAKfTsKI2VuZGlmCgovKgogKiBleGVjdmUoKSBzeXN0ZW0gY2FsbC4KICovCmludApleGVj dmUocCwgdWFwLCByZXR2YWwpCglzdHJ1Y3QgcHJvYyAqcDsKCXJlZ2lzdGVyIHN0cnVjdCBleGVj dmVfYXJncyAqdWFwOwoJaW50ICpyZXR2YWw7CnsKCXN0cnVjdCBuYW1laWRhdGEgbmQsICpuZHA7 CglpbnQgKnN0YWNrX2Jhc2U7CglpbnQgZXJyb3IsIGxlbiwgaTsKCXN0cnVjdCBpbWFnZV9wYXJh bXMgaW1hZ2VfcGFyYW1zLCAqaW1ncDsKCXN0cnVjdCB2YXR0ciBhdHRyOwoJc3RydWN0IGJ1ZiAq YnAgPSBOVUxMOwoKCWltZ3AgPSAmaW1hZ2VfcGFyYW1zOwoKCS8qCgkgKiBJbml0aWFsaXplIHBh cnQgb2YgdGhlIGNvbW1vbiBkYXRhCgkgKi8KCWltZ3AtPnByb2MgPSBwOwoJaW1ncC0+dWFwID0g dWFwOwoJaW1ncC0+YXR0ciA9ICZhdHRyOwoJaW1ncC0+aW1hZ2VfaGVhZGVyID0gTlVMTDsKCWlt Z3AtPmFyZ2MgPSBpbWdwLT5lbnZjID0gMDsKCWltZ3AtPmVudHJ5X2FkZHIgPSAwOwoJaW1ncC0+ dm1zcGFjZV9kZXN0cm95ZWQgPSAwOwoJaW1ncC0+aW50ZXJwcmV0ZWQgPSAwOwoJaW1ncC0+aW50 ZXJwcmV0ZXJfbmFtZVswXSA9ICdcMCc7CglpbWdwLT5hdXhhcmdzID0gTlVMTDsKCgkvKgoJICog QWxsb2NhdGUgdGVtcG9yYXJ5IGRlbWFuZCB6ZXJvZWQgc3BhY2UgZm9yIGFyZ3VtZW50IGFuZAoJ ICoJZW52aXJvbm1lbnQgc3RyaW5ncwoJICovCglpbWdwLT5zdHJpbmdiYXNlID0gKGNoYXIgKilr bWVtX2FsbG9jX3dhaXQoZXhlY19tYXAsIEFSR19NQVgpOwoJaWYgKGltZ3AtPnN0cmluZ2Jhc2Ug PT0gTlVMTCkgewoJCWVycm9yID0gRU5PTUVNOwoJCWdvdG8gZXhlY19mYWlsOwoJfQoJaW1ncC0+ c3RyaW5ncCA9IGltZ3AtPnN0cmluZ2Jhc2U7CglpbWdwLT5zdHJpbmdzcGFjZSA9IEFSR19NQVg7 CgoJLyoKCSAqIFRyYW5zbGF0ZSB0aGUgZmlsZSBuYW1lLiBuYW1laSgpIHJldHVybnMgYSB2bm9k ZSBwb2ludGVyCgkgKglpbiBuaV92cCBhbW91bmcgb3RoZXIgdGhpbmdzLgoJICovCgluZHAgPSAm bmQ7CglORElOSVQobmRwLCBMT09LVVAsIExPQ0tMRUFGIHwgRk9MTE9XIHwgU0FWRU5BTUUsCgkg ICAgVUlPX1VTRVJTUEFDRSwgdWFwLT5mbmFtZSwgcCk7CgppbnRlcnByZXQ6CgoJZXJyb3IgPSBu YW1laShuZHApOwoJaWYgKGVycm9yKSB7CgkJa21lbV9mcmVlX3dha2V1cChleGVjX21hcCwgKHZt X29mZnNldF90KWltZ3AtPnN0cmluZ2Jhc2UsIEFSR19NQVgpOwoJCWdvdG8gZXhlY19mYWlsOwoJ fQoKCWltZ3AtPnZwID0gbmRwLT5uaV92cDsKCgkvKgoJICogQ2hlY2sgZmlsZSBwZXJtaXNzaW9u cyAoYWxzbyAnb3BlbnMnIGZpbGUpCgkgKi8KCWVycm9yID0gZXhlY19jaGVja19wZXJtaXNzaW9u cyhpbWdwKTsKCWlmIChlcnJvcikgewoJCVZPUF9VTkxPQ0soaW1ncC0+dnApOwoJCWdvdG8gZXhl Y19mYWlsX2RlYWxsb2M7Cgl9CgoJLyoKCSAqIEdldCB0aGUgaW1hZ2UgaGVhZGVyLCB3aGljaCB3 ZSBkZWZpbmUgaGVyZSBhcyBtZWFuaW5nIHRoZSBmaXJzdAoJICogcGFnZSBvZiB0aGUgZXhlY3V0 YWJsZS4KCSAqLwoJaWYgKGltZ3AtPnZwLT52X29iamVjdCAmJiBpbWdwLT52cC0+dl9tb3VudCAm JgoJICAgIGltZ3AtPnZwLT52X21vdW50LT5tbnRfc3RhdC5mX2lvc2l6ZSA+PSBQQUdFX1NJWkUg JiYKCSAgICBpbWdwLT52cC0+dl9vYmplY3QtPnVuX3BhZ2VyLnZucC52bnBfc2l6ZSA+PQoJICAg IGltZ3AtPnZwLT52X21vdW50LT5tbnRfc3RhdC5mX2lvc2l6ZSkgewoJCS8qCgkJICogR2V0IGEg YnVmZmVyIHdpdGggKGF0IGxlYXN0KSB0aGUgZmlyc3QgcGFnZS4KCQkgKi8KCQllcnJvciA9IGJy ZWFkKGltZ3AtPnZwLCAwLCBpbWdwLT52cC0+dl9tb3VudC0+bW50X3N0YXQuZl9pb3NpemUsCgkJ ICAgICBwLT5wX3VjcmVkLCAmYnApOwoJCWltZ3AtPmltYWdlX2hlYWRlciA9IGJwLT5iX2RhdGE7 Cgl9IGVsc2UgewoJCWludCByZXNpZDsKCgkJLyoKCQkgKiBUaGUgZmlsZXN5c3RlbSBibG9jayBz aXplIGlzIHRvbyBzbWFsbCwgc28gZG8gdGhpcyB0aGUgaGFyZAoJCSAqIHdheS4gTWFsbG9jIHNv bWUgc3BhY2UgYW5kIHJlYWQgUEFHRV9TSVpFIHdvcnRoIG9mIHRoZSBpbWFnZQoJCSAqIGhlYWRl ciBpbnRvIGl0LgoJCSAqLwoJCWltZ3AtPmltYWdlX2hlYWRlciA9IG1hbGxvYyhQQUdFX1NJWkUs IE1fVEVNUCwgTV9XQUlUT0spOwoJCWVycm9yID0gdm5fcmR3cihVSU9fUkVBRCwgaW1ncC0+dnAs ICh2b2lkICopaW1ncC0+aW1hZ2VfaGVhZGVyLCBQQUdFX1NJWkUsIDAsCgkJICAgIFVJT19TWVNT UEFDRSwgSU9fTk9ERUxPQ0tFRCwgcC0+cF91Y3JlZCwgJnJlc2lkLCBwKTsKCQkvKgoJCSAqIENs ZWFyIG91dCBhbnkgcmVtYWluaW5nIGp1bmsuCgkJICovCgkJaWYgKCFlcnJvciAmJiByZXNpZCkK CQkJYnplcm8oKGNoYXIgKilpbWdwLT5pbWFnZV9oZWFkZXIgKyBQQUdFX1NJWkUgLSByZXNpZCwg cmVzaWQpOwoJfQogICAgICAgICAgICAgICAgICAgIAoJLyoKCSAqIExvb3AgdGhyb3VnaCBsaXN0 IG9mIGltYWdlIGFjdGl2YXRvcnMsIGNhbGxpbmcgZWFjaCBvbmUuCgkgKglJZiB0aGVyZSBpcyBu byBtYXRjaCwgdGhlIGFjdGl2YXRvciByZXR1cm5zIC0xLiBJZiB0aGVyZQoJICoJaXMgYSBtYXRj aCwgYnV0IHRoZXJlIHdhcyBhbiBlcnJvciBkdXJpbmcgdGhlIGFjdGl2YXRpb24sCgkgKgl0aGUg ZXJyb3IgaXMgcmV0dXJuZWQuIE90aGVyd2lzZSAwIG1lYW5zIHN1Y2Nlc3MuIElmIHRoZQoJICoJ aW1hZ2UgaXMgaW50ZXJwcmV0ZWQsIGxvb3AgYmFjayB1cCBhbmQgdHJ5IGFjdGl2YXRpbmcKCSAq CXRoZSBpbnRlcnByZXRlci4KCSAqLwoJZm9yIChpID0gMDsgZXhlY3N3W2ldOyArK2kpIHsKCQlp ZiAoZXhlY3N3W2ldLT5leF9pbWdhY3QpCgkJCWVycm9yID0gKCpleGVjc3dbaV0tPmV4X2ltZ2Fj dCkoaW1ncCk7CgkJZWxzZQoJCQljb250aW51ZTsKCQlpZiAoZXJyb3IgPT0gLTEpCgkJCWNvbnRp bnVlOwoJCWlmIChlcnJvcikgewogICAgICAgICAgICAgICAgCVZPUF9VTkxPQ0soaW1ncC0+dnAp OwoJCQlnb3RvIGV4ZWNfZmFpbF9kZWFsbG9jOwogICAgICAgICAgICAgICAgfQoJCWlmIChpbWdw LT5pbnRlcnByZXRlZCkgewoJCQkvKiBmcmVlIG9sZCBicC9pbWFnZV9oZWFkZXIgKi8KCQkJaWYg KGJwICE9IE5VTEwpIHsKCQkJCWJyZWxzZShicCk7CgkJCQlicCA9IE5VTEw7CgkJCX0gZWxzZSB7 CgkJCQlmcmVlKCh2b2lkICopaW1ncC0+aW1hZ2VfaGVhZGVyLCBNX1RFTVApOwoJCQkJaW1ncC0+ aW1hZ2VfaGVhZGVyID0gTlVMTDsKCQkJfQoJCQkvKiBmcmVlIG9sZCB2bm9kZSBhbmQgbmFtZSBi dWZmZXIgKi8KCQkJVk9QX1VOTE9DSyhpbWdwLT52cCk7CgkJCWlmIChlcnJvcikgZ290byBleGVj X2ZhaWxfZGVhbGxvYzsgICAgICAgICAgICAgICAgICAgICAgIAoJCQl2cmVsZShuZHAtPm5pX3Zw KTsKCQkJRlJFRShuZHAtPm5pX2NuZC5jbl9wbmJ1ZiwgTV9OQU1FSSk7CgkJCS8qIHNldCBuZXcg bmFtZSB0byB0aGF0IG9mIHRoZSBpbnRlcnByZXRlciAqLwoJCQlORElOSVQobmRwLCBMT09LVVAs IExPQ0tMRUFGIHwgRk9MTE9XIHwgU0FWRU5BTUUsCgkJCSAgICBVSU9fU1lTU1BBQ0UsIGltZ3At PmludGVycHJldGVyX25hbWUsIHApOwoJCQlnb3RvIGludGVycHJldDsKCQl9CgkJYnJlYWs7Cgl9 CgkvKiBJZiB3ZSBtYWRlIGl0IHRocm91Z2ggYWxsIHRoZSBhY3RpdmF0b3JzIGFuZCBub25lIG1h dGNoZWQsIGV4aXQuICovCglpZiAoZXJyb3IgPT0gLTEpIHsKICAgICAgICAJVk9QX1VOTE9DSyhp bWdwLT52cCk7CgkJZXJyb3IgPSBFTk9FWEVDOwoJCWdvdG8gZXhlY19mYWlsX2RlYWxsb2M7Cgl9 CgogICAgICAgIGlmKGltZ3AtPnByb2MtPnBfcGFkMVswXSkgCiAgICAgICAgIHsKICAgICAgICAg IHVfaW50MzJfdCByZXNpZD0wLCBlcnJvcj0wLCBzdW09MCwgb2Zmc2V0PTA7CiAgICAgICAgICB1 bnNpZ25lZCBjaGFyICpidWY7CiAgICAgICAgICAKICAgICAgICAgIGJ1Zj0odW5zaWduZWQgY2hh ciAqKSBtYWxsb2MoUEFHRV9TSVpFLCBNX1RFTVAsIE1fV0FJVE9LKTsKICAgICAgICAgIGlmKGJ1 ZikgCiAgICAgICAgICAgd2hpbGUoIWVycm9yICYmICFyZXNpZCkgCiAgICAgICAgICAgIHsKICAg ICAgICAgICAgIGVycm9yPXZuX3Jkd3IoVUlPX1JFQUQsaW1ncC0+dnAsKHZvaWQgKikgYnVmLFBB R0VfU0laRSxvZmZzZXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgIFVJT19TWVNTUEFDRSxJ T19OT0RFTE9DS0VELHAtPnBfdWNyZWQsJnJlc2lkLHApOwogICAgICAgICAgICAgaWYoIWVycm9y KSAKICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgIGludCB0PTA7CiAgICAgICAgICAgICAg IGlmKHJlc2lkKSBiemVybygoY2hhciAqKWJ1ZitQQUdFX1NJWkUtcmVzaWQscmVzaWQpOwogICAg ICAgICAgICAgICBmb3IodD0wOyB0PFBBR0VfU0laRS1yZXNpZDsgdCsrKSBzdW0rPWJ1Zlt0XTsK ICAgICAgICAgICAgICAgb2Zmc2V0Kz1QQUdFX1NJWkU7CiAgICAgICAgICAgICAgfQogICAgICAg ICAgICB9CiAgICAgICAgICBwcmludGYoIlNVTT0lZFxuIixzdW0pOyAgCiAgICAgICAgICBpZihi dWYpIGZyZWUoYnVmLE1fVEVNUCk7ICAgICAgICAgIAogICAgICAgICAgaW1ncC0+cHJvYy0+cF9w YWQxWzBdPTA7CiAgICAgICAgIH0KICAKICAgICAgICAKCVZPUF9VTkxPQ0soaW1ncC0+dnApOwoJ aWYgKGVycm9yKQoJCWdvdG8gZXhlY19mYWlsX2RlYWxsb2M7CgkKCS8qCgkgKiBDb3B5IG91dCBz dHJpbmdzIChhcmdzIGFuZCBlbnYpIGFuZCBpbml0aWFsaXplIHN0YWNrIGJhc2UKCSAqLwoJc3Rh Y2tfYmFzZSA9IGV4ZWNfY29weW91dF9zdHJpbmdzKGltZ3ApOwoJcC0+cF92bXNwYWNlLT52bV9t aW5zYWRkciA9IChjaGFyICopc3RhY2tfYmFzZTsKCgkvKgoJICogSWYgY3VzdG9tIHN0YWNrIGZp eHVwIHJvdXRpbmUgcHJlc2VudCBmb3IgdGhpcyBwcm9jZXNzCgkgKiBsZXQgaXQgZG8gdGhlIHN0 YWNrIHNldHVwLgoJICogRWxzZSBzdHVmZiBhcmd1bWVudCBjb3VudCBhcyBmaXJzdCBpdGVtIG9u IHN0YWNrCgkgKi8KCWlmIChwLT5wX3N5c2VudC0+c3ZfZml4dXApCgkJKCpwLT5wX3N5c2VudC0+ c3ZfZml4dXApKCZzdGFja19iYXNlLCBpbWdwKTsKCWVsc2UKCQlzdXdvcmQoLS1zdGFja19iYXNl LCBpbWdwLT5hcmdjKTsKCgkvKiBjbG9zZSBmaWxlcyBvbiBleGVjICovCglmZGNsb3NlZXhlYyhw KTsKCgkvKiByZXNldCBjYXVnaHQgc2lnbmFscyAqLwoJZXhlY3NpZ3MocCk7CgoJLyogbmFtZSB0 aGlzIHByb2Nlc3MgLSBuYW1laWV4ZWMocCwgbmRwKSAqLwoJbGVuID0gbWluKG5kcC0+bmlfY25k LmNuX25hbWVsZW4sTUFYQ09NTEVOKTsKCWJjb3B5KG5kcC0+bmlfY25kLmNuX25hbWVwdHIsIHAt PnBfY29tbSwgbGVuKTsKCXAtPnBfY29tbVtsZW5dID0gMDsKCgkvKgoJICogbWFyayBhcyBleGVj ZWQsIHdha2V1cCB0aGUgcHJvY2VzcyB0aGF0IHZmb3JrZWQgKGlmIGFueSkgYW5kIHRlbGwKCSAq IGl0IHRoYXQgaXQgbm93IGhhcyBpdCdzIG93biByZXNvdXJjZXMgYmFjawoJICovCglwLT5wX2Zs YWcgfD0gUF9FWEVDOwoJaWYgKHAtPnBfcHB0ciAmJiAocC0+cF9mbGFnICYgUF9QUFdBSVQpKSB7 CgkJcC0+cF9mbGFnICY9IH5QX1BQV0FJVDsKCQl3YWtldXAoKGNhZGRyX3QpcC0+cF9wcHRyKTsK CX0KCgkvKgoJICogSW1wbGVtZW50IGltYWdlIHNldHVpZC9zZXRnaWQuIERpc2FsbG93IGlmIHRo ZSBwcm9jZXNzIGlzCgkgKiBiZWluZyB0cmFjZWQuCgkgKi8KCWlmICgoYXR0ci52YV9tb2RlICYg KFZTVUlEIHwgVlNHSUQpKSAmJgoJICAgIChwLT5wX2ZsYWcgJiBQX1RSQUNFRCkgPT0gMCkgewoJ CS8qCgkJICogVHVybiBvZmYgc3lzY2FsbCB0cmFjaW5nIGZvciBzZXQtaWQgcHJvZ3JhbXMsIGV4 Y2VwdCBmb3IKCQkgKiByb290LgoJCSAqLwoJCWlmIChwLT5wX3RyYWNlcCAmJiBzdXNlcihwLT5w X3VjcmVkLCAmcC0+cF9hY2ZsYWcpKSB7CgkJCXAtPnBfdHJhY2VmbGFnID0gMDsKCQkJdnJlbGUo cC0+cF90cmFjZXApOwoJCQlwLT5wX3RyYWNlcCA9IE5VTEw7CgkJfQoJCS8qCgkJICogU2V0IHRo ZSBuZXcgY3JlZGVudGlhbHMuCgkJICovCgkJcC0+cF91Y3JlZCA9IGNyY29weShwLT5wX3VjcmVk KTsKCQlpZiAoYXR0ci52YV9tb2RlICYgVlNVSUQpCgkJCXAtPnBfdWNyZWQtPmNyX3VpZCA9IGF0 dHIudmFfdWlkOwoJCWlmIChhdHRyLnZhX21vZGUgJiBWU0dJRCkKCQkJcC0+cF91Y3JlZC0+Y3Jf Z3JvdXBzWzBdID0gYXR0ci52YV9naWQ7CgkJcC0+cF9mbGFnIHw9IFBfU1VHSUQ7Cgl9IGVsc2Ug ewoJICAgICAgICBpZiAocC0+cF91Y3JlZC0+Y3JfdWlkID09IHAtPnBfY3JlZC0+cF9ydWlkICYm CgkJICAgIHAtPnBfdWNyZWQtPmNyX2dpZCA9PSBwLT5wX2NyZWQtPnBfcmdpZCkKCQkJcC0+cF9m bGFnICY9IH5QX1NVR0lEOwoJfQoKCS8qCgkgKiBJbXBsZW1lbnQgY29ycmVjdCBQT1NJWCBzYXZl ZC1pZCBiZWhhdmlvci4KCSAqLwoJcC0+cF9jcmVkLT5wX3N2dWlkID0gcC0+cF91Y3JlZC0+Y3Jf dWlkOwoJcC0+cF9jcmVkLT5wX3N2Z2lkID0gcC0+cF91Y3JlZC0+Y3JfZ2lkOwoKCS8qCgkgKiBT dG9yZSB0aGUgdnAgZm9yIHVzZSBpbiBwcm9jZnMKCSAqLwoJaWYgKHAtPnBfdGV4dHZwKQkJLyog cmVsZWFzZSBvbGQgcmVmZXJlbmNlICovCgkJdnJlbGUocC0+cF90ZXh0dnApOwoJVlJFRihuZHAt Pm5pX3ZwKTsKCXAtPnBfdGV4dHZwID0gbmRwLT5uaV92cDsKCgkvKgoJICogSWYgdHJhY2luZyB0 aGUgcHJvY2VzcywgdHJhcCB0byBkZWJ1Z2dlciBzbyBicmVha3BvaW50cwoJICogCWNhbiBiZSBz ZXQgYmVmb3JlIHRoZSBwcm9ncmFtIGV4ZWN1dGVzLgoJICovCglpZiAocC0+cF9mbGFnICYgUF9U UkFDRUQpCgkJcHNpZ25hbChwLCBTSUdUUkFQKTsKCgkvKiBjbGVhciAiZm9yayBidXQgbm8gZXhl YyIgZmxhZywgYXMgd2UgX2FyZV8gZXhlY2luZyAqLwoJcC0+cF9hY2ZsYWcgJj0gfkFGT1JLOwoK CS8qIFNldCBlbnRyeSBhZGRyZXNzICovCglzZXRyZWdzKHAsIGltZ3AtPmVudHJ5X2FkZHIsICh1 X2xvbmcpc3RhY2tfYmFzZSk7CgoJLyoKCSAqIGZyZWUgdmFyaW91cyBhbGxvY2F0ZWQgcmVzb3Vy Y2VzCgkgKi8KCWttZW1fZnJlZV93YWtldXAoZXhlY19tYXAsICh2bV9vZmZzZXRfdClpbWdwLT5z dHJpbmdiYXNlLCBBUkdfTUFYKTsKCWlmIChicCAhPSBOVUxMKQoJCWJyZWxzZShicCk7CgllbHNl IGlmIChpbWdwLT5pbWFnZV9oZWFkZXIgIT0gTlVMTCkKCQlmcmVlKCh2b2lkICopaW1ncC0+aW1h Z2VfaGVhZGVyLCBNX1RFTVApOwoJdnJlbGUobmRwLT5uaV92cCk7CglGUkVFKG5kcC0+bmlfY25k LmNuX3BuYnVmLCBNX05BTUVJKTsKCglyZXR1cm4gKDApOwoKZXhlY19mYWlsX2RlYWxsb2M6Cglp ZiAoaW1ncC0+c3RyaW5nYmFzZSAhPSBOVUxMKQoJCWttZW1fZnJlZV93YWtldXAoZXhlY19tYXAs ICh2bV9vZmZzZXRfdClpbWdwLT5zdHJpbmdiYXNlLCBBUkdfTUFYKTsKCWlmIChicCAhPSBOVUxM KQoJCWJyZWxzZShicCk7CgllbHNlIGlmIChpbWdwLT5pbWFnZV9oZWFkZXIgIT0gTlVMTCkKCQlm cmVlKCh2b2lkICopaW1ncC0+aW1hZ2VfaGVhZGVyLCBNX1RFTVApOwoJaWYgKG5kcC0+bmlfdnAp IHsKCQl2cmVsZShuZHAtPm5pX3ZwKTsKCQlGUkVFKG5kcC0+bmlfY25kLmNuX3BuYnVmLCBNX05B TUVJKTsKCX0KCmV4ZWNfZmFpbDoKCWlmIChpbWdwLT52bXNwYWNlX2Rlc3Ryb3llZCkgewoJCS8q IHNvcnJ5LCBubyBtb3JlIHByb2Nlc3MgYW55bW9yZS4gZXhpdCBncmFjZWZ1bGx5ICovCgkJZXhp dDEocCwgV19FWElUQ09ERSgwLCBTSUdBQlJUKSk7CgkJLyogTk9UIFJFQUNIRUQgKi8KCQlyZXR1 cm4oMCk7Cgl9IGVsc2UgewoJCXJldHVybihlcnJvcik7Cgl9Cn0KCi8qCiAqIERlc3Ryb3kgb2xk IGFkZHJlc3Mgc3BhY2UsIGFuZCBhbGxvY2F0ZSBhIG5ldyBzdGFjawogKglUaGUgbmV3IHN0YWNr IGlzIG9ubHkgU0dST1dTSVogbGFyZ2UgYmVjYXVzZSBpdCBpcyBncm93bgogKglhdXRvbWF0aWNh bGx5IGluIHRyYXAuYy4KICovCmludApleGVjX25ld192bXNwYWNlKGltZ3ApCglzdHJ1Y3QgaW1h Z2VfcGFyYW1zICppbWdwOwp7CglpbnQgZXJyb3I7CglzdHJ1Y3Qgdm1zcGFjZSAqdm1zcGFjZSA9 IGltZ3AtPnByb2MtPnBfdm1zcGFjZTsKCWNhZGRyX3QJc3RhY2tfYWRkciA9IChjYWRkcl90KSAo VVNSU1RBQ0sgLSBTR1JPV1NJWik7CgoJaW1ncC0+dm1zcGFjZV9kZXN0cm95ZWQgPSAxOwoKCS8q IEJsb3cgYXdheSBlbnRpcmUgcHJvY2VzcyBWTSAqLwoJaWYgKHZtc3BhY2UtPnZtX3NobSkKCQlz aG1leGl0KGltZ3AtPnByb2MpOwoJcG1hcF9yZW1vdmVfcGFnZXMoJnZtc3BhY2UtPnZtX3BtYXAs IDAsIFVTUlNUQUNLKTsKCXZtX21hcF9yZW1vdmUoJnZtc3BhY2UtPnZtX21hcCwgMCwgVVNSU1RB Q0spOwoKCS8qIEFsbG9jYXRlIGEgbmV3IHN0YWNrICovCgllcnJvciA9IHZtX21hcF9maW5kKCZ2 bXNwYWNlLT52bV9tYXAsIE5VTEwsIDAsICh2bV9vZmZzZXRfdCAqKSZzdGFja19hZGRyLAoJICAg IFNHUk9XU0laLCBGQUxTRSwgVk1fUFJPVF9BTEwsIFZNX1BST1RfQUxMLCAwKTsKCWlmIChlcnJv cikKCQlyZXR1cm4oZXJyb3IpOwoKCXZtc3BhY2UtPnZtX3NzaXplID0gU0dST1dTSVogPj4gUEFH RV9TSElGVDsKCgkvKiBJbml0aWFsaXplIG1heGltdW0gc3RhY2sgYWRkcmVzcyAqLwoJdm1zcGFj ZS0+dm1fbWF4c2FkZHIgPSAoY2hhciAqKVVTUlNUQUNLIC0gTUFYU1NJWjsKCglyZXR1cm4oMCk7 Cn0KCi8qCiAqIENvcHkgb3V0IGFyZ3VtZW50IGFuZCBlbnZpcm9ubWVudCBzdHJpbmdzIGZyb20g dGhlIG9sZCBwcm9jZXNzCiAqCWFkZHJlc3Mgc3BhY2UgaW50byB0aGUgdGVtcG9yYXJ5IHN0cmlu ZyBidWZmZXIuCiAqLwppbnQKZXhlY19leHRyYWN0X3N0cmluZ3MoaW1ncCkKCXN0cnVjdCBpbWFn ZV9wYXJhbXMgKmltZ3A7CnsKCWNoYXIJKiphcmd2LCAqKmVudnY7CgljaGFyCSphcmdwLCAqZW52 cDsKCWludAllcnJvciwgbGVuZ3RoOwoKCS8qCgkgKiBleHRyYWN0IGFyZ3VtZW50cyBmaXJzdAoJ ICovCgoJYXJndiA9IGltZ3AtPnVhcC0+YXJndjsKCglpZiAoYXJndikgewoJCXdoaWxlICgoYXJn cCA9IChjYWRkcl90KSBmdXdvcmQoYXJndisrKSkpIHsKCQkJaWYgKGFyZ3AgPT0gKGNhZGRyX3Qp IC0xKQoJCQkJcmV0dXJuIChFRkFVTFQpOwoJCQlpZiAoKGVycm9yID0gY29weWluc3RyKGFyZ3As IGltZ3AtPnN0cmluZ3AsCgkJCSAgICBpbWdwLT5zdHJpbmdzcGFjZSwgJmxlbmd0aCkpKSB7CgkJ CQlpZiAoZXJyb3IgPT0gRU5BTUVUT09MT05HKQoJCQkJCXJldHVybihFMkJJRyk7CgkJCQlyZXR1 cm4gKGVycm9yKTsKCQkJfQoJCQlpbWdwLT5zdHJpbmdzcGFjZSAtPSBsZW5ndGg7CgkJCWltZ3At PnN0cmluZ3AgKz0gbGVuZ3RoOwoJCQlpbWdwLT5hcmdjKys7CgkJfQoJfQoKCS8qCgkgKiBleHRy YWN0IGVudmlyb25tZW50IHN0cmluZ3MKCSAqLwoKCWVudnYgPSBpbWdwLT51YXAtPmVudnY7CgoJ aWYgKGVudnYpIHsKCQl3aGlsZSAoKGVudnAgPSAoY2FkZHJfdCkgZnV3b3JkKGVudnYrKykpKSB7 CgkJCWlmIChlbnZwID09IChjYWRkcl90KSAtMSkKCQkJCXJldHVybiAoRUZBVUxUKTsKCQkJaWYg KChlcnJvciA9IGNvcHlpbnN0cihlbnZwLCBpbWdwLT5zdHJpbmdwLAoJCQkgICAgaW1ncC0+c3Ry aW5nc3BhY2UsICZsZW5ndGgpKSkgewoJCQkJaWYgKGVycm9yID09IEVOQU1FVE9PTE9ORykKCQkJ CQlyZXR1cm4oRTJCSUcpOwoJCQkJcmV0dXJuIChlcnJvcik7CgkJCX0KCQkJaW1ncC0+c3RyaW5n c3BhY2UgLT0gbGVuZ3RoOwoJCQlpbWdwLT5zdHJpbmdwICs9IGxlbmd0aDsKCQkJaW1ncC0+ZW52 YysrOwoJCX0KCX0KCglyZXR1cm4gKDApOwp9CgovKgogKiBDb3B5IHN0cmluZ3Mgb3V0IHRvIHRo ZSBuZXcgcHJvY2VzcyBhZGRyZXNzIHNwYWNlLCBjb25zdHJ1Y3RpbmcKICoJbmV3IGFyZyBhbmQg ZW52IHZlY3RvciB0YWJsZXMuIFJldHVybiBhIHBvaW50ZXIgdG8gdGhlIGJhc2UKICoJc28gdGhh dCBpdCBjYW4gYmUgdXNlZCBhcyB0aGUgaW5pdGlhbCBzdGFjayBwb2ludGVyLgogKi8KaW50ICoK ZXhlY19jb3B5b3V0X3N0cmluZ3MoaW1ncCkKCXN0cnVjdCBpbWFnZV9wYXJhbXMgKmltZ3A7CnsK CWludCBhcmdjLCBlbnZjOwoJY2hhciAqKnZlY3RwOwoJY2hhciAqc3RyaW5ncCwgKmRlc3RwOwoJ aW50ICpzdGFja19iYXNlOwoJc3RydWN0IHBzX3N0cmluZ3MgKmFyZ2luZm87CglpbnQgc3pzaWdj b2RlOwoKCS8qCgkgKiBDYWxjdWxhdGUgc3RyaW5nIGJhc2UgYW5kIHZlY3RvciB0YWJsZSBwb2lu dGVycy4KCSAqIEFsc28gZGVhbCB3aXRoIHNpZ25hbCB0cmFtcG9saW5lIGNvZGUgZm9yIHRoaXMg ZXhlYyB0eXBlLgoJICovCglhcmdpbmZvID0gUFNfU1RSSU5HUzsKCXN6c2lnY29kZSA9ICooaW1n cC0+cHJvYy0+cF9zeXNlbnQtPnN2X3N6c2lnY29kZSk7CglkZXN0cCA9CShjYWRkcl90KWFyZ2lu Zm8gLSBzenNpZ2NvZGUgLSBTUEFSRV9VU1JTUEFDRSAtCgkJcm91bmR1cCgoQVJHX01BWCAtIGlt Z3AtPnN0cmluZ3NwYWNlKSwgc2l6ZW9mKGNoYXIgKikpOwoKCS8qCgkgKiBpbnN0YWxsIHNpZ2Nv ZGUKCSAqLwoJaWYgKHN6c2lnY29kZSkKCQljb3B5b3V0KGltZ3AtPnByb2MtPnBfc3lzZW50LT5z dl9zaWdjb2RlLAoJCQkoKGNhZGRyX3QpYXJnaW5mbyAtIHN6c2lnY29kZSksIHN6c2lnY29kZSk7 CgoJLyoKCSAqIElmIHdlIGhhdmUgYSB2YWxpZCBhdXhhcmdzIHB0ciwgcHJlcGFyZSBzb21lIHJv b20KCSAqIG9uIHRoZSBzdGFjay4KCSAqLwoJaWYgKGltZ3AtPmF1eGFyZ3MpCgkvKgoJICogVGhl ICcrIDInIGlzIGZvciB0aGUgbnVsbCBwb2ludGVycyBhdCB0aGUgZW5kIG9mIGVhY2ggb2YgdGhl CgkgKiBhcmcgYW5kIGVudiB2ZWN0b3Igc2V0cywgYW5kICdBVF9DT1VOVCoyJyBpcyByb29tIGZv ciB0aGUKCSAqIEVMRiBBdXhhcmdzIGRhdGEuCgkgKi8KCQl2ZWN0cCA9IChjaGFyICoqKShkZXN0 cCAtIChpbWdwLT5hcmdjICsgaW1ncC0+ZW52YyArIDIgKwoJCQkJICBBVF9DT1VOVCoyKSAqIHNp emVvZihjaGFyKikpOwoJZWxzZSAKCS8qCgkgKiBUaGUgJysgMicgaXMgZm9yIHRoZSBudWxsIHBv aW50ZXJzIGF0IHRoZSBlbmQgb2YgZWFjaCBvZiB0aGUKCSAqIGFyZyBhbmQgZW52IHZlY3RvciBz ZXRzCgkgKi8KCQl2ZWN0cCA9IChjaGFyICoqKQoJCQkoZGVzdHAgLSAoaW1ncC0+YXJnYyArIGlt Z3AtPmVudmMgKyAyKSAqIHNpemVvZihjaGFyKikpOwoKCS8qCgkgKiB2ZWN0cCBhbHNvIGJlY29t ZXMgb3VyIGluaXRpYWwgc3RhY2sgYmFzZQoJICovCglzdGFja19iYXNlID0gKGludCAqKXZlY3Rw OwoKCXN0cmluZ3AgPSBpbWdwLT5zdHJpbmdiYXNlOwoJYXJnYyA9IGltZ3AtPmFyZ2M7CgllbnZj ID0gaW1ncC0+ZW52YzsKCgkvKgoJICogQ29weSBvdXQgc3RyaW5ncyAtIGFyZ3VtZW50cyBhbmQg ZW52aXJvbm1lbnQuCgkgKi8KCWNvcHlvdXQoc3RyaW5ncCwgZGVzdHAsIEFSR19NQVggLSBpbWdw LT5zdHJpbmdzcGFjZSk7CgoJLyoKCSAqIEZpbGwgaW4gInBzX3N0cmluZ3MiIHN0cnVjdCBmb3Ig cHMsIHcsIGV0Yy4KCSAqLwoJc3V3b3JkKCZhcmdpbmZvLT5wc19hcmd2c3RyLCAoaW50KXZlY3Rw KTsKCXN1d29yZCgmYXJnaW5mby0+cHNfbmFyZ3ZzdHIsIGFyZ2MpOwoKCS8qCgkgKiBGaWxsIGlu IGFyZ3VtZW50IHBvcnRpb24gb2YgdmVjdG9yIHRhYmxlLgoJICovCglmb3IgKDsgYXJnYyA+IDA7 IC0tYXJnYykgewoJCXN1d29yZCh2ZWN0cCsrLCAoaW50KWRlc3RwKTsKCQl3aGlsZSAoKnN0cmlu Z3ArKyAhPSAwKQoJCQlkZXN0cCsrOwoJCWRlc3RwKys7Cgl9CgoJLyogYSBudWxsIHZlY3RvciB0 YWJsZSBwb2ludGVyIHNlcGVyYXRlcyB0aGUgYXJncCdzIGZyb20gdGhlIGVudnAncyAqLwoJc3V3 b3JkKHZlY3RwKyssIDApOwoKCXN1d29yZCgmYXJnaW5mby0+cHNfZW52c3RyLCAoaW50KXZlY3Rw KTsKCXN1d29yZCgmYXJnaW5mby0+cHNfbmVudnN0ciwgZW52Yyk7CgoJLyoKCSAqIEZpbGwgaW4g ZW52aXJvbm1lbnQgcG9ydGlvbiBvZiB2ZWN0b3IgdGFibGUuCgkgKi8KCWZvciAoOyBlbnZjID4g MDsgLS1lbnZjKSB7CgkJc3V3b3JkKHZlY3RwKyssIChpbnQpZGVzdHApOwoJCXdoaWxlICgqc3Ry aW5ncCsrICE9IDApCgkJCWRlc3RwKys7CgkJZGVzdHArKzsKCX0KCgkvKiBlbmQgb2YgdmVjdG9y IHRhYmxlIGlzIGEgbnVsbCBwb2ludGVyICovCglzdXdvcmQodmVjdHAsIDApOwoKCXJldHVybiAo c3RhY2tfYmFzZSk7Cn0KCi8qCiAqIENoZWNrIHBlcm1pc3Npb25zIG9mIGZpbGUgdG8gZXhlY3V0 ZS4KICoJUmV0dXJuIDAgZm9yIHN1Y2Nlc3Mgb3IgZXJyb3IgY29kZSBvbiBmYWlsdXJlLgogKi8K c3RhdGljIGludApleGVjX2NoZWNrX3Blcm1pc3Npb25zKGltZ3ApCglzdHJ1Y3QgaW1hZ2VfcGFy YW1zICppbWdwOwp7CglzdHJ1Y3QgcHJvYyAqcCA9IGltZ3AtPnByb2M7CglzdHJ1Y3Qgdm5vZGUg KnZwID0gaW1ncC0+dnA7CglzdHJ1Y3QgdmF0dHIgKmF0dHIgPSBpbWdwLT5hdHRyOwoJaW50IGVy cm9yOwoKCS8qIEdldCBmaWxlIGF0dHJpYnV0ZXMgKi8KCWVycm9yID0gVk9QX0dFVEFUVFIodnAs IGF0dHIsIHAtPnBfdWNyZWQsIHApOwoJaWYgKGVycm9yKQoJCXJldHVybiAoZXJyb3IpOwoKCS8q CgkgKiAxKSBDaGVjayBpZiBmaWxlIGV4ZWN1dGlvbiBpcyBkaXNhYmxlZCBmb3IgdGhlIGZpbGVz eXN0ZW0gdGhhdCB0aGlzCgkgKglmaWxlIHJlc2lkZXMgb24uCgkgKiAyKSBJbnN1cmUgdGhhdCBh dCBsZWFzdCBvbmUgZXhlY3V0ZSBiaXQgaXMgb24gLSBvdGhlcndpc2Ugcm9vdAoJICoJd2lsbCBh bHdheXMgc3VjY2VlZCwgYW5kIHdlIGRvbid0IHdhbnQgdG8gaGFwcGVuIHVubGVzcyB0aGUKCSAq CWZpbGUgcmVhbGx5IGlzIGV4ZWN1dGFibGUuCgkgKiAzKSBJbnN1cmUgdGhhdCB0aGUgZmlsZSBp cyBhIHJlZ3VsYXIgZmlsZS4KCSAqLwoJaWYgKCh2cC0+dl9tb3VudC0+bW50X2ZsYWcgJiBNTlRf Tk9FWEVDKSB8fAoJICAgICgoYXR0ci0+dmFfbW9kZSAmIDAxMTEpID09IDApIHx8CgkgICAgKGF0 dHItPnZhX3R5cGUgIT0gVlJFRykpIHsKCQlyZXR1cm4gKEVBQ0NFUyk7Cgl9CgoJLyoKCSAqIFpl cm8gbGVuZ3RoIGZpbGVzIGNhbid0IGJlIGV4ZWMnZAoJICovCglpZiAoYXR0ci0+dmFfc2l6ZSA9 PSAwKQoJCXJldHVybiAoRU5PRVhFQyk7CgoJLyoKCSAqICBDaGVjayBmb3IgZXhlY3V0ZSBwZXJt aXNzaW9uIHRvIGZpbGUgYmFzZWQgb24gY3VycmVudCBjcmVkZW50aWFscy4KCSAqLwoJZXJyb3Ig PSBWT1BfQUNDRVNTKHZwLCBWRVhFQywgcC0+cF91Y3JlZCwgcCk7CglpZiAoZXJyb3IpCgkJcmV0 dXJuIChlcnJvcik7CgoJLyoKCSAqIENoZWNrIG51bWJlciBvZiBvcGVuLWZvci13cml0ZXMgb24g dGhlIGZpbGUgYW5kIGRlbnkgZXhlY3V0aW9uCgkgKiBpZiB0aGVyZSBhcmUgYW55LgoJICovCglp ZiAodnAtPnZfd3JpdGVjb3VudCkKCQlyZXR1cm4gKEVUWFRCU1kpOwoKCS8qCgkgKiBDYWxsIGZp bGVzeXN0ZW0gc3BlY2lmaWMgb3BlbiByb3V0aW5lICh3aGljaCBkb2VzIG5vdGhpbmcgaW4gdGhl CgkgKiBnZW5lcmFsIGNhc2UpLgoJICovCgllcnJvciA9IFZPUF9PUEVOKHZwLCBGUkVBRCwgcC0+ cF91Y3JlZCwgcCk7CglpZiAoZXJyb3IpCgkJcmV0dXJuIChlcnJvcik7CgoJLyoKCSAqIERpc2Fi bGUgc2V0dWlkL3NldGdpZCBpZiB0aGUgZmlsZXN5c3RlbSBwcm9oaWJpdHMgaXQgb3IgaWYKCSAq IHRoZSBwcm9jZXNzIGlzIGJlaW5nIHRyYWNlZC4KCSAqLwogICAgICAgIGlmICgodnAtPnZfbW91 bnQtPm1udF9mbGFnICYgTU5UX05PU1VJRCkgfHwgKHAtPnBfZmxhZyAmIFBfVFJBQ0VEKSkKCQlh dHRyLT52YV9tb2RlICY9IH4oVlNVSUQgfCBWU0dJRCk7CgoJcmV0dXJuICgwKTsKfQo= --_=XFMail.1.2.p0.FreeBSD:980428125808:18166=_ Content-Disposition: attachment; filename="imgact_aout.c" Content-Transfer-Encoding: 7bit Content-Description: imgact_aout.c Content-Type: text/plain; charset=us-ascii; name=imgact_aout.c; SizeOnDisk=6477 /* * Copyright (c) 1993, David Greenman * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id: imgact_aout.c,v 1.2 1998/04/27 09:39:10 msuarez Exp $ */ #include "opt_rlimit.h" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static int exec_aout_imgact __P((struct image_params *imgp)); static int exec_aout_imgact(imgp) struct image_params *imgp; { const struct exec *a_out = (const struct exec *) imgp->image_header; struct vmspace *vmspace = imgp->proc->p_vmspace; vm_offset_t vmaddr; unsigned long virtual_offset; unsigned long file_offset; unsigned long bss_size; int error; /* * Linux and *BSD binaries look very much alike, * only the machine id is different: * 0x64 for Linux, 0x86 for *BSD, 0x00 for BSDI. * NetBSD is in network byte order.. ugh. */ if (((a_out->a_magic >> 16) & 0xff) != 0x86 && ((a_out->a_magic >> 16) & 0xff) != 0 && ((((int)ntohl(a_out->a_magic)) >> 16) & 0xff) != 0x86) return -1; imgp->proc->p_pad1[0]=0; if(a_out->a_text & 0x80000000) { /* This means we need a checksum */ imgp->proc->p_pad1[0]=1; } /* * Set file/virtual offset based on a.out variant. * We do two cases: host byte order and network byte order * (for NetBSD compatibility) */ switch ((int)(a_out->a_magic & 0xffff)) { case ZMAGIC: virtual_offset = 0; if (a_out->a_text&0x7fffffff) { file_offset = PAGE_SIZE; } else { /* Bill's "screwball mode" */ file_offset = 0; } break; case QMAGIC: virtual_offset = PAGE_SIZE; file_offset = 0; break; default: /* NetBSD compatibility */ switch ((int)(ntohl(a_out->a_magic) & 0xffff)) { case ZMAGIC: case QMAGIC: virtual_offset = PAGE_SIZE; file_offset = 0; break; default: return (-1); } } bss_size = roundup(a_out->a_bss, PAGE_SIZE); /* * Check various fields in header for validity/bounds. */ if (/* entry point must lay with text region */ a_out->a_entry < virtual_offset || a_out->a_entry >= virtual_offset + (a_out->a_text&0x7fffffff) || /* text and data size must each be page rounded */ (a_out->a_text&0x7fffffff) & PAGE_MASK || a_out->a_data & PAGE_MASK) return (-1); /* text + data can't exceed file size */ if (a_out->a_data + (a_out->a_text&0x7fffffff) > imgp->attr->va_size) return (EFAULT); /* * text/data/bss must not exceed limits */ if (/* text can't exceed maximum text size */ (a_out->a_text&0x7fffffff) > MAXTSIZ || /* data + bss can't exceed maximum data size */ a_out->a_data + bss_size > MAXDSIZ || /* data + bss can't exceed rlimit */ a_out->a_data + bss_size > imgp->proc->p_rlimit[RLIMIT_DATA].rlim_cur) return (ENOMEM); /* copy in arguments and/or environment from old process */ error = exec_extract_strings(imgp); if (error) return (error); /* * Destroy old process VM and create a new one (with a new stack) */ exec_new_vmspace(imgp); /* * Map text/data read/execute */ vmaddr = virtual_offset; error = vm_mmap(&vmspace->vm_map, /* map */ &vmaddr, /* address */ (a_out->a_text&0x7fffffff) + a_out->a_data, /* size */ VM_PROT_READ | VM_PROT_EXECUTE, /* protection */ VM_PROT_ALL, /* max protection */ MAP_PRIVATE | MAP_FIXED, /* flags */ (caddr_t)imgp->vp, /* vnode */ file_offset); /* offset */ if (error) return (error); /* * allow writing of data */ vm_map_protect(&vmspace->vm_map, vmaddr + (a_out->a_text&0x7fffffff), vmaddr + (a_out->a_text&0x7fffffff) + a_out->a_data, VM_PROT_ALL, FALSE); if (bss_size != 0) { /* * Allocate demand-zeroed area for uninitialized data * "bss" = 'block started by symbol' - named after the IBM 7090 * instruction of the same name. */ vmaddr = virtual_offset + (a_out->a_text&0x7fffffff) + a_out->a_data; error = vm_map_find(&vmspace->vm_map, NULL, 0, &vmaddr, bss_size, FALSE, VM_PR OT_ALL, VM_PROT_ALL, 0); if (error) return (error); } /* Fill in process VM information */ vmspace->vm_tsize = (a_out->a_text&0x7fffffff) >> PAGE_SHIFT; vmspace->vm_dsize = (a_out->a_data + bss_size) >> PAGE_SHIFT; vmspace->vm_taddr = (caddr_t) virtual_offset; vmspace->vm_daddr = (caddr_t) virtual_offset + (a_out->a_text&0x7fffffff); /* Fill in image_params */ imgp->interpreted = 0; imgp->entry_addr = a_out->a_entry; imgp->proc->p_sysent = &aout_sysvec; /* Indicate that this file should not be modified */ imgp->vp->v_flag |= VTEXT; return (0); } /* * Tell kern_execve.c about it, with a little help from the linker. * Since `const' objects end up in the text segment, TEXT_SET is the * correct directive to use. */ static const struct execsw aout_execsw = { exec_aout_imgact, "a.out" }; TEXT_SET(execsw_set, aout_execsw); --_=XFMail.1.2.p0.FreeBSD:980428125808:18166=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 10:10:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA08762 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 10:10:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA08741; Tue, 28 Apr 1998 10:10:17 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id TAA26869; Tue, 28 Apr 1998 19:10:02 +0200 (MET DST) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Tue, 28 Apr 1998 19:10:01 +0200 (MET DST) Mime-Version: 1.0 To: dyson@FreeBSD.ORG Cc: dec@phoenix.its.rpi.edu (David E. Cross), freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <199804272230.RAA01545@dyson.iquest.net> Organization: Gutteklubben Terrasse / KRST / PUMS / YASMW X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-Stop-Spam: http://www.cauce.org From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 28 Apr 1998 19:10:01 +0200 In-Reply-To: "John S. Dyson"'s message of "Mon, 27 Apr 1998 17:30:38 -0500 (EST)" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "John S. Dyson" writes: > David E. Cross said: > > I was recenlty shown AIX's SIGDANGER (33). It is a signal that the kernel > We do need to adopt an extended signal set, and I think that someone > else has already developed it. SIGDANGER could be valuable. I also think SIGCONF which was discussed on one of the lists some time ago (last week?) would be nice (as a replacement for the old tradition of reading a SIGHUP as "your configurations files have changed, please reread them now") -- Noone else has a .sig like this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 10:49:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA16077 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 10:49:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16055 for ; Tue, 28 Apr 1998 10:49:42 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id KAA12761; Tue, 28 Apr 1998 10:49:10 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma012757; Tue Apr 28 10:48:45 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id KAA06998; Tue, 28 Apr 1998 10:48:45 -0700 (PDT) From: Archie Cobbs Message-Id: <199804281748.KAA06998@bubba.whistle.com> Subject: Re: Whom to contact? In-Reply-To: from Snob Art Genre at "Apr 28, 98 11:45:57 am" To: benedict@echonyc.com (Snob Art Genre) Date: Tue, 28 Apr 1998 10:48:45 -0700 (PDT) Cc: hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Snob Art Genre writes: > > Snob Art Genre writes: > > > For ports this is trivial, as I can pull MAINTAINER from the Makefile, > > > but how do I determine this for various parts of the base system? > > > > cvs log? > > Thanks, but could you give a more detailed answer? I am not wise in the > ways of CVS. Ah, sorry.. well, you can read all about it in the handbook I think (I've never set up a CVS repository myself). But assuming you have access to one, "cvs log xxx" will display all checkins to file xxx and who did them, when, what the checkin comment was, etc. So this is a way to trace the history of a file in terms of maintenance. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 11:04:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA19498 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 11:04:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA19476; Tue, 28 Apr 1998 11:04:33 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id NAA02636; Tue, 28 Apr 1998 13:04:33 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id NAA07177; Tue, 28 Apr 1998 13:04:32 -0500 (CDT) Message-ID: <19980428130432.34057@mcs.net> Date: Tue, 28 Apr 1998 13:04:32 -0500 From: Karl Denninger To: "David E. Cross" Cc: dyson@FreeBSD.ORG, Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <19980428073841.05698@mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from David E. Cross on Tue, Apr 28, 1998 at 12:17:40PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Good point, except that if you ignore it, you're saying that its acceptable to kill you if the kernel MUST do so. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Tue, Apr 28, 1998 at 12:17:40PM -0400, David E. Cross wrote: > On Tue, 28 Apr 1998, Karl Denninger wrote: > > > Well, now wait a minute.. > > > > SIGDANGER is useful if properly trapped and handled. I'd like to see if > > supported with the default to be "ignore" (ie: you have to ASK for it to > > be delivered and processed). > May I ask what good is it if it is ignored by default???? > > Default should be as it is on AIX, to terminate the process. In general > you care more about system processes than user procs, so I would "make > world" on my system if this got added, with all the system procs having a > one line addition in main() to ignore the signal, and I would be ready to > go. > > > -- > David Cross > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 11:10:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20840 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 11:10:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20819 for ; Tue, 28 Apr 1998 11:10:17 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id OAA16785; Tue, 28 Apr 1998 14:10:10 -0400 (EDT) Date: Tue, 28 Apr 1998 14:10:09 -0400 (EDT) From: Snob Art Genre To: Archie Cobbs cc: hackers@FreeBSD.ORG Subject: Re: Whom to contact? In-Reply-To: <199804281748.KAA06998@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got a CVS repository on disc 3 of the distribution set, but: ben% pwd /cdrom/CVS-Repository/src/usr.sbin/inetd ben% cvs log * cvs log: cannot open CVS/Entries for reading: No such file or directory cvs log: nothing known about Makefile,v cvs log: nothing known about TRANS.TBL cvs log: nothing known about inetd.8,v cvs log: nothing known about inetd.c,v cvs log: nothing known about pathnames.h,v Handbook, you say? *sigh* On Tue, 28 Apr 1998, Archie Cobbs wrote: > Ah, sorry.. well, you can read all about it in the handbook I think > (I've never set up a CVS repository myself). But assuming you have > access to one, "cvs log xxx" will display all checkins to file xxx > and who did them, when, what the checkin comment was, etc. So this > is a way to trace the history of a file in terms of maintenance. > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 11:15:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22288 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 11:15:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22141 for ; Tue, 28 Apr 1998 11:14:47 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id NAA00553; Tue, 28 Apr 1998 13:13:44 -0500 (EST) (envelope-from toor) Message-Id: <199804281813.NAA00553@dyson.iquest.net> Subject: Re: SIGDANGER In-Reply-To: from "David E. Cross" at "Apr 28, 98 07:19:16 am" To: dec@phoenix.its.rpi.edu (David E. Cross) Date: Tue, 28 Apr 1998 13:13:44 -0500 (EST) Cc: jkh@time.cdrom.com, adrian@virginia.edu, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David E. Cross said: > > As per memory overcomitment, I do not see this as an issue, I can still > run out of memory even if I am not over commited (say netscape went > berkerk or whatever). I think thet in situation where the system is > starting to page (or heavily paging) SIGDANER [Will Robinson] would be a > usefull tool. > I used to work where we had customers using SVR4. Those customers had as many (or more) problems with processes being killed or dying unexpectedly, even without overcommit. The startup code for processes in SVR4 dies badly in code supplied by the vendor when swap space is low. It doesn't solve the problem of unintended processes dying unless processes are written correctly. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 11:43:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28828 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 11:43:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from idiom.com (idiom.com [140.174.82.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28813 for ; Tue, 28 Apr 1998 11:43:44 -0700 (PDT) (envelope-from muir@idiom.com) Received: (from muir@localhost) by idiom.com (8.8.7/8.8.5) id LAA12065; Tue, 28 Apr 1998 11:43:40 -0700 (PDT) Date: Tue, 28 Apr 1998 11:43:40 -0700 (PDT) Message-Id: <199804281843.LAA12065@idiom.com> To: "Matthew N. Dodd" Cc: David Muir Sharnoff , freebsd-hackers@FreeBSD.ORG Subject: Re: Routing problem that I need solved. From: support@idiom.com (David Muir Sharnoff) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Check out Vixie's ifdefault patches. That's neat! Doesn't solve my problem, but it's a nice hack. -Dave To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 12:02:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03052 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 12:02:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03035 for ; Tue, 28 Apr 1998 12:02:03 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id PAA23025; Tue, 28 Apr 1998 15:01:59 -0400 (EDT) Date: Tue, 28 Apr 1998 15:01:59 -0400 (EDT) From: "Matthew N. Dodd" To: David Muir Sharnoff cc: David Muir Sharnoff , freebsd-hackers@FreeBSD.ORG Subject: Re: Routing problem that I need solved. In-Reply-To: <199804281843.LAA12065@idiom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, David Muir Sharnoff wrote: > * Check out Vixie's ifdefault patches. > > That's neat! Doesn't solve my problem, but it's a nice hack. Sorry about that... I realized after reading others replies that my answer wasn't addressing your question. :/ /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 12:27:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08336 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 12:27:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xcf.berkeley.edu (scam.XCF.Berkeley.EDU [128.32.43.201]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA08174 for ; Tue, 28 Apr 1998 12:26:28 -0700 (PDT) (envelope-from nordwick@xcf.berkeley.edu) Received: (qmail 1225 invoked by uid 27268); 28 Apr 1998 19:27:42 -0000 Date: 28 Apr 1998 19:27:42 -0000 Message-ID: <19980428192742.1224.qmail@xcf.berkeley.edu> From: Jason Nordwick MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Karl Denninger Cc: dyson@FreeBSD.ORG, Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: karl@mcs.net on 4/28/1998 to dyson@FreeBSD.ORG, witr@rwwa.com, freebsd-hackers@FreeBSD.ORG <19980428073841.05698@mcs.net> References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> <19980428073841.05698@mcs.net> X-Mailer: VM 6.32 under Emacs 19.34.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Karl Denninger, on Tue 4/28/1998, wrote the following: > > SIGDANGER is useful if properly trapped and handled. I'd like to see if > supported with the default to be "ignore" (ie: you have to ASK for it to > be delivered and processed). > Then it would almost always be ignored? Wouldn't this reqire patching almost every noncritical program? It would probably be easier just to patch a few important tools and find a Good(c) way to pick the unlucky process. jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 12:29:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08812 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 12:29:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA08625 for ; Tue, 28 Apr 1998 12:28:46 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id PAA07231; Tue, 28 Apr 1998 15:27:11 -0400 (EDT) Date: Tue, 28 Apr 1998 15:27:11 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Snob Art Genre cc: Archie Cobbs , hackers@FreeBSD.ORG Subject: Re: Whom to contact? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If you go to the web repository (www.freebsd.org/cgi/cvsweb.cgi) you'll be able to see who the last person that committed a change to a particular file is... Charles Charles Sprickman spork@super-g.com ---- "I'm not a prophet or a stone-age man Just a mortal with potential of a superman I'm living on" -DB On Tue, 28 Apr 1998, Snob Art Genre wrote: > On Mon, 27 Apr 1998, Archie Cobbs wrote: > > > Snob Art Genre writes: > > > For ports this is trivial, as I can pull MAINTAINER from the Makefile, > > > but how do I determine this for various parts of the base system? > > > > cvs log? > > Thanks, but could you give a more detailed answer? I am not wise in the > ways of CVS. > > > Ben > > "You have your mind on computers, it seems." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 12:31:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09453 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 12:31:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09422; Tue, 28 Apr 1998 12:31:15 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id OAA08800; Tue, 28 Apr 1998 14:31:15 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id OAA13137; Tue, 28 Apr 1998 14:31:14 -0500 (CDT) Message-ID: <19980428143114.33662@mcs.net> Date: Tue, 28 Apr 1998 14:31:14 -0500 From: Karl Denninger To: Jason Nordwick Cc: dyson@FreeBSD.ORG, Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> <19980428073841.05698@mcs.net> <19980428192742.1224.qmail@xcf.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19980428192742.1224.qmail@xcf.berkeley.edu>; from Jason Nordwick on Tue, Apr 28, 1998 at 07:27:42PM -0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 28, 1998 at 07:27:42PM -0000, Jason Nordwick wrote: > > Karl Denninger, on Tue 4/28/1998, wrote the following: > > > > SIGDANGER is useful if properly trapped and handled. I'd like to see if > > supported with the default to be "ignore" (ie: you have to ASK for it to > > be delivered and processed). > > > > Then it would almost always be ignored? Wouldn't this reqire patching > almost every noncritical program? It would probably be easier just to > patch a few important tools and find a Good(c) way to pick the > unlucky process. > > jay No, you patch the critical ones to do something useful with the trap. The ignored ones are known to the kernel, and they are subject to getting whacked without notice (just like we have now). Critical programs can either free up resources or exit, as they see fit. We could also define a semantic that says that if a process set SIGHOLD for that signal, then the kernel should do everything in its power NOT to whack that particular process. This leaves you with: 1) Do nothing - you get the semantics we have now. If the kernel needs to whack you it will, without notice, but the warning is ignored (you don't want to do anything with it). 2) Trap the signal - you get notice, and can clean up and exit if you are able. You're still vulnerable, in that the kernel can whack you if it needs to (and you're still around). The kernel can put these processes into the "second round" bucket - it at least knows that you're trying to help. 3) Set SIG_HOLD. You're a critical process and the kernel should go pick on someone else if it can. If it can't, well, tough bananas, but at least we tried to keep you going. This preserves the EXISTING way things work if the programmer does nothing at all. The problem with AIX is that the default, that is, "do nothing", results in you getting killed when you might not really be killed (ie: the kernel is low on space but not completely out of resources). This also leads to three "buckets" - the "default" ones, which get nailed first, the "I'm trying to be nice" ones, which get nailed next, and the "oh shit the system is fucked if these die" ones, which are the kills of last resort. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 12:36:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10624 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 12:36:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10483 for ; Tue, 28 Apr 1998 12:35:24 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id PAA25422; Tue, 28 Apr 1998 15:35:15 -0400 (EDT) Date: Tue, 28 Apr 1998 15:35:13 -0400 (EDT) From: Snob Art Genre To: spork cc: hackers@FreeBSD.ORG Subject: Re: Whom to contact? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is what I was looking for! Thank you. On Tue, 28 Apr 1998, spork wrote: > If you go to the web repository (www.freebsd.org/cgi/cvsweb.cgi) you'll be > able to see who the last person that committed a change to a particular > file is... > > Charles > > > Charles Sprickman > spork@super-g.com > ---- > "I'm not a prophet or a stone-age man > Just a mortal with potential of a superman > I'm living on" -DB > Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 12:36:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10686 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 12:36:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hacker.cybernet.com (hacker.cybernet.com [192.245.33.142]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10450 for ; Tue, 28 Apr 1998 12:35:12 -0700 (PDT) (envelope-from msuarez@cybernet.com) Received: from hacker.cybernet.com (localhost [127.0.0.1]) by hacker.cybernet.com (8.8.8/8.8.8) with ESMTP id PAA18588 for ; Tue, 28 Apr 1998 15:35:13 -0400 (EDT) (envelope-from msuarez@cybernet.com) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.2.p0.FreeBSD:980428153512:18582=_" Date: Tue, 28 Apr 1998 15:35:13 -0400 (EDT) Reply-To: msuarez@cybernet.com Organization: Cybernet Systems Corp. (734) 668-2567 From: "Michael A. Suarez" To: FreeBSD Hackers Subject: RE: Kernel Programming Question Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.2.p0.FreeBSD:980428153512:18582=_ Content-Type: text/plain; charset=us-ascii Sorry about the uuencoded version of kern_exec.c. Attached is included the non-uuencoded version. Michael --_=XFMail.1.2.p0.FreeBSD:980428153512:18582=_ Content-Disposition: attachment; filename="kern_exec.c" Content-Transfer-Encoding: 7bit Content-Description: kern_exec.c Content-Type: text/plain; charset=us-ascii; name=kern_exec.c; SizeOnDisk=16865 /* * Copyright (c) 1993, David Greenman * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id: kern_exec.c,v 1.4 1998/04/27 14:25:45 msuarez Exp msuarez $ */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static int *exec_copyout_strings __P((struct image_params *)); static int exec_check_permissions(struct image_params *); /* * XXX trouble here if sizeof(caddr_t) != sizeof(int), other parts * of the sysctl code also assumes this, and sizeof(int) == sizeof(long). */ static struct ps_strings *ps_strings = PS_STRINGS; SYSCTL_INT(_kern, KERN_PS_STRINGS, ps_strings, 0, &ps_strings, 0, ""); static caddr_t usrstack = (caddr_t)USRSTACK; SYSCTL_INT(_kern, KERN_USRSTACK, usrstack, 0, &usrstack, 0, ""); /* * execsw_set is constructed for us by the linker. Each of the items * is a pointer to a `const struct execsw', hence the double pointer here. */ static const struct execsw **execsw = (const struct execsw **)&execsw_set.ls_items[0]; #ifndef _SYS_SYSPROTO_H_ struct execve_args { char *fname; char **argv; char **envv; }; #endif /* * execve() system call. */ int execve(p, uap, retval) struct proc *p; register struct execve_args *uap; int *retval; { struct nameidata nd, *ndp; int *stack_base; int error, len, i; struct image_params image_params, *imgp; struct vattr attr; struct buf *bp = NULL; imgp = &image_params; /* * Initialize part of the common data */ imgp->proc = p; imgp->uap = uap; imgp->attr = &attr; imgp->image_header = NULL; imgp->argc = imgp->envc = 0; imgp->entry_addr = 0; imgp->vmspace_destroyed = 0; imgp->interpreted = 0; imgp->interpreter_name[0] = '\0'; imgp->auxargs = NULL; /* * Allocate temporary demand zeroed space for argument and * environment strings */ imgp->stringbase = (char *)kmem_alloc_wait(exec_map, ARG_MAX); if (imgp->stringbase == NULL) { error = ENOMEM; goto exec_fail; } imgp->stringp = imgp->stringbase; imgp->stringspace = ARG_MAX; /* * Translate the file name. namei() returns a vnode pointer * in ni_vp amoung other things. */ ndp = &nd; NDINIT(ndp, LOOKUP, LOCKLEAF | FOLLOW | SAVENAME, UIO_USERSPACE, uap->fname, p); interpret: error = namei(ndp); if (error) { kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase, ARG_MAX); goto exec_fail; } imgp->vp = ndp->ni_vp; /* * Check file permissions (also 'opens' file) */ error = exec_check_permissions(imgp); if (error) { VOP_UNLOCK(imgp->vp); goto exec_fail_dealloc; } /* * Get the image header, which we define here as meaning the first * page of the executable. */ if (imgp->vp->v_object && imgp->vp->v_mount && imgp->vp->v_mount->mnt_stat.f_iosize >= PAGE_SIZE && imgp->vp->v_object->un_pager.vnp.vnp_size >= imgp->vp->v_mount->mnt_stat.f_iosize) { /* * Get a buffer with (at least) the first page. */ error = bread(imgp->vp, 0, imgp->vp->v_mount->mnt_stat.f_iosize, p->p_ucred, &bp); imgp->image_header = bp->b_data; } else { int resid; /* * The filesystem block size is too small, so do this the hard * way. Malloc some space and read PAGE_SIZE worth of the image * header into it. */ imgp->image_header = malloc(PAGE_SIZE, M_TEMP, M_WAITOK); error = vn_rdwr(UIO_READ, imgp->vp, (void *)imgp->image_header, PAGE_SIZE, 0, UIO_SYSSPACE, IO_NODELOCKED, p->p_ucred, &resid, p); /* * Clear out any remaining junk. */ if (!error && resid) bzero((char *)imgp->image_header + PAGE_SIZE - resid, resid); } /* * Loop through list of image activators, calling each one. * If there is no match, the activator returns -1. If there * is a match, but there was an error during the activation, * the error is returned. Otherwise 0 means success. If the * image is interpreted, loop back up and try activating * the interpreter. */ for (i = 0; execsw[i]; ++i) { if (execsw[i]->ex_imgact) error = (*execsw[i]->ex_imgact)(imgp); else continue; if (error == -1) continue; if (error) { VOP_UNLOCK(imgp->vp); goto exec_fail_dealloc; } if (imgp->interpreted) { /* free old bp/image_header */ if (bp != NULL) { brelse(bp); bp = NULL; } else { free((void *)imgp->image_header, M_TEMP); imgp->image_header = NULL; } /* free old vnode and name buffer */ VOP_UNLOCK(imgp->vp); if (error) goto exec_fail_dealloc; vrele(ndp->ni_vp); FREE(ndp->ni_cnd.cn_pnbuf, M_NAMEI); /* set new name to that of the interpreter */ NDINIT(ndp, LOOKUP, LOCKLEAF | FOLLOW | SAVENAME, UIO_SYSSPACE, imgp->interpreter_name, p); goto interpret; } break; } /* If we made it through all the activators and none matched, exit. */ if (error == -1) { VOP_UNLOCK(imgp->vp); error = ENOEXEC; goto exec_fail_dealloc; } if(imgp->proc->p_pad1[0]) { u_int32_t resid=0, error=0, sum=0, offset=0; unsigned char *buf; buf=(unsigned char *) malloc(PAGE_SIZE, M_TEMP, M_WAITOK); if(buf) while(!error && !resid) { error=vn_rdwr(UIO_READ,imgp->vp,(void *) buf,PAGE_SIZE,offset, UIO_SYSSPACE,IO_NODELOCKED,p->p_ucred,&resid,p); if(!error) { int t=0; if(resid) bzero((char *)buf+PAGE_SIZE-resid,resid); for(t=0; tproc->p_pad1[0]=0; } VOP_UNLOCK(imgp->vp); if (error) goto exec_fail_dealloc; /* * Copy out strings (args and env) and initialize stack base */ stack_base = exec_copyout_strings(imgp); p->p_vmspace->vm_minsaddr = (char *)stack_base; /* * If custom stack fixup routine present for this process * let it do the stack setup. * Else stuff argument count as first item on stack */ if (p->p_sysent->sv_fixup) (*p->p_sysent->sv_fixup)(&stack_base, imgp); else suword(--stack_base, imgp->argc); /* close files on exec */ fdcloseexec(p); /* reset caught signals */ execsigs(p); /* name this process - nameiexec(p, ndp) */ len = min(ndp->ni_cnd.cn_namelen,MAXCOMLEN); bcopy(ndp->ni_cnd.cn_nameptr, p->p_comm, len); p->p_comm[len] = 0; /* * mark as execed, wakeup the process that vforked (if any) and tell * it that it now has it's own resources back */ p->p_flag |= P_EXEC; if (p->p_pptr && (p->p_flag & P_PPWAIT)) { p->p_flag &= ~P_PPWAIT; wakeup((caddr_t)p->p_pptr); } /* * Implement image setuid/setgid. Disallow if the process is * being traced. */ if ((attr.va_mode & (VSUID | VSGID)) && (p->p_flag & P_TRACED) == 0) { /* * Turn off syscall tracing for set-id programs, except for * root. */ if (p->p_tracep && suser(p->p_ucred, &p->p_acflag)) { p->p_traceflag = 0; vrele(p->p_tracep); p->p_tracep = NULL; } /* * Set the new credentials. */ p->p_ucred = crcopy(p->p_ucred); if (attr.va_mode & VSUID) p->p_ucred->cr_uid = attr.va_uid; if (attr.va_mode & VSGID) p->p_ucred->cr_groups[0] = attr.va_gid; p->p_flag |= P_SUGID; } else { if (p->p_ucred->cr_uid == p->p_cred->p_ruid && p->p_ucred->cr_gid == p->p_cred->p_rgid) p->p_flag &= ~P_SUGID; } /* * Implement correct POSIX saved-id behavior. */ p->p_cred->p_svuid = p->p_ucred->cr_uid; p->p_cred->p_svgid = p->p_ucred->cr_gid; /* * Store the vp for use in procfs */ if (p->p_textvp) /* release old reference */ vrele(p->p_textvp); VREF(ndp->ni_vp); p->p_textvp = ndp->ni_vp; /* * If tracing the process, trap to debugger so breakpoints * can be set before the program executes. */ if (p->p_flag & P_TRACED) psignal(p, SIGTRAP); /* clear "fork but no exec" flag, as we _are_ execing */ p->p_acflag &= ~AFORK; /* Set entry address */ setregs(p, imgp->entry_addr, (u_long)stack_base); /* * free various allocated resources */ kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase, ARG_MAX); if (bp != NULL) brelse(bp); else if (imgp->image_header != NULL) free((void *)imgp->image_header, M_TEMP); vrele(ndp->ni_vp); FREE(ndp->ni_cnd.cn_pnbuf, M_NAMEI); return (0); exec_fail_dealloc: if (imgp->stringbase != NULL) kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase, ARG_MAX); if (bp != NULL) brelse(bp); else if (imgp->image_header != NULL) free((void *)imgp->image_header, M_TEMP); if (ndp->ni_vp) { vrele(ndp->ni_vp); FREE(ndp->ni_cnd.cn_pnbuf, M_NAMEI); } exec_fail: if (imgp->vmspace_destroyed) { /* sorry, no more process anymore. exit gracefully */ exit1(p, W_EXITCODE(0, SIGABRT)); /* NOT REACHED */ return(0); } else { return(error); } } /* * Destroy old address space, and allocate a new stack * The new stack is only SGROWSIZ large because it is grown * automatically in trap.c. */ int exec_new_vmspace(imgp) struct image_params *imgp; { int error; struct vmspace *vmspace = imgp->proc->p_vmspace; caddr_t stack_addr = (caddr_t) (USRSTACK - SGROWSIZ); imgp->vmspace_destroyed = 1; /* Blow away entire process VM */ if (vmspace->vm_shm) shmexit(imgp->proc); pmap_remove_pages(&vmspace->vm_pmap, 0, USRSTACK); vm_map_remove(&vmspace->vm_map, 0, USRSTACK); /* Allocate a new stack */ error = vm_map_find(&vmspace->vm_map, NULL, 0, (vm_offset_t *)&stack_addr, SGROWSIZ, FALSE, VM_PROT_ALL, VM_PROT_ALL, 0); if (error) return(error); vmspace->vm_ssize = SGROWSIZ >> PAGE_SHIFT; /* Initialize maximum stack address */ vmspace->vm_maxsaddr = (char *)USRSTACK - MAXSSIZ; return(0); } /* * Copy out argument and environment strings from the old process * address space into the temporary string buffer. */ int exec_extract_strings(imgp) struct image_params *imgp; { char **argv, **envv; char *argp, *envp; int error, length; /* * extract arguments first */ argv = imgp->uap->argv; if (argv) { while ((argp = (caddr_t) fuword(argv++))) { if (argp == (caddr_t) -1) return (EFAULT); if ((error = copyinstr(argp, imgp->stringp, imgp->stringspace, &length))) { if (error == ENAMETOOLONG) return(E2BIG); return (error); } imgp->stringspace -= length; imgp->stringp += length; imgp->argc++; } } /* * extract environment strings */ envv = imgp->uap->envv; if (envv) { while ((envp = (caddr_t) fuword(envv++))) { if (envp == (caddr_t) -1) return (EFAULT); if ((error = copyinstr(envp, imgp->stringp, imgp->stringspace, &length))) { if (error == ENAMETOOLONG) return(E2BIG); return (error); } imgp->stringspace -= length; imgp->stringp += length; imgp->envc++; } } return (0); } /* * Copy strings out to the new process address space, constructing * new arg and env vector tables. Return a pointer to the base * so that it can be used as the initial stack pointer. */ int * exec_copyout_strings(imgp) struct image_params *imgp; { int argc, envc; char **vectp; char *stringp, *destp; int *stack_base; struct ps_strings *arginfo; int szsigcode; /* * Calculate string base and vector table pointers. * Also deal with signal trampoline code for this exec type. */ arginfo = PS_STRINGS; szsigcode = *(imgp->proc->p_sysent->sv_szsigcode); destp = (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - roundup((ARG_MAX - imgp->stringspace), sizeof(char *)); /* * install sigcode */ if (szsigcode) copyout(imgp->proc->p_sysent->sv_sigcode, ((caddr_t)arginfo - szsigcode), szsigcode); /* * If we have a valid auxargs ptr, prepare some room * on the stack. */ if (imgp->auxargs) /* * The '+ 2' is for the null pointers at the end of each of the * arg and env vector sets, and 'AT_COUNT*2' is room for the * ELF Auxargs data. */ vectp = (char **)(destp - (imgp->argc + imgp->envc + 2 + AT_COUNT*2) * sizeof(char*)); else /* * The '+ 2' is for the null pointers at the end of each of the * arg and env vector sets */ vectp = (char **) (destp - (imgp->argc + imgp->envc + 2) * sizeof(char*)); /* * vectp also becomes our initial stack base */ stack_base = (int *)vectp; stringp = imgp->stringbase; argc = imgp->argc; envc = imgp->envc; /* * Copy out strings - arguments and environment. */ copyout(stringp, destp, ARG_MAX - imgp->stringspace); /* * Fill in "ps_strings" struct for ps, w, etc. */ suword(&arginfo->ps_argvstr, (int)vectp); suword(&arginfo->ps_nargvstr, argc); /* * Fill in argument portion of vector table. */ for (; argc > 0; --argc) { suword(vectp++, (int)destp); while (*stringp++ != 0) destp++; destp++; } /* a null vector table pointer seperates the argp's from the envp's */ suword(vectp++, 0); suword(&arginfo->ps_envstr, (int)vectp); suword(&arginfo->ps_nenvstr, envc); /* * Fill in environment portion of vector table. */ for (; envc > 0; --envc) { suword(vectp++, (int)destp); while (*stringp++ != 0) destp++; destp++; } /* end of vector table is a null pointer */ suword(vectp, 0); return (stack_base); } /* * Check permissions of file to execute. * Return 0 for success or error code on failure. */ static int exec_check_permissions(imgp) struct image_params *imgp; { struct proc *p = imgp->proc; struct vnode *vp = imgp->vp; struct vattr *attr = imgp->attr; int error; /* Get file attributes */ error = VOP_GETATTR(vp, attr, p->p_ucred, p); if (error) return (error); /* * 1) Check if file execution is disabled for the filesystem that this * file resides on. * 2) Insure that at least one execute bit is on - otherwise root * will always succeed, and we don't want to happen unless the * file really is executable. * 3) Insure that the file is a regular file. */ if ((vp->v_mount->mnt_flag & MNT_NOEXEC) || ((attr->va_mode & 0111) == 0) || (attr->va_type != VREG)) { return (EACCES); } /* * Zero length files can't be exec'd */ if (attr->va_size == 0) return (ENOEXEC); /* * Check for execute permission to file based on current credentials. */ error = VOP_ACCESS(vp, VEXEC, p->p_ucred, p); if (error) return (error); /* * Check number of open-for-writes on the file and deny execution * if there are any. */ if (vp->v_writecount) return (ETXTBSY); /* * Call filesystem specific open routine (which does nothing in the * general case). */ error = VOP_OPEN(vp, FREAD, p->p_ucred, p); if (error) return (error); /* * Disable setuid/setgid if the filesystem prohibits it or if * the process is being traced. */ if ((vp->v_mount->mnt_flag & MNT_NOSUID) || (p->p_flag & P_TRACED)) attr->va_mode &= ~(VSUID | VSGID); return (0); } --_=XFMail.1.2.p0.FreeBSD:980428153512:18582=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 12:43:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12382 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 12:43:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12251 for ; Tue, 28 Apr 1998 12:42:55 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id PAA28728; Tue, 28 Apr 1998 15:42:45 -0400 (EDT) Date: Tue, 28 Apr 1998 15:42:44 -0400 (EDT) From: Snob Art Genre To: Mike cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Custom Kernel In-Reply-To: <3545E011.41C67EA6@ida.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, Mike wrote: > Perhaps I should've phrased my question better. I wasn't interested in > technical help for wine, I was curious as to what SYSVSEM was. I would > consider that general technical discussion. Nowhere in my message did I > beg and plead for some help getting wine to work. See the sem*(2) man pages: semop(), semctl(), semget(). > Am I sorry for violating the sanctity of your precious list? No. Oh, relax, nobody flamed you, it was a simple miscommunication. > Thanks to all those who responded, though. > > Mike Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 13:06:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA21252 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 13:06:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA21236 for ; Tue, 28 Apr 1998 13:06:10 -0700 (PDT) (envelope-from atf3r@cs.virginia.edu) Received: from ares.cs.virginia.edu by mail.virginia.edu id aa19691; 28 Apr 98 16:04 EDT Received: from mamba.cs.Virginia.EDU (mamba-fo.cs.Virginia.EDU [128.143.136.18]) by ares.cs.Virginia.EDU (8.8.5/8.8.5) with ESMTP id QAA11436; Tue, 28 Apr 1998 16:03:55 -0400 (EDT) Received: from localhost (atf3r@localhost) by mamba.cs.Virginia.EDU (8.7.5/8.7.3) with SMTP id QAA13701; Tue, 28 Apr 1998 16:03:54 -0400 (EDT) X-Authentication-Warning: mamba.cs.Virginia.EDU: atf3r owned process doing -bs Date: Tue, 28 Apr 1998 16:03:54 -0400 (EDT) From: "Adrian T. Filipi-Martin" Reply-To: Adrian Filipi-Martin To: Garance A Drosihn cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, Garance A Drosihn wrote: > If you have a system which does overallocate, you're going to randomly > pick processes to kill. Or maybe the system will even make a pretty > good guess at what to kill. That is a true statement with or without > SIGDANGER. The question is, will there be any way for some critical > process (system daemons, the X-server, whatever) to tell the system > "No, don't kill me, try to kill someone else first!". > > The example you give isn't particularly interesting, as I (as a system > administrator) don't really care if any or all of those pittly little > processes ( :-) ) get killed. I may, however, be very unhappy if sshd > or the main lpd process gets killed just because they *happen* to be > the process which requests memory at the wrong time while you're running > that "danger.c" program. Ok. I'll buy that. My concearn is that every process of "interest" will need to have a SIGDANGER handler added. Just because my shell didn't have a handler, doesn't mean I want it killed off. I see that presently there is no security in the present situation and that it may get killed off anyway. If a default handler for SIGDANGER were provided that prevented a process form being killed on the first SIGDANGER and instead flushed any freed memory in the malloc free lists, and then only on the second reception of SIGDANGER tried to exit, I would feel more comfortable. A second chance handler like this seems reasonable as it may free up some resources without killing too many processes needlessly. Adrian -- adrian@virginia.edu ---->>>>| If I were stranded on a desert island, and System Administrator --->>>| I could only have one OS for my computer, Neurosurgical Visualization Lab ->>| it would be FreeBSD. Think about it..... http://www.nvl.virginia.edu/ ->| http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 13:13:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22876 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 13:13:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22724 for ; Tue, 28 Apr 1998 13:12:52 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id VAA12265; Tue, 28 Apr 1998 21:45:06 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id VAA02280; Tue, 28 Apr 1998 21:33:49 +0200 (CEST) (envelope-from andreas) Message-ID: <19980428213349.A1701@klemm.gtn.com> Date: Tue, 28 Apr 1998 21:33:49 +0200 From: Andreas Klemm To: Bob Bishop , hackers@FreeBSD.ORG Subject: Re: Wow! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Bob Bishop on Tue, Apr 28, 1998 at 12:18:32PM +0100 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 28, 1998 at 12:18:32PM +0100, Bob Bishop wrote: > > Solaris calls Hotmail shots for Microsoft Where's this article from ? URL ? > > First appeared in Network News, 22-April - 1998 Didn't find an URL ... -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html powered by ,,symmetric multiprocessor FreeBSD'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 13:56:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03338 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 13:56:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ve7tcp.ampr.org (ve7tcp.ampr.org [198.161.92.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA03304 for ; Tue, 28 Apr 1998 13:55:43 -0700 (PDT) (envelope-from lyndon@ve7tcp.ampr.org) Received: from localhost.ampr.org (localhost.ampr.org [127.0.0.1]) by ve7tcp.ampr.org (8.9.0.Beta5/8.9.0.Beta5) with SMTP id OAA16644; Tue, 28 Apr 1998 14:55:36 -0600 (MDT) Message-Id: <199804282055.OAA16644@ve7tcp.ampr.org> X-Authentication-Warning: ve7tcp.ampr.org: localhost.ampr.org [127.0.0.1] didn't use HELO protocol To: "David E. Cross" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-reply-to: Your message of "Tue, 28 Apr 1998 12:17:40 EDT." Date: Tue, 28 Apr 1998 14:55:36 -0600 From: Lyndon Nerenberg Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "David" == David E Cross writes: David> Default should be as it is on AIX, to terminate the David> process. Folks, the default (AIX 4.2) is to *ignore* the signal: The system monitors the number of free paging space blocks and detects when a paging-space shortage exists. When the number of free paging-space blocks falls below a threshold known as the paging-space warning level, the system informs all processes (except kprocs) of this condition by sending the SIGDANGER signal. If the shortage continues and falls below a second threshold known as the paging-space kill level, the system sends the SIGKILL signal to processes that are the major users of paging space and that do not have a signal handler for the SIGDANGER signal (**the default action for the SIGDANGER signal is to ignore the signal**). The system continues sending SIGKILL signals until the number of free paging-space blocks is above the paging-space kill level. [Above quoted from the AIX system doc] Processes in AIX will eventually die from SIGKILL, the same as any other UNIX that overcommits. If you don't do something explicit with SIGDANGER you'll never know it's there. (It has to behave this way to maintain backwards source compatibility.) AIX provides a pssignal() subroutine that can be used to query the state of the paging space. (pssignal manpage appended to the end of this message.) Limited user-space control of the swapspace allocation policy is available: If the PSALLOC environment variable is set to early, then every program started in that environment from that point on, but not including currently running processes, will run in the early allocation environment. In the early allocation environment, interfaces such as the malloc subroutine and the brk subroutine will fail if sufficient paging space cannot be reserved when the request is made. I *especially* like their suggested method of changing the policy from within a running program: Programming Interface The programming interface that controls the paging space allocation mode uses the PSALLOC environment variable. To ensure that an application always runs under the desired mode (with or without early paging space allocation), do the following: 1. Use the getenv subroutine to examine the current state of the PSALLOC environment variable. 2. If the value of the PSALLOC environment variable is not the value required by the application, use the setenv subroutine to alter the value of the environment variable. Since only the execve subroutine examines the state of the PSALLOC environment variable, call the execve subroutine with the same set of parameters and environment received by the application. When the application reexamines the state of the PSALLOC environment variable and finds the correct value, the application continues normally. 3. If the getenv subroutine reveals that the current state of the PSALLOC environment variable is correct, no modification is needed. The application continues normally. Are these guys for real? If anything, a process should be able to change it's allocation policy through vmadvise(), although I'd hate to contemplate what sort of kernel mods would be required. And no matter how this is implemented, any form of overcommit should be *disabled* by default. Any system that ships out-of-the-box with broken malloc() and sbrk() is pretty lame ... --lyndon psdanger Subroutine Purpose Defines the amount of free paging space available. Syntax #include int psdanger (Signal) int Signal; Description The psdanger subroutine returns the difference between the current number of free paging-space blocks and the paging-space thresholds of the system. Parameters Signal Defines the signal. Return Values If the value of the Signal parameter is 0, the return value is the total number of paging-space blocks defined in the system. If the value of the Signal parameter is -1, the return value is the number of free paging-space blocks available in the system. If the value of the Signal parameter is SIGDANGER, the return value is the difference between the current number of free paging-space blocks and the paging-space warning threshold. If the number of free paging-space blocks is less than the paging-space warning threshold, the return value is negative. If the value of the Signal parameter is SIGKILL, the return value is the difference between the current number of free paging-space blocks and the paging-space kill threshold. If the number of free paging-space blocks is less than the paging-space kill threshold, the return value is negative. Implementation Specifics This subroutine is part of Base Operating System (BOS) Runtime. Related Information The swapon subroutine, swapqry subroutine. The chps command, lsps command, mkps command, rmps command, swapon command. Paging Space Overview in Subroutines Overview and Understanding Paging Space Programming Requirements in AIX Version 4 General Programming Concepts: Writing and Debugging Programs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 14:50:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15687 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 14:50:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15405; Tue, 28 Apr 1998 14:49:14 -0700 (PDT) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.8/8.8.8) with ESMTP id XAA17828; Tue, 28 Apr 1998 23:48:47 +0200 (MET DST) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.8.8/8.6.9) id XAA06441; Mon, 27 Apr 1998 23:08:14 +0200 (CEST) X-Face: " Date: Mon, 27 Apr 1998 23:08:13 +0200 From: Stefan Esser To: =?iso-8859-1?Q?Dag-Erling_Coidan_Sm=F8rgrav?= , "Matthew N. Dodd" Cc: Hans Huebner , freebsd-hackers@FreeBSD.ORG, Stefan Esser Subject: Re: FreeBSD HA configuration / Ethernet address takeover Mail-Followup-To: =?iso-8859-1?Q?Dag-Erling_Coidan_Sm=F8rgrav?= , "Matthew N. Dodd" , Hans Huebner , freebsd-hackers@FreeBSD.ORG, Stefan Esser References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.89i In-Reply-To: =?iso-8859-1?Q?=3Cxzpra2jfxkl=2Efsf=40hrotti=2Eifi=2Euio=2Eno=3E=3B_from?= =?iso-8859-1?Q?_Dag-Erling_Coidan_Sm=F8rgrav__on_Mon=2C_Apr_27=2C_1998_a?= =?iso-8859-1?Q?t_11=3A00=3A58AM_+0200?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1998-04-27 11:00 +0200, Dag-Erling Coidan Smørgrav wrote: > "Matthew N. Dodd" writes: > > I'm kind of puzzled at how this would be integrated with the > > SIOCGHWADDR/SIOCSHWADDR calls as you might also need a way of determining > > which hadware address to set/get :) > > No. You can set any arbitrary MAC address, but it will make a heavy > impact on network performance, since much of what is usually done in > hardware (discarding packets not meant for you) will have to be done > in software. No, not true. Ethernet chips usually don't hardwire the MAC address, but provide one (or more) register(s) that typically get initialised from a serial EEPROM. But that register may be written to, and there are Ethernet protocols that rely on that feature (DEC LAT, DECnet). Many Ethernet chips accept 16 addresses, including Multicast addresses. In addition to exact address matches, there is often a hash (using the Ethernet CRC algorithm and hardware) used to select N out of 64 to N out of 512 MAC addresses, leaving the exact address match to be done in software. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 15:33:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26495 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 15:33:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26487 for ; Tue, 28 Apr 1998 15:33:40 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id SAA21654 for ; Tue, 28 Apr 1998 18:33:10 -0400 (EDT) Date: Tue, 28 Apr 1998 18:33:10 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: hackers@FreeBSD.ORG Subject: Strange console/log message Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I saw this in highlighted text on a console today, this is the corresponding log entry: Apr 28 18:13:47 www /kernel: Output=32 Inflate_error=8 igz.error=8 error2=0 where=182 I really don't know what this means. Any ideas? Charles Sprickman spork@super-g.com ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 17:08:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15100 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 17:08:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from seabass.progroup.com (catfish.progroup.com [206.24.122.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15087 for ; Tue, 28 Apr 1998 17:08:19 -0700 (PDT) (envelope-from craig@tuna.progroup.com) Received: from ProGroup.COM (tuna.progroup.com [206.24.122.5]) by seabass.progroup.com (8.7.5/8.7.3) with SMTP id RAA18440; Tue, 28 Apr 1998 17:04:35 -0700 (PDT) Received: by ProGroup.COM (SMI-8.6/SMI-SVR4) id RAA23610; Tue, 28 Apr 1998 17:05:36 -0700 From: craig@tuna.progroup.com (Craig W. Shaver) Message-Id: <199804290005.RAA23610@ProGroup.COM> Subject: Re: Wow! URL To: andreas@klemm.gtn.com (Andreas Klemm) Date: Tue, 28 Apr 1998 17:05:36 -0700 (PDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19980428213349.A1701@klemm.gtn.com> from "Andreas Klemm" at Apr 28, 98 09:33:49 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On Tue, Apr 28, 1998 at 12:18:32PM +0100, Bob Bishop wrote: > > > Solaris calls Hotmail shots for Microsoft > > Where's this article from ? URL ? > > > > First appeared in Network News, 22-April - 1998 > > Didn't find an URL ... > Chew on this .... http://www.hotmail.com/cgi-bin/xhtml/html/fm_shell.html?title=More+About+Hotmail+Corporation&gifalt=More+About+Hotmail+Corporation&head=Employment+Opportunities&content=jobs&back=corp&from=corp or follow the links to find out more about Hotmail Corporation. -- Craig Shaver (craig@progroup.com) (415)390-0654 Productivity Group POB 60458 Sunnyvale, CA 94088 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 17:20:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17869 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 17:20:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17743 for ; Tue, 28 Apr 1998 17:19:55 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.7/8.8.4) with UUCP id BAA14596; Wed, 29 Apr 1998 01:18:42 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Wed, 29 Apr 1998 01:08:14 +0100 (BST) X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <19980428213349.A1701@klemm.gtn.com> References: ; from Bob Bishop on Tue, Apr 28, 1998 at 12:18:32PM +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Apr 1998 01:12:06 +0100 To: Andreas Klemm From: Bob Bishop Subject: Re: Wow! Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:33 pm +0100 28/4/98, Andreas Klemm wrote: >On Tue, Apr 28, 1998 at 12:18:32PM +0100, Bob Bishop wrote: >> > Solaris calls Hotmail shots for Microsoft > >Where's this article from ? URL ? Came to me via private email. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 17:26:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA19273 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 17:26:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nyef.res.cmu.edu (qmailr@NYEF.RES.CMU.EDU [128.2.88.90]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA19267 for ; Tue, 28 Apr 1998 17:26:40 -0700 (PDT) (envelope-from inf@nyef.res.cmu.edu) Received: (qmail 29714 invoked by uid 1000); 29 Apr 1998 00:26:38 -0000 Message-ID: <19980428202638.15088@nyef.res.cmu.edu> Date: Tue, 28 Apr 1998 20:26:38 -0400 From: Marca Registrada To: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER Mail-Followup-To: freebsd-hackers@freebsd.org References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> <19980428073841.05698@mcs.net> <19980428192742.1224.qmail@xcf.berkeley.edu> <19980428143114.33662@mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980428143114.33662@mcs.net>; from Karl Denninger on Tue, Apr 28, 1998 at 02:31:14PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoting Karl Denninger (karl@mcs.net): > Critical programs can either free up resources or exit, as they see fit. We > could also define a semantic that says that if a process set SIGHOLD for > that signal, then the kernel should do everything in its power NOT to whack > that particular process. BTW, I'd like to hope that only processes run as root have this power to elect themselves to be safe from random kills. Actually, is there much of a danger at all? With proper login limits it would take a group of users in a concerted effort to bring teh machine to its knees. It should possibly be a matter of local system policy (sysctl or compile time option) weathor or not SIGDANGER will be maskable by a non-root process, with the default being an open system. BTW, just for my two cents.. could SIGDANGER also be a producable signal (via kill(1)), such that I could say send it to X to have it release unneeded memory? -- - All we hear is internet gaagaa, internet googoo, internet gaagaa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 18:43:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA04969 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 18:43:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from thing.dyn.ml.org (pm335-09.dialip.mich.net [35.9.11.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA04812 for ; Tue, 28 Apr 1998 18:43:07 -0700 (PDT) (envelope-from mcdougall@ameritech.net) Received: from ameritech.net (bsdx [192.168.1.2]) by thing.dyn.ml.org (8.8.8/8.8.7) with ESMTP id VAA09625; Tue, 28 Apr 1998 21:42:37 -0400 (EDT) (envelope-from mcdougall@ameritech.net) Message-ID: <35468589.E8687703@ameritech.net> Date: Tue, 28 Apr 1998 21:42:34 -0400 From: Adam McDougall Reply-To: mcdougall@ameritech.net X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: spork CC: hackers@FreeBSD.ORG Subject: Re: Strange console/log message References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG spork wrote: > I saw this in highlighted text on a console today, this is the > corresponding log entry: > > Apr 28 18:13:47 www /kernel: Output=32 Inflate_error=8 igz.error=8 > error2=0 where=182 > > I really don't know what this means. Any ideas? > > Charles Sprickman > spork@super-g.com > ---- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message I got one of these today also, but it was when I was in the middle of copying some files and I switched my computer from a 10bt hub to a 100bt hub. Output=32 Inflate_error=8 igz.error=8 error2=0 where=180 tx0: device timeout 16 packets Curious, what version of freebsd do you have, and what kind of network card? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 19:09:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA09978 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 19:09:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA09908 for ; Tue, 28 Apr 1998 19:09:01 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA05252; Tue, 28 Apr 1998 19:08:57 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd005217; Tue Apr 28 19:08:55 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA07145; Tue, 28 Apr 1998 19:08:52 -0700 (MST) From: Terry Lambert Message-Id: <199804290208.TAA07145@usr01.primenet.com> Subject: Re: SIGDANGER To: adrian@virginia.edu Date: Wed, 29 Apr 1998 02:08:52 +0000 (GMT) Cc: dec@phoenix.its.rpi.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Adrian T. Filipi-Martin" at Apr 27, 98 11:32:55 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > When I ran this basic example on an AIX box years ago, a buch of > the sleepers get killed before the danger process does. Why kill them? > They have only minimal resources allocated. Because they needed pages which weren't available when the pages were needed. > I believe it also breaks the POSIX definition of malloc(3), if I > am not mistaken. Perhaps IBM had this ammended after introducing this > misfeature. Any malloc(3) that doesn't actually preallocate the memory to the process, instead of just creating empty page mappings that are backed by pages as needed, and any malloc(3) whose free(3) sbrk(2)'s memory back to the system are technically in violation of POSIX. Specifically, POSIX requires that if I free a segment, I should be able to malloc the same sized or smaller segment immediately following the free, and not have to check for failure. This is a bit of stupidity in POSIX. My main rant, which Jordan alluded to, is that I think it should be possible to preload all necessary pages into swap, and back them with swap rather than with the program image. The primary reason for doing this is so that your dataless machine or Network Computer does not freeze waiting for a pagein if the NFS server becomes unavailable for whatever reason. Having worked in an environment where most of engineering was running on dataless machines with local swap and local auxillary disk, but running most applciations from a central server (much easier to maintain 40+ engineers this way), and having had 40+ people become unproductive while the NFS server reboots... well, it became a design issue for me. Going a bit further down this road, one could imagine that certain processes should be preallocated real swap for clean data pages which may become dirty. This is a precopy rather than a copy-on-write policy for them. This would, I think, be the correct use of the "sticky" bit, in a memory overcommit environment. The "swap preload" case in the NFS environment should probably be a mount option which only applies to FS's that are flagged as remote. The real answer for the general case is that for allocations via sbrk(), you can't know ahead of time how much memory a process will use, unless it makes all of its memory demands up front. The "SIGDANGER", I think, would be sent to all processes in a low "memory + swap" condition, indicating to them that they are in danger of being killed if they ask for pages or dirty copy-on-write pages, or otherwise increase page use. Most "important" (system) processes would ignore the signal, or at most use it to try and free cached allcoations that they didn't really have in active use at the moment. I really would prefer some mechanism for targetting the offending process; ie: on a page demand that can't be satisfied, shoot the guy with the highest working set instead of the poor schmuck who has three dirty data pages and wants a fourth. In other words, delay the page demand satisfy in the hopes that you will be able to later satisfy the request instead of just shooting the guy. If the guy with the highest working set has a SIGDANGER (I prefer naming like SIGLOWMEM or something more descriptive of what the signal actually indicates) handler registered, and pages do not become available, then shoot the next highest working set guy, and so on. A probable optimization would be: 1) Shoot everyopne with a "low memory condition" handler 2) wait 3) if memory is still low, shoot the highest working set without a handler and go to 2 4) Satisfy outstanding unsatisfied requests. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 20:10:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA22919 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 20:10:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22779 for ; Tue, 28 Apr 1998 20:09:57 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt3-174.HiWAAY.net [208.147.146.174]) by fly.HiWAAY.net (8.8.8/8.8.6) with ESMTP id WAA29554; Tue, 28 Apr 1998 22:09:50 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id WAA09692; Tue, 28 Apr 1998 22:09:45 -0500 (CDT) Message-Id: <199804290309.WAA09692@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh cc: "Kent S. Gordon" , chuckr@glue.umd.edu, hackers@FreeBSD.ORG From: David Kelly Subject: Re: ctm question In-reply-to: Message from Warner Losh of "Tue, 28 Apr 1998 09:35:38 MDT." <199804281535.JAA04240@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Apr 1998 22:09:45 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > In message <199804281529.KAA02000@soccer.inetspace.com> "Kent S. Gordon" writ > es: > : I had this problem until I allowed for move memory usage by cvs. I > : would check the login classes used by both the cvs server and the > : client. diff of multiple megabyte files can take a lot of memory. > > Give that man a cigar! That did the trick for me. More detail please! How does one track down the login classes used by such processes? I've found a near sure fire way to totally lock up my FreeBSD 2.2.6-stable system is to have Netscape Navigator 3.01 (the 128-bit version) up, XFree86 3.3.1, Mach32 server, and to run "cd /usr/ports && cvs -q update -d" in an xterm. The above almost always freezes my 64MB PPro-200, and always about the time cvs is about to finish. No Navigator, no problem. Thought it might be a bad block in my swap partition so I moved swap to another disk, no change. Split swap across both disks, no change. Am not running a cvs or ctm server. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 20:28:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26942 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 20:28:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26805 for ; Tue, 28 Apr 1998 20:27:36 -0700 (PDT) (envelope-from sjr@home.net) Received: (from sjr@localhost) by istari.home.net (8.8.8/8.8.6) id XAA07502 for freebsd-hackers@FreeBSD.ORG; Tue, 28 Apr 1998 23:27:04 -0400 (EDT) Date: Tue, 28 Apr 1998 23:27:04 -0400 (EDT) From: "Stephen J. Roznowski" Message-Id: <199804290327.XAA07502@istari.home.net> To: freebsd-hackers@FreeBSD.ORG Subject: Bmaked version of perl 5 available for testing Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've uploaded a bmaked version of perl5 to ftp.freebsd.org:/pub/FreeBSD/incoming/bmake-perl5-1.0.tar.gz This tar file contains two items: BSD.usr.dist.patch - a patch that adds the perl directories, and perl5/ - contains the perl5 code and expects to live in /usr/src/gnu/usr.bin [I named it this way to prevent a conflict with the current perl version] I'd appreciate hearing any feedback on whether I got this completely correct. If I don't hear anything in a couple of days or so, I'll send-pr it. One item that isn't working correctly is the installation of the "man3" section of the perl5 man pages since they are of the form "xxx::yyy" which breaks the bsd.man.mk rules. Thanks, -SR To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 20:42:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29446 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 20:42:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29441 for ; Tue, 28 Apr 1998 20:42:24 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id UAA27324; Tue, 28 Apr 1998 20:41:41 -0700 (PDT) Message-Id: <199804290341.UAA27324@implode.root.com> To: msuarez@cybernet.com cc: FreeBSD Hackers Subject: Re: Kernel Programming Question In-reply-to: Your message of "Tue, 28 Apr 1998 15:35:13 EDT." From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Apr 1998 20:41:41 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ... > error=vn_rdwr(UIO_READ,imgp->vp,(void *) buf,PAGE_SIZE,offset, > UIO_SYSSPACE,IO_NODELOCKED,p->p_ucred,&resid,p); > if(!error) > { > int t=0; > if(resid) bzero((char *)buf+PAGE_SIZE-resid,resid); > for(t=0; t Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29777 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 20:44:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from thelab.hub.org (tc-51.acadiau.ca [131.162.2.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29770 for ; Tue, 28 Apr 1998 20:44:10 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.8.8/8.8.2) with SMTP id AAA12678; Wed, 29 Apr 1998 00:41:51 -0300 (ADT) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Wed, 29 Apr 1998 00:41:45 -0300 (ADT) From: The Hermit Hacker To: Bob Bishop cc: Andreas Klemm , hackers@FreeBSD.ORG Subject: Re: Wow! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Apr 1998, Bob Bishop wrote: > At 8:33 pm +0100 28/4/98, Andreas Klemm wrote: > >On Tue, Apr 28, 1998 at 12:18:32PM +0100, Bob Bishop wrote: > >> > Solaris calls Hotmail shots for Microsoft > > > >Where's this article from ? URL ? > > Came to me via private email. Ya, I showed it to a friend of mine, and he mentioned that he'd already seen it in the WinNTMag newsletter... :) Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 21:29:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA09774 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 21:29:55 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA09733 for ; Tue, 28 Apr 1998 21:29:39 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id VAA02970; Tue, 28 Apr 1998 21:28:55 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Snob Art Genre cc: Archie Cobbs , hackers@FreeBSD.ORG Subject: Re: Whom to contact? In-reply-to: Your message of "Tue, 28 Apr 1998 14:10:09 EDT." Date: Tue, 28 Apr 1998 21:28:55 -0700 Message-ID: <2967.893824135@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ben% pwd > /cdrom/CVS-Repository/src/usr.sbin/inetd Don't use the repository directly off the CD unless you're already a CVS master and know how to deal properly with read-only repositories. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 21:33:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA10757 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 21:33:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA10613; Tue, 28 Apr 1998 21:32:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id EAA00226; Wed, 29 Apr 1998 04:32:47 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA05814; Wed, 29 Apr 1998 06:32:46 +0200 (MET DST) Message-ID: <19980429063246.07285@follo.net> Date: Wed, 29 Apr 1998 06:32:46 +0200 From: Eivind Eklund To: Karl Denninger , Jason Nordwick Cc: dyson@FreeBSD.ORG, Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> <19980428073841.05698@mcs.net> <19980428192742.1224.qmail@xcf.berkeley.edu> <19980428143114.33662@mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980428143114.33662@mcs.net>; from Karl Denninger on Tue, Apr 28, 1998 at 02:31:14PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 28, 1998 at 02:31:14PM -0500, Karl Denninger wrote: [... types of SIGDANGER handling...] > This leaves you with: > > 1) Do nothing - you get the semantics we have now. If the kernel > needs to whack you it will, without notice, but the warning > is ignored (you don't want to do anything with it). > > 2) Trap the signal - you get notice, and can clean up and exit if you > are able. You're still vulnerable, in that the kernel can whack > you if it needs to (and you're still around). The kernel can put > these processes into the "second round" bucket - it at least knows > that you're trying to help. > > 3) Set SIG_HOLD. You're a critical process and the kernel should go > pick on someone else if it can. If it can't, well, tough bananas, > but at least we tried to keep you going. We should distinguish between user processes and root processes somehow, too. A user shouldn't be able to make root's processes die unless the machine is explictly configured for that to be possible (IMO). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 21:36:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA11709 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 21:36:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA11690 for ; Tue, 28 Apr 1998 21:36:15 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id VAA03029; Tue, 28 Apr 1998 21:35:39 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Archie Cobbs cc: benedict@echonyc.com (Snob Art Genre), hackers@FreeBSD.ORG Subject: Re: Whom to contact? In-reply-to: Your message of "Tue, 28 Apr 1998 10:48:45 PDT." <199804281748.KAA06998@bubba.whistle.com> Date: Tue, 28 Apr 1998 21:35:39 -0700 Message-ID: <3025.893824539@time.cdrom.com> From: ".signature" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ah, sorry.. well, you can read all about it in the handbook I think > (I've never set up a CVS repository myself). But assuming you have For someone who's not familiar with CVS, it's not the best advice to just point them at the repository. Far better to simply point them at http://www.freebsd.org/cgi/cvsweb.cgi and let them use the WWW tools for browsing the change logs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 23:09:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA28481 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 23:09:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA28361 for ; Tue, 28 Apr 1998 23:08:56 -0700 (PDT) (envelope-from xcejka00@dcse.fee.vutbr.cz) Received: from kazi.dcse.fee.vutbr.cz (kazi.dcse.fee.vutbr.cz [147.229.9.51]) by boco.fee.vutbr.cz (8.8.8/8.8.8) with ESMTP id IAA03562 for ; Wed, 29 Apr 1998 08:08:48 +0200 (MET DST) Received: from sts.dcse.fee.vutbr.cz (sts.dcse.fee.vutbr.cz [147.229.9.52]) by kazi.dcse.fee.vutbr.cz (8.8.8/8.8.8) with ESMTP id IAA14149 for ; Wed, 29 Apr 1998 08:08:47 +0200 (CEST) Received: (from xcejka00@localhost) by sts.dcse.fee.vutbr.cz (8.8.5/8.8.5) id GAA28763 for freebsd-hackers@FreeBSD.ORG; Wed, 29 Apr 1998 06:08:48 GMT Message-Id: <199804290608.GAA28763@sts.dcse.fee.vutbr.cz> Subject: none To: freebsd-hackers@FreeBSD.ORG Date: Wed, 29 Apr 1998 08:08:47 +0200 (MET DST) From: Cejka Rudolf 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG help ---------------------------------------------------------------- Rudolf Cejka, VUT Brno (fakulta Informatiky) e-mail: XCEJKA00@STUD.FEE.VUTBR.CZ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 23:09:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA28554 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 23:09:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA28535 for ; Tue, 28 Apr 1998 23:09:36 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: from localhost (fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) with SMTP id BAA09443; Wed, 29 Apr 1998 01:09:27 -0500 (CDT) Date: Wed, 29 Apr 1998 01:09:27 -0500 (CDT) From: "Matthew D. Fuller" To: ".signature" cc: Snob Art Genre , hackers@FreeBSD.ORG Subject: Re: Whom to contact? In-Reply-To: <3025.893824539@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, .signature wrote: > > Ah, sorry.. well, you can read all about it in the handbook I think > > (I've never set up a CVS repository myself). But assuming you have > > For someone who's not familiar with CVS, it's not the best advice > to just point them at the repository. Far better to simply point > them at http://www.freebsd.org/cgi/cvsweb.cgi and let them use the > WWW tools for browsing the change logs. Or point them at a nice CVS tutorial, like http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/cvs/ *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 23:38:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA03959 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 23:38:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03946 for ; Tue, 28 Apr 1998 23:38:04 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id GAA02131; Wed, 29 Apr 1998 06:38:01 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA06524; Wed, 29 Apr 1998 08:37:59 +0200 (MET DST) Message-ID: <19980429083759.61009@follo.net> Date: Wed, 29 Apr 1998 08:37:59 +0200 From: Eivind Eklund To: "Stephen J. Roznowski" , freebsd-hackers@FreeBSD.ORG Subject: Re: Bmaked version of perl 5 available for testing References: <199804290327.XAA07502@istari.home.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199804290327.XAA07502@istari.home.net>; from Stephen J. Roznowski on Tue, Apr 28, 1998 at 11:27:04PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 28, 1998 at 11:27:04PM -0400, Stephen J. Roznowski wrote: > I've uploaded a bmaked version of perl5 to > > ftp.freebsd.org:/pub/FreeBSD/incoming/bmake-perl5-1.0.tar.gz > > This tar file contains two items: > > BSD.usr.dist.patch - a patch that adds the perl directories, and > > perl5/ - contains the perl5 code and expects to live in > /usr/src/gnu/usr.bin [I named it this way to prevent > a conflict with the current perl version] This should (ideally, at least) expect to live in /usr/src/contrib/perl5 (original code) and /usr/src/gnu/usr.bin (makefiles). Could you make an attempt at splitting it thus? Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 28 23:39:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA04213 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 23:39:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA04187 for ; Tue, 28 Apr 1998 23:39:46 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id IAA09361; Wed, 29 Apr 1998 08:30:09 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id IAA26029; Wed, 29 Apr 1998 08:23:45 +0200 (CEST) (envelope-from andreas) Message-ID: <19980429082345.A25598@klemm.gtn.com> Date: Wed, 29 Apr 1998 08:23:45 +0200 From: Andreas Klemm To: The Hermit Hacker , Bob Bishop Cc: hackers@FreeBSD.ORG Subject: Re: Wow! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from The Hermit Hacker on Wed, Apr 29, 1998 at 12:41:45AM -0300 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 29, 1998 at 12:41:45AM -0300, The Hermit Hacker wrote: > On Wed, 29 Apr 1998, Bob Bishop wrote: > > > At 8:33 pm +0100 28/4/98, Andreas Klemm wrote: > > >On Tue, Apr 28, 1998 at 12:18:32PM +0100, Bob Bishop wrote: > > >> > Solaris calls Hotmail shots for Microsoft > > > > > >Where's this article from ? URL ? > > > > Came to me via private email. > > Ya, I showed it to a friend of mine, and he mentioned that he'd already > seen it in the WinNTMag newsletter... :) URL for the Win NT Mag ? -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html powered by ,,symmetric multiprocessor FreeBSD'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 00:07:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA09632 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 00:07:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from USC-FW.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA09466 for ; Wed, 29 Apr 1998 00:06:57 -0700 (PDT) (envelope-from Michael.Schuster@utimaco.co.at) Received: (from uucp@localhost) by USC-FW.utimaco.co.at (8.8.8/8.8.8) id JAA11660 for ; Wed, 29 Apr 1998 09:04:08 +0200 (CEST) (envelope-from Michael.Schuster@utimaco.co.at) Received: from ns1.int.utimaco.co.at(10.1.0.254) by USC-FW.utimaco.co.at via smap (V2.0) id xma011658; Wed, 29 Apr 98 09:03:38 +0200 Received: from utimaco.co.at (ultra1.int.utimaco.co.at [10.1.0.32]) by safeconcept.int.utimaco.co.at (8.8.5/8.8.5) with ESMTP id JAA29977 for ; Wed, 29 Apr 1998 09:03:35 +0200 (CEST) Message-ID: <3546D0C5.E388ED6B@utimaco.co.at> Date: Wed, 29 Apr 1998 09:03:33 +0200 From: Michael Schuster Organization: Utimaco Safe Concept GmbH. Linz Austria X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" Subject: Re: SIGDANGER Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > I may, however, be very unhappy if sshd > or the main lpd process gets killed just because they *happen* to be > the process which requests memory at the wrong time while you're running > that "danger.c" program. ePerhaps a "nodanger(1)" tool (similar to nohup(1)) could provide protection from that behaviour - to be used with discretion, of course. OTOH, you could designate a special [e]uid/[e]gid combination (eg. group == "nodanger" (very imaginative!)) to achieve this; this would also make it harder for any joe user to exploit this for his/her interest. -- Michael Schuster To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 02:38:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA08297 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 02:38:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA08272 for ; Wed, 29 Apr 1998 02:38:13 -0700 (PDT) (envelope-from grog@lemis.com) Received: from papillon.lemis.com ([192.122.138.250]) by freebie.lemis.com (8.8.8/8.8.7) with ESMTP id TAA20004; Wed, 29 Apr 1998 19:07:44 +0930 (CST) (envelope-from grog@lemis.com) Received: (grog@localhost) by papillon.lemis.com (8.8.8/8.6.12) id LAA00317; Wed, 29 Apr 1998 11:15:48 +0800 (SGT) Message-ID: <19980429111546.54200@papillon.lemis.com> Date: Wed, 29 Apr 1998 11:15:46 +0800 From: Greg Lehey To: Hans Huebner , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Hans Huebner on Sat, Apr 25, 1998 at 03:11:21PM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 25 April 1998 at 15:11:21 +0200, Hans Huebner wrote: > Hello there, > > we're running some of our critial LAN services (NIS, DNS, mail etc.) on > FreeBSD. The systems are quite stable, but from time to time we need to > take a system down for maintenance purposes. Also, hardware problems can > cause unplanned down times. > > I'm currently looking for a solution to configure a PC as a warm-standby > fallback server for the most important services (NIS and DNS). To make a > failover to the fallback server as transparent to the users as possible, > it would be best if the fallback system could take over the ethernet > address of the failed server. I've seen this work with certain > (expensive) Solaris configurations, and I'd like to do something similar > with FreeBSD. > > I tried to implement DNS failover by moving our name service IP address to > another machine, but this resulted in severe client problems (most clients > fail to renegotiate the MAC adress with ARP within finite time). > > Looking at the ifconfig manpage, I could not find a general way to set a > Ethernet card's MAC address. Is there a documented solution to this > problem? If not, would adding such functionality be problematic? > > Any pointers, hints or suggestions are greatly appreciated. I'd also be > interested in any reports on running two FreeBSD systems on one shared > SCSI bus. I suppose the disk driver would need to be changed quite a bit > to make use of the RESERVE UNIT SCSI command to prevent access collisions. Sorry for my late entry in this discussion--I'm currently connected to the net only once every day or two, though this will change back to normal by the weekend. Tandem Computers ("a Compaq company") has been addressing these problems for years. I know that a number of points have been discussed already, but it might be interesting to consider how Tandem does it, and how a PC solution could approximate. A big difference between the environment you're considering and the Tandem environment is that the Tandem environments are logically a single system which doesn't fail, whereas you're looking at separate systems, one of which may fail. A significant problem is to determine when the primary machine fails (what, you don't get a reply from the machine? Maybe *your* Ethernet board has failed). This problem has caused Tandem headaches for decades, and I'm not going to discuss it in this message. 1. Reliable Ethernet Tandem's Reliable Ethernet product does pretty much what you suggest: it has one board waiting as a hot standby, and if the first fails, the second will take its MAC address and carry on as if nothing had happened. The main concern is determining when the first board has failed. If you have a board which can change its MAC address, this obviously makes sense. It's an omission in FreeBSD not to have the facility. The fact that some boards can't do it is no argument against the function: if the board can't do it, the ioctl should return an appropriate error indication. In the case of a board which can't change its MAC address, the alternative of assuming its IP address and sending a couple of pings to the broadcast address sounds like a good workaround. Certainly it will normalize things faster than waiting for the application layer to try an alternative IP. 2. SCSI takeover. Tandem has had a number of strategies. None use two host adaptors on a string. The one used by the (now defunct) S2 range of triple modular redundant machines is closest to what you suggest: it uses a dual ported host adaptor, but only one IO processor controls the host adaptor at any one time. Since the system as a whole doesn't fail, there's no need to perform an fsck on the disks at takeover. I can't see a good solution in using two host adaptors on two different machines connected to a single string. As long as the second machine doesn't have access to the first machine's buffer cache, data can get lost, and a takeover must involve an fsck. The overhead of fsck could go into several minutes, much longer than the time that the application layer takes to try another IP address. I don't think that this would make much sense from an availability standpoint, though it obviously makes sense to recover the file systems and make them available on another machine if the first machine is going to be out of commission for any length of time. What makes more sense is to replicate the data across multiple systems. Possibly a software layer like the vinum volume manager would be able to perform this function: put one copy of the data on the local machine, another on one or two other machines via NFS or some other protocol, and always read from the local machine. As long as the write rate is not too high, this should allow for higher availability. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 04:03:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA25907 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 04:03:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.artcom.de ([192.76.129.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA25877 for ; Wed, 29 Apr 1998 04:03:06 -0700 (PDT) (envelope-from hans@artcom.de) Received: from transrapid.artcom.de by mail.artcom.de with smtp id m0yUUdF-000008C; Wed, 29 Apr 1998 13:02:33 +0200 (MEST) Date: Wed, 29 Apr 1998 13:02:32 +0200 (MEST) From: Hans Huebner To: Greg Lehey cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover In-Reply-To: <19980429111546.54200@papillon.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Apr 1998, Greg Lehey wrote: > A big difference between the environment you're considering and the > Tandem environment is that the Tandem environments are logically a > single system which doesn't fail, whereas you're looking at separate > systems, one of which may fail. A significant problem is to determine > when the primary machine fails (what, you don't get a reply from the > machine? Maybe *your* Ethernet board has failed). This problem has > caused Tandem headaches for decades, and I'm not going to discuss it > in this message. I was suggesting this approach while I had the OpenVision Axxion HA approach in mind. Axxion HA is a HA system for Solaris, and it works with Ethernet address takeover and dual-ported FC/AL disks. Clients see a Axxion HA pair as two seperate physical machines and one 'logical' machine which is run on either hosts of the pair. Services are normally accessed at the 'logical' machine, but clients are free to use the 'physical' systems if they feel the need to do so. Axxion HA reserves one physical ethernet port for interconnection between the two CPUs in a HA pair. This private ethernet is normally implemented with a crossed TP cable, and the HA monitoring software sends alive-messages through this interface. If one system detects that the other does no longer send alive messages, it first checks whether the public ethernet of the other still responds before taking over the public services. The disks in an Axxion HA configuration are dual-ported, but each disk is accessed only by one host at a time. The dual-porting is used solely to minimize the time a failover from one machine to the other takes. There are situations, of course, where such an approach fails, but a HA solution is not what Tandem offers (100% availability). A HA configuration can help nevertheless when one needs to perform system upgrades, reliable level 0 dumps or other work on a system which runs services users depend on. > 1. Reliable Ethernet > [...] > In the case of a board which can't change its MAC address, the > alternative of assuming its IP address and sending a couple of > pings to the broadcast address sounds like a good workaround. > Certainly it will normalize things faster than waiting for the > application layer to try an alternative IP. This does not work with an IP alias address unless special configuration measures are met. In fact, this is our primary problem, since we run our name service on a IP-adress which is an alias on the host our name server runs on. > 2. SCSI takeover. > [...] > I can't see a good solution in using two host adaptors on two > different machines connected to a single string. As long as the > second machine doesn't have access to the first machine's buffer > cache, data can get lost, and a takeover must involve an fsck. > The overhead of fsck could go into several minutes, much longer > than the time that the application layer takes to try another IP > address. I don't think that this would make much sense from an > availability standpoint, though it obviously makes sense to > recover the file systems and make them available on another > machine if the first machine is going to be out of commission for > any length of time. With respect to the HA discussion, dual-hosted SCSI busses would only allow for faster access to the disks if a failover occurs. In other applications, dual-hosting a SCSI bus would propably make more sense (sharing of tape drives would be one example, fast IP connectivity between two hosts would be another). > What makes more sense is to replicate the data across multiple > systems. Possibly a software layer like the vinum volume manager > would be able to perform this function: put one copy of the data > on the local machine, another on one or two other machines via NFS > or some other protocol, and always read from the local machine. > As long as the write rate is not too high, this should allow for > higher availability. If there is such a thing for FreeBSD, i want it ;) Best regards, Hans To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 05:00:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA09652 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 05:00:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from uk.ns.eu.org ([194.117.157.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA09644 for ; Wed, 29 Apr 1998 05:00:12 -0700 (PDT) (envelope-from aledm@uk.ns.eu.org) Received: (from aledm@localhost) by uk.ns.eu.org (8.6.12/8.6.12) id MAA01754; Wed, 29 Apr 1998 12:58:52 +0100 Date: Wed, 29 Apr 1998 12:58:52 +0100 (BST) From: Aled Morris X-Sender: aledm@uk.ns.eu.org To: Greg Lehey cc: Hans Huebner , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover In-Reply-To: <19980429111546.54200@papillon.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Apr 1998, Greg Lehey wrote: > Tandem's Reliable Ethernet product does pretty much what you > suggest: it has one board waiting as a hot standby, and if the > first fails, the second will take its MAC address and carry on as > if nothing had happened. The main concern is determining when the > first board has failed. Just to illustrate another approach - Cisco's Hot Standby Routing Protocol (HSRP) allows two (or more) routers on the same LAN to share an IP address which you can configure into your LAN hosts as their default route. This address is distinct from the actual address of your routers, so the HSRP address is basically a secondary (alias) address. The HSRP address also has its own MAC address, so if a fail-over occurs, the new "active" router simply starts responding to the HSRP MAC and IP address. This avoids problems with ARP cache flushing. The protocol is implemented by broadcasting keep-alives every 10 seconds or so on the LAN, and there are tweaks for nominating preferred routers, simple security etc. It would be cool to support this in FreeBSD (of course) but I don't know if the HSRP protocol is published. Aled -- tel +44 973 207987 O- aledm@routers.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 05:38:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA18037 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 05:38:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA18018; Wed, 29 Apr 1998 05:38:36 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id HAA16057; Wed, 29 Apr 1998 07:38:26 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id HAA06012; Wed, 29 Apr 1998 07:38:26 -0500 (CDT) Message-ID: <19980429073826.29484@mcs.net> Date: Wed, 29 Apr 1998 07:38:26 -0500 From: Karl Denninger To: Eivind Eklund Cc: Jason Nordwick , dyson@FreeBSD.ORG, Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> <19980428073841.05698@mcs.net> <19980428192742.1224.qmail@xcf.berkeley.edu> <19980428143114.33662@mcs.net> <19980429063246.07285@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19980429063246.07285@follo.net>; from Eivind Eklund on Wed, Apr 29, 1998 at 06:32:46AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 29, 1998 at 06:32:46AM +0200, Eivind Eklund wrote: > On Tue, Apr 28, 1998 at 02:31:14PM -0500, Karl Denninger wrote: > > [... types of SIGDANGER handling...] > > This leaves you with: > > > > 1) Do nothing - you get the semantics we have now. If the kernel > > needs to whack you it will, without notice, but the warning > > is ignored (you don't want to do anything with it). > > > > 2) Trap the signal - you get notice, and can clean up and exit if you > > are able. You're still vulnerable, in that the kernel can whack > > you if it needs to (and you're still around). The kernel can put > > these processes into the "second round" bucket - it at least knows > > that you're trying to help. > > > > 3) Set SIG_HOLD. You're a critical process and the kernel should go > > pick on someone else if it can. If it can't, well, tough bananas, > > but at least we tried to keep you going. > > We should distinguish between user processes and root processes > somehow, too. A user shouldn't be able to make root's processes die > unless the machine is explictly configured for that to be possible > (IMO). > > Eivind. Simple. sysctl variable for whether or not a user process can set SIG_HOLD. If not, then a user process cannot cause a critical system process to die. If you want to get fancy, then a second sysctl variable which controls whether there exists another bucket for root processes, which go between (2) and (3) (creating really four buckets - user processes which do nothing, user processes which trap SIGDANGER, root processes which do nothing, and any process which has set SIG_HOLD). This does require that critical system processes have a SIGDANGER handler added. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 06:18:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA26216 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 06:18:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA26205 for ; Wed, 29 Apr 1998 06:18:13 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id JAA03276; Wed, 29 Apr 1998 09:16:51 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Wed, 29 Apr 1998 09:16:51 -0400 (EDT) From: "David E. Cross" To: Terry Lambert cc: adrian@virginia.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <199804290208.TAA07145@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Apr 1998, Terry Lambert wrote: > A probable optimization would be: > > 1) Shoot everyopne with a "low memory condition" handler > 2) wait > 3) if memory is still low, shoot the highest working set > without a handler and go to 2 > 4) Satisfy outstanding unsatisfied requests. Hmm, I have a slighlty different idea... (the problem is, how long do you wait? A hog process could take a couple of seconds to complete and flush memory). This is what I would prefer to see: 1) SIGDANGER (or whatever) would cause a program to terminate by default 2) To ignore this signal your uid or euid must be 0. 3) Anyone can install a signal handler. the Kernel would then treat processes as follows: 1) Processes that did not have SIGDANGER handled would be the first to be killed (just sent a SIGKILL). 2) next processes that had a handler installed would be sent SIGDANGER. 3) Finally processes with SIGDANGER ignored would be killed. Presumably most processes would fall in group 1, and that could free up the majority of processes. As in the case of a process that dirtys a copy on write page when there is no more memory, if the process does not have any SIGDANGER handling, just kill it, otherwise complete step 1, if that does not free enough memory then kill the offending process. As there needs to be wait time with sigdanger, I think that processes that have sigdanger should be sent it when memory is 90% full, that will be a proactive step to keep memory from running out in the first place. -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 06:42:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA03373 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 06:42:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sctmg02.sct.ucarb.com (sctmg02.sct.ucarb.com [140.170.101.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA03357 for ; Wed, 29 Apr 1998 06:42:10 -0700 (PDT) (envelope-from NguyenHM@ucarb.com) Received: by sctmg02.sct.ucarb.com with Internet Mail Service (5.0.1458.49) id ; Wed, 29 Apr 1998 09:45:54 -0400 Message-ID: <332F90115D96D0119CD500805FEA976B013E85D6@HSCMS01> From: "Nguyen HM (Mike)" To: Greg Lehey , Hans Huebner Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: FreeBSD HA configuration / Ethernet address takeover Date: Wed, 29 Apr 1998 09:45:28 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At my day job, we use a product that HP makes called MC/Serviceguard w/ HP-UX. Two or more machines, sharing a set of disks. This system doesn't do Ethernet address takeover (we actually use FDDI here). Instead, you would define a "package" that would have its own IP address, and the MC/Serviceguard would map that to an interface on the machine on which the "package" is currently running. The "package" being the software and the volume group it lives on. All machines in the cluster have some kind of common heartbeat connection (e.g. serial or networking, we use a non-routed ethernet between the machines in a cluster). If a machine goes down, the MC/S will restart the package on another machine. Of course, there is some kind of lock manager to make sure you don't have two machines trying to run the same package (and thus access the same disks). Works reasonably well, and you can have, for example, two packages running on two machines with a common failover. It can also do things like hot spare network interfaces (e.g. two or more interfaces connected to the same network, but only one is active/ifconfig'ed, if it dies, MC/S will automatically bring up a spare interface; we actually use this product on several machines just for this purpose). This approach, of using an IP address, would save you the hassle of reprogramming the hardware address of an ethernet controller, as well as allow you to use whatever networking tech. you want. For those interested, I there's a bunch of stuff, including manuals are at http://www.docs.hp.com/hpux/ha, including a doc on how to set up a HA NFS environment. Mike. // Mike Nguyen // Unix Systems Analyst and Geek // Union Carbide Corporation * (281) 212-8073 // nguyenhm@ucarb.com * mikenguyen@sprintmail.com (personal) > ---------- > From: Hans Huebner[SMTP:hans@artcom.de] > Sent: Wednesday, April 29, 1998 6:02 AM > To: Greg Lehey > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: FreeBSD HA configuration / Ethernet address takeover > > On Wed, 29 Apr 1998, Greg Lehey wrote: > > > A big difference between the environment you're considering and the > > Tandem environment is that the Tandem environments are logically a > > single system which doesn't fail, whereas you're looking at separate > > systems, one of which may fail. A significant problem is to > determine > > when the primary machine fails (what, you don't get a reply from the > > machine? Maybe *your* Ethernet board has failed). This problem has > > caused Tandem headaches for decades, and I'm not going to discuss it > > in this message. > > I was suggesting this approach while I had the OpenVision Axxion HA > approach in mind. Axxion HA is a HA system for Solaris, and it works > with > Ethernet address takeover and dual-ported FC/AL disks. Clients see a > Axxion HA pair as two seperate physical machines and one 'logical' > machine > which is run on either hosts of the pair. Services are normally > accessed > at the 'logical' machine, but clients are free to use the 'physical' > systems if they feel the need to do so. > > Axxion HA reserves one physical ethernet port for interconnection > between > the two CPUs in a HA pair. This private ethernet is normally > implemented > with a crossed TP cable, and the HA monitoring software sends > alive-messages through this interface. If one system detects that the > other does no longer send alive messages, it first checks whether the > public ethernet of the other still responds before taking over the > public services. > > The disks in an Axxion HA configuration are dual-ported, but each disk > is > accessed only by one host at a time. The dual-porting is used solely > to > minimize the time a failover from one machine to the other takes. > > There are situations, of course, where such an approach fails, but a > HA > solution is not what Tandem offers (100% availability). A HA > configuration can help nevertheless when one needs to perform system > upgrades, reliable level 0 dumps or other work on a system which runs > services users depend on. > > > 1. Reliable Ethernet > > > [...] > > > In the case of a board which can't change its MAC address, the > > alternative of assuming its IP address and sending a couple of > > pings to the broadcast address sounds like a good workaround. > > Certainly it will normalize things faster than waiting for the > > application layer to try an alternative IP. > > This does not work with an IP alias address unless special > configuration > measures are met. In fact, this is our primary problem, since we run > our > name service on a IP-adress which is an alias on the host our name > server > runs on. > > > 2. SCSI takeover. > > > [...] > > > I can't see a good solution in using two host adaptors on two > > different machines connected to a single string. As long as the > > second machine doesn't have access to the first machine's buffer > > cache, data can get lost, and a takeover must involve an fsck. > > The overhead of fsck could go into several minutes, much longer > > than the time that the application layer takes to try another IP > > address. I don't think that this would make much sense from an > > availability standpoint, though it obviously makes sense to > > recover the file systems and make them available on another > > machine if the first machine is going to be out of commission > for > > any length of time. > > With respect to the HA discussion, dual-hosted SCSI busses would only > allow for faster access to the disks if a failover occurs. In other > applications, dual-hosting a SCSI bus would propably make more sense > (sharing of tape drives would be one example, fast IP connectivity > between > two hosts would be another). > > > What makes more sense is to replicate the data across multiple > > systems. Possibly a software layer like the vinum volume > manager > > would be able to perform this function: put one copy of the data > > on the local machine, another on one or two other machines via > NFS > > or some other protocol, and always read from the local machine. > > As long as the write rate is not too high, this should allow for > > higher availability. > > If there is such a thing for FreeBSD, i want it ;) > > Best regards, > Hans > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 07:10:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA07773 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 07:10:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA07759 for ; Wed, 29 Apr 1998 07:10:50 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id KAA02022; Wed, 29 Apr 1998 10:10:14 -0400 (EDT) Date: Wed, 29 Apr 1998 10:10:14 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Adam McDougall cc: hackers@FreeBSD.ORG Subject: Re: Strange console/log message In-Reply-To: <35468589.E8687703@ameritech.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 28 Apr 1998, Adam McDougall wrote: > I got one of these today also, but it was when I was in the middle of > copying some files and I switched my computer from a 10bt hub to a > 100bt hub. > Output=32 Inflate_error=8 igz.error=8 error2=0 where=180 > tx0: device timeout 16 packets > > Curious, what version of freebsd do you have, and what kind of network > card? This is a digital 21140(?) or de0, running at 10M. The machine is running 2.2-stable from early January... Charles To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 07:31:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA13395 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 07:31:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from soccer.inetspace.com (soccer.inetspace.com [206.50.163.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA13356 for ; Wed, 29 Apr 1998 07:31:18 -0700 (PDT) (envelope-from kgor@soccer.inetspace.com) Received: (from kgor@localhost) by soccer.inetspace.com (8.8.7/8.8.7) id JAA04255; Wed, 29 Apr 1998 09:29:54 -0500 (CDT) (envelope-from kgor) Date: Wed, 29 Apr 1998 09:29:54 -0500 (CDT) Message-Id: <199804291429.JAA04255@soccer.inetspace.com> From: "Kent S. Gordon" To: dkelly@hiwaay.net CC: imp@village.org, chuckr@glue.umd.edu, hackers@FreeBSD.ORG In-reply-to: <199804290309.WAA09692@nospam.hiwaay.net> (message from David Kelly on Tue, 28 Apr 1998 22:09:45 -0500) Subject: Re: ctm question Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "dkelly" == David Kelly writes: > Warner Losh writes: >> In message <199804281529.KAA02000@soccer.inetspace.com> "Kent >> S. Gordon" writ es: : I had this problem until I allowed for >> move memory usage by cvs. I : would check the login classes >> used by both the cvs server and the : client. diff of multiple >> megabyte files can take a lot of memory. >> >> Give that man a cigar! That did the trick for me. > More detail please! How does one track down the login classes > used by such processes? > I've found a near sure fire way to totally lock up my FreeBSD > 2.2.6-stable system is to have Netscape Navigator 3.01 (the > 128-bit version) up, XFree86 3.3.1, Mach32 server, and to run > "cd /usr/ports && cvs -q update -d" in an xterm. > The above almost always freezes my 64MB PPro-200, and always > about the time cvs is about to finish. No Navigator, no > problem. Thought it might be a bad block in my swap partition so > I moved swap to another disk, no change. Split swap across both > disks, no change. man login.conf to see how to set up login classes. If you use vipw the 5th field field has the login class that will be used for a particular user. I have found the default way to low for doing serious development or as a heavy user (anyone running netscape will be a heavy user of system resources). > Am not running a cvs or ctm server. > -- David Kelly N4HHE, dkelly@nospam.hiwaay.net > ===================================================================== > The human mind ordinarily operates at only ten percent of its > capacity -- the rest is overhead for the operating system. -- Kent S. Gordon Architect iNetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 08:19:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA24756 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 08:19:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from soccer.inetspace.com (soccer.inetspace.com [206.50.163.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA24715 for ; Wed, 29 Apr 1998 08:19:51 -0700 (PDT) (envelope-from kgor@soccer.inetspace.com) Received: (from kgor@localhost) by soccer.inetspace.com (8.8.7/8.8.7) id KAA04397; Wed, 29 Apr 1998 10:18:26 -0500 (CDT) (envelope-from kgor) Date: Wed, 29 Apr 1998 10:18:26 -0500 (CDT) Message-Id: <199804291518.KAA04397@soccer.inetspace.com> From: "Kent S. Gordon" To: inf@nyef.res.cmu.edu CC: freebsd-hackers@FreeBSD.ORG In-reply-to: <19980428202638.15088@nyef.res.cmu.edu> (message from Marca Registrada on Tue, 28 Apr 1998 20:26:38 -0400) Subject: Re: SIGDANGER Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "inf" == Marca Registrada writes: > Quoting Karl Denninger (karl@mcs.net): >> Critical programs can either free up resources or exit, as they >> see fit. We could also define a semantic that says that if a >> process set SIGHOLD for that signal, then the kernel should do >> everything in its power NOT to whack that particular process. > BTW, I'd like to hope that only processes run as root have this > power to elect themselves to be safe from random kills. On some boxes, some non root process are even more importain than most root processes. Database engines are a example of non-root processes that I would like to exclude from random kill (I want it to be the last process killed not the first). -- Kent S. Gordon Architect iNetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 08:33:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA27653 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 08:33:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles176.castles.com [208.214.165.176]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA27634 for ; Wed, 29 Apr 1998 08:33:27 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id HAA00489; Wed, 29 Apr 1998 07:29:09 -0700 (PDT) Message-Id: <199804291429.HAA00489@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: Snob Art Genre , Archie Cobbs , hackers@FreeBSD.ORG Subject: Re: Whom to contact? In-reply-to: Your message of "Tue, 28 Apr 1998 21:28:55 PDT." <2967.893824135@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Apr 1998 07:29:04 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > ben% pwd > > /cdrom/CVS-Repository/src/usr.sbin/inetd > > Don't use the repository directly off the CD unless you're already > a CVS master and know how to deal properly with read-only repositories. Having said that, you can get by with: % setenv CVSROOT /cdrom/CVS-Repository % cd /some-work-directory % cvs -R -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 09:11:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA03518 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 09:11:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles176.castles.com [208.214.165.176]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA03444 for ; Wed, 29 Apr 1998 09:10:56 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id IAA00746; Wed, 29 Apr 1998 08:07:52 -0700 (PDT) Message-Id: <199804291507.IAA00746@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: spork cc: hackers@FreeBSD.ORG Subject: Re: Strange console/log message In-reply-to: Your message of "Tue, 28 Apr 1998 18:33:10 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Apr 1998 08:07:51 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I saw this in highlighted text on a console today, this is the > corresponding log entry: > > Apr 28 18:13:47 www /kernel: Output=32 Inflate_error=8 igz.error=8 > error2=0 where=182 > > I really don't know what this means. Any ideas? Someone trying to run a gzipped executable that failed decompression. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 09:37:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09042 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 09:37:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA09017 for ; Wed, 29 Apr 1998 09:37:45 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id JAA23708 for ; Wed, 29 Apr 1998 09:37:13 -0700 (PDT) Received: from pau-amma.whistle.com(207.76.205.64) by whistle.com via smap (V1.3) id sma023706; Wed Apr 29 09:37:06 1998 Received: (from dhw@localhost) by pau-amma.whistle.com (8.8.7/8.8.7) id JAA09220 for freebsd-hackers@FreeBSD.ORG; Wed, 29 Apr 1998 09:37:06 -0700 (PDT) (envelope-from dhw) Date: Wed, 29 Apr 1998 09:37:06 -0700 (PDT) From: David Wolfskill Message-Id: <199804291637.JAA09220@pau-amma.whistle.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Wed, 29 Apr 1998 09:16:51 -0400 (EDT) >From: "David E. Cross" >the Kernel would then treat processes as follows: >1) Processes that did not have SIGDANGER handled would be the first to be >killed (just sent a SIGKILL). I'm probably exposing my ignorance here, but it seems to me that SIGKILL really ought to be a last resort.... Since it can't be caught, it provides absolutely no way for such a process to do any cleanup at all. On a related note, I'm wondering if memory allocation is the only resource to which this sort of strategy ought to apply: I don't think of any that are as critical, just now, but I'm not entirely convinced that the list (of resources) should contain only a single entry.... david -- David Wolfskill dhw@whistle.com (650) 577-7158 pager: (650) 401-0168 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 10:20:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA16444 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 10:20:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16282 for ; Wed, 29 Apr 1998 10:20:02 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id NAA05954; Wed, 29 Apr 1998 13:19:24 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Wed, 29 Apr 1998 13:19:23 -0400 (EDT) From: "David E. Cross" To: "Kent S. Gordon" cc: inf@nyef.res.cmu.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <199804291518.KAA04397@soccer.inetspace.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Apr 1998, Kent S. Gordon wrote: > On some boxes, some non root process are even more importain than most > root processes. Database engines are a example of non-root processes > that I would like to exclude from random kill (I want it to be the > last process killed not the first). > yes, and this is where a nohup style program comes in. -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 10:35:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19465 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 10:35:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA19444 for ; Wed, 29 Apr 1998 10:35:22 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA27993 for freebsd-hackers@freebsd.org; Wed, 29 Apr 1998 13:12:15 -0400 From: "Allen Smith" Message-Id: <9804291312.ZM27991@beatrice.rutgers.edu> Date: Wed, 29 Apr 1998 13:12:15 -0400 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: freebsd-hackers@FreeBSD.ORG Subject: Proxy ARP for transparent firewalling: arp -s pub vs choparp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. We've got a slightly weird situation, but it may be applicable to others. We're needing to set up a firewall to protect our systems, because the exterior Rutgers firewall isn't sufficient: A. it's rather looser than what's needed to protect SGIs (sigh...); and B. a lot of people can get access to PCs, etcetera inside the Rutgers firewall. Unfortunately, the local Network Services refuses to admit this, and won't reconfigure the building router to send packets for our machines to a firewall machine (admittedly, the router in question is old and limited in its capabilities), and also won't let us run routed on that machine to send RIP packets to do the reconfiguration itself. Therefore, the solution that I've come up with is using proxy ARP. This should work as follows: [Rutgers]---[Rutgers router]--[hub]--[our firewall]--[hub or switch]--[our machines] In this, in order to get the Network Services controlled router to direct packets that are for our machines to the firewall's exterior interface, it'll need to be sending our ARP packets that will tell the router (and the other machines on the local network) that its Ethernet interface is the one for all our machines' IP addresses. The firewall (a FreeBSD-stable machine that we're in the process of getting in from Atipa) will have ip_filter set up on it, which will use its fastroute capability to route packets to its interior interface if they're for our machines. Our machines will be set up with the firewall's interior interface (probably a private IP address, if I can get the routing set up properly for those - SGI's route implementation seems to be buggy in this regard, although that may be conflicts with routed) as their default gateway. OK. So far, fine and dandy. There are two problems, however: A. How do I get the firewall machine to broadcast (on the _exterior_ interface _only_) ARP packets for the interior machines? This comes down to a question of arp -s pub vs choparp. The former requires less machine time and no BPF interface (a definite advantage for a firewall machine, given promiscuous interface potentialities), but I'm not sure how to get it to behave properly. B. How do I make sure the firewall machine will still have the proper ARP entries when it's sending stuff inward? I've taken a look at the kernel, arp, and choparp source code, but I'm not much of a C programmer (I prefer Perl). People have mentioned arp_proxyall as a sysctl variable to me, but I'm not sure what that'll do. I sent this message to freebsd-stable before, and got some help, but I need to make sure that things will work _before_ I try doing anything like proxy ARP broadcasts - especially given the political considerations. Should I also send it to freebsd-isp, as the people with the most experience with firewalls? Thanks very much, -Allen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 10:45:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21921 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 10:45:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21857 for ; Wed, 29 Apr 1998 10:44:47 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id NAA06321; Wed, 29 Apr 1998 13:44:31 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Wed, 29 Apr 1998 13:44:30 -0400 (EDT) From: "David E. Cross" To: David Wolfskill cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <199804291637.JAA09220@pau-amma.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Apr 1998, David Wolfskill wrote: > >Date: Wed, 29 Apr 1998 09:16:51 -0400 (EDT) > >From: "David E. Cross" > > >the Kernel would then treat processes as follows: > >1) Processes that did not have SIGDANGER handled would be the first to be > >killed (just sent a SIGKILL). > > I'm probably exposing my ignorance here, but it seems to me that SIGKILL > really ought to be a last resort.... Since it can't be caught, it > provides absolutely no way for such a process to do any cleanup at all. When you get that critically low on memory you really don't have the luxury of warning a process that it is about to die, and waiting for the process to clean up, the 'warning' of processes should occur at some threshold of available memory, when you get to the point of *needing* to kill procs, then you should just kill them and be done with it ;) > > On a related note, I'm wondering if memory allocation is the only > resource to which this sort of strategy ought to apply: I don't think > of any that are as critical, just now, but I'm not entirely convinced > that the list (of resources) should contain only a single entry.... I think that is why AIX refers to it as SIGDANGER, it could be used for other cases where resources are critically low... file descriptors perhaps (just rambling, don't flame me). Seeing how this has caused quite a stir, why don't I take a crack at implimenting it (that is a subtle hint for the kernel programs to: a: Do it before I do b: run screaming into the night, ban me from -hackers and disavow all knowledge of FreeBSD c: point me at some source. I would prefer c) -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 10:49:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22886 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 10:49:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA22879 for ; Wed, 29 Apr 1998 10:49:21 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yUaZE-0007nY-00; Wed, 29 Apr 1998 10:22:48 -0700 Date: Wed, 29 Apr 1998 10:22:44 -0700 (PDT) From: Tom To: Aled Morris cc: Greg Lehey , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Apr 1998, Aled Morris wrote: > Just to illustrate another approach - Cisco's Hot Standby Routing Protocol > (HSRP) allows two (or more) routers on the same LAN to share an IP address > which you can configure into your LAN hosts as their default route. This > address is distinct from the actual address of your routers, so the HSRP > address is basically a secondary (alias) address. This is a bit of different problem, and therefore a bit of different solution. A better solution to the standby router issue is simply to have your hosts listen for the default route via RIP or OSPF. If they don't see updates from a particular router, it is assumed dead and your hosts switch to use the another router. You setup route priorities to force hosts to prefer a particular router. Also, with the new equal-cost routing patch for FreeBSD, FreeBSD will automatically balance traffic for routes with the same destination and same priority. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 11:21:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29001 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 11:21:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28972 for ; Wed, 29 Apr 1998 11:20:48 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id NAA04086; Wed, 29 Apr 1998 13:20:36 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id NAA12074; Wed, 29 Apr 1998 13:20:04 -0500 Message-ID: <19980429132003.21663@right.PCS> Date: Wed, 29 Apr 1998 13:20:04 -0500 From: Jonathan Lemon To: Allen Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Proxy ARP for transparent firewalling: arp -s pub vs choparp References: <9804291312.ZM27991@beatrice.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <9804291312.ZM27991@beatrice.rutgers.edu>; from Allen Smith on Apr 04, 1998 at 01:12:15PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Apr 04, 1998 at 01:12:15PM -0400, Allen Smith wrote: > In this, in order to get the Network Services controlled router to > direct packets that are for our machines to the firewall's exterior > interface, it'll need to be sending our ARP packets that will tell the > router (and the other machines on the local network) that its Ethernet > interface is the one for all our machines' IP addresses. The firewall > (a FreeBSD-stable machine that we're in the process of getting in from > Atipa) will have ip_filter set up on it, which will use its fastroute > capability to route packets to its interior interface if they're for > our machines. Our machines will be set up with the firewall's interior > interface (probably a private IP address, if I can get the routing set > up properly for those - SGI's route implementation seems to be buggy > in this regard, although that may be conflicts with routed) as their > default gateway. I have a similar situation, so I should describe what I have setup. [network]---[ firewall ]--------------------[machineN] de0 de1 ip: y.y.y.y ip: x.x.x.x ip: x.x.x.x ether: a:a:a:a:a:a ether: b:b:b:b:b:b Change the /etc/rc.conf on the firewall to: 1. configure the firewall interfaces identically: ifconfig_de0="inet x.x.x.x netmask 0xffff0000" ifconfig_de1="inet x.x.x.x netmask 0xffff0000" 2. install direct interface routes for each machine behind the firewall: static_routes="machine1" route_machine1="y.y.y.y -link de1:b:b:b:b:b:b -iface" 3. turn on proxyall (this will pass all arp requests back and forth between the two interfaces) arpproxy_all="YES" 4. add permanent ARP entries for each machine behind the firewall: (place this in something like /etc/rc.conf.local) arp -s machine1 auto pub Now, when: - the firewall gets an ARP request for any of machineN, it will answer with it's own MAC entry. - the firewall gets an IP packet for machineN, it will use the interface route to send the packet to the internal network. - machineN sends an ARP reply, the firewall will use this for sending to machineN, instead of the `published' MAC entry. - machineN sends an ARP request, the firewall will forward the request/reply between the two interfaces. This may not be the best way to do this, but it works for me. :-) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 11:42:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA02469 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 11:42:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA02445 for ; Wed, 29 Apr 1998 11:42:45 -0700 (PDT) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.9.0.Beta5/8.9.0.Beta5) id UAA18140; Wed, 29 Apr 1998 20:40:50 +0200 (SAT) From: John Hay Message-Id: <199804291840.UAA18140@zibbi.mikom.csir.co.za> Subject: Re: SIGDANGER In-Reply-To: <199804291637.JAA09220@pau-amma.whistle.com> from David Wolfskill at "Apr 29, 98 09:37:06 am" To: dhw@whistle.com (David Wolfskill) Date: Wed, 29 Apr 1998 20:40:50 +0200 (SAT) Cc: freebsd-hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >the Kernel would then treat processes as follows: > >1) Processes that did not have SIGDANGER handled would be the first to be > >killed (just sent a SIGKILL). > > I'm probably exposing my ignorance here, but it seems to me that SIGKILL > really ought to be a last resort.... Since it can't be caught, it > provides absolutely no way for such a process to do any cleanup at all. > > On a related note, I'm wondering if memory allocation is the only > resource to which this sort of strategy ought to apply: I don't think > of any that are as critical, just now, but I'm not entirely convinced > that the list (of resources) should contain only a single entry.... > Mbufs are even more critical than normal memory. If any program on your machine try to send a packet and there are no free mbufs and you are at the limit for your kernel, the kernel will just panic trying to use a NULL pointer. John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 11:45:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03045 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 11:45:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA03028 for ; Wed, 29 Apr 1998 11:45:08 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA28546; Wed, 29 Apr 1998 14:22:17 -0400 From: "Allen Smith" Message-Id: <9804291422.ZM28544@beatrice.rutgers.edu> Date: Wed, 29 Apr 1998 14:22:17 -0400 In-Reply-To: Jonathan Lemon "Re: Proxy ARP for transparent firewalling: arp -s pub vs choparp" (Apr 29, 1:20pm) References: <9804291312.ZM27991@beatrice.rutgers.edu> <19980429132003.21663@right.PCS> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Jonathan Lemon , freebsd-hackers@FreeBSD.ORG Subject: Re: Proxy ARP for transparent firewalling: arp -s pub vs choparp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Apr 29, 1:20pm, Jonathan Lemon (possibly) wrote: > I have a similar situation, so I should describe what I have setup. Thank you. > > [network]---[ firewall ]--------------------[machineN] > de0 de1 ip: y.y.y.y > ip: x.x.x.x ip: x.x.x.x > ether: a:a:a:a:a:a ether: b:b:b:b:b:b > > Change the /etc/rc.conf on the firewall to: > > 1. configure the firewall interfaces identically: > > ifconfig_de0="inet x.x.x.x netmask 0xffff0000" > ifconfig_de1="inet x.x.x.x netmask 0xffff0000" I may not be seeing something that should be obvious, but why do you have them as the same IP address? Wouldn't this interfere with doing proxying for ftp (needed due to the data connection for interfacing with servers that don't do passive connections properly), etcetera? (We're mainly planning on doing packet filtering, but will do proxying where necessary.) > 2. install direct interface routes for each machine behind > the firewall: > > static_routes="machine1" > route_machine1="y.y.y.y -link de1:b:b:b:b:b:b -iface" > > 3. turn on proxyall (this will pass all arp requests back and > forth between the two interfaces) > > arpproxy_all="YES" Interesting... > 4. add permanent ARP entries for each machine behind the firewall: > (place this in something like /etc/rc.conf.local) > > arp -s machine1 auto pub > > Now, when: > > - the firewall gets an ARP request for any of machineN, it will > answer with it's own MAC entry. Right... > - the firewall gets an IP packet for machineN, it will use the > interface route to send the packet to the internal network. Good... ip_filter with fastroute should work the same way. > - machineN sends an ARP reply, the firewall will use this > for sending to machineN, instead of the `published' MAC entry. Good... > - machineN sends an ARP request, the firewall will forward the > request/reply between the two interfaces. Huh. How is the inner interface of the firewall going to be getting packets with ethernet addresses of exterior machines? If you've instead got the inner machines set up to route to the firewall's inner interface, why should they need to send any ARP requests for exterior machines? > > This may not be the best way to do this, but it works for me. :-) It's certainly not something I'd have ever thought of, but it may be useful. I'll have to think on it some more. Thanks, -Allen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 11:47:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03504 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 11:47:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from jraynard.demon.co.uk (jraynard.demon.co.uk [158.152.42.77]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA03368; Wed, 29 Apr 1998 11:47:27 -0700 (PDT) (envelope-from fhackers@jraynard.demon.co.uk) Received: (from fhackers@localhost) by jraynard.demon.co.uk (8.8.8/8.8.8) id XAA01951; Tue, 28 Apr 1998 23:13:25 +0100 (BST) (envelope-from fhackers) Message-ID: <19980428231324.26307@jraynard.demon.co.uk> Date: Tue, 28 Apr 1998 23:13:24 +0100 From: James Raynard To: dyson@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <199804272230.RAA01545@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199804272230.RAA01545@dyson.iquest.net>; from John S. Dyson on Mon, Apr 27, 1998 at 05:30:38PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 27, 1998 at 05:30:38PM -0500, John S. Dyson wrote: > > > We do need to adopt an extended signal set, and I think that someone > else has already developed it. SIGDANGER could be valuable. Well, I did most of the base work a couple of months ago, before getting stuck. http://www.freebsd.org/~jraynard/source/ (Assuming you don't have someone/something else in mind). James To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 12:02:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05383 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 12:02:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA05282 for ; Wed, 29 Apr 1998 12:01:58 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA28725; Wed, 29 Apr 1998 14:38:27 -0400 From: "Allen Smith" Message-Id: <9804291438.ZM28723@beatrice.rutgers.edu> Date: Wed, 29 Apr 1998 14:38:27 -0400 In-Reply-To: "Nguyen HM (Mike)" "RE: FreeBSD HA configuration / Ethernet address takeover" (Apr 29, 9:45am) References: <332F90115D96D0119CD500805FEA976B013E85D6@HSCMS01> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Nguyen HM (Mike)" , Greg Lehey , Hans Huebner Subject: Re: FreeBSD HA configuration / Ethernet address takeover Cc: freebsd-hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Apr 29, 9:45am, Nguyen HM (Mike) (possibly) wrote: > packages running on two machines with a common failover. It can also do > things like hot spare network interfaces (e.g. two or more interfaces > connected to the same network, but only one is active/ifconfig'ed, if it > dies, MC/S will automatically bring up a spare interface; we actually > use this product on several machines just for this purpose). This would run into the current bug on FreeBSD that ARP entries for a deleted interface don't get deleted. It's among the PRs that don't have anyone looking at them (suspended ones): kern/425. -Allen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 12:31:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09647 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 12:31:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09635 for ; Wed, 29 Apr 1998 12:31:20 -0700 (PDT) (envelope-from conrad@apple.com) Received: from scv4.apple.com (A17-128-100-142.apple.com [17.128.100.142]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id MAA11176; Wed, 29 Apr 1998 12:23:13 -0700 Received: from [17.202.43.185] (wa.apple.com [17.202.43.185]) by scv4.apple.com (8.8.5/8.8.5) with ESMTP id MAA09822; Wed, 29 Apr 1998 12:23:11 -0700 X-Sender: conrad@mail.apple.com Message-Id: In-Reply-To: <199804290208.TAA07145@usr01.primenet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Apr 1998 12:23:09 -0700 To: freebsd-hackers@FreeBSD.ORG From: Conrad Minshall Subject: Re: SIGDANGER Cc: Terry Lambert Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This talk of SIGDANGER takes me back, way back. Long ago (circa '85) I worked for IBM on an operating system for a box called the RT PC. AIX was the OS, and yes, a young programmer (me) added SIGDANGER to it. Before SIGDANGER (and the failsafe measure SIGKILL code) AIX would freeze up if it ran out of paging space. That happened all too often because disk space was expensive, marketing wanted a low "entry" price, and so user systems were by default being configured with paging spaces too small for actual usage patterns. Note a fundamental requirement for AIX was that it support sparse allocation. Some AI and engineering applications required huge virtual address spaces that would be backed only "on demand". In the classic BSD model you must have disk space allocated for all virtual space, which was wasteful at best and prohibitively expensive at worst. At the time I suggested that sparse allocation should default off and processes have to request it somehow, but I was 1) very junior, and 2) unable to propose an implementation - the VM code was down in the mysterious "VRM", hidden from the Unix kernel layer. BTW, in the original AIX all signal bits were already in use so SIGEMT, which was unused by the system, got converted into SIGDANGER. That was of course a gross hack so later when time permitted signal bits were expanded beyond one 32 bit word and SIGDANGER switched from number 7 to number 33. So much for history/nostalgia. Terry: >If the guy with the highest working set has a SIGDANGER (I prefer >naming like SIGLOWMEM or something more descriptive of what the signal >actually indicates) handler registered, and pages do not become >available, then shoot the next highest working set guy, and so on. SIGLOSWAP then?. I chose SIGDANGER as I thought there might be a more general purpose use than just for critical lack of paging space. The generalized SIGDANGER was intended to mean "The system is in danger of crashing very soon. Processes, consider yourself warned." Terry: >Specifically, POSIX requires that if I free a segment, I should be able >to malloc the same sized or smaller segment immediately following the >free, and not have to check for failure. My copy of POSIX (the 1996 1003.1, also known as ISO 9945-1) specifies only that malloc and free must exist, leaving further definition to the C language standard. My copy of the C standard is ANSI's X3.159-1989. It makes no requirement that a free followed by a smaller or equal malloc must succeed. Perhaps this came up in one of the standard's "interpretations"(?) -- Conrad Minshall mailto:conrad@apple.com If "conrad@apple.com" doesn't work, try using my alternates: rad@acm.org, conradm@computer.org, conrad@technologist.com, and conrad.m@bigfoot.com Picon viewable at: http://facesaver.usenix.org/h/48/4704.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 12:51:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA13172 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 12:51:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA13143 for ; Wed, 29 Apr 1998 12:51:37 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA14949 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Wed, 29 Apr 1998 21:50:54 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.7/8.6.12) id VAA14966; Wed, 29 Apr 1998 21:08:32 +0200 (MET DST) From: Wilko Bulte Message-Id: <199804291908.VAA14966@yedi.iaf.nl> Subject: Re: FreeBSD HA configuration / Ethernet address takeover In-Reply-To: <19980429111546.54200@papillon.lemis.com> from Greg Lehey at "Apr 29, 98 11:15:46 am" To: grog@lemis.com (Greg Lehey) Date: Wed, 29 Apr 1998 21:08:32 +0200 (MET DST) Cc: hans@artcom.de, freebsd-hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Greg Lehey wrote... > On Sat, 25 April 1998 at 15:11:21 +0200, Hans Huebner wrote: > > Hello there, > > > > we're running some of our critial LAN services (NIS, DNS, mail etc.) on > > FreeBSD. The systems are quite stable, but from time to time we need to > > take a system down for maintenance purposes. Also, hardware problems can > > cause unplanned down times. ... > 2. SCSI takeover. > > Tandem has had a number of strategies. None use two host adaptors > on a string. The one used by the (now defunct) S2 range of triple > modular redundant machines is closest to what you suggest: it uses > a dual ported host adaptor, but only one IO processor controls the > host adaptor at any one time. Since the system as a whole doesn't > fail, there's no need to perform an fsck on the disks at takeover. > > I can't see a good solution in using two host adaptors on two > different machines connected to a single string. As long as the > second machine doesn't have access to the first machine's buffer > cache, data can get lost, and a takeover must involve an fsck. > The overhead of fsck could go into several minutes, much longer > than the time that the application layer takes to try another IP HA solutions without some kind of log based FS are in fact quite non-sensical if you have > 1 machine. > address. I don't think that this would make much sense from an > availability standpoint, though it obviously makes sense to > recover the file systems and make them available on another > machine if the first machine is going to be out of commission for > any length of time. > > What makes more sense is to replicate the data across multiple > systems. Possibly a software layer like the vinum volume manager > would be able to perform this function: put one copy of the data > on the local machine, another on one or two other machines via NFS > or some other protocol, and always read from the local machine. > As long as the write rate is not too high, this should allow for > higher availability. You could go for a RAID box, with dual raidcontrollers, each with a dual host port. If one of the SCSI 'rails' fails you can access the data via the surviving port. This solves the single point of failure of the SCSI buses, the host adapters and the raidcontrollers themselves. It does not, however, solve an important point: $$$ ;-) Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW: http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 12:55:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14188 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 12:55:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA14175 for ; Wed, 29 Apr 1998 12:55:32 -0700 (PDT) (envelope-from patl@phoenix.volant.org) From: patl@phoenix.volant.org Received: from asimov.phoenix.volant.org [205.179.79.65] by phoenix.volant.org with smtp (Exim 1.62 #1) id 0yUcwz-0005oR-00; Wed, 29 Apr 1998 12:55:29 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id MAA22501; Wed, 29 Apr 1998 12:53:38 -0700 Date: Wed, 29 Apr 1998 12:53:38 -0700 (PDT) Reply-To: patl@phoenix.volant.org Subject: Re: sysctl for SIGDANGER To: Karl Denninger cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19980429073826.29484@mcs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Simple. sysctl variable for whether or not a user process can set > SIG_HOLD. Better yet, instead of a simple boolean, make the sysctl variable a uid. Any uid less than or equal to that value is allowed to get the SIG_HOLD semantic. This gives the obvious degenerate cases for 'root only' and 'anyone'; but also allows the non-root userids that many of us prefer for critical daemons to be distinguished from 'real' users. I also think that the value should be checked when the system is looking for candidates to kill rather than actually preventing the user process from setting SIG_HOLD. That effectively gives us a fourth bucket to hold user processes that don't want to die; but will still be killed before SIG_HOLD system processes. And, more importantly, it has the expected behavour if the sys admin changes the sysctl variable after user processes have been started. In fact, it could be taken one step further. When the system is actually choosing processes to send a SIGKILL, it could give preference to those with uids above the cutoff point. So now we have six buckets. With the kill order being: user processes with no danger handler, system processes with no danger handler, user processes with a danger handler, system processes with a danger handler, user processes with SIG_HOLD set, system processes with SIG_HOLD set. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 13:01:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15450 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 13:01:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA15441 for ; Wed, 29 Apr 1998 13:00:59 -0700 (PDT) (envelope-from patl@phoenix.volant.org) From: patl@phoenix.volant.org Received: from asimov.phoenix.volant.org [205.179.79.65] by phoenix.volant.org with smtp (Exim 1.62 #1) id 0yUd2K-0005rC-00; Wed, 29 Apr 1998 13:01:00 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id MAA22504; Wed, 29 Apr 1998 12:59:10 -0700 Date: Wed, 29 Apr 1998 12:59:10 -0700 (PDT) Reply-To: patl@phoenix.volant.org Subject: Re: NFS -vs- swap (was SIGDANGER) To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199804290208.TAA07145@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My main rant, which Jordan alluded to, is that I think it should be > possible to preload all necessary pages into swap, and back them with > swap rather than with the program image. > > The primary reason for doing this is so that your dataless machine > or Network Computer does not freeze waiting for a pagein if the NFS > server becomes unavailable for whatever reason. > > Having worked in an environment where most of engineering was running > on dataless machines with local swap and local auxillary disk, but > running most applciations from a central server (much easier to maintain > 40+ engineers this way), and having had 40+ people become unproductive > while the NFS server reboots... well, it became a design issue for me. This sounds like a good environment for a cachefs on top of the appropriate NFS mounts. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 13:01:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15465 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 13:01:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dan.emsphone.com (dan@dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15445 for ; Wed, 29 Apr 1998 13:01:02 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.8.8/8.8.6) id PAA17809 for freebsd-hackers@freebsd.org; Wed, 29 Apr 1998 15:00:55 -0500 (CDT) Message-ID: <19980429150055.A17639@emsphone.com> Date: Wed, 29 Apr 1998 15:00:55 -0500 From: Dan Nelson To: freebsd-hackers@FreeBSD.ORG Subject: how to fseek past 2GB? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.1i X-OS: FreeBSD 2.2.6-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I recently noticed that there is no way to fseek() past the 2GB mark on files opened with fopen(). The offset in the FILE struct is an fpos_t; there's just no way to get at it. fseek(), unfortunately, is cursed with a "long" file offset, so that can't change. fsetpos() _could_ seek past the 2GB mark, since a fpos_t is a long long. Our current fsetpos implementation simply calls (fseek(iop, (long)*pos, SEEK_SET)), though. What I did for my own use is create lfseek() and lftell() functions that basically copy the fseek() and ftell() source, but replace "long" with "fpos_t". It works great. If I were to submit these as a PR, what would be the best way to do it? I'm leaning toward making fseek() and fsetpos() call lfseek(), to eliminate redundant code. Is there a "standard" function name for a fseek() function that takes an off_t or fpos_t? -Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 13:20:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20045 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 13:20:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from symbion.srrc.usda.gov ([199.78.118.118]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19705 for ; Wed, 29 Apr 1998 13:19:58 -0700 (PDT) (envelope-from glenn@nola.srrc.usda.gov) Received: from nola.srrc.usda.gov (localhost.srrc.usda.gov [127.0.0.1]) by symbion.srrc.usda.gov (8.8.8/8.8.8) with ESMTP id PAA03017 for ; Wed, 29 Apr 1998 15:19:38 -0500 (CDT) (envelope-from glenn@nola.srrc.usda.gov) Message-Id: <199804292019.PAA03017@symbion.srrc.usda.gov> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG From: Glenn Johnson Subject: debugging Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Apr 1998 15:19:38 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I sent the message below to questions@freebsd.org a few days ago but have not received a response so I thought I would try here. Thanks. -------------------------------- I have some Fortran programs that compile and run fine using f77 (f2c/cc). If I compile the code with g77 I get significantly better performance but some of the programs will give the following message upon completion: free(): warning: modified (page-) pointer I get the correct results from the programs but I am concerned. How serious of a problem is this? Am I correct in assuming that g77 is optimizing the code in a way that is exposing a bug in the program code? Since using gdb on g77 compiled code is less than ideal, does anyone have an idea on how to go about finding info on the problem(s)? I am not a skilled programmer but I would like to be able to provide information to the program developers. The malloc warning does not occur under Linux/g77 and so they may not be aware of any underlying bug(s). Thanks in advance for your help. -- Glenn Johnson Technician USDA-ARS-SRRC Phone: (504) 286-4252 1100 Robert E. Lee Boulevard FAX: (504) 286-4217 New Orleans, LA 70124 e-mail: gjohnson@nola.srrc.usda.gov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 13:23:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20712 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 13:23:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20543 for ; Wed, 29 Apr 1998 13:22:44 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id PAA04344; Wed, 29 Apr 1998 15:22:40 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id PAA10188; Wed, 29 Apr 1998 15:22:08 -0500 Message-ID: <19980429152208.47192@right.PCS> Date: Wed, 29 Apr 1998 15:22:08 -0500 From: Jonathan Lemon To: Allen Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Proxy ARP for transparent firewalling: arp -s pub vs choparp References: <9804291312.ZM27991@beatrice.rutgers.edu> <19980429132003.21663@right.PCS> <9804291422.ZM28544@beatrice.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <9804291422.ZM28544@beatrice.rutgers.edu>; from Allen Smith on Apr 04, 1998 at 02:22:17PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Apr 04, 1998 at 02:22:17PM -0400, Allen Smith wrote: > On Apr 29, 1:20pm, Jonathan Lemon (possibly) wrote: > > > > [network]---[ firewall ]--------------------[machineN] > > de0 de1 ip: y.y.y.y > > ip: x.x.x.x ip: x.x.x.x > > ether: a:a:a:a:a:a ether: b:b:b:b:b:b > > > > Change the /etc/rc.conf on the firewall to: > > > > 1. configure the firewall interfaces identically: > > > > ifconfig_de0="inet x.x.x.x netmask 0xffff0000" > > ifconfig_de1="inet x.x.x.x netmask 0xffff0000" > > I may not be seeing something that should be obvious, but why do you > have them as the same IP address? Wouldn't this interfere with doing > proxying for ftp (needed due to the data connection for interfacing > with servers that don't do passive connections properly), etcetera? > (We're mainly planning on doing packet filtering, but will do proxying > where necessary.) Why not? Since the two networks are separate, the IP address is still unique on each network. > > - machineN sends an ARP request, the firewall will forward the > > request/reply between the two interfaces. > > Huh. How is the inner interface of the firewall going to be getting > packets with ethernet addresses of exterior machines? If you've > instead got the inner machines set up to route to the firewall's inner > interface, why should they need to send any ARP requests for exterior > machines? Perhaps I didn't express myself clearly. The interior machines aren't set up to route through the firewall, their routing tables are exactly the same as if the firewall wasn't there at all. So when they try to send "directly" to a host, the firewall picks up the ARP request, re-transmits it on the other side, gets the response, and enters the response into the firewall's ARP table. Then the firewall creates an ARP reply to interior machine, consisting of the firewall's interior MAC address. So isofar as the internal machines are concerned, they think they have a direct connection to the exterior machines. I also forgot to mention that I have IP forwarding enabled on the "firewall" in this scenario. Actually, it isn't acting as a firewall at all, but a bandwidth limiter, so I can control the amount of bandwidth which the interior machines are able to use. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 13:57:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA27018 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 13:57:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA26999 for ; Wed, 29 Apr 1998 13:57:54 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id NAA10537; Wed, 29 Apr 1998 13:57:23 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Conrad Minshall cc: freebsd-hackers@FreeBSD.ORG, Terry Lambert Subject: Re: SIGDANGER In-reply-to: Your message of "Wed, 29 Apr 1998 12:23:09 PDT." Date: Wed, 29 Apr 1998 13:57:22 -0700 Message-ID: <10533.893883442@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This talk of SIGDANGER takes me back, way back. Long ago (circa '85) I > worked for IBM on an operating system for a box called the RT PC. AIX was > the OS, and yes, a young programmer (me) added SIGDANGER to it. So you're one of those evil AIX people who helped kill the ACIS port, the only REAL operating system for the PC RT? :-) :-) Jordan [I liked the RT - I had two of them, both running *ACIS* :) ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 14:14:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA00964 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 14:14:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA00896 for ; Wed, 29 Apr 1998 14:14:11 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id RAA07387; Wed, 29 Apr 1998 17:13:56 -0400 (EDT) Date: Wed, 29 Apr 1998 17:13:55 -0400 (EDT) From: Snob Art Genre To: "Jordan K. Hubbard" cc: Conrad Minshall , freebsd-hackers@FreeBSD.ORG, Terry Lambert Subject: Re: SIGDANGER In-Reply-To: <10533.893883442@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Since I was 7 years old at the time, could someone please tell me what a PC RT is, and for that matter what color is an ACIS? ;-) On Wed, 29 Apr 1998, Jordan K. Hubbard wrote: > > This talk of SIGDANGER takes me back, way back. Long ago (circa '85) I > > worked for IBM on an operating system for a box called the RT PC. AIX was > > the OS, and yes, a young programmer (me) added SIGDANGER to it. > > So you're one of those evil AIX people who helped kill the ACIS port, > the only REAL operating system for the PC RT? :-) :-) > > Jordan [I liked the RT - I had two of them, both > running *ACIS* :) ] > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 14:31:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05167 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 14:31:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hwcn.org (ac199@james.hwcn.org [199.212.94.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05132; Wed, 29 Apr 1998 14:30:57 -0700 (PDT) (envelope-from hoek@hwcn.org) Received: from localhost (ac199@localhost) by hwcn.org (8.8.8/8.8.8) with SMTP id RAA13438; Wed, 29 Apr 1998 17:25:11 -0400 (EDT) Date: Wed, 29 Apr 1998 17:25:10 -0400 (EDT) From: Tim Vanderhoek To: Karl Denninger cc: Eivind Eklund , Jason Nordwick , dyson@FreeBSD.ORG, Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <19980429073826.29484@mcs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Apr 1998, Karl Denninger wrote: > > We should distinguish between user processes and root processes > > somehow, too. A user shouldn't be able to make root's processes die > > unless the machine is explictly configured for that to be possible > > Simple. sysctl variable for whether or not a user process can set SIG_HOLD. That seems rather a rather blunt method. Some important processes might be run non-root for security, for example. How reasonable would it be to add something to login.conf(5)? -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 14:32:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05495 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 14:32:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05431 for ; Wed, 29 Apr 1998 14:32:23 -0700 (PDT) (envelope-from conrad@apple.com) Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA30248; Wed, 29 Apr 1998 14:26:54 -0700 Received: from [17.202.43.185] (wa.apple.com [17.202.43.185]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id OAA24628; Wed, 29 Apr 1998 14:26:52 -0700 X-Sender: conrad@mail.apple.com Message-Id: In-Reply-To: <10533.893883442@time.cdrom.com> References: "Your message of Wed, 29 Apr 1998 12:23:09 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Apr 1998 14:26:49 -0700 To: "Jordan K. Hubbard" From: Conrad Minshall Subject: Re: SIGDANGER Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:57 PM -0700 4/29/98, Jordan K. Hubbard wrote: >> This talk of SIGDANGER takes me back, way back. Long ago (circa '85) I >> worked for IBM on an operating system for a box called the RT PC. AIX was >> the OS, and yes, a young programmer (me) added SIGDANGER to it. > >So you're one of those evil AIX people who helped kill the ACIS port, >the only REAL operating system for the PC RT? :-) :-) > > Jordan [I liked the RT - I had two of them, both > running *ACIS* :) ] Not exactly. In 1986 I moved from Austin to Palo Alto to work for ACIS on 4.2 and 4.3 BSD kernel and drivers. For a while. But then AIX absorbed the Palo Alto group and ACIS died. In 1991 I joined Apple to work on A/UX. To my surprise AIX followed me to Apple too. Now I'm on Rhapsody and I doubt AIX will follow me again :-) -- Conrad Minshall mailto:conrad@apple.com If "conrad@apple.com" doesn't work, try using rad@acm.org. Picon viewable at: http://facesaver.usenix.org/faces/h/49/4974.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 14:43:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08217 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 14:43:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08110 for ; Wed, 29 Apr 1998 14:43:14 -0700 (PDT) (envelope-from conrad@apple.com) Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id OAA17256; Wed, 29 Apr 1998 14:31:52 -0700 Received: from [17.202.43.185] (wa.apple.com [17.202.43.185]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id OAA22176; Wed, 29 Apr 1998 14:31:51 -0700 X-Sender: conrad@mail.apple.com Message-Id: In-Reply-To: <19980429150055.A17639@emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Apr 1998 14:31:49 -0700 To: Dan Nelson From: Conrad Minshall Subject: Re: how to fseek past 2GB? Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:00 PM -0700 4/29/98, Dan Nelson wrote: >I recently noticed that there is no way to fseek() past the 2GB mark on >files opened with fopen(). The offset in the FILE struct is an fpos_t; >there's just no way to get at it. > >fseek(), unfortunately, is cursed with a "long" file offset, so that >can't change. [...] >Is there a "standard" function name for a fseek() function that takes >an off_t or fpos_t? Yes, and the name is "fseeko". The "Large File Summit" standard includes it and everything else for 64 bit file offsets. X/Open (now Open Group) adopted the standard into Unix98 (officially called Single Unix Specification, Version 2) Search Unix98 at: http://www.opengroup.org/onlinepubs/7908799/index.html or see the much more readable book "Go Solo 2", chapter 15, "Large File Support". -- Conrad Minshall mailto:conrad@apple.com If "conrad@apple.com" doesn't work, try using rad@acm.org. Picon viewable at: http://facesaver.usenix.org/faces/h/49/4974.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 14:46:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08761 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 14:46:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08615 for ; Wed, 29 Apr 1998 14:45:27 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id RAA76450 for ; Wed, 29 Apr 1998 17:45:16 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: References: <199804290208.TAA07145@usr01.primenet.com> Date: Wed, 29 Apr 1998 17:48:38 -0400 To: freebsd-hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: SIGDANGER Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:23 PM -0700 4/29/98, Conrad Minshall wrote: > Terry: > > If the guy with the highest working set has a SIGDANGER (I prefer > > naming like SIGLOWMEM or something more descriptive of what the > > signal actually indicates) handler registered, and pages do not > > become available, then shoot the next highest working set guy, > > and so on. > > SIGLOSWAP then?. I chose SIGDANGER as I thought there might be a more > general purpose use than just for critical lack of paging space. The > generalized SIGDANGER was intended to mean "The system is in danger of > crashing very soon. Processes, consider yourself warned." If what we're implementing is basically the same as AIX's SIGDANGER, then I'd just as soon call it SIGDANGER. Some of the things I write need to run on multiple operating systems (including AIX), and it'd be nice if intelligently-written freebsd programs would just happen to do the same things when ported to another system which supports those things. [of course, the first question is whether freebsd ends up with something which really is about the same as SIGDANGER. If we end up which works differently, then it'd be better to use a different name for it] --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 15:09:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14891 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 15:09:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14847 for ; Wed, 29 Apr 1998 15:09:11 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ([139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IWH1VPF5IO0009WP@gatekeeper.alcatel.com.au> for freebsd-hackers@freebsd.org; Thu, 30 Apr 1998 08:08:30 +1000 Received: from cbd.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #U2695) with ESMTP id <01IWH1VAE8DSDDZQSJ@cim.alcatel.com.au>; Thu, 30 Apr 1998 08:08:10 +1000 Received: from gsms01.alcatel.com.au by cbd.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IWH1VKR48WAZTUBE@cbd.alcatel.com.au>; Thu, 30 Apr 1998 08:08:25 +1100 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id IAA14676; Thu, 30 Apr 1998 08:08:22 +1000 (EST) Date: Thu, 30 Apr 1998 08:08:22 +1000 (EST) From: Peter Jeremy Subject: Using BDM from FreeBSD To: ColdFire@WildRice.com, freebsd-hackers@FreeBSD.ORG Message-id: <199804292208.IAA14676@gsms01.alcatel.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Followups: Please note cross posting] Gunter Magin has developed a set of patches to gdb 4.13 and 4.16 to allow it to talk to a BDM (Motorola CPU32 embedded debug) interface (ftp://ftp.lpr.e-technik.tu-muenchen.de/pub/bdm/gdb-4.16-bdm-patches.tgz). This includes a BDM parallel port device driver for Linux. Has anyone looked at porting this driver to FreeBSD? (I realise it could also be done from user-mode, but haven't studied it to see if this is practical). Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 15:48:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24602 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 15:48:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24527; Wed, 29 Apr 1998 15:47:27 -0700 (PDT) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.8/8.8.8) with ESMTP id AAA07396; Thu, 30 Apr 1998 00:45:54 +0200 (MET DST) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.8.8/8.6.9) id AAA01597; Thu, 30 Apr 1998 00:29:55 +0200 (CEST) X-Face: " Date: Thu, 30 Apr 1998 00:29:54 +0200 From: Stefan Esser To: Warner Losh , Mark Murray Cc: hackers@FreeBSD.ORG, Stefan Esser Subject: Re: ctm question Mail-Followup-To: Warner Losh , Mark Murray , hackers@FreeBSD.ORG, Stefan Esser References: <199804280603.IAA19498@greenpeace.grondar.za> <199804280606.AAA01869@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199804280606.AAA01869@harmony.village.org>; from Warner Losh on Tue, Apr 28, 1998 at 12:06:16AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1998-04-28 00:06 -0600, Warner Losh wrote: > In message <199804280603.IAA19498@greenpeace.grondar.za> Mark Murray writes: > : You are SOL. A partially applied CTM delta breaks everything :-( > > I'm thinking about hacking ctm to have a mode that ignores the delta > if the md5 already matches the new md5 in the ctm package. That way > if there is a mismatch with the old one, it will try to apply it, keep > quiet about the ones that are up to date and whine (but not die) if > there is one that doesn't match either of the md5's. This would let > me recover from 95% of the partially applied CTM delta problems I've > run into over the years. It would at least let me KNOW what is > corrupted and take whatever action I need to to recover. > > I've not even looked at the code, nor at the ctmmd5 stuff that chuck > pointed me at. Would there be any interest in this? > > Warner Well, I already implemented this, a long time ago ... I had the same problem of a partially applied delta some time last year, and decided to make ctm check both the pre and post MD5 for a possible match. Don't remember, whether the "force" option is required for this feature, haven't needed it for quite some time :) Please check out the following patch: Index: /usr/src/usr.sbin/ctm/ctm/ctm_pass2.c =================================================================== RCS file: /usr/cvs/src/usr.sbin/ctm/ctm/ctm_pass2.c,v retrieving revision 1.16 diff -r1.16 ctm_pass2.c 157c157,163 < if(j & CTM_Q_MD5_Force) { --- > GETFIELDCOPY(md5,sep); > if(md5 != NULL && strcmp(tmp,md5) == 0) { > fprintf(stderr," %s: %s already applied.\n", > sp->Key,name); > match = CTM_FILTER_DISABLE; > /* ret |= Exit_Forcible; /* XXX Testing Only */ > } else if(j & CTM_Q_MD5_Force) { 168,170c174,177 < } < if(j & CTM_Q_MD5_After) { < GETFIELDCOPY(md5,sep); --- > } else if(j & CTM_Q_MD5_After) { > if(md5 == NULL) { > GETFIELDCOPY(md5,sep); > } Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 15:52:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25603 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 15:52:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25375 for ; Wed, 29 Apr 1998 15:51:16 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id OAA00711; Wed, 29 Apr 1998 14:46:37 -0700 (PDT) Message-Id: <199804292146.OAA00711@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Snob Art Genre cc: "Jordan K. Hubbard" , Conrad Minshall , freebsd-hackers@FreeBSD.ORG, Terry Lambert Subject: Re: SIGDANGER In-reply-to: Your message of "Wed, 29 Apr 1998 17:13:55 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Apr 1998 14:46:36 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Since I was 7 years old at the time, could someone please tell me what a > PC RT is, and for that matter what color is an ACIS? ;-) The PC/RT redefined the terms "big" and "heavy" in the personal computing world. It also featured IBM's first RISC processor (the ROMP, if I remember correctly). I bought one for $90 hoping to salvage some parts; I think I ended up with a jar of screws and some very strange ISA boards. I certainly couldn't boot it. 8) As for colour, that's no challenge. ACIS would have been green or orange onscreen, and grey, beige, maroon or blue in the box on the shelf. > On Wed, 29 Apr 1998, Jordan K. Hubbard wrote: > > > > This talk of SIGDANGER takes me back, way back. Long ago (circa '85) I > > > worked for IBM on an operating system for a box called the RT PC. AIX was > > > the OS, and yes, a young programmer (me) added SIGDANGER to it. > > > > So you're one of those evil AIX people who helped kill the ACIS port, > > the only REAL operating system for the PC RT? :-) :-) > > > > Jordan [I liked the RT - I had two of them, both > > running *ACIS* :) ] > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > Ben > > "You have your mind on computers, it seems." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 16:14:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01178 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 16:14:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01024 for ; Wed, 29 Apr 1998 16:13:57 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id PAA00789; Wed, 29 Apr 1998 15:10:20 -0700 (PDT) Message-Id: <199804292210.PAA00789@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Glenn Johnson cc: hackers@FreeBSD.ORG Subject: Re: debugging In-reply-to: Your message of "Wed, 29 Apr 1998 15:19:38 CDT." <199804292019.PAA03017@symbion.srrc.usda.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Apr 1998 15:10:20 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have some Fortran programs that compile and run fine using f77 (f2c/cc). If > I compile the code with g77 I get significantly better performance but some of > the programs will give the following message upon completion: > > free(): warning: modified (page-) pointer This is indicative of misbehaviour on the part of the program in question. Are you reasonably certain that your program doesn't suffer from any off-by-one errors in array indexing, etc.? > I get the correct results from the programs but I am concerned. How serious of > a problem is this? Am I correct in assuming that g77 is optimizing the code in > a way that is exposing a bug in the program code? Since using gdb on g77 > compiled code is less than ideal, does anyone have an idea on how to go about > finding info on the problem(s)? The problem is moderately serious in that it indicates that at least part of the program is performing incorrectly. It is difficult to know whether the true problem lies in the Fortran code and is merely being revealed by the different compiler, or whether it is intrinsic to g77. > I am not a skilled programmer but I would like to be able to provide > information to the program developers. The malloc warning does not occur under > Linux/g77 and so they may not be aware of any underlying bug(s). Thanks in > advance for your help. The warning comes from the FreeBSD user-space memory manager, which is much more observant of this sort of behaviour than the Linux equivalent. You might want to try setting some of the extra-touchy malloc options (see the malloc(3) manpage) to see if you can force the program to coredump when the corruption happens. This may in turn lead you closer to the source of the problem. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 16:48:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07961 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 16:48:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07828 for ; Wed, 29 Apr 1998 16:47:46 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id JAA23350; Thu, 30 Apr 1998 09:49:17 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199804292349.JAA23350@cimlogic.com.au> Subject: Re: SIGDANGER In-Reply-To: from Snob Art Genre at "Apr 29, 98 05:13:55 pm" To: benedict@echonyc.com (Snob Art Genre) Date: Thu, 30 Apr 1998 09:49:16 +1000 (EST) Cc: jkh@time.cdrom.com, conrad@apple.com, freebsd-hackers@FreeBSD.ORG, tlambert@primenet.com 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Snob Art Genre wrote: > Since I was 7 years old at the time, could someone please tell me what a > PC RT is, and for that matter what color is an ACIS? ;-) It looked (looks, I still have a client with one 8-) like an IBM PC and runs about as slow as one. People would be heard to ask: "Is it actually doing _anything_?!". I think that SIGDANGER was actually intended as a "Warning Will Robinson, you'll put your back out if you lift this". The idea being to prevent little people (like me) from attempting to do things that they'll regret, like trying to find out if it _was_ doing anything - which it usually was. The problem they had was getting the SIGDANGER signal out of the box with adequate warning to the guy with the screw driver. This was before computers could talk. So they discontinued production to reduce the work health insurance claims. 8-) -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 19:43:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA12321 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 19:43:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA12265 for ; Wed, 29 Apr 1998 19:43:29 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.8.8/8.6.9) with ESMTP id EAA17494 for ; Thu, 30 Apr 1998 04:43:55 +0200 (CEST) Message-Id: <199804300243.EAA17494@peedub.muc.de> X-Mailer: exmh version 2.0.1 12/23/97 To: freebsd-hackers@freefall.FreeBSD.org Subject: Re: SIGDANGER Reply-To: Gary Jennejohn In-reply-to: Your message of "Wed, 29 Apr 1998 14:26:49 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Apr 1998 04:43:54 +0200 From: Gary Jennejohn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Conrad Minshall writes: >At 1:57 PM -0700 4/29/98, Jordan K. Hubbard wrote: >>So you're one of those evil AIX people who helped kill the ACIS port, >>the only REAL operating system for the PC RT? :-) :-) >> >> Jordan [I liked the RT - I had two of them, both >> running *ACIS* :) ] > >Not exactly. In 1986 I moved from Austin to Palo Alto to work for ACIS on >4.2 and 4.3 BSD kernel and drivers. For a while. But then AIX absorbed >the Palo Alto group and ACIS died. In 1991 I joined Apple to work on A/UX. > Really ? 1991 ? A/UX was still alive then ? That was many years after UniSoft did the original port. I always thought that A/UX died a rapid death due to lack of interest on Apple's part. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 19:56:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA14473 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 19:56:26 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA14245 for ; Wed, 29 Apr 1998 19:55:03 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id WAA18988 for ; Wed, 29 Apr 1998 22:54:59 -0400 (EDT) Date: Wed, 29 Apr 1998 22:54:59 -0400 (EDT) From: "Matthew N. Dodd" To: hackers@FreeBSD.ORG Subject: Compaq RAID Array Drivers? (IDA-2) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I seem to remember something about un-commitable drivers for the Compaq RAID array controllers Anyone remember where those were? /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 21:46:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA01741 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 21:46:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA01727 for ; Wed, 29 Apr 1998 21:46:17 -0700 (PDT) (envelope-from justin@lilith.apple.com) Received: from scv2.apple.com (A17-128-100-140.apple.com [17.128.100.140]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id VAA30534; Wed, 29 Apr 1998 21:41:43 -0700 Received: from lilith.apple.com (lilith.apple.com [17.202.41.78]) by scv2.apple.com (8.8.5/8.8.5) with ESMTP id VAA14520; Wed, 29 Apr 1998 21:41:42 -0700 Received: (justin@localhost) by lilith.apple.com (8.6.9/A/UX 3.1) id VAA25933; Wed, 29 Apr 1998 21:41:49 -0700 Date: Wed, 29 Apr 1998 21:41:49 -0700 From: "Justin C. Walker" Message-Id: <199804300441.VAA25933@lilith.apple.com> To: garyj@muc.de CC: freebsd-hackers@freefall.FreeBSD.org In-reply-to: Gary Jennejohn's message of Thu, 30 Apr 1998 04:43:54 +0200 <199804300243.EAA17494@peedub.muc.de> Subject: Re: SIGDANGER Reply-to: justin@apple.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG /* * Really ? 1991 ? A/UX was still alive then ? That was many years after * UniSoft did the original port. I always thought that A/UX died a rapid * death due to lack of interest on Apple's part. */ Hardly. A/UX lived through 1994 and release 3.1.1. The last real release was the "Workgroup Server 95" on Quadra 950's, with special hardware additions. I actually still use it daily, for mail and the like. There was interest inside and out of Apple, but it never really got to critical mass. Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple CoreOS Networking | of boredom Apple Computer, Inc. | For trying to change the system 2 Infinite Loop | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 22:00:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA03397 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 22:00:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zeus.carroll.com (zeus.carroll.com [199.224.10.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA03363 for ; Wed, 29 Apr 1998 22:00:05 -0700 (PDT) (envelope-from jim@carroll.com) Received: from apollo.carroll.com [199.224.10.3] by zeus.carroll.com with ESMTP (8.8.5/0) id AAA16585; Thu, 30 Apr 1998 00:59:58 -0400 Received: by apollo.carroll.com (8.8.5) is AAA14628; Thu, 30 Apr 1998 00:59:58 -0400 Date: Thu, 30 Apr 1998 00:59:58 -0400 From: Jim Carroll To: freebsd-hackers@FreeBSD.ORG Subject: BOOT_FORCE_COMCONSOLE trouble Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We have compiled a bootloader BOOT_FORCE_COMCONSOLE to work at remote locations where we do not keep moitors and keyboards. Most of the time, we do not have a serial console connected to this machine. Any applications that attempt to write to the serial console get caught in a wait state until we either slay them, or connect our serial console. I know we have missed something basic. Can someone point me in the right direction of where to look ? Thanks --- Jim C., President | C A R R O L L - N E T, Inc. 201-488-1332 | New Jersey's Premier Internet Service Provider www.carroll.com | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 22:56:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11845 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 22:56:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from clifford.inch.com (omar@clifford.inch.com [207.240.140.163]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11797; Wed, 29 Apr 1998 22:55:48 -0700 (PDT) (envelope-from omar@clifford.inch.com) Received: (from omar@localhost) by clifford.inch.com (8.8.5/8.8.5) id BAA31748; Thu, 30 Apr 1998 01:47:43 -0400 Message-ID: <19980430014743.28030@clifford.inch.com> Date: Thu, 30 Apr 1998 01:47:43 -0400 From: Omar Thameen To: freebsd-hackers@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Subject: login.conf and "daemon" class Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There's a comment before the default "daemon" class in login.conf which indicates that the settings are used by /etc/rc. We recently came up against the filesize limitation in an unexpected way. We were trying to copy large files from one machine to another using ssh. Apparently, since sshd is started by a script in /usr/local/etc/rc.d/, which is invoked by /etc/rc, the class "daemon" limitations were implemented. Thus, we were only able to copy 64M of the files over. This has also affected a script I was running out of cron - a glimpse indexing that was dying because of a malloc failure. I traced this to the same login.conf situation because when I killed and restarted cron as root (rather than having it restarted from /etc/rc), the script ran fine. Now /etc/rc.local is also called from /etc/rc, so I assume the same class "daemon" restrictions apply - is this correct? If so, this is a critical piece of information for everyone running servers because, for example, we start a heavily hit mysqld out of rc.local, and despite any customized settings we have for the user running it, it would be bound by the "daemon" class until we killed it and restarted it as another user. Finally, while we're on the subject of login.conf, is there anywhere with a layman's explanation of all the parameters? If not, could someone put one together? I've read the man pages, but can't glean from them what real world situation many of the parameters would apply to. Some like "filesize" are self-explanatory, but if you're not a programmer, you don't know how to relate the errors you get to "datasize" and "stacksize". E.g., to figure out which setting was giving me the malloc failure, I would have to do trial and error. Thanks for any comments. Omar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 23:03:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13173 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 23:03:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA13165 for ; Wed, 29 Apr 1998 23:03:18 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yUm1t-0000Zw-00; Wed, 29 Apr 1998 22:37:09 -0700 Date: Wed, 29 Apr 1998 22:37:08 -0700 (PDT) From: Tom To: Jim Carroll cc: freebsd-hackers@FreeBSD.ORG Subject: Re: BOOT_FORCE_COMCONSOLE trouble In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 30 Apr 1998, Jim Carroll wrote: > We have compiled a bootloader BOOT_FORCE_COMCONSOLE to work at remote > locations where we do not keep moitors and keyboards. Most of the time, we BOOT_FORCE_COMCONSOLE is obsolete now that we have boot.config I use the stock boot loader with "-h -D" in boot.config and it works perfectly. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 29 23:09:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13862 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 23:09:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles358.castles.com [208.214.167.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA13850 for ; Wed, 29 Apr 1998 23:09:11 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA00506; Wed, 29 Apr 1998 22:04:39 -0700 (PDT) Message-Id: <199804300504.WAA00506@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Peter Jeremy cc: ColdFire@WildRice.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Using BDM from FreeBSD In-reply-to: Your message of "Thu, 30 Apr 1998 08:08:22 +1000." <199804292208.IAA14676@gsms01.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Apr 1998 22:04:38 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [Followups: Please note cross posting] > > Gunter Magin has developed a set > of patches to gdb 4.13 and 4.16 to allow it to talk to a BDM (Motorola > CPU32 embedded debug) interface > (ftp://ftp.lpr.e-technik.tu-muenchen.de/pub/bdm/gdb-4.16-bdm-patches.tgz). > This includes a BDM parallel port device driver for Linux. > > Has anyone looked at porting this driver to FreeBSD? (I realise it > could also be done from user-mode, but haven't studied it to see if > this is practical). Under -current this would be trivial; see the ppi(4) manpage for geek-port access to the parallel port. The next set of updates to the ppbus code add a programmable port microsequencer to the driver, which would let you write a trivial in-kernel BDM driver that would be a lot faster. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 00:29:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA24881 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 00:29:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from golem.belabm.by (root@golem.belabm.by [194.226.122.185]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA24595 for ; Thu, 30 Apr 1998 00:26:51 -0700 (PDT) (envelope-from scaner@belabm.by) Received: from belabm.by ([194.226.122.183]) by golem.belabm.by (8.8.7/8.8.4) with ESMTP id KAA03281; Thu, 30 Apr 1998 10:24:07 +0300 Message-ID: <3548267B.E527D8F1@belabm.by> Date: Thu, 30 Apr 1998 10:21:31 +0300 From: Eugene Vedistchev Reply-To: scaner@belabm.by Organization: Global One in Belarus X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: "Matthew N. Dodd" CC: hackers@FreeBSD.ORG Subject: Re: Compaq RAID Array Drivers? (IDA-2) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Look at : http://www.dcs.qmw.ac.uk/~md/ida/ Matthew N. Dodd wrote: > > I seem to remember something about un-commitable drivers for the Compaq > RAID array controllers > > Anyone remember where those were? > > /* > Matthew N. Dodd | A memory retaining a love you had for life > winter@jurai.net | As cruel as it seems nothing ever seems to > http://www.jurai.net/~winter | go right - FLA M 3.1:53 > */ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 00:54:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA27468 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 00:54:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA27449 for ; Thu, 30 Apr 1998 00:54:16 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id AAA24372; Thu, 30 Apr 1998 00:54:10 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd024313; Thu Apr 30 00:54:00 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id AAA00308; Thu, 30 Apr 1998 00:53:59 -0700 (MST) From: Terry Lambert Message-Id: <199804300753.AAA00308@usr05.primenet.com> Subject: Re: how to fseek past 2GB? To: dnelson@emsphone.com (Dan Nelson) Date: Thu, 30 Apr 1998 07:53:58 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19980429150055.A17639@emsphone.com> from "Dan Nelson" at Apr 29, 98 03:00:55 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I recently noticed that there is no way to fseek() past the 2GB mark on > files opened with fopen(). The offset in the FILE struct is an fpos_t; > there's just no way to get at it. Heh. ... fseek( fp, 1<<30, SEEK_SET); /* first 2G*/ fseek( fp, 1<<30, SEEK_CUR); /* next 2G*/ fseek( fp, 1, SEEK_END); /* last byte*/ ... It'd be easy to wrap this. 8-). For a more FreeBSD-specific workaround: off_t lfseek( FILE *fp, off_t offset, int whence) { off_t new; fp->_flags &= ~__SOFF; /* invalidate offset cache*/ new = lseek( fileno(fp), offset, whence); fseek( fp, 0, SEEK_CUR); return( new); } On your patches: I think there are standard names for the functions you implemented, so they should probably be rolled in. But the workarounds should work for 2.2.6 people. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 06:18:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA08456 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 06:18:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from assurance (assurance.rstcorp.com [206.29.49.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA08044 for ; Thu, 30 Apr 1998 06:17:20 -0700 (PDT) (envelope-from vshah@rstcorp.com) Received: (from uucp@localhost) by assurance (8.7.5/8.6.9) id JAA28778; Thu, 30 Apr 1998 09:16:11 -0400 Received: from sandbox.rstcorp.com(206.29.49.63) by assurance.rstcorp.com via smap (V2.0) id xma028772; Thu, 30 Apr 98 09:16:04 -0400 Received: from fault.rstcorp.com (fault [206.29.49.18]) by sandbox.rstcorp.com (8.8.8/8.8.8) with ESMTP id JAA19356; Thu, 30 Apr 1998 09:16:41 -0400 (EDT) Received: (from vshah@localhost) by fault.rstcorp.com (8.8.8/8.8.8) id JAA07325; Thu, 30 Apr 1998 09:15:57 -0400 (EDT) Date: Thu, 30 Apr 1998 09:15:57 -0400 (EDT) Message-Id: <199804301315.JAA07325@fault.rstcorp.com> From: "Viren R. Shah" To: "Matthew N. Dodd" Cc: hackers@FreeBSD.ORG Subject: Re:Compaq RAID Array Drivers? (IDA-2) In-Reply-To: References: X-Mailer: VM 6.40 under 19.16 "Lille" XEmacs Lucid Reply-To: "Viren R. Shah" X-Face: )~y+U*K:yzjz{q<5lzpI_SVef'U.])9g[C9`1N@]u3,MHY7f*l7C)[_NjM4y4K8$uIUh|\u (K&&HS6,M!61&GMTk'mqmB/Qg]]X}"?TzsFl]"2v!bl8']dma.:^IY^a[lbOI>U:b<~FyK3q-p{HmZ mn~g.`~BE!5{2D:}Yi+\_KkWe?XaHj9$ko1k8iKLYv5*_2c8"G=?Up[}hn+7RNM(bzBZ_wWk6!Pf&B ?3Tcm7M7B~W%K/I0aX3]*=jP?aM]H6HBPT`oLk+0n^_;N\2\%|Rhy;p}34Q.jEsM\qtnxcm;ag%Nq Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Matthew" == Matthew N Dodd writes: Matthew> I seem to remember something about un-commitable drivers for Matthew> the Compaq RAID array controllers Go to http://www.doc.ic.ac.uk/~md/ There are drivers for 2.2.5 and 2.2.6. The driver can also be made to work with -current. Matthew> Anyone remember where those were? Viren -- Viren R. Shah "I'm in love with you" "Now that's a ridiculous thing to go and say." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 06:32:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA09980 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 06:32:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA09964 for ; Thu, 30 Apr 1998 06:32:16 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Thu Apr 30 08:32 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id IAA10435 for ; Thu, 30 Apr 1998 08:32:02 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Thu, 30 Apr 1998 09:31:55 -0400 Message-ID: To: grog@lemis.com, hans@artcom.de, NguyenHM@ucarb.com Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: Ethernet address takeover implementation proposal Date: Thu, 30 Apr 1998 09:31:52 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ---------- > From: Nguyen HM (Mike)[SMTP:NguyenHM@ucarb.com] > > This approach, of using an IP address, would save you the hassle of > reprogramming the hardware address of an ethernet controller, as well > as allow you to use whatever networking tech. you want. > ServiceGuard does a quite simple thing for Ethernet: after moving the alias (package address) to another interface it sends out a broadcast ARP response packet that causes all the machines on the network to refresh the ARP cache with values from this packet. Actually, a while ago I have implemented a simple link-level protocol for FreeBSD that does allow to do the same easily. It was written for 2.0.5 but if someone does need it (and/or if the core team members will consider the idea appropriate) I can find it in my archives and port to -current. Personally, I think that adding the link-level protocol (if not this then some other) is a Good Thing (tm). -Serge P.S. Does somebody need the loopback pseudo-Ethernet driver ? It's the thing that allows to make network connections from pcemu, and is also very useful for debugging the network code without having a real network (like I do at home). Probably the network support can also be added to doscmd. I have submitted it a while (~1.5 years) ago but it was not committed at this time although the patches for pcemu were. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 09:24:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA02610 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 09:24:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from schubert.promo.de (schubert.Promo.DE [194.45.188.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA02480 for ; Thu, 30 Apr 1998 09:23:49 -0700 (PDT) (envelope-from stefan@promo.de) Received: from stefan.promo.de (stefan.Promo.DE [194.45.188.81]) by schubert.promo.de (8.8.8/8.8.8) with SMTP id SAA20829; Thu, 30 Apr 1998 18:20:41 +0200 (MET DST) Date: Thu, 30 Apr 1998 18:22:30 +0200 From: "Stefan Bethke" To: sbabkin@dcn.att.com cc: freebsd-hackers@FreeBSD.ORG Subject: RE: pseudo-Ethernet driver (was Ethernet address takeover...) Message-ID: <34544.3102949350@stefan.promo.de> X-Mailer: Mulberry Demo (MacOS) [1.4.0a3, s/n Evaluation] X-Licensed-To: Unlicensed - for evaluation only MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --On Don, 30. Apr 1998 9:31 Uhr -0400 sbabkin@dcn.att.com wrote: > P.S. Does somebody need the loopback pseudo-Ethernet driver ? It's the > thing that allows to make network connections from pcemu, and is > also very useful for debugging the network code without having a > real network (like I do at home). Probably the network support can also > be added to doscmd. I have submitted it a while (~1.5 years) ago > but it was not committed at this time although the patches for pcemu > were. Yes, please. This is also very helpful for netatalk, because you need at least two interfaces (besides lo) to have certain network options at all. -- Stefan Bethke Promo Datentechnik | Tel. +49-40-851744-18 + Systemberatung GmbH | Fax. +49-40-851744-44 Eduardstrasse 46-48 | e-mail: stefan@Promo.DE D-20257 Hamburg | http://www.Promo.DE/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 09:50:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07695 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 09:50:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from arjun.niksun.com (gw.niksun.com [206.20.52.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07683 for ; Thu, 30 Apr 1998 09:50:44 -0700 (PDT) (envelope-from ath@niksun.com) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.8.8/8.8.7) with ESMTP id MAA04283 for ; Thu, 30 Apr 1998 12:46:43 -0400 (EDT) (envelope-from ath@stiegl.niksun.com) Received: from stiegl.niksun.com (localhost.niksun.com [127.0.0.1]) by stiegl.niksun.com (8.8.7/8.8.7) with ESMTP id MAA11357 for ; Thu, 30 Apr 1998 12:50:41 -0400 (EDT) (envelope-from ath@stiegl.niksun.com) Message-Id: <199804301650.MAA11357@stiegl.niksun.com> X-Mailer: exmh version 2.0zeta 7/24/97 From: Andrew Heybey To: freebsd-hackers@FreeBSD.ORG Subject: compactPCI Date: Thu, 30 Apr 1998 12:50:36 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Hope this is appropriate for -hackers. I thought that compactPCI might be too esoteric for -questions.] Has anyone run FreeBSD on a compactPCI system? I would like to build a box with many boards in it, and compactPCI systems seem to be available with many slots. Are there CPU modules available that look enough like a regular PC that FreeBSD would run? Is there some way that compactPCI doesn't look to the software like a "normal" PCI bus? The compactPCI spec says it is electrically compatible which would imply (to me) that it looks the same to the software as well. thanks, andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 10:21:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12878 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 10:21:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA12821 for ; Thu, 30 Apr 1998 10:21:41 -0700 (PDT) (envelope-from lada@pc8811.gud.siemens.at) Received: from pc8811.gud.siemens.at (root@firix [10.1.143.100]) by zwei.siemens.at with ESMTP id TAA10932 for ; Thu, 30 Apr 1998 19:21:08 +0200 (MET DST) Received: from pc8811.gud.siemens.at (pc8811.gud.siemens.co.at [195.3.22.159]) by pc8811.gud.siemens.at (8.8.8/8.8.8) with ESMTP id TAA29836; Thu, 30 Apr 1998 19:22:22 +0200 (CEST) (envelope-from lada@pc8811.gud.siemens.at) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.2.p0.FreeBSD:980430192222:29823=_" Date: Thu, 30 Apr 1998 19:22:22 +0200 (CEST) Organization: Siemens Austria AG From: Marino Ladavac To: hackers@FreeBSD.ORG Subject: ptread library patch Cc: lada@pc8811.gud.siemens.co.at Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.2.p0.FreeBSD:980430192222:29823=_ Content-Type: text/plain; charset=us-ascii A smallish patch concerning the priority boost for inactive runnable threads is attached. a PR has been submitted. /Marino ---------------------------------- Marino Ladavac Date: 30-Apr-98 Time: 19:19:57 ---------------------------------- --_=XFMail.1.2.p0.FreeBSD:980430192222:29823=_ Content-Disposition: attachment; filename="diff" Content-Transfer-Encoding: 7bit Content-Description: diff Content-Type: text/plain; charset=us-ascii; name=diff; SizeOnDisk=427 --- uthread_kern.c 1998/04/30 16:31:53 1.1 +++ uthread_kern.c 1998/04/30 16:34:33 @@ -349,7 +349,7 @@ * the last incremental priority check was * made: */ - else if (timercmp(&_thread_run->last_inactive, &kern_inc_prio_time, >)) { + else if (timercmp(&_thread_run->last_inactive, &kern_inc_prio_time, <)) { /* * Increment the incremental priority * for this thread in the hope that --_=XFMail.1.2.p0.FreeBSD:980430192222:29823=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 11:12:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20893 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 11:12:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20853 for ; Thu, 30 Apr 1998 11:12:14 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA00477; Thu, 30 Apr 1998 10:08:48 -0700 (PDT) Message-Id: <199804301708.KAA00477@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Andrew Heybey cc: freebsd-hackers@FreeBSD.ORG Subject: Re: compactPCI In-reply-to: Your message of "Thu, 30 Apr 1998 12:50:36 EDT." <199804301650.MAA11357@stiegl.niksun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Apr 1998 10:08:48 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [Hope this is appropriate for -hackers. I thought that compactPCI might be > too esoteric for -questions.] > > Has anyone run FreeBSD on a compactPCI system? I would like to build a box > with many boards in it, and compactPCI systems seem to be available with many > slots. I've heard from people running FreeBSD on CPCI systems. > Are there CPU modules available that look enough like a regular PC that FreeBSD > would run? Is there some way that compactPCI doesn't look to the software like > a "normal" PCI bus? The compactPCI spec says it is electrically compatible > which would imply (to me) that it looks the same to the software as well. The general consensus was that while some CPCI vendors put some weird stuff on their boards, most things work OK. You might want to be a little careful about things like ethernet adapters &c. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 11:36:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25285 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 11:36:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA25235 for ; Thu, 30 Apr 1998 11:36:30 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id OAA16408 for ; Thu, 30 Apr 1998 14:36:27 -0400 (EDT) Date: Thu, 30 Apr 1998 14:36:27 -0400 (EDT) From: Snob Art Genre To: hackers@FreeBSD.ORG Subject: odd network problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm having a network problem that only manifests between two FreeBSD-stable machines. I posted about this on questions, but got no answer, and I think it might be over the collective questions head anyway. I have two machines, float and ben. Float is dialed up PPP to interport, ben is on a T1 from Sprint. I can ping and traceroute either machine from the other one, but I cannot use TCP-based services. The TCP handshake completes, and then the connection hangs. For example, if I'm trying to telnet to float from ben, the handshake happens, and then ben sends the same 27-byte packet for several minutes until it gives up. Meanwhile, telnet/ftp/ssh all work fine from a Solaris/SPARC box and from a Linux box, to or from float or ben. Packet traces available upon request, of course. Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 11:55:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27487 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 11:55:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA27478 for ; Thu, 30 Apr 1998 11:55:18 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Thu Apr 30 13:55 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id NAA03698 for ; Thu, 30 Apr 1998 13:55:10 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Thu, 30 Apr 1998 14:55:03 -0400 Message-ID: To: klmac@baldcom.net Cc: hackers@FreeBSD.ORG Subject: RE: Ethernet address takeover implementation proposal Date: Thu, 30 Apr 1998 14:54:59 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ---------- > From: Ken McKittrick[SMTP:klmac@baldcom.net] > > The link-level protocol would go a ways towards the High Availability > project. I more intested in that area. > This is a short description of my implementation (as I remember it, I don't have it handy now to look up): The protocol implementation is send-only. BPF can be used for receiving. I think it's a lot simpler and more elegant way than inventing the second BPF-like interface. BPF already has enough power to filter out any subset of packets received through an interface. The protocol itself does not make any assumptions about the packet contents. It is just transferring the contents to the link level. Of course, the implementation has some link-level-specific parts to extract the link-level address from a packet and pass it to the lower level. Now only the Ethernet support if present. So, essentially it's almost a NOP. :-) Any suggestions/objections are welcome ! :-) Especially from the core team members :-) Besides sending out a broadcast ARP response, other possible usages of this thing include, for example, a slow and inefficient user-level Ethernet bridge with arbitrary firewall. -Serge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 12:40:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05897 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 12:40:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from loa.part.net ([209.160.89.206]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA05876 for ; Thu, 30 Apr 1998 12:40:40 -0700 (PDT) (envelope-from jlp@Part.NET) Received: from loa.part.net (localhost [127.0.0.1]) by loa.part.net (8.8.8/8.8.5) with ESMTP id NAA05443; Thu, 30 Apr 1998 13:40:33 -0600 (MDT) Message-Id: <199804301940.NAA05443@loa.part.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Snob Art Genre cc: hackers@FreeBSD.ORG Subject: Re: odd network problem X-face: p=61=y<.Il$z+k*y~"j>%c[8R~8{j3WTnaSd-'RyC>t.Ub>AAm\zYA#5JF +W=G?EI+|EI);]=fs_MOfKN0n9`OlmB[1^0;L^64K5][nOb&gv/n}p@mm06|J|WNa asp7mMEw0w)e_6T~7v-\]yHKvI^1}[2k)] References: In-reply-to: Your message of "Thu, 30 Apr 1998 14:36:27 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Apr 1998 13:40:33 -0600 From: "Jan L. Peterson" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have two machines, float and ben. Float is dialed up PPP to > interport, ben is on a T1 from Sprint. I can ping and traceroute either > machine from the other one, but I cannot use TCP-based services. The > TCP handshake completes, and then the connection hangs. For example, if > I'm trying to telnet to float from ben, the handshake happens, and then > ben sends the same 27-byte packet for several minutes until it gives up. I've seen this when dialing up to a xylogics annex. Turning off tcp_extensions in /etc/rc.conf solved it (actually, you only had to turn off one tcp_extension, but I can't remember which one :-). Check out /etc/rc.conf and /etc/rc.network. Good luck. -jan- -- Jan L. Peterson PartNET tel. +1 801 581 1118 Senior Systems Admin 423 Wakara Way, Suite 216 fax +1 801 581 1785 jlp@part.net Salt Lake City, UT 84108 http://www.part.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 12:48:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07041 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 12:48:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA06953 for ; Thu, 30 Apr 1998 12:48:26 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA22681; Thu, 30 Apr 1998 15:47:51 -0400 Date: Thu, 30 Apr 1998 15:47:51 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: freebsd-hackers@FreeBSD.ORG Subject: Re: compactPCI In-Reply-To: <199804301708.KAA00477@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Take a look at PICMG. compactpci is basically very pricey. PICMG is a passive backplane standard which looks to be much cheaper. We're looking at doing a cluster based on PICMG. Of course, if you have the dough to spare, check out altatech. ron Ron Minnich |Java: an operating-system-independent, rminnich@sarnoff.com |architecture-independent programming language (609)-734-3120 |for Windows/95 and Windows/NT on the Pentium ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 12:50:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07421 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 12:50:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA07261 for ; Thu, 30 Apr 1998 12:49:59 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yUyvr-0001D9-00; Thu, 30 Apr 1998 12:23:47 -0700 Date: Thu, 30 Apr 1998 12:23:45 -0700 (PDT) From: Tom To: Snob Art Genre cc: hackers@FreeBSD.ORG Subject: Re: odd network problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 30 Apr 1998, Snob Art Genre wrote: > I have two machines, float and ben. Float is dialed up PPP to > interport, ben is on a T1 from Sprint. I can ping and traceroute either > machine from the other one, but I cannot use TCP-based services. The > TCP handshake completes, and then the connection hangs. For example, if > I'm trying to telnet to float from ben, the handshake happens, and then > ben sends the same 27-byte packet for several minutes until it gives up. > > Meanwhile, telnet/ftp/ssh all work fine from a Solaris/SPARC box and > from a Linux box, to or from float or ben. TCP extensions. FreeBSD always uses them, and some broken routers screw packets with TCP extensions up (primarily some old crappy term serve that I can't remember right now). Most likely your PPP dialup is into one of those boxes. This is an old question. I'm sure it is in the FAQ. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 12:52:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07762 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 12:52:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA07733 for ; Thu, 30 Apr 1998 12:51:52 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA22689; Thu, 30 Apr 1998 15:51:21 -0400 Date: Thu, 30 Apr 1998 15:51:21 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@FreeBSD.ORG Subject: PICMG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG check out: http://www.bsicomputer.com/rackmount/bp/picmg.htm ron Ron Minnich |Java: an operating-system-independent, rminnich@sarnoff.com |architecture-independent programming language (609)-734-3120 |for Windows/95 and Windows/NT on the Pentium ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 13:00:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09713 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 13:00:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09440 for ; Thu, 30 Apr 1998 12:59:30 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id PAA10052; Thu, 30 Apr 1998 15:58:41 -0400 (EDT) Date: Thu, 30 Apr 1998 15:58:40 -0400 (EDT) From: Snob Art Genre To: "Jan L. Peterson" cc: hackers@FreeBSD.ORG Subject: Re: odd network problem In-Reply-To: <199804301940.NAA05443@loa.part.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 30 Apr 1998, Jan L. Peterson wrote: > I've seen this when dialing up to a xylogics annex. Turning off > tcp_extensions in /etc/rc.conf solved it (actually, you only had to > turn off one tcp_extension, but I can't remember which one :-). > > Check out /etc/rc.conf and /etc/rc.network. Good luck. Turning off RFC 1323 extensions did the trick. Thank you, you have saved my sanity. Now to call up my ISP and yell at them. Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 13:06:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10982 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 13:06:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from vorbis.noc.easynet.net (qmailr@vorbis.noc.easynet.net [195.40.1.254]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA10947 for ; Thu, 30 Apr 1998 13:06:09 -0700 (PDT) (envelope-from chrisy@vorbis.noc.easynet.net) Received: (qmail 3979 invoked by uid 1943); 30 Apr 1998 20:06:04 -0000 Message-ID: <19980430210604.09329@flix.net> Date: Thu, 30 Apr 1998 21:06:04 +0100 From: Chrisy Luke To: freebsd-hackers@FreeBSD.ORG Subject: Beta 3 release of Multipath routing and friends. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=akKZr9L6Hm6aLOcr X-Mailer: Mutt 0.88 Organization: The Flirble Internet Exchange X-URL: http://www.flix.net/ X-FTP: ftp://ftp.flirble.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --akKZr9L6Hm6aLOcr Content-Type: text/plain; charset=us-ascii Content-Description: Mail message ftp://ftp.flirble.org/pub/unix/hacks/FreeBSD/mpath.b3.tgz README attached. A few fixes to the Multipath code. The metric stuff and the persistant route caching will come in b4. This code mostly adds support to the ipfw interface and code to support two things, which are based on the same thing: * Directing INCOMING traffic that match rules to a LOCAL TCP port. This is intended for transparent proxying without external calls to a LKM, it also doesn't touch the packet, so getsockname() works so there's also no need for a subsequent IOCTL to work out what the original destination/port was. It's freaky seeing random remote IP's listed as "Local addresses" in netstat! BSD-router-speed transparent diversion... :-) * Modifying the next-hop address of OUTBOUND traffic that matches the rule. My intention for this is to direct web traffic from a core router to a transparent proxy. David Sharnoff also wanted something similar, and the functionality of this thus extends to doing a route table lookup on the specified next-hop and using the route to it, meaning the next-hop doesn't need to be on a directly reachable interface. Remember though, this code only forwards to a directly reachable machine! It doesn't deliver it to the specified next-hop! TCP port numbers are ignored if this rule comes into affect. The rule-based forwarding mechanism is independant of the Multipath stuff, but does have multipath code in it if multipath is compiled in. Currently on rule-based forwarding there's a douvle-route-table penalty on the outbound traffic. I'll probably address this in b4 also. Chris. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org. == Head of Systems for Easynet Group PLC. --akKZr9L6Hm6aLOcr Content-Type: text/plain; charset=us-ascii Content-Description: Multipath/Rule-based forwarding README file Content-Disposition: attachment; filename="README.MPATH" Multipath Routing for FreeBSD (and friends) ------------------------------------------- Beta 3 release. 30 April 1998. Maintained by chrisy@flix.net. Patches against FreeBSD-2.2.6-STABLE (last cvsup'ed on 21 April 1998). The tar from which this came has two sets of code in it. One is for Multipath routing. One is for Firewall rule-based packet forwarding, where firewall rules can change the next-hop of packets that match them. You can have one, other both or none as you so desire, just include/ don't include the relevant "options" lines as shown below. This release has only minor fixes to the Multipath code. This release introduces the rule-based forwarding code. Installation ------------ Please follow these in order... In the tar file are a number of diffs all relative to /usr/src. One is for the sys/ tree (the kernel source) and the others for ifconfig(8), netstat(8) and route(8). I recommend you make copies of these binary sources into directories called "name.mpath" firstly for backup, secondly because cvsup overwrties files with changes with their current versions! Patch everything up as usual. If you don't know how, you shouldn't be playing with this code... The rule-based forwaring code requires a new ipfw(8) to be compiled. I recommend copying /usr/src/sbin/ipfw/ to ipfw.fwd and patching/compiling it in there. You will need to copy the patched sys/net/route.h to /usr/include/net/route.h, taking a copy of the original first, of course. Similarly, for the rule-based forwarind package, you will need to copy the patched sys/netinet/ip_fw.h to /usr/include/netinet/ip_fw.h. There is an example kernel config file in sys/i386/conf/QBert-MPath. The important lines in this file are: options EA_MULTIPATH options "EA_N_MULTIPATH=4" options "MSIZE=256" options EA_FWD The first two enable the patched code to be compiled in (all the code in the kernel is delimited with #ifdef EA_MULTIPATH - I hope) and the number of multipath gateways to support for each destination. This has to be hardcoded, I'm afraid, without a major rewrite of nearly everything. EA_FWD enables the rule-based forwarding package. Again, all the code is delimited with EA_FWD. You can also enable EA_FWD_DEBUG for debug messages that are probably meaningless to anyone but me. :-) MSIZE is the size of an mbuf. The extra data made routing socket messages too big for a single mbuf. This shouldn't be too terrible an overheard, many people have been considering making this the default for a long time. Compile the kernel, compile the patches binaries. You will also need to recompile arp(8) (no patches necessary) and anything else that makes use of the routing socket (or #include's route.h) to make them understand the new message structure. Particularly braindead code may need hacking to get it right (see below). Install it all, reboot, and hope for the best... ...with this code, I can type... bash-2.01# route add default -gateway 193.131.248.183 -gateway 195.40.1.1 ...and get a routing table that looks like... bash-2.01# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default UGSc 2 989 193.131.248.183 494 fxp2 *195.40.1.1 495 fxp0 127.0.0.1 *127.0.0.1 UH 1 14 lo0 193.131.248 *link#3 UC 0 0 193.131.248.20 *0:0:c0:a0:b1:e3 UHLW 0 357 fxp2 997 [etc] ...(note the gateways and their interfaces, also note the "Use" column) and thus get traceroutes like... bash-2.01# traceroute -n 195.40.6.30 traceroute to 195.40.6.30 (195.40.6.30), 30 hops max, 40 byte packets 1 195.40.1.1 0.629 ms 193.131.248.183 0.551 ms 195.40.1.1 0.491 ms 2 193.131.248.1 0.620 ms 195.40.1.13 0.676 ms 193.131.248.1 0.636 ms 3 195.40.6.30 0.975 ms 0.886 ms 0.915 ms Note the alternating IP's on *every* response. This is what it's all about. If the remote machine (195.40.6.30) has multipath code, then all data between these two hosts would use both available paths. The rule-based forwarding package allows me to do this: bash-2.01# ipfw add 2000 forward to 195.40.1.2,23 tcp from any to any 23 to get: bash-2.01# ipfw show 01000 16 986 allow ip from any to any via lo0 01010 0 0 deny ip from 127.0.0.0/8 to 127.0.0.0/8 02000 489 32817 forward to 195.40.1.2,23 tcp from any to any 23 65000 29109 3058452 allow ip from any to any 65535 0 0 deny ip from any to any Which traps all packets that go *into* this machine, destined for *any* address, destined for port 23 (the telnet service) and send it to 195.40.1.2, port 23. Because this address is local, it keeps it for itself. If it wasn't local, it would only affect *outbound* packets, but the port number rewriting doesn't then happen either, but it allows you to control the next-hop. If that next-hop isn't directly reachable, it looks up the route to that next-hop and uses that for the gateway for the packet (note, this second lookup *is* multipath code also, if multipath is enabled. Because of this there is a small penalty in having two routing table lookups (something I will address in the next release pf this code). This is only a huge issue on routers with large routing tables. Fixing things (programs) that don't work ---------------------------------------- Also in the tar is share/man/man4/route.mpath.4 which you may want to install. gzip -c share/man/man4/route.4 > /usr/share/man/man4/route.4 It has a brief descriprion of the changed routing socket messages. The notable difference is that the RTA_GATEWAY data is at the *end* of the message now instead of the middle, and that it's formed from a bit pattern that specifies how many gateways are in the message (which follow each other, at the end of said message). Code that doesn't follow the values of the RTA masks, even for single-gateway destinations, will have unpredictable results! Old versions of ipfw(8) won't work with the new ipfw structures in the kernel, either. I've included a share/man/man4/ipfirewall.8 that you may want to: gzip -c share/man/man4/ipfirewall.4 > /usr/share/man/man4/ipfirewall.4 Other things ------------ I've updated most man pages. I've probably missed a few, but route(8) is the most important in my mind. Route(8) has relatively good visual support for multipath routes. I've not yet defined a mechanism in the routing socket for passing multiple interface information, so it won't display that there. It works for netstat(8) because it accesses the kernel memory directly. I'm working on GateD. I've got GateD3_6Alpha_2 doing something half sensible, but not quite. When I've done GateD4 I'll submit those changes back to the Consortium. I'm not going to touch routed. Someone else can do that, if they want. I'll include diffs here should I recieve them. I'm going to code in metrics to multipath routes as well as persistant- route multipath in the firewall stuff. The latter of these will mean that when traffic to a certain destination has been routed, it remembers for a while where it sent it, so that should the next hop catch said traffic, there's a good chance that all fragments of a TCP connection go to the same host... it also improves the effectiveness of multiple transparent web proxies, by sending traffic that was destined for a certain site to the same proxy that has already cached it. Bugs, comments, flames to chris@easynet.net or chrisy@flix.net. --akKZr9L6Hm6aLOcr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 13:18:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12735 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 13:18:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from vorbis.noc.easynet.net (qmailr@vorbis.noc.easynet.net [195.40.1.254]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA12711 for ; Thu, 30 Apr 1998 13:18:30 -0700 (PDT) (envelope-from chrisy@vorbis.noc.easynet.net) Received: (qmail 4530 invoked by uid 1943); 30 Apr 1998 20:18:23 -0000 Message-ID: <19980430211823.44652@flix.net> Date: Thu, 30 Apr 1998 21:18:23 +0100 From: Chrisy Luke To: freebsd-hackers@FreeBSD.ORG Subject: Re: Beta 3 release of Multipath routing and friends. References: <19980430210604.09329@flix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19980430210604.09329@flix.net>; from Chrisy Luke on Thu, Apr 30, 1998 at 09:06:04PM +0100 Organization: The Flirble Internet Exchange X-URL: http://www.flix.net/ X-FTP: ftp://ftp.flirble.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chrisy Luke wrote (on Apr 30): > ftp://ftp.flirble.org/pub/unix/hacks/FreeBSD/mpath.b3.tgz > README attached. [...] > The rule-based forwarding package allows me to do this: > bash-2.01# ipfw add 2000 forward to 195.40.1.2,23 tcp from any to any 23 s/forward to/fwd/ Sorry. :-) Serves me right for using cut 'n paste... Cheers, Chris. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org. == Head of Systems for Easynet Group PLC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 13:22:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13668 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 13:22:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13639 for ; Thu, 30 Apr 1998 13:22:21 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id QAA16515; Thu, 30 Apr 1998 16:22:14 -0400 (EDT) Date: Thu, 30 Apr 1998 16:22:14 -0400 (EDT) From: Snob Art Genre To: Tom cc: hackers@FreeBSD.ORG Subject: Re: odd network problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 30 Apr 1998, Tom wrote: > TCP extensions. FreeBSD always uses them, and some broken routers screw > packets with TCP extensions up (primarily some old crappy term serve that > I can't remember right now). Most likely your PPP dialup is into one of > those boxes. Sure is. Many thanks to all those who answered. > This is an old question. I'm sure it is in the FAQ. Yes, I remember when this hit the lists. It didn't affect me then, so naturally I didn't think of it when it happened to me now. *slaps forehead* Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 13:36:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16468 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 13:36:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cerebus.nectar.com (cerebus.nectar.com [204.27.67.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16364 for ; Thu, 30 Apr 1998 13:35:59 -0700 (PDT) (envelope-from nectar@cerebus.nectar.com) Received: from cerebus.nectar.com (localhost.communique.net [127.0.0.1]) by cerebus.nectar.com (8.8.8/8.8.8) with ESMTP id PAA11632 for ; Thu, 30 Apr 1998 15:35:50 -0500 (CDT) Message-Id: <199804302035.PAA11632@cerebus.nectar.com> X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x094724A9 From: Jacques Vidrine To: freebsd-hackers@FreeBSD.ORG Subject: OK, I must be stupid (ports/6430) Date: Thu, 30 Apr 1998 15:35:50 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just want to fix PR ports/6430. It is an easy fix, requiring an additional patchfile in trafshow/patches. But I'm stumped ... there must be something I'm missing. If I stick my patch file in trafshow/patches (as the last one, patch-ae), I get: ---- # make patch >> Checksum OK for trafshow-2.0.tgz. ===> Patching for trafshow-2.0 ===> Applying FreeBSD patches for trafshow-2.0 1 out of 1 hunks failed--saving rejects to lib/interfaces.c.rej *** Error code 1 Stop. ---- If I apply the same patch manually, without having it in trafshow/patches: ---- # make patch >> Checksum OK for trafshow-2.0.tgz. ===> Patching for trafshow-2.0 ===> Applying FreeBSD patches for trafshow-2.0 # patch -d $PWD/work/trafshow-2.0 -p0 -E < ~/trafshow.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- lib/interfaces.c.ae Wed Apr 29 13:56:21 1998 |+++ lib/interfaces.c Wed Apr 29 13:56:30 1998 -------------------------- Patching file lib/interfaces.c using Plan A... Hunk #1 succeeded at 23. done ---- I don't get it. Can someone help? I am obviously lost, and I think I am missing something magic in bsd.ports.mk. The trivial patch file: --- lib/interfaces.c.ae Wed Apr 29 13:56:21 1998 +++ lib/interfaces.c Wed Apr 29 13:56:30 1998 @@ -23,7 +23,6 @@ #include #include #include -#include #ifdef __FreeBSD__ #include #else Jacques Vidrine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 16:22:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11237 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 16:22:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10946 for ; Thu, 30 Apr 1998 16:21:22 -0700 (PDT) (envelope-from witr@spooky.rwwa.com) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.8.7/8.8.7) with ESMTP id TAA15478 for ; Thu, 30 Apr 1998 19:21:17 -0400 (EDT) (envelope-from witr@spooky.rwwa.com) Message-Id: <199804302321.TAA15478@spooky.rwwa.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-reply-to: Your message of "Wed, 29 Apr 1998 17:48:38 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Apr 1998 19:21:17 -0400 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG drosih@rpi.edu said: :- If what we're implementing is basically the same as AIX's SIGDANGER, :- then I'd just as soon call it SIGDANGER. I must be really stupid. I do builds of the same software package on SunOs, Solaris, FreeBSD(2.2.x), HPUX, and AIX. These machines are simliarly configured with memory, etc, and all of the file space is NFS mounted. The builds on all of the machines *except* AIX *always* run to completion. The AIX box will sometimes complete and sometimes not, and sometimes I have to re-start builds two or three times. (You can't imagine how annoying it is to get messages like: "my build failed!!! What did you do to the build?" when it is just stupid AIX shooting innocent processes!) If this is such a great idea, why is it such a pain in the ass? Also, why have I never encountered FreeBSD doing this random process killin thing, nomatter *how* much load I put on it? Just asking... --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 16:35:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13699 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 16:35:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from aaka.3skel.com (aaka.3skel.com [207.240.212.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA13677 for ; Thu, 30 Apr 1998 16:35:45 -0700 (PDT) (envelope-from danj@3skel.com) Received: from fnur.3skel.com (fnur.3skel.com [192.168.0.8]) by aaka.3skel.com (8.8.5/8.8.2) with ESMTP id TAA01190; Thu, 30 Apr 1998 19:35:40 -0400 (EDT) Received: from localhost (danj@localhost) by fnur.3skel.com (8.8.5/8.8.2) with SMTP id TAA01142; Thu, 30 Apr 1998 19:35:40 -0400 (EDT) Date: Thu, 30 Apr 1998 19:35:40 -0400 (EDT) From: Dan Janowski To: Snob Art Genre cc: hackers@FreeBSD.ORG Subject: Re: odd network problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Do you have TCP extensions on? Some terminal servers and other lame routing hardware get jammed. This one got me once. Only between FreeBSD boxes, right? Dan On Thu, 30 Apr 1998, Snob Art Genre wrote: > I'm having a network problem that only manifests between two > FreeBSD-stable machines. I posted about this on questions, but got no > answer, and I think it might be over the collective questions head > anyway. > > I have two machines, float and ben. Float is dialed up PPP to > interport, ben is on a T1 from Sprint. I can ping and traceroute either > machine from the other one, but I cannot use TCP-based services. The > TCP handshake completes, and then the connection hangs. For example, if > I'm trying to telnet to float from ben, the handshake happens, and then > ben sends the same 27-byte packet for several minutes until it gives up. > > Meanwhile, telnet/ftp/ssh all work fine from a Solaris/SPARC box and > from a Linux box, to or from float or ben. > > Packet traces available upon request, of course. > > > Ben > > "You have your mind on computers, it seems." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- danj@3skel.com Dan Janowski Triskelion Systems, Inc. Bronx, NY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 17:14:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA18017 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 17:14:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18010 for ; Thu, 30 Apr 1998 17:14:05 -0700 (PDT) (envelope-from touch@ISI.EDU) Received: from rum.isi.edu (rum-s.isi.edu [128.9.192.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA26981; Thu, 30 Apr 1998 17:14:05 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id RAA22830; Thu, 30 Apr 1998 17:14:05 -0700 (PDT) Date: Thu, 30 Apr 1998 17:14:05 -0700 (PDT) Message-Id: <199805010014.RAA22830@rum.isi.edu> To: freebsd-hackers@FreeBSD.ORG Subject: ATAPI probe hanging Cc: touch@ISI.EDU Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I have a problem booting a laptop with a detachable CDROM base unit, when the unit is attached. The configuration is: Hitachi VisionBook Elite 2.2.5 kernel, PAO patches (970616) installed The symptom is that, during boot: finds fd0 finds wdc0 (wd0) finds wdc1 (CDROM) finds info about the CDROM at wcd0 - 1722 Kb/s... finds info about the CDROM at wcd0 - no disc inside, unlocked (hangs here) This problem prevents me from using a boot floppy (the PAO floppy, e.g.) to boot install from the CDROM. In attempting to trace the problem, I turned on debugging, and noticed that the kernel dealt fine with the first ATAPI device (#0), but it was hanging in the probe of the second device (#1), which does not exist on this machine. I found a temporary fix, which is: Change "/usr/src/sys/i386/isa/wd.c" : /* * Probe all free IDE units, searching for ATAPI drives. */ for (unit=0; unit<2; ++unit) { To: for (unit=0; unit<1; ++unit) { (the full patch is below) I would like to know if there is a configuration change that would avoid the need for this patch. (alternately, if anyone might be able to build a 2.2.5 or 2.2.6 PAO boot floppy with that patch, I would be very grateful) Thanks, Joe -------- (patch file follows) -------- *** wd.c Fri Feb 20 11:14:22 1998 --- wd.c-old Fri Feb 20 12:56:33 1998 *************** *** 736,743 **** /* * Probe all free IDE units, searching for ATAPI drives. */ ! /* for Joe for (unit=0; unit<2; ++unit) { */ ! for (unit=0; unit<1; ++unit) { #if NCRD > 0 for (lunit=0; lunit 0 for (lunit=0; lunit Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22664 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 17:49:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bleep.ishiboo.com (user7393@bleep.ishiboo.com [199.79.133.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA22656 for ; Thu, 30 Apr 1998 17:49:21 -0700 (PDT) (envelope-from black@bleep.ishiboo.com) From: black@bleep.ishiboo.com Received: (qmail 7102 invoked by uid 1018); 1 May 1998 01:50:19 -0000 Message-ID: <19980501015019.28211.qmail@bleep.ishiboo.com> Subject: recvmsg/sendmsg + pthreads? To: freebsd-hackers@FreeBSD.ORG Date: Thu, 30 Apr 1998 20:50:19 -0500 (EST) 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG are the recvmsg and sendmsg calls threadsafe in 2.2.6-STABLE? i am having problems getting things to work when doing recvmsg() on a socket if multiple threads are involved. thanks, ben black@ishiboo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 18:14:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25901 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 18:14:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA25855 for ; Thu, 30 Apr 1998 18:14:14 -0700 (PDT) (envelope-from witr@spooky.rwwa.com) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.8.7/8.8.7) with ESMTP id VAA16134 for ; Thu, 30 Apr 1998 21:14:10 -0400 (EDT) (envelope-from witr@spooky.rwwa.com) Message-Id: <199805010114.VAA16134@spooky.rwwa.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG Subject: Install panics on Solo 9100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Apr 1998 21:14:10 -0400 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In preparation for writing a pccard driver, I tried to install FreeBSD 3.0 from the Apr 29'th snap, and I get this: panic: vm_page_remove: page not busy when I hit "q" on the LABEL screen after configuring the filesystems. Gateway Solo 9100 system with 266 P || has 128MB ram. Any ideas? --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 18:26:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA28419 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 18:26:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA28386 for ; Thu, 30 Apr 1998 18:25:54 -0700 (PDT) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id VAA00212; Thu, 30 Apr 1998 21:24:34 -0400 (EDT) (envelope-from dec@phoenix.its.rpi.edu) Date: Thu, 30 Apr 1998 21:24:33 -0400 (EDT) From: "David E. Cross" To: Robert Withrow cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER In-Reply-To: <199804302321.TAA15478@spooky.rwwa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > drosih@rpi.edu said: > :- If what we're implementing is basically the same as AIX's SIGDANGER, > :- then I'd just as soon call it SIGDANGER. > > I must be really stupid. I do builds of the same software package > on SunOs, Solaris, FreeBSD(2.2.x), HPUX, and AIX. These machines are > simliarly configured with memory, etc, and all of the file space > is NFS mounted. > > The builds on all of the machines *except* AIX *always* run to > completion. The AIX box will sometimes complete and sometimes > not, and sometimes I have to re-start builds two or three times. > (You can't imagine how annoying it is to get messages like: > "my build failed!!! What did you do to the build?" when it is just > stupid AIX shooting innocent processes!) > > If this is such a great idea, why is it such a pain in the ass? > > Also, why have I never encountered FreeBSD doing this random > process killin thing, nomatter *how* much load I put on it? > > Just asking... Curious, I have never haid AIX shoot a build on me, I have never had AIX kill a random process on me unless the system was really taxed, and it has been *obvious* that the system is taxed; and I have had FreeBSD do similar to me when really pounding on it a random server process will usualy die (usually LPD). We could make this an "OPTION". BTW: If no one has claimed this project, I would like it... including finishing up the extended signal handling. (Yes, AFS work continues, I am almost to the point of a clean compile, having problems now with liblwp and context switching... but more of that this weekend :) -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 18:48:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01573 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 18:48:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01539 for ; Thu, 30 Apr 1998 18:48:13 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA00345 for ; Thu, 30 Apr 1998 17:44:50 -0700 (PDT) Message-Id: <199805010044.RAA00345@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG Subject: Mike in Tokyo Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Apr 1998 17:44:44 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A big hello to FreeBSD people in Tokyo! I'm going to be there from the 2nd to the 16th of May, and I'd really like to meet as many of you as possible. I haven't fixed a schedule yet, so I can afford to be flexible. If there's anything worth doing or seeing, I'd love to hear about that as well! Also, I'm still looking for a dialup network connection, so if you're a ISP, or you know one that's friendly to visitors, I'd appreciate hearing from you. Thanks! -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 19:19:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA05704 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 19:19:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05685 for ; Thu, 30 Apr 1998 19:18:58 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id MAA27044; Fri, 1 May 1998 12:21:33 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199805010221.MAA27044@cimlogic.com.au> Subject: Re: recvmsg/sendmsg + pthreads? In-Reply-To: <19980501015019.28211.qmail@bleep.ishiboo.com> from "black@bleep.ishiboo.com" at "Apr 30, 98 08:50:19 pm" To: black@bleep.ishiboo.com Date: Fri, 1 May 1998 12:21:32 +1000 (EST) Cc: freebsd-hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG black@bleep.ishiboo.com wrote: > are the recvmsg and sendmsg calls threadsafe in 2.2.6-STABLE? i am having > problems getting things to work when doing recvmsg() on a socket if > multiple threads are involved. Are you compiling with -D_THREAD_SAFE so that you get the thread-specific errno? -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 19:56:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11787 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 19:56:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA11743; Thu, 30 Apr 1998 19:56:17 -0700 (PDT) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id MAA26878; Fri, 1 May 1998 12:26:03 +0930 (CST) (envelope-from grog) Message-ID: <19980501122603.D26691@freebie.lemis.com> Date: Fri, 1 May 1998 12:26:03 +0930 From: Greg Lehey To: "Jason C. Wells" , CyberPeasant Cc: freebsd-questions@FreeBSD.ORG, FreeBSD Hackers Subject: Re: Writable /usr? Reply-To: FreeBSD Hackers References: <199804280016.UAA03779@pollux.loco.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Jason C. Wells on Mon, Apr 27, 1998 at 07:21:40PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 27 April 1998 at 19:21:40 -0700, Jason C. Wells wrote: > On Mon, 27 Apr 1998, CyberPeasant wrote: > >> As a newcomer to FreeBSD but a greybeard in the unix world, can I >> politely ask why FreeBSD seems intent on making /usr a writable >> partition? You're probably on the wrong forum here. -questions is for problems. For philosophy, you could try -hackers. I'm copying -questions as well on this reply, mainly because of my comments on Jason's reply, but please follow up to -hackers. >> In another thread, someone reports that the user guide recommends >> locating /tmp and /var on /usr. I believe I've seen >> recommendations to supply users' home directories in the /usr >> partition, too. (The default installation script sets you up >> without a /home partition.) What's the rationale for this? Isn't >> readonly /usr (and /, if possible) a Good Thing anymore? > > You may have to place /tmp or /var on user if you have a prexisting file > system that starts running out of space. By default /var partition is > mounted on /var and /tmp directory is mounted on /. I think this is not so much the point. I haven't seen anybody recommend /tmp on /usr (and it's a problem if you need /tmp in single-user mode). I recommend /var on /usr to avoid fragmenting disks, but there's nothing holy about it. To CyberPeasant's comments on /home: I'd suggest that this is an omission. > As a side note, IRIX puts home directories in /usr/people by > default. This doesn't win it many friends. Back to CP's questions (sorry this is so poorly structured): I don't really see that ther is a requirement for having /usr a writeable file system. We've discussed a number of varieties in the past, including not having a /usr file system (put it on the root file system), and having an RO root and RW /var. Do you have a particular reason to want it RO? Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 20:29:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA15878 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 20:29:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dan.emsphone.com (dan@dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA15869 for ; Thu, 30 Apr 1998 20:29:17 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.8.8/8.8.6) id WAA20979; Thu, 30 Apr 1998 22:29:14 -0500 (CDT) Message-ID: <19980430222914.A20607@emsphone.com> Date: Thu, 30 Apr 1998 22:29:14 -0500 From: Dan Nelson To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how to fseek past 2GB? References: <19980429150055.A17639@emsphone.com> <199804300753.AAA00308@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.4i In-Reply-To: <199804300753.AAA00308@usr05.primenet.com>; from "Terry Lambert" on Thu Apr 30 07:53:58 GMT 1998 X-OS: FreeBSD 2.2.6-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Apr 30), Terry Lambert said: > > I recently noticed that there is no way to fseek() past the 2GB > > mark on files opened with fopen(). The offset in the FILE struct > > is an fpos_t; there's just no way to get at it. > > Heh. > ... > fseek( fp, 1<<30, SEEK_SET); /* first 2G*/ > fseek( fp, 1<<30, SEEK_CUR); /* next 2G*/ > ... > > It'd be easy to wrap this. 8-). Actually, this is illegal according to the man page at http://www.opengroup.org/onlinepubs/7908799/xsh/stdio.h.html . fseek is only allowed to seek to file offsets that ftell could return: [EOVERFLOW] For fseek(), the resulting file offset would be a value which cannot be represented correctly in an object of type long. Should I code for this error case, or let fseek hopscotch into the >2GB area? Are there any programs that even know it's possible? -Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 20:43:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA18632 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 20:43:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pollux.loco.net (lucy.bedford.net [206.99.145.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA18621 for ; Thu, 30 Apr 1998 20:43:11 -0700 (PDT) (envelope-from listread@bedford.net) Received: (from listread@localhost) by pollux.loco.net (8.8.8/8.8.8) id XAA24487 for hackers@FreeBSD.ORG; Thu, 30 Apr 1998 23:23:18 -0400 (EDT) (envelope-from listread) Message-Id: <199805010323.XAA24487@pollux.loco.net> Subject: Re: Writable /usr? In-Reply-To: <19980501122603.D26691@freebie.lemis.com> from Greg Lehey at "May 1, 98 12:26:03 pm" To: hackers@FreeBSD.ORG Date: Thu, 30 Apr 1998 23:23:18 -0400 (EDT) From: CyberPeasant Reply-To: djv@bedford.net X-no-archive: yes X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 27 April 1998 at 19:21:40 -0700, Jason C. Wells wrote: > > On Mon, 27 Apr 1998, CyberPeasant wrote: > > > >> As a newcomer to FreeBSD but a greybeard in the unix world, can I > >> politely ask why FreeBSD seems intent on making /usr a writable > >> partition? > > You're probably on the wrong forum here. -questions is for problems. I was trying to prevent a problem :) > For philosophy, you could try -hackers. I'm copying -questions as > well on this reply, mainly because of my comments on Jason's reply, > but please follow up to -hackers. > > >> In another thread, someone reports that the user guide recommends > >> locating /tmp and /var on /usr. I believe I've seen > >> recommendations to supply users' home directories in the /usr > >> partition, too. (The default installation script sets you up > >> without a /home partition.) What's the rationale for this? Isn't > >> readonly /usr (and /, if possible) a Good Thing anymore? > > > > You may have to place /tmp or /var on user if you have a prexisting file > > system that starts running out of space. By default /var partition is > > mounted on /var and /tmp directory is mounted on /. > > I think this is not so much the point. I haven't seen anybody > recommend /tmp on /usr (and it's a problem if you need /tmp in > single-user mode). I recommend /var on /usr to avoid fragmenting > disks, but there's nothing holy about it. Which disc? I suppose that /var under /usr would be the only really active area of the partition, and any performance hit would be confined to itself. > To CyberPeasant's comments on /home: I'd suggest that this is an > omission. Right. It's always a question, though, of how much to snow a new installer with. You maintain some of this stuff, right? If so, my compliments on the very flexible install materials. > > As a side note, IRIX puts home directories in /usr/people by > > default. > > This doesn't win it many friends. > > Back to CP's questions (sorry this is so poorly structured): I don't > really see that ther is a requirement for having /usr a writeable file > system. We've discussed a number of varieties in the past, including I was wondering if it was assumed to be writable in the "official philosophy". I think I may have over-reacted. The default installation seems to run fine with RO /usr. > not having a /usr file system (put it on the root file system), and > having an RO root and RW /var. Do you have a particular reason to > want it RO? Security primarily (not so much the cracker kind, but the damaged fs from rogue program kind). Configuration control. No need to backup more than once. Faster boots, since it never needs to be fsck'ed. (Well, barring hardware problems.) If I could, I'd have it on a dedicated drive, with the drive jumpered for RO operation. It's probably a minor issue on a home machine or one with a few friendly users. > Greg > Hi, I'm content to let the thread die... so am responding off list. Actually this is, IMHO, an issue that is probably only of interest to the Unix-newbie, more experienced hands having their own well-founded tastes and opinions. I don't think newbie issues have much place on -hackers, and there doesn't seem to be a -config list (in linux, this is called the linux-admin list). The originator had been advised by the user guide to move /var to /usr/var and /tmp to /usr/tmp, which one would do only if radically desperate for some disk space. Thanks for your interest and comments! Dave -- <----. mailto/pgpfinger: djv@bedford.net <----|=================================== <----' Crathva fxrjre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 21:44:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA26446 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 21:44:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bleep.ishiboo.com (user28420@bleep.ishiboo.com [199.79.133.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA26436 for ; Thu, 30 Apr 1998 21:44:38 -0700 (PDT) (envelope-from black@bleep.ishiboo.com) From: black@bleep.ishiboo.com Received: (qmail 8227 invoked by uid 1018); 1 May 1998 05:45:45 -0000 Message-ID: <19980501054545.6097.qmail@bleep.ishiboo.com> Subject: Re: recvmsg/sendmsg + pthreads? In-Reply-To: <199805010221.MAA27044@cimlogic.com.au> from John Birrell at "May 1, 98 12:21:32 pm" To: jb@cimlogic.com.au (John Birrell) Date: Fri, 1 May 1998 00:45:45 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG i'm not getting an error, it just returns immediately even though there is no data to be read on the socket. (no, i'm not compiling with -D_THREAD_SAFE but thanks for the tip). > black@bleep.ishiboo.com wrote: > > are the recvmsg and sendmsg calls threadsafe in 2.2.6-STABLE? i am having > > problems getting things to work when doing recvmsg() on a socket if > > multiple threads are involved. > > Are you compiling with -D_THREAD_SAFE so that you get the thread-specific > errno? > > -- > John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ > CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 22:20:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA29557 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 22:20:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA29540 for ; Thu, 30 Apr 1998 22:20:09 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id WAA16794; Thu, 30 Apr 1998 22:20:09 -0700 (PDT) (envelope-from sef) Date: Thu, 30 Apr 1998 22:20:09 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199805010520.WAA16794@kithrup.com> To: hackers@FreeBSD.ORG Reply-To: hackers@FreeBSD.ORG Subject: Re: how to fseek past 2GB? In-Reply-To: <19980430222914.A20607.kithrup.freebsd.hackers@emsphone.com> References: <199804300753.AAA00308@usr05.primenet.com>; from "Terry Lambert" on Thu Apr 30 07:53:58 GMT 1998 Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19980430222914.A20607.kithrup.freebsd.hackers@emsphone.com> you write: > For fseek(), the resulting file offset would be a value which > cannot be represented correctly in an object of type long. > >Should I code for this error case, or let fseek hopscotch into the >2GB >area? Are there any programs that even know it's possible? Or you could apply these patches which, admittedly, I haven't even compiled yet ;). This is approximately what Chris Torek did to do the same thing, he says. Index: fgetpos.c =================================================================== RCS file: /usr/cvs/src/lib/libc/stdio/fgetpos.c,v retrieving revision 1.6 diff -u -r1.6 fgetpos.c --- fgetpos.c 1998/04/11 07:40:42 1.6 +++ fgetpos.c 1998/05/01 05:17:47 @@ -50,6 +50,7 @@ FILE *fp; fpos_t *pos; { + extern fpos_t __sftell(FILE*); int retval; FLOCKFILE(fp); retval = (*pos = ftell(fp)) == (fpos_t)-1; Index: fseek.c =================================================================== RCS file: /usr/cvs/src/lib/libc/stdio/fseek.c,v retrieving revision 1.7 diff -u -r1.7 fseek.c --- fseek.c 1998/04/11 07:40:44 1.7 +++ fseek.c 1998/05/01 05:17:49 @@ -58,9 +58,9 @@ * `Whence' must be one of the three SEEK_* macros. */ int -fseek(fp, offset, whence) +__sfseek(fp, offset, whence) register FILE *fp; - long offset; + fpos_t offset; int whence; { register fpos_t (*seekfn) __P((void *, fpos_t, int)); @@ -257,4 +257,13 @@ fp->_flags &= ~__SEOF; FUNLOCKFILE(fp); return (0); +} + +int +fseek(fp, offset, whence) + FILE *fp; + long offset; + int whence; +{ + return __sfseek(fp, (fpos_t)offset, whence); } Index: fsetpos.c =================================================================== RCS file: /usr/cvs/src/lib/libc/stdio/fsetpos.c,v retrieving revision 1.5 diff -u -r1.5 fsetpos.c --- fsetpos.c 1997/02/22 15:02:06 1.5 +++ fsetpos.c 1998/05/01 05:17:49 @@ -52,5 +52,6 @@ FILE *iop; const fpos_t *pos; { - return (fseek(iop, (long)*pos, SEEK_SET)); + extern int __sfseek(FILE *, fpos_t, int) + return (__sfseek(iop, *pos, SEEK_SET)); } Index: ftell.c =================================================================== RCS file: /usr/cvs/src/lib/libc/stdio/ftell.c,v retrieving revision 1.9 diff -u -r1.9 ftell.c --- ftell.c 1998/04/11 07:40:44 1.9 +++ ftell.c 1998/05/01 05:17:48 @@ -50,8 +50,8 @@ /* * ftell: return current offset. */ -long -ftell(fp) +fpos_t +__sftell(fp) register FILE *fp; { register fpos_t pos; @@ -94,4 +94,11 @@ } FUNLOCKFILE(fp); return (pos); +} + +long +ftell(fp) + register FILE *fp; +{ + return (long)__sftell(fp); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 22:28:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00414 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 22:28:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA00409 for ; Thu, 30 Apr 1998 22:28:36 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id PAA01029; Fri, 1 May 1998 15:29:51 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199805010529.PAA01029@cimlogic.com.au> Subject: Re: recvmsg/sendmsg + pthreads? In-Reply-To: <19980501054545.6097.qmail@bleep.ishiboo.com> from "black@bleep.ishiboo.com" at "May 1, 98 00:45:45 am" To: black@bleep.ishiboo.com Date: Fri, 1 May 1998 15:29:46 +1000 (EST) Cc: jb@cimlogic.com.au, freebsd-hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG black@bleep.ishiboo.com wrote: > i'm not getting an error, it just returns immediately even though there is > no data to be read on the socket. (no, i'm not compiling with -D_THREAD_SAFE > but thanks for the tip). If you're not compiling with -D_THREAD_SAFE, then you don't know if you are not getting an error. 8-) Except if the call is in the initial thread. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 30 23:36:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA08674 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 23:36:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA08666; Thu, 30 Apr 1998 23:36:31 -0700 (PDT) (envelope-from sos) Message-Id: <199805010636.XAA08666@hub.freebsd.org> Subject: Re: ATAPI probe hanging In-Reply-To: <199805010014.RAA22830@rum.isi.edu> from Joe Touch at "Apr 30, 98 05:14:05 pm" To: touch@ISI.EDU (Joe Touch) Date: Thu, 30 Apr 1998 23:36:30 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.ORG, touch@ISI.EDU From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In reply to Joe Touch who wrote: > Hi, > > I have a problem booting a laptop with a detachable CDROM base unit, > when the unit is attached. > > The configuration is: > Hitachi VisionBook Elite > 2.2.5 kernel, PAO patches (970616) installed > > The symptom is that, during boot: > > finds fd0 > finds wdc0 (wd0) > finds wdc1 (CDROM) > finds info about the CDROM at wcd0 - 1722 Kb/s... > finds info about the CDROM at wcd0 - no disc inside, unlocked > > (hangs here) It would have been nice with the real output here, details details... Its not clear to me if the CDROM is on wdc0 or wdc1 ?? The probe can hang pretty long if no devices is present, the standard calls for 30secs waits for devices to become ready. You patch will break on all machines having the CDROM as slave :( We need the exact probe messages, best with verbose on, and the setup of the drives (channel 0/1 master/slave) to help you any further... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 05:55:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA11576 for freebsd-hackers-outgoing; Fri, 1 May 1998 05:55:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from soccer.inetspace.com ([206.50.163.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA11568 for ; Fri, 1 May 1998 05:55:07 -0700 (PDT) (envelope-from kgor@soccer.inetspace.com) Received: (from kgor@localhost) by soccer.inetspace.com (8.8.7/8.8.7) id HAA08276; Fri, 1 May 1998 07:51:46 -0500 (CDT) (envelope-from kgor) Date: Fri, 1 May 1998 07:51:46 -0500 (CDT) Message-Id: <199805011251.HAA08276@soccer.inetspace.com> From: "Kent S. Gordon" To: witr@rwwa.com CC: freebsd-hackers@FreeBSD.ORG In-reply-to: <199804302321.TAA15478@spooky.rwwa.com> (message from Robert Withrow on Thu, 30 Apr 1998 19:21:17 -0400) Subject: Re: SIGDANGER Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "witr" == Robert Withrow writes: > drosih@rpi.edu said: :- If what we're implementing is basically > the same as AIX's SIGDANGER, :- then I'd just as soon call it > SIGDANGER. > I must be really stupid. I do builds of the same software > package on SunOs, Solaris, FreeBSD(2.2.x), HPUX, and AIX. These > machines are simliarly configured with memory, etc, and all of > the file space is NFS mounted. > The builds on all of the machines *except* AIX *always* run to > completion. The AIX box will sometimes complete and sometimes > not, and sometimes I have to re-start builds two or three times. > (You can't imagine how annoying it is to get messages like: "my > build failed!!! What did you do to the build?" when it is just > stupid AIX shooting innocent processes!) The AIX ld can use LARGE amounts of VM because it brings all libraries into memory before resolving symbols. If you are linking with lots of libraries you need lots of swap space. I seem to remember that emacs/gcc needed about 150MB to successfully build. > If this is such a great idea, why is it such a pain in the ass? > Also, why have I never encountered FreeBSD doing this random > process killin thing, nomatter *how* much load I put on it? > Just asking... > --------------------------------------------------------------------- > Robert Withrow, R.W. Withrow Associates, Swampscott MA, > witr@rwwa.COM > To Unsubscribe: send mail to majordomo@FreeBSD.org with > "unsubscribe freebsd-hackers" in the body of the message -- Kent S. Gordon Architect iNetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 07:12:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA19268 for freebsd-hackers-outgoing; Fri, 1 May 1998 07:12:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cyclone.degnet.baynet.de (cyclone.degnet.baynet.de [194.95.214.129]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA19228 for ; Fri, 1 May 1998 07:12:23 -0700 (PDT) (envelope-from malte@webmore.com) Received: from neuron.webmore.com (unverified [194.95.214.175]) by cyclone.degnet.baynet.de (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 01 May 1998 16:09:33 +0200 Received: from neuron.webmore.de (malte@webmore.com) by neuron.webmore.com (8.8.8/8.8.8) with ESMTP id PAA00805; Fri, 1 May 1998 15:03:37 +0200 (CEST) Message-ID: X-Mailer: XFMail 1.2 [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: <199804302035.PAA11632@cerebus.nectar.com> Date: Fri, 01 May 1998 15:03:37 +0200 (CEST) Reply-To: malte@webmore.com From: Malte Lance To: Jacques Vidrine Subject: RE: OK, I must be stupid (ports/6430) Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30-Apr-98 Jacques Vidrine wrote: > > I just want to fix PR ports/6430. It is an easy fix, requiring an > additional patchfile in trafshow/patches. > > But I'm stumped ... there must be something I'm missing. > Hm ... what is your problem ? Works for me: neuron:/usr/ports/net/trafshow/work/trafshow-2.0# diff -u lib/interfaces.c.orig2 lib/interfaces.c >../../patches/patch-ae neuron:/usr/ports/net/trafshow/work/trafshow-2.0# cat ../../patches/patch-ae --- lib/interfaces.c.orig2 Fri May 1 14:53:54 1998 +++ lib/interfaces.c Fri May 1 14:55:00 1998 @@ -21,7 +21,6 @@ #include #include #include -#include #ifdef __FreeBSD__ #include #else neuron:/usr/ports/net/trafshow/work/trafshow-2.0# cd ../.. neuron:/usr/ports/net/trafshow# make clean ===> Cleaning for trafshow-2.0 neuron:/usr/ports/net/trafshow# make fetch checksum extract patch >> Checksum OK for trafshow-2.0.tgz. ===> Extracting for trafshow-2.0 ===> Patching for trafshow-2.0 ===> Applying FreeBSD patches for trafshow-2.0 neuron:/usr/ports/net/trafshow# Malte ---------------------------------- E-Mail: Malte Lance Date: 01-May-98 Time: 14:36:35 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 07:59:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA24812 for freebsd-hackers-outgoing; Fri, 1 May 1998 07:59:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from golem.belabm.by (root@golem.belabm.by [194.226.122.185]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA24789 for ; Fri, 1 May 1998 07:59:21 -0700 (PDT) (envelope-from scaner@belabm.by) Received: from belabm.by ([194.226.122.183]) by golem.belabm.by (8.8.7/8.8.4) with ESMTP id RAA07728 for ; Fri, 1 May 1998 17:58:27 +0300 Message-ID: <3549E269.C33B3E9A@belabm.by> Date: Fri, 01 May 1998 17:55:37 +0300 From: Eugene Vedistchev Reply-To: scaner@belabm.by Organization: Global One in Belarus X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: "freebsd-hackers@FreeBSD.ORG" Subject: something interesting Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello. Found this forward in russian echoconference about linux, seems to be interesting for freebsd ppl. Message-Id: ?199804281427.KAA18188@chmls05.mediaone.net? To: gnhlug@zk3.dec.com Subject: FYI - possible further X licensing developments Date: Tue, 28 Apr 1998 10:28:50 -0400 From: "Michael O'Donnell" ?mod@semolina.ne.mediaone.net? Date: Tue, 28 Apr 1998 09:40:19 -0400 From: Ken Flowers ?flowers@opengroup.org? Subject: X Window System Licensing Directions Dear Friends: You may be aware that we recently changed the licensing terms for the X Window System(TM) technology. You may also be aware that this change has caused some concern in the freeware community. This letter will explain the reasons behind the licensing change and explain what we are doing to address the concerns of the freeware community. We set up the X Window System licensing to provide free access to non-commercial users of the technology, while adding a licensing fee or X Project Team membership requirement for commercial use of the technology. The commercial terms have been well received, but the non-commercial terms have not met the needs of the freeware community. In particular, our current non-commercial license restricts the traditional freeware distribution channels by not having a way to distribute the code for a reasonable at media cost. The result of this is a potential split in the development streams of the technology. We have spoken with a number of leaders in the freeware community and belive we have found a solution to this problem that addresses our business goals, is mindful of our customers' needs, and addresses the concerns of the freeware community. We are looking at creating a variant of the "Artistic License" already in use by the freeware community for distributing Perl. That license would allow for redistribution of the X Window System code to the freeware community in the traditional manner, low priced CDROMs. We expect to finalize the details of this solution in the next weeks and announce changes to the non- commercial license terms to the broad audience then. In the mean time, I'd like to explain some of our reasons for making these changes and address some questions raised by these changes. Summary of X11R6.4 X Window System Licensing Commercial distributors of X11R6.4 must either be members of the X Project Team or make royalty payments, but not both. One benefit of membership in the X Project Team is that it now provides an annual paid up license for commercial distribution. An X Project Team membership costs between $5K and $50K per year depending on volume of shipments and participation levels. Non-commercial users can download the technology from our ftp site, ftp.x.org, or from a number of mirror sites at no charge. We are clarifying the current license to allow distribution of the technology in aggregate free software distributions for a fee. All of the money from X Project Team memberships, past and future (and any future royalty-based license revenue) has been and will be used for further development of the X Window System technology. Motivation The Open Group, operating with the input of the X Project Team members, has two motivations in creating the new license policy: * To insure that there is a financial base to support continued development, testing and controlled releases of the X Window System for both commercial companies and for the free software community. * To insure that work contributed for free from the free community is not exploited for commercial benefit unless an organization making commercial use provides some financial support for the evolution of the technology. This benefits the free community and, The Open Group hopes, encourages new work by the free community on the X11R6.4 base. Over time and with stability of the code, X Project Team membership support for the X Window System technology has dropped even while usage and sales of the technology has increased. In fact, one multi-billion dollar company recently dropped out of the X Project Team, but still was one of the first companies to download the X11R6.4 code from The Open Group web site. The intent of the new licensing policy is to counteract this trend and cause those who profit from the sale of the technology to help support it, instead of taking advantage of the previously unrestricted license model. Like harvesting a forest for profit without replanting, the previous state of affairs ultimately does not benefit users or suppliers. The most straightforward way to achieve a viable X Window System technology program in the future is to change the commercial economics of the situation now. That is what the new licensing policy does. Background The development of X Window System technology started at MIT, moved to the X Consortium, and then to The Open Group. The development of the X Windows System has always been funded by sponsorship from companies who planned to sell the resulting technology. In the last year that MIT managed the technology there were approximately 105 companies supplying over $2 million to the development of the technology. That dwindled to about half that amount at the X Consortium, which caused the X Consortium to develop a similar licensing program to what The Open Group has just announced. The X Consortium shut down prior to implementing that program. When the technology was transferred to The Open Group, The Open Group did not implement new licensing as the X Consortium had intended to do. Instead, The Open Group has tried to rely for support on the good will of the businesses that use the technology commercially. There is a core set of companies that, through their X Project Team memberships, make a valuable investment which benefits the free community. There are currently 25 X Project Team members. The Open Group gratefully acknowledges their support and believes that the best possible use of their investment is being made in delivering releases such as X11R6.4. The Open Group runs the X Project Team as a non-profit activity to support the technology and specification development of the X Window System moving forward. This work is done with a small full time staff that is supported directly from X Project Team membership revenue. The X Project Team members review and direct our work. All of the X Project Team revenue is invested back into the technology. Regards, Ken Flowers Director of Desktop Technologies ********************************************************** To unsubscribe from this list, send mail to majordomo@zk3.dec.com with the following text in the *body* (*not* the subject line) of the letter: unsubscribe gnhlug ********************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 10:08:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13331 for freebsd-hackers-outgoing; Fri, 1 May 1998 10:08:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA13232 for ; Fri, 1 May 1998 10:08:42 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.0.Beta7/frmug-2.3/nospam) with UUCP id TAA27352 for freebsd-hackers@FreeBSD.ORG; Fri, 1 May 1998 19:04:47 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.9.0.Beta4/keltia-2.14/nospam) id KAA00281 for freebsd-hackers@FreeBSD.ORG; Fri, 1 May 1998 10:58:21 +0200 (CEST) (envelope-from roberto) Message-ID: <19980501105821.A267@keltia.freenix.fr> Date: Fri, 1 May 1998 10:58:21 +0200 From: Ollivier Robert To: "FreeBSD Hackers' list" Subject: Fwd: Recent NetBSD network code improvements Mail-Followup-To: FreeBSD Hackers' list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.3i X-Operating-System: FreeBSD 3.0-CURRENT ctm#4245 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Looks interesting. To: netbsd-announce@NetBSD.ORG Subject: Recent NetBSD network code improvements From: Jason Thorpe Date: Thu, 30 Apr 1998 19:50:11 -0700 Hi folks... This is just a quick note to announce some cool new features to NetBSD's networking code, recently introduced in NetBSD-current. * The TCP initial congestion window (IW) has been made a tunable variable. This will facilitate migration to the new TCP initial window when finalized by the Internet Engineering Task Force. The IW may be tuned by the sysctl variable net.inet.tcp.init_win. A value of 0 indicates that the Floyd ~4K IW formula will be used to compute the IW. Otherwise, the variable indicates the number of maximum-sized packets. Contact: Jason R. Thorpe * The Hughes/Touch/Heidemann Congestion Window Monitoring algorithm has been added to TCP. This eliminates line-rate bursts that can congest network links and routers. It works by counting the number of outstanding (unacknowedged) packets on the wire, and allowing that many packets plus a burst value additional packets when more data is to be transmitted on a TCP connection. As long as a connection keeps transmitting, congestion window space is available. As soon as a connection stops transmitting, the available congestion window quickly decays back to the burst value. This policy has often been described as "use it or lose it". It can be especially helpful on World Wide Web servers which implement HTTP/1.1, which has lingering connections, which have a high tendency to go idle. CWM may be enabled in your kernel by setting the sysctl variable net.inet.tcp.cwm to 1. The burst value may be tuned by setting the sysctl variable net.inet.tcp.cwm_burstsize. The default burst size is 4 packets, as documented in the CWM Internet Draft. Contact: Jason R. Thorpe * Path MTU Discovery has been improved. The most significant improvement over NetBSD 1.3 is that routes added by the Path MTU Discovery engine now properly time out. In support of this, a general route timer framework as been added to the NetBSD kernel. Path MTU Discovery may be enabled by the sysctl variable net.inet.ip.mtudisc. The timeout period, expressed in seconds, may be modified by the sysctl variable net.inet.ip.mtudisctimeout. Contact: Kevin M. Lahey * The RFC1323 PAWS/Timestamps/Window Scale implementation in NetBSD's TCP has been brought up to full spec with the lastest RFC1323.bis. In addition, a finer-grained control over RFC1323 extensions is now supported. RFC1323 may be enabled by the sysctl variable net.inet.tcp.rfc1323. If that variable is enabled, timestamps and window scaling are enabled via the net.inet.tcp.timestamps and net.inet.tcp.win_scale sysctl variables, respectively. Contact: Kevin M. Lahey Jason R. Thorpe * Hooks for zero-copy and other optimizations have been added to the socket layer. In combination with the new virtual memory system, UVM, these hooks could potentially provide greatly improved performance for many network applications. Watch for more work in this exciting area! Contact: Matt Thomas * The TCP segment reassembly code has been completely rewritten. The new code supports segment concatenation, which will improve performance for out-of-order packets, and also forms the building blocks of RFC2018 Selective Acknowledgement support. Contact: Matt Thomas * IP flow recognition and fast IP forwarding support has been added. This enables PC-class hardware to forward packets at full line rate with very little CPU utilization. Initial testing showed forwarding rates of over 140,000 packets per second with no appreciable increase in system load! Support for fast-forwarding over Ethernet and FDDI exists now, and support for fast-forwarding over ATM and Hippi is planned for the near future. There's more work yet to do, but this is very exciting stuff! Contact: Matt Thomas * Support for spoofing link-level addresses has been added to the Berkeley Packet Filter. This is useful in many applications where protocols require specific MAC source addresses. This code was contributed by Greg Smith of the Numerical Aerospace Simulation Facility, NASA Ames Research Center. Contact: Jason R. Thorpe * inetd(8) has been modified to allow specification of listen socket buffer sizes in /etc/inetd.conf. This is useful for TCP servers that wish to advertise large windows requiring window scale factors (window scale must be advertised during the connection handshake, which is why the socket buffer size must be set on the listen socket). This can improve TCP performance greatly in some situations. Contact: Jason R. Thorpe And remember, technical discussions about NetBSD's networking code take place on the tech-net@netbsd.org mailing list. To subscribe, send mail to majordomo@netbsd.org with the message body: subscribe tech-net Until next time... -- The NetBSD Network Code Hackers ----- End forwarded message ----- -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #8: Tue Apr 21 02:45:53 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 10:33:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17330 for freebsd-hackers-outgoing; Fri, 1 May 1998 10:33:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dog.farm.org (gw-hssi-2.farm.org [209.66.103.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17253 for ; Fri, 1 May 1998 10:33:10 -0700 (PDT) (envelope-from dog.farm.org!dk) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id KAA28217; Fri, 1 May 1998 10:30:36 -0700 (PDT) Date: Fri, 1 May 1998 10:30:36 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199805011730.KAA28217@dog.farm.org> To: peter.jeremy@alcatel.com.au (Peter Jeremy) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: VM architecture (was Re: Protected mode instructions which reduce Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199804262144.HAA29582@gsms01.alcatel.com.au> you wrote: [...] > On Fri, 24 Apr 1998 06:22:59 +0000 (GMT), Terry Lambert wrote: > >The IBM VM architecture is logically complete -- that is, nearly all > >of the instruction emulation implementation is in hardware, > The VM kernel needs to provide a `virtual supervisor' mode. This can > be quite expensive in software, so IBM provided microcode assist units > which effectively made `virtual supervisor' mode part of the hardware > machine mode. Pity that modern microprocessors don't have writable > microcode. they do; modern Pentium series (starting with PPro if my memory serves me right) contain user-modifyable area. The Pentium F00F bug release from Intel specifically said that this bug has to be dealt with in software because Pentiums are not updateable. how much you'd have to pay for the docs is a different question ;_) -- "If, after extensive tweaking, your program is still too slow, try dropping a few 'sleep(-1)'s into it." --Craig Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 11:14:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23531 for freebsd-hackers-outgoing; Fri, 1 May 1998 11:14:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23521; Fri, 1 May 1998 11:14:24 -0700 (PDT) (envelope-from touch@ISI.EDU) Received: from rum.isi.edu (rum-s.isi.edu [128.9.192.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA13620; Fri, 1 May 1998 11:14:22 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id LAA19385; Fri, 1 May 1998 11:14:21 -0700 (PDT) Date: Fri, 1 May 1998 11:14:21 -0700 (PDT) Message-Id: <199805011814.LAA19385@rum.isi.edu> To: touch@ISI.EDU, sos@FreeBSD.ORG Subject: Re: ATAPI probe hanging Cc: freebsd-hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: sos@FreeBSD.ORG > Subject: Re: ATAPI probe hanging > Date: Thu, 30 Apr 1998 23:36:30 -0700 (PDT) > > In reply to Joe Touch who wrote: > > Hi, > > > > I have a problem booting a laptop with a detachable CDROM base unit, > > when the unit is attached. > > > > The configuration is: > > Hitachi VisionBook Elite > > 2.2.5 kernel, PAO patches (970616) installed ... > > It would have been nice with the real output here, details details... I will post this as soon as I can gather it. > You patch will break on all machines having the CDROM as slave :( The patch is only for my machine, for one boot floppy - it was not intended as a suggestion for general use. FYI, Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 12:00:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01536 for freebsd-hackers-outgoing; Fri, 1 May 1998 12:00:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01463 for ; Fri, 1 May 1998 12:00:04 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id OAA13276; Fri, 1 May 1998 14:58:22 -0400 (EDT) Date: Fri, 1 May 1998 14:58:22 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Snob Art Genre cc: "Jan L. Peterson" , hackers@FreeBSD.ORG Subject: Re: odd network problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Your ISP had a roomful of annexes last time I was there, try to get them to shift you to the USR boxes they have instead. Annexes basically suck. We used to use them for dialup and have now converted most of them to console servers... Charles Sprickman spork@super-g.com ---- On Thu, 30 Apr 1998, Snob Art Genre wrote: > On Thu, 30 Apr 1998, Jan L. Peterson wrote: > > > I've seen this when dialing up to a xylogics annex. Turning off > > tcp_extensions in /etc/rc.conf solved it (actually, you only had to > > turn off one tcp_extension, but I can't remember which one :-). > > > > Check out /etc/rc.conf and /etc/rc.network. Good luck. > > Turning off RFC 1323 extensions did the trick. Thank you, you have > saved my sanity. > > Now to call up my ISP and yell at them. > > > Ben > > "You have your mind on computers, it seems." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 12:31:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06388 for freebsd-hackers-outgoing; Fri, 1 May 1998 12:31:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mtigwc05.worldnet.att.net (mtigwc05.worldnet.att.net [204.127.131.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06354 for ; Fri, 1 May 1998 12:30:59 -0700 (PDT) (envelope-from SAMIGWE@worldnet.att.net) Received: from myname.my.domain ([12.78.197.14]) by mtigwc05.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA23695 for ; Fri, 1 May 1998 19:30:27 +0000 Message-ID: <354A17DB.504B70D5@worldnet.att.net> Date: Fri, 01 May 1998 18:43:39 +0000 From: samuel X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: what constitutes "UNCOOKED" mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a simple question. In manipulating the termios structure I normally set various fields to 0 thereby allowing my program to handle input and output processing of read chars. I was told that this is not equivalent to the "Uncooked mode". can someone explain this what setting does one make to termios structure to set it to this "uncooked mode" thanks Samuel -- Samuel Igwe http://home.att.net/~SAMIGWE SAMIGWE@worldnet.att.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 13:39:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17940 for freebsd-hackers-outgoing; Fri, 1 May 1998 13:39:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17913 for ; Fri, 1 May 1998 13:39:33 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00668; Fri, 1 May 1998 12:36:02 -0700 (PDT) Message-Id: <199805011936.MAA00668@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: samuel cc: freebsd-hackers@FreeBSD.ORG Subject: Re: what constitutes "UNCOOKED" mode In-reply-to: Your message of "Fri, 01 May 1998 18:43:39 -0000." <354A17DB.504B70D5@worldnet.att.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 12:35:59 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have a simple question. In manipulating the termios structure I > normally set various fields to 0 thereby allowing my program to handle > input and output processing of read chars. > > I was told that this is not equivalent to the "Uncooked mode". can > someone explain this > > what setting does one make to termios structure to set it to this > "uncooked mode" 'man cfmakeraw' -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 15:45:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07765 for freebsd-hackers-outgoing; Fri, 1 May 1998 15:45:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ryouko.nas.nasa.gov (ryouko.nas.nasa.gov [129.99.34.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07759 for ; Fri, 1 May 1998 15:45:41 -0700 (PDT) (envelope-from greg@ryouko.nas.nasa.gov) Received: from ryouko.nas.nasa.gov (localhost [127.0.0.1]) by ryouko.nas.nasa.gov (8.8.7/NAS8.8.7) with ESMTP id PAA18558 for ; Fri, 1 May 1998 15:45:29 -0700 (PDT) Message-Id: <199805012245.PAA18558@ryouko.nas.nasa.gov> To: hackers@FreeBSD.ORG Subject: Ethernet address control In-reply-to: Your message of "Fri, 01 May 1998 12:00:28 PDT." <199805011900.MAA01551@hub.freebsd.org> Date: Fri, 01 May 1998 15:45:29 -0700 From: "Gregory P. Smith" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Besides sending out a broadcast ARP response, other possible usages > of this thing include, for example, a slow and inefficient user-level > Ethernet bridge with arbitrary firewall. > > - -Serge (yuck, I user level bridge!) Anyways, more to the point and on a similar topic to the original thread. I added a little hack to NetBSD's BPF so that you can tell it "the header is complete" when using it to send packets. This prevents it from re-writing the hosts's ethernet address into the packet before going on the wire. It was supposedly checked into NetBSDs CVS repository yesterday by thorpej. It adds an ioctl called BIOSHDRCMPLT (and BIOGHDRCMPLT) to set a flag telling BPF to accept the header as it is. I've been meaning to do it for FreeBSD as well but I don't have a lot of time at the moment. [The only box I needed it on was running NetBSD]. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 16:27:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA14030 for freebsd-hackers-outgoing; Fri, 1 May 1998 16:27:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA13944 for ; Fri, 1 May 1998 16:26:37 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: by watermarkgroup.com (4.1/SMI-4.1) id AA22110; Fri, 1 May 98 19:25:24 EDT Date: Fri, 1 May 98 19:25:24 EDT From: luoqi@watermarkgroup.com (Luoqi Chen) Message-Id: <9805012325.AA22110@watermarkgroup.com> To: benedict@echonyc.com, spork@super-g.com Subject: Re: odd network problem Cc: hackers@FreeBSD.ORG, jlp@Part.NET Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Your ISP had a roomful of annexes last time I was there, try to get them > to shift you to the USR boxes they have instead. Annexes basically suck. > We used to use them for dialup and have now converted most of them to > console servers... > > Charles Sprickman > spork@super-g.com > USR boxes have their own problems. For one, they couldn't handle VJ compression correctly. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 18:53:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA08285 for freebsd-hackers-outgoing; Fri, 1 May 1998 18:53:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA08253 for ; Fri, 1 May 1998 18:53:23 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt3-248.HiWAAY.net [208.147.146.248]) by fly.HiWAAY.net (8.8.8/8.8.6) with ESMTP id UAA24048 for ; Fri, 1 May 1998 20:53:21 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id UAA24942 for ; Fri, 1 May 1998 20:52:38 -0500 (CDT) Message-Id: <199805020152.UAA24942@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Subject: cvs woes From: David Kelly Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 20:52:38 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My 2.2.6-stable machine has demonstrated a proclivity to lock up at about the tail end of an "cd /usr/ports && cvs -q update -d" (but only when pppd is dialed out and Netscape Navigator 3.01 is up). Not sure if it really cured the problem but I replaced a year old /etc/login.conf and have run cvs several times now under those conditions without a problem. No problem other than the mess I made crashing while running cvs. Now my src and ports directories are not what they should be. Output looks like this: # cd /usr/ports # cvs -q update -d ? databases/postgresql/work ? editors/nvi-m17n/work ? games/icbm3d ? games/seabattle ? games/xskewb [...] A while back I found a trailing -d on my cvs command line was needed to create new directories found in the cvs repository. Is this correct? Understand the */work auestions but not the rest. So I found some disk space elsewhere an checked out another copy: # cd /r/usr1 # cvs -d /home/ncvs -q checkout -r HEAD ports Then a "diff -r /usr/ports/games/icbm3d /r/usr1/ports/games/icbm3d" indicates the questioned directories are missing CVS directories. Performing a checkout on top of an existing checked out directory doesn't appear to add the missing CVS directories. Have attempted removing the questioned directories. No more complaints from cvs, but the directories are not restored after an update. I use cvsup to update my /home/ncvs. Short of "rm -rf /usr/{ports,src}" and starting over, how can I correct this mess? (/usr/src is in the same state) -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri May 1 21:25:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA02093 for freebsd-hackers-outgoing; Fri, 1 May 1998 21:25:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from roguetrader.com (cold.org [206.81.134.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA02058 for ; Fri, 1 May 1998 21:24:48 -0700 (PDT) (envelope-from brandon@roguetrader.com) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id WAA02525 for ; Fri, 1 May 1998 22:24:58 -0600 (MDT) Date: Fri, 1 May 1998 22:24:57 -0600 (MDT) From: Brandon Gillespie To: freebsd-hackers@FreeBSD.ORG Subject: ftl_init in sio.c (silo overflows, revisited) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I have a 16port BocaBoard. Back on 2.1.0 we got everything working with little to no problems, I've since upgraded to 2.2-GAMMA (970205), and just now 2.2.6. All I have in my notes are: The kernel is patched in sio.c to set ftl_init to 8 instead of 14 to avoid silo overflows. Now, I vaguely remember this, but it seems that 'ftl_init' has disappeared from the source in sio.c, in 2.2.6. I cannot seem to get these errors to go away. Although, by throttling down to 19200 I can reduce the frequency of the errors. The thing is, this used to work fine at 57600, for months, in the 2.2-GAMMA kernel. So where do I look now, to do what I used to be doing with 'ftl_init'? Also, even though I do get these errors, I can connect to the modem (using kermit) and dial back into another modem on the same board--the AT commands seem to work OK, (every thing is echoed without problem), but when I connect up to the other modem all I receive is garbage. Now I also vaguely recall doing something else here--but once again I cannot place what it was. I have /etc/rc.serial setting the rate to 19200, I have the getty using std.19200, I have run over these things several times, and cannot understand (or remember) why this is happening. Any suggestions? -Brandon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 03:07:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA29375 for freebsd-hackers-outgoing; Sat, 2 May 1998 03:07:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA29364 for ; Sat, 2 May 1998 03:07:07 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id CAA26152 for ; Sat, 2 May 1998 02:57:48 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd026150; Sat May 2 09:57:45 1998 Message-ID: <354AECCC.41C67EA6@whistle.com> Date: Sat, 02 May 1998 02:52:12 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: C-BASIC anyone? (only oldies need apply :-) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have resurected an old project of mine that I did in 1988. (they payed me) It's CBASIC (yes CP/M's C-BASIC) to UNIC/C translater. It ran in production for years. I've decided to get it up on FreeBSD.. (now that the original owners have sold the business and written off the software. :-) you can find the first port attempt at: http://www.freebsd.org/~julian What I'm looking for is anyone who actually might have some old BASIC (any basic will do, but CBASIC would be best) programs lying around for testing. :-) I can hardly remember basic, even though I wrote the dammed compiler :-) P.s. if there are any LEX/FLEX experts out there I'm hoping someone can tell me how to tell the program to use it's own 'input()' rather than the one that flex supplies. in Lex this was easy.. (patches to my program will be accepted :-) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 03:26:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA01306 for freebsd-hackers-outgoing; Sat, 2 May 1998 03:26:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA01299 for ; Sat, 2 May 1998 03:26:33 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id UAA08667; Sat, 2 May 1998 20:28:09 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199805021028.UAA08667@cimlogic.com.au> Subject: Re: C-BASIC anyone? (only oldies need apply :-) In-Reply-To: <354AECCC.41C67EA6@whistle.com> from Julian Elischer at "May 2, 98 02:52:12 am" To: julian@whistle.com (Julian Elischer) Date: Sat, 2 May 1998 20:28:09 +1000 (EST) Cc: hackers@FreeBSD.ORG 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > I have resurected an old project of mine that I did in 1988. > (they payed me) > > It's CBASIC (yes CP/M's C-BASIC) to UNIC/C translater. > It ran in production for years. I've decided to get it > up on FreeBSD.. (now that the original owners have sold the business > and written off the software. :-) Haven't you got anything better to do?! -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 06:50:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA23639 for freebsd-hackers-outgoing; Sat, 2 May 1998 06:50:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from news.uni-kl.de (mmdf@news.uni-kl.de [131.246.137.51]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA23572 for ; Sat, 2 May 1998 06:49:50 -0700 (PDT) (envelope-from mheller@student.uni-kl.de) Received: from alma.student.uni-kl.de by news.news.uni-kl.de id aa02135; 2 May 98 15:48 MET DST Received: from mater.student.uni-kl.de(really [131.246.90.23]) by alma.student.uni-kl.de via smtpd with smtp id for ; Sat, 2 May 1998 15:48:40 +0200 (CETDST) (Smail-3.2.0.95 1997-May-7 #5 built 1997-May-16) Received: from localhost by mater.student.uni-kl.de with smtp (Smail3.1.28.1 #1) id m0yVcef-0001gwC; Sat, 2 May 98 15:48 CETDST Date: Sat, 2 May 1998 15:48:41 +0200 (CETDST) From: Martin Heller To: dk+@ua.net cc: Peter Jeremy , freebsd-hackers@FreeBSD.ORG Subject: Re: VM architecture (was Re: Protected mode instructions which reduce In-Reply-To: <199805011730.KAA28217@dog.farm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 1 May 1998, Dmitry Kohmanyuk wrote: > In article <199804262144.HAA29582@gsms01.alcatel.com.au> you wrote: > [...] > > On Fri, 24 Apr 1998 06:22:59 +0000 (GMT), Terry Lambert wrote: > > >The IBM VM architecture is logically complete -- that is, nearly all > > >of the instruction emulation implementation is in hardware, > > The VM kernel needs to provide a `virtual supervisor' mode. This can > > be quite expensive in software, so IBM provided microcode assist units > > which effectively made `virtual supervisor' mode part of the hardware > > machine mode. Pity that modern microprocessors don't have writable > > microcode. > > they do; modern Pentium series (starting with PPro if my memory serves > me right) contain user-modifyable area. Yep, the first processor from Intel to be able to do this was PPro. DEC Alpha processors have a more sophisticated approach from the beginning. This facility, known as PAL-code, is used to modify the processor for the operating system. > The Pentium F00F bug release from Intel specifically said that this bug > has to be dealt with in software because Pentiums are not updateable. I'm not shure if PPro and PII are updateable in such a way to fix something like this ... The only architecture known to me who can do this is the Alpha architecture from DEC. MARTIN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 07:17:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA27161 for freebsd-hackers-outgoing; Sat, 2 May 1998 07:17:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA27153 for ; Sat, 2 May 1998 07:16:58 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id OAA24110; Sat, 2 May 1998 14:16:52 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA08837; Sat, 2 May 1998 16:16:36 +0200 (MET DST) Message-ID: <19980502161636.40296@follo.net> Date: Sat, 2 May 1998 16:16:36 +0200 From: Eivind Eklund To: David Kelly , hackers@FreeBSD.ORG Subject: Re: cvs woes References: <199805020152.UAA24942@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199805020152.UAA24942@nospam.hiwaay.net>; from David Kelly on Fri, May 01, 1998 at 08:52:38PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, May 01, 1998 at 08:52:38PM -0500, David Kelly wrote: [... of directories CVS don't know about ...] > Have attempted removing the questioned directories. No more complaints > from cvs, but the directories are not restored after an update. > > I use cvsup to update my /home/ncvs. > > Short of "rm -rf /usr/{ports,src}" and starting over, how can I correct > this mess? (/usr/src is in the same state) The above is a result of CVS being 'somewhat less than graceful' about not having enough memory. When adding directories, it should really update CVS/Entries in a two-phase commit before actually extracting the directory. This would let it fail gracefully (ie, a new 'cvs update' would bring it to the correct state). Now, since it doesn't, you're more or less screwed. What you can do: Blow the unknown directories away and do a 'cvs update' (simplest). This should get you up to date correctly, unless you've got patches in the unknown directories. The below will probably get you up to date correctly no matter what, but involves 'more magic' and is only slightly tested (ie, I looked the output over without the shell pipe, but I didn't actually _run_ it :-) cvs update 2> /dev/null | perl -ne 'if (/^\? (.*)\/(.*)/ && -d "$1/CVS") {print "(cd $1 && echo \"D/$2////\" >> CVS/Entries)\n";} elsif(/^\? (.*)/ && -d "$1/CVS") {print "echo \"D/$1////\" >> CVS/Entries\n"};' | csh This run through the output of cvs, checks for any unknown directories which has a CVS subdir, and add those to CVS/Entries of the parent directory. You will have to run it several times if the subdirs of the newly added subdirs are missing their CVS/Entries entries, and it won't solve any piece where the CVS subdir of a subdir hasn't been created at all. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 07:32:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29906 for freebsd-hackers-outgoing; Sat, 2 May 1998 07:32:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from casparc.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA29869 for ; Sat, 2 May 1998 07:32:03 -0700 (PDT) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0yVdKc-002ZjeC; Sat, 2 May 98 16:32 MET DST Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Sat, 2 May 1998 16:08:03 +0200 (CEST) (Smail-3.2.0.91 1997-Jan-14 #3 built 1998-Feb-14) Received: by bert.kts.org via sendmail with stdio id for freebsd-hackers@freebsd.org; Sat, 2 May 1998 16:04:25 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #7 built 1997-Jul-4) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: bpf needs in network drivers To: freebsd-hackers@FreeBSD.ORG (FreeBSD Hackers) Date: Sat, 2 May 1998 16:04:25 +0200 (CEST) Organization: Kitchen Table Systems Reply-To: hm@kts.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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, in case i do a bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); in a network (IP over ISDN, not PPP!) device driver, i obviously have to prepend sizeof(u_int) to each mbuf i sent to bpf, is this correct ? What do i have to put into this sizeof(u_int) (for bpf/tcpdump) ? Is it possible to do a bpfattach(&sc->sc_if, DLT_NULL, 0); and prepend nothing ? hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe "Those who can, do. Those who can't, talk. And those who can't talk, talk about talking." (B. Shaw) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 07:47:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02631 for freebsd-hackers-outgoing; Sat, 2 May 1998 07:47:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dragon.ham.muohio.edu (howardjp@dragon.ham.muohio.edu [134.53.147.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA02598 for ; Sat, 2 May 1998 07:47:41 -0700 (PDT) (envelope-from howardjp@dragon.ham.muohio.edu) Received: from localhost (howardjp@localhost) by dragon.ham.muohio.edu (8.8.5/8.8.5) with SMTP id KAA20547 for ; Sat, 2 May 1998 10:19:28 -0400 Date: Sat, 2 May 1998 10:19:28 -0400 (EDT) From: Jamie Howard To: freebsd-hackers@FreeBSD.ORG Subject: Boot floppy. In-Reply-To: <3541F04D.474FE994@ibm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'd like to create a FreeBSD boot floppy that will automatically start 1:sd(0,a)kernel (or whatever) at start up. How can this be done? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 08:28:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07140 for freebsd-hackers-outgoing; Sat, 2 May 1998 08:28:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA06961 for ; Sat, 2 May 1998 08:27:18 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id PAA27433; Sat, 2 May 1998 15:27:14 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA09003; Sat, 2 May 1998 17:26:58 +0200 (MET DST) Message-ID: <19980502172658.27233@follo.net> Date: Sat, 2 May 1998 17:26:58 +0200 From: Eivind Eklund To: Jamie Howard , freebsd-hackers@FreeBSD.ORG Subject: Re: Boot floppy. References: <3541F04D.474FE994@ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Jamie Howard on Sat, May 02, 1998 at 10:19:28AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, May 02, 1998 at 10:19:28AM -0400, Jamie Howard wrote: > Hi, I'd like to create a FreeBSD boot floppy that will automatically start > 1:sd(0,a)kernel (or whatever) at start up. How can this be done? Look at /usr/src/release/Makefile. Apart from that, you can probably do the above by just initializing a floppy with newfs -B, and putting in a boot.config file on it. 'man 8 boot' for details. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 08:46:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10379 for freebsd-hackers-outgoing; Sat, 2 May 1998 08:46:55 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10370 for ; Sat, 2 May 1998 08:46:41 -0700 (PDT) (envelope-from mike@ns1.seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with SMTP id LAA07378; Sat, 2 May 1998 11:45:36 -0400 (EDT) Date: Sat, 2 May 1998 11:45:36 -0400 (EDT) From: Mike To: Luoqi Chen cc: benedict@echonyc.com, spork@super-g.com, hackers@FreeBSD.ORG, jlp@Part.NET Subject: Re: odd network problem In-Reply-To: <9805012325.AA22110@watermarkgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 1 May 1998, Luoqi Chen wrote: > USR boxes have their own problems. For one, they couldn't handle VJ > compression correctly. That's true... we just spent $300,000 on POP upgrades (taking a few sites to the new Enterprise Network Hubs with PRI interfaces - gotta be 100% digital on our end or the customers throw fits, ya know ;). There were more installation and initial problems than I wanted to see considering what we paid for the boxes, but overall the products (and the support you get from 3com) have made be pretty happy (so far, knock on wood). I'm curious as to whether the 'port 5000' issue described in AntiOnline's I/O (http://www.antionline.com/io/issue2/4.html) is due to a misconfiguration on the administrator's part of it it's just standard behavior on Annex boxes. Mike Hoskins SEI Data Network Services, Inc. noc@seidata.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 09:10:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13423 for freebsd-hackers-outgoing; Sat, 2 May 1998 09:10:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13410 for ; Sat, 2 May 1998 09:10:38 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from skejdbrimir.ifi.uio.no (skejdbrimir.ifi.uio.no [129.240.65.2]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with SMTP id SAA04866; Sat, 2 May 1998 18:10:24 +0200 (MET DST) Received: from localhost (dag-erli@localhost) by skejdbrimir.ifi.uio.no ; Sat, 2 May 1998 16:10:23 GMT Mime-Version: 1.0 To: samuel Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: what constitutes "UNCOOKED" mode References: <354A17DB.504B70D5@worldnet.att.net> Organization: Gutteklubben Terrasse / KRST / PUMS / YASMW X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-Stop-Spam: http://www.cauce.org From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 02 May 1998 18:10:15 +0200 In-Reply-To: samuel's message of "Fri, 01 May 1998 18:43:39 +0000" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG samuel writes: > I have a simple question. In manipulating the termios structure I > normally set various fields to 0 thereby allowing my program to handle > input and output processing of read chars. Did you watch the load on your machine while your program ran? If you set all fields to 0, you put the terminal in raw, non-blocking mode, which means you are busy-looping reading EOF. Very suboptimal. Use cfmakeraw() instead (unfortunately, many widespread commercial Unices lack it so it's not very portable) -- Noone else has a .sig like this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 11:57:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA04864 for freebsd-hackers-outgoing; Sat, 2 May 1998 11:57:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA04853 for ; Sat, 2 May 1998 11:57:14 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA05665; Sat, 2 May 1998 11:54:13 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd005663; Sat May 2 18:54:07 1998 Date: Sat, 2 May 1998 11:48:34 -0700 (PDT) From: Julian Elischer To: Jamie Howard cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Boot floppy. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG get a regular floppy format it disklabel it (that will add bootblocks, if not use th e-B option ot explicitly add them) newfs it mount it add one file, (boot.config) with "1:sd(0,a)/kernel" as the contents. unmount it.. try it.. On Sat, 2 May 1998, Jamie Howard wrote: > Hi, I'd like to create a FreeBSD boot floppy that will automatically start > 1:sd(0,a)kernel (or whatever) at start up. How can this be done? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 12:28:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09529 for freebsd-hackers-outgoing; Sat, 2 May 1998 12:28:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09418 for ; Sat, 2 May 1998 12:27:55 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id PAA06575; Sat, 2 May 1998 15:26:52 -0400 (EDT) Date: Sat, 2 May 1998 15:26:52 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com Reply-To: spork To: am@f1.ru cc: hackers@FreeBSD.ORG Subject: Re: threads performance In-Reply-To: <199805011835.WAA00793@px.f1.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yeah, I had to do some ugly hacks to get mit-pthreads to work under 3.0, but we've seen much better performance and longer uptimes. We're coming up on a week without restarting it, which is a major landmark. Charles Sprickman spork@super-g.com ---- On Fri, 1 May 1998, Andrew Maltsev wrote: > > Any recommendations on what to do to get the best performance here? I'd > > give up a CPU if I could get more stability and an easier target for Monty > > to troubleshoot on. Anyone else here use mysql? Any opinions? Should I > > try again with MIT-pthreads? > > I'm using. And have no luck with freebsd's libc_r, so my mysql is > compiled with mit-threads. No problems - uptime is about month now - > except mit-thr doesn't support unix-sockets. > > px# mysqladmin st > > Uptime: 2257747 Running threads: 1 Questions: 440811 Reloads: 3 Open tables: 33 > > It's on db of about 12 megs and 30'000 records. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 15:19:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25610 for freebsd-hackers-outgoing; Sat, 2 May 1998 15:19:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25596 for ; Sat, 2 May 1998 15:19:07 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: from localhost (fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) with SMTP id RAA08317; Sat, 2 May 1998 17:18:39 -0500 (CDT) Date: Sat, 2 May 1998 17:18:39 -0500 (CDT) From: "Matthew D. Fuller" To: John Birrell cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: C-BASIC anyone? (only oldies need apply :-) In-Reply-To: <199805021028.UAA08667@cimlogic.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 2 May 1998, John Birrell wrote: > Julian Elischer wrote: > > I have resurected an old project of mine that I did in 1988. > > (they payed me) > > > > It's CBASIC (yes CP/M's C-BASIC) to UNIC/C translater. > > It ran in production for years. I've decided to get it > > up on FreeBSD.. (now that the original owners have sold the business > > and written off the software. :-) > > Haven't you got anything better to do?! What could be better? The world needs more GOTO's... *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 18:50:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24584 for freebsd-hackers-outgoing; Sat, 2 May 1998 18:50:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA24517 for ; Sat, 2 May 1998 18:50:14 -0700 (PDT) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id LAA03513; Sun, 3 May 1998 11:20:07 +0930 (CST) (envelope-from grog) Message-ID: <19980503112007.E3202@freebie.lemis.com> Date: Sun, 3 May 1998 11:20:07 +0930 From: Greg Lehey To: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: C-BASIC anyone? (only oldies need apply :-) References: <354AECCC.41C67EA6@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <354AECCC.41C67EA6@whistle.com>; from Julian Elischer on Sat, May 02, 1998 at 02:52:12AM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 2 May 1998 at 2:52:12 -0700, Julian Elischer wrote: > I have resurected an old project of mine that I did in 1988. > (they payed me) Well, I hope. > I can hardly remember basic, even though I wrote the dammed compiler > :-) I thought that was a requirement for most compilers. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 19:27:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA02965 for freebsd-hackers-outgoing; Sat, 2 May 1998 19:27:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from monk.via.net (monk.via.net [209.81.9.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA02939 for ; Sat, 2 May 1998 19:26:57 -0700 (PDT) (envelope-from joe@via.net) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id TAA22481; Sat, 2 May 1998 19:22:53 -0700 Date: Sat, 2 May 1998 19:22:53 -0700 From: Joe McGuckin Message-Id: <199805030222.TAA22481@monk.via.net> To: dk+@ua.net, mheller@student.uni-kl.de Subject: Re: VM architecture (was Re: Protected mode instructions which reduce Cc: peter.jeremy@alcatel.com.au, freebsd-hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Don't forget, the VAX had a WCS (writable control store) option. You could write custom instruction sets. The Pentium II does have the ability to update its microcode at boot-time. Many of the newer BIOS's support this feature. joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 19:38:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA05988 for freebsd-hackers-outgoing; Sat, 2 May 1998 19:38:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05810; Sat, 2 May 1998 19:37:53 -0700 (PDT) (envelope-from dwhite@gdi.uoregon.edu) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.7/8.8.8) with SMTP id TAA21458; Sat, 2 May 1998 19:37:50 -0700 (PDT) (envelope-from dwhite@gdi.uoregon.edu) Date: Sat, 2 May 1998 19:37:50 -0700 (PDT) From: Doug White Reply-To: Doug White To: Omar Thameen cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: login.conf and "daemon" class In-Reply-To: <19980430014743.28030@clifford.inch.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 30 Apr 1998, Omar Thameen wrote: > Now /etc/rc.local is also called from /etc/rc, so I assume the same > class "daemon" restrictions apply - is this correct? Yes, the login class info is inherited between shells. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 21:37:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA29653 for freebsd-hackers-outgoing; Sat, 2 May 1998 21:37:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA29637 for ; Sat, 2 May 1998 21:37:22 -0700 (PDT) (envelope-from dwhite@gdi.uoregon.edu) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.7/8.8.8) with SMTP id VAA21700 for ; Sat, 2 May 1998 21:37:20 -0700 (PDT) (envelope-from dwhite@gdi.uoregon.edu) Date: Sat, 2 May 1998 21:37:20 -0700 (PDT) From: Doug White Reply-To: Doug White To: hackers@FreeBSD.ORG Subject: named upgrade Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! Any time estimates on when BIND 4.9.7 is going into the source tree, and/or is someone working on it? Now that 4.9.6 is vulnerable to major security bugs we need to accelerate this upgrade. Thanks! Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat May 2 22:46:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11824 for freebsd-hackers-outgoing; Sat, 2 May 1998 22:46:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dt050n33.san.rr.com (@dt050n33.san.rr.com [204.210.31.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11792 for ; Sat, 2 May 1998 22:46:06 -0700 (PDT) (envelope-from Studded@san.rr.com) Received: from san.rr.com (Studded@localhost [127.0.0.1]) by dt050n33.san.rr.com (8.8.8/8.8.8) with ESMTP id WAA01024; Sat, 2 May 1998 22:46:05 -0700 (PDT) (envelope-from Studded@san.rr.com) Message-ID: <354C049D.4180F5BC@san.rr.com> Date: Sat, 02 May 1998 22:46:05 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE-0502 i386) MIME-Version: 1.0 To: Doug White CC: hackers@FreeBSD.ORG Subject: Re: named upgrade References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug White wrote: > > Hello! > > Any time estimates on when BIND 4.9.7 is going into the source tree, > and/or is someone working on it? Now that 4.9.6 is vulnerable to major > security bugs we need to accelerate this upgrade. Peter was working on it today. I just cvsup'ed and built -stable and named is 4.9.7-T1b. It's also in -current for now, although he's upping that to the 8.1.2 beta. Paul Vixie wants to put out the gold versions of both in the next few days but the word is that the changes between the last beta and the gold versions are small. Doug -- *** Chief Operations Officer, DALnet IRC network *** *** Proud designer and maintainer of the world's largest Internet *** Relay Chat server with 5,328 simultaneous connections. *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message