From owner-freebsd-hackers Sun Dec 14 00:02:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA19633 for hackers-outgoing; Sun, 14 Dec 1997 00:02:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA19627; Sun, 14 Dec 1997 00:02:32 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id AAA00554; Sun, 14 Dec 1997 00:02:57 -0800 Date: Sun, 14 Dec 1997 00:02:57 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio Reply-To: Jason Evans To: "John S. Dyson" cc: Terry Lambert , jkh@time.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port In-Reply-To: <199712130043.TAA03452@dyson.iquest.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, 12 Dec 1997, John S. Dyson wrote: > I don't have a Sparc manual yet, but it is likely that if you want a > referenced bit, you have to emulate it. If you don't want to emulate > it, I can add about 20 or so lines of code to the upper level VM so > that it isn't needed for now. (Actually, it is likely that the referenced > bit managment isn't needed, for a 1st pass -- get it working -- port.) You're right, there is no explicit referenced bit. There are 13 extra bits available though. Will we need any of them for anything else (13 sounds like plenty)? > I wouldn't try to make the port "perfect" in the first pass, but once > it is sort-of running, it will be easier for more people to work on it. I think this needs to be the attitude all the way around on the initial pass. The UltraSPARC has tons of features that, if used correctly, provide incredible performance gains. First, it just needs to work though. Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Sun Dec 14 00:19:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20380 for hackers-outgoing; Sun, 14 Dec 1997 00:19:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20372 for ; Sun, 14 Dec 1997 00:19:38 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id BAA07657; Sun, 14 Dec 1997 01:17:39 -0700 (MST) Date: Sun, 14 Dec 1997 01:17:39 -0700 (MST) Message-Id: <199712140817.BAA07657@narnia.plutotech.com> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <199712140658.WAA09916@rah.star-gate.com> In-Reply-To: <199712140658.WAA09916@rah.star-gate.com> From: gibbs@narnia.plutotech.com (Justin T. Gibbs) Subject: Bus/Processor specific I/O methods - was Re: Beginning SPARC port X-Original-Newsgroups: pluto.freebsd.hackers To: Amancio Hasty cc: hackers@FreeBSD.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk NetBSD has already dealt with this issue. It's called "bus.h". All of the new CAM SCSI drivers use a FreeBSD version of this file to perform device I/O. It also covers DMA and in fact the ISA bounce buffers that are used in CAM use "bus DMA" instead of the older bounce buffer scheme used in current. We shouldn't re-invent the wheel unless there are sound reasons to do so. Please review these files from a recent CAM snapshot to see if this is an acceptable solution to the problem: sys/i386/include/bus.h sys/i386/i386/busdma_machdep.c And to see how the APIs are used: sys/dev/aic7xxx/aic7xxx.h sys/dev/aic7xxx/aic7xxx.c sys/pci/ahc_pci.c These files are available in diff format in the archive: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/cam-971209.diffs.gz -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== From owner-freebsd-hackers Sun Dec 14 00:25:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20824 for hackers-outgoing; Sun, 14 Dec 1997 00:25:53 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 AAA20816 for ; Sun, 14 Dec 1997 00:25:46 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id AAA10506; Sun, 14 Dec 1997 00:25:37 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712140825.AAA10506@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: gibbs@narnia.plutotech.com (Justin T. Gibbs) cc: hackers@FreeBSD.org Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 01:17:39 MST." <199712140817.BAA07657@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 00:25:37 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Cool, a sane posting regarding this issue and right on target! I will review it however is going to take a little time over here because I have a queue of freebsd related small projects. Hopefully, your posting should be sufficient to anchor the discussion and further developments. Best Regards, Amancio > NetBSD has already dealt with this issue. It's called "bus.h". All > of the new CAM SCSI drivers use a FreeBSD version of this file to > perform device I/O. It also covers DMA and in fact the ISA bounce > buffers that are used in CAM use "bus DMA" instead of the older > bounce buffer scheme used in current. We shouldn't re-invent the > wheel unless there are sound reasons to do so. Please review these > files from a recent CAM snapshot to see if this is an acceptable > solution to the problem: > > sys/i386/include/bus.h > sys/i386/i386/busdma_machdep.c > > And to see how the APIs are used: > sys/dev/aic7xxx/aic7xxx.h > sys/dev/aic7xxx/aic7xxx.c > sys/pci/ahc_pci.c > > These files are available in diff format in the archive: > > ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/cam-971209.diffs.gz > > -- > Justin T. Gibbs > =========================================== > FreeBSD - Turning PCs into workstations > =========================================== From owner-freebsd-hackers Sun Dec 14 00:33:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21360 for hackers-outgoing; Sun, 14 Dec 1997 00:33:38 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 AAA21354 for ; Sun, 14 Dec 1997 00:33:33 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id AAA15237; Sun, 14 Dec 1997 00:32:38 -0800 (PST) To: Luigi Rizzo cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed code merge, objections? In-reply-to: Your message of "Sun, 14 Dec 1997 07:33:58 +0100." <199712140633.HAA01277@labinfo.iet.unipi.it> Date: Sun, 14 Dec 1997 00:32:38 -0800 Message-ID: <15233.882088358@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I was referring to the aio driver or other potentially interesting > device drivers/kernel modules in -current (I have no current > examples, but in the past it took some time to integrate the Bt848 > and the kernel bootp support). Same rules apply. :) Jordan From owner-freebsd-hackers Sun Dec 14 00:40:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21695 for hackers-outgoing; Sun, 14 Dec 1997 00:40:15 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 AAA21690 for ; Sun, 14 Dec 1997 00:40:11 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA13044; Sun, 14 Dec 1997 00:35:29 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd013039; Sun Dec 14 00:35:23 1997 Date: Sun, 14 Dec 1997 00:32:45 -0800 (PST) From: Julian Elischer To: Joerg Wunsch cc: freebsd-hackers@freebsd.org Subject: Re: Proposed code merge, objections? In-Reply-To: <199712131504.QAA22341@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 iHmmmmmm I thought that new drivers (that don't change existing functionality) could be ADDED to -stable if deemed sufficiently useful, and they have proved themselves in -current. On Sat, 13 Dec 1997, J Wunsch wrote: > "J. Weatherbee - Senior Systems Architect" wrote: > > > I've been told there is no official policy on this, so I want some > > feedback. I am considering currently a merge of the alog driver > > (Industrial Computer Source AIO8-P) into -stable. > > -stable is not meant to accumulate new features from -current. Unless > there are strong reasons, new drivers should not migrate there. This > _is_ official policy. > > -- > 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 Dec 14 00:45:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA22007 for hackers-outgoing; Sun, 14 Dec 1997 00:45:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from superior.mooseriver.com (dynamic42.pm04.sf3d.best.com [209.24.234.234]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA22001 for ; Sun, 14 Dec 1997 00:45:48 -0800 (PST) (envelope-from jgrosch@superior.mooseriver.com) Received: (from jgrosch@localhost) by superior.mooseriver.com (8.8.7/8.8.5) id AAA00516; Sun, 14 Dec 1997 00:45:47 -0800 (PST) Message-ID: <19971214004546.03594@mooseriver.com> Date: Sun, 14 Dec 1997 00:45:46 -0800 From: Josef Grosch To: hackers@freebsd.org Subject: weird IP address 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 While sending out hate mail to the latest round of spammers I got an answer back from nslookup that I just do not understand. I got spam from MoneyMakers.com. When I did an nslookup I got the following: superior% nslookup moneymakers.com Server: superior.mooseriver.com Address: 205.166.121.5 Non-authoritative answer: Name: moneymakers.com Address: 1.1.1.1 ^^^^^^^ Josef -- Josef Grosch | Another day closer to a | FreeBSD 2.2.5 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses From owner-freebsd-hackers Sun Dec 14 01:00:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA22667 for hackers-outgoing; Sun, 14 Dec 1997 01:00:23 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 BAA22661 for ; Sun, 14 Dec 1997 01:00:19 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA13341; Sun, 14 Dec 1997 01:00:01 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd013324; Sun Dec 14 00:59:59 1997 Date: Sun, 14 Dec 1997 00:57:20 -0800 (PST) From: Julian Elischer To: Terry Lambert cc: Mike Smith , bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-Reply-To: <199712132055.NAA29304@usr06.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 > One "incidental" piece of parametric information I am interested in > seeing is the physical block size. This is already propogated up.. BTW terry isn't UFS restricted to making dir entries in FRAG sizes rather than physical blocksizes? From owner-freebsd-hackers Sun Dec 14 01:08:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA23113 for hackers-outgoing; Sun, 14 Dec 1997 01:08:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA23106 for ; Sun, 14 Dec 1997 01:08:50 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.5/8.8.5) with ESMTP id DAA16789; Sun, 14 Dec 1997 03:08:40 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199712140222.MAA04796@word.smith.net.au> References: Your message of "Sat, 13 Dec 1997 20:55:27 -0000." <199712132055.NAA29304@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 14 Dec 1997 03:00:11 -0600 To: Mike Smith From: Richard Wackerbarth Subject: Re: blocksize on devfs entries (and related) Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 8:22 PM -0600 12/13/97, Mike Smith wrote: >> Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks >> are not constrained to start at an even offset from the start of the >> disk, only from an even cylinder boundry. > >In the light of the nonexistence of "cylinders" in the proposed model, >it strikes me that this becomes an issue of synthesising a conforming >pseudo-geometry at filesystem creation time, and little more. >Compatability is likely an issue there. Compatability is an issue in that the system must be able to accept and create file systems that are acceptable to a foreign OS. Otherwise, why bother with all these exotic file systems :-) This is particularly important with removable media. Richard Wackerbarth From owner-freebsd-hackers Sun Dec 14 01:50:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA24899 for hackers-outgoing; Sun, 14 Dec 1997 01:50:41 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 BAA24887 for ; Sun, 14 Dec 1997 01:50:28 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA07085; Sun, 14 Dec 1997 01:50:03 -0800 (PST) Message-ID: <19971214015002.48331@hydrogen.nike.efn.org> Date: Sun, 14 Dec 1997 01:50:02 -0800 From: John-Mark Gurney To: "Justin T. Gibbs" Cc: Amancio Hasty , hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port References: <199712140658.WAA09916@rah.star-gate.com> <199712140817.BAA07657@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712140817.BAA07657@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Dec 14, 1997 at 01:17:39AM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs scribbled this message on Dec 14: > NetBSD has already dealt with this issue. It's called "bus.h". All > of the new CAM SCSI drivers use a FreeBSD version of this file to > perform device I/O. It also covers DMA and in fact the ISA bounce > buffers that are used in CAM use "bus DMA" instead of the older > bounce buffer scheme used in current. We shouldn't re-invent the > wheel unless there are sound reasons to do so. Please review these > files from a recent CAM snapshot to see if this is an acceptable > solution to the problem: in my opinion, they didn't go far enough... they still have seperate structures for each bus... and their resource is bus dependant.. there isn't a common structure between all busses... with my code, very little will actually have to be done to allow devices to be used between bus types... and if the interface to the bus isn't radicly different (like supporting same memory/io/interrupt) sets, the only difference will be the probe code... the hardest part of the whole thing though, is to some how create a way for common resources to be able to use keys... because if your trying to do dma with channel one on the first isa bus, how do you tell the different between dma channel one on the second bus... so far, the only way that I've come up with a way to solve this is to pass back three parameters when the device allocates a resource... this is a function pointer, a device pointer (an interrupt handler is a device just like a dma controller or an ethernet card is, and will require a device entry along with other devices) and the special parameter that identifies the resource (like irq number or dma number).. we can make a special exception though... and that would be for memory and io port accesses... which I think should either ALWAYS use a macro along with the parameter passed back (for access), or compare against the function pointer for possible "constants"... the former is probably better than the later... right now the latest specs for the bus/device code is at: http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html I've started working on code (I've written the header files).. but right now I'm working on some B-tree code first... hopefully I'll have something that will be usable in the next few weeks.. -- 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 Sun Dec 14 01:53:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA25068 for hackers-outgoing; Sun, 14 Dec 1997 01:53:03 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 BAA25053 for ; Sun, 14 Dec 1997 01:52:54 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 26134 invoked by uid 1001); 14 Dec 1997 09:52:49 +0000 (GMT) To: jgrosch@superior.mooseriver.com Cc: hackers@FreeBSD.ORG Subject: Re: weird IP address In-Reply-To: Your message of "Sun, 14 Dec 1997 00:45:46 -0800" References: <19971214004546.03594@mooseriver.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 14 Dec 1997 10:52:49 +0100 Message-ID: <26132.882093169@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > While sending out hate mail to the latest round of spammers I got an answer > back from nslookup that I just do not understand. I got spam from > MoneyMakers.com. When I did an nslookup I got the following: > > superior% nslookup moneymakers.com > Server: superior.mooseriver.com > Address: 205.166.121.5 > > Non-authoritative answer: > Name: moneymakers.com > Address: 1.1.1.1 My guess is that they're doing that precisely to keep you from responding. You'll find: moneymakers.com. 288800 MX 10 mail.moneymakers.com. ftp.moneymakers.com. 288800 A 1.1.1.1 mail.moneymakers.com. 288800 A 1.1.1.1 www.moneymakers.com. 288800 A 1.1.1.1 So they're doing everything they can to prevent you from responding to their spam. Try looking at the Received: lines for some (possibly) more relevant info. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sun Dec 14 01:56:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA25258 for hackers-outgoing; Sun, 14 Dec 1997 01:56:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25253 for ; Sun, 14 Dec 1997 01:56:01 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id BAA03216; Sun, 14 Dec 1997 01:56:10 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd003214; Sun Dec 14 01:56:03 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id BAA12602; Sun, 14 Dec 1997 01:55:52 -0800 (PST) From: Ulf Zimmermann Message-Id: <199712140955.BAA12602@Gatekeeper.Alameda.net> Subject: Re: weird IP address In-Reply-To: <19971214004546.03594@mooseriver.com> from Josef Grosch at "Dec 14, 97 00:45:46 am" To: jgrosch@superior.mooseriver.com Date: Sun, 14 Dec 1997 01:55:52 -0800 (PST) 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 > While sending out hate mail to the latest round of spammers I got an answer > back from nslookup that I just do not understand. I got spam from > MoneyMakers.com. When I did an nslookup I got the following: > > superior% nslookup moneymakers.com > Server: superior.mooseriver.com > Address: 205.166.121.5 > > Non-authoritative answer: > Name: moneymakers.com > Address: 1.1.1.1 > ^^^^^^^ Very simple. Most people now reject email from not existing domains. So they created the domain and put into their name server at NS.PROPAGATION.COM and NS2.PROPAGATION.COM the IP number of 1.1.1.1. It is a kind of real IP number, even it is not in use. (First class A network). > > > Josef > > -- > Josef Grosch | Another day closer to a | FreeBSD 2.2.5 > jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses > > Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Sun Dec 14 02:54:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA27786 for hackers-outgoing; Sun, 14 Dec 1997 02:54:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA27775 for ; Sun, 14 Dec 1997 02:54:37 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712141054.CAA27775@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA084596834; Sun, 14 Dec 1997 21:53:54 +1100 From: Darren Reed Subject: SPARC issues. To: hackers@freebsd.org Date: Sun, 14 Dec 1997 21:53:54 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can we have freebsd-sparc@freebsd.org please ? Darren From owner-freebsd-hackers Sun Dec 14 02:59:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA28059 for hackers-outgoing; Sun, 14 Dec 1997 02:59:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mutara.noc.erols.net (gjp@mutara.noc.erols.net [207.172.25.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA28042 for ; Sun, 14 Dec 1997 02:59:08 -0800 (PST) (envelope-from gjp@mutara.noc.erols.net) Received: (from gjp@localhost) by mutara.noc.erols.net (8.8.8/8.8.7) id FAA18630; Sun, 14 Dec 1997 05:59:06 -0500 (EST) Date: Sun, 14 Dec 1997 05:59:06 -0500 (EST) Message-Id: <199712141059.FAA18630@mutara.noc.erols.net> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <26132.882093169@verdi.nethelp.no> From: gjp@erols.net (Gary Palmer) Subject: Re: weird IP address X-Original-Newsgroups: lists.freebsd.hackers To: hackers@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In article <26132.882093169@verdi.nethelp.no>, sthaug@nethelp.no writes: > My guess is that they're doing that precisely to keep you from responding. > You'll find: > > moneymakers.com. 288800 MX 10 mail.moneymakers.com. > ftp.moneymakers.com. 288800 A 1.1.1.1 > mail.moneymakers.com. 288800 A 1.1.1.1 > www.moneymakers.com. 288800 A 1.1.1.1 > > So they're doing everything they can to prevent you from responding to > their spam. Try looking at the Received: lines for some (possibly) more > relevant info. If it was the same stuff I pulled from our spools here, its sent from a Netcom dialin through their dfw mail servers. Makes me wish that Netcom management had let Mark keep the anti-spam mail checks in place ... sigh Gary From owner-freebsd-hackers Sun Dec 14 03:08:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA28553 for hackers-outgoing; Sun, 14 Dec 1997 03:08:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA28542 for ; Sun, 14 Dec 1997 03:08:15 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712141108.DAA28542@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA087377662; Sun, 14 Dec 1997 22:07:42 +1100 From: Darren Reed Subject: Re: Beginning SPARC port To: tlambert@primenet.com (Terry Lambert) Date: Sun, 14 Dec 1997 22:07:41 +1100 (EDT) Cc: jasone@canonware.com, jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199712130002.RAA17704@usr04.primenet.com> from "Terry Lambert" at Dec 13, 97 00:02:15 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Terry Lambert, sie said: [...] > Part of getting the kernel working is in doing a lot of hardware > specific things. These need to be abstracted (this is my opinion) > to make ports easier. I think these should be encapsulated via a > C interface, so that for a new port, you can write a C stub that > provides the hardware specific information as hardcoded values for > the porting hardware you are using. Memory size, etc.. All the > things you would get from PPCBug, M68kBug, OpenBoot, PC BIOS, etc.. > I would be happy to help with this code. I hate to say this, but, see NetBSD. From owner-freebsd-hackers Sun Dec 14 04:10:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA01776 for hackers-outgoing; Sun, 14 Dec 1997 04:10:42 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 EAA01771 for ; Sun, 14 Dec 1997 04:10:35 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id EAA11730; Sun, 14 Dec 1997 04:10:25 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712141210.EAA11730@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: gjp@erols.net (Gary Palmer) cc: hackers@freebsd.org Subject: Re: weird IP address In-reply-to: Your message of "Sun, 14 Dec 1997 05:59:06 EST." <199712141059.FAA18630@mutara.noc.erols.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 04:10:25 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If it was issue from netcom just mail to their abuse dept since in the past they have been very responsive. Cheers, Amancio > In article <26132.882093169@verdi.nethelp.no>, > sthaug@nethelp.no writes: > > My guess is that they're doing that precisely to keep you from responding. > > You'll find: > > > > moneymakers.com. 288800 MX 10 mail.moneymakers.com. > > ftp.moneymakers.com. 288800 A 1.1.1.1 > > mail.moneymakers.com. 288800 A 1.1.1.1 > > www.moneymakers.com. 288800 A 1.1.1.1 > > > > So they're doing everything they can to prevent you from responding to > > their spam. Try looking at the Received: lines for some (possibly) more > > relevant info. > > If it was the same stuff I pulled from our spools here, its sent from > a Netcom dialin through their dfw mail servers. Makes me wish that > Netcom management had let Mark keep the anti-spam mail checks in > place ... sigh > > Gary > From owner-freebsd-hackers Sun Dec 14 04:42:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA03193 for hackers-outgoing; Sun, 14 Dec 1997 04:42:07 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 EAA03186 for ; Sun, 14 Dec 1997 04:41:59 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA02028 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Sun, 14 Dec 1997 13:42:12 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA15213; Sat, 13 Dec 1997 19:50:17 +0100 (MET) From: Wilko Bulte Message-Id: <199712131850.TAA15213@yedi.iaf.nl> Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] To: sthaug@nethelp.no Date: Sat, 13 Dec 1997 19:50:17 +0100 (MET) Cc: imp@village.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <21442.882034810@verdi.nethelp.no> from "sthaug@nethelp.no" at Dec 13, 97 06:40:10 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 sthaug@nethelp.no wrote... > > : Spot on. With an appropriate cable, any halfway-decent PC monitor will > > : handle all of the standard Sun video modes. > > > > And with the right xf86 config file, you can use a sun monitor on a pc > > As far as I know that's not true of *all* Sun monitors, because not all > Sun monitors are multisync. I believe all *recent* Sun monitors are > multisync, though. Correct. E.g the older Hitachi monitors are single-sync. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-hackers Sun Dec 14 05:26:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA07585 for hackers-outgoing; Sun, 14 Dec 1997 05:26:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from didda.est.is (ppp-44.est.is [194.144.208.144]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA07561 for ; Sun, 14 Dec 1997 05:26:29 -0800 (PST) (envelope-from totii@est.is) Received: from est.is (didda.est.is [192.168.255.1]) by didda.est.is (8.8.7/8.8.7) with ESMTP id NAA00815; Sun, 14 Dec 1997 13:25:53 GMT (envelope-from totii@est.is) Message-ID: <3493DE61.887D1F80@est.is> Date: Sun, 14 Dec 1997 13:25:53 +0000 From: "Žoršur Ivarsson" X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Ulf Zimmermann CC: jgrosch@superior.mooseriver.com, hackers@FreeBSD.ORG Subject: Re: weird IP address References: <199712140955.BAA12602@Gatekeeper.Alameda.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ulf Zimmermann wrote: > > > While sending out hate mail to the latest round of spammers I got an answer > > back from nslookup that I just do not understand. I got spam from > > MoneyMakers.com. When I did an nslookup I got the following: > > > > superior% nslookup moneymakers.com > > Server: superior.mooseriver.com > > Address: 205.166.121.5 > > > > Non-authoritative answer: > > Name: moneymakers.com > > Address: 1.1.1.1 > > ^^^^^^^ > > Very simple. Most people now reject email from not existing domains. So they > created the domain and put into their name server at NS.PROPAGATION.COM and > NS2.PROPAGATION.COM the IP number of 1.1.1.1. It is a kind of real IP number, > even it is not in use. (First class A network). > > > > > > > Josef > > > > -- > > Josef Grosch | Another day closer to a | FreeBSD 2.2.5 > > jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses > > > > > > Ulf. > > --------------------------------------------------------------------- > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 This ip address is in use: Name: NS.LOTTOSPORTS.COM Address: 1.1.1.1 whois gives information on company thats owns this address -- Žóršur Ķvarsson Thordur Ivarsson Rafeindavirki Electronic technician Noršurgötu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri Ķsland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-hackers Sun Dec 14 05:52:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08741 for hackers-outgoing; Sun, 14 Dec 1997 05:52:28 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 FAA08736 for ; Sun, 14 Dec 1997 05:52:20 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 27285 invoked by uid 1001); 14 Dec 1997 13:52:16 +0000 (GMT) To: totii@est.is Cc: hackers@FreeBSD.ORG Subject: Re: weird IP address In-Reply-To: Your message of "Sun, 14 Dec 1997 13:25:53 +0000" References: <3493DE61.887D1F80@est.is> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 14 Dec 1997 14:52:16 +0100 Message-ID: <27283.882107536@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This ip address is in use: > > > Name: NS.LOTTOSPORTS.COM > Address: 1.1.1.1 > > whois gives information on company thats owns this address Nope. 1.1.1.1 is not in use. Check the address allocation for the block in the InterNIC database. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- % whois -h rs.internic.net 1.0.0.0 IANA (RESERVED-9) Netname: RESERVED-9 Netnumber: 1.0.0.0 Coordinator: Reynolds, Joyce K. (JKR1) JKRey@ISI.EDU (310) 822-1511 Record last updated on 17-Apr-95. Database last updated on 13-Dec-97 06:26:00 EDT. From owner-freebsd-hackers Sun Dec 14 06:05:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA09349 for hackers-outgoing; Sun, 14 Dec 1997 06:05:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from atom.ru ([195.34.17.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA09330 for ; Sun, 14 Dec 1997 06:04:58 -0800 (PST) (envelope-from solik@atom.ru) Received: (from solik@localhost) by atom.ru (8.8.8/8.8.5) id QAA02790; Sun, 14 Dec 1997 16:48:48 +0300 (MSK) Message-Id: <199712141348.QAA02790@atom.ru> Subject: Re: weird IP address In-Reply-To: <26132.882093169@verdi.nethelp.no> from "sthaug@nethelp.no" at "Dec 14, 97 10:52:49 am" To: sthaug@nethelp.no Date: Sun, 14 Dec 1997 16:48:47 +0300 (MSK) Cc: hackers@FreeBSD.ORG From: Sergey Solyanik X-Beer-To: solik@mosinfo.com X-Beer-Minimum: infinite 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 Hi! > moneymakers.com. 288800 MX 10 mail.moneymakers.com. > ftp.moneymakers.com. 288800 A 1.1.1.1 > mail.moneymakers.com. 288800 A 1.1.1.1 > www.moneymakers.com. 288800 A 1.1.1.1 I've just received answer from hostmaster@propagation.com: Here it is: ---8<--- >From atom Sun Dec 14 16:41:40 1997 Received: (from atom@localhost) by atom.ru (8.8.8/8.8.5) id QAA02737 for Sergey Solyanik ; Sun, 14 Dec 1997 16:41:39 +0300 (MSK) Received: from uranus.spectronet.net (uranus.spectronet.net [207.227.212.3]) by www.bestware.net (8.8.6/8.6.9) with ESMTP id FAA14075 for ; Sun, 14 Dec 1997 05:52:01 -0500 (EST) Received: from localhost (jjr@localhost) by uranus.spectronet.net (8.8.5/8.8.4) with SMTP id EAA17400; Sun, 14 Dec 1997 04:47:12 -0600 X-Authentication-Warning: uranus.spectronet.net: jjr owned process doing -bs Date: Sun, 14 Dec 1997 04:47:11 -0600 (CST) From: John To: Sergey Solyanik cc: hostmaster@propagation.com Subject: Re: What the hell is 1.1.1.1 - moneymakers.com ?! In-Reply-To: <3493B898.41C67EA6@atom.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 03e8d05520608be5a613f067e59b21f2 X-Tossed-By: Tosser/Perl-0.0.7 Status: RO Did you ever think that maybe they forged the headers to make it look like it came from moneymakers.com??? In this case, it DID! John On Sun, 14 Dec 1997, Sergey Solyanik wrote: > Hi! > > Why You, the Hostmaster, allow to set a incorrect record in Your DNS for > moneymacers.com ? > How can You, the Hostmaster, support such DNS ?! > You did that for money, didn't You ? > > Please, fix this record to real IP, that all SPAM haters in the world > may beat them. > > --->8--- I realize that emotions overfooded me, but... Good luck! -- Solik. [Team OS/2] SSV3-RIPE ...See You on the Dark Side of the Moon... -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/CC d-(+) s:- a- C+++ UB++++$ P+$ L- E- W+++$ N++ o? K? w--- O+++$ M V PS+ PE- Y+ PGP t? 5? X+ R- tv- b+++ DI? D G e h r- y+ ------END GEEK CODE BLOCK------ From owner-freebsd-hackers Sun Dec 14 07:37:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14140 for hackers-outgoing; Sun, 14 Dec 1997 07:37:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from didda.est.is (ppp-44.est.is [194.144.208.144]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14132 for ; Sun, 14 Dec 1997 07:37:12 -0800 (PST) (envelope-from totii@est.is) Received: from est.is (didda.est.is [192.168.255.1]) by didda.est.is (8.8.7/8.8.7) with ESMTP id PAA03612; Sun, 14 Dec 1997 15:36:50 GMT (envelope-from totii@est.is) Message-ID: <3493FD12.2AF1873D@est.is> Date: Sun, 14 Dec 1997 15:36:50 +0000 From: "Žoršur Ivarsson" X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: sthaug@nethelp.no CC: "hackers@FreeBSD.ORG" Subject: Re: weird IP address References: <3493DE61.887D1F80@est.is> <27283.882107536@verdi.nethelp.no> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk sthaug@nethelp.no wrote: > > > This ip address is in use: > > > > > > Name: NS.LOTTOSPORTS.COM > > Address: 1.1.1.1 > > > > whois gives information on company thats owns this address > > Nope. 1.1.1.1 is not in use. Check the address allocation for the block > in the InterNIC database. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > ---------------------------------------------------------------------- > % whois -h rs.internic.net 1.0.0.0 > IANA (RESERVED-9) > > Netname: RESERVED-9 > Netnumber: 1.0.0.0 > > Coordinator: > Reynolds, Joyce K. (JKR1) JKRey@ISI.EDU > (310) 822-1511 > > Record last updated on 17-Apr-95. > Database last updated on 13-Dec-97 06:26:00 EDT. what is this then ? ... whois 1.1.1.1 [No name] (NS35365-HST) Hostname: NS.LOTTOSPORTS.COM Address: 1.1.1.1 System: ? running ? Record last updated on 26-Nov-97. Database last updated on 14-Dec-97 05:23:51 EDT. and the other way around %whois lottosports.com Lotto Sports Inc. (LOTTOSPORTS2-DOM) 10863 97st Edmonton, AB T5H 2M6 , CA Domain Name: LOTTOSPORTS.COM Administrative Contact, Technical Contact, Zone Contact: Pui, Jesse (JP6361) scorpiox@SPRINT.CA 403-425-4098 (FAX) 403-428-6261 Billing Contact: Pui, Jesse (JP6361) scorpiox@SPRINT.CA 403-425-4098 (FAX) 403-428-6261 Record last updated on 26-Nov-97. Record created on 26-Nov-97. Database last updated on 14-Dec-97 05:23:51 EDT. Domain servers in listed order: NS.LOTTOSPORTS.COM 1.1.1.1 NS2.LOTTOSPORTS.COM 1.1.1.2 Database last updated on 14-Dec-97 05:23:51 EDT. -- Žóršur Ķvarsson Thordur Ivarsson Rafeindavirki Electronic technician Noršurgötu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri Ķsland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-hackers Sun Dec 14 09:13:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20030 for hackers-outgoing; Sun, 14 Dec 1997 09:13:42 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 JAA20024 for ; Sun, 14 Dec 1997 09:13:35 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id KAA22284; Sun, 14 Dec 1997 10:12:42 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id KAA02574; Sun, 14 Dec 1997 10:13:18 -0700 (MST) Date: Sun, 14 Dec 1997 10:13:18 -0700 (MST) From: Marc Slemko To: Žoršur Ivarsson cc: "hackers@FreeBSD.ORG" Subject: Re: weird IP address In-Reply-To: <3493FD12.2AF1873D@est.is> 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 JAA20025 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 14 Dec 1997, Žoršur Ivarsson wrote: > > what is this then ? ... > > whois 1.1.1.1 > > [No name] (NS35365-HST) > > Hostname: NS.LOTTOSPORTS.COM > Address: 1.1.1.1 > System: ? running ? > > Record last updated on 26-Nov-97. > Database last updated on 14-Dec-97 05:23:51 EDT. > Just because someone registers a record using that address doesn't mean it is allocated to anyone. You can register whatever you feel like; the InterNIC doesn't care about anything as long as you pay. This is just like how you can put any IP address in your domain files without having anything to do with it. > > and the other way around > > %whois lottosports.com > Lotto Sports Inc. (LOTTOSPORTS2-DOM) > 10863 97st > Edmonton, AB T5H 2M6 > , > CA Hmm. Same city as me. From owner-freebsd-hackers Sun Dec 14 09:57:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22987 for hackers-outgoing; Sun, 14 Dec 1997 09:57:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bubba.NMSU.Edu (bubba.NMSU.Edu [128.123.3.39]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22980 for ; Sun, 14 Dec 1997 09:57:17 -0800 (PST) (envelope-from ian@nmsu.edu) Received: from NMSU.Edu by bubba.NMSU.Edu (8.8.7/NMSU) id KAA29173; Sun, 14 Dec 1997 10:56:02 -0700 (MST) Received: from wilma by NMSU.Edu (8.8.4/NMSU-1.18) id KAA13346; Sun, 14 Dec 1997 10:57:16 -0700 (MST) Received: from nmsu.edu by wilma (SMI-8.6/NMSU) id KAA04429; Sun, 14 Dec 1997 10:57:05 -0700 Message-ID: <34941E48.E2339DD0@nmsu.edu> Date: Sun, 14 Dec 1997 10:58:32 -0700 From: Ian Logan Organization: Computing and Networking X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.6 sun4m) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port References: <18492.881979199@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > I'm not trying to actively discourage such efforts, and if you're > really wanting to hack support for the 4m then by all means, please do > so. I was simply trying to stem the tide of "Cool! When's this all > going to work on my SS5 clone!" sorts of questions before Jason's even > gotten started on the principal objective. :) > > Jordan You're right, I got a bit too excited myself :) Ian -- Ian Logan Computing & Networking New Mexico State University Email: ian@nmsu.edu Phone: 505-646-6034 Fax: 505-646-5278 From owner-freebsd-hackers Sun Dec 14 10:21:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25089 for hackers-outgoing; Sun, 14 Dec 1997 10:21:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA25078 for ; Sun, 14 Dec 1997 10:21:36 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id TAA08412 for freebsd-hackers@freebsd.org; Sun, 14 Dec 1997 19:21:34 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id TAA29536; Sun, 14 Dec 1997 19:16:08 +0100 (MET) Date: Sun, 14 Dec 1997 19:16:08 +0100 (MET) Message-Id: <199712141816.TAA29536@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden 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 References: <199712071816.KAA21840@freefall.freebsd.org> <19971208091729.40125@uriah.heep.sax.de> <863ek4p1tx.fsf_-_@bitbox.follo.net> <199712100013.BAA04827@uriah.heep.sax.de> <863ek1xtsl.fsf@bitbox.follo.net> In-Reply-To: <863ek1xtsl.fsf@bitbox.follo.net> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: New option model (was Re: cvs commit: src/sys/kern kern_exit.c) X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Eivind Eklund wrote: > As far as I can see, the only correct #ifdef's in the kernel .c files > are #ifdef KERNEL (should be _KERNEL) - everything else should be > #if to allow #define XXX 1 or 0. Am I correct? Should I fix this as > I do my walkthrough anyway? Hmm, not sure. All the boolean current options are #ifdef-evaluated. What do others think about it? I don't see an urgent need to change _this_. Well, if you were going to spell _KERNEL correctly, by all means, go ahead! ;) > For any option that isn't mentioned in a header file, it should be > fairly simple to move to the new model - a bit of work, but mostly > just work, not thought. Yep. Options mentioned in header files are the actual problem. Most of the header files doing so are bogus. I'm not sure what others think about kernel structs that vary their size based on different kernel option usage. IMHO they should die, since they are highly dangerous, and this danger doesn't justify the few saved bytes. >> Except for a few things like #ifdef _KERNEL (still >> misspelled as #ifdef KERNEL in FreeBSD), #ifdef's should be mostly >> banned from .h files. > > These look like a lot of non-trivial work to fix :-( Unfortunately, yes. If people can help fixing them, this would be highly appreciated. -- 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 Dec 14 10:22:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25155 for hackers-outgoing; Sun, 14 Dec 1997 10:22:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from didda.est.is (ppp-44.est.is [194.144.208.144]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA25149 for ; Sun, 14 Dec 1997 10:22:33 -0800 (PST) (envelope-from totii@est.is) Received: from est.is (didda.est.is [192.168.255.1]) by didda.est.is (8.8.7/8.8.7) with ESMTP id SAA20030; Sun, 14 Dec 1997 18:21:28 GMT (envelope-from totii@est.is) Message-ID: <349423A7.5669E713@est.is> Date: Sun, 14 Dec 1997 18:21:28 +0000 From: "Žoršur Ivarsson" X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Marc Slemko CC: "hackers@FreeBSD.ORG" Subject: Re: weird IP address References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Marc Slemko wrote: > > On Sun, 14 Dec 1997, Žoršur Ivarsson wrote: > > > > what is this then ? ... > > > > whois 1.1.1.1 > > > > [No name] (NS35365-HST) > > > > Hostname: NS.LOTTOSPORTS.COM > > Address: 1.1.1.1 > > System: ? running ? > > > > Record last updated on 26-Nov-97. > > Database last updated on 14-Dec-97 05:23:51 EDT. > > > > Just because someone registers a record using that address doesn't mean > it is allocated to anyone. You can register whatever you feel like; > the InterNIC doesn't care about anything as long as you pay. > > This is just like how you can put any IP address in your domain > files without having anything to do with it. > > > > > and the other way around > > > > %whois lottosports.com > > Lotto Sports Inc. (LOTTOSPORTS2-DOM) > > 10863 97st > > Edmonton, AB T5H 2M6 > > , > > CA > > Hmm. Same city as me. Are you telling me that I could register "what ever name" to "what ever ip address" that even does not belong to me? This does not seem to be logical. I can use "what ever name".est.is in my domain for my network 194.144.208."what ever" but I must not be allowed to register "what ever other name".est.is to address/network that I have not got from INTERNIC/RIPE. We have virtual domains here and they have logical reason, but not someone using reseved (assigned) address is not ethical. -- Žóršur Ķvarsson Thordur Ivarsson Rafeindavirki Electronic technician Noršurgötu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri Ķsland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-hackers Sun Dec 14 10:26:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25591 for hackers-outgoing; Sun, 14 Dec 1997 10:26:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (as1-p21.tfs.net [139.146.205.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA25553 for ; Sun, 14 Dec 1997 10:26:42 -0800 (PST) (envelope-from jbryant@unix.tfs.net) Received: (from jbryant@localhost) by unix.tfs.net (8.8.8/8.8.5) id MAA02929 for freebsd-hackers@freebsd.org; Sun, 14 Dec 1997 12:26:37 -0600 (CST) From: Jim Bryant Message-Id: <199712141826.MAA02929@unix.tfs.net> Subject: rhapsody article To: freebsd-hackers@freebsd.org Date: Sun, 14 Dec 1997 12:26:35 -0600 (CST) Reply-to: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 3.0-CURRENT #0: Mon Dec 1 15:51:40 CST 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 remembering the talk about apple's rhapsody os... i just came across this high-level article.. found no mention of bsd though.. http://www.osnews.com/yellowbox.html 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 Dec 14 10:32:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26076 for hackers-outgoing; Sun, 14 Dec 1997 10:32:27 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 KAA26066 for ; Sun, 14 Dec 1997 10:32:21 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id LAA24445; Sun, 14 Dec 1997 11:31:50 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id LAA02967; Sun, 14 Dec 1997 11:32:26 -0700 (MST) Date: Sun, 14 Dec 1997 11:32:25 -0700 (MST) From: Marc Slemko To: Žoršur Ivarsson cc: "hackers@FreeBSD.ORG" Subject: Re: weird IP address In-Reply-To: <349423A7.5669E713@est.is> 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 KAA26067 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 14 Dec 1997, Žoršur Ivarsson wrote: > Are you telling me that I could register "what ever name" to "what ever > ip address" that even does not belong to me? I am saying you can use whatever IP you want for a nameserver when registering a domain via the InterNIC and they will not trying to figure out if you are authorized to use it. The InterNIC will list that nameserver in the DNS for that domain, will add a glue record for the nameserver, and will create a host record. You can't have multiple host records for one IP, though. > This does not seem to be logical. I can use "what ever name".est.is in > my domain for my network 194.144.208."what ever" but I must not be > allowed to register "what ever other name".est.is to address/network > that I have not got from INTERNIC/RIPE. Of course it is logical. How do you propose to magically detect if someone is using an address they shouldn't? You don't gain anything from doing it because you can't actually use that IP for anything. > We have virtual domains here and they have logical reason, but not > someone using reseved (assigned) address is not ethical. Ethics have nothing to do with it. From owner-freebsd-hackers Sun Dec 14 10:35:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26301 for hackers-outgoing; Sun, 14 Dec 1997 10:35:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA26290 for ; Sun, 14 Dec 1997 10:35:19 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id TAA08407 for freebsd-hackers@freebsd.org; Sun, 14 Dec 1997 19:21:33 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id TAA29546; Sun, 14 Dec 1997 19:19:13 +0100 (MET) Date: Sun, 14 Dec 1997 19:19:13 +0100 (MET) Message-Id: <199712141819.TAA29546@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden 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 References: In-Reply-To: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: Proposed code merge, objections? X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk njs3@doc.ic.ac.uk (Niall Smart) wrote: >> -stable is not meant to accumulate new features from -current. Unless >> there are strong reasons, new drivers should not migrate there. This >> _is_ official policy. > > Does this include drivers for common peripherals such as network cards > and SCSI controllers? Well, i wrote `strong reasons' (and other folks even made that less restrictive). A strong reason is, of course, driver changes due to market changes, like merging drivers for new chips where the older chips are getting rare already. The basic questions are: .. is there actually demand for it (which i doubt for aio/alog)? .. is the change non-intrusive enough to make fatal problems in -stable unlikely? -- 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 Dec 14 10:59:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA28657 for hackers-outgoing; Sun, 14 Dec 1997 10:59:22 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 KAA28646 for ; Sun, 14 Dec 1997 10:59:16 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xhJFt-0006zk-00; Sun, 14 Dec 1997 11:59:09 -0700 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id MAA04338; Sun, 14 Dec 1997 12:00:17 -0700 (MST) Message-Id: <199712141900.MAA04338@harmony.village.org> To: gjp@erols.net (Gary Palmer) Subject: Re: Beginning SPARC port Cc: itojun@itojun.org, hackers@freebsd.org In-reply-to: Your message of "Sun, 14 Dec 1997 00:06:53 EST." <199712140506.AAA17194@mutara.noc.erols.net> References: <199712140506.AAA17194@mutara.noc.erols.net> <199712140433.XAA17136@mutara.noc.erols.net> <16085.882074445@coconut.itojun.org> Date: Sun, 14 Dec 1997 12:00:17 -0700 From: Warner Losh Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199712140506.AAA17194@mutara.noc.erols.net> Gary Palmer writes: : What I am trying to say is that while it may not be the Politically : Correct(TM) solution, it is not totally i386 bound either. Being : #defines, its a bit more flexible than you were making out. For a long time Linux has used outb/inb (and maybe still does) for accessing I/O space. On the Linux/MIPS ports, these functions are basically #define outb(port,value) *((char *) (base + port)) = value On the MIPS machines that Linux is being ported to, the I/O space is mapped at various locations depending on the machine type and sometimes on the device being mapped (on ISA bus, on EISA bus or on motherboard). Warner From owner-freebsd-hackers Sun Dec 14 11:09:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00240 for hackers-outgoing; Sun, 14 Dec 1997 11:09:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00235 for ; Sun, 14 Dec 1997 11:09:33 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id LAA10029; Sun, 14 Dec 1997 11:46:42 -0700 (MST) Message-Id: <199712141846.LAA10029@pluto.plutotech.com> To: John-Mark Gurney cc: hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 01:50:02 PST." <19971214015002.48331@hydrogen.nike.efn.org> Date: Sun, 14 Dec 1997 11:44:51 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Justin T. Gibbs scribbled this message on Dec 14: >> NetBSD has already dealt with this issue. >> ... >in my opinion, they didn't go far enough... they still have seperate >structures for each bus... and their resource is bus dependant.. >there isn't a common structure between all busses... Actually, they do have a common structure between all busses at least from the configuration standpoint. They use "new config" which builds a full tree of configured buses. How those buses implement the functionality required by bus.h is up to the individual bus type. This seems to be the correct solution to me as to do otherwise might force one "simple bus" to carry baggage from a "complicated bus" just so you could have a shared data structure. There is also the issue that some resources may not exist on some bus types, may be localized to a particular bus, shared only by busses of the same type, or shared with other bus types in the system. You have to handle all cases. >with my code, very little will actually have to be done to allow devices >to be used between bus types... How is this not the case for the bus.h interface? All of the aic7xxx.c file works regardless of whether the bus is PCI, EISA, or VL. It knows nothing about how DMA and device access is performed on these busses other than the fact that DMA and device access is possible for all the cards it supports. The knowledge of how to do this is encapsulated in the "bus handle" that was passed down from the parent bus to the device at probe/attach time. >and if the interface to the bus isn't >radicly different (like supporting same memory/io/interrupt) sets, >the only difference will be the probe code... Isn't this the case now? ahc_pci.c, ahc_eisa.c, and there should be an ahc_isa.c for the VL cards combined with a bus independent back end. >the hardest part of the whole thing though, is to some how create a >way for common resources to be able to use keys... because if your >trying to do dma with channel one on the first isa bus, how do you >tell the different between dma channel one on the second bus... > >so far, the only way that I've come up with a way to solve this is to >pass back three parameters when the device allocates a resource... >this is a function pointer, a device pointer (an interrupt handler is >a device just like a dma controller or an ethernet card is, and will >require a device entry along with other devices) and the special >parameter that identifies the resource (like irq number or dma number).. I think that it should be a completly opaque type in much the same way that the bus.h interface is specified. It should be up to the bus/device managing the resource to decide just what and how it stores sufficient information to manage that resource. >we can make a special exception though... and that would be for memory >and io port accesses... which I think should either ALWAYS use a macro >along with the parameter passed back (for access), or compare against >the function pointer for possible "constants"... the former is probably >better than the later... I don't believe that this will work on the Alpha. >right now the latest specs for the bus/device code is at: >http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html I'll take a look. -- Justin From owner-freebsd-hackers Sun Dec 14 11:23:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01891 for hackers-outgoing; Sun, 14 Dec 1997 11:23:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA01880 for ; Sun, 14 Dec 1997 11:22:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA10791 for ; Sun, 14 Dec 1997 19:22:51 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id UAA13250; Sun, 14 Dec 1997 20:22:50 +0100 (MET) X-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: New option model (was Re: cvs commit: src/sys/kern kern_exit.c) References: <199712071816.KAA21840@freefall.freebsd.org> <19971208091729.40125@uriah.heep.sax.de> <863ek4p1tx.fsf_-_@bitbox.follo.net> <199712100013.BAA04827@uriah.heep.sax.de> <863ek1xtsl.fsf@bitbox.follo.net> <199712141816.TAA29536@uriah.heep.sax.de> From: Eivind Eklund Date: 14 Dec 1997 20:22:48 +0100 In-Reply-To: j@uriah.heep.sax.de's message of Sun, 14 Dec 1997 19:16:08 +0100 (MET) Message-ID: <86zpm3pw53.fsf@bitbox.follo.net> Lines: 38 X-Mailer: Gnus v5.4.52/XEmacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk j@uriah.heep.sax.de (J Wunsch) writes: > Eivind Eklund wrote: > > > As far as I can see, the only correct #ifdef's in the kernel .c files > > are #ifdef KERNEL (should be _KERNEL) - everything else should be > > #if to allow #define XXX 1 or 0. Am I correct? Should I fix this as > > I do my walkthrough anyway? > > Hmm, not sure. All the boolean current options are #ifdef-evaluated. > > What do others think about it? I don't see an urgent need to change > _this_. I didn't notice all of those options had an 'N' prefixed :-( NPPP_DEFLATE still seems somehow bogus. Fixing the non-header file versions would then just be adding the proper opt_xxx.h includes - should be trivial, except I'm not certain what kernel code is being re-vamped at any moment. > Well, if you were going to spell _KERNEL correctly, by all means, go > ahead! ;) Won't this break many patches people are keeping externally? > I'm not sure what others think about kernel structs that vary their > size based on different kernel option usage. IMHO they should die, > since they are highly dangerous, and this danger doesn't justify the > few saved bytes. I dislike them, at least. I also dislike using structs to communicate kernel <-> userland - e.g. for ipfw. I'd like this to use something like the tags system on the Amiga. Eivind. From owner-freebsd-hackers Sun Dec 14 11:25:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA02202 for hackers-outgoing; Sun, 14 Dec 1997 11:25:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA02197 for ; Sun, 14 Dec 1997 11:25:53 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin1.anlw.anl.gov [141.221.254.101]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id MAA21728; Sun, 14 Dec 1997 12:25:26 -0700 Date: Sun, 14 Dec 1997 12:24:55 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Marc Slemko cc: Žoršur Ivarsson , "hackers@FreeBSD.ORG" Subject: Re: weird IP address 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 > > We have virtual domains here and they have logical reason, but not > > someone using reseved (assigned) address is not ethical. > > Ethics have nothing to do with it. > Of course, anyone running a DNS which is authortitative for a particular domain can have address records pointing to wherever they want. However, I think that the internet depends to some extent on people running DNS servers to act in a responsible manner. I think ethics does have something to do with it. If Sanford Wallace decided to have www.cyberpromo.com point to a machine I own, I *would* be concerned. And it wouldn't be ethical. Charles Mott From owner-freebsd-hackers Sun Dec 14 12:39:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA07933 for hackers-outgoing; Sun, 14 Dec 1997 12:39:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA07928 for ; Sun, 14 Dec 1997 12:39:44 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id MAA25208; Sun, 14 Dec 1997 12:40:19 -0800 (PST) Date: Sun, 14 Dec 1997 12:40:19 -0800 (PST) From: Jim Shankland Message-Id: <199712142040.MAA25208@biggusdiskus.flyingfox.com> To: marcs@znep.com, totii@est.is Subject: Re: weird IP address Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Marc Slemko writes: > I am saying you can use whatever IP you want for a nameserver > when registering a domain via the InterNIC and they will not > trying to figure out if you are authorized to use it. The > InterNIC will list that nameserver in the DNS for that domain, > will add a glue record for the nameserver, and will create a > host record. You can't have multiple host records for one IP, > though. Back when domain registration was free, InterNIC would actually check the name servers you named, making sure that they were reachable and had proper NS and SOA records for your new domain. If not, your registration was put on hold until you fixed things. Now that they're charging money for the service, evidently they can no longer afford to do this :-(. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-hackers Sun Dec 14 12:46:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA08524 for hackers-outgoing; Sun, 14 Dec 1997 12:46:21 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 MAA08514 for ; Sun, 14 Dec 1997 12:46:12 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 28644 invoked by uid 1001); 14 Dec 1997 20:46:07 +0000 (GMT) To: marcs@znep.com Cc: hackers@FreeBSD.ORG Subject: Re: weird IP address In-Reply-To: Your message of "Sun, 14 Dec 1997 11:32:25 -0700 (MST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 14 Dec 1997 21:46:07 +0100 Message-ID: <28642.882132367@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This does not seem to be logical. I can use "what ever name".est.is in > > my domain for my network 194.144.208."what ever" but I must not be > > allowed to register "what ever other name".est.is to address/network > > that I have not got from INTERNIC/RIPE. > > Of course it is logical. How do you propose to magically detect if > someone is using an address they shouldn't? You don't gain anything from > doing it because you can't actually use that IP for anything. Well, you could for instance check (in the case of name servers) that the name servers are actually configured for the domain it is claimed they serve. Some TLDs registration authorities do this actively, for instance .no (Norway) - a domain *will not* be registered unless the name servers answer authoritatively. (Doesn't prevent the name servers from going non-authoritative later, of course - but it sure weeds out a lot of ISP wannabees.) > > We have virtual domains here and they have logical reason, but not > > someone using reseved (assigned) address is not ethical. > > Ethics have nothing to do with it. Yes and no. We've had people registering a .com domain with InterNIC and *later* asking for name service for this domain. To my mind this is only fair if you ask in advance. But this no longer has anything to do with FreeBSD, so let's take it to private email if anybody wants to continue the discussion. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sun Dec 14 12:48:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA08825 for hackers-outgoing; Sun, 14 Dec 1997 12:48:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from didda.est.is (ppp-44.est.is [194.144.208.144]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA08794 for ; Sun, 14 Dec 1997 12:48:36 -0800 (PST) (envelope-from totii@est.is) Received: from est.is (didda.est.is [192.168.255.1]) by didda.est.is (8.8.7/8.8.7) with ESMTP id UAA20931; Sun, 14 Dec 1997 20:47:53 GMT (envelope-from totii@est.is) Message-ID: <349445F8.82059360@est.is> Date: Sun, 14 Dec 1997 20:47:52 +0000 From: "Žoršur Ivarsson" X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Charles Mott CC: Marc Slemko , "hackers@FreeBSD.ORG" Subject: Re: weird IP address References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles Mott wrote: > > > > We have virtual domains here and they have logical reason, but not > > > someone using reseved (assigned) address is not ethical. > > > > Ethics have nothing to do with it. > > > > Of course, anyone running a DNS which is authortitative for a particular > domain can have address records pointing to wherever they want. However, > I think that the internet depends to some extent on people running DNS > servers to act in a responsible manner. I think ethics does have > something to do with it. > > If Sanford Wallace decided to have www.cyberpromo.com point to a machine I > own, I *would* be concerned. And it wouldn't be ethical. > > Charles Mott I thought, when I apply for ip address and domain name I needed to stick with what I get and InterNIC/RIPE should keep correct and safe database of those networks that are available. I am not sure if the "central control" of domain names and networks are then working any more like what we saw from previous. If 1.0.0.0 is not in use why can 1.1.1.1 and 1.1.1.2 be used of someone? Or at least someone register domain name on address that is not in use/not allocated to him. I had one network floating around for some time and because of difficulties to connect to the internet it was designated to other company. Later on I was connected, and got all kinds of problems because of the others company use of the addresses, I was not informed that my use of the network was canceled. -- Žóršur Ķvarsson Thordur Ivarsson Rafeindavirki Electronic technician Noršurgötu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri Ķsland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-hackers Sun Dec 14 14:29:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA16327 for hackers-outgoing; Sun, 14 Dec 1997 14:29:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tahoe.sierranv.net (root@sierranv.net [208.8.112.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA16296 for ; Sun, 14 Dec 1997 14:28:37 -0800 (PST) (envelope-from aaabudget@freeyellow.com) From: aaabudget@freeyellow.com Received: from user900.meznet4.net (pm01-9.sierranv.net [208.8.113.57]) by tahoe.sierranv.net (8.8.8/8.8.8) with SMTP id OAA19312; Sun, 14 Dec 1997 14:26:49 -0800 Message-Id: <199712142226.OAA19312@tahoe.sierranv.net> To: h9506587@hkusub.hku.hk Subject: boeeow up to $100,000 virtually overnight *! Reply-To: aaabudget@freeyellow.com Date: Fri, 21 Oct 97 19:24:52 EST Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Filterd Via The Remove List At http://www.antispam.org Borrow up to $100,000 Virtually Overnight. Even if your Bank Just turned you down. Surprizing new sources of cash for - The hard pressed Borrower. Loans with no questions asked $50,000 Debt Consolidation "Line of Credit" in 7days. Signature loans from $300 to $50,000 No co-signer, no collateral, no credit check. Bankruptcy and hard to place loans Loans to stop foreclosure, payoff judgements, IRS Liens, etc. All these plus 100's of unusual sources. Even your Banker does not know about these sources and hopes you never will. Worldwide loans and loan guarantees. For more information go to http://www.freeyellow.com/members/aaabudget/index.html *** Important Message - Sent Using The Zenith Bulk Emailer *** For Your FREE Copy Of This Program - http://209.27.224.16 From owner-freebsd-hackers Sun Dec 14 14:40:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA17142 for hackers-outgoing; Sun, 14 Dec 1997 14:40:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mars.abcinternet.net (drow@mars.abcinternet.net [205.216.244.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA17131 for ; Sun, 14 Dec 1997 14:40:20 -0800 (PST) (envelope-from drow@drow.net) Received: from localhost (drow@localhost) by mars.abcinternet.net (8.8.8/8.8.5) with SMTP id RAA29587; Sun, 14 Dec 1997 17:38:48 -0500 (EST) Date: Sun, 14 Dec 1997 17:38:48 -0500 (EST) From: Dan Jacobowitz X-Sender: drow@mars.abcinternet.net To: Jim Shankland cc: hackers@FreeBSD.ORG Subject: Re: weird IP address In-Reply-To: <199712142040.MAA25208@biggusdiskus.flyingfox.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 Dec 1997, Jim Shankland wrote: > Marc Slemko writes: > > > I am saying you can use whatever IP you want for a nameserver > > when registering a domain via the InterNIC and they will not > > trying to figure out if you are authorized to use it. The > > InterNIC will list that nameserver in the DNS for that domain, > > will add a glue record for the nameserver, and will create a > > host record. You can't have multiple host records for one IP, > > though. > > Back when domain registration was free, InterNIC would actually > check the name servers you named, making sure that they were reachable > and had proper NS and SOA records for your new domain. If not, your > registration was put on hold until you fixed things. > > Now that they're charging money for the service, evidently they > can no longer afford to do this :-(. It strikes me as a little odd that InterNIC puts reverse DNS for the nameservers on their root servers - in fact, judging by my past experiences, I could ahve sworn that they did not. (In fact, hgaving just gone to check a few others, they do not) Apparently they only do so if no other NS is responsible for ther reverse range specified! Go figure. An InterNIC bug? From owner-freebsd-hackers Sun Dec 14 15:05:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA19201 for hackers-outgoing; Sun, 14 Dec 1997 15:05:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA19187 for ; Sun, 14 Dec 1997 15:05:27 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id XAA10959 for freebsd-hackers@freebsd.org; Sun, 14 Dec 1997 23:22:34 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id XAA01033; Sun, 14 Dec 1997 23:09:50 +0100 (MET) Date: Sun, 14 Dec 1997 23:09:50 +0100 (MET) Message-Id: <199712142209.XAA01033@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden 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 References: <199712071816.KAA21840@freefall.freebsd.org> <19971208091729.40125@uriah.heep.sax.de> <863ek4p1tx.fsf_-_@bitbox.follo.net> <199712100013.BAA04827@uriah.heep.sax.de> <863ek1xtsl.fsf@bitbox.follo.net> <199712141816.TAA29536@uriah.heep.sax.de> <86zpm3pw53.fsf@bitbox.follo.net> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: New option model (was Re: cvs commit: src/sys/kern kern_exit.c) X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Eivind Eklund wrote: >> Well, if you were going to spell _KERNEL correctly, by all means, go >> ahead! ;) > > Won't this break many patches people are keeping externally? FreeBSD 3.0 will break almost anything anyway, so it's a good time to do this. :) > I also dislike using structs to communicate kernel <-> > userland - e.g. for ipfw. I'd like this to use something like the > tags system on the Amiga. For ioctls, they are rather safe in the BSD model, since the struct size is crunched into the ioctl command. So if you extend a struct later, just rename the old one in the kernel header file, as well as the old ioctl cmd value, and you can easily support both in parallel. -- 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 Dec 14 15:32:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA21591 for hackers-outgoing; Sun, 14 Dec 1997 15:32:39 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 PAA21580 for ; Sun, 14 Dec 1997 15:32:28 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id QAA03086; Sun, 14 Dec 1997 16:31:13 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id QAA04753; Sun, 14 Dec 1997 16:31:50 -0700 (MST) Date: Sun, 14 Dec 1997 16:31:49 -0700 (MST) From: Marc Slemko To: Dan Jacobowitz cc: Jim Shankland , hackers@FreeBSD.ORG Subject: Re: weird IP address 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 Sun, 14 Dec 1997, Dan Jacobowitz wrote: > > > On Sun, 14 Dec 1997, Jim Shankland wrote: > > > Marc Slemko writes: > > > > > I am saying you can use whatever IP you want for a nameserver > > > when registering a domain via the InterNIC and they will not > > > trying to figure out if you are authorized to use it. The > > > InterNIC will list that nameserver in the DNS for that domain, > > > will add a glue record for the nameserver, and will create a > > > host record. You can't have multiple host records for one IP, > > > though. > > > > Back when domain registration was free, InterNIC would actually > > check the name servers you named, making sure that they were reachable > > and had proper NS and SOA records for your new domain. If not, your > > registration was put on hold until you fixed things. > > > > Now that they're charging money for the service, evidently they > > can no longer afford to do this :-(. > > > It strikes me as a little odd that InterNIC puts reverse DNS for the > nameservers on their root servers - in fact, judging by my past > experiences, I could ahve sworn that they did not. > > (In fact, hgaving just gone to check a few others, they do not) > > Apparently they only do so if no other NS is responsible for ther reverse > range specified! > > Go figure. An InterNIC bug? Huh? Why are you saying they are doing reverse DNS entries? Nothing posted here suggests that. From owner-freebsd-hackers Sun Dec 14 15:47:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22851 for hackers-outgoing; Sun, 14 Dec 1997 15:47:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA22837 for ; Sun, 14 Dec 1997 15:47:38 -0800 (PST) (envelope-from kpielorz@caladan.tdx.co.uk) Received: from localhost (kpielorz@localhost) by caladan.tdx.co.uk (8.8.5/8.8.5) with SMTP id XAA00487 for ; Sun, 14 Dec 1997 23:27:16 GMT Date: Sun, 14 Dec 1997 23:27:16 +0000 (GMT) From: Karl Pielorz To: hackers@freebsd.org Subject: /kernel 'calcru' negative offset? 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 posted this in the questions list - but not gotten any replies... I'm running FreeBSD 2.2.5-Release on a laptop (one that sadly doesn't work with the PAO laptop support patches / drivers etc.) When the system boots - the kernel thinks the CPU is only 50Mhz (instead of 100Mhz) - It's an Intel Pentium 100. This is when running the laptop in 'brain dead' mode, i.e. no power saving, no spinning down of the harddrive etc. - and no APM idleing the CPU when it thinks it's not busy... I've fiddled around with the kernel config - in particular the CLK_CALIBRATION type config options - all to no avail... Is there a way of forcing the kernel to beleive the CPU is 100Mhz? - intead of 50Mhz? Regards, Kp From owner-freebsd-hackers Sun Dec 14 15:54:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA23344 for hackers-outgoing; Sun, 14 Dec 1997 15:54:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA23329 for ; Sun, 14 Dec 1997 15:54:33 -0800 (PST) (envelope-from kpielorz@caladan.tdx.co.uk) Received: from localhost (kpielorz@localhost) by caladan.tdx.co.uk (8.8.5/8.8.5) with SMTP id XAA00506 for ; Sun, 14 Dec 1997 23:33:51 GMT Date: Sun, 14 Dec 1997 23:33:51 +0000 (GMT) From: Karl Pielorz To: hackers@freebsd.org Subject: 132 Column mode on VGA Consoles 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 Is there a way of getting the kernel to boot in 132 column mode on a VGA based 2.2.5-Release / 2.2.2-Release box at all? I've looked at the vidcontrol(1) command, and at writing a small program that attempts to use the VGASETCOLMS ioctl (thinking if I can't boot to 132 I can switch after boot?) - but all to no avail... Is this a no-no at the moment, or can it be done? (before I waste any more time ;-) - I've had a quick look in the FAQ's / mailing list archives - it's mentioned sufficiently occasionally enough to make me think it's probably not easily possible... :-( Kp From owner-freebsd-hackers Sun Dec 14 16:15:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA25115 for hackers-outgoing; Sun, 14 Dec 1997 16:15:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA25107 for ; Sun, 14 Dec 1997 16:15:20 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id QAA05450; Sun, 14 Dec 1997 16:15:21 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd005448; Sun Dec 14 16:15:17 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id QAA06706; Sun, 14 Dec 1997 16:15:13 -0800 (PST) From: Ulf Zimmermann Message-Id: <199712150015.QAA06706@Gatekeeper.Alameda.net> Subject: Re: weird IP address In-Reply-To: from Dan Jacobowitz at "Dec 14, 97 05:38:48 pm" To: drow@drow.net (Dan Jacobowitz) Date: Sun, 14 Dec 1997 16:15:12 -0800 (PST) Cc: jas@flyingfox.com, 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 > > > On Sun, 14 Dec 1997, Jim Shankland wrote: > > > Marc Slemko writes: > > > > > I am saying you can use whatever IP you want for a nameserver > > > when registering a domain via the InterNIC and they will not > > > trying to figure out if you are authorized to use it. The > > > InterNIC will list that nameserver in the DNS for that domain, > > > will add a glue record for the nameserver, and will create a > > > host record. You can't have multiple host records for one IP, > > > though. > > > > Back when domain registration was free, InterNIC would actually > > check the name servers you named, making sure that they were reachable > > and had proper NS and SOA records for your new domain. If not, your > > registration was put on hold until you fixed things. > > > > Now that they're charging money for the service, evidently they > > can no longer afford to do this :-(. > > > It strikes me as a little odd that InterNIC puts reverse DNS for the > nameservers on their root servers - in fact, judging by my past > experiences, I could ahve sworn that they did not. > > (In fact, hgaving just gone to check a few others, they do not) > > Apparently they only do so if no other NS is responsible for ther reverse > range specified! > > Go figure. An InterNIC bug? This one is around for a longer time already: Gatekeeper ulf /home/ulf > whois 111.111.111.111 [No name] (NS35119-HST) Hostname: NS1.MINDGFX.NET Address: 111.111.111.111 System: ? running ? ditto this one: Gatekeeper ulf /home/ulf > whois 222.222.222.222 [No name] (NS35120-HST) Hostname: NS2.MINDGFX.NET Address: 222.222.222.222 System: ? running ? Gatekeeper ulf /home/ulf > whois MINDGFX.NET Mindblowin GFX (MINDGFX-DOM) Mellby 8 Laholm, Halland 312 96 Record last updated on 21-Nov-97. Record created on 21-Nov-97. Database last updated on 14-Dec-97 05:23:51 EDT. This was a different domain before. Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Sun Dec 14 16:16:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA25218 for hackers-outgoing; Sun, 14 Dec 1997 16:16:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA25205 for ; Sun, 14 Dec 1997 16:16:20 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id QAA05466; Sun, 14 Dec 1997 16:16:21 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd005464; Sun Dec 14 16:16:12 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id QAA06784; Sun, 14 Dec 1997 16:16:09 -0800 (PST) From: Ulf Zimmermann Message-Id: <199712150016.QAA06784@Gatekeeper.Alameda.net> Subject: Re: weird IP address In-Reply-To: from Marc Slemko at "Dec 14, 97 04:31:49 pm" To: marcs@znep.com (Marc Slemko) Date: Sun, 14 Dec 1997 16:16:09 -0800 (PST) Cc: drow@drow.net, jas@flyingfox.com, 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 > On Sun, 14 Dec 1997, Dan Jacobowitz wrote: > > > > > > > On Sun, 14 Dec 1997, Jim Shankland wrote: > > > > > Marc Slemko writes: > > > > > > > I am saying you can use whatever IP you want for a nameserver > > > > when registering a domain via the InterNIC and they will not > > > > trying to figure out if you are authorized to use it. The > > > > InterNIC will list that nameserver in the DNS for that domain, > > > > will add a glue record for the nameserver, and will create a > > > > host record. You can't have multiple host records for one IP, > > > > though. > > > > > > Back when domain registration was free, InterNIC would actually > > > check the name servers you named, making sure that they were reachable > > > and had proper NS and SOA records for your new domain. If not, your > > > registration was put on hold until you fixed things. > > > > > > Now that they're charging money for the service, evidently they > > > can no longer afford to do this :-(. > > > > > > It strikes me as a little odd that InterNIC puts reverse DNS for the > > nameservers on their root servers - in fact, judging by my past > > experiences, I could ahve sworn that they did not. > > > > (In fact, hgaving just gone to check a few others, they do not) > > > > Apparently they only do so if no other NS is responsible for ther reverse > > range specified! > > > > Go figure. An InterNIC bug? > > Huh? Why are you saying they are doing reverse DNS entries? Nothing > posted here suggests that. Yes, they do: Gatekeeper ulf /home/ulf > nslookup 111.111.111.111 Server: gatekeeper.Alameda.net Address: 207.90.181.2 Name: NS1.MINDGFX.NET Address: 111.111.111.111 Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Sun Dec 14 16:41:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27784 for hackers-outgoing; Sun, 14 Dec 1997 16:41:07 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 QAA27769 for ; Sun, 14 Dec 1997 16:40:54 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id RAA04952; Sun, 14 Dec 1997 17:40:46 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id RAA05082; Sun, 14 Dec 1997 17:41:29 -0700 (MST) Date: Sun, 14 Dec 1997 17:41:29 -0700 (MST) From: Marc Slemko To: Ulf Zimmermann cc: hackers@freebsd.org Subject: Re: weird IP address In-Reply-To: <199712150016.QAA06784@Gatekeeper.Alameda.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 Sun, 14 Dec 1997, Ulf Zimmermann wrote: > > Huh? Why are you saying they are doing reverse DNS entries? Nothing > > posted here suggests that. > > Yes, they do: > > Gatekeeper ulf /home/ulf > nslookup 111.111.111.111 > Server: gatekeeper.Alameda.net > Address: 207.90.181.2 > > Name: NS1.MINDGFX.NET > Address: 111.111.111.111 They should not be doing that because it is very incorrect. I will see if they can be convinced to stop doing this horrible thing. From owner-freebsd-hackers Sun Dec 14 16:43:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28000 for hackers-outgoing; Sun, 14 Dec 1997 16:43:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bob.scl.ameslab.gov (bob.scl.ameslab.gov [147.155.137.254]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27972 for ; Sun, 14 Dec 1997 16:42:53 -0800 (PST) (envelope-from ccsanady@bob.scl.ameslab.gov) Received: from bob.scl.ameslab.gov (localhost [127.0.0.1]) by bob.scl.ameslab.gov (8.8.8/8.8.5) with ESMTP id SAA14933; Sun, 14 Dec 1997 18:45:56 -0600 (CST) Message-Id: <199712150045.SAA14933@bob.scl.ameslab.gov> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Justin T. Gibbs" cc: John-Mark Gurney , hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 11:44:51 MST." <199712141846.LAA10029@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 18:45:56 -0600 From: Chris Csanady Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk FWIW, NetBSD has a couple of nice man pages on their bus stuff. See bus_space(9) and bus_dma(9). It looks like a well abstracted interface, and works on several architectures. We really should be looking at ways to make the BSD's more similar whenever possible. Making the drivers more portable would especially be nice.. so I think that this issue definately deserves more thought. Chris From owner-freebsd-hackers Sun Dec 14 17:16:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01131 for hackers-outgoing; Sun, 14 Dec 1997 17:16:14 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 RAA01106 for ; Sun, 14 Dec 1997 17:16:02 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id LAA00251; Mon, 15 Dec 1997 11:40:22 +1030 (CST) Message-Id: <199712150110.LAA00251@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Karl Pielorz cc: hackers@freebsd.org Subject: Re: /kernel 'calcru' negative offset? In-reply-to: Your message of "Sun, 14 Dec 1997 23:27:16 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 11:40:21 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've posted this in the questions list - but not gotten any replies... I'm > running FreeBSD 2.2.5-Release on a laptop (one that sadly doesn't work > with the PAO laptop support patches / drivers etc.) Can you be more specific (not here, but on the -mobile list) about your problems? We may not be able to help, but without knowing we certainly can't. > When the system boots - the kernel thinks the CPU is only 50Mhz (instead > of 100Mhz) - It's an Intel Pentium 100. This is when running the laptop in > 'brain dead' mode, i.e. no power saving, no spinning down of the harddrive > etc. - and no APM idleing the CPU when it thinks it's not busy... What mode is the unit in? Some systems (eg. this Toshiba) save the current power mode across reboots, so if I shut it down having hotkeyed into Low, when I bring it back up, it will still be in Low. > I've fiddled around with the kernel config - in particular the > CLK_CALIBRATION type config options - all to no avail... > > Is there a way of forcing the kernel to beleive the CPU is 100Mhz? - > intead of 50Mhz? If the kernel measures the clock as being 50MHz, then either your realtime clock is broken, or the CPU *is* running at 50MHz. mike From owner-freebsd-hackers Sun Dec 14 17:21:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01552 for hackers-outgoing; Sun, 14 Dec 1997 17:21:23 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 RAA01538 for ; Sun, 14 Dec 1997 17:21:13 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id LAA00275; Mon, 15 Dec 1997 11:45:22 +1030 (CST) Message-Id: <199712150115.LAA00275@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Chris Csanady cc: "Justin T. Gibbs" , John-Mark Gurney , hackers@freebsd.org Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 18:45:56 MDT." <199712150045.SAA14933@bob.scl.ameslab.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 11:45:22 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > FWIW, NetBSD has a couple of nice man pages on their bus stuff. See > bus_space(9) and bus_dma(9). It looks like a well abstracted interface, > and works on several architectures. We really should be looking at ways > to make the BSD's more similar whenever possible. Making the drivers > more portable would especially be nice.. so I think that this issue > definately deserves more thought. The NetBSD 'bus.h' interface has had a lot of time to stabilise, and plenty of performance-sensitive pounding. For all its conceptual difficulty, it *does* appear to be the best way to go. (No insult intended, JMG!) mike From owner-freebsd-hackers Sun Dec 14 17:22:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01663 for hackers-outgoing; Sun, 14 Dec 1997 17:22:06 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 RAA01646 for ; Sun, 14 Dec 1997 17:21:57 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id RAA27680; Sun, 14 Dec 1997 17:21:39 -0800 (PST) Message-ID: <19971214172139.05704@hydrogen.nike.efn.org> Date: Sun, 14 Dec 1997 17:21:39 -0800 From: John-Mark Gurney To: Chris Csanady Cc: hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port References: <199712141846.LAA10029@pluto.plutotech.com> <199712150045.SAA14933@bob.scl.ameslab.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712150045.SAA14933@bob.scl.ameslab.gov>; from Chris Csanady on Sun, Dec 14, 1997 at 06:45:56PM -0600 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Csanady scribbled this message on Dec 14: > FWIW, NetBSD has a couple of nice man pages on their bus stuff. See > bus_space(9) and bus_dma(9). It looks like a well abstracted interface, > and works on several architectures. We really should be looking at ways > to make the BSD's more similar whenever possible. Making the drivers I agree, I'll take a look... but the last time I looked at it, there wasn't any way to let a device add a resource for use by other devices on the bus... which is a serious limitation IMO... I do plan on using their extent routines for resource tracking... > more portable would especially be nice.. so I think that this issue > definately deserves more thought. well.. that's what I've been doing for the past two and a half months.. and I'm posted a number of messages for people to comment on my design for the new bus/device code... please look at: http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html to see what I'm doing with it... any comments would be welcome, I've recieved very few, so I assume no one has any problems with it yet... -- 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 Sun Dec 14 17:54:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04903 for hackers-outgoing; Sun, 14 Dec 1997 17:54:46 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 RAA04879 for ; Sun, 14 Dec 1997 17:54:39 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id MAA01844; Mon, 15 Dec 1997 12:24:18 +1030 (CST) (envelope-from grog) Message-ID: <19971215122417.32812@lemis.com> Date: Mon, 15 Dec 1997 12:24:17 +1030 From: Greg Lehey To: Marc Slemko Cc: Ulf Zimmermann , hackers@FreeBSD.ORG Subject: Re: weird IP address References: <199712150016.QAA06784@Gatekeeper.Alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Marc Slemko on Sun, Dec 14, 1997 at 05:41:29PM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Dec 14, 1997 at 05:41:29PM -0700, Marc Slemko wrote: > On Sun, 14 Dec 1997, Ulf Zimmermann wrote: > >>> Huh? Why are you saying they are doing reverse DNS entries? Nothing >>> posted here suggests that. >> >> Yes, they do: >> >> Gatekeeper ulf /home/ulf > nslookup 111.111.111.111 >> Server: gatekeeper.Alameda.net >> Address: 207.90.181.2 >> >> Name: NS1.MINDGFX.NET >> Address: 111.111.111.111 > > They should not be doing that because it is very incorrect. I will see if > they can be convinced to stop doing this horrible thing. Good idea. Why not go and explain what they're doing and ask them nicely to stop. Seriously, you've seen the reaction of one of these people already. They're doing it deliberately to circumvent spam filters which check for valid domains and addresses. I'm getting to the stage where I think that global legislation is imperative to be able to do something about these criminals. Greg From owner-freebsd-hackers Sun Dec 14 17:58:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA05216 for hackers-outgoing; Sun, 14 Dec 1997 17:58:19 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 RAA05208 for ; Sun, 14 Dec 1997 17:58:11 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id SAA06965; Sun, 14 Dec 1997 18:57:57 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id SAA05661; Sun, 14 Dec 1997 18:58:40 -0700 (MST) Date: Sun, 14 Dec 1997 18:58:39 -0700 (MST) From: Marc Slemko To: Greg Lehey cc: hackers@FreeBSD.ORG Subject: Re: weird IP address In-Reply-To: <19971215122417.32812@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 Dec 1997, Greg Lehey wrote: > On Sun, Dec 14, 1997 at 05:41:29PM -0700, Marc Slemko wrote: > > On Sun, 14 Dec 1997, Ulf Zimmermann wrote: > > > >>> Huh? Why are you saying they are doing reverse DNS entries? Nothing > >>> posted here suggests that. > >> > >> Yes, they do: > >> > >> Gatekeeper ulf /home/ulf > nslookup 111.111.111.111 > >> Server: gatekeeper.Alameda.net > >> Address: 207.90.181.2 > >> > >> Name: NS1.MINDGFX.NET > >> Address: 111.111.111.111 > > > > They should not be doing that because it is very incorrect. I will see if > > they can be convinced to stop doing this horrible thing. > > Good idea. Why not go and explain what they're doing and ask them > nicely to stop. > > Seriously, you've seen the reaction of one of these people already. > They're doing it deliberately to circumvent spam filters which check > for valid domains and addresses. I'm getting to the stage where I > think that global legislation is imperative to be able to do something > about these criminals. No, it is the InterNIC that is doing this. This current issue (putting bogus reverse DNS entries in for certain host records) is very difficult from creating bogus domains just so they exist to spam from. Note that just creating a bogus domain with bogus nameservers will not be sufficient to get past most valid-domain filters. I certainly do intend to find out why the InterNIC is doing it and ask them nicely to stop. From owner-freebsd-hackers Sun Dec 14 18:07:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA06039 for hackers-outgoing; Sun, 14 Dec 1997 18:07:56 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 SAA06034 for ; Sun, 14 Dec 1997 18:07:49 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id SAA00278; Sun, 14 Dec 1997 18:07:40 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712150207.SAA00278@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: John-Mark Gurney cc: Chris Csanady , hackers@freebsd.org Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 17:21:39 PST." <19971214172139.05704@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 18:07:39 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > for the new bus/device code... please look at: > http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html > to see what I'm doing with it... any comments would be welcome, I've > recieved very few, so I assume no one has any problems with it yet... Daily post requesting review may actually help to catch the group's attention -- sometimes the group sleeps on issues 8) Regards, Amancio From owner-freebsd-hackers Sun Dec 14 18:33:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA08567 for hackers-outgoing; Sun, 14 Dec 1997 18:33:26 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 SAA08515 for ; Sun, 14 Dec 1997 18:33:11 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id SAA27957; Sun, 14 Dec 1997 18:30:34 -0800 (PST) Message-ID: <19971214183034.27523@hydrogen.nike.efn.org> Date: Sun, 14 Dec 1997 18:30:34 -0800 From: John-Mark Gurney To: Mike Smith Cc: hackers@freebsd.org Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port References: <199712150045.SAA14933@bob.scl.ameslab.gov> <199712150115.LAA00275@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712150115.LAA00275@word.smith.net.au>; from Mike Smith on Mon, Dec 15, 1997 at 11:45:22AM +1030 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 Mike Smith scribbled this message on Dec 15: > > > > FWIW, NetBSD has a couple of nice man pages on their bus stuff. See > > bus_space(9) and bus_dma(9). It looks like a well abstracted interface, > > and works on several architectures. We really should be looking at ways > > to make the BSD's more similar whenever possible. Making the drivers > > more portable would especially be nice.. so I think that this issue > > definately deserves more thought. > > The NetBSD 'bus.h' interface has had a lot of time to stabilise, and > plenty of performance-sensitive pounding. For all its conceptual > difficulty, it *does* appear to be the best way to go. > > (No insult intended, JMG!) actually, after reading the man pages... I found the BEST way to describe bus.h... it's just a subset of what I want to do... bus.h only describes how to interact with mem/io ranges by the cpu... my bus/device code does a lot more than that... it keeps keeps track of ALL bus resources.. my bus/device code is best described as a complete device management system than a bus interface mechanism... I have larger plans for my code than just managing hardware devices... the code will be VERY simply to expand it to support such things as using to keep track of char/block devices, and other things... with a common interface.. it will be VERY easy to create something like the win95's list of system devices that is VERY complete... -- 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 Sun Dec 14 18:45:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA09833 for hackers-outgoing; Sun, 14 Dec 1997 18:45:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net ([207.31.78.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA09801 for ; Sun, 14 Dec 1997 18:44:56 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id VAA26577; Sun, 14 Dec 1997 21:45:19 -0500 (EST) Date: Sun, 14 Dec 1997 21:45:18 -0500 (EST) From: "Matthew N. Dodd" To: Marc Slemko cc: Ulf Zimmermann , hackers@FreeBSD.ORG Subject: Re: weird IP address 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 Look, its really easy to filter the addresses of the known rogue nameservers so that your spoofed /domainname rules in sendmail will 451 these messages. > > Gatekeeper ulf /home/ulf > nslookup 111.111.111.111 > > Server: gatekeeper.Alameda.net > > Address: 207.90.181.2 > > > > Name: NS1.MINDGFX.NET > > Address: 111.111.111.111 > > They should not be doing that because it is very incorrect. I will see if > they can be convinced to stop doing this horrible thing. > /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Sun Dec 14 18:56:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA10728 for hackers-outgoing; Sun, 14 Dec 1997 18:56:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA10720 for ; Sun, 14 Dec 1997 18:56:29 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id TAA27503; Sun, 14 Dec 1997 19:56:19 -0700 (MST) Message-Id: <199712150256.TAA27503@pluto.plutotech.com> To: Chris Csanady cc: "Justin T. Gibbs" , John-Mark Gurney , hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 18:45:56 CST." <199712150045.SAA14933@bob.scl.ameslab.gov> Date: Sun, 14 Dec 1997 19:54:28 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >FWIW, NetBSD has a couple of nice man pages on their bus stuff. See >bus_space(9) and bus_dma(9). It looks like a well abstracted interface, >and works on several architectures. We really should be looking at ways >to make the BSD's more similar whenever possible. Making the drivers >more portable would especially be nice.. so I think that this issue >definately deserves more thought. > >Chris Although the bus.h stuff I did for CAM is taken pretty much verbatum from NetBSD, I did not implement bus DMA in the same fashion. The interface was changed slightly to make it more space efficient. -- Justin From owner-freebsd-hackers Sun Dec 14 22:19:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA25151 for hackers-outgoing; Sun, 14 Dec 1997 22:19:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA25116 for ; Sun, 14 Dec 1997 22:18:53 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712150618.WAA25116@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA230286659; Mon, 15 Dec 1997 17:17:39 +1100 From: Darren Reed Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port To: gurney_j@resnet.uoregon.edu Date: Mon, 15 Dec 1997 17:17:38 +1100 (EDT) Cc: mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <19971214183034.27523@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 14, 97 06:30:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from John-Mark Gurney, sie said: > > actually, after reading the man pages... I found the BEST way to describe > bus.h... it's just a subset of what I want to do... bus.h only describes > how to interact with mem/io ranges by the cpu... my bus/device code > does a lot more than that... it keeps keeps track of ALL bus resources.. > > my bus/device code is best described as a complete device management > system than a bus interface mechanism... > > I have larger plans for my code than just managing hardware devices... > the code will be VERY simply to expand it to support such things as > using to keep track of char/block devices, and other things... with a > common interface.. it will be VERY easy to create something like the > win95's list of system devices that is VERY complete... Hmmm, here's a question for you... How long before FreeBSD has an 10-MB kernel at boot-time, just like NT ? (Well, minus whatever bloat there is for the GUI) Darren From owner-freebsd-hackers Sun Dec 14 22:28:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA25783 for hackers-outgoing; Sun, 14 Dec 1997 22:28:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA25771 for ; Sun, 14 Dec 1997 22:28:25 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id XAA20749; Sun, 14 Dec 1997 23:27:51 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd020737; Sun Dec 14 23:27:50 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id XAA25570; Sun, 14 Dec 1997 23:27:44 -0700 (MST) From: Terry Lambert Message-Id: <199712150627.XAA25570@usr09.primenet.com> Subject: Re: blocksize on devfs entries (and related) To: julian@whistle.com (Julian Elischer) Date: Mon, 15 Dec 1997 06:27:44 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, bgingery@gtcs.com, hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Dec 14, 97 00:57:20 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > One "incidental" piece of parametric information I am interested in > > seeing is the physical block size. > > This is already propogated up.. > BTW terry isn't UFS restricted to making dir entries in FRAG sizes rather > than physical blocksizes? Yes and no. DIRBLKSZ is 512, always. 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 Dec 14 22:35:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA26197 for hackers-outgoing; Sun, 14 Dec 1997 22:35:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA26192 for ; Sun, 14 Dec 1997 22:35:33 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id XAA10599; Sun, 14 Dec 1997 23:38:45 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd010547; Sun Dec 14 23:38:32 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id XAA25793; Sun, 14 Dec 1997 23:34:44 -0700 (MST) From: Terry Lambert Message-Id: <199712150634.XAA25793@usr09.primenet.com> Subject: Re: blocksize on devfs entries (and related) To: mike@smith.net.au (Mike Smith) Date: Mon, 15 Dec 1997 06:34:44 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, bgingery@gtcs.com, hackers@FreeBSD.ORG In-Reply-To: <199712140222.MAA04796@word.smith.net.au> from "Mike Smith" at Dec 14, 97 12:52:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Consider the FFS directory management code. It has knowledge of > > physical blocks. In fact, it can not easily handle a directory > > block that is not exactly a physical block size. The current code > > can not be broken across block I/O's, nor can it handle partial > > block I/O's well (there are a number of failure modes). > > This sounds like a fault in the FFS design. Do you know of any work > that deals with this? I dealt with this when I changed the DIRBLKSZ from 512 to 1024 in the Windows95 port of FFS that Artisoft did. I had to do this to support a maximally-sized Unicode file name in the Unicode namespace required by Windows 95's IFS. > > For you to be able to fit a maximally-sized file name in a single > > directory block means your directory block must be over 512 bytes > > in length. > > Would you suggest upping the "fundamental" system blocksize? How would > FFS cope in the face of 2k blocks? It would have to set the DIRBLKSZ to the minimum of the amount required and the physical block size, and deal with agregating multiple blocks. This has implications for the atomicity of the directory operations, since metadata updates must be synchronus. It's messy without changes to namei() and the opacity of a cn_pnbuf structure (which must be opaque in order to be able to serve multiple namespaces at the same time... not just because making it opaque renders the interface reflexive. It's the sweater where you pul one thread... > > Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks > > are not constrained to start at an even offset from the start of the > > disk, only from an even cylinder boundry. > > In the light of the nonexistence of "cylinders" in the proposed model, > it strikes me that this becomes an issue of synthesising a conforming > pseudo-geometry at filesystem creation time, and little more. > Compatability is likely an issue there. Page alignment must equal 1k block alignment for the 0th of 4 blocks; alternately, access will be... uh, slow. > > Ah, brave new world, that has such thing in't. 8-). > > Yeah. I bet the old farts are saying "good thing it's them windbags > discussin' this, if'n it were someone prone to doin' stuff we'd be in > serious shit, eh boys"? 8) Well, you have commit privs, right? I wouldn't be adverse to having a little code committed. ;-). 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 Dec 14 22:48:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27078 for hackers-outgoing; Sun, 14 Dec 1997 22:48:56 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 WAA27061 for ; Sun, 14 Dec 1997 22:48:24 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id RAA01358; Mon, 15 Dec 1997 17:12:41 +1030 (CST) Message-Id: <199712150642.RAA01358@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Mon, 15 Dec 1997 06:34:44 -0000." <199712150634.XAA25793@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 17:12:41 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Consider the FFS directory management code. It has knowledge of > > > physical blocks. In fact, it can not easily handle a directory > > > block that is not exactly a physical block size. The current code > > > can not be broken across block I/O's, nor can it handle partial > > > block I/O's well (there are a number of failure modes). > > > > This sounds like a fault in the FFS design. Do you know of any work > > that deals with this? > > I dealt with this when I changed the DIRBLKSZ from 512 to 1024 in the > Windows95 port of FFS that Artisoft did. I had to do this to support > a maximally-sized Unicode file name in the Unicode namespace required > by Windows 95's IFS. Ok. By this you confess that you understand the issues, and you have dealt with them comprehensively before. I do hope that Artisoft let you take your notes with you... 8) > > > For you to be able to fit a maximally-sized file name in a single > > > directory block means your directory block must be over 512 bytes > > > in length. > > > > Would you suggest upping the "fundamental" system blocksize? How would > > FFS cope in the face of 2k blocks? > > It would have to set the DIRBLKSZ to the minimum of the amount required > and the physical block size, and deal with agregating multiple blocks. Pardon my ignorance, but what's the issue with aggregating blocks? I presume that the directory code reads/writes in multiples of DIRBLKSZ > This has implications for the atomicity of the directory operations, > since metadata updates must be synchronus. It's messy without changes > to namei() and the opacity of a cn_pnbuf structure (which must be opaque > in order to be able to serve multiple namespaces at the same time... not > just because making it opaque renders the interface reflexive. How is an update of a group of blocks any less atomic than the update of a single block? Is this only an issue in the light of fragmentation of a directory on a non-DIRBLKSZ multiple boundary? > > > Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks > > > are not constrained to start at an even offset from the start of the > > > disk, only from an even cylinder boundry. > > > > In the light of the nonexistence of "cylinders" in the proposed model, > > it strikes me that this becomes an issue of synthesising a conforming > > pseudo-geometry at filesystem creation time, and little more. > > Compatability is likely an issue there. > > Page alignment must equal 1k block alignment for the 0th of 4 blocks; > alternately, access will be... uh, slow. I think you've left out enough context there that I can't approach any of that. Unless you are referring to mmap() on such files. mike From owner-freebsd-hackers Sun Dec 14 22:58:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27714 for hackers-outgoing; Sun, 14 Dec 1997 22:58:08 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 WAA27707 for ; Sun, 14 Dec 1997 22:58:02 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id WAA00736; Sun, 14 Dec 1997 22:56:39 -0800 (PST) Message-ID: <19971214225639.55532@hydrogen.nike.efn.org> Date: Sun, 14 Dec 1997 22:56:39 -0800 From: John-Mark Gurney To: Darren Reed Cc: hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port References: <19971214183034.27523@hydrogen.nike.efn.org> <199712150617.WAA20179@resnet.uoregon.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712150617.WAA20179@resnet.uoregon.edu>; from Darren Reed on Mon, Dec 15, 1997 at 05:17:38PM +1100 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 Darren Reed scribbled this message on Dec 15: > In some mail from John-Mark Gurney, sie said: > > > > actually, after reading the man pages... I found the BEST way to describe > > bus.h... it's just a subset of what I want to do... bus.h only describes > > how to interact with mem/io ranges by the cpu... my bus/device code > > does a lot more than that... it keeps keeps track of ALL bus resources.. > > > > my bus/device code is best described as a complete device management > > system than a bus interface mechanism... > > > > I have larger plans for my code than just managing hardware devices... > > the code will be VERY simply to expand it to support such things as > > using to keep track of char/block devices, and other things... with a > > common interface.. it will be VERY easy to create something like the > > win95's list of system devices that is VERY complete... > > Hmmm, here's a question for you... > How long before FreeBSD has an 10-MB kernel at boot-time, just like NT ? > (Well, minus whatever bloat there is for the GUI) hmm... here's a question for you... how much kernel work have you done in making the freebsd kernel as small as possible?? with the changes that I'm working on... the ONLY things neccessary in a static kernel will be the boot device (be it network card or hard disk), and file system for modules... then the rest will be dynamicly loaded... so, does the above comment say that you have a better layer already implemented and ready to go, just waiting for review and committing? if not, then don't go and asume that EVERYTHING that mentions microsoft is a bad thing... did I say it was even going to work like microsoft's products?? PLEASE PLEASE PLEASE PLEASE PLEASE PLEASE PLEASE DON'T MAKE COMMENTS ABOUT CODE (or a spec) YOU'VE NEVER SEEN (Heck, I haven't even seen the code yet :) ). but please do read the spec and tell me how to improve the code. The current spec is at: http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html -- 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 Sun Dec 14 23:24:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA29664 for hackers-outgoing; Sun, 14 Dec 1997 23:24:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA29659 for ; Sun, 14 Dec 1997 23:24:27 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id AAA00141; Mon, 15 Dec 1997 00:23:57 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd000113; Mon Dec 15 00:23:39 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id AAA27555; Mon, 15 Dec 1997 00:23:36 -0700 (MST) From: Terry Lambert Message-Id: <199712150723.AAA27555@usr09.primenet.com> Subject: Re: blocksize on devfs entries (and related) To: mike@smith.net.au (Mike Smith) Date: Mon, 15 Dec 1997 07:23:36 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, bgingery@gtcs.com, hackers@FreeBSD.ORG In-Reply-To: <199712150642.RAA01358@word.smith.net.au> from "Mike Smith" at Dec 15, 97 05:12:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I dealt with this when I changed the DIRBLKSZ from 512 to 1024 in the [ ... ] > Ok. By this you confess that you understand the issues, and you have > dealt with them comprehensively before. I do hope that Artisoft let > you take your notes with you... 8) They can't remove them without a scalpal. I had done a similar change to UFS at Novell, previously. It's common techoology, I think. > > It would have to set the DIRBLKSZ to the minimum of the amount required > > and the physical block size, and deal with agregating multiple blocks. > > Pardon my ignorance, but what's the issue with aggregating blocks? I > presume that the directory code reads/writes in multiples of DIRBLKSZ Soft updates. If you look at the UFS/FFS code, you'll see that directory blocks are 512b, and all other metadata structures are a block size or some integer factor of a blocksize (inodes are 128b -- 4 per disk block) in size. The metadata synchronicity guarantees are largely predicated on the idea that no metadata modification will be larger than a block. This is with 'good reason, now that the cylinder boundries are unknown. Consider a system running soft updates, in the face of a power failure, with a two block write crossing a cylinder boundry. This will result in a seek. All but the most modern drives (which can power track buffer writes and a seek through rotational energy of the disk) will fail to commit the write properly. This would be bad. It is a big issue in considering a switch to soft updates, and it's a meta-issue for high availability systems, where an operation against a database is not atomic, but must be idempotent. So long as a single "transaction" can't cross a seek boundry, this is not an issue. When a single transaction can, then it becomes a *big* issue. I'm pretty sure McKusick's soft updates implementation assumes physical block atomicity for metadata updates. > How is an update of a group of blocks any less atomic than the update > of a single block? See above. > Is this only an issue in the light of fragmentation > of a directory on a non-DIRBLKSZ multiple boundary? No. One would also have to consider LFS extents "fragmented" across a seek boundry, in the event that the soft updates implementation is ever extended to apply to anything other than an FFS/UFS (it's current limitation -- it's not a general event-graph soloution to the ordering guarantee problem). This is also a general issue for ACL's, OS/2 Extended attributes, HFS resource forks, and any other construct that pushes metadata (potentially) over a seek boundry. NTFS and VIVA are other examples that comes to mind. > > > > Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks > > > > are not constrained to start at an even offset from the start of the > > > > disk, only from an even cylinder boundry. > > > > > > In the light of the nonexistence of "cylinders" in the proposed model, > > > it strikes me that this becomes an issue of synthesising a conforming > > > pseudo-geometry at filesystem creation time, and little more. > > > Compatability is likely an issue there. > > > > Page alignment must equal 1k block alignment for the 0th of 4 blocks; > > alternately, access will be... uh, slow. > > I think you've left out enough context there that I can't approach any > of that. Unless you are referring to mmap() on such files. No. The mmap() issue is seperate. Consider two 4k pages on disk: [ 4k ][ 4k ] This is made up of physical blocks: [ 512b ][ 512b ][ 512b ][ 512b ][ 512b ][ 512b ][ 512b ][ 512b ] These physical blocks are agregated, begining on a "cylinder boundry", to form "FAT blocks": [ 512b ][ 1k ][ 1k ][ 1k ][ 512b ] ^ | page boundry Now we have an FAT "block" that spans a page boundry. To access (read/write) the block, we must access two pages -- 8k. This is slow. There is an unsigned char associated with the in core page reference structure. The bits of this value are intended to indicate validity of non-fault-based (ie: not mmap()) presence do that you can do block level instead of page level I/O (for devices with a blocksize of more than 512b, for a 4k page). This would require an access of 1k (two 512b blocks) to reference the page. Assumming this is implemented (the bits are there, but unused for this purpose), this still leaves the need to do a page mapping. To combat this, the "device" for a FATFS must begin on the mythical "cylinder boundry", so that one, not two, page mappings are required for random access of the FAT. This will result in the 1k "blocks" being aligned on page boundries for the device. Not doing these things is "uh, slow". This is one of the reasons the Linux FATFS implementation kicks the FreeBSD's implementation's butt on performance metrics. 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 Dec 14 23:32:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA00334 for hackers-outgoing; Sun, 14 Dec 1997 23:32:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA00326 for ; Sun, 14 Dec 1997 23:32:45 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id XAA26498; Sun, 14 Dec 1997 23:32:07 -0800 (PST) Message-ID: <19971214233205.37702@micron.mini.net> Date: Sun, 14 Dec 1997 23:32:06 -0800 From: Jonathan Mini To: John-Mark Gurney Cc: Darren Reed , hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port Reply-To: Jonathan Mini References: <19971214183034.27523@hydrogen.nike.efn.org> <199712150617.WAA20179@resnet.uoregon.edu> <19971214225639.55532@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <19971214225639.55532@hydrogen.nike.efn.org>; from John-Mark Gurney on Sun, Dec 14, 1997 at 10:56:39PM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John-Mark Gurney stands accused of saying: > Darren Reed scribbled this message on Dec 15: > > > I have larger plans for my code than just managing hardware devices... > > > the code will be VERY simply to expand it to support such things as > > > using to keep track of char/block devices, and other things... with a > > > common interface.. it will be VERY easy to create something like the > > > win95's list of system devices that is VERY complete... > > > > Hmmm, here's a question for you... > > How long before FreeBSD has an 10-MB kernel at boot-time, just like NT ? > > (Well, minus whatever bloat there is for the GUI) > > hmm... here's a question for you... > how much kernel work have you done in making the freebsd kernel as small > as possible?? with the changes that I'm working on... the ONLY things > neccessary in a static kernel will be the boot device (be it network > card or hard disk), and file system for modules... then the rest will > be dynamicly loaded... It looks like there is a slight misconception here. John-Mark was talking about how the code would allow the system to provide a _single_ tree which tracked all system resources, as well as pseudo and virtual resources. Aside from his comment about dynamic loading (which is very useful in some situations, less useful in others) I would like to put forth that his specification (as I have seen it) will actually cause an overall net REDUCTION of code and datapsace usage in the kernel due to the fact that it will allow the removal of several redundant pieces of code. This resource tracking method will help a lot of pieces of code which are pretty much hacks currently. Devfs will become much slimmer, and much easier to maintain. (devices won't need to declare both device nodes and device instances, since the tree will handle this) Also, all of the bus systems, such as ISA, PCI and the "dynamic" busses like the PCMCIA card bus will be able to share much of their code. It will also allow for machine dependancy of several bus types to be removed, such as the ISA bus which is currently in the i386 tree. Through the use of John-Mark's bus/device code, the ISA busses hanging off of PCI busses (and other arrangements, such as non-PCI x86 machines) will be able to be tracked and maintained without machine-dependant code pushed onto the device driver. In addition, much of the bus/device implementation itself is machine independant -- not to mention bus independant, which means that creating ports, and managing new bus types in the future will be very easy. The only parts of the implementation that are bus dependant (and possibly machine dependant) are the portions of code that allow a device to access the resources it has allocated. This is like having a 'bus driver' for each bus as well as a 'device driver' for each device. Because of this, devices which have the same interface, but a different transporting bus, can be "installed" onto multiple busses without ANY change to the driver itself. Your comment of "how long until FreeBSD has a 10M kernel" is valid, but only under a different context than you meant it. FreeBSD needs to look farther down the road at every turn if we are going to avoid undue kernel bloat. This system, in conjunction with the kld system, will make the kernel completely dynamic, and give it the tools needed to track static and dynamic resource usage. This change will result in increased flexibility in our kernel now, and down the road, when FreeBSD truely is multi-platform, it will give FreeBSD a much smaller code-base to maintain, as well as a smaller (and most likely faster) resulting kernel. Although it seems rediculous, I ask a different question : "how long until FreeBSD has a 256k kernel?" I'd like to see a system come into implementation where all modules can become dynamic, including things such as the UFS and inet modules, which currently are basically manditory. (the astute reader would realise that a dynamic module system that did this would require a built-in dependancy system, but that's another issue altogether) This type of dynamic loading of modules can't be implemented correctly until we have a method of easily tracking resources dynamically. John-Mark's bus/device system does this, and, based on my observations of he current codebase, it is obvious (at least to me, YMMV) that this code is greatly required. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Sun Dec 14 23:47:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA01335 for hackers-outgoing; Sun, 14 Dec 1997 23:47:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA01329 for ; Sun, 14 Dec 1997 23:47:08 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id AAA18389; Mon, 15 Dec 1997 00:50:23 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd018376; Mon Dec 15 00:50:17 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id AAA28454; Mon, 15 Dec 1997 00:46:28 -0700 (MST) From: Terry Lambert Message-Id: <199712150746.AAA28454@usr09.primenet.com> Subject: Re: weird IP address To: sthaug@nethelp.no Date: Mon, 15 Dec 1997 07:46:28 +0000 (GMT) Cc: jgrosch@superior.mooseriver.com, hackers@FreeBSD.ORG In-Reply-To: <26132.882093169@verdi.nethelp.no> from "sthaug@nethelp.no" at Dec 14, 97 10:52:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > While sending out hate mail to the latest round of spammers I got an answer > > back from nslookup that I just do not understand. I got spam from > > MoneyMakers.com. When I did an nslookup I got the following: > > > > superior% nslookup moneymakers.com > > Server: superior.mooseriver.com > > Address: 205.166.121.5 > > > > Non-authoritative answer: > > Name: moneymakers.com > > Address: 1.1.1.1 > > My guess is that they're doing that precisely to keep you from responding. > You'll find: > > moneymakers.com. 288800 MX 10 mail.moneymakers.com. > ftp.moneymakers.com. 288800 A 1.1.1.1 > mail.moneymakers.com. 288800 A 1.1.1.1 > www.moneymakers.com. 288800 A 1.1.1.1 > > So they're doing everything they can to prevent you from responding to > their spam. Try looking at the Received: lines for some (possibly) more > relevant info. This is good. Contact InterNIC. They will revoke the domain pending pointing to real IP addresses for the A records. I have had luck with this tack before. 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 Dec 14 23:47:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA01416 for hackers-outgoing; Sun, 14 Dec 1997 23:47:54 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 XAA01382 for ; Sun, 14 Dec 1997 23:47:39 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id SAA01554; Mon, 15 Dec 1997 18:12:07 +1030 (CST) Message-Id: <199712150742.SAA01554@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Mon, 15 Dec 1997 07:23:36 -0000." <199712150723.AAA27555@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 18:12:06 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > It would have to set the DIRBLKSZ to the minimum of the amount required > > > and the physical block size, and deal with agregating multiple blocks. > > > > Pardon my ignorance, but what's the issue with aggregating blocks? I > > presume that the directory code reads/writes in multiples of DIRBLKSZ > > Soft updates. > > If you look at the UFS/FFS code, you'll see that directory blocks are 512b, > and all other metadata structures are a block size or some integer factor > of a blocksize (inodes are 128b -- 4 per disk block) in size. > > The metadata synchronicity guarantees are largely predicated on the idea > that no metadata modification will be larger than a block. This is with > 'good reason, now that the cylinder boundries are unknown. > > Consider a system running soft updates, in the face of a power failure, > with a two block write crossing a cylinder boundry. This will result > in a seek. All but the most modern drives (which can power track buffer > writes and a seek through rotational energy of the disk) will fail to > commit the write properly. > > This would be bad. Unfortunately, the above reasoning is soggy. In the face of a power failure, there is no guarantee that a given block will be completely updated, so the current "guaranteed atomicity" for single-block writes doesn't exist. > It is a big issue in considering a switch to soft updates, and it's > a meta-issue for high availability systems, where an operation against > a database is not atomic, but must be idempotent. Let me just make sure I've got this: the basic point of concern is that a multiblock transaction with storage may (under exceptional conditions) only partially complete, and this partial completion (may) lead to states from which recovery would be problematic. Correct? Hmm. > So long as a single "transaction" can't cross a seek boundry, this is not > an issue. When a single transaction can, then it becomes a *big* issue. I think that the concept of a "seek" boundary is irrelevant; any potential dividing point satsifies the above criteria for concern. A seek window is larger than the interblock window (which is still a possible split point), but smaller than a badblock forwarding window. > This is also a general issue for ACL's, OS/2 Extended attributes, HFS > resource forks, and any other construct that pushes metadata (potentially) > over a seek boundry. NTFS and VIVA are other examples that comes to mind. So what's the "standard" solution? Put serialisation markers in every physical block? How would this deal with a synthetic volume using least-common-multiple aggregate blocks on base media with different block sizes? > > > > > > Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks > > > > > are not constrained to start at an even offset from the start of the > > > > > disk, only from an even cylinder boundry. > > > > > > > > In the light of the nonexistence of "cylinders" in the proposed model, > > > > it strikes me that this becomes an issue of synthesising a conforming > > > > pseudo-geometry at filesystem creation time, and little more. > > > > Compatability is likely an issue there. > > > > > > Page alignment must equal 1k block alignment for the 0th of 4 blocks; > > > alternately, access will be... uh, slow. > > > > I think you've left out enough context there that I can't approach any > > of that. Unless you are referring to mmap() on such files. > > No. The mmap() issue is seperate. > > Consider two 4k pages on disk: > > [ 4k ][ 4k ] > > This is made up of physical blocks: > > [ 512b ][ 512b ][ 512b ][ 512b ][ 512b ][ 512b ][ 512b ][ 512b ] > > These physical blocks are agregated, begining on a "cylinder boundry", > to form "FAT blocks": > > [ 512b ][ 1k ][ 1k ][ 1k ][ 512b ] > ^ > | > page boundry > > Now we have an FAT "block" that spans a page boundry. > > To access (read/write) the block, we must access two pages -- 8k. This is where I'm not getting it. To read the cluster (the 'FAT block'), one reads the required physical blocks, surely. Or is this issue of 'page alignment' more to do with the cache? mike From owner-freebsd-hackers Sun Dec 14 23:51:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA01793 for hackers-outgoing; Sun, 14 Dec 1997 23:51:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA01781 for ; Sun, 14 Dec 1997 23:50:58 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712150750.XAA01781@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA241052236; Mon, 15 Dec 1997 18:50:37 +1100 From: Darren Reed Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port To: gurney_j@resnet.uoregon.edu Date: Mon, 15 Dec 1997 18:50:36 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, hackers@FreeBSD.ORG In-Reply-To: <19971214225639.55532@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 14, 97 10:56:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from John-Mark Gurney, sie said: > > hmm... here's a question for you... > how much kernel work have you done in making the freebsd kernel as small > as possible?? with the changes that I'm working on... the ONLY things > neccessary in a static kernel will be the boot device (be it network > card or hard disk), and file system for modules... then the rest will > be dynamicly loaded... Well, the Solaris2 kernel is 600k (/platform/sun4m/kernel/unix) for 2.5.1, but /platform/sun4m is 4.5M in size with another 1.5M in /usr/kernel. Personally, I find as the number of files required to boot into single user increases, the greater the chance of shit happening on a bad crash and the system becoming unable to boot itself. Personally, I think that the boot device and root fs should always be "in" the kernel so that if someone has nuked all your modules, you can still get up into single user mode. I think that whilst the above goal is interesting (and perhaps worthwhile), there are already problems which need to be solved for LKM's which aren't, as yet, such as merging LKM symbols so that gdb on the kernel is sane and fixing up crash dumps.. Darren From owner-freebsd-hackers Sun Dec 14 23:53:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA02117 for hackers-outgoing; Sun, 14 Dec 1997 23:53:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA02108 for ; Sun, 14 Dec 1997 23:53:09 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id AAA18959; Mon, 15 Dec 1997 00:56:25 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd018947; Mon Dec 15 00:56:18 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id AAA28647; Mon, 15 Dec 1997 00:52:28 -0700 (MST) From: Terry Lambert Message-Id: <199712150752.AAA28647@usr09.primenet.com> Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port To: avalon@coombs.anu.edu.au (Darren Reed) Date: Mon, 15 Dec 1997 07:52:28 +0000 (GMT) Cc: gurney_j@resnet.uoregon.edu, mike@smith.net.au, hackers@freebsd.org In-Reply-To: <199712150618.WAA25116@hub.freebsd.org> from "Darren Reed" at Dec 15, 97 05: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 > > I have larger plans for my code than just managing hardware devices... > > the code will be VERY simply to expand it to support such things as > > using to keep track of char/block devices, and other things... with a > > common interface.. it will be VERY easy to create something like the > > win95's list of system devices that is VERY complete... > > Hmmm, here's a question for you... > How long before FreeBSD has an 10-MB kernel at boot-time, just like NT ? > (Well, minus whatever bloat there is for the GUI) We will go to preferential ELF segment loading and LKM's for non-boot-critical devices long before that happens. 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 Dec 14 23:58:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA02507 for hackers-outgoing; Sun, 14 Dec 1997 23:58:45 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 XAA02500 for ; Sun, 14 Dec 1997 23:58:37 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA00907; Sun, 14 Dec 1997 23:58:14 -0800 (PST) Message-ID: <19971214235813.15283@hydrogen.nike.efn.org> Date: Sun, 14 Dec 1997 23:58:13 -0800 From: John-Mark Gurney To: Darren Reed Cc: hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port References: <19971214225639.55532@hydrogen.nike.efn.org> <199712150750.XAA03236@resnet.uoregon.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712150750.XAA03236@resnet.uoregon.edu>; from Darren Reed on Mon, Dec 15, 1997 at 06:50:36PM +1100 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 Darren Reed scribbled this message on Dec 15: > In some mail from John-Mark Gurney, sie said: > > > > hmm... here's a question for you... > > how much kernel work have you done in making the freebsd kernel as small > > as possible?? with the changes that I'm working on... the ONLY things > > neccessary in a static kernel will be the boot device (be it network > > card or hard disk), and file system for modules... then the rest will > > be dynamicly loaded... > > Well, the Solaris2 kernel is 600k (/platform/sun4m/kernel/unix) for 2.5.1, > but /platform/sun4m is 4.5M in size with another 1.5M in /usr/kernel. > Personally, I find as the number of files required to boot into single > user increases, the greater the chance of shit happening on a bad crash > and the system becoming unable to boot itself. Personally, I think that > the boot device and root fs should always be "in" the kernel so that if > someone has nuked all your modules, you can still get up into single user > mode. umm... that's EXACTLY what I said...: "the ONLY things neccessary in a static kernel will be the boot device (be it network card or hard disk), and file system" now I did add for modules which might of confused you, but unless freebsd's boot process changes significantly, there isn't going to be easy support for loading each neccessary "module" to get into single usermode... plus, I don't want to think about stuff like that for the x86.. :) > I think that whilst the above goal is interesting (and perhaps worthwhile), > there are already problems which need to be solved for LKM's which aren't, > as yet, such as merging LKM symbols so that gdb on the kernel is sane and > fixing up crash dumps.. who care's about LKM's?? LKM's as they now are should just die... I'm working on replacing it with the kld system (which once fully working looks like it will be renamed to LKM)... and this to some extent should already be supported... thought I haven't personally tried it yet myself... seems you've forgotten that this is a volunteer project... I'm doing this because I choose to, not because your paying me to, (thought if you need something worked on, I wouldn't mind getting paid)... -- 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 Dec 15 00:12:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA03513 for hackers-outgoing; Mon, 15 Dec 1997 00:12:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pili.adn.edu.ph ([165.220.57.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA03487; Mon, 15 Dec 1997 00:12:12 -0800 (PST) (envelope-from art@pili.adn.edu.ph) Received: from localhost (art@localhost) by pili.adn.edu.ph (8.8.5/8.8.5) with SMTP id QAA03695; Mon, 15 Dec 1997 16:19:14 +0800 (PHT) Date: Mon, 15 Dec 1997 16:19:14 +0800 (PHT) From: Arthur Alacar To: hackers@FreeBSD.ORG cc: freebsd-questions@FreeBSD.ORG Subject: ESS ES688 Audio Drive 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 Am running on FreeBSD-2.2.5 and is trying to configure my ESS ES688 Audio Drive. But CAN'T make it to work. i have tried using soundblaster pro device ... with this kernel configuration.. > options SBC_IRQ=5 > controller snd0 > device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr > device opl0 at isa? port 0x388 > device joy0 at isa? port "IO_GAME" and the OS were able to DETECT these devices.. but whenever i tried working with sounds... am receiving this error message. > Sound: DMA timed out - IRQ/DRQ config error? is there any available support for this card? or how can i make this up? need help on this. THANK YOU! Merry Christmas BSD people! .a.r.t. From owner-freebsd-hackers Mon Dec 15 00:26:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA05005 for hackers-outgoing; Mon, 15 Dec 1997 00:26:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04988 for ; Mon, 15 Dec 1997 00:26:34 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712150826.AAA04988@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA243794368; Mon, 15 Dec 1997 19:26:08 +1100 From: Darren Reed Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port To: gurney_j@resnet.uoregon.edu Date: Mon, 15 Dec 1997 19:26:08 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, hackers@FreeBSD.ORG In-Reply-To: <19971214235813.15283@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 14, 97 11:58:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from John-Mark Gurney, sie said: > > seems you've forgotten that this is a volunteer project... I'm doing > this because I choose to, not because your paying me to, (thought if > you need something worked on, I wouldn't mind getting paid)... no, but because its a volunteer effort doesn't mean you should ignore the people who have to use it. From owner-freebsd-hackers Mon Dec 15 00:44:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA06650 for hackers-outgoing; Mon, 15 Dec 1997 00:44:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA06589 for ; Mon, 15 Dec 1997 00:44:03 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA17668 for freebsd-hackers@freebsd.org; Mon, 15 Dec 1997 09:43:29 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id JAA03985; Mon, 15 Dec 1997 09:34:39 +0100 (MET) Date: Mon, 15 Dec 1997 09:34:39 +0100 (MET) Message-Id: <199712150834.JAA03985@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden 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 References: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: 132 Column mode on VGA Consoles X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Karl Pielorz wrote: > Is there a way of getting the kernel to boot in 132 column mode on a VGA > based 2.2.5-Release / 2.2.2-Release box at all? This used to be possible for some (now rather obsolete) hardware in the pcvt console driver. The solution was not elegant (everything was hard-coded into the driver), and eventually became stale. With the advent of affordable graphics equipment, most people don't seem to be that much interested in working hard on the text console enhancement (although i know Sųren's got some plans in mind), at least not enough to spend hundreds of hours there. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Dec 15 01:11:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09618 for hackers-outgoing; Mon, 15 Dec 1997 01:11:59 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 BAA09613 for ; Mon, 15 Dec 1997 01:11:52 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id TAA00961; Mon, 15 Dec 1997 19:36:15 +1030 (CST) Message-Id: <199712150906.TAA00961@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Mike Smith cc: Terry Lambert , bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Mon, 15 Dec 1997 18:12:06 +1030." <199712150742.SAA01554@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 19:36:13 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > Consider a system running soft updates, in the face of a power failure, > > with a two block write crossing a cylinder boundry. This will result > > in a seek. All but the most modern drives (which can power track buffer > > writes and a seek through rotational energy of the disk) will fail to > > commit the write properly. > > Unfortunately, the above reasoning is soggy. In the face of a power > failure, there is no guarantee that a given block will be completely > updated, so the current "guaranteed atomicity" for single-block writes > doesn't exist. Oops. I'm the one who's wet here; I see the assumption now - block is not written, block is corrupt, block is written are all detectable states. This presumes there's no way for the device to present a block that's been only partially updated, which is reasonable. mike From owner-freebsd-hackers Mon Dec 15 01:13:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09977 for hackers-outgoing; Mon, 15 Dec 1997 01:13:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09970 for ; Mon, 15 Dec 1997 01:13:50 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id BAA26688; Mon, 15 Dec 1997 01:13:07 -0800 (PST) Message-ID: <19971215011306.46218@micron.mini.net> Date: Mon, 15 Dec 1997 01:13:06 -0800 From: Jonathan Mini To: Joerg Wunsch Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 132 Column mode on VGA Consoles Reply-To: Jonathan Mini References: <199712150834.JAA03985@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: <199712150834.JAA03985@uriah.heep.sax.de>; from J Wunsch on Mon, Dec 15, 1997 at 09:34:39AM +0100 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch stands accused of saying: > With the advent of affordable graphics equipment, most people don't > seem to be that much interested in working hard on the text console > enhancement (although i know Sųren's got some plans in mind), at least > not enough to spend hundreds of hours there. I plan on implementing a layered console system that will allow the syscons driver (or it's kin) to use VESA VBE text modes to display it's output. This will mean that the 132x25, 132x30, 132x50, 132x60 and other modes like it will be feasable. As soon as the vesa code goes in, there will be _three_ possible sources of contention over the system console's device(s), the Xfree86 system, the VESA library, and syscons itself. In order to rectify these contentions, I plan on implementing a simple dual or possibly tri-layered console system that will remove these contentions. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Mon Dec 15 01:23:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA10833 for hackers-outgoing; Mon, 15 Dec 1997 01:23:01 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 BAA10818 for ; Mon, 15 Dec 1997 01:22:53 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id EAA04315; Mon, 15 Dec 1997 04:22:15 -0500 (EST) (envelope-from toor) Message-Id: <199712150922.EAA04315@dyson.iquest.net> Subject: Re: blocksize on devfs entries (and related) In-Reply-To: <199712150723.AAA27555@usr09.primenet.com> from Terry Lambert at "Dec 15, 97 07:23:36 am" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 15 Dec 1997 04:22:14 -0500 (EST) Cc: mike@smith.net.au, tlambert@primenet.com, bgingery@gtcs.com, hackers@FreeBSD.ORG From: "John S. Dyson" 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 Terry Lambert said: > > This is one of the reasons the Linux FATFS implementation kicks the > FreeBSD's implementation's butt on performance metrics. > I could be wrong, but I suspect the reason that our FATFS is slow now is that don't use our cluster code. It isn't that slow anymore, after all of the unneeded sync writes were fixed. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Mon Dec 15 01:23:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA10886 for hackers-outgoing; Mon, 15 Dec 1997 01:23:14 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 BAA10817 for ; Mon, 15 Dec 1997 01:22:52 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id BAA00888; Mon, 15 Dec 1997 01:22:06 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712150922.BAA00888@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Darren Reed cc: gurney_j@resnet.uoregon.edu, hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Mon, 15 Dec 1997 18:50:36 +1100." <199712150750.XAA01781@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 01:22:06 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Well, the Solaris2 kernel is 600k (/platform/sun4m/kernel/unix) for 2.5.1, You mean their OS boot loader is 600k 8) Last but not least I miss the part of a critical and or constructive criticism. It almost looks like you are having a bad day 8) Cheers, Amancio From owner-freebsd-hackers Mon Dec 15 01:30:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA11673 for hackers-outgoing; Mon, 15 Dec 1997 01:30:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA11665 for ; Mon, 15 Dec 1997 01:30:48 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712150930.BAA11665@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA250638203; Mon, 15 Dec 1997 20:30:03 +1100 From: Darren Reed Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 15 Dec 1997 20:30:03 +1100 (EDT) Cc: gurney_j@resnet.uoregon.edu, hackers@FreeBSD.ORG In-Reply-To: <199712150922.BAA00888@rah.star-gate.com> from "Amancio Hasty" at Dec 15, 97 01:22:06 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Amancio Hasty, sie said: > > > Well, the Solaris2 kernel is 600k (/platform/sun4m/kernel/unix) for 2.5.1, > > You mean their OS boot loader is 600k 8) > > Last but not least I miss the part of a critical and or constructive > criticism. It almost looks like you are having a bad day 8) Ack! Sorry. the kernel (/kernel/genunix) is 880k. /kernel is around 9M in size and is just comprimsed of the kernel + modules. so around 14 - 15M of modules, all up. my reference to a 10M kernel wasn't how big /kernel would be, but how big the kernel is when running in multiuser mode (when you've got all your drivers and everything else loaded and have allocated memory to store information about anything which might be relevant). From owner-freebsd-hackers Mon Dec 15 01:38:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12195 for hackers-outgoing; Mon, 15 Dec 1997 01:38:43 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 BAA12187 for ; Mon, 15 Dec 1997 01:38:39 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id BAA00969; Mon, 15 Dec 1997 01:38:31 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712150938.BAA00969@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Darren Reed cc: gurney_j@resnet.uoregon.edu, hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Mon, 15 Dec 1997 20:30:03 +1100." <199712150930.BAA00916@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 01:38:30 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thats fine . John-Mark's work as well as other in the area of bus abstraction will serve two purpose: 1. pave the way for robust PnP support in FreeBSD 2. abstract bus interface for multiple platforms We really need to iron out the PnP issue on FreeBSD and the bus interface for multiple platforms is a secondary benefit. Amancio > In some mail from Amancio Hasty, sie said: > > > > > Well, the Solaris2 kernel is 600k (/platform/sun4m/kernel/unix) for 2.5.1, > > > > You mean their OS boot loader is 600k 8) > > > > Last but not least I miss the part of a critical and or constructive > > criticism. It almost looks like you are having a bad day 8) > > Ack! Sorry. > > the kernel (/kernel/genunix) is 880k. /kernel is around 9M in size and > is just comprimsed of the kernel + modules. > > so around 14 - 15M of modules, all up. > > my reference to a 10M kernel wasn't how big /kernel would be, but how > big the kernel is when running in multiuser mode (when you've got all > your drivers and everything else loaded and have allocated memory to > store information about anything which might be relevant). > From owner-freebsd-hackers Mon Dec 15 03:20:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA18415 for hackers-outgoing; Mon, 15 Dec 1997 03:20:31 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 DAA18409 for ; Mon, 15 Dec 1997 03:20:25 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id DAA20369; Mon, 15 Dec 1997 03:20:00 -0800 (PST) To: John-Mark Gurney cc: Darren Reed , hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 23:58:13 PST." <19971214235813.15283@hydrogen.nike.efn.org> Date: Mon, 15 Dec 1997 03:20:00 -0800 Message-ID: <20365.882184800@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > seems you've forgotten that this is a volunteer project... I'm doing > this because I choose to, not because your paying me to, (thought if > you need something worked on, I wouldn't mind getting paid)... Speaking for myself, John-Mark, I say just keep doing what you're doing and who knows, if it bears real fruit then the monetary aspects may work themselves out also [touches the side of his nose]. It's been known to happen before. :-) Jordan From owner-freebsd-hackers Mon Dec 15 03:47:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA20063 for hackers-outgoing; Mon, 15 Dec 1997 03:47:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from db2server.voga.com.br (db2server.voga.com.br [200.239.39.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA20057 for ; Mon, 15 Dec 1997 03:47:00 -0800 (PST) (envelope-from daniel_sobral@voga.com.br) From: daniel_sobral@voga.com.br Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by db2server.voga.com.br (8.8.3+2.6Wbeta9/8.8.7) with SMTP id IAA12998; Mon, 15 Dec 1997 08:46:18 -0300 Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 0325656E.0040A429 ; Mon, 15 Dec 1997 08:46:03 -0300 X-Lotus-FromDomain: VOGA To: tlambert@primenet.com cc: hackers@FreeBSD.ORG Message-ID: <8325656E.003FF988.00@papagaio.voga.com.br> Date: Mon, 15 Dec 1997 08:45:43 -0300 Subject: Re: Why so many steps to build new kernel? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The idea that there needs to be a mechanism for handling mutual > exclusions presupposes (incorrectly, IMO), that some drivers are > mutually exclusive. Well, as far as I know, syscon and the vt stuff are mutually exclusive. And, generally, speaking, two drivers to the same piece of hardware will be mutually exclusive. That's not that unlikely to ignore the possibility. > Similarly, prerequisite identification is well and good, but can be > done symbolically, without reference to a kernel configurator. Similarly, the kernel configurator should not display syscon's history buffer size option if you did not select syscon. > So what's left for a kernel configurator to do? > ...Nothing. In a perfect world, with elf kernel, PnP PCI devices, devfs, and well behaviored hardware, sure, nothing's left to do. (except that, there probably would be even then) From owner-freebsd-hackers Mon Dec 15 04:46:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA23823 for hackers-outgoing; Mon, 15 Dec 1997 04:46:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA23813 for ; Mon, 15 Dec 1997 04:46:53 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id EAA27121; Mon, 15 Dec 1997 04:46:38 -0800 (PST) Message-ID: <19971215044637.29929@micron.mini.net> Date: Mon, 15 Dec 1997 04:46:37 -0800 From: Jonathan Mini To: "Jordan K. Hubbard" Cc: Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <19971211013734.16942@micron.mini.net> <26106.881834408@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <26106.881834408@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 02:00:08AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > Give me something that's written in straight C and easy to wrap into > TCL (which should be possible unless you decide to pass all kinds of > nasty structures around and expose that in the C API) and I'll be your > friend for life. OK, so maybe that doesn't sound like such a treat, > so let me just say that I'd really really appreciate it and so would > many others. :) I've never used Tcl, so I don't know what kind of exportability it has, but the following system (which I'm planning on using for a network exportable GUI) should be exportable to practically any langauge. The following system may seem a little overkill, but I'm writing it for another project, (I have to write a development kit to ship with my game, and it needs it's own GUI, there are other things in that product that need it also) you're baiscally getting half of it for free. (yay :)) This GUI is split into four layers, while one layer is technically the "application," and may or may not count in your book, it's still there. :) The layers are the device layer, the interface layer, the transport layer and the application layer. The device layer implements sources for events (this is an event-driven system, of course) from actual real-world devices, such as timers, a keyboard, a mouse, whatever. It is responsible for interfacing with the world, so to speak. The other thing the device layer does is display objects. Objects are an encapsulation structure which can represent (and does represent) every item in the GUI. When an object needs to be displayed, an event is generated and (eventually) sent to the display layer, which then displays it. Obviously, this means that the display layer must know how to draw every possible kind of object, and that everything which could possibly be displayed on-screen must be representable in the form of an object. The second layer, called the interface layer, actually handles the user interface itself. That is, it responds to events by either rearanging objects, filtering those events, or generating new events. Although it does nothing directly with either the user or the application, it is the essence of the user interface, and defines all of its behaviour. (well, most of it) The third layer, called the transport layer, holds two jobs : + The first is like what a window manager does for X. It manages windows and other similar groups of objects in ways that are transparant to both the objects themselves and the application. + Secondly, it manages the transportation method between the actual user interface (embodied by the display layer and the interface layer) and the actual application. This layer can talk to any of the other layers, and in some cases re-arranges the layering. For exameple, the transport layer is repsonsible for doing things like exporting the user's devices to (possibly) multiple clients. To do this, it takes the place of all of the lower layers for the client, and all of the upper layers for the server. The fourth, and final, layer is the application itself, or more rightly, the interface the application has to the UI system. (i.e. the application's API) Because this layer is above the transport layer, it could be anything. It is feasable to implement the fourth layer using a pipe which sends events back and forth as text strings. With that method, a Bourne shell script could be the final application, so I don't think Tcl will have any problems. > What do you think? Not next Tuesday, but I'll (hopefully) have a version working in a month. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Mon Dec 15 04:50:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA24057 for hackers-outgoing; Mon, 15 Dec 1997 04:50:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA24043 for ; Mon, 15 Dec 1997 04:50:03 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id EAA27134; Mon, 15 Dec 1997 04:49:50 -0800 (PST) Message-ID: <19971215044949.04507@micron.mini.net> Date: Mon, 15 Dec 1997 04:49:49 -0800 From: Jonathan Mini To: "Jordan K. Hubbard" Cc: Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <19971211013734.16942@micron.mini.net> <26106.881834408@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <26106.881834408@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 02:00:08AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > We basically just need: > > o Buttons - pushbutton, radio, checkbox. > > o Scrolling list menus (or scrolling arrays of buttons, > however you want to conceptualize it) > > o Entry fields with reasonably emacs-like character editing > support. > > o Scrolling text boxes and simple text fields. > > o Checkbox / Radio > o Gauges. > > o Compound dialogs. > > o Simple forms entry. Here's a listing of the "native" objects, i.e. objects that are planeed to be supported allready. With the exception of OBJ_PICT, there should be no problems displaying ANY of them in a text mode : OBJ_TEXT text string OBJ_PICT image OBJ_BARGRP a horizontal or vertical bar of objects. Used for things like menu bars, status lines, etc, etc. (placement of objects can be resized and rearanged via drags & drops, if enabled) OBJ_BOX box. (outline [frame], or filled) OBJ_BUTTON button (emits an even when clicked on) OBJ_CHECKGRP group where any or all items can be selected. OBJ_DIALOG your basic dialog box. OBJ_DROPBOX one-line box with list of choices, drop-down menu will show all of them. OBJ_EDITOR basic editor. allows for single or multi-line text editing. OBJ_FOLDERGRP group of objects, where only one is displayed at a time, and each has a 'tab' that selects which one is displayed. (e.g. Win95's properties menus' layouts) OBJ_FRAMEDIAG hook for window manager - the frame around a dialog box. OBJ_FRAMEMENU hook for window manager - the frame around a menu. OBJ_FRAMEPAL hook for window manager - the frame around a floating palette. OBJ_FRAMEWIN hook for window manager - the frame around a window. OBJ_GRIDGROUP aligns children into a grid, where one or more may be selected. (e.g. for a toolbar) OBJ_GROUP basic group displays all objects as if independant, but placed relative to group's origin, and clipped to group's size. OBJ_HISTORY input line with a drop-down menu of past choices. OBJ_HLINE a horizontal line, used for many things. OBJ_INPUT one-line text input. OBJ_LABEL labels another object. (e.g. would label a entry box in a dialog box) OBJ_RADIOGRP group where only one item can be selected. OBJ_RINGGRP group of objects that share a display space by ordering themselves in a ring that can be rotated via grabbing the backdrop and dragging. (e.g. 3DS/Max's control system, and others) OBJ_SCROLL a scrolling group. used to encapulate large or dynamic sized objects. will optionally show horizontal and vertical scroll bars. OBJ_SLIDEGRP used to implement "slider" controls. display's it's children for the range, (e.g. a OBJ_SL_TICK, OBJ_SL_FILL, OBJ_SL_NUM) and adds [optional] buttons for incrementing/decrementing the value. All slider's can be of two types : 'requested' and 'actuall.' This allows for one indicator (for exameple, a OBJ_SL_FILL) to show te atual setting, while another (for example, a OBJ_SL_TICK) to show a requested value. This is useful for controlling things that take time to respond to a new setting. OBJ_SL_TICK a bar with a tick on it [draggable] OBJ_SL_NUM a number [editable] OBJ_SL_FILL a solid color fills full or empty side. [draggable] OBJ_SL_UNION stacks several on top of each other. OBJ_TREEGRP group where objects are listed in a [collapsable] tree. OBJ_MENU an actual menu OBJ_MENUGRP like OBJ_TREEGRP, but creates a popup/pulldown menu for each level of the tree, a la sub-menus. OBJ_VALIDATOR requires children be valid against a rule-set. OBJ_VLINE a vertical line, used for many things. OBJ_WINDOW an actual window If any don't make much sense, or you see something you thik is missing, please let me know, and I'll (probably) be happy to add it. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Mon Dec 15 04:50:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA24114 for hackers-outgoing; Mon, 15 Dec 1997 04:50:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from didda.est.is (ppp-22.est.is [194.144.208.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA24092; Mon, 15 Dec 1997 04:50:33 -0800 (PST) (envelope-from totii@est.is) Received: from est.is (didda.est.is [192.168.255.1]) by didda.est.is (8.8.7/8.8.7) with ESMTP id MAA01054; Mon, 15 Dec 1997 12:49:38 GMT (envelope-from totii@est.is) Message-ID: <34952761.3D618169@est.is> Date: Mon, 15 Dec 1997 12:49:38 +0000 From: "Žoršur Ivarsson" X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Arthur Alacar CC: hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: ESS ES688 Audio Drive References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Arthur Alacar wrote: > > Am running on FreeBSD-2.2.5 and is trying to configure my > ESS ES688 Audio Drive. But CAN'T make it to work. > > i have tried using soundblaster pro device ... with this kernel > configuration.. > > > options SBC_IRQ=5 > > > controller snd0 > > device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr > > device opl0 at isa? port 0x388 > > device joy0 at isa? port "IO_GAME" > > and the OS were able to DETECT these devices.. > > but whenever i tried working with sounds... am receiving this error > message. > > > Sound: DMA timed out - IRQ/DRQ config error? > > is there any available support for this card? or how can i make this up? > > need help on this. THANK YOU! > > Merry Christmas BSD people! > > .a.r.t. Try the new driver from Luigi, It does work well for me and fixed this proble in my system -- Žóršur Ķvarsson Thordur Ivarsson Rafeindavirki Electronic technician Noršurgötu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri Ķsland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-hackers Mon Dec 15 05:03:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA25105 for hackers-outgoing; Mon, 15 Dec 1997 05:03:10 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 FAA25099 for ; Mon, 15 Dec 1997 05:02:56 -0800 (PST) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0xha9p-0032gtC; Mon, 15 Dec 97 14:02 MET Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Mon, 15 Dec 1997 13:24:06 +0100 (MET) (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; Mon, 15 Dec 1997 13:15:40 +0100 (CET) (Smail-3.2.0.94 1997-Apr-22 #7 built 1997-Jul-4) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: 132 Column mode on VGA Consoles In-Reply-To: <199712150834.JAA03985@uriah.heep.sax.de> from J Wunsch at "Dec 15, 97 09:34:39 am" To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 15 Dec 1997 13:15:40 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG 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 J Wunsch wrote: > > This used to be possible for some (now rather obsolete) hardware in > the pcvt console driver. Obsolete ? No ! Manufacturers tend to be backward compatible within their chip-families, so this still runs (for the supported chipsets) with a little tweaking for the chip-id on up-to-date hardware. 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 Mon Dec 15 05:03:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA25165 for hackers-outgoing; Mon, 15 Dec 1997 05:03:50 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 FAA25150 for ; Mon, 15 Dec 1997 05:03:29 -0800 (PST) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0xha9r-0032hIC; Mon, 15 Dec 97 14:02 MET Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Mon, 15 Dec 1997 13:28:54 +0100 (MET) (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; Mon, 15 Dec 1997 13:20:29 +0100 (CET) (Smail-3.2.0.94 1997-Apr-22 #7 built 1997-Jul-4) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: 132 Column mode on VGA Consoles In-Reply-To: <19971215011306.46218@micron.mini.net> from Jonathan Mini at "Dec 15, 97 01:13:06 am" To: j_mini@efn.org Date: Mon, 15 Dec 1997 13:20:29 +0100 (CET) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG 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 Jonathan Mini wrote: > > As soon as the vesa code goes in, there will be _three_ possible sources of > contention over the system console's device(s), the Xfree86 system, the VESA > library, and syscons itself. Hopefully this implementation will allow other "drivers" than syscons. If it would, it would we one step towards the unified console driver we are talking about since 386bsd 0.1. 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 Mon Dec 15 05:28:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA27050 for hackers-outgoing; Mon, 15 Dec 1997 05:28:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA27040 for ; Mon, 15 Dec 1997 05:28:23 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id FAA27182; Mon, 15 Dec 1997 05:24:33 -0800 (PST) Message-ID: <19971215052432.11830@micron.mini.net> Date: Mon, 15 Dec 1997 05:24:32 -0800 From: Jonathan Mini To: hm@kts.org Cc: j_mini@efn.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: 132 Column mode on VGA Consoles Reply-To: Jonathan Mini References: <19971215011306.46218@micron.mini.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Hellmuth Michaelis on Mon, Dec 15, 1997 at 01:20:29PM +0100 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hellmuth Michaelis stands accused of saying: > Jonathan Mini wrote: > > > > As soon as the vesa code goes in, there will be _three_ possible sources of > > contention over the system console's device(s), the Xfree86 system, the VESA > > library, and syscons itself. > > Hopefully this implementation will allow other "drivers" than syscons. If it > would, it would we one step towards the unified console driver we are talking > about since 386bsd 0.1. Of course. Why else would I want to layer the code? Personally, I am annoyed with syscons as it is now, and would (at least) like to see two other 'drivers' : one that is _much_ smaller (a TTY-only implementation, for example) and one that is vt100 instead of SCO compatable. I'm sure there are other things that people will want to see. But, for now, I just want to get rid of the contention over the display hardware, and since my only option to fix that is to layer the console code, I might as well Get It Right. The layering is simple : 1) The lowest layer is, of course, the devices. VESA VBE, the BIOS int 10 services, and a hardware-specific driver are three that come to mind. Also, input devices such as the keyboard and mouse. 2) A layer which implements the user-interface which binds the other two layers together. This layer could be anything from a NOOP to a virtual terminal system like syscons is now, to a full-flegded windowing system. I don't care. :) 3) A layer which uses a tty to interface with the rest of the world. this layer implements junk like VT100 support, SCO or whatever. Two things should be noted : 1) The kernel's private interface to the console needs to be changed, as well as /dev/cons's mutilation of the tty methidology. The kernel console code also needs to be moved out of the i386 tree. This is no hardware dependant, layer 1 of the console system is. (The console code as it is now isn't really hardware dependant either) 2) I will personally write the code to provide ALL of the functionality of syscons, so don't even go down the road of "but you need to provide blah blah blah blah blah." I could go into long discussions about how wonderful this would be in the future, but I'm sure you've all already heard the advantages of a layered console. For now, it will just remove the device contention of the the current console system via the second layer. (It will have support for handling multiple consumers, and switching between them) In the very short term, little will be gained from this, except that the code will probably get slightly larger, but then again perhaps not. A few minor features will be gained, such as being able to use VESA video modes. However, in the long run, the code could feasably be MUCH smaller (a BIOS int 10 layer with a NOOP layer with a TTY emulation layer would be MUCH smaller) and feasably be able to do more . -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Mon Dec 15 06:12:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA00381 for hackers-outgoing; Mon, 15 Dec 1997 06:12:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pili.adn.edu.ph ([165.220.57.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA00349; Mon, 15 Dec 1997 06:12:34 -0800 (PST) (envelope-from art@pili.adn.edu.ph) Received: from localhost (art@localhost) by pili.adn.edu.ph (8.8.5/8.8.5) with SMTP id WAA06795; Mon, 15 Dec 1997 22:18:44 +0800 (PHT) Date: Mon, 15 Dec 1997 22:18:44 +0800 (PHT) From: Arthur Alacar To: Žoršur Ivarsson cc: hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: ESS ES688 Audio Drive In-Reply-To: <34952761.3D618169@est.is> 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 > > Try the new driver from Luigi, It does work well for me and fixed this > proble in my system > and where can i find this? .a.r.t. From owner-freebsd-hackers Mon Dec 15 06:37:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA01974 for hackers-outgoing; Mon, 15 Dec 1997 06:37:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA01962 for ; Mon, 15 Dec 1997 06:36:52 -0800 (PST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00558; Mon, 15 Dec 1997 09:36:10 -0500 (EST) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.8.7/8.8.7) with ESMTP id JAA08694; Mon, 15 Dec 1997 09:36:04 -0500 (EST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199712151436.JAA08694@bmcgover-pc.cisco.com> To: marcs@znep.com, totii@est.is, sthaug@nethelp.no cc: hackers@freebsd.org Subject: RE: Re: Weird IP addresses Date: Mon, 15 Dec 1997 09:36:04 -0500 From: Brian McGovern Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk None of the explanations are true. The fact of the matter is the Internic has broken down most of their "Reserved" Class A, and B blocks in order to make as many C blocks as possible. There was an RFC published a while back (I remember it in the six month timeframe, but it may be older) that if you compare to earlier address allocation RFCs, has a far fewer number of "reserved blocks". The fact that the Internic is trying to make money is true. However, they're doing it by stretching what little resources they have left, not by allowing bogus domain entries. And yes, you can do whatever you like to your local DNS, and it doesn't have to be "correct". Remember, however, that if the rest of the net tends not to agree with you, whatever you do locally will have little impact on the 'Net as a whole. From owner-freebsd-hackers Mon Dec 15 06:49:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA02860 for hackers-outgoing; Mon, 15 Dec 1997 06:49:47 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 GAA02854 for ; Mon, 15 Dec 1997 06:49:41 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id HAA00496; Mon, 15 Dec 1997 07:49:35 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id HAA09057; Mon, 15 Dec 1997 07:45:14 -0700 (MST) Date: Mon, 15 Dec 1997 07:45:14 -0700 (MST) From: Marc Slemko To: Brian McGovern cc: hackers@freebsd.org Subject: RE: Re: Weird IP addresses In-Reply-To: <199712151436.JAA08694@bmcgover-pc.cisco.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 Dec 1997, Brian McGovern wrote: > None of the explanations are true. > > The fact of the matter is the Internic has broken down most of their > "Reserved" Class A, and B blocks in order to make as many C blocks as > possible. There was an RFC published a while back (I remember it in the > six month timeframe, but it may be older) that if you compare to earlier > address allocation RFCs, has a far fewer number of "reserved blocks". The blocks in question have not been reallocated. 111.111.111.111 and 222.222.222.222 have PTR records at the root name servers. They have not been allocated and even if they were the InterNIC should not be placing bogus reverse DNS records in place for them. > > The fact that the Internic is trying to make money is true. However, they're > doing it by stretching what little resources they have left, not by allowing > bogus domain entries. I do not think they have started giving out these blocks yet because it simply isn't necessary. There have been some experiments done on them, though. The InterNIC makes no money from IP address allocations; if anything, they lose money. In any case, they will no longer have control of North American allocations after December 22 when ARIN takes over. From owner-freebsd-hackers Mon Dec 15 07:12:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA04257 for hackers-outgoing; Mon, 15 Dec 1997 07:12:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from icsnet.com (icsnet.com [204.194.104.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA04247 for ; Mon, 15 Dec 1997 07:12:50 -0800 (PST) (envelope-from meltzer@icsnet.com) Received: from www (www [204.194.104.2]) by icsnet.com (8.8.5/8.8.5) with SMTP id KAA08730; Mon, 15 Dec 1997 10:08:20 -0500 (EST) Date: Mon, 15 Dec 1997 10:08:20 -0500 (EST) From: Jeffrey Meltzer X-Sender: meltzer@www To: freebsd-hackers@freebsd.org cc: izaac@newtonian.ml.org Subject: FreeBSD on an HP Vectra VE Message-ID: Organization: Intelligent Computer Solutions X-Mailer: PINE 3.96 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 setting up FreeBSD for the first time, and have hit a small snag in setting up X. When I run the SuperProbe utility, it says there is a SiS 6C205 card, which I have (comes annoyingly with the motherboard on a HP Vectra VE). But, when i run the configure utility, that's not an option, only another SiS card is there. Anyone have any idea as to whether that one is compatable or not? Also, I just picked the unsupported card option, and when i tried to start X, it told me it couldn't find the mouse, which in setup I put in as /dev/mouse, which is linked to /dev/psm1. If anyone has any ideas, it would be much appreciated... Jeffrey Meltzer ,,, meltzer@icsnet.com (0 0) -------------------------oOO--(_)--OOo------- Intelligent Computer Solutions 516-218-0700 VillageNet Technical Support 516-218-9090 http://www.icsnet.com/~meltzer From owner-freebsd-hackers Mon Dec 15 07:19:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA04830 for hackers-outgoing; Mon, 15 Dec 1997 07:19:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from www.stv.ee (www.stv.ee [195.50.193.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA04807 for ; Mon, 15 Dec 1997 07:19:00 -0800 (PST) (envelope-from dima@stv.ee) Received: from stv.ee (dima2 [192.168.193.38]) by www.stv.ee (8.8.5/8.8.5) with ESMTP id RAA01696 for ; Mon, 15 Dec 1997 17:18:16 +0200 (EET) Message-ID: <3495499E.621A5474@stv.ee> Date: Mon, 15 Dec 1997 17:15:42 +0200 From: Dmitry Baranov X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Internal network->Internet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello. I have an internal subnet like 192.168.X.X and only a handful of real ip adresses. I whant to allow machines from internal networks get services from Internet. I install squid proxy for ftp and http service. Nntpcache for news. But can somebody helps me how can I allow icq traffgic ? I tried SOCKS 5 with no effect. Dmitry Baranov From owner-freebsd-hackers Mon Dec 15 07:35:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA06592 for hackers-outgoing; Mon, 15 Dec 1997 07:35:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA06077 for ; Mon, 15 Dec 1997 07:30:23 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712151530.HAA06077@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA290939783; Tue, 16 Dec 1997 02:29:44 +1100 From: Darren Reed Subject: Re: Re: Weird IP addresses To: marcs@znep.com (Marc Slemko) Date: Tue, 16 Dec 1997 02:29:43 +1100 (EDT) Cc: bmcgover@cisco.com, hackers@FreeBSD.ORG In-Reply-To: from "Marc Slemko" at Dec 15, 97 07:45:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Marc Slemko, sie said: > > I do not think they have started giving out these blocks yet because it > simply isn't necessary. There have been some experiments done on them, > though. The InterNIC makes no money from IP address allocations; if > anything, they lose money. In any case, they will no longer have control > of North American allocations after December 22 when ARIN takes over. Net 24 is being used by Telcos around the world for setting up cable internet access. That was one of those reserved class-A blocks. Try traceroute'ing to 24.0.0.2, for example. However, this isn't 1.1.1.1 or 111.111.111.111. Darren From owner-freebsd-hackers Mon Dec 15 08:05:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA08745 for hackers-outgoing; Mon, 15 Dec 1997 08:05:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from toth.ferginc.com (toth.ferginc.com [205.139.23.69]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA08728 for ; Mon, 15 Dec 1997 08:05:42 -0800 (PST) (envelope-from branson@toth.ferginc.com) Received: (from branson@localhost) by toth.ferginc.com (You_Can/Keep_Guessing) id LAA03096; Mon, 15 Dec 1997 11:02:29 -0500 (EST) Message-ID: <19971215110229.18906@toth.FergInc.com> Date: Mon, 15 Dec 1997 11:02:29 -0500 From: Branson Matheson To: Jeffrey Meltzer Cc: freebsd-hackers@freebsd.org, izaac@newtonian.ml.org Subject: Re: FreeBSD on an HP Vectra VE Reply-To: Branson.Matheson@FergInc.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Jeffrey Meltzer on Mon, Dec 15, 1997 at 10:08:20AM -0500 Organization: Ferguson Enterprises, Inc. X-Operating-System: FreeBSD 2.2.2-RELEASE Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Dec 15, 1997 at 10:08:20AM -0500, Jeffrey Meltzer wrote: > I'm setting up FreeBSD for the first time, and have hit a small snag in > setting up X. When I run the SuperProbe utility, it says there is a SiS > 6C205 card, which I have (comes annoyingly with the motherboard on a HP > Vectra VE). But, when i run the configure utility, that's not an option, > only another SiS card is there. Anyone have any idea as to whether that > one is compatable or not? I used the standard svga driver with my VE. The one that I had used a Cirrus Logic card. I don't think I had that card however. We have mutiple XM's and XU's here running fbsd with out a hitch.. and I have used it on other vectras here by netbooting. > Also, I just picked the unsupported card option, and when i tried to start > X, it told me it couldn't find the mouse, which in setup I put in as > /dev/mouse, which is linked to /dev/psm1. Hmmm.. unless you have *two* psm devices ... try /dev/psm0 ;-) - branson ------------------------------------------------------------------------------- Branson Matheson " If you are falling off of a mountain, Unix System Administrator You may as well try to fly." Ferguson Enterprises, Inc. - Delenn, Mimbari Ambassador ( $statements = ) !~ /Corporate Opinion/; From owner-freebsd-hackers Mon Dec 15 10:20:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA21404 for hackers-outgoing; Mon, 15 Dec 1997 10:20:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA20761 for ; Mon, 15 Dec 1997 10:15:21 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA27631; Mon, 15 Dec 1997 11:14:53 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd027555; Mon Dec 15 11:14:28 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA18539; Mon, 15 Dec 1997 11:14:23 -0700 (MST) From: Terry Lambert Message-Id: <199712151814.LAA18539@usr05.primenet.com> Subject: Re: Why so many steps to build new kernel? To: daniel_sobral@voga.com.br Date: Mon, 15 Dec 1997 18:14:23 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <8325656E.003FF988.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 15, 97 08:45:43 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The idea that there needs to be a mechanism for handling mutual > > exclusions presupposes (incorrectly, IMO), that some drivers are > > mutually exclusive. > > Well, as far as I know, syscon and the vt stuff are mutually exclusive. > And, generally, speaking, two drivers to the same piece of hardware will be > mutually exclusive. That's not that unlikely to ignore the possibility. The first one to grab the hardware gets it. If you want to prefer one driver over the other, you link it first so it gets first shot at the SYSINIT. If you want to configure one to be first at run time instead of at link time: use an ELF archiver. > > Similarly, prerequisite identification is well and good, but can be > > done symbolically, without reference to a kernel configurator. > > Similarly, the kernel configurator should not display syscon's history > buffer size option if you did not select syscon. A data section groveller would allow you to set this type of thing; we currently have three of them, counting sysinit/rc.conf. > > So what's left for a kernel configurator to do? > > > ...Nothing. > > In a perfect world, with elf kernel, PnP PCI devices, devfs, and well > behaviored hardware, sure, nothing's left to do. > > (except that, there probably would be even then) So why work on (or argue heatedly about) code that's going to go away? There's no need for a build-time configurator, in any case. 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 Dec 15 10:34:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23094 for hackers-outgoing; Mon, 15 Dec 1997 10:34:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA23087 for ; Mon, 15 Dec 1997 10:34:28 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA10900; Mon, 15 Dec 1997 11:33:55 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd010874; Mon Dec 15 11:33:49 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA19433; Mon, 15 Dec 1997 11:33:46 -0700 (MST) From: Terry Lambert Message-Id: <199712151833.LAA19433@usr05.primenet.com> Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port To: avalon@coombs.anu.edu.au (Darren Reed) Date: Mon, 15 Dec 1997 18:33:46 +0000 (GMT) Cc: gurney_j@resnet.uoregon.edu, avalon@coombs.anu.edu.au, hackers@FreeBSD.ORG In-Reply-To: <199712150750.XAA01781@hub.freebsd.org> from "Darren Reed" at Dec 15, 97 06:50:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Well, the Solaris2 kernel is 600k (/platform/sun4m/kernel/unix) for 2.5.1, > but /platform/sun4m is 4.5M in size with another 1.5M in /usr/kernel. > Personally, I find as the number of files required to boot into single > user increases, the greater the chance of shit happening on a bad crash > and the system becoming unable to boot itself. Personally, I think that > the boot device and root fs should always be "in" the kernel so that if > someone has nuked all your modules, you can still get up into single user > mode. Mount the root read-only, and you will have the same guarantees. Implement soft updates, and you will have the same guarantees. The statement "shit happens" only applies when you let your guard down; you have to make a conscious decision to do this. Let's note, also, that Solaris can be recovered, easily, from CDROM in case of this type of Spamming of the kernel... > I think that whilst the above goal is interesting (and perhaps worthwhile), > there are already problems which need to be solved for LKM's which aren't, > as yet, such as merging LKM symbols so that gdb on the kernel is sane and > fixing up crash dumps.. Both of these are relatively easy to accomplish using John Polstra's ELF implementation. 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 Dec 15 10:41:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA24107 for hackers-outgoing; Mon, 15 Dec 1997 10:41:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA24082; Mon, 15 Dec 1997 10:41:34 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA03479; Mon, 15 Dec 1997 11:40:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd003388; Mon Dec 15 11:40:34 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA19909; Mon, 15 Dec 1997 11:40:22 -0700 (MST) From: Terry Lambert Message-Id: <199712151840.LAA19909@usr05.primenet.com> Subject: Re: blocksize on devfs entries (and related) To: dyson@FreeBSD.ORG Date: Mon, 15 Dec 1997 18:40:22 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, bgingery@gtcs.com, hackers@FreeBSD.ORG In-Reply-To: <199712150922.EAA04315@dyson.iquest.net> from "John S. Dyson" at Dec 15, 97 04:22:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This is one of the reasons the Linux FATFS implementation kicks the > > FreeBSD's implementation's butt on performance metrics. > > I could be wrong, but I suspect the reason that our FATFS is slow now > is that don't use our cluster code. It isn't that slow anymore, after > all of the unneeded sync writes were fixed. It's still slower than it has to be; this is kind of a tangent at this point, however. A more interesting tangent in the same vein is how you would support multiple name spaces in VFAT through the existing namei() (you wouldn't, basically). 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 Dec 15 10:42:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA24244 for hackers-outgoing; Mon, 15 Dec 1997 10:42:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA24206 for ; Mon, 15 Dec 1997 10:42:35 -0800 (PST) (envelope-from daniel_sobral@voga.com.br) From: daniel_sobral@voga.com.br Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 0325656E.0066C386 ; Mon, 15 Dec 1997 15:42:27 -0300 X-Lotus-FromDomain: VOGA To: tlambert@primenet.com cc: hackers@FreeBSD.ORG Message-ID: <8325656E.00652DC2.00@papagaio.voga.com.br> Date: Mon, 15 Dec 1997 15:42:21 -0300 Subject: Re: Why so many steps to build new kernel? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The first one to grab the hardware gets it. If you > want to prefer one driver over the other, you link > it first so it gets first shot at the SYSINIT. If > you want to configure one to be first at run time > instead of at link time: use an ELF archiver. And that's supposed to be user friendly at the same time, right? I'm talking about what the kernel configuration file must have so that a user friendly configuration tool can be created. And, as far as I am concerned, ordering is not user friendly. > > Similarly, the kernel configurator should not display syscon's history > > buffer size option if you did not select syscon. > A data section groveller would allow you to set this type of thing; > we currently have three of them, counting sysinit/rc.conf. That would kind of work. Except... that structure does not have the semantic content for which it is being used, meaning that: 1) If the need later arises for the correct structure, we'll be left with the choice of modifying *all* previous structures to the correct one (and we all know how hard such things are), or using two different structures for the same end. 2) It may lead to pilot error. 3) It's a hack and should be banned to hell. Terry, are you suggesting a backward compatibility hack (with tradition, not even code!) instead of doing the right thing??? > > In a perfect world, with elf kernel, PnP PCI devices, devfs, and well > > behaviored hardware, sure, nothing's left to do. > > > (except that, there probably would be even then) > So why work on (or argue heatedly about) code that's going to go away? That should be obvious! We don't leave in a perfect world. (Proof: FreeBSD runs on Intel with IDE hacks^^Wdrives) > There's no need for a build-time configurator, in any case. You mean there won't be no need for a build-time configurator if and when we get to the perfect world, right? Because, right now, I can't seem to get along without config... From owner-freebsd-hackers Mon Dec 15 11:54:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA04294 for hackers-outgoing; Mon, 15 Dec 1997 11:54:31 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 LAA04275 for ; Mon, 15 Dec 1997 11:54:24 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA15748; Mon, 15 Dec 1997 11:30:33 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd015743; Mon Dec 15 11:30:28 1997 Message-ID: <349584B3.FF6D5DF@whistle.com> Date: Mon, 15 Dec 1997 11:27:47 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Jonathan Mini CC: hm@kts.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org Subject: Re: 132 Column mode on VGA Consoles References: <19971215011306.46218@micron.mini.net> <19971215052432.11830@micron.mini.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jonathan Mini wrote: > > Hellmuth Michaelis stands accused of saying: > > Jonathan Mini wrote: > > > > > > As soon as the vesa code goes in, there will be _three_ possible sources of > > > contention over the system console's device(s), the Xfree86 system, the VESA > > > library, and syscons itself. > > > > Hopefully this implementation will allow other "drivers" than syscons. If it > > would, it would we one step towards the unified console driver we are talking > > about since 386bsd 0.1. > I still have the design and discussion archives from back then do you want them? We actually ended up with a design, but no implementation. > Of course. Why else would I want to layer the code? > > Personally, I am annoyed with syscons as it is now, and would (at least) like > to see two other 'drivers' : one that is _much_ smaller (a TTY-only > implementation, for example) and one that is vt100 instead of SCO compatable. > I'm sure there are other things that people will want to see. > > But, for now, I just want to get rid of the contention over the display > hardware, and since my only option to fix that is to layer the console code, I > might as well Get It Right. The layering is simple : > > 1) The lowest layer is, of course, the devices. VESA VBE, the BIOS > int 10 services, and a hardware-specific driver are three that come > to mind. Also, input devices such as the keyboard and mouse. > > 2) A layer which implements the user-interface which binds the other > two layers together. This layer could be anything from a NOOP to a > virtual terminal system like syscons is now, to a full-flegded > windowing system. I don't care. :) > > 3) A layer which uses a tty to interface with the rest of the world. > this layer implements junk like VT100 support, SCO or whatever. > > Two things should be noted : > 1) The kernel's private interface to the console needs to be changed, > as well as /dev/cons's mutilation of the tty methidology. The kernel > console code also needs to be moved out of the i386 tree. This is no > hardware dependant, layer 1 of the console system is. (The console > code as it is now isn't really hardware dependant either) > > 2) I will personally write the code to provide ALL of the functionality > of syscons, so don't even go down the road of "but you need to provide > blah blah blah blah blah." > > I could go into long discussions about how wonderful this would be in the > future, but I'm sure you've all already heard the advantages of a layered > console. For now, it will just remove the device contention of the the current > console system via the second layer. (It will have support for handling > multiple consumers, and switching between them) > In the very short term, little will be gained from this, except that the code > will probably get slightly larger, but then again perhaps not. A few minor > features will be gained, such as being able to use VESA video modes. > > However, in the long run, the code could feasably be MUCH smaller (a BIOS int > 10 layer with a NOOP layer with a TTY emulation layer would be MUCH smaller) > and feasably be able to do more system here>. > > -- > Jonathan Mini Ingenious Productions > Software Development P.O. Box 5693, > Eugene, Or. 97405 > > "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Mon Dec 15 12:18:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA08606 for hackers-outgoing; Mon, 15 Dec 1997 12:18:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA08588 for ; Mon, 15 Dec 1997 12:17:58 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id NAA09804; Mon, 15 Dec 1997 13:22:15 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd009782; Mon Dec 15 13:22:06 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id NAA15154; Mon, 15 Dec 1997 13:17:43 -0700 (MST) From: Terry Lambert Message-Id: <199712152017.NAA15154@usr07.primenet.com> Subject: Re: Why so many steps to build new kernel? To: daniel_sobral@voga.com.br Date: Mon, 15 Dec 1997 20:17:43 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <8325656E.00652DC2.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 15, 97 03:42:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > And that's supposed to be user friendly at the same time, right? > > I'm talking about what the kernel configuration file must have so that a > user friendly configuration tool can be created. And, as far as I am > concerned, ordering is not user friendly. The existance of mutually exclusive drivers is not friendly. There are two types of exclusion: 1) Screw up: the driver probes are antagonistic to other hardware. This should be fixed by changing the probe code. 2) Screw up: there is more than one driver for the given hardware. This should be fixed by integration. Your console example falls into #2, and Johnathan Mini is working on fixing it. Do you have other examples? > > A data section groveller would allow you to set this type of thing; > > we currently have three of them, counting sysinit/rc.conf. > > That would kind of work. Except... that structure does not have the > semantic content for which it is being used, meaning that: > > 1) If the need later arises for the correct structure, we'll be left with > the choice of modifying *all* previous structures to the correct one (and > we all know how hard such things are), or using two different structures > for the same end. This is why there needs to be an extensible schema mechanism (like that of LDAP) instead of a binary structure based mechanism for doing this sort of thing. This is why God invented Directories. > 2) It may lead to pilot error. Detachable power cords lead to pilot error. Eventually, you have to cut your losses below a certain level of complexity. Your problem with this seems to be that BSD isn't below that line. I think a kernel configurator will just prop up the existing bad situation, and delay more correct change. > 3) It's a hack and should be banned to hell. > > Terry, are you suggesting a backward compatibility hack (with tradition, > not even code!) instead of doing the right thing??? "Backward compatability hack"? ELF archiver? What ELF system are *you* running on?!? > > There's no need for a build-time configurator, in any case. > > You mean there won't be no need for a build-time configurator if and when > we get to the perfect world, right? Because, right now, I can't seem to get > along without config... And the more you enhance it, the less likely that people will do anything about moving the code forward in this area. "Good Enough" is the enemy of "Better". 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 Dec 15 12:21:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09054 for hackers-outgoing; Mon, 15 Dec 1997 12:21:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA08062 for ; Mon, 15 Dec 1997 12:15:48 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id MAA27525; Mon, 15 Dec 1997 12:15:26 -0800 (PST) Message-ID: <19971215121524.20928@micron.mini.net> Date: Mon, 15 Dec 1997 12:15:24 -0800 From: Jonathan Mini To: Julian Elischer Cc: Jonathan Mini , hm@kts.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org Subject: Re: 132 Column mode on VGA Consoles Reply-To: Jonathan Mini References: <19971215011306.46218@micron.mini.net> <19971215052432.11830@micron.mini.net> <349584B3.FF6D5DF@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <349584B3.FF6D5DF@whistle.com>; from Julian Elischer on Mon, Dec 15, 1997 at 11:27:47AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Elischer stands accused of saying: > I still have the design and discussion archives from back then > do you want them? > We actually ended up with a design, but no implementation. They might be helpful. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Mon Dec 15 12:28:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA10050 for hackers-outgoing; Mon, 15 Dec 1997 12:28:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from TomQNX.tomqnx.com (ott-pm6-19.comnet.ca [206.75.140.179]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA10033 for ; Mon, 15 Dec 1997 12:28:38 -0800 (PST) (envelope-from freebsd@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0xhh48-000A0nC; Mon, 15 Dec 1997 15:24:36 -0500 (EST) Message-Id: From: freebsd@tomqnx.com (Tom Torrance) Subject: Re: Re: Weird IP addresses In-Reply-To: from Marc Slemko at "Dec 15, 97 07:45:14 am" To: marcs@znep.com (Marc Slemko) Date: Mon, 15 Dec 1997 15:24:36 -0500 (EST) Cc: bmcgover@cisco.com, hackers@FreeBSD.ORG, JKRey@isi.edu 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 > On Mon, 15 Dec 1997, Brian McGovern wrote: > > > None of the explanations are true. > > > > The fact of the matter is the Internic has broken down most of their > > "Reserved" Class A, and B blocks in order to make as many C blocks as > > possible. There was an RFC published a while back (I remember it in the > > six month timeframe, but it may be older) that if you compare to earlier > > address allocation RFCs, has a far fewer number of "reserved blocks". > > The blocks in question have not been reallocated. > > 111.111.111.111 and 222.222.222.222 have PTR records at the root name > servers. They have not been allocated and even if they were the InterNIC > should not be placing bogus reverse DNS records in place for them. It appears to me that they have NOT. The SPAM accounts seem to be set up by a company called Internic Software in Australia. The InterNIC allowed them to register a domain MINDGFX.COM with the nameservers 111.111.111.111 and 222.222.222.222. The InterNIC has NS records for the above numbers. The invalid nameservers have the reverse DNS entries. 111.0.0.0 is allocated and administered by JKRey@isi.edu who is copied for info on this message along with hostmaster@internic.net who will hopefully follow up on the situation. > > > > > The fact that the Internic is trying to make money is true. However, they're > > doing it by stretching what little resources they have left, not by allowing > > bogus domain entries. > > I do not think they have started giving out these blocks yet because it > simply isn't necessary. There have been some experiments done on them, > though. The InterNIC makes no money from IP address allocations; if > anything, they lose money. In any case, they will no longer have control > of North American allocations after December 22 when ARIN takes over. > > From owner-freebsd-hackers Mon Dec 15 12:36:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA10932 for hackers-outgoing; Mon, 15 Dec 1997 12:36:53 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 MAA10919 for ; Mon, 15 Dec 1997 12:36:38 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xhhFf-0007es-00; Mon, 15 Dec 1997 13:36:31 -0700 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id NAA23973; Mon, 15 Dec 1997 13:36:24 -0700 (MST) Message-Id: <199712152036.NAA23973@harmony.village.org> To: Darren Reed Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port Cc: gurney_j@resnet.uoregon.edu, hackers@freebsd.org In-reply-to: Your message of "Mon, 15 Dec 1997 18:50:36 +1100." <199712150750.XAA01781@hub.freebsd.org> References: <199712150750.XAA01781@hub.freebsd.org> Date: Mon, 15 Dec 1997 13:36:24 -0700 From: Warner Losh Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199712150750.XAA01781@hub.freebsd.org> Darren Reed writes: : someone has nuked all your modules, you can still get up into single user : mode. That is a major problem on Solaris machines I do development on here. If you have bugs in the device driver you are working on, it is often the case that files critical to the booting of the system aren't there and it is time to grab the cdrom and boot off of it to repair the damage (or in extreme cases to reinstall the OS). That said, it sure is nice being able to load/unload drivers all the time w/o muich hassle. Warner From owner-freebsd-hackers Mon Dec 15 12:57:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA13074 for hackers-outgoing; Mon, 15 Dec 1997 12:57:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from TomQNX.tomqnx.com (ott-pm6-02.comnet.ca [206.75.140.162]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA13048 for ; Mon, 15 Dec 1997 12:56:51 -0800 (PST) (envelope-from freebsd@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0xhhWC-000A0nC; Mon, 15 Dec 1997 15:53:36 -0500 (EST) Message-Id: From: freebsd@tomqnx.com (Tom Torrance) Subject: Re: Re: Weird IP addresses In-Reply-To: from Marc Slemko at "Dec 15, 97 07:45:14 am" To: marcs@znep.com (Marc Slemko) Date: Mon, 15 Dec 1997 15:53:36 -0500 (EST) Cc: bmcgover@cisco.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 1.0.0.0 is also allocated and administered by Joyce Reynolds who has been informed of the apparent illegal usage of 1.1.1.1 and 1.1.1.2 by LOTTOSPORTS.COM for SPAM purposes (along with hostmaster@internic.net). Regards, Tom From owner-freebsd-hackers Mon Dec 15 14:48:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23451 for hackers-outgoing; Mon, 15 Dec 1997 14:48:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23439 for ; Mon, 15 Dec 1997 14:48:42 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.8/8.8.5) with SMTP id RAA01218; Mon, 15 Dec 1997 17:45:19 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Mon, 15 Dec 1997 17:45:19 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: Dmitry Baranov cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Internal network->Internet In-Reply-To: <3495499E.621A5474@stv.ee> 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 should look into the program 'NATd' it's in the ports collection, i have a semi-helpful webpage up that might be of help to you: www.cs.sunyit.edu/~perlsta click on the unix link. then look at the info you will have to understand the what protocols are being used by the product... NATd rules because it's very transparent, FTP, IRC and a LOT of otherstuff work with it, however weird stuff using UPD transport will probably break, and if you NEED it to work you will only have one machine capable of resonding.... on another note, NATd allows 'tunneling' of requests to be passed to other machines, ie. you telnet to machine A and it completes a circut to machine B.... it's all very neeto. .________________________________________________________________________ __ _ |Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?" |perlsta@sunyit.edu --"who was that masked admin?" |http://www.cs.sunyit.edu/~perlsta : ' On Mon, 15 Dec 1997, Dmitry Baranov wrote: > Hello. > I have an internal subnet like 192.168.X.X and only a handful of real > ip adresses. > I whant to allow machines from internal networks get services from > Internet. > I install squid proxy for ftp and http service. Nntpcache for news. > But can somebody helps me how can I allow icq traffgic ? > I tried SOCKS 5 with no effect. > > Dmitry Baranov > > From owner-freebsd-hackers Mon Dec 15 15:00:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA24511 for hackers-outgoing; Mon, 15 Dec 1997 15:00:42 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 OAA24425 for ; Mon, 15 Dec 1997 14:59:47 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id JAA05442; Tue, 16 Dec 1997 09:29:05 +1030 (CST) (envelope-from grog) Message-ID: <19971216092905.55311@lemis.com> Date: Tue, 16 Dec 1997 09:29:05 +1030 From: Greg Lehey To: Rob Nelson Cc: FreeBSD Hackers Subject: Re: 3com 3c509 card References: <34955B38.167E@panews.press.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Rob Nelson on Mon, Dec 15, 1997 at 09:15:09AM -0800 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Dec 15, 1997 at 09:15:09AM -0800, Rob Nelson wrote: > On Mon, 15 Dec 1997, Eric Fosdike wrote: > >> This card is flagged as 'buggy' by the kernel install options. What is >> causing it to be buggy? We are looking to roll out a large number of BSD >> boxes with 3com 509 cards in. Where exactly is the problem with these >> cards? > > We have used both the 3Com 509 combo as well as the TP cards on several > FreeBSD boxes with no problems. Same here. I've been using one for years. > They work very well. I think the "buggy" designation is a leftover > from earlier revisions of the driver. A while back I'd get hangs from time to time (I needed to down and up the interface to unwedge it), but I haven't had that for a long time. I'd agree with your assessment. I'm copying -hackers for comment. Greg From owner-freebsd-hackers Mon Dec 15 17:36:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA07812 for hackers-outgoing; Mon, 15 Dec 1997 17:36:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from skraldespand.demos.su (skraldespand.demos.su [194.87.5.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA07798 for ; Mon, 15 Dec 1997 17:36:40 -0800 (PST) (envelope-from mishania@skraldespand.demos.su) Received: (from mishania@localhost) by skraldespand.demos.su (8.8.8/D) id EAA19586; Tue, 16 Dec 1997 04:36:10 +0300 (MSK) Posted-Date: Tue, 16 Dec 1997 04:36:10 +0300 (MSK) Message-ID: <19971216043610.01160@demos.su> Date: Tue, 16 Dec 1997 04:36:10 +0300 From: "Mikhail A. Sokolov" To: Branson.Matheson@FergInc.com Cc: Jeffrey Meltzer , freebsd-hackers@FreeBSD.ORG, izaac@newtonian.ml.org Subject: Re: FreeBSD on an HP Vectra VE References: <19971215110229.18906@toth.FergInc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <19971215110229.18906@toth.FergInc.com>; from Branson Matheson on Mon, Dec 15, 1997 at 11:02:29AM -0500 Organization: Demos Company, Ltd., Moscow, Russian Federation. X-Point-of-View: Gravity is myth, - the earth sucks. Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Dec 15, 1997 at 11:02:29AM -0500, Branson Matheson wrote: # On Mon, Dec 15, 1997 at 10:08:20AM -0500, Jeffrey Meltzer wrote: # > I'm setting up FreeBSD for the first time, and have hit a small snag in # > setting up X. When I run the SuperProbe utility, it says there is a SiS # > 6C205 card, which I have (comes annoyingly with the motherboard on a HP # > Vectra VE). But, when i run the configure utility, that's not an option, # > only another SiS card is there. Anyone have any idea as to whether that # > one is compatable or not? # I used the standard svga driver with my VE. The one that I had used # a Cirrus Logic card. I don't think I had that card however. We have # mutiple XM's and XU's here running fbsd with out a hitch.. and I # have used it on other vectras here by netbooting. However, it won't provide 2mb card capacities, that workaround with that driver. Neither XFree, nor Xaccel drivers won't do that, - the best solution is to get some $2x svga, a la S3 or something. # # > Also, I just picked the unsupported card option, and when i tried to start # > X, it told me it couldn't find the mouse, which in setup I put in as # > /dev/mouse, which is linked to /dev/psm1. # Hmmm.. unless you have *two* psm devices ... try /dev/psm0 ;-) Easy, psm0 isn't active even if it's configured. boot -cv, activate it. This behaviour is intended one, since some of motherboards will freese if psm is activated ;-(. Guys, can't it be that psm0 is activated by default, if configured? I hardly saw 1% if all motherboards which will need this, - shouldn't it be that if config sees the board, where it is known to be a problem, it will not enable psm at startup? It's not that hard, but quite annoying to enable the mouse each time you get new kernel. # # - branson -- -mishania From owner-freebsd-hackers Mon Dec 15 17:53:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA09198 for hackers-outgoing; Mon, 15 Dec 1997 17:53:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09183 for ; Mon, 15 Dec 1997 17:53:14 -0800 (PST) (envelope-from gozer@ludd.luth.se) Received: from father.ludd.luth.se (gozer@father.ludd.luth.se [130.240.16.18]) by zed.ludd.luth.se (8.8.5/8.8.5) with SMTP id CAA26432; Tue, 16 Dec 1997 02:52:27 +0100 Date: Tue, 16 Dec 1997 02:52:27 +0100 (MET) From: Johan Larsson To: Greg Lehey cc: Rob Nelson , FreeBSD Hackers Subject: Re: 3com 3c509 card In-Reply-To: <19971216092905.55311@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 Tue, 16 Dec 1997, Greg Lehey wrote: > On Mon, Dec 15, 1997 at 09:15:09AM -0800, Rob Nelson wrote: > > On Mon, 15 Dec 1997, Eric Fosdike wrote: > > > >> This card is flagged as 'buggy' by the kernel install options. What is > >> causing it to be buggy? We are looking to roll out a large number of BSD > >> boxes with 3com 509 cards in. Where exactly is the problem with these > >> cards? > > > > We have used both the 3Com 509 combo as well as the TP cards on several > > FreeBSD boxes with no problems. > > Same here. I've been using one for years. > > > They work very well. I think the "buggy" designation is a leftover > > from earlier revisions of the driver. > > A while back I'd get hangs from time to time (I needed to down and up > the interface to unwedge it), but I haven't had that for a long time. > I'd agree with your assessment. I'm copying -hackers for comment. I have had this problem alot lately, and also a problem with the input network load to be around 30-90kByte/sec constantly! :( But this night i tracked the problem down to be in the later versions of if_ep.c and if_epreg.h . I am now running my current with the 1.62 of if_ep.c and the 1.21 of if_epreg.h . This works! I haven't had time to track down _what_ exactly that's been done lately with this driver. Perhaps the people responsible of it could tell us more. So my suggestion is that you _don't_ ship your computers with 3com cards, at least not the 509. Johan -- * mailto:gozer@ludd.luth.se * http://www.ludd.luth.se/users/gozer/ * * Powered by FreeBSD. http://www.se.freebsd.org/ +-+-+-+-+-+-+-+-+ * From owner-freebsd-hackers Mon Dec 15 18:09:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA10296 for hackers-outgoing; Mon, 15 Dec 1997 18:09:03 -0800 (PST) (envelope-from owner-freebsd-hackers) 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 SAA10284 for ; Mon, 15 Dec 1997 18:08:52 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id SAA03623; Mon, 15 Dec 1997 18:08:22 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712160208.SAA03623@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: freebsd@tomqnx.com (Tom Torrance) cc: marcs@znep.com (Marc Slemko), bmcgover@cisco.com, hackers@FreeBSD.ORG Subject: Re: Weird IP addresses In-reply-to: Your message of "Mon, 15 Dec 1997 15:53:36 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 18:08:21 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Last week I mailed to abuse@netcom.com and at least this guy is not going to be bothering us anymore from netcom.com. I think we need a global Spammer Net Rating because I am sure the spammer is just going to move to a different ISP . Amancio abuse@netcom.com said: > Hello. > We have terminated the account of our user for breaking our policies. > In the future we will not allow this person to purchase another > account through us, at NETCOM. If you receive any further contact > from this user through NETCOM, please contact us immediatly. For more > information on these Acceptable Useage and Guidelines, please review > them at this website. > http://www.netcom.com/netcom/aug.html > We apoligize for any inconveniance our user may have caused. > Keman NETCOM Policy Management ---------------------------------------- > ------------------------------ NETCOM On-Line Communication Services, > Inc. abuse@netcom.com NETCOM Policy Management: (408) > 881-3499 M-F 9AM-5PM PST 24-Hour Technical Support: (408) > 881-1810 support@netcom.com ----------------------------------- > ----------------------------------- > You wrote: > From hasty@netcom.com Sun Dec 14 04:15:14 1997 > Received: from netcom14.netcom.com (hasty@netcom14.netcom.com > [192.100.81.126]) by office4.corp.netcom.com (8.6.12/Netcom-Corp) with > ESMTP id EAA14631 for ; Sun, 14 Dec 1997 > 04:15:13 -0800 > Received: (from hasty@localhost) > by netcom14.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id > EAA16254 > for abuse@netcom.com; Sun, 14 Dec 1997 04:15:13 -0800 (PST) > Date: Sun, 14 Dec 1997 04:15:13 -0800 (PST) > From: Amancio Hasty Jr > Message-Id: <199712141215.EAA16254@netcom14.netcom.com> > To: abuse@netcom.com > Subject: Howdy you seem to have a very persisten spammmer > Status: RO > > > I have received dozens of e-mail messages from: > > Return-path: 78204332@moneymakers.com > Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com > [206.214.98.2]) > by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id RAA03604 > for ; Fri, 12 Dec 1997 17:30:36 > -0800 (PST) > (envelope-from 78204332@moneymakers.com) > Received: (from smap@localhost) > by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) > id TAA05843; Fri, 12 Dec 1997 19:28:34 -0600 (CST) > Received: from nbw-nj14-15.ix.netcom.com(198.211.225.207) by > dfw-ix2.ix.netcom.com via smap (V1.3) > id rma004573; Fri Dec 12 19:20:53 1997 > Received: from mailhost.moneymakers.com ( SYTM.moneymakers.com > (203.74.9.110)) by moneymakers.com (8.8.5/8.6.5) with SMTP id GAA05881 > for ; Fri, 12 Dec 1997 20:03:10 -0600 > (EST) > Message-id: <199746522791.FBB03720@moneymakers.com> > Reply-to: ShowYouTheMoney@moneymakers.com > X-pmflags: 128 0 > X-uidl: 64827751009732159745119985624733 > Comments: Authenticated sender is > From: 78204332@moneymakers.com > Date: Fri, 12 Dec 97 20:03:10 EST > To: ShowYouTheMoney@moneymakers.com > Subject: Make $2,000 - $5,000 per week -NOT MLM > > 

> ARE YOU READY TO MAKE IT; WILL THE LIGHT GO ON?
> 
> 	Tnks,
> 	Amancio
> 





From owner-freebsd-hackers  Mon Dec 15 18:36:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA12382
          for hackers-outgoing; Mon, 15 Dec 1997 18:36:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 SAA12337
          for ; Mon, 15 Dec 1997 18:35:48 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA00551;
	Tue, 16 Dec 1997 12:57:22 +1030 (CST)
Message-Id: <199712160227.MAA00551@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Johan Larsson 
cc: Greg Lehey , Rob Nelson ,
        FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Tue, 16 Dec 1997 02:52:27 BST."
              
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Dec 1997 12:57:22 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> So my suggestion is that you _don't_ ship your computers with 3com cards,
> at least not the 509.

I'd have to ask why anyone would use a 3c509 when an NE2000 clone is 
cheaper, faster and better supported.

Alternatively, I'd have to wonder why anyone would contemplate shipping 
a hardware combination that they haven't tested extensively in-house 
first.

mike



From owner-freebsd-hackers  Mon Dec 15 18:38:39 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA12711
          for hackers-outgoing; Mon, 15 Dec 1997 18:38:39 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 SAA12548
          for ; Mon, 15 Dec 1997 18:37:17 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id NAA02232;
          Tue, 16 Dec 1997 13:06:55 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971216130653.14137@lemis.com>
Date: Tue, 16 Dec 1997 13:06:53 +1030
From: Greg Lehey 
To: Mike Smith 
Cc: Johan Larsson , Rob Nelson ,
        FreeBSD Hackers 
Subject: Re: 3com 3c509 card
References:  <199712160227.MAA00551@word.smith.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <199712160227.MAA00551@word.smith.net.au>; from Mike Smith on Tue, Dec 16, 1997 at 12:57:22PM +1030
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, Dec 16, 1997 at 12:57:22PM +1030, Mike Smith wrote:
>>
>> So my suggestion is that you _don't_ ship your computers with 3com cards,
>> at least not the 509.
>
> I'd have to ask why anyone would use a 3c509 when an NE2000 clone is
> cheaper, faster and better supported.

I'd have to, too.  But in my experience, the 3c509 is a whole lot
faster than the NE2000 clones I've used.  Of course, nowadays with
fast processors, you don't see much difference, but it's a different
story with 486/33's

Greg

From owner-freebsd-hackers  Mon Dec 15 18:50:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA13784
          for hackers-outgoing; Mon, 15 Dec 1997 18:50:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 SAA13743
          for ; Mon, 15 Dec 1997 18:49:56 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id NAA00629;
	Tue, 16 Dec 1997 13:14:12 +1030 (CST)
Message-Id: <199712160244.NAA00629@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Greg Lehey 
cc: Mike Smith , Johan Larsson ,
        Rob Nelson , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Tue, 16 Dec 1997 13:06:53 +1030."
             <19971216130653.14137@lemis.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Dec 1997 13:14:11 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> On Tue, Dec 16, 1997 at 12:57:22PM +1030, Mike Smith wrote:
> >>
> >> So my suggestion is that you _don't_ ship your computers with 3com cards,
> >> at least not the 509.
> >
> > I'd have to ask why anyone would use a 3c509 when an NE2000 clone is
> > cheaper, faster and better supported.
> 
> I'd have to, too.  But in my experience, the 3c509 is a whole lot
> faster than the NE2000 clones I've used.  Of course, nowadays with
> fast processors, you don't see much difference, but it's a different
> story with 486/33's

Nope.  They're both PIO cards, and the 'ed' driver spits all over the 
'ep' driver.  Any inversions you may have seen would have been 
environmental relating to the different behaviour of the various chips 
relating to bus traffic.

Yes, I've used both.  Yes, I've seen > 1000K/sec out of an 'ed' card on 
a 486/50.   With modern processors, yes, the differences are less 
evident, but I'll still take an NE2000 over a 509 anyday.  Especially 
when a single-chip card based on something like the RTL2019 costs less 
than AUD$40, and "just works".

mike



From owner-freebsd-hackers  Mon Dec 15 19:16:28 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA15871
          for hackers-outgoing; Mon, 15 Dec 1997 19:16:28 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA15866
          for ; Mon, 15 Dec 1997 19:16:22 -0800 (PST)
          (envelope-from dec@phoenix.its.rpi.edu)
Received: from localhost (dec@localhost)
	by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id WAA13380;
	Mon, 15 Dec 1997 22:15:40 -0500 (EST)
	(envelope-from dec@phoenix.its.rpi.edu)
Date: Mon, 15 Dec 1997 22:15:39 -0500 (EST)
From: "David E. Cross" 
To: Mike Smith 
cc: Johan Larsson , Greg Lehey ,
        Rob Nelson , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-Reply-To: <199712160227.MAA00551@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

On Tue, 16 Dec 1997, Mike Smith wrote:

> > 
> > So my suggestion is that you _don't_ ship your computers with 3com cards,
> > at least not the 509.
> 
> I'd have to ask why anyone would use a 3c509 when an NE2000 clone is 
> cheaper, faster and better supported.
> 
> Alternatively, I'd have to wonder why anyone would contemplate shipping 
> a hardware combination that they haven't tested extensively in-house 
> first.
> 

Ok... this I take offence at.. I have always had great troubles with the
NE2000 cards and compatibles in all areas (from working to performance).
I have 2 3c509s in my system, and have only had a problem once (Back with
FreeBSD 2.1.5 I think, which got pulled because of the problem).  As for
performance... I have done cross subnet installs with these cards and got
a sustained (on a 1.5 Gigabyte file) transfer of 800 K Bytes per second
(between 2 3c509s, across 2 subnets with other computers)... I am *very*
pleased with these cards.  My understanding of the 'buggy' comment comes
from the PNP nature of these cards.

--
David Cross
ACS Consultant


From owner-freebsd-hackers  Mon Dec 15 19:38:45 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA17508
          for hackers-outgoing; Mon, 15 Dec 1997 19:38:45 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA17503
          for ; Mon, 15 Dec 1997 19:38:41 -0800 (PST)
          (envelope-from cmott@srv.net)
Received: from darkstar.home (ras520.srv.net [205.180.127.20]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id UAA01398 for ; Mon, 15 Dec 1997 20:38:31 -0700
Date: Mon, 15 Dec 1997 20:37:58 -0700 (MST)
From: Charles Mott 
X-Sender: cmott@darkstar.home
To: FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-Reply-To: <199712160244.NAA00629@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

> Nope.  They're both PIO cards, and the 'ed' driver spits all over the 
> 'ep' driver.  Any inversions you may have seen would have been 
> environmental relating to the different behaviour of the various chips 
> relating to bus traffic.
> 
> Yes, I've used both.  Yes, I've seen > 1000K/sec out of an 'ed' card on 
> a 486/50.   With modern processors, yes, the differences are less 
> evident, but I'll still take an NE2000 over a 509 anyday.  Especially 
> when a single-chip card based on something like the RTL2019 costs less 
> than AUD$40, and "just works".
> 
> mike
> 

I've gotten 700 Kbytes/sec for sustained transfers on an NE 2000 clone on
a 386/33 under 2.2.2.  Performance under 2.1.x was 300 Kbytes/sec. 
Something radically improved in the 2.1->2.2 transition.  I had thought it
was the core networking code, but I am wondering if the driver improved
also.

Sometimes slow CPUs are good indicators of software improvements.

Charles Mott


From owner-freebsd-hackers  Mon Dec 15 20:38:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA20902
          for hackers-outgoing; Mon, 15 Dec 1997 20:38:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from mars.abcinternet.net (drow@mars.abcinternet.net [205.216.244.14])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA20894
          for ; Mon, 15 Dec 1997 20:37:56 -0800 (PST)
          (envelope-from drow@drow.net)
Received: from localhost (drow@localhost)
	by mars.abcinternet.net (8.8.8/8.8.5) with SMTP id XAA20361
	for ; Mon, 15 Dec 1997 23:36:26 -0500 (EST)
Date: Mon, 15 Dec 1997 23:36:26 -0500 (EST)
From: Dan Jacobowitz  
X-Sender: drow@mars.abcinternet.net
To: hackers@freebsd.org
Subject: passwd issues with kerberos
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 of all - my system somehow ended up using MD5 passwords (don't ask)
and my next project for passwd will be to make it switch to DES passwords.
That's a site-specific patch more than a FreeBSD issue, although I'll make
it available once I get it to work.)

Next - is the DES encryption used by kerberosIV and that used by
libdescrypt?  If so, it may be possible for me to hack kdb_edit to create
new principals for all of my users from the passwd databse, once we're
back in DES mode.

Is there an adduser with kerberos support by any chance?  Adding each one
is a royal pain - I know there must be a better tool than kdb_edit out
there somewhere.

 

I have currently kerberos installed - more for the encrypted telnet
sessions than anything else - but only I and a few others have kerberos
principals.  I got royally sick of passwd assuming kerberos (unless passwd
-l was explicitly specified - Teach a bunch of idiot users THAT:).  So,
here's a little patch to /usr/src/usr.bin/passwd/passwd.c which simply
checks to see whether the user has a kerberos principal and if not assumes
local passwords.  Now, I understand this may not be desirable in
absolutely all situations - that's why the #ifdef.

Feel free to offer opinions/alternatives/improvements.

Here goes:

*** passwd.c.old	Fri Aug  1 02:39:47 1997
--- passwd.c	Mon Dec 15 23:16:27 1997
***************
*** 208,215 ****
  	if (!use_local_passwd) {
  #ifdef	KERBEROS
  		if(krb_get_lrealm(realm, 0) == KSUCCESS) {
! 			fprintf(stderr, "realm %s\n", realm);
! 			exit(krb_passwd(argv[0], iflag, rflag, uflag));
  		}
  #endif
  	}
--- 208,221 ----
  	if (!use_local_passwd) {
  #ifdef	KERBEROS
  		if(krb_get_lrealm(realm, 0) == KSUCCESS) {
! #ifndef HATE_NON_KERBEROS
! 			if (KDC_PR_UNKNOWN != krb_get_pw_in_tkt(uname, "", realm, "krbtgt", realm, 1, "")) {
! #endif
! 				fprintf(stderr, "realm %s\n", realm);
! 				exit(krb_passwd(argv[0], iflag, rflag, uflag));
! #ifndef HATE_NON_KERBEROS
! 			}
! #endif
  		}
  #endif
  	}



From owner-freebsd-hackers  Mon Dec 15 20:44:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA21358
          for hackers-outgoing; Mon, 15 Dec 1997 20:44:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA21343
          for ; Mon, 15 Dec 1997 20:44:09 -0800 (PST)
          (envelope-from jin@george.lbl.gov)
Received: (from jin@localhost)
	by george.lbl.gov (8.8.8/LBL-ITG) id UAA16864
	for hackers@freebsd.org; Mon, 15 Dec 1997 20:44:08 -0800 (PST)
Date: Mon, 15 Dec 1997 20:44:08 -0800 (PST)
From: Jin Guojun (ITG staff) 
Message-Id: <199712160444.UAA16864@george.lbl.gov>
To: hackers@freebsd.org
Subject: suggestion on using boot.config
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I do not know if this is a good place to address this issue.

For remote development, I would like to modified "boot.c" to rename
"/boot.config" to either "/boot.config.run" or "/boot.config.last"
after readfile("boot.config", boot_config, BOOT_CONFIG_SIZE);

The reason for this change is just for remote development.
This will avoid bad kernel/driver keep looping on panic during the development.

For example,
# more /boot.config
/kernel.newdrv

# ll /k*
-rwxr-xr-x  1 root  wheel  1282582 Dec 12 18:11 /kernel*
-rwxr-xr-x  1 root  wheel  1457189 Dec 12 09:43 /kernel.GENERIC*
-rwxr-xr-x  1 root  wheel  1507955 Dec 15 19:42 /kernel.newdrv*
-rw-r--r--  1 root  wheel        0 Dec 12 09:43 /kernel.config


This boot.config will boot system to /kernel.newdrv. If /kernel.newdrv is bad
and there is no one near the machine, currently, the machine will never boot up.
If /boot.config can be renamed in boot.c and maybe changed back after 
successfully booting, it will be panic on /kernel.newdrv and automatically
boot to /kernel on the second time; so thing can keep going.

Any Pro/Con?

-Jin

P.S.	Please CC to me when reply. Thanks.


From owner-freebsd-hackers  Mon Dec 15 21:17:23 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA23525
          for hackers-outgoing; Mon, 15 Dec 1997 21:17:23 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA23510
          for ; Mon, 15 Dec 1997 21:17:16 -0800 (PST)
          (envelope-from dec@phoenix.its.rpi.edu)
Received: from localhost (dec@localhost)
	by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id AAA14483;
	Tue, 16 Dec 1997 00:17:05 -0500 (EST)
	(envelope-from dec@phoenix.its.rpi.edu)
Date: Tue, 16 Dec 1997 00:17:05 -0500 (EST)
From: "David E. Cross" 
To: Dan Jacobowitz 
cc: hackers@FreeBSD.ORG
Subject: Re: passwd issues with kerberos
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 Dec 1997, Dan Jacobowitz wrote:

> 
> 
> 
> (First of all - my system somehow ended up using MD5 passwords (don't ask)
> and my next project for passwd will be to make it switch to DES passwords.
> That's a site-specific patch more than a FreeBSD issue, although I'll make
> it available once I get it to work.)
> 
> Next - is the DES encryption used by kerberosIV and that used by
> libdescrypt?  If so, it may be possible for me to hack kdb_edit to create
> new principals for all of my users from the passwd databse, once we're
> back in DES mode.

Yes, KerberosIV (asnd Kerberos V by default use DES).  The answer to you
second question is no.  Kerberos IV uses straight DES CBC (actually PCBC).
The DES used in the passwd files is DES with a 'salt' value.  The 'salt'
value (there are 4096 of them) is mixed in with the password at each round
(there are 12 rounds, Kerberos IV only has one).  In short, while both are
DES, there are numerous differences that would make 'converting' the
passwords not possible.  On the plus side of things, you can give poeple
both a kerberos and a local password, instruct them to change, and nuke
their regular password when they do (this is the method I usually
recomend).

> 
> Is there an adduser with kerberos support by any chance?  Adding each one
> is a royal pain - I know there must be a better tool than kdb_edit out
> there somewhere.
> 
yes... using kdb_edit is just plain evil... use 'kadmin'  (requires you
start kadmind, which you should anyway).  There is a good section on this
in the FreeBSD Handbook.



From owner-freebsd-hackers  Mon Dec 15 22:08:59 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA27861
          for hackers-outgoing; Mon, 15 Dec 1997 22:08:59 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from noether.blah.org (slmel12p25.ozemail.com.au [203.108.200.113])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA27829
          for ; Mon, 15 Dec 1997 22:08:43 -0800 (PST)
          (envelope-from ada@not-enough.bandwidth.org)
Received: (from ada@localhost)
          by noether.blah.org (8.8.7/8.8.8) id RAA03776
          for hackers@FreeBSD.ORG; Tue, 16 Dec 1997 17:08:18 +1100 (EST)
From: Ada 
Message-Id: <199712160608.RAA03776@noether.blah.org>
Subject: Re: Why FIONREAD has no dual for write ?
In-Reply-To: <199712091520.HAA09154@hub.freebsd.org> from "owner-hackers-digest@FreeBSD.ORG" at "Dec 9, 97 07:20:23 am"
To: hackers@FreeBSD.ORG
Date: Tue, 16 Dec 1997 17:08:18 +1100 (EST)
Reply-To: ada@bsd.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

> From: Bakul Shah 
> Date: Mon, 08 Dec 1997 19:45:05 -0500
> Subject: Re: Why FIONREAD has no dual for write ? 
> 
> Perhaps one solution is to add an ioctl to set high/low
> watermarks on a device and add new event bits POLLIN_WM and
> POLLLOUT_WM for the poll() syscall.
> 
> In pollfd->events you set these bits instead of (or in
> addition to) POLLIN/POLLOUT.  On return the corresponding bit
> in pollfd->revents is set only if there are _greater than low
> watermark_ bytes on input and _less than high watermark_
> bytes on output.  This guarantees that you can transfer some
> minimum number of bytes on read/write (provided you use the
> O_EXCL mode).
> 
> This is a more general solution that allows finer control
> over when to schedule IO and is useful in all sorts of
> situations.

How about a counterpart to select() which can request a minimum number
of bytes {free,ready} in the buffer?  This could also be useful in
situations where one does not wish to implement buffering; instead the
kernel buffers could be used.

Is this feasable in light of how select() works?

Ada.

From owner-freebsd-hackers  Mon Dec 15 22:40:14 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA29697
          for hackers-outgoing; Mon, 15 Dec 1997 22:40:14 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 WAA29687
          for ; Mon, 15 Dec 1997 22:40:09 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id WAA18399;
	Mon, 15 Dec 1997 22:32:42 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd018395; Mon Dec 15 22:32:35 1997
Date: Mon, 15 Dec 1997 22:29:54 -0800 (PST)
From: Julian Elischer 
To: Jin Guojun 
cc: hackers@FreeBSD.ORG
Subject: Re: suggestion on using boot.config
In-Reply-To: <199712160444.UAA16864@george.lbl.gov>
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

for this you should try:
man nextboot

the bootblocks in teh state they are in now\have some bugs if you try to
set flags (e.g. -s) but otherwise the options for nextboot work well
it can be set to selct differnt kernels and partitions for the next 65
boots if you wish

(it uses up N+3 bytes per boot where N is the name of the kernel.
the WRITEBACK option will zero out each name as it's used.)

The down side of this is it cannot be used in "Dangerously dedicated" mode
(I have thoughts for this)


julian
(We use it all the time for remote rebooting on new kernels.
If the boot fails, the next boot will use the next name in the sequence.)
(of course we also have a hardware watchdog)
 
On Mon, 15 Dec 1997, Jin Guojun wrote:

> I do not know if this is a good place to address this issue.
> 
> For remote development, I would like to modified "boot.c" to rename
> "/boot.config" to either "/boot.config.run" or "/boot.config.last"
> after readfile("boot.config", boot_config, BOOT_CONFIG_SIZE);
> 
> The reason for this change is just for remote development.
> This will avoid bad kernel/driver keep looping on panic during the development.
> 
> For example,
> # more /boot.config
> /kernel.newdrv
> 
> # ll /k*
> -rwxr-xr-x  1 root  wheel  1282582 Dec 12 18:11 /kernel*
> -rwxr-xr-x  1 root  wheel  1457189 Dec 12 09:43 /kernel.GENERIC*
> -rwxr-xr-x  1 root  wheel  1507955 Dec 15 19:42 /kernel.newdrv*
> -rw-r--r--  1 root  wheel        0 Dec 12 09:43 /kernel.config
> 
> 
> This boot.config will boot system to /kernel.newdrv. If /kernel.newdrv is bad
> and there is no one near the machine, currently, the machine will never boot up.
> If /boot.config can be renamed in boot.c and maybe changed back after 
> successfully booting, it will be panic on /kernel.newdrv and automatically
> boot to /kernel on the second time; so thing can keep going.
> 
> Any Pro/Con?
> 
> -Jin
> 
> P.S.	Please CC to me when reply. Thanks.
> 
> 


From owner-freebsd-hackers  Tue Dec 16 00:04:44 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA05114
          for hackers-outgoing; Tue, 16 Dec 1997 00:04:44 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 AAA05103
          for ; Tue, 16 Dec 1997 00:04:35 -0800 (PST)
          (envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
	id 0xhrn2-0000oB-00; Mon, 15 Dec 1997 23:51:40 -0800
Date: Mon, 15 Dec 1997 23:51:31 -0800 (PST)
From: Tom 
To: Mike Smith 
cc: Greg Lehey , Johan Larsson ,
        Rob Nelson , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-Reply-To: <199712160244.NAA00629@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


On Tue, 16 Dec 1997, Mike Smith wrote:

> > I'd have to, too.  But in my experience, the 3c509 is a whole lot
> > faster than the NE2000 clones I've used.  Of course, nowadays with
> > fast processors, you don't see much difference, but it's a different
> > story with 486/33's
> 
> Nope.  They're both PIO cards, and the 'ed' driver spits all over the 
> 'ep' driver.  Any inversions you may have seen would have been 
> environmental relating to the different behaviour of the various chips 
> relating to bus traffic.

  In fact don't NE2000 cards have way more buffer space too?  I know all
NE2000 cards have a 16KB buffer, and I believe the 509 card is much less.

  Also, the ed driver supports shared memory cards like the SMC Ultra 16.
Fastest ISA ethernet you can get.

Tom


From owner-freebsd-hackers  Tue Dec 16 00:40:50 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA07488
          for hackers-outgoing; Tue, 16 Dec 1997 00:40:50 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from noether.blah.org (slmel12p25.ozemail.com.au [203.108.200.113])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07463
          for ; Tue, 16 Dec 1997 00:40:22 -0800 (PST)
          (envelope-from ada@not-enough.bandwidth.org)
Received: (from ada@localhost)
          by noether.blah.org (8.8.7/8.8.8) id TAA05709
          for hackers@freebsd.org; Tue, 16 Dec 1997 19:39:58 +1100 (EST)
From: Ada 
Message-Id: <199712160839.TAA05709@noether.blah.org>
Subject:  Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port
In-Reply-To: <199712152018.MAA08626@hub.freebsd.org> from "owner-hackers-digest@freebsd.org" at "Dec 15, 97 12:18:16 pm"
To: hackers@freebsd.org
Date: Tue, 16 Dec 1997 19:39:58 +1100 (EST)
Reply-To: ada@bsd.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

> From: Jonathan Mini 
> Date: Sun, 14 Dec 1997 23:32:06 -0800
> Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port

>   Although it seems rediculous, I ask a different question : "how long until
> FreeBSD has a 256k kernel?" I'd like to see a system come into implementation
> where all modules can become dynamic, including things such as the UFS and inet
> modules, which currently are basically manditory. (the astute reader would
> realise that a dynamic module system that did this would require a built-in
> dependancy system, but that's another issue altogether)
>   This type of dynamic loading of modules can't be implemented correctly until
> we have a method of easily tracking resources dynamically. John-Mark's
> bus/device system does this, and, based on my observations of he current
> codebase, it is obvious (at least to me, YMMV) that this code is greatly
> required.
There is a fundamental problem between this and devfs:

if devfs waits for the driver to create device nodes, and the driver waits
until its device entry is touched before it's loaded, how does the
process begin?

Ada.

-- 
`Albert, stop telling God what to do.'
	-- Niels Bohr

From owner-freebsd-hackers  Tue Dec 16 00:43:06 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA07661
          for hackers-outgoing; Tue, 16 Dec 1997 00:43:06 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07654
          for ; Tue, 16 Dec 1997 00:43:01 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-13.cetlink.net [209.54.58.13])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id DAA29966;
          Tue, 16 Dec 1997 03:42:15 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Tom 
Cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
Date: Tue, 16 Dec 1997 09:43:02 GMT
Message-ID: <34964c48.30733173@mail.cetlink.net>
References: 
In-Reply-To: 
X-Mailer: Forte Agent 1.01/16.397
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 AAA07656
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Mon, 15 Dec 1997 23:51:31 -0800 (PST), Tom  wrote:

>  Also, the ed driver supports shared memory cards like the SMC Ultra 16.
>Fastest ISA ethernet you can get.

I replaced an NE2000 clone with a SMC Ultra 16, thinking shared memory
would consume far less CPU than PIO with an NE2000.  But it seems to
be about the same.

John




From owner-freebsd-hackers  Tue Dec 16 00:46:36 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA07905
          for hackers-outgoing; Tue, 16 Dec 1997 00:46:36 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 AAA07885
          for ; Tue, 16 Dec 1997 00:46:30 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id TAA01580;
	Tue, 16 Dec 1997 19:10:50 +1030 (CST)
Message-Id: <199712160840.TAA01580@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: jak@cetlink.net (John Kelly)
cc: Tom , Mike Smith ,
        FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Tue, 16 Dec 1997 09:43:02 GMT."
             <34964c48.30733173@mail.cetlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Tue, 16 Dec 1997 19:10:50 +1030
From: Mike Smith 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id AAA07891
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> On Mon, 15 Dec 1997 23:51:31 -0800 (PST), Tom  wrote:
> 
> >  Also, the ed driver supports shared memory cards like the SMC Ultra 16.
> >Fastest ISA ethernet you can get.
> 
> I replaced an NE2000 clone with a SMC Ultra 16, thinking shared memory
> would consume far less CPU than PIO with an NE2000.  But it seems to
> be about the same.

About half.  Please don't confuse anecdotal evidence with measured 
results.

mike



From owner-freebsd-hackers  Tue Dec 16 00:50:25 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA08251
          for hackers-outgoing; Tue, 16 Dec 1997 00:50:25 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA08243
          for ; Tue, 16 Dec 1997 00:50:17 -0800 (PST)
          (envelope-from erakupa@kk.etx.ericsson.se)
Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-1.12) with SMTP id JAA22409 for ; Tue, 16 Dec 1997 09:49:47 +0100 (MET)
Received: from kk662.kk.etx.ericsson.se by kkb3 (SMI-8.6/LME-2.2.6)
	id JAA18996; Tue, 16 Dec 1997 09:49:43 +0100
From: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen)
Received: by kk662.kk.etx.ericsson.se (SMI-8.6/client-1.6)
	id JAA02895; Tue, 16 Dec 1997 09:49:45 +0100
Date: Tue, 16 Dec 1997 09:49:45 +0100
Message-Id: <199712160849.JAA02895@kk662.kk.etx.ericsson.se>
To: freebsd-hackers@freebsd.org
Subject: profiling inside kernel
X-Sun-Charset: US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hello hackers!

I have hopefully two simple questions:

- How can one get assembler listing from a function within gdb?
  (I need to count the real machine instructions in a function)

- How can one do some profiling in kernel (to find out bottle
  necks etc. in my LKM)

I'm running FreeBSD 2.2.5-RELEASE if that matters. Thanks for your
answer in advance :-)

/Martti

From owner-freebsd-hackers  Tue Dec 16 00:58:29 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA08768
          for hackers-outgoing; Tue, 16 Dec 1997 00:58:29 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA08758
          for ; Tue, 16 Dec 1997 00:58:23 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-13.cetlink.net [209.54.58.13])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id DAA00369;
          Tue, 16 Dec 1997 03:58:09 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Mike Smith 
Cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
Date: Tue, 16 Dec 1997 09:57:47 GMT
Message-ID: <34974fcb.31632460@mail.cetlink.net>
References: <199712160840.TAA01580@word.smith.net.au>
In-Reply-To: <199712160840.TAA01580@word.smith.net.au>
X-Mailer: Forte Agent 1.01/16.397
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 AAA08759
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, 16 Dec 1997 19:10:50 +1030, Mike Smith 
wrote:

>> I replaced an NE2000 clone with a SMC Ultra 16, thinking shared memory
>> would consume far less CPU than PIO with an NE2000.  But it seems to
>> be about the same.
>
>About half.  Please don't confuse anecdotal evidence with measured 
>results.
>

I tested with an FTP transfer and consumed about 45% CPU in both
cases.  

I wonder if I'm doing something wrong.  I have the SMC card set to use
zero wait state and my kernel recognizes the memory on the card.  I
don't know what else I can do to improve it.

John




From owner-freebsd-hackers  Tue Dec 16 01:23:56 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA10629
          for hackers-outgoing; Tue, 16 Dec 1997 01:23:56 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 BAA10592
          for ; Tue, 16 Dec 1997 01:23:42 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id TAA18346;
          Tue, 16 Dec 1997 19:53:05 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971216195304.56154@lemis.com>
Date: Tue, 16 Dec 1997 19:53:04 +1030
From: Greg Lehey 
To: John Kelly 
Cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card
References: <199712160840.TAA01580@word.smith.net.au> <34974fcb.31632460@mail.cetlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <34974fcb.31632460@mail.cetlink.net>; from John Kelly on Tue, Dec 16, 1997 at 09:57:47AM +0000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, Dec 16, 1997 at 09:57:47AM +0000, John Kelly wrote:
> On Tue, 16 Dec 1997 19:10:50 +1030, Mike Smith 
> wrote:
>
>>> I replaced an NE2000 clone with a SMC Ultra 16, thinking shared memory
>>> would consume far less CPU than PIO with an NE2000.  But it seems to
>>> be about the same.
>>
>> About half.  Please don't confuse anecdotal evidence with measured
>> results.
>>
>
> I tested with an FTP transfer and consumed about 45% CPU in both
> cases.

That's a lot of CPU.  What kind of CPU is it?  How much user time did
it use?

Greg

From owner-freebsd-hackers  Tue Dec 16 02:38:05 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA15054
          for hackers-outgoing; Tue, 16 Dec 1997 02:38:05 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from pili.adn.edu.ph (pili.adn.edu.ph [165.220.57.4])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA15024;
          Tue, 16 Dec 1997 02:37:53 -0800 (PST)
          (envelope-from art@pili.adn.edu.ph)
Received: from localhost (art@localhost)
	by pili.adn.edu.ph (8.8.5/8.8.5) with SMTP id SAA11676;
	Tue, 16 Dec 1997 18:45:10 +0800 (PHT)
Date: Tue, 16 Dec 1997 18:45:10 +0800 (PHT)
From: Arthur Alacar 
To: hackers@FreeBSD.ORG
cc: freebsd-questions@FreeBSD.ORG
Subject: ESS ES688 Audio Drive 
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



Am running on FreeBSD-2.2.5 and is trying to configure my 
ESS ES688 Audio Drive. But CAN'T make it to work. 

i have tried using soundblaster pro device ... with this kernel
configuration..


> options		SBC_IRQ=5

> controller snd0
> device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr
> device opl0 at isa? port 0x388
> device joy0 at isa? port "IO_GAME"


and the OS were able to DETECT these devices..

but whenever i tried working with sounds... am receiving this error
message.

> Sound: DMA timed out - IRQ/DRQ config error?


is there any available support for this card? or how can i make this up? 

need help on this. THANK YOU!


Merry Christmas BSD people!

.a.r.t.



From owner-freebsd-hackers  Tue Dec 16 02:52:58 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA16008
          for hackers-outgoing; Tue, 16 Dec 1997 02:52:58 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA16002
          for ; Tue, 16 Dec 1997 02:52:43 -0800 (PST)
          (envelope-from daniel_sobral@voga.com.br)
From: daniel_sobral@voga.com.br
Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997))  id 0325656F.003BC017 ; Tue, 16 Dec 1997 07:52:37 -0300
X-Lotus-FromDomain: VOGA
To: tlambert@primenet.com
cc: hackers@FreeBSD.ORG
Message-ID: <8325656F.0038C91F.00@papagaio.voga.com.br>
Date: Tue, 16 Dec 1997 07:52:31 -0300
Subject: Re: Why so many steps to build new kernel?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


> The existance of mutually exclusive drivers is not friendly.

Agreed. But do not forget that mutual exclusion is not the only thing being
discussed here. You said prerequisites are not useful either.

> There are two types of exclusion:

> 1) Screw up: the driver probes are antagonistic to other
> hardware.  This should be fixed by changing the probe
> code.

This may not always be fixed, as far as legacy hardware goes.

> 2) Screw up: there is more than one driver for the given
> hardware.  This should be fixed by integration.

> Your console example falls into #2, and Johnathan Mini is working
> on fixing it.

> Do you have other examples?

Since you disregarded my RL examples as "will be fixed in the future", I'll
bring something from the future to haunt you... :-)

FreeBSD creates a driver for device X. Third-party commercial vendor
creates another driver for the same device X. Thus, you cannot help but say
"hey, use _this_ driver instead of the other one".

Now, just so you don't forget, below we discuss mutual exclusions _and_
prerequisites.

> > That would kind of work. Except... that structure does not have the
> > semantic content for which it is being used, meaning that:
>
> > 1) If the need later arises for the correct structure, we'll be left
with
> > the choice of modifying *all* previous structures to the correct one
(and
> > we all know how hard such things are), or using two different
structures
> > for the same end.

> This is why there needs to be an extensible schema mechanism (like that
> of LDAP) instead of a binary structure based mechanism for doing this
> sort of thing.

> This is why God invented Directories.

That is not the point. We use your solution to deal with "legacy" code that
has not been "fixed" yet (assuming this is at all possible), and then we
stumble on some other "mutually exclusive options" that _cannot_ be solved
the way you proposed. We create the "mutual exclusion" structure to solve
that problem, and end up with two different structures being used to solve
the same problem. See 1) above.

As for "binary", I haven't said "binary", I haven't _thought_ "binary".
When I say "structure", forget C's "struct". Structure as in "directories
is a structure".

> > 2) It may lead to pilot error.

> Detachable power cords lead to pilot error.  Eventually, you have to
> cut your losses below a certain level of complexity.  Your problem
> with this seems to be that BSD isn't below that line.

> I think a kernel configurator will just prop up the existing bad
> situation, and delay more correct change.

Not at all.

First, you have yet to show me that we can do without some kind of "what
devices/features I want to be loaded/probed" configurator. I *don't have*
PCI on my FreeBSD computer, so it is very easy for me to ignore any
suggestion that precludes non-PCI hardware.

Second, I am not coding anything. Somebody else is, and this somebody
choose to deal with the problem at this level. I'm just making suggestions
in the hope that he won't screw up in the process he has choosen to deal
with.

> > 3) It's a hack and should be banned to hell.
>
> > Terry, are you suggesting a backward compatibility hack (with
tradition,
> > not even code!) instead of doing the right thing???

> "Backward compatability hack"?  ELF archiver?

> What ELF system are *you* running on?!?

Elf? You said "rc.conf". You were talking about using sections instead of
prerequisites to deal with the "history buffer only with syscon" problem.
So, you propose a solution that does not deal directly with the problem, by
stating explicitly "this only if that", which has potential problems as
shown above, and say your solution has historical precedent, exemplifying
with rc.conf.

Terry, it would be more productive if you choose one of the two solutions
you proposed:

1) Don't. Kernel configuration should go away. (In this case, just stay
away from the discussion, as it's about kernel configuration, like it or
not)

2) Use this and that. (In this case, deal with the issues at hand instead
of directing problems to your solution to 1)

> > You mean there won't be no need for a build-time configurator if and
when
> > we get to the perfect world, right? Because, right now, I can't seem to
get
> > along without config...

> And the more you enhance it, the less likely that people will do anything
> about moving the code forward in this area.  "Good Enough" is the enemy
> of "Better".

That's a valid point of view, though I think it is flawed. Anyway, if
that's your opinion, why are you discussing how the kernel configurator
file should be structured?



From owner-freebsd-hackers  Tue Dec 16 02:53:58 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA16051
          for hackers-outgoing; Tue, 16 Dec 1997 02:53:58 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA16046
          for ; Tue, 16 Dec 1997 02:53:53 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-40.cetlink.net [209.54.58.40])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id FAA06965;
          Tue, 16 Dec 1997 05:53:06 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Greg Lehey 
Cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card
Date: Tue, 16 Dec 1997 11:54:03 GMT
Message-ID: <349867a9.37744789@mail.cetlink.net>
References: <199712160840.TAA01580@word.smith.net.au> <34974fcb.31632460@mail.cetlink.net> <19971216195304.56154@lemis.com>
In-Reply-To: <19971216195304.56154@lemis.com>
X-Mailer: Forte Agent 1.01/16.397
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 CAA16047
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, 16 Dec 1997 19:53:04 +1030, Greg Lehey  wrote:

>> I tested with an FTP transfer and consumed about 45% CPU in both
>> cases.
>
>That's a lot of CPU.

It was an FTP upload.  A download consumed less CPU.

>What kind of CPU is it?

486 DX4-100.

>How much user time did it use?

With an 8 meg file upload, user CPU was less than 3%, while interrupt
CPU varied between 25% - 35% and system CPU varied between 25% - 35%.

Downloading the same file, total CPU was only 35%, with interrupt no
more than about 10%.


John



From owner-freebsd-hackers  Tue Dec 16 02:55:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA16295
          for hackers-outgoing; Tue, 16 Dec 1997 02:55:55 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 CAA16275
          for ; Tue, 16 Dec 1997 02:55:50 -0800 (PST)
          (envelope-from luigi@labinfo.iet.unipi.it)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA04814; Tue, 16 Dec 1997 09:42:24 +0100
From: Luigi Rizzo 
Message-Id: <199712160842.JAA04814@labinfo.iet.unipi.it>
Subject: Re: Why FIONREAD has no dual for write ?
To: ada@bsd.org
Date: Tue, 16 Dec 1997 09:42:24 +0100 (MET)
Cc: hackers@FreeBSD.ORG
In-Reply-To: <199712160608.RAA03776@noether.blah.org> from "Ada" at Dec 16, 97 05:07:59 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > situations.
w dou 
> 
> How about a counterpart to select() which can request a minimum number
> of bytes {free,ready} in the buffer?  This could also be useful in
> situations where one does not wish to implement buffering; instead the
> kernel buffers could be used.
> 
> Is this feasable in light of how select() works?
> 
> Ada.
> 
How do you pass the (array of=) desired lengths to the new select ?

	Luigi

From owner-freebsd-hackers  Tue Dec 16 04:01:48 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA20073
          for hackers-outgoing; Tue, 16 Dec 1997 04:01:48 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA20067
          for ; Tue, 16 Dec 1997 04:01:40 -0800 (PST)
          (envelope-from arg@arg1.demon.co.uk)
Received: (from arg@localhost)
	by arg1.demon.co.uk (8.8.5/8.8.5) id LAA12880;
	Tue, 16 Dec 1997 11:59:19 GMT
Date: Tue, 16 Dec 1997 11:59:18 +0000 (GMT)
From: Andrew Gordon 
X-Sender: arg@server.arg.sj.co.uk
To: John Kelly 
cc: FreeBSD Hackers , Mike Smith 
Subject: Re: 3com 3c509 card 
In-Reply-To: <34964c48.30733173@mail.cetlink.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 Dec 1997, John Kelly wrote:

> On Mon, 15 Dec 1997 23:51:31 -0800 (PST), Tom  wrote:
> 
> >  Also, the ed driver supports shared memory cards like the SMC Ultra 16.
> >Fastest ISA ethernet you can get.
> 
> I replaced an NE2000 clone with a SMC Ultra 16, thinking shared memory
> would consume far less CPU than PIO with an NE2000.  But it seems to
> be about the same.

Have you got a _real_ (no longer available) Ultra here?  Testing with FTP 
(on a 486), I get about 600-700kbyte/sec with NE2000s, and 900-1000kbyte/s
with SMC Ultra.  However, the "EtherEZ" which has replaced the Ultra 
appears to be a bit of a lemon - giving rather inconsistent performance
(dropped packets) and even when not dropping packets, worse throughput 
than the Ultra.  This appears to be due to its reduced buffer size (8K 
vs. 16K); also, I notice that it only has one chip for the 8K RAM (vs. 2 
chips on the Ultra) - so, although still notionally a 16-bit card, I 
suspect it might be multiplexing accesses to a single 8-bit wide device 
and hence needing to insert wait states.  I haven't actually proven this 
theory, but the performance is certainluy not good.

(above tests done with several examples of each type, so I'm not 
suffering from faulty cards).

From owner-freebsd-hackers  Tue Dec 16 05:10:36 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA23510
          for hackers-outgoing; Tue, 16 Dec 1997 05:10:36 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cindy.ensino.ibilce.unesp.br (root@cindy.ensino.ibilce.unesp.br [200.17.30.150])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA23501
          for ; Tue, 16 Dec 1997 05:10:27 -0800 (PST)
          (envelope-from JULAVERO@midway.ensino.ibilce.unesp.br)
From: JULAVERO@midway.ensino.ibilce.unesp.br
Received: from midway.ensino.ibilce.unesp.br (midway.ensino.ibilce.unesp.br [200.17.30.230])
	by cindy.ensino.ibilce.unesp.br (8.8.7/8.8.7) with ESMTP id LAA18950
	for ; Tue, 16 Dec 1997 11:09:09 -0200
Received: from MIDWAY/SpoolDir by midway.ensino.ibilce.unesp.br (Mercury 1.21);
    16 Dec 97 11:13:31 gmt -0300
Received: from SpoolDir by MIDWAY (Mercury 1.30); 16 Dec 97 11:13:03 gmt -0300
To: HACKERS@FREEBSD.ORG
Date:          Tue, 16 Dec 1997 11:13:00 GMT-0300
Subject:       
Priority: normal
X-mailer: Pegasus Mail v3.40 (NDS)
Message-ID: <10245361A2F@midway.ensino.ibilce.unesp.br>
Sender: owner-freebsd-hackers@FREEBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

UNSUBSCRIBE

From owner-freebsd-hackers  Tue Dec 16 05:15:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA23766
          for hackers-outgoing; Tue, 16 Dec 1997 05:15:04 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cindy.ensino.ibilce.unesp.br (root@cindy.ensino.ibilce.unesp.br [200.17.30.150])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA23670
          for ; Tue, 16 Dec 1997 05:13:42 -0800 (PST)
          (envelope-from JULAVERO@midway.ensino.ibilce.unesp.br)
From: JULAVERO@midway.ensino.ibilce.unesp.br
Received: from midway.ensino.ibilce.unesp.br (midway.ensino.ibilce.unesp.br [200.17.30.230])
	by cindy.ensino.ibilce.unesp.br (8.8.7/8.8.7) with ESMTP id LAA20288
	for ; Tue, 16 Dec 1997 11:12:45 -0200
Received: from MIDWAY/SpoolDir by midway.ensino.ibilce.unesp.br (Mercury 1.21);
    16 Dec 97 11:17:07 gmt -0300
Received: from SpoolDir by MIDWAY (Mercury 1.30); 16 Dec 97 11:15:43 gmt -0300
To: HACKERS@FREEBSD.ORG
Date:          Tue, 16 Dec 1997 11:15:37 GMT-0300
Subject:       
Priority: normal
X-mailer: Pegasus Mail v3.40 (NDS)
Message-ID: <102509B45BB@midway.ensino.ibilce.unesp.br>
Sender: owner-freebsd-hackers@FREEBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

UNSUBSCRIBE

From owner-freebsd-hackers  Tue Dec 16 06:44:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA28768
          for hackers-outgoing; Tue, 16 Dec 1997 06:44:51 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from crocus.gamma.ru (crocus.gamma.ru [193.124.255.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA28733
          for ; Tue, 16 Dec 1997 06:44:13 -0800 (PST)
          (envelope-from ivt@crocus.gamma.ru)
Received: (from ivt@localhost) by crocus.gamma.ru (8.8.5/8.7.3) id RAA24936; Tue, 16 Dec 1997 17:42:11 +0300 (MSK)
Message-Id: <199712161442.RAA24936@crocus.gamma.ru>
Subject: Re: panic: blkfree: freeling free block/frag
In-Reply-To: <199712051953.MAA16124@usr08.primenet.com> from Terry Lambert at "Dec 5, 97 07:53:14 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Tue, 16 Dec 1997 17:42:10 +0300 (MSK)
Cc: ivt@gamma.ru, freebsd-hackers@FreeBSD.ORG
From: "Igor Timkin" 
Organization: Gamma Ltd., Moscow, Russia
X-Class: Fast
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

Terry Lambert writes:
> > Every 4-8 days my news server (~10 full incoming feeds, ~50
> > outgoing feeds) crash:
> > panic: blkfree: freeing free block
> > or
> > panic: blkfree: freeing free frag
> 
> Long Answer:
> 
> Generally, this type of problem means you should rebuild the news spool,
> since *any* corruption could result in invalid information on the disk
> that could result in a panic.
> 
> Most likely, you crashed once, and you expected fsck to do something
> that it can't do reliably: recover an async mounted partition.  The
> partition was "recovered" and marked clean, but when you reference
> a particular disk metadata construct, it goes off into the weeds
> because the recovery was imperfect.

Unfortunally, I still have this problem.
I had make newfs 5 days ago. But yestarday I got the same panic
(uptime 5.2 days):

ivt@news:/var/tmp/innfeed:2:306>gdb -k /sys/compile/NEWS/kernel /usr/local/news/crash/vmcore.1
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd), 
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 1f0000
current pcb at 1d79c0
panic: blkfree: freeing free block
#0  boot (howto=256) at ../../kern/kern_shutdown.c:266
266                                     dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:266
#1  0xe01105e2 in panic (fmt=0xe0188a85 "blkfree: freeing free block")
    at ../../kern/kern_shutdown.c:390
#2  0xe0188c57 in ffs_blkfree (ip=0xe3e50500, bno=10, size=4096)
    at ../../ufs/ffs/ffs_alloc.c:1230
#3  0xe018b09a in ffs_indirtrunc (ip=0xe3e50500, lbn=-12, dbn=394248, 
    lastbn=-1, level=0, countp=0xdfbffd9c) at ../../ufs/ffs/ffs_inode.c:500
#4  0xe018aac8 in ffs_truncate (ap=0xdfbffe74) at ../../ufs/ffs/ffs_inode.c:317
#5  0xe018e6a5 in ufs_inactive (ap=0xdfbffea0) at vnode_if.h:1003
#6  0xe012fb3f in vrele (vp=0xe3b12800) at vnode_if.h:699
#7  0xe012fa33 in vput (vp=0xe3b12800) at ../../kern/vfs_subr.c:858
#8  0xe0191e80 in ufs_remove (ap=0xdfbffef4) at ../../ufs/ufs/ufs_vnops.c:697
#9  0xe0131d25 in unlink (p=0xe4dc6e00, uap=0xdfbfff94, retval=0xdfbfff84)
    at vnode_if.h:459
#10 0xe01ac1ff in syscall (frame={tf_es = 39, tf_ds = -541130713, tf_edi = 1, 
      tf_esi = 28736, tf_ebp = -541074456, tf_isp = -541065244, 
      tf_ebx = 28944, tf_edx = 0, tf_ecx = 41472, tf_eax = 10, tf_trapno = 7, 
      tf_err = 7, tf_eip = 268950145, tf_cs = 31, tf_eflags = 582, 
      tf_esp = -541074568, tf_ss = 39}) at ../../i386/i386/trap.c:890
#11 0x1007da81 in ?? ()
#12 0x2453 in ?? ()
#13 0x2914 in ?? ()
#14 0x1095 in ?? ()

fsck -y /var/spool/news:
** /dev/rccd0c
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=12450 (152 should be 0)
CORRECT? yes

** Phase 2 - Check Pathnames
UNALLOCATED  I=12447  OWNER=news MODE=0
SIZE=0 MTIME=Dec 15 21:35 1997
NAME=/relcom/netnews/big/11105

REMOVE? yes

UNALLOCATED  I=12448  OWNER=news MODE=0
SIZE=0 MTIME=Dec 15 21:35 1997
NAME=/relcom/netnews/big/11107

REMOVE? yes

UNALLOCATED  I=12449  OWNER=news MODE=0
SIZE=0 MTIME=Dec 15 21:35 1997
NAME=/relcom/nennews/big/11108

REMOVE? yes

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT FILE I=12450 OWNER=news MODE=100664
SIZE=0 MTIME=Dec 15 21:35 1997  COUNT 0 SHOULD BE 1
ADJUST? yes

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLOCK
SALVAGE? yes

BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes

CLEAN FLAG NOT SET IN SUPERBLOCK
FIX? yes

I don't have any ahc and kernel error and warning messages,
the clean news spool.

I have crash dump image and may put it on my ftp server or download
it on any server (512M).

From owner-freebsd-hackers  Tue Dec 16 06:52:23 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA29475
          for hackers-outgoing; Tue, 16 Dec 1997 06:52:23 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from kai.communique.net (Kai.communique.net [204.27.67.90])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA29462
          for ; Tue, 16 Dec 1997 06:52:14 -0800 (PST)
          (envelope-from nectar@kai.communique.net)
Received: (from smap@localhost)
	by kai.communique.net (8.8.8/8.8.7) id IAA01047;
	Tue, 16 Dec 1997 08:56:00 -0600 (CST)
Message-Id: <199712161456.IAA01047@kai.communique.net>
X-Authentication-Warning: kai.communique.net: smap set sender to  using -f
Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0)
	id xma001044; Tue, 16 Dec 97 08:55:43 -0600
From: Jacques Vidrine 
To: "David E. Cross" 
cc: Mike Smith , Johan Larsson ,
        Greg Lehey , Rob Nelson ,
        FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to:  
References: 
Date: Tue, 16 Dec 1997 08:55:43 -0600
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


I'll second that ... I've used FreeBSD for 3 years, and used almost
exclusively 3COM 3c509 cards for 10BaseT.  I'd guess that we have at
least 3 dozen boxes running with these cards, and they perform well.

We starting using the 3COM cards after having bad luck with NE2000
clone cards. *shrug*

Just wanted to point out that Your Mileage May Vary.

Jacques Vidrine 

On 15 December 1997 at 22:15, "David E. Cross"  wrote:
> On Tue, 16 Dec 1997, Mike Smith wrote:
> 
> > > 
> > > So my suggestion is that you _don't_ ship your computers with 3com cards,
> > > at least not the 509.
> > 
> > I'd have to ask why anyone would use a 3c509 when an NE2000 clone is 
> > cheaper, faster and better supported.
> > 
> > Alternatively, I'd have to wonder why anyone would contemplate shipping 
> > a hardware combination that they haven't tested extensively in-house 
> > first.
> > 
> 
> Ok... this I take offence at.. I have always had great troubles with the
> NE2000 cards and compatibles in all areas (from working to performance).
> I have 2 3c509s in my system, and have only had a problem once (Back with
> FreeBSD 2.1.5 I think, which got pulled because of the problem).  As for
> performance... I have done cross subnet installs with these cards and got
> a sustained (on a 1.5 Gigabyte file) transfer of 800 K Bytes per second
> (between 2 3c509s, across 2 subnets with other computers)... I am *very*
> pleased with these cards.  My understanding of the 'buggy' comment comes
> from the PNP nature of these cards.
> 
> --
> David Cross
> ACS Consultant
> 

From owner-freebsd-hackers  Tue Dec 16 07:35:15 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA02737
          for hackers-outgoing; Tue, 16 Dec 1997 07:35:15 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [209.49.144.254])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA02704
          for ; Tue, 16 Dec 1997 07:34:42 -0800 (PST)
          (envelope-from jamie@itribe.net)
Message-Id: <199712161528.KAA09023@gatekeeper.itribe.net>
Received: forwarded by SMTP 1.5.2.
Date: Tue, 16 Dec 1997 10:33:15 -0500 (EST)
From: Jamie Bowden 
To: John Kelly 
cc: FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-Reply-To: <34964c48.30733173@mail.cetlink.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 Tue, 16 Dec 1997, John Kelly wrote:

> On Mon, 15 Dec 1997 23:51:31 -0800 (PST), Tom  wrote:
> 
> >  Also, the ed driver supports shared memory cards like the SMC Ultra 16.
> >Fastest ISA ethernet you can get.
> 
> I replaced an NE2000 clone with a SMC Ultra 16, thinking shared memory
> would consume far less CPU than PIO with an NE2000.  But it seems to
> be about the same.
> 
> John

I have an NE2000 and an SMC Ultra Elite (8216T).  I can get a little over
a megabyte/sec throughput on the SMC.  The NE2000 seems to max out at
about 700 kilobyte/sec.

-- 
Jamie Bowden
Systems Administrator, iTRiBE.net

If we've got to fight over grep, sign me up.  But boggle can go.
	-Ted Faber (on Hasbro's request for removal of /usr/games/boggle)


From owner-freebsd-hackers  Tue Dec 16 07:36:27 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA02878
          for hackers-outgoing; Tue, 16 Dec 1997 07:36:27 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 HAA02862
          for ; Tue, 16 Dec 1997 07:36:20 -0800 (PST)
          (envelope-from dennis@etinc.com)
Received: from dbsys.etinc.com (dbsys.etinc.com [204.141.95.138]) by etinc.com (8.8.3/8.6.9) with SMTP id KAA04823 for ; Tue, 16 Dec 1997 10:40:07 -0500 (EST)
Message-Id: <3.0.32.19971216103907.00a96580@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 16 Dec 1997 10:39:08 -0500
To: hackers@freebsd.org
From: dennis 
Subject: ifconfig reports bogus netmask
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 chance of this getting fixed? Its been broken forever. I'm
talking about PTP interfaces, where the routes are inherently host
mask routes. ifconfig reports the natural mask or whatever you give
it....and its rather confusing trying to explain to the woodchucks that
its wrong.

Dennis

From owner-freebsd-hackers  Tue Dec 16 07:46:45 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA03778
          for hackers-outgoing; Tue, 16 Dec 1997 07:46:45 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA03765
          for ; Tue, 16 Dec 1997 07:46:19 -0800 (PST)
          (envelope-from rivers@dignus.com)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
          by elvis.vnet.net (8.8.8/8.8.4) with ESMTP
	  id KAA23232; Tue, 16 Dec 1997 10:46:05 -0500 (EST)
Received: from lakes.dignus.com (lakes [10.0.0.3])
	by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id LAA26046;
	Tue, 16 Dec 1997 11:08:26 -0500 (EST)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.7/8.6.9) id KAA13808; Tue, 16 Dec 1997 10:51:44 -0500 (EST)
Date: Tue, 16 Dec 1997 10:51:44 -0500 (EST)
From: Thomas David Rivers 
Message-Id: <199712161551.KAA13808@lakes.dignus.com>
To: ivt@gamma.ru, tlambert@primenet.com
Subject: Re: panic: blkfree: freeling free block/frag
Cc: freebsd-hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


"Igor Timkin"  writes:
> 
> Terry Lambert writes:
> > > Every 4-8 days my news server (~10 full incoming feeds, ~50
> > > outgoing feeds) crash:
> > > panic: blkfree: freeing free block
> > > or
> > > panic: blkfree: freeing free frag
> > 
> > Long Answer:
> > 
> > Generally, this type of problem means you should rebuild the news spool,
> > since *any* corruption could result in invalid information on the disk
> > that could result in a panic.
> > 
> > Most likely, you crashed once, and you expected fsck to do something
> > that it can't do reliably: recover an async mounted partition.  The
> > partition was "recovered" and marked clean, but when you reference
> > a particular disk metadata construct, it goes off into the weeds
> > because the recovery was imperfect.
> 
> Unfortunally, I still have this problem.
> I had make newfs 5 days ago. But yestarday I got the same panic
> (uptime 5.2 days):


Yep - this looks _exactly_ like my "daily panic" problem I had
on a full news feed... 

I wonder - did you happen to see John Dyson's recent post regarding
a small VM patch to 2.2.5.  It seems unrelated, but it could be a contributor
to the problem.  I haven't yet tried it on my stand-alone reproduction;
but it might be worthwhile for you to try.

A newfs, etc.. isn't going to fix this.  For example; you can probably
recreate it rather quickly by scribbling all over the disk (i.e.
write 0xff all over the partition), doing a newfs - which should initialize
things to their proper values, then doing an fsck to find out some
of the 0xff values incorrectly remain (that's my stand-alone reproduction.)

The "bug" - is that somehow a buffer is being incorrectly reused; but
it seems to be _very_ timing dependent.. when I put nice printf()s in the
kernel to try and track this down - the problem goes away.   Making it
extremely difficult to find...

I've demonstrated it on a aha1542, and a 2748, and a IDE disk drive, so
I don't believe it's hardware dependent (although the two SCSI versions
were with the same SCSI disk drive - the IDE one, of course, was not)
and with a 486 and a 386 and a 386sx.

Sorry I don't have good news to add - but I wanted to add my experiences
to help any curious readers...

Also - if anyone has time and feels like debugging this; I have
a serial-console setup on the machine that reproduces it.  I can
make accounts available to anyone to connect via the internet to this
setup and have a "whack" at it.   (i.e. log into the machine to which
the serial console is connected... )

	- Dave Rivers -



> 
> ivt@news:/var/tmp/innfeed:2:306>gdb -k /sys/compile/NEWS/kernel /usr/local/news/crash/vmcore.1
> GDB is free software and you are welcome to distribute copies of it
>  under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.16 (i386-unknown-freebsd), 
> Copyright 1996 Free Software Foundation, Inc...
> IdlePTD 1f0000
> current pcb at 1d79c0
> panic: blkfree: freeing free block
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:266
> 266                                     dumppcb.pcb_cr3 = rcr3();
> (kgdb) where
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:266
> #1  0xe01105e2 in panic (fmt=0xe0188a85 "blkfree: freeing free block")
>     at ../../kern/kern_shutdown.c:390
> #2  0xe0188c57 in ffs_blkfree (ip=0xe3e50500, bno=10, size=4096)
>     at ../../ufs/ffs/ffs_alloc.c:1230
> #3  0xe018b09a in ffs_indirtrunc (ip=0xe3e50500, lbn=-12, dbn=394248, 
>     lastbn=-1, level=0, countp=0xdfbffd9c) at ../../ufs/ffs/ffs_inode.c:500
> #4  0xe018aac8 in ffs_truncate (ap=0xdfbffe74) at ../../ufs/ffs/ffs_inode.c:317
> #5  0xe018e6a5 in ufs_inactive (ap=0xdfbffea0) at vnode_if.h:1003
> #6  0xe012fb3f in vrele (vp=0xe3b12800) at vnode_if.h:699
> #7  0xe012fa33 in vput (vp=0xe3b12800) at ../../kern/vfs_subr.c:858
> #8  0xe0191e80 in ufs_remove (ap=0xdfbffef4) at ../../ufs/ufs/ufs_vnops.c:697
> #9  0xe0131d25 in unlink (p=0xe4dc6e00, uap=0xdfbfff94, retval=0xdfbfff84)
>     at vnode_if.h:459
> #10 0xe01ac1ff in syscall (frame={tf_es = 39, tf_ds = -541130713, tf_edi = 1, 
>       tf_esi = 28736, tf_ebp = -541074456, tf_isp = -541065244, 
>       tf_ebx = 28944, tf_edx = 0, tf_ecx = 41472, tf_eax = 10, tf_trapno = 7, 
>       tf_err = 7, tf_eip = 268950145, tf_cs = 31, tf_eflags = 582, 
>       tf_esp = -541074568, tf_ss = 39}) at ../../i386/i386/trap.c:890
> #11 0x1007da81 in ?? ()
> #12 0x2453 in ?? ()
> #13 0x2914 in ?? ()
> #14 0x1095 in ?? ()


From owner-freebsd-hackers  Tue Dec 16 07:59:17 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA04629
          for hackers-outgoing; Tue, 16 Dec 1997 07:59:17 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA04261
          for ; Tue, 16 Dec 1997 07:54:01 -0800 (PST)
          (envelope-from perlsta@cs.sunyit.edu)
Received: from localhost (perlsta@localhost)
	by server.local.sunyit.edu (8.8.8/8.8.5) with SMTP id KAA13718;
	Tue, 16 Dec 1997 10:57:30 -0500 (EST)
X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs
Date: Tue, 16 Dec 1997 10:57:29 -0500 (EST)
From: Alfred Perlstein 
X-Sender: perlsta@server.local.sunyit.edu
To: Igor Timkin 
cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG
Subject: Re: panic: blkfree: freeling free block/frag
In-Reply-To: <199712161442.RAA24936@crocus.gamma.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

if possible try new ram/cache, or maybe motherboard....
check your heat situation...


On Tue, 16 Dec 1997, Igor Timkin wrote:

> Terry Lambert writes:
> > > Every 4-8 days my news server (~10 full incoming feeds, ~50
> > > outgoing feeds) crash:
> > > panic: blkfree: freeing free block
> > > or
> > > panic: blkfree: freeing free frag
> > 
> > Long Answer:
> > 
> > Generally, this type of problem means you should rebuild the news spool,
> > since *any* corruption could result in invalid information on the disk
> > that could result in a panic.
> > 
> > Most likely, you crashed once, and you expected fsck to do something
> > that it can't do reliably: recover an async mounted partition.  The
> > partition was "recovered" and marked clean, but when you reference
> > a particular disk metadata construct, it goes off into the weeds
> > because the recovery was imperfect.
> 
> Unfortunally, I still have this problem.
> I had make newfs 5 days ago. But yestarday I got the same panic
> (uptime 5.2 days):
> 
> ivt@news:/var/tmp/innfeed:2:306>gdb -k /sys/compile/NEWS/kernel /usr/local/news/crash/vmcore.1
> GDB is free software and you are welcome to distribute copies of it
>  under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.16 (i386-unknown-freebsd), 
> Copyright 1996 Free Software Foundation, Inc...
> IdlePTD 1f0000
> current pcb at 1d79c0
> panic: blkfree: freeing free block
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:266
> 266                                     dumppcb.pcb_cr3 = rcr3();
> (kgdb) where
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:266
> #1  0xe01105e2 in panic (fmt=0xe0188a85 "blkfree: freeing free block")
>     at ../../kern/kern_shutdown.c:390
> #2  0xe0188c57 in ffs_blkfree (ip=0xe3e50500, bno=10, size=4096)
>     at ../../ufs/ffs/ffs_alloc.c:1230
> #3  0xe018b09a in ffs_indirtrunc (ip=0xe3e50500, lbn=-12, dbn=394248, 
>     lastbn=-1, level=0, countp=0xdfbffd9c) at ../../ufs/ffs/ffs_inode.c:500
> #4  0xe018aac8 in ffs_truncate (ap=0xdfbffe74) at ../../ufs/ffs/ffs_inode.c:317
> #5  0xe018e6a5 in ufs_inactive (ap=0xdfbffea0) at vnode_if.h:1003
> #6  0xe012fb3f in vrele (vp=0xe3b12800) at vnode_if.h:699
> #7  0xe012fa33 in vput (vp=0xe3b12800) at ../../kern/vfs_subr.c:858
> #8  0xe0191e80 in ufs_remove (ap=0xdfbffef4) at ../../ufs/ufs/ufs_vnops.c:697
> #9  0xe0131d25 in unlink (p=0xe4dc6e00, uap=0xdfbfff94, retval=0xdfbfff84)
>     at vnode_if.h:459
> #10 0xe01ac1ff in syscall (frame={tf_es = 39, tf_ds = -541130713, tf_edi = 1, 
>       tf_esi = 28736, tf_ebp = -541074456, tf_isp = -541065244, 
>       tf_ebx = 28944, tf_edx = 0, tf_ecx = 41472, tf_eax = 10, tf_trapno = 7, 
>       tf_err = 7, tf_eip = 268950145, tf_cs = 31, tf_eflags = 582, 
>       tf_esp = -541074568, tf_ss = 39}) at ../../i386/i386/trap.c:890
> #11 0x1007da81 in ?? ()
> #12 0x2453 in ?? ()
> #13 0x2914 in ?? ()
> #14 0x1095 in ?? ()
> 
> fsck -y /var/spool/news:
> ** /dev/rccd0c
> ** Phase 1 - Check Blocks and Sizes
> INCORRECT BLOCK COUNT I=12450 (152 should be 0)
> CORRECT? yes
> 
> ** Phase 2 - Check Pathnames
> UNALLOCATED  I=12447  OWNER=news MODE=0
> SIZE=0 MTIME=Dec 15 21:35 1997
> NAME=/relcom/netnews/big/11105
> 
> REMOVE? yes
> 
> UNALLOCATED  I=12448  OWNER=news MODE=0
> SIZE=0 MTIME=Dec 15 21:35 1997
> NAME=/relcom/netnews/big/11107
> 
> REMOVE? yes
> 
> UNALLOCATED  I=12449  OWNER=news MODE=0
> SIZE=0 MTIME=Dec 15 21:35 1997
> NAME=/relcom/nennews/big/11108
> 
> REMOVE? yes
> 
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> LINK COUNT FILE I=12450 OWNER=news MODE=100664
> SIZE=0 MTIME=Dec 15 21:35 1997  COUNT 0 SHOULD BE 1
> ADJUST? yes
> 
> ** Phase 5 - Check Cyl groups
> FREE BLK COUNT(S) WRONG IN SUPERBLOCK
> SALVAGE? yes
> 
> BLK(S) MISSING IN BIT MAPS
> SALVAGE? yes
> 
> SUMMARY INFORMATION BAD
> SALVAGE? yes
> 
> CLEAN FLAG NOT SET IN SUPERBLOCK
> FIX? yes
> 
> I don't have any ahc and kernel error and warning messages,
> the clean news spool.
> 
> I have crash dump image and may put it on my ftp server or download
> it on any server (512M).
> 


From owner-freebsd-hackers  Tue Dec 16 08:19:32 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA06021
          for hackers-outgoing; Tue, 16 Dec 1997 08:19:32 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from mail.award.de (mail.award.de [195.30.16.205])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA06010
          for ; Tue, 16 Dec 1997 08:19:19 -0800 (PST)
          (envelope-from timog@mail.award.de)
Received: (qmail 4811 invoked by uid 1015); 16 Dec 1997 16:08:51 -0000
Message-ID: <19971216170851.08240@mail.award.de>
Date: Tue, 16 Dec 1997 17:08:51 +0100
From: tg@award.de
To: hackers@freebsd.org
Subject: JDK port, anyone ?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
Reply_To: 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Everybody,
I seem to remember somebody complaining that there was no 'real' JDK-1.1
available for FreeBSD. As I'm also a little impaired by the lack of a 1.1
JDK, so I was wondering if somebody was currently working on a port. If not,
I might volunteer to do one. Oops, accidentally used the 'v' word :-).
However the usual lack of time, the usual work commitments etc. blah blah
mean that I would not be able to start before the end of January.
Before I start, I would actually like to get some answers to the following 
questions:
- Is there any interest for such a port? Considering my usual state of
  overworkedness, such an undertaking should make sense to more people than
  just myself. I can *probably* live with using the Linux port.

- Any others that are interested in joining this effort?

- Other comments and suggestions are welcone, of course.

BTW, please cc me on any mails as I don't currently subscribe to -hackers from
this account. Changing jobs in the next two weeks would otherwise mean that I
loose all the mail to hackers.

Timo

From owner-freebsd-hackers  Tue Dec 16 09:22:14 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA11001
          for hackers-outgoing; Tue, 16 Dec 1997 09:22:14 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10985
          for ; Tue, 16 Dec 1997 09:21:49 -0800 (PST)
          (envelope-from fullermd@futuresouth.com)
Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21])
	by shell.futuresouth.com (8.8.8/8.8.8) with SMTP id LAA01172;
	Tue, 16 Dec 1997 11:20:50 -0600 (CST)
Date: Tue, 16 Dec 1997 11:20:49 -0600 (CST)
From: "Matthew D. Fuller" 
To: Jacques Vidrine 
cc: "David E. Cross" , Mike Smith ,
        Johan Larsson , Greg Lehey ,
        Rob Nelson , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-Reply-To: <199712161456.IAA01047@kai.communique.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 Dec 1997, Jacques Vidrine wrote:

> 
> I'll second that ... I've used FreeBSD for 3 years, and used almost
> exclusively 3COM 3c509 cards for 10BaseT.  I'd guess that we have at
> least 3 dozen boxes running with these cards, and they perform well.
> 
> We starting using the 3COM cards after having bad luck with NE2000
> clone cards. *shrug*
> 
> Just wanted to point out that Your Mileage May Vary.

Here's my (probably useless, but oh well) $0.02.
I've got 2 systems here; one's my Cyrix 6x86 166, which presently has a
3C905 card locked in 10 Mbps mode, and the other's my friend's 486 SX33,
which has my 3C509 in it.  Testing a quick ftp transfer here...
Downloading to the 486, I have (polled from top):
 3537 fullermd  3   0   480K   636K ttyin    0:16 68.66% 53.37% ftp
for this:
ftp> get long.file
local: long.file remote: long.file
200 PORT command successful.
150 Opening BINARY mode data connection for 'long.file' (7964976 bytes).
226 Transfer complete.
7964976 bytes received in 17.26 seconds (450.56 Kbytes/s)
ftp> 

the 486 is a slow computer, so most transfers will prob be a fair bit
faster.  Again, Your Mileage May Vary

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
|       FreeBSD; the way computers were meant to be       |
* "The only reason I'm burning my candle at both ends, is *
| that I haven't figured out how to light the middle yet."|
*    fullermd@futuresouth.com      :-}  MAtthew Fuller    *
|      http://keystone.westminster.edu/~fullermd          |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



From owner-freebsd-hackers  Tue Dec 16 09:37:20 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA12050
          for hackers-outgoing; Tue, 16 Dec 1997 09:37:20 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA11726
          for ; Tue, 16 Dec 1997 09:31:44 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA00532;
	Tue, 16 Dec 1997 10:31:13 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id KAA08730; Tue, 16 Dec 1997 10:31:11 -0700
Date: Tue, 16 Dec 1997 10:31:11 -0700
Message-Id: <199712161731.KAA08730@mt.sri.com>
From: Nate Williams 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: tg@award.de
Cc: hackers@freebsd.org
Subject: Re: JDK port, anyone ?
In-Reply-To: <19971216170851.08240@mail.award.de>
References: <19971216170851.08240@mail.award.de>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> I seem to remember somebody complaining that there was no 'real' JDK-1.1
> available for FreeBSD. As I'm also a little impaired by the lack of a 1.1
> JDK, so I was wondering if somebody was currently working on a port.

Actually, there *is* a JDK1.1 port available for FreeBSD, but not a
latter port.  However, diffs to JDK1.1.2 were just made available, see
the freebsd-java mailing list.

> If not,
> I might volunteer to do one. Oops, accidentally used the 'v' word :-).
> However the usual lack of time, the usual work commitments etc. blah blah
> mean that I would not be able to start before the end of January.

I resemble that remark. :)

> Before I start, I would actually like to get some answers to the following 
> questions:
> - Is there any interest for such a port? Considering my usual state of
>   overworkedness, such an undertaking should make sense to more people than
>   just myself. I can *probably* live with using the Linux port.

Of course.  However, the Linux port may work much better now due to
recent bugfixes in the Linuxulator. :)

> - Any others that are interested in joining this effort?

Sure, check out freebsd-java@FreeBSD.org

> - Other comments and suggestions are welcone, of course.

I'm currently building a JDK1.1.2 port using the patches posted about in
the java mailing list, but it won't be distributable due to Motif
licensing.  I hope to somehow fix that, but it just depends on the
weather.  If it's snows a whole bunch then I'll be outside playing it,
but if the weather is as yucky as it is now over Christmas (40 degrees
and brown) then I'll probably spend more time inside. :(



Nate

From owner-freebsd-hackers  Tue Dec 16 09:45:49 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA12722
          for hackers-outgoing; Tue, 16 Dec 1997 09:45:49 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from mail.award.de (mail.award.de [195.30.16.205])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA12568
          for ; Tue, 16 Dec 1997 09:43:35 -0800 (PST)
          (envelope-from timog@mail.award.de)
Received: (qmail 7170 invoked by uid 1015); 16 Dec 1997 17:32:54 -0000
Message-ID: <19971216183254.08680@mail.award.de>
Date: Tue, 16 Dec 1997 18:32:54 +0100
From: tg@award.de
To: Nate Williams 
Cc: hackers@freebsd.org
Subject: Re: JDK port, anyone ?
References: <19971216170851.08240@mail.award.de> <199712161731.KAA08730@mt.sri.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: <199712161731.KAA08730@mt.sri.com>; from Nate Williams on Tue, Dec 16, 1997 at 10:31:11AM -0700
Reply_To: 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, Dec 16, 1997 at 10:31:11AM -0700, Nate Williams wrote:
> > I seem to remember somebody complaining that there was no 'real' JDK-1.1
> > available for FreeBSD. As I'm also a little impaired by the lack of a 1.1
> > JDK, so I was wondering if somebody was currently working on a port.
> 
> Actually, there *is* a JDK1.1 port available for FreeBSD, but not a
> latter port.  However, diffs to JDK1.1.2 were just made available, see
> the freebsd-java mailing list.

I know about the port, I've seen it. Unfortunately it doesn't sport a debugger,
even if it is only jdb. Without a debugger, it's back to using 1.0.2 or Linux 
JDK. Also, I was actually thinking of porting 1.1.5, if I can get that one from
sun.
 
> > If not,
> > I might volunteer to do one. Oops, accidentally used the 'v' word :-).
> > However the usual lack of time, the usual work commitments etc. blah blah
> > mean that I would not be able to start before the end of January.
> 
> I resemble that remark. :)
> 
> > Before I start, I would actually like to get some answers to the following 
> > questions:
> > - Is there any interest for such a port? Considering my usual state of
> >   overworkedness, such an undertaking should make sense to more people than
> >   just myself. I can *probably* live with using the Linux port.
> 
> Of course.  However, the Linux port may work much better now due to
> recent bugfixes in the Linuxulator. :)


> > - Any others that are interested in joining this effort?
> 
> Sure, check out freebsd-java@FreeBSD.org

Yet another freebsd mailing list that I missed. Thanks. Will subscribe later.

> > - Other comments and suggestions are welcone, of course.
> 
> I'm currently building a JDK1.1.2 port using the patches posted about in
> the java mailing list, but it won't be distributable due to Motif
> licensing.  I hope to somehow fix that, but it just depends on the
> weather.  If it's snows a whole bunch then I'll be outside playing it,
> but if the weather is as yucky as it is now over Christmas (40 degrees
> and brown) then I'll probably spend more time inside. :(

Did you check if lesstif might work? I've found it quite useful. But of course
lesstif break GNU emacs if you build it with lesstif, but that's probably not
a comment on the stability of lesstif (Just to follow up another thread...).

Timo

From owner-freebsd-hackers  Tue Dec 16 09:49:06 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA13100
          for hackers-outgoing; Tue, 16 Dec 1997 09:49:06 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA13091
          for ; Tue, 16 Dec 1997 09:49:00 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA00659;
	Tue, 16 Dec 1997 10:48:56 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id KAA08788; Tue, 16 Dec 1997 10:48:50 -0700
Date: Tue, 16 Dec 1997 10:48:50 -0700
Message-Id: <199712161748.KAA08788@mt.sri.com>
From: Nate Williams 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: tg@award.de
Cc: Nate Williams , hackers@freebsd.org
Subject: Re: JDK port, anyone ?
In-Reply-To: <19971216183254.08680@mail.award.de>
References: <19971216170851.08240@mail.award.de>
	<199712161731.KAA08730@mt.sri.com>
	<19971216183254.08680@mail.award.de>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > I seem to remember somebody complaining that there was no 'real' JDK-1.1
> > > available for FreeBSD. As I'm also a little impaired by the lack of a 1.1
> > > JDK, so I was wondering if somebody was currently working on a port.
> > 
> > Actually, there *is* a JDK1.1 port available for FreeBSD
...

> I know about the port, I've seen it. Unfortunately it doesn't sport a
> debugger, even if it is only jdb.

In reality, having used almost *every* Java development environment out
there (including Cafe, VCafe, JWS 1.0, JWS 2.0, JBuilder, jdb, and
others too numerous to mention) there is no such thing as a *working*
debugger for Java. :(

System.out.println is your friend. :)

> using 1.0.2 or Linux JDK. Also, I was actually thinking of porting
> 1.1.5, if I can get that one from sun.

I just got my copy yesterday after sending in the non-commercial
license.

> > > - Any others that are interested in joining this effort?
> > 
> > Sure, check out freebsd-java@FreeBSD.org
> 
> Yet another freebsd mailing list that I missed. Thanks. Will subscribe later.

This is a new one, so don't feel too bad.

> > > - Other comments and suggestions are welcone, of course.
> > 
> > I'm currently building a JDK1.1.2 port using the patches posted about in
> > the java mailing list, but it won't be distributable due to Motif
> > licensing.  I hope to somehow fix that, but it just depends on the
> > weather.  If it's snows a whole bunch then I'll be outside playing it,
> > but if the weather is as yucky as it is now over Christmas (40 degrees
> > and brown) then I'll probably spend more time inside. :(

> 
> Did you check if lesstif might work? I've found it quite useful. But of course
> lesstif break GNU emacs if you build it with lesstif, but that's probably not
> a comment on the stability of lesstif (Just to follow up another thread...).

The port I have that uses Lesstif breaks stuff all over the place.
Since I make my living doing Java work *AND* I have a Motif license, I
don't have time to mess with Lesstif bugs.  But, if/when I get a more
recent version ported I'll try to make a public version.



Nate

From owner-freebsd-hackers  Tue Dec 16 10:58:30 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA18408
          for hackers-outgoing; Tue, 16 Dec 1997 10:58:30 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA18385
          for ; Tue, 16 Dec 1997 10:58:19 -0800 (PST)
          (envelope-from rivers@dignus.com)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
          by elvis.vnet.net (8.8.8/8.8.4) with ESMTP
	  id NAA22730; Tue, 16 Dec 1997 13:57:40 -0500 (EST)
Received: from lakes.dignus.com (lakes [10.0.0.3])
	by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id OAA26789;
	Tue, 16 Dec 1997 14:20:06 -0500 (EST)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.7/8.6.9) id OAA14117; Tue, 16 Dec 1997 14:03:20 -0500 (EST)
Date: Tue, 16 Dec 1997 14:03:20 -0500 (EST)
From: Thomas David Rivers 
Message-Id: <199712161903.OAA14117@lakes.dignus.com>
To: nate@mt.sri.com, tg@award.de
Subject: Re: JDK port, anyone ?
Cc: hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> > I know about the port, I've seen it. Unfortunately it doesn't sport a
> > debugger, even if it is only jdb.
> 
> In reality, having used almost *every* Java development environment out
> there (including Cafe, VCafe, JWS 1.0, JWS 2.0, JBuilder, jdb, and
> others too numerous to mention) there is no such thing as a *working*
> debugger for Java. :(
> 
> System.out.println is your friend. :)
> 

 I can assure you that some people are working closely with Sun
 on improving this very problem...

	- Dave Rivers -


From owner-freebsd-hackers  Tue Dec 16 11:03:10 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA18844
          for hackers-outgoing; Tue, 16 Dec 1997 11:03:10 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA18836
          for ; Tue, 16 Dec 1997 11:02:52 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA01222;
	Tue, 16 Dec 1997 12:02:43 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id MAA09344; Tue, 16 Dec 1997 12:02:41 -0700
Date: Tue, 16 Dec 1997 12:02:41 -0700
Message-Id: <199712161902.MAA09344@mt.sri.com>
From: Nate Williams 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Thomas David Rivers 
Cc: nate@mt.sri.com, tg@award.de, hackers@FreeBSD.ORG
Subject: Re: JDK port, anyone ?
In-Reply-To: <199712161903.OAA14117@lakes.dignus.com>
References: <199712161903.OAA14117@lakes.dignus.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > > I know about the port, I've seen it. Unfortunately it doesn't sport a
> > > debugger, even if it is only jdb.
> > 
> > In reality, having used almost *every* Java development environment out
> > there (including Cafe, VCafe, JWS 1.0, JWS 2.0, JBuilder, jdb, and
> > others too numerous to mention) there is no such thing as a *working*
> > debugger for Java. :(
> > 
> > System.out.println is your friend. :)
> > 
> 
>  I can assure you that some people are working closely with Sun
>  on improving this very problem...

I'm glad to hear it, but given the 'state of the art' in Thread
debuggers, forgive me for not being too terribly optimistic that
anything significant will happen within the next 6-12 months.



Nate

From owner-freebsd-hackers  Tue Dec 16 11:03:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA18972
          for hackers-outgoing; Tue, 16 Dec 1997 11:03:51 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA18425
          for ; Tue, 16 Dec 1997 10:58:34 -0800 (PST)
          (envelope-from tlambert@usr01.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id MAA15863;
	Tue, 16 Dec 1997 12:04:43 -0700 (MST)
Received: from usr01.primenet.com(206.165.6.201)
 via SMTP by smtp03.primenet.com, id smtpd015833; Tue Dec 16 12:04:38 1997
Received: (from tlambert@localhost)
	by usr01.primenet.com (8.8.5/8.8.5) id LAA18094;
	Tue, 16 Dec 1997 11:47:57 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712161847.LAA18094@usr01.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: daniel_sobral@voga.com.br
Date: Tue, 16 Dec 1997 18:47:57 +0000 (GMT)
Cc: tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <8325656F.0038C91F.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 16, 97 07:52:31 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > The existance of mutually exclusive drivers is not friendly.
> 
> Agreed. But do not forget that mutual exclusion is not the only thing being
> discussed here. You said prerequisites are not useful either.

No.  I said prerequisites could be automatically handled by the KLD
code, and so they are not necessary to specify in a kernel config.
This is very different than say they are not useful (frankly, with
the number of appeals I've made for graphical soloutions to problems,
I'm surprised you could even think I meant that ;-)).


> > There are two types of exclusion:
> 
> > 1) Screw up: the driver probes are antagonistic to other
> > hardware.  This should be fixed by changing the probe
> > code.
> 
> This may not always be fixed, as far as legacy hardware goes.

So far, it's always been fixable with probe order.  Probe order can
be specified using a priority field in the data in the driver image
itself, and doesn't require a config file (or us one, in fact; the
priority for the LANCE probe in the GENERIC image, for example).


> > 2) Screw up: there is more than one driver for the given
> > hardware.  This should be fixed by integration.
> >
> > Your console example falls into #2, and Johnathan Mini is working
> > on fixing it.
> >
> > Do you have other examples?
> 
> Since you disregarded my RL examples as "will be fixed in the future", I'll
> bring something from the future to haunt you... :-)
> 
> FreeBSD creates a driver for device X. Third-party commercial vendor
> creates another driver for the same device X. Thus, you cannot help but say
> "hey, use _this_ driver instead of the other one".
> 
> Now, just so you don't forget, below we discuss mutual exclusions _and_
> prerequisites.
> 
> > > That would kind of work. Except... that structure does not have the
> > > semantic content for which it is being used, meaning that:
> >
> > > 1) If the need later arises for the correct structure, we'll be
> > >    left with the choice of modifying *all* previous structures
> > >    to the correct one (and we all know how hard such things are),
> > >    or using two different structures for the same end.
> >
> > This is why there needs to be an extensible schema mechanism (like that
> > of LDAP) instead of a binary structure based mechanism for doing this
> > sort of thing.
> >
> > This is why God invented Directories.
> 
> That is not the point. We use your solution to deal with "legacy" code that
> has not been "fixed" yet (assuming this is at all possible), and then we
> stumble on some other "mutually exclusive options" that _cannot_ be solved
> the way you proposed. We create the "mutual exclusion" structure to solve
> that problem, and end up with two different structures being used to solve
> the same problem. See 1) above.

The order of operation is dictated by the initialization order preference
data.  For your example of a third party driver to replace a FreeBSD
driver, the obvious answer is to give the third party driver a higher
priority.  If present, it will get to the hardware first, and the
FreeBSD driver's probe will fail, and it will be unloaded.

> As for "binary", I haven't said "binary", I haven't _thought_ "binary".
> When I say "structure", forget C's "struct". Structure as in "directories
> is a structure".

The idea that a structure change could not be forward compatible is
what implied binary.  If it's not binary, then a correct design
wll *always* be forward compatible.

Look at the sysinit_sub_id values for the order field in the file
/usr/include/sys/kernel.h.  When I first wrote the SYSINIT() code,
this is exactly the problem I was attempting to solve.  I believe I
*did* solve the problem.


> > I think a kernel configurator will just prop up the existing bad
> > situation, and delay more correct change.
> 
> Not at all.
> 
> First, you have yet to show me that we can do without some kind of "what
> devices/features I want to be loaded/probed" configurator. I *don't have*
> PCI on my FreeBSD computer, so it is very easy for me to ignore any
> suggestion that precludes non-PCI hardware.

This is an easy answer.  You load all drivers for which their probe
routines in their ELF init sections probe "true".  Period.  If you
don't want to actually use the devices, then don't open their /dev
entries.  But you don't get a choice about the driver.

If the driver is not boot critical, and you don't want it loaded
(ie: an embedded system with a sound chip on the board but no
speakers attached, etc.), then don't put the module binary into
the directory where the kernel looks for module binaries.

This handles the "need/want to be loaded" cases.

Your kernel configurator is /bin/ln, /bin/rm, and /bin/cp.


> Second, I am not coding anything. Somebody else is, and this somebody
> choose to deal with the problem at this level. I'm just making suggestions
> in the hope that he won't screw up in the process he has choosen to deal
> with.

Well, fine.  But the concept of needing a kernel configurator itself
is what's flawed, and any suggestions about "what kind is needed" are
compounding that.  I'm just pointing that out in the hopes that someone
will not make it their life's work, only to find it dead on arrival,
since I expect these ELF dependent facilities to appear "soon".


> > > Terry, are you suggesting a backward compatibility hack (with
> > > tradition, not even code!) instead of doing the right thing???
> >
> > "Backward compatability hack"?  ELF archiver?
> >
> > What ELF system are *you* running on?!?
> 
> Elf? You said "rc.conf".

???

I think you have the wrong person.  I think rc.conf is an abomination
before God.  For one thing, it lives in a directory which, in my ideal
world, is mounted read-only.  So you wouldn't be able to "conf" the
thing anyway.

> You were talking about using sections instead of prerequisites to
> deal with the "history buffer only with syscon" problem.

Well, I think you don't need to tune the syscons buffer the way
you are presenting tuning it.  I think that if it's a tunable, it
should be a runtime tunable, and you should be able to access it
via a persistant MIB.  A directory.  If this is what got you
confused about rc.conf (many sysctl "MIB" tunables persistance are
kludged by existing in rc.conf now), then you misaprehended me.

> So, you propose a solution that does not deal directly with the
> problem, by stating explicitly "this only if that",

Yes.

> which has potential problems as shown above,

No.  Makefiles deal with these dependencies every day.  It's called
a topological sort.

> and say your solution has historical precedent, exemplifying with rc.conf.

No, exemplefied with "make", "tsort", "LDAP", the Windows NT and
Windows 95 registries, AIX, and NeXTStep's niload/nidump (this last's
failure of the "netinfo" mechanism derives from trying to make flat
files available at the same time without providing "vipw"-like
wrappers through which they must be editted.


> Terry, it would be more productive if you choose one of the two solutions
> you proposed:
> 
> 1) Don't. Kernel configuration should go away. (In this case, just stay
> away from the discussion, as it's about kernel configuration, like it or
> not)

Fine; but don't expect that the resulting code will be useful or used
in the near future when it becomes possible for us to dynamically load
kernel components, and to discard potentially boot-critical drivers
which are not in use.


> 2) Use this and that. (In this case, deal with the issues at hand instead
> of directing problems to your solution to 1)

Well, I presented my persepective on a framework in which a kernel
configurator is not necessary.  That's the future I advocate.  This
means that I oppose projects whose assumptions preclude such a future.
You can't expect me to not be vocal in this opposition.  The further
you go down the wrong road, the harder it's going to be to backtrack.


> > And the more you enhance it, the less likely that people will do anything
> > about moving the code forward in this area.  "Good Enough" is the enemy
> > of "Better".
> 
> That's a valid point of view, though I think it is flawed. Anyway, if
> that's your opinion, why are you discussing how the kernel configurator
> file should be structured?

I haven't.  I've only discussed how the problems you are attempting to
solve via a kernel configurator should be solved instead, so that they
require less user intervention, and do not violate the principle of
least astonishment.

I'm only voting, for cases where you require explicit dependencies,
that those dependencies aren't routed through a human being running
a kernel configurator to be resolved.


					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  Tue Dec 16 11:12:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA20013
          for hackers-outgoing; Tue, 16 Dec 1997 11:12:04 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from main.brewich.com (USR1-1.detnet.com [207.113.12.19] (may be forged))
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA19968
          for ; Tue, 16 Dec 1997 11:11:51 -0800 (PST)
          (envelope-from gclarkii@main.brewich.com)
Received: (from gclarkii@localhost)
	by main.brewich.com (8.8.7/8.8.5) id NAA01920;
	Tue, 16 Dec 1997 13:11:23 -0600 (CST)
From: Gary Clark II 
Message-Id: <199712161911.NAA01920@main.brewich.com>
Subject: Re: JDK port, anyone ?
To: nate@mt.sri.com (Nate Williams)
Date: Tue, 16 Dec 1997 13:11:23 -0600 (CST)
Cc: tg@award.de, hackers@freebsd.org
In-Reply-To: <199712161731.KAA08730@mt.sri.com> from Nate Williams at "Dec 16, 97 10:31:11 am"
X-Mailer: ELM [version 2.4ME+ PL22 (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

Nate Williams wrote:
--SNIP--
> 
> Actually, there *is* a JDK1.1 port available for FreeBSD, but not a
> latter port.  However, diffs to JDK1.1.2 were just made available, see
> the freebsd-java mailing list.

What about Alex's JDK-1.1.2 that is in incoming on ftp.freebsd.org?
If you already have motif (like I do), just replace lesstif with motif
and your pretty well ready to go.

--SNIP--

> 
> Nate
> 
> 


-- 
Gary Clark II   (N5VMF) |    I speak only for myself and "maybe" my company 
gclarkii@GBData.COM     |          Member of the FreeBSD Doc Team 
  Providing Internet and ISP startups - http://WWW.GBData.com for information
       FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/FAQ.latin1 

From owner-freebsd-hackers  Tue Dec 16 11:14:50 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA20307
          for hackers-outgoing; Tue, 16 Dec 1997 11:14:50 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA20286
          for ; Tue, 16 Dec 1997 11:14:39 -0800 (PST)
          (envelope-from tlambert@usr01.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id MAA21549;
	Tue, 16 Dec 1997 12:31:14 -0700 (MST)
Received: from usr01.primenet.com(206.165.6.201)
 via SMTP by smtp03.primenet.com, id smtpd021524; Tue Dec 16 12:31:09 1997
Received: (from tlambert@localhost)
	by usr01.primenet.com (8.8.5/8.8.5) id MAA19768;
	Tue, 16 Dec 1997 12:14:24 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712161914.MAA19768@usr01.primenet.com>
Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port
To: ada@bsd.org
Date: Tue, 16 Dec 1997 19:14:24 +0000 (GMT)
Cc: hackers@freebsd.org
In-Reply-To: <199712160839.TAA05709@noether.blah.org> from "Ada" at Dec 16, 97 07:39:58 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >   This type of dynamic loading of modules can't be implemented correctly until
> > we have a method of easily tracking resources dynamically. John-Mark's
> > bus/device system does this, and, based on my observations of he current
> > codebase, it is obvious (at least to me, YMMV) that this code is greatly
> > required.
> There is a fundamental problem between this and devfs:
> 
> if devfs waits for the driver to create device nodes, and the driver waits
> until its device entry is touched before it's loaded, how does the
> process begin?

The probe code is seperate from the code that implements what is being
probed for... it lives in a seperate ELF segment in the driver image.

Alternately, you load the driver, try the probe, and if it fails, you
discard the driver.  You can do this on a whole driver without needing
initial support for ELF sections seperating the probe code.

This presumes that in a post-link static kernel that drivers which may
be discarded live in their own sections.  This lets the kernel recover
the memory used by an unused static device.

If you have section tagging (preload,nonswappable) for boot critical
and swap path components, then the kernel loader can decide to load
only part of the kernel initially.  You could then also have the
scenario where you have all devices linked into the kernel, and the
kernel's disk footprint was much larger than the kernels memory footprint.
This is actually a less desirable scenario, however, since it means
that it's more difficult to dynamically add things like third party
drivers and FS's.


I personally have a preference for /libexec and /usr/libexec for
boot-path and non-boot-path components for things like file systems.

The boot FS must be statically linked for the kernel to be able to
find additional components, but after that, what's needed?  Basically,
a way to hook a new FS into the FS commands (mount/fsck/etc.) and
a way to get the code into the kernel on demand.

A probe=true is the definition of an "arrival event".


					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  Tue Dec 16 11:14:53 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA20319
          for hackers-outgoing; Tue, 16 Dec 1997 11:14:53 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA20298
          for ; Tue, 16 Dec 1997 11:14:47 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA01312;
	Tue, 16 Dec 1997 12:14:39 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id MAA09447; Tue, 16 Dec 1997 12:14:38 -0700
Date: Tue, 16 Dec 1997 12:14:38 -0700
Message-Id: <199712161914.MAA09447@mt.sri.com>
From: Nate Williams 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Gary Clark II 
Cc: nate@mt.sri.com (Nate Williams), tg@award.de, hackers@freebsd.org
Subject: Re: JDK port, anyone ?
In-Reply-To: <199712161911.NAA01920@main.brewich.com>
References: <199712161731.KAA08730@mt.sri.com>
	<199712161911.NAA01920@main.brewich.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > Actually, there *is* a JDK1.1 port available for FreeBSD, but not a
> > latter port.  However, diffs to JDK1.1.2 were just made available, see
> > the freebsd-java mailing list.
> 
> What about Alex's JDK-1.1.2 that is in incoming on ftp.freebsd.org?
> If you already have motif (like I do), just replace lesstif with motif
> and your pretty well ready to go.

Well, that one wasn't publicized, and I wasn't about to.

Also, you can't replace the lesstif library with Motif since it
apparently isn't binary compatible with a standard Motif library.  It
dies with internalization calls. :(



Nate

From owner-freebsd-hackers  Tue Dec 16 11:26:19 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA21374
          for hackers-outgoing; Tue, 16 Dec 1997 11:26:19 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 LAA21356
          for ; Tue, 16 Dec 1997 11:25:44 -0800 (PST)
          (envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id LAA26826; Tue, 16 Dec 1997 11:25:21 -0800 (PST)
To: tg@award.de
cc: hackers@FreeBSD.ORG
Subject: Re: JDK port, anyone ? 
In-reply-to: Your message of "Tue, 16 Dec 1997 17:08:51 +0100."
             <19971216170851.08240@mail.award.de> 
Date: Tue, 16 Dec 1997 11:25:21 -0800
Message-ID: <26823.882300321@time.cdrom.com>
From: "Jordan K. Hubbard" 
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Everybody,
> I seem to remember somebody complaining that there was no 'real' JDK-1.1
> available for FreeBSD. As I'm also a little impaired by the lack of a 1.1
> JDK, so I was wondering if somebody was currently working on a port. If not,

What's wrong with http://www.csi.uottawa.ca/~kwhite/javaport.html ?

From owner-freebsd-hackers  Tue Dec 16 11:33:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA21958
          for hackers-outgoing; Tue, 16 Dec 1997 11:33:42 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21934
          for ; Tue, 16 Dec 1997 11:33:31 -0800 (PST)
          (envelope-from tlambert@usr01.primenet.com)
Received: (from daemon@localhost)
	by smtp01.primenet.com (8.8.8/8.8.8) id MAA10409;
	Tue, 16 Dec 1997 12:19:20 -0700 (MST)
Received: from usr01.primenet.com(206.165.6.201)
 via SMTP by smtp01.primenet.com, id smtpd010386; Tue Dec 16 12:19:19 1997
Received: (from tlambert@localhost)
	by usr01.primenet.com (8.8.5/8.8.5) id MAA20145;
	Tue, 16 Dec 1997 12:19:15 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712161919.MAA20145@usr01.primenet.com>
Subject: Re: panic: blkfree: freeling free block/frag
To: ivt@gamma.ru (Igor Timkin)
Date: Tue, 16 Dec 1997 19:19:15 +0000 (GMT)
Cc: tlambert@primenet.com, ivt@gamma.ru, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199712161442.RAA24936@crocus.gamma.ru> from "Igor Timkin" at Dec 16, 97 05:42:10 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> ivt@news:/var/tmp/innfeed:2:306>gdb -k /sys/compile/NEWS/kernel /usr/local/news/crash/vmcore.1
> GDB is free software and you are welcome to distribute copies of it
>  under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.16 (i386-unknown-freebsd), 
> Copyright 1996 Free Software Foundation, Inc...
> IdlePTD 1f0000
> current pcb at 1d79c0
> panic: blkfree: freeing free block
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:266
> 266                                     dumppcb.pcb_cr3 = rcr3();
> (kgdb) where
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:266
> #1  0xe01105e2 in panic (fmt=0xe0188a85 "blkfree: freeing free block")
>     at ../../kern/kern_shutdown.c:390
> #2  0xe0188c57 in ffs_blkfree (ip=0xe3e50500, bno=10, size=4096)
>     at ../../ufs/ffs/ffs_alloc.c:1230
> #3  0xe018b09a in ffs_indirtrunc (ip=0xe3e50500, lbn=-12, dbn=394248, 
>     lastbn=-1, level=0, countp=0xdfbffd9c) at ../../ufs/ffs/ffs_inode.c:500
> #4  0xe018aac8 in ffs_truncate (ap=0xdfbffe74) at ../../ufs/ffs/ffs_inode.c:317
> #5  0xe018e6a5 in ufs_inactive (ap=0xdfbffea0) at vnode_if.h:1003
> #6  0xe012fb3f in vrele (vp=0xe3b12800) at vnode_if.h:699
> #7  0xe012fa33 in vput (vp=0xe3b12800) at ../../kern/vfs_subr.c:858
> #8  0xe0191e80 in ufs_remove (ap=0xdfbffef4) at ../../ufs/ufs/ufs_vnops.c:697
> #9  0xe0131d25 in unlink (p=0xe4dc6e00, uap=0xdfbfff94, retval=0xdfbfff84)
>     at vnode_if.h:459
> #10 0xe01ac1ff in syscall (frame={tf_es = 39, tf_ds = -541130713, tf_edi = 1, 
>       tf_esi = 28736, tf_ebp = -541074456, tf_isp = -541065244, 
>       tf_ebx = 28944, tf_edx = 0, tf_ecx = 41472, tf_eax = 10, tf_trapno = 7, 
>       tf_err = 7, tf_eip = 268950145, tf_cs = 31, tf_eflags = 582, 
>       tf_esp = -541074568, tf_ss = 39}) at ../../i386/i386/trap.c:890
> #11 0x1007da81 in ?? ()
> #12 0x2453 in ?? ()
> #13 0x2914 in ?? ()
> #14 0x1095 in ?? ()

Start at unlink, and look at the arguments all the way down to see
if they are reasonable.

When you find an unreasonable argument, go up one function, and look at
the contents of the auto variables.  See if they are corrupted.

Personally, I am not happy with the vnode/free block management in
FreeBSD, but there's nothing I can do about it to make it more
deterministic.  I'm pretty sure that the race windows have been
nailed closed by increased complexity, so it's probably something
else.


					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  Tue Dec 16 11:45:35 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA23142
          for hackers-outgoing; Tue, 16 Dec 1997 11:45:35 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA23096
          for ; Tue, 16 Dec 1997 11:45:12 -0800 (PST)
          (envelope-from kpielorz@caladan.tdx.co.uk)
Received: from localhost (kpielorz@localhost)
	by caladan.tdx.co.uk (8.8.5/8.8.5) with SMTP id TAA01279
	for ; Tue, 16 Dec 1997 19:24:48 GMT
Date: Tue, 16 Dec 1997 19:24:47 +0000 (GMT)
From: Karl Pielorz 
To: hackers@freebsd.org
Subject: Compiling Kernels on remote machine & using 'wrong' versions
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 All,

A quick question (which may have been better in questions- - but it's
kinda kernel related)...

I'm about to start writing a device driver to run under FreeBSD
2.2.5-Release - I have 2 machines, 1 very fast (P-Pro 233), and one very
slow (486-SX 33). The two are linked via NFS etc. To makes things even
more complex - the fast one is 2.2.2-Release and the slow one is
2.2.5-Release ;-)

Is there an easy way to Use the 'fast' machine to compile Kernels for the slow
machine (which is fairly quick at NFS) - if so - how? (for example the
slow machine appears as:

/home/phoenix/root
/home/phoenix/usr
/home/phoenix/usr2
/home/phoenix/var

Mounted on the Fast machine - is there some big global I can set to tell
the fast machine where to get all its sources from so that it will compile
2.2.5 Kernels? (i.e. using the /sys, /usr/src /usr/includes etc. from the
slow machine via NFS?)

- or -

Can I move all the /usr filesystem from the slow machine (phoenix)
physically to the fast machine - and have it compile kernels etc. from
there?

What I'm basically trying to do is have my cake and eat it - The hardware
the drivers for is on the slow machine, I want to keep my source either on
that machine (or the fast machine) - while using the fast one to crunch a
kernel - then spit it back to the slow machine for running etc...

Is this going to be easy? - or am I better either just moving the 2.2.2
machine up to 2.2.5 - or the 2.2.5 machine down to 2.2.2 (so they're all
running the same release?)

Final question - I accidentally booted the 2.2.5 system with a 2.2.2
kernel - it boots OK, and seems to run OK (yes, I can hear the screams of
'Noooohhh!!' from here) - but is it really that bad - considering I don't
really care about the fate of the slow 2.2.5 machine? - That way I can
keep all my stuff on the 2.2.2 machine (which is nicely, safely stable &
remote) - and just run the 2.2.5 on 2.2.2 kernels...

Sorry for the long post - theres probably a better way of explaining all
this, but I just can't find it ;-)

Regards,

Karl Pielorz



From owner-freebsd-hackers  Tue Dec 16 12:24:22 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA26433
          for hackers-outgoing; Tue, 16 Dec 1997 12:24:22 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26421
          for ; Tue, 16 Dec 1997 12:24:12 -0800 (PST)
          (envelope-from rb@gid.co.uk)
Received: from gid.co.uk (uucp@localhost)
          by isbalham.ist.co.uk (8.8.7/8.8.4) with UUCP
	  id UAA25048; Tue, 16 Dec 1997 20:21:08 GMT
Received: from [194.32.164.2] by seagoon.gid.co.uk; Tue, 16 Dec 1997 20:17:56 GMT
X-Sender: rb@194.32.164.1
Message-Id: 
In-Reply-To: 
References: <34964c48.30733173@mail.cetlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 16 Dec 1997 20:18:23 +0000
To: Andrew Gordon 
From: Bob Bishop 
Subject: Re: 3com 3c509 card
Cc: FreeBSD Hackers , Mike Smith ,
        John Kelly 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

At 11:59 am +0000 16/12/97, Andrew Gordon wrote:
>[...]However, the "EtherEZ" which has replaced the Ultra
>appears to be a bit of a lemon - giving rather inconsistent performance
>[etc]

I'd have to second that, but the 8216 isn't the fastest ISA ethernet. I've
found an NE2100 clone (lnc driver) beats it, but not by a whole lot.



--
Bob Bishop              (0118) 977 4017  international code +44 118
rb@gid.co.uk        fax (0118) 989 4254  between 0800 and 1800 UK



From owner-freebsd-hackers  Tue Dec 16 13:52:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA02891
          for hackers-outgoing; Tue, 16 Dec 1997 13:52:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA02865
          for ; Tue, 16 Dec 1997 13:52:00 -0800 (PST)
          (envelope-from helbig@Informatik.BA-Stuttgart.DE)
Received: (from helbig@localhost)
	by rvc1.informatik.ba-stuttgart.de (8.8.8/8.8.5) id WAA03783;
	Tue, 16 Dec 1997 22:23:52 +0100 (MET)
From: Wolfgang Helbig 
Message-Id: <199712162123.WAA03783@rvc1.informatik.ba-stuttgart.de>
Subject: Re: Compiling Kernels on remote machine & using 'wrong' versions
In-Reply-To:  from Karl Pielorz at "Dec 16, 97 07:24:47 pm"
To: kpielorz@caladan.tdx.co.uk (Karl Pielorz)
Date: Tue, 16 Dec 1997 22:23:51 +0100 (MET)
Cc: hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL30 (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 All,
> 
> A quick question (which may have been better in questions- - but it's
> kinda kernel related)...
> 
> I'm about to start writing a device driver to run under FreeBSD
> 2.2.5-Release - I have 2 machines, 1 very fast (P-Pro 233), and one very
> slow (486-SX 33). The two are linked via NFS etc. To makes things even
> more complex - the fast one is 2.2.2-Release and the slow one is
> 2.2.5-Release ;-)
> 
> Is there an easy way to Use the 'fast' machine to compile Kernels for the slow
> machine (which is fairly quick at NFS) - if so - how? (for example the
> slow machine appears as:
> 
> /home/phoenix/root
> /home/phoenix/usr
> /home/phoenix/usr2
> /home/phoenix/var

Just build the kernel in /home/phoenix/usr/src/sys/compile/.
AFAIK, the sources below the usr/src/sys directory are used exclusively for
the kernel, regardless of the pathname of this directory.
You have to use the config(8) program from the target (i. e. slow) machine,
because the release of config and kernel sources should match.

> Final question - I accidentally booted the 2.2.5 system with a 2.2.2
> kernel - it boots OK, and seems to run OK (yes, I can hear the screams of
> 'Noooohhh!!' from here) - but is it really that bad - considering I don't

I don't here nothing :-) The 2.2.x releases are supposed to be
stable, i. e. in theory only bugfixes should make the difference
between 2.2.2 and 2.2.5 .  But ... running  a 2.2.2 kernel on a
2.2.5 machine is not tested very well, so your milage may vary.

> really care about the fate of the slow 2.2.5 machine? - That way I can
> keep all my stuff on the 2.2.2 machine (which is nicely, safely stable &
> remote) - and just run the 2.2.5 on 2.2.2 kernels...

Fine, go ahead.

Wolfgang

From owner-freebsd-hackers  Tue Dec 16 14:01:20 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA03812
          for hackers-outgoing; Tue, 16 Dec 1997 14:01:20 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA03782
          for ; Tue, 16 Dec 1997 14:01:12 -0800 (PST)
          (envelope-from avalon@coombs.anu.edu.au)
Message-Id: <199712162201.OAA03782@hub.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA205049510; Wed, 17 Dec 1997 08:58:30 +1100
From: Darren Reed 
Subject: Re: Why so many steps to build new kernel?
To: tlambert@primenet.com (Terry Lambert)
Date: Wed, 17 Dec 1997 08:58:30 +1100 (EDT)
Cc: daniel_sobral@voga.com.br, tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <199712161847.LAA18094@usr01.primenet.com> from "Terry Lambert" at Dec 16, 97 06:47:57 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from Terry Lambert, sie said:
> 
> > > The existance of mutually exclusive drivers is not friendly.
> > 
> > Agreed. But do not forget that mutual exclusion is not the only thing being
> > discussed here. You said prerequisites are not useful either.
> 
> No.  I said prerequisites could be automatically handled by the KLD
> code, and so they are not necessary to specify in a kernel config.
> This is very different than say they are not useful (frankly, with
> the number of appeals I've made for graphical soloutions to problems,
> I'm surprised you could even think I meant that ;-)).

Or you can try a kludge like solaris and have a symbol in a driver like
"_depends_on" specify any pre/co-requisites.

> > > There are two types of exclusion:
> > 
> > > 1) Screw up: the driver probes are antagonistic to other
> > > hardware.  This should be fixed by changing the probe
> > > code.
> > 
> > This may not always be fixed, as far as legacy hardware goes.
> 
> So far, it's always been fixable with probe order.  Probe order can
> be specified using a priority field in the data in the driver image
> itself, and doesn't require a config file (or us one, in fact; the
> priority for the LANCE probe in the GENERIC image, for example).

Bzzt.  You have to load all the drivers then, to determine all the
priorities so you can probe them in the correct order.  For small
memory machines, this might be somewhat of a problem when we get
to the stage of having megabytes of driver modules.

My suggestion would be to have knowledge of *some* drivers builtin
to the kernel and then have init load the rest in an order specified
by some file.  If the file is corrupt or shit happens, bailout and start
/sbin/sh.

> The order of operation is dictated by the initialization order preference
> data.  For your example of a third party driver to replace a FreeBSD
> driver, the obvious answer is to give the third party driver a higher
> priority.  If present, it will get to the hardware first, and the
> FreeBSD driver's probe will fail, and it will be unloaded.

How about just replacing the file (i.e. module) on the disk ?  Renaming
it, if you like.  That has worked for me in the past when dealing with
these sorts of problems.  Or if you have a config file which mentions
drivers to use, etc, you remove the FreeBSD one and add the 3rd party
one instead.

btw, I can see FreeBSD taking a long time to bootup...

> If the driver is not boot critical, and you don't want it loaded
> (ie: an embedded system with a sound chip on the board but no
> speakers attached, etc.), then don't put the module binary into
> the directory where the kernel looks for module binaries.

This solution also handles the multiple revisions of the same driver
problem.

> This handles the "need/want to be loaded" cases.
> 
> Your kernel configurator is /bin/ln, /bin/rm, and /bin/cp.

How about /bin/mv ?  It's a start, but a bit more would be nice.

> I haven't.  I've only discussed how the problems you are attempting to
> solve via a kernel configurator should be solved instead, so that they
> require less user intervention, and do not violate the principle of
> least astonishment.

How about the KISS approach ?  Or has that fallen out of favour ?

Darren

From owner-freebsd-hackers  Tue Dec 16 14:30:11 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA06546
          for hackers-outgoing; Tue, 16 Dec 1997 14:30:11 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 OAA06491
          for ; Tue, 16 Dec 1997 14:29:57 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id IAA27052;
          Wed, 17 Dec 1997 08:59:45 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971217085945.37164@lemis.com>
Date: Wed, 17 Dec 1997 08:59:45 +1030
From: Greg Lehey 
To: dennis 
Cc: hackers@FreeBSD.ORG
Subject: Re: ifconfig reports bogus netmask
References: <3.0.32.19971216103907.00a96580@etinc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <3.0.32.19971216103907.00a96580@etinc.com>; from dennis on Tue, Dec 16, 1997 at 10:39:08AM -0500
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, Dec 16, 1997 at 10:39:08AM -0500, dennis wrote:
>
> Is there any chance of this getting fixed? Its been broken forever. I'm
> talking about PTP interfaces, where the routes are inherently host
> mask routes. ifconfig reports the natural mask or whatever you give
> it....and its rather confusing trying to explain to the woodchucks that
> its wrong.

Well, ifconfig reports the net mask that is set.  And yes, it's
inappropriate for "real" point-to-point interfaces.  But it's not the
reporting that's wrong, it's the setting.  Just set all ones when
setting the interface, and you'll be OK.

I suppose I should mention that there's a sizeable minority who think
this is the way the net mask *should* be.  Maybe one of them will
explain, I keep forgetting.

Greg


From owner-freebsd-hackers  Tue Dec 16 15:43:56 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA11697
          for hackers-outgoing; Tue, 16 Dec 1997 15:43:56 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from main.brewich.com (USR1-1.detnet.com [207.113.12.24] (may be forged))
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA11686
          for ; Tue, 16 Dec 1997 15:43:34 -0800 (PST)
          (envelope-from gclarkii@main.brewich.com)
Received: (from gclarkii@localhost)
	by main.brewich.com (8.8.7/8.8.5) id RAA03586;
	Tue, 16 Dec 1997 17:43:10 -0600 (CST)
From: Gary Clark II 
Message-Id: <199712162343.RAA03586@main.brewich.com>
Subject: Re: JDK port, anyone ?
To: nate@mt.sri.com (Nate Williams)
Date: Tue, 16 Dec 1997 17:43:07 -0600 (CST)
Cc: nate@mt.sri.com, tg@award.de, hackers@FreeBSD.ORG
In-Reply-To: <199712161914.MAA09447@mt.sri.com> from Nate Williams at "Dec 16, 97 12:14:38 pm"
X-Mailer: ELM [version 2.4ME+ PL22 (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

Nate Williams wrote:
> > > Actually, there *is* a JDK1.1 port available for FreeBSD, but not a
> > > latter port.  However, diffs to JDK1.1.2 were just made available, see
> > > the freebsd-java mailing list.
> > 
> > What about Alex's JDK-1.1.2 that is in incoming on ftp.freebsd.org?
> > If you already have motif (like I do), just replace lesstif with motif
> > and your pretty well ready to go.
> 
> Well, that one wasn't publicized, and I wasn't about to.
I think he did publicize(sic) it...???

> 
> Also, you can't replace the lesstif library with Motif since it
> apparently isn't binary compatible with a standard Motif library.  It
> dies with internalization calls. :(
Well all the demos and what little code I have written all work fine
putting Motif 1.2.? in place of the lesstif library.

> 
> Nate

Gary


-- 
Gary Clark II   (N5VMF) |    I speak only for myself and "maybe" my company 
gclarkii@GBData.COM     |          Member of the FreeBSD Doc Team 

From owner-freebsd-hackers  Tue Dec 16 15:48:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA12276
          for hackers-outgoing; Tue, 16 Dec 1997 15:48:04 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 PAA12199
          for ; Tue, 16 Dec 1997 15:47:49 -0800 (PST)
          (envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
	id 0xi6Wp-0001G9-00; Tue, 16 Dec 1997 15:35:55 -0800
Date: Tue, 16 Dec 1997 15:35:48 -0800 (PST)
From: Tom 
To: Karl Pielorz 
cc: hackers@freebsd.org
Subject: Re: Compiling Kernels on remote machine & using 'wrong' versions
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 Dec 1997, Karl Pielorz wrote:

> Is there an easy way to Use the 'fast' machine to compile Kernels for the slow
> machine (which is fairly quick at NFS) - if so - how? (for example the
> slow machine appears as:

  Yes.  Kernel source will build from any directory, so that directory
could be anywhere.

  I build kernels on a development machine which is also an NFS server, so
I just mount the "sys" directory on the clients, and do a "make install"
to install.

> Final question - I accidentally booted the 2.2.5 system with a 2.2.2
> kernel - it boots OK, and seems to run OK (yes, I can hear the screams of
> 'Noooohhh!!' from here) - but is it really that bad - considering I don't
> really care about the fate of the slow 2.2.5 machine? - That way I can
> keep all my stuff on the 2.2.2 machine (which is nicely, safely stable &
> remote) - and just run the 2.2.5 on 2.2.2 kernels...

  Why are you doing development on 2.2.2 in the first place?

  All the 2.2 systems are somewhat compatible, but various programs that
poke around in kernel memory may die.

Tom


From owner-freebsd-hackers  Tue Dec 16 15:48:44 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA12399
          for hackers-outgoing; Tue, 16 Dec 1997 15:48:44 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 PAA12340
          for ; Tue, 16 Dec 1997 15:48:21 -0800 (PST)
          (envelope-from mrcpu@cdsnet.net)
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 PAA11364
	for ; Tue, 16 Dec 1997 15:48:20 -0800 (PST)
Date: Tue, 16 Dec 1997 15:48:20 -0800 (PST)
From: Jaye Mathisen  
To: hackers@freebsd.org
Subject: NFS thingamabob in 2.2.5-stable
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 get this message occasionally on my 2.2.5-stable box (supped like a few
days ago).

nfs_bioread: non vmio buf found, discarding


Don't know if it's critical.


From owner-freebsd-hackers  Tue Dec 16 15:59:01 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA13114
          for hackers-outgoing; Tue, 16 Dec 1997 15:59:01 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 PAA13063
          for ; Tue, 16 Dec 1997 15:58:14 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id KAA00272;
	Wed, 17 Dec 1997 10:22:43 +1030 (CST)
Message-Id: <199712162352.KAA00272@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: jak@cetlink.net (John Kelly)
cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Tue, 16 Dec 1997 09:57:47 GMT."
             <34974fcb.31632460@mail.cetlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Wed, 17 Dec 1997 10:22:42 +1030
From: Mike Smith 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA13093
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> On Tue, 16 Dec 1997 19:10:50 +1030, Mike Smith 
> wrote:
> 
> >> I replaced an NE2000 clone with a SMC Ultra 16, thinking shared memory
> >> would consume far less CPU than PIO with an NE2000.  But it seems to
> >> be about the same.
> >
> >About half.  Please don't confuse anecdotal evidence with measured 
> >results.
> >
> 
> I tested with an FTP transfer and consumed about 45% CPU in both
> cases.  
> 
> I wonder if I'm doing something wrong.

Well, for starters you aren't disclosing your measurement technique.  
It sounds to me as though it's not measuring the relative CPU consumed 
per bytes/datagrams transferred by the driver though.

All you have established is that a known ~50% improvement in the CPU 
utilisation of the driver has not affected the amount of CPU used for 
your FTP transfer.  This should tell you something about how efficient 
the driver is in the first place, especially compared with the other 
operations involved in the transfer.

First thing anyone should learn; how to measure things.  Whether you're 
talking engineering, physics, chemistry or computing; if you don't know 
what you're measuring, the numbers mean nothing.

Marketing, now that's a different story. 8)

mike



From owner-freebsd-hackers  Tue Dec 16 16:14:52 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA14209
          for hackers-outgoing; Tue, 16 Dec 1997 16:14:52 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 QAA14201
          for ; Tue, 16 Dec 1997 16:14:45 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id KAA00363;
	Wed, 17 Dec 1997 10:37:59 +1030 (CST)
Message-Id: <199712170007.KAA00363@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: ada@bsd.org
cc: hackers@FreeBSD.ORG
Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port 
In-reply-to: Your message of "Tue, 16 Dec 1997 19:39:58 +1100."
             <199712160839.TAA05709@noether.blah.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 10:37:58 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> There is a fundamental problem between this and devfs:

Nope. 8)

> if devfs waits for the driver to create device nodes, and the driver waits
> until its device entry is touched before it's loaded, how does the
> process begin?

The probe/attach code is in a separate section in the driver module.  
It's loaded and run based on the bus' probing policy (eg. PCI & PnP 
load/run on an ID match, ISA loads and probes based on config data), 
and then discarded.  This creates a lazy binding between the device 
nodes and the module object, which is resolved (the body of the module 
object is loaded) on first open.

The kernel should probably keep the module open to prevent it being 
deleted/unmounted, and the probe/attach will almost certainly leave 
data for each instance attached lying around.

This is consistent with the conceptual difference between "is it there" 
(probe/attach) and "I want to use it" (open).

mike



From owner-freebsd-hackers  Tue Dec 16 16:35:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA15937
          for hackers-outgoing; Tue, 16 Dec 1997 16:35:42 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 QAA15912
          for ; Tue, 16 Dec 1997 16:35:34 -0800 (PST)
          (envelope-from dennis@etinc.com)
Received: from dbsys.etinc.com (dbsys.etinc.com [204.141.95.138]) by etinc.com (8.8.3/8.6.9) with SMTP id TAA08325; Tue, 16 Dec 1997 19:39:13 -0500 (EST)
Message-Id: <3.0.32.19971216193810.00b3b480@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 16 Dec 1997 19:38:10 -0500
To: Greg Lehey 
From: dennis 
Subject: Re: ifconfig reports bogus netmask
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 08:59 AM 12/17/97 +1030, you wrote:
>On Tue, Dec 16, 1997 at 10:39:08AM -0500, dennis wrote:
>>
>> Is there any chance of this getting fixed? Its been broken forever. I'm
>> talking about PTP interfaces, where the routes are inherently host
>> mask routes. ifconfig reports the natural mask or whatever you give
>> it....and its rather confusing trying to explain to the woodchucks that
>> its wrong.
>
>Well, ifconfig reports the net mask that is set.  And yes, it's
>inappropriate for "real" point-to-point interfaces.  But it's not the
>reporting that's wrong, it's the setting.  Just set all ones when
>setting the interface, and you'll be OK.
>
>I suppose I should mention that there's a sizeable minority who think
>this is the way the net mask *should* be.  Maybe one of them will
>explain, I keep forgetting.

I disagree. The route is expicitly set by the command to be a host route, 
but the mask (and I'm talking about the case where no mask is specified
in the ifconfig) is set to the natural mask (class, that is). 

Even if you specifiy a non-host mask, a host route is set...if that is the
case then only a host mask should be allowed, and a host mask should
be forced. You SHOULD be able to override the host setting, that is, if a
mask is specified explicitly then the route should be set according to the
netmask.

Dennis

From owner-freebsd-hackers  Tue Dec 16 17:02:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA17977
          for hackers-outgoing; Tue, 16 Dec 1997 17:02:21 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 RAA17953
          for ; Tue, 16 Dec 1997 17:02:08 -0800 (PST)
          (envelope-from imp@village.org)
Received: from harmony [10.0.0.6] 
	by rover.village.org with esmtp (Exim 1.71 #1)
	id 0xi7sE-0000VY-00; Tue, 16 Dec 1997 18:02:06 -0700
Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id SAA00624 for ; Tue, 16 Dec 1997 18:02:13 -0700 (MST)
Message-Id: <199712170102.SAA00624@harmony.village.org>
To: hackers@freebsd.org
Subject: Question about making a new machine from an old one
Date: Tue, 16 Dec 1997 18:02:13 -0700
From: Warner Losh 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

OK.  I have a new machine I'd like to bring online.  I'd rather not
download the latest snapshot, but do have a complete -stable tree that
I just built that I'd like to place onto a disk and then boot that
disk on the new machine.

As near as I can tell, from looking at the makefiles, I would do
something like the following:

disklabel new-disk
newfs new-disk-a
newfs new-disk-d
newfs new-disk-e
newfs new-disk-f
mount new-disk-a /gerbils
mkdir /gerbils/usr /gerbils/var /gerbils/home
mount new-disk-d /gerbils/usr
mount new-disk-e /gerbils/var
mount new-disk-f /gerbils/home
cd /usr/src
make buildworld
cd /usr/src/etc
make distribution DESTDIR=/gerbils
cd ..
make installworld DESTDIR=/gerbils

umount /gerbils/{usr,home,var} /gerbils

Then take the disk to the new system and run /stand/sysinstall to
configure the system in single user.

Have I missed anything?  Is there an easier way to do this that
doesn't require that I grab a snapshot?  What's the smallest subset I
can install that would allow me to upgrade via make installworld?

Thanks much...

Warner

From owner-freebsd-hackers  Tue Dec 16 17:09:22 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA18655
          for hackers-outgoing; Tue, 16 Dec 1997 17:09:22 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 RAA18362
          for ; Tue, 16 Dec 1997 17:05:38 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id LAA27589;
          Wed, 17 Dec 1997 11:34:02 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971217113402.56822@lemis.com>
Date: Wed, 17 Dec 1997 11:34:02 +1030
From: Greg Lehey 
To: dennis 
Cc: hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask
References: <3.0.32.19971216193810.00b3b480@etinc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <3.0.32.19971216193810.00b3b480@etinc.com>; from dennis on Tue, Dec 16, 1997 at 07:38:10PM -0500
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, Dec 16, 1997 at 07:38:10PM -0500, dennis wrote:
> At 08:59 AM 12/17/97 +1030, you wrote:
>> On Tue, Dec 16, 1997 at 10:39:08AM -0500, dennis wrote:
>>>
>>> Is there any chance of this getting fixed? Its been broken forever. I'm
>>> talking about PTP interfaces, where the routes are inherently host
>>> mask routes. ifconfig reports the natural mask or whatever you give
>>> it....and its rather confusing trying to explain to the woodchucks that
>>> its wrong.
>>
>> Well, ifconfig reports the net mask that is set.  And yes, it's
>> inappropriate for "real" point-to-point interfaces.  But it's not the
>> reporting that's wrong, it's the setting.  Just set all ones when
>> setting the interface, and you'll be OK.
>>
>> I suppose I should mention that there's a sizeable minority who think
>> this is the way the net mask *should* be.  Maybe one of them will
>> explain, I keep forgetting.
>
> I disagree. The route is expicitly set by the command to be a host route,
> but the mask (and I'm talking about the case where no mask is specified
> in the ifconfig) is set to the natural mask (class, that is).

I'm not sure what you're disagreeing with here.  I said that ifconfig
is just reporting the net mask.  I believe this to be true.  I also
said that ifconfig will set the net mask based on the address class,
not on the type of connection.  You seem to be saying the same thing.
What are you disagreeing with?

> Even if you specifiy a non-host mask, a host route is set...if that is the
> case then only a host mask should be allowed, and a host mask should
> be forced. You SHOULD be able to override the host setting, that is, if a
> mask is specified explicitly then the route should be set according to the
> netmask.

Good point.  I suppose we could consider it a bug.  But, as I say,
some people expect a different net mask.  My ISP (Telstra, Australia's
telco, and a reasonably experienced provider) asks me to set a net
mask of 0xffffffc0 for some reason.  I wonder why.  I notice now that
I look at it that I'm not complying.

Greg

From owner-freebsd-hackers  Tue Dec 16 17:14:24 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA19148
          for hackers-outgoing; Tue, 16 Dec 1997 17:14:24 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 RAA18589
          for ; Tue, 16 Dec 1997 17:08:30 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id LAA27601;
          Wed, 17 Dec 1997 11:38:01 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971217113801.53802@lemis.com>
Date: Wed, 17 Dec 1997 11:38:01 +1030
From: Greg Lehey 
To: Mike Smith 
Cc: John Kelly , FreeBSD Hackers 
Subject: Re: 3com 3c509 card
References: <34974fcb.31632460@mail.cetlink.net> <199712162352.KAA00272@word.smith.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <199712162352.KAA00272@word.smith.net.au>; from Mike Smith on Wed, Dec 17, 1997 at 10:22:42AM +1030
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, Dec 17, 1997 at 10:22:42AM +1030, Mike Smith wrote:
>> On Tue, 16 Dec 1997 19:10:50 +1030, Mike Smith 
>> wrote:
>>
>>>> I replaced an NE2000 clone with a SMC Ultra 16, thinking shared memory
>>>> would consume far less CPU than PIO with an NE2000.  But it seems to
>>>> be about the same.
>>>
>>> About half.  Please don't confuse anecdotal evidence with measured
>>> results.
>>>
>>
>> I tested with an FTP transfer and consumed about 45% CPU in both
>> cases.
>>
>> I wonder if I'm doing something wrong.
>
> Well, for starters you aren't disclosing your measurement technique.
> It sounds to me as though it's not measuring the relative CPU consumed
> per bytes/datagrams transferred by the driver though.
>
> All you have established is that a known ~50% improvement in the CPU
> utilisation of the driver has not affected the amount of CPU used for
> your FTP transfer.  This should tell you something about how efficient
> the driver is in the first place, especially compared with the other
> operations involved in the transfer.
>
> First thing anyone should learn; how to measure things.  Whether you're
> talking engineering, physics, chemistry or computing; if you don't know
> what you're measuring, the numbers mean nothing.

It's easy to say that sort of thing.  Now how about explaining what he
should be looking for?

I've been doing some experiments with ftps on my local network, but
the results have been puzzling, and until I know what's going on, I'm
not going to go into too much detail.  But I've noticed that I'm
getting very high interrupt times on a P5/133 (up to over 50%) when
receiving large files (40 MB).  I've also noticed that the transfer
starts at about 1 MB/s, but after about 10 MB there are problems, and
the final transfer rate is often less than 500 kB/s.  This is not what
I measured on the same systems about a year ago.  I may follow up on
this if I find time.

Greg

From owner-freebsd-hackers  Tue Dec 16 17:24:39 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA20106
          for hackers-outgoing; Tue, 16 Dec 1997 17:24:39 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 RAA19587
          for ; Tue, 16 Dec 1997 17:19:00 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id LAA00848;
	Wed, 17 Dec 1997 11:43:07 +1030 (CST)
Message-Id: <199712170113.LAA00848@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Greg Lehey 
cc: Mike Smith , John Kelly ,
        FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Wed, 17 Dec 1997 11:38:01 +1030."
             <19971217113801.53802@lemis.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 11:43:07 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >> I tested with an FTP transfer and consumed about 45% CPU in both
> >> cases.
> >>
> >> I wonder if I'm doing something wrong.
> >
> > Well, for starters you aren't disclosing your measurement technique.
> > It sounds to me as though it's not measuring the relative CPU consumed
> > per bytes/datagrams transferred by the driver though.
> >
> > All you have established is that a known ~50% improvement in the CPU
> > utilisation of the driver has not affected the amount of CPU used for
> > your FTP transfer.  This should tell you something about how efficient
> > the driver is in the first place, especially compared with the other
> > operations involved in the transfer.
> >
> > First thing anyone should learn; how to measure things.  Whether you're
> > talking engineering, physics, chemistry or computing; if you don't know
> > what you're measuring, the numbers mean nothing.
> 
> It's easy to say that sort of thing.  Now how about explaining what he
> should be looking for?

CPU time spent in the driver; I'd have thought that was pretty obvious 
from the above.  Call microtime() on entry to driver functions, call it 
again on exit, and add the difference to a counter.  Extract the value 
of the counter and relate it to the number of bytes transferred on the 
interface.  Be careful not to double-count time.  Be sensitive to 
per-datagram as opposed to per-byte overheads.

An earlier poster described a substantial performance improvement 
between 2.1 and 2.2 on a slow system; I believe this had to to with 
changes in the mbuf management code (clustering?).

mike



From owner-freebsd-hackers  Tue Dec 16 17:44:09 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA21977
          for hackers-outgoing; Tue, 16 Dec 1997 17:44:09 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21884
          for ; Tue, 16 Dec 1997 17:43:53 -0800 (PST)
          (envelope-from mini@d198-232.uoregon.edu)
Received: (from mini@localhost)
	by d198-232.uoregon.edu (8.8.5/8.8.5) id RAA29129;
	Tue, 16 Dec 1997 17:43:22 -0800 (PST)
Message-ID: <19971216174321.03686@micron.mini.net>
Date: Tue, 16 Dec 1997 17:43:21 -0800
From: Jonathan Mini 
To: Terry Lambert 
Cc: daniel_sobral@voga.com.br, hackers@FreeBSD.ORG
Subject: Re: Why so many steps to build new kernel?
Reply-To: Jonathan Mini 
References: <8325656F.0038C91F.00@papagaio.voga.com.br> <199712161847.LAA18094@usr01.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: <199712161847.LAA18094@usr01.primenet.com>; from Terry Lambert on Tue, Dec 16, 1997 at 06:47:57PM +0000
X-files: The Truth is Out There
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

[ .... much ramblings by many people deleted .... ]

  Please understand that I am attacking this as two seperate systems :

	1) A system which manages building of multiple options or modules into
	one or more modules which together make a "kernel." (this means support
	for both a static kernel and a completely dynamic kernel. Both extremes
	will be useful to different people, but the majority of us will want
	something in the middle)

	2) Another system which manages that management. This is the "kernel
	configuratior" and one will be neccisary to build static kernels, no
	matter how you look at the problem. While I am all for dynamic kernels,
	a static kernel is still very useful, and I VERY much do not want to
	see that possibility go away.
	  It should also be noted that this tool will be needed to configure
	compile-time options of the modules.

  Currently, I haven't even begun to think about part 2, but am instead trying
to come up with an easy-to-maintain and extendable method of implementing part
1. I am to replace the config(8) utility and it's underlying build method with
something that will remove many of the problems of config(8). 

-- 
Jonathan Mini 					Ingenious Productions
Software Development				P.O. Box 5693,
						Eugene, Or. 97405

 "A child of five could understand this! Quick -- Fetch me a child of five."

From owner-freebsd-hackers  Tue Dec 16 17:55:48 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA23260
          for hackers-outgoing; Tue, 16 Dec 1997 17:55:48 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23228
          for ; Tue, 16 Dec 1997 17:55:37 -0800 (PST)
          (envelope-from asami@vader.cs.berkeley.edu)
Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.7/8.7.3) id RAA04988; Tue, 16 Dec 1997 17:55:33 -0800 (PST)
Date: Tue, 16 Dec 1997 17:55:33 -0800 (PST)
Message-Id: <199712170155.RAA04988@vader.cs.berkeley.edu>
To: imp@village.org
CC: hackers@freebsd.org
In-reply-to: <199712170102.SAA00624@harmony.village.org> (message from Warner Losh on Tue, 16 Dec 1997 18:02:13 -0700)
Subject: Re: Question about making a new machine from an old one
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

 * mount new-disk-a /gerbils
 * mkdir /gerbils/usr /gerbils/var /gerbils/home
 * mount new-disk-d /gerbils/usr
 * mount new-disk-e /gerbils/var
 * mount new-disk-f /gerbils/home

(mount these with "-o async", that will make the rest much faster.)

After this, I usually just do a

===
cd /
find -dx . | cpio -dump /gerbils
find -dx usr var home | cpio -dump /gerbils
vi /gerbils/etc/
===

That's how I duplicated the 20 machines in our disk array here.  (Of
course, you probably don't want the "/home" to be copied, but you get
the idea.)

Satoshi

From owner-freebsd-hackers  Tue Dec 16 18:06:13 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA24238
          for hackers-outgoing; Tue, 16 Dec 1997 18:06:13 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from mail.xmission.com (mail.xmission.com [198.60.22.22])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA24198;
          Tue, 16 Dec 1997 18:05:25 -0800 (PST)
          (envelope-from softweyr@xmission.com)
Received: from xmission.com [199.104.124.49] 
	by mail.xmission.com with esmtp (Exim 1.73 #4)
	id 0xi8rR-0003B7-00; Tue, 16 Dec 1997 19:05:21 -0700
Message-ID: <34973506.B112548D@xmission.com>
Date: Tue, 16 Dec 1997 19:12:22 -0700
From: Wes Peters 
Reply-To: chat@FreeBSD.ORG, softweyr@xmission.com
Organization: Softweyr LLC
X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386)
MIME-Version: 1.0
To: chat@FreeBSD.ORG
CC: questions@freesbd.org, hackers@FreeBSD.ORG, isp@FreeBSD.ORG
Subject: Support for secure http protocols
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

FreeBies and Gentlehackers,

I've been working on a project to provide an essential service for FreeBSD
users via a web/http interface.  (No, I'm not ready to discuss it yet, I
don't have time to answer 5,000 questions about "why don't you do it this
ways").  Suffice it to say that several of you will be interested in it.
Now, for the meat of the question.

This service will need secure communications with the http server in question.
I've looked and looked, and haven't found anything approaching a W3C or IETF
decision on secure communications for http.  The IETF is apparently waiting
for the W3C to make up its collective mind, and W3C has done so much waffling
on this issue they've hired Aunt Jemima as their hacker relations expert.

So, my question is: if I have the capability (time, interest, etc) to 
implement only ONE secure http transport, which one should it be?  There
is a draft ieft standard for S-HTTP, but Netscape et al HTTP-SSL seems to
have garnered more support in the real world.

I've cc'd the questions, hackers, and isp mail lists because they represent,
collectively, the FreeBSD user base, core development team, and the people
most familiar with web servers.  Please note that I've directed followups to
me, and to the chat list.  

I'm mostly looking for a poll of what others have implemented, and why, as
opposed to a philosophical discussion of the merits of each; I've read too
much of this in the flame wars being traded between Netscape and Terisa.

-- 
       "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                 Softweyr LLC
http://www.xmission.com/~softweyr                 softweyr@xmission.com

From owner-freebsd-hackers  Tue Dec 16 18:08:44 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA24700
          for hackers-outgoing; Tue, 16 Dec 1997 18:08:44 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA24022
          for ; Tue, 16 Dec 1997 18:03:33 -0800 (PST)
          (envelope-from archie@whistle.com)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA04142; Tue, 16 Dec 1997 18:02:58 -0800 (PST)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
	id sma004140; Tue Dec 16 18:02:30 1997
Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id SAA03536; Tue, 16 Dec 1997 18:02:29 -0800 (PST)
From: Archie Cobbs 
Message-Id: <199712170202.SAA03536@bubba.whistle.com>
Subject: Re: profiling inside kernel
In-Reply-To: <199712160849.JAA02895@kk662.kk.etx.ericsson.se> from ETX-B-SL Martti Kuparinen at "Dec 16, 97 09:49:45 am"
To: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen)
Date: Tue, 16 Dec 1997 18:02:28 -0800 (PST)
Cc: 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


ETX-B-SL Martti Kuparinen writes:
> - How can one get assembler listing from a function within gdb?
>   (I need to count the real machine instructions in a function)

I think "x/16i" will do the trick... that's "examine, decode as
instruction, 16 times".

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

From owner-freebsd-hackers  Tue Dec 16 18:12:59 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA25025
          for hackers-outgoing; Tue, 16 Dec 1997 18:12:59 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 SAA24890
          for ; Tue, 16 Dec 1997 18:10:52 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id SAA16604;
	Tue, 16 Dec 1997 18:08:38 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd016599; Tue Dec 16 18:08:32 1997
Message-ID: <3497337D.4487EB71@whistle.com>
Date: Tue, 16 Dec 1997 18:05:49 -0800
From: Julian Elischer 
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Terry Lambert 
CC: Igor Timkin , freebsd-hackers@freebsd.org
Subject: Re: panic: blkfree: freeling free block/frag
References: <199712161919.MAA20145@usr01.primenet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

hey!
how come all this kernel is linked to run at 0xe0000000
rather than 0xf0000000?


> > GDB 4.16 (i386-unknown-freebsd),
> > Copyright 1996 Free Software Foundation, Inc...
> > IdlePTD 1f0000
> > current pcb at 1d79c0
> > panic: blkfree: freeing free block
> > #0  boot (howto=256) at ../../kern/kern_shutdown.c:266
> > 266                                     dumppcb.pcb_cr3 = rcr3();
> > (kgdb) where
> > #0  boot (howto=256) at ../../kern/kern_shutdown.c:266
> > #1  0xe01105e2 in panic (fmt=0xe0188a85 "blkfree: freeing free block")
> >     at ../../kern/kern_shutdown.c:390
> > #2  0xe0188c57 in ffs_blkfree (ip=0xe3e50500, bno=10, size=4096)
> >     at ../../ufs/ffs/ffs_alloc.c:1230
> > #3  0xe018b09a in ffs_indirtrunc (ip=0xe3e50500, lbn=-12, dbn=394248,
> >     lastbn=-1, level=0, countp=0xdfbffd9c) at ../../ufs/ffs/ffs_inode.c:500
> > #4  0xe018aac8 in ffs_truncate (ap=0xdfbffe74) at ../../ufs/ffs/ffs_inode.c:317
> > #5  0xe018e6a5 in ufs_inactive (ap=0xdfbffea0) at vnode_if.h:1003
> > #6  0xe012fb3f in vrele (vp=0xe3b12800) at vnode_if.h:699
> > #7  0xe012fa33 in vput (vp=0xe3b12800) at ../../kern/vfs_subr.c:858
> > #8  0xe0191e80 in ufs_remove (ap=0xdfbffef4) at ../../ufs/ufs/ufs_vnops.c:697
> > #9  0xe0131d25 in unlink (p=0xe4dc6e00, uap=0xdfbfff94, retval=0xdfbfff84)
> >     at vnode_if.h:459
> > #10 0xe01ac1ff in syscall (frame={tf_es = 39, tf_ds = -541130713, tf_edi = 1,
> >       tf_esi = 28736, tf_ebp = -541074456, tf_isp = -541065244,
> >       tf_ebx = 28944, tf_edx = 0, tf_ecx = 41472, tf_eax = 10, tf_trapno = 7,
> >       tf_err = 7, tf_eip = 268950145, tf_cs = 31, tf_eflags = 582,
> >       tf_esp = -541074568, tf_ss = 39}) at ../../i386/i386/trap.c:890
> > #11 0x1007da81 in ?? ()
> > #12 0x2453 in ?? ()
> > #13 0x2914 in ?? ()
> > #14 0x1095 in ?? ()
> 
>

From owner-freebsd-hackers  Tue Dec 16 18:22:45 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA25721
          for hackers-outgoing; Tue, 16 Dec 1997 18:22:45 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA25715
          for ; Tue, 16 Dec 1997 18:22:30 -0800 (PST)
          (envelope-from archie@whistle.com)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA04284; Tue, 16 Dec 1997 18:21:59 -0800 (PST)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
	id sma004282; Tue Dec 16 18:21:38 1997
Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id SAA17619; Tue, 16 Dec 1997 18:21:38 -0800 (PST)
From: Archie Cobbs 
Message-Id: <199712170221.SAA17619@bubba.whistle.com>
Subject: Re: ifconfig reports bogus netmask
In-Reply-To: <19971217085945.37164@lemis.com> from Greg Lehey at "Dec 17, 97 08:59:45 am"
To: grog@lemis.com (Greg Lehey)
Date: Tue, 16 Dec 1997 18:21:38 -0800 (PST)
Cc: dennis@etinc.com, 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

Greg Lehey writes:
> On Tue, Dec 16, 1997 at 10:39:08AM -0500, dennis wrote:
> >
> > Is there any chance of this getting fixed? Its been broken forever. I'm
> > talking about PTP interfaces, where the routes are inherently host
> > mask routes. ifconfig reports the natural mask or whatever you give
> > it....and its rather confusing trying to explain to the woodchucks that
> > its wrong.
> 
> Well, ifconfig reports the net mask that is set.  And yes, it's
> inappropriate for "real" point-to-point interfaces.  But it's not the
> reporting that's wrong, it's the setting.  Just set all ones when
> setting the interface, and you'll be OK.
> 
> I suppose I should mention that there's a sizeable minority who think
> this is the way the net mask *should* be.  Maybe one of them will
> explain, I keep forgetting.

I agree with Dennis..

The bottom line is that no matter what you set the netmask to,
it has absolutely no effect on anything.

So unless the current behavior is going to be changed, the netmask
should be removed from the display (at least) because it serves only
to confuse people.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

From owner-freebsd-hackers  Tue Dec 16 19:07:54 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA29172
          for hackers-outgoing; Tue, 16 Dec 1997 19:07:54 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA29137;
          Tue, 16 Dec 1997 19:07:37 -0800 (PST)
          (envelope-from cmott@srv.net)
Received: from darkstar.home (ras519.srv.net [205.180.127.19]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id UAA03188; Tue, 16 Dec 1997 20:07:31 -0700
Date: Tue, 16 Dec 1997 20:06:58 -0700 (MST)
From: Charles Mott 
X-Sender: cmott@darkstar.home
To: chat@freebsd.org, softweyr@xmission.com
cc: questions@freesbd.org, hackers@freebsd.org, isp@freebsd.org
Subject: Re: Support for secure http protocols
In-Reply-To: <34973506.B112548D@xmission.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 Tue, 16 Dec 1997, Wes Peters wrote:

> So, my question is: if I have the capability (time, interest, etc) to 
> implement only ONE secure http transport, which one should it be?  There
> is a draft ieft standard for S-HTTP, but Netscape et al HTTP-SSL seems to
> have garnered more support in the real world.

I've said this once before, but I think the way to go is to operate an
"anonymous" ssh server on the web server, and then have the client
application set up a secure proxy connection to the host via existing the
existing port remapping (-L option) in ssh.

I think anonymous ssh could have a similar impact to anonymous ftp.  Ssh
based clients would use the anonymous user name the same way web browsers
do for ftp right now. 

Ssh and sshd are already universal in the unix world, and the Wintel
variant (F-Secure) is reasonably priced.  Why not encapsulate security as
much as possible in an ssh framework?  Then developers could stop thinking
about the subtleties and cross-national implications of licensing. 

Charles Mott


From owner-freebsd-hackers  Tue Dec 16 19:14:15 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA29734
          for hackers-outgoing; Tue, 16 Dec 1997 19:14:15 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29721
          for ; Tue, 16 Dec 1997 19:14:01 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-13.cetlink.net [209.54.58.13])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id WAA12538;
          Tue, 16 Dec 1997 22:13:10 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Mike Smith 
Cc: Greg Lehey , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
Date: Wed, 17 Dec 1997 04:14:07 GMT
Message-ID: <34974b92.96107160@mail.cetlink.net>
References: <199712170113.LAA00848@word.smith.net.au>
In-Reply-To: <199712170113.LAA00848@word.smith.net.au>
X-Mailer: Forte Agent 1.01/16.397
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 TAA29722
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 17 Dec 1997 11:43:07 +1030, Mike Smith 
wrote:

> Well, for starters you aren't disclosing your measurement technique.

Simple CPU percentages from top.

> All you have established is that a known ~50% improvement in the CPU
> utilisation of the driver has not affected the amount of CPU used for
> your FTP transfer.

If it's true that the driver is 50% more efficient with the SMC Ultra
16, then how is it possible that the FTP code performs worse to keep
the total percentage about the same?  Are you saying that the driver
component is so small that the improvement is drowned out by the FTP?

I think my next test will be to set up a "router" machine with 4
ethernet adapters, and saturate them all from other connected machines
with all traffic passing through the router and none terminating in it
to eliminate all processing load except the routing and SMC driver.

> First thing anyone should learn; how to measure things.  Whether you're
> talking engineering, physics, chemistry or computing; if you don't know
> what you're measuring, the numbers mean nothing.

If I can't route 4 ethernet interfaces with SMC Ultras then a rigorous
academic exercise has no value for my purposes.  I just want a rough
projection that's reasonably accurate.

> CPU time spent in the driver; I'd have thought that was pretty obvious 
> from the above.  Call microtime() on entry to driver functions, call it 
> again on exit, and add the difference to a counter.  Extract the value 
> of the counter and relate it to the number of bytes transferred on the 
> interface.  Be careful not to double-count time.  Be sensitive to 
> per-datagram as opposed to per-byte overheads.

That's what I meant, above.
  
John



From owner-freebsd-hackers  Tue Dec 16 19:19:46 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA00291
          for hackers-outgoing; Tue, 16 Dec 1997 19:19:46 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from gatekeeper.ray.com (gatekeeper.ray.com [138.125.162.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00248
          for ; Tue, 16 Dec 1997 19:19:16 -0800 (PST)
          (envelope-from moncrg@bt340707.res.ray.com)
Received: (mailer@localhost) by gatekeeper.ray.com (8.8.7/8.8.7) id WAA18273 for ; Tue, 16 Dec 1997 22:19:03 -0500
Received: from bt340707.res.ray.com/138.125.142.35()
	by gatekeeper.ray.com
	id sma.882319714.017146; Tue Dec 16 19:48:34 1997
Received: (from moncrg@localhost)
	by bt340707.res.ray.com (8.8.7/8.8.7) id TAA21293;
	Tue, 16 Dec 1997 19:44:08 -0500 (EST)
	(envelope-from moncrg)
Date: Tue, 16 Dec 1997 19:44:08 -0500 (EST)
Message-Id: <199712170044.TAA21293@bt340707.res.ray.com>
From: "Gregory D. Moncreaff" 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: hackers@FreeBSD.ORG
Subject: atapi.c || wierd hardware
X-Mailer: VM 6.31 under 20.2 XEmacs Lucid
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


I've got a couple of IDE cdroms that, on boot/probe, 
put a line as follows in the log:

wdc1: unit 0 (atapi): , removable, dma, iordy

(lots of whitespace between 'NEC' and 'CD')

what I'm wondering about is if NEC has a strange string in its
firmware or if atapi.c needs to clean up for this or both

I took a look in atapi.c and as far as I can tell, it only
cleans up trailing garbage....

From owner-freebsd-hackers  Tue Dec 16 19:20:56 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA00477
          for hackers-outgoing; Tue, 16 Dec 1997 19:20:56 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00472
          for ; Tue, 16 Dec 1997 19:20:49 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-13.cetlink.net [209.54.58.13])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id WAA13436;
          Tue, 16 Dec 1997 22:20:39 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Andrew Gordon 
Cc: FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
Date: Wed, 17 Dec 1997 04:21:36 GMT
Message-ID: <349851b2.97675708@mail.cetlink.net>
References: 
In-Reply-To: 
X-Mailer: Forte Agent 1.01/16.397
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 TAA00473
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, 16 Dec 1997 11:59:18 +0000 (GMT), Andrew Gordon
 wrote:

>>SMC Ultra 16

>Have you got a _real_

The genuine article.

>(no longer available) Ultra here?

I have about 200.

>Testing with FTP (on a 486), I get about 600-700kbyte/sec
>with NE2000s, and 900-1000kbyte/s with SMC Ultra.

Interesting.  I've never seen my Ultras go above 700.  I'll keep
poking around to see if I'm doing something wrong.

John



From owner-freebsd-hackers  Tue Dec 16 19:40:49 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA02439
          for hackers-outgoing; Tue, 16 Dec 1997 19:40:49 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 TAA02431
          for ; Tue, 16 Dec 1997 19:40:43 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id OAA01300;
	Wed, 17 Dec 1997 14:04:26 +1030 (CST)
Message-Id: <199712170334.OAA01300@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: jak@cetlink.net (John Kelly)
cc: Mike Smith , Greg Lehey ,
        FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Wed, 17 Dec 1997 04:14:07 GMT."
             <34974b92.96107160@mail.cetlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Wed, 17 Dec 1997 14:04:26 +1030
From: Mike Smith 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id TAA02434
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > All you have established is that a known ~50% improvement in the CPU
> > utilisation of the driver has not affected the amount of CPU used for
> > your FTP transfer.
> 
> If it's true that the driver is 50% more efficient with the SMC Ultra
> 16, then how is it possible that the FTP code performs worse to keep
> the total percentage about the same?  Are you saying that the driver
> component is so small that the improvement is drowned out by the FTP?

This would appear to be the logical conclusion, presuming no other 
influences exist.  Without demonstrating the latter, however, you can't 
be sure of anything.

> > First thing anyone should learn; how to measure things.  Whether you're
> > talking engineering, physics, chemistry or computing; if you don't know
> > what you're measuring, the numbers mean nothing.
> 
> If I can't route 4 ethernet interfaces with SMC Ultras then a rigorous
> academic exercise has no value for my purposes.  I just want a rough
> projection that's reasonably accurate.

"AT Bus Design" (Edward Solari, Annabooks), p 6-101, quoted without 
permission, excerpt from table 6-3: ISA AND E-ISA PLATFORM STANDARD 
ACCESS MEMORY CYCLE LENGTH

BUS OWNER	CYCLE BEGINS	CYCLE ENDS	CYCLE	CYCLE
						SIZE	LENGTH
---------------------------------------------------------------
PLAT FORM (sic)	.5 TCLK TO	END COMMAND	 8 BITS	6 TCLK
CPU		ACT BALE	ACT PERIOD	16 BITS	3 TCLK

For reference, TCLK is the period of BCLK, ie. 1 TCLK ~= 120ns for the 
standard 8.33MHz BCLK.
So a 16-bit memory cycle on the ISA bus takes at least 360ns.
If you flip that the other way around and account for the other .5 TCLK 
idle before BALE can go active again, you get about 2.5 16-bit cycles 
per microsecond, or about 5MB/sec ISA memory bandwidth.

Of couse, you could just say that the 5MB/sec figure has been generally 
known for the last decade or so, but I thought a really simple adademic 
wank might convince you of the basic usefulness of measurement doctrine.

Now, if you take into account just a little CPU overhead, interrupt 
cycle overhead, metadata overhead, you will quickly see that you're 
not going to route 4MB/sec aggregate traffic through anything on the ISA
bus, period.

Personally, I'd recommend a 4-port Zynx card.

mike



From owner-freebsd-hackers  Tue Dec 16 20:09:14 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA04091
          for hackers-outgoing; Tue, 16 Dec 1997 20:09:14 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA04069
          for ; Tue, 16 Dec 1997 20:09:04 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-13.cetlink.net [209.54.58.13])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id XAA17829;
          Tue, 16 Dec 1997 23:08:38 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Mike Smith 
Cc: FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
Date: Wed, 17 Dec 1997 05:09:35 GMT
Message-ID: <349a59c3.99678713@mail.cetlink.net>
References: <199712170334.OAA01300@word.smith.net.au>
In-Reply-To: <199712170334.OAA01300@word.smith.net.au>
X-Mailer: Forte Agent 1.01/16.397
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 UAA04070
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 17 Dec 1997 14:04:26 +1030, Mike Smith 
wrote:

>"AT Bus Design" (Edward Solari, Annabooks)

BTW, I checked on getting that book and it seems to be no longer
available.

>Now, if you take into account just a little CPU overhead, interrupt 
>cycle overhead, metadata overhead, you will quickly see that you're 
>not going to route 4MB/sec aggregate traffic through anything on the ISA
>bus, period.

I seem to have one 486 board running at 12 MHz ISA and clock doubled
50/100MHz DX4-100 CPU will no apparent problems.  This has reduced my
(measured) 8 bit I/O cycle time to 0.65 usec.  I don't have a suitable
method for measuring the 16-bit cycle time, but I'm hoping for nearly
4MB through this supercharged bus in 16-bit mode.  I'm only getting
about 700K per card, so I don't think I need a full 4MB anyway.  I
might even be able to use five interfaces -- they won't be saturated
all the time.

>Personally, I'd recommend a 4-port Zynx card.

I have a small truckload of SMC Ultras I need to use.

John



From owner-freebsd-hackers  Tue Dec 16 20:17:12 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA04813
          for hackers-outgoing; Tue, 16 Dec 1997 20:17:12 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 UAA04800
          for ; Tue, 16 Dec 1997 20:17:06 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id OAA01443;
	Wed, 17 Dec 1997 14:40:28 +1030 (CST)
Message-Id: <199712170410.OAA01443@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: jak@cetlink.net (John Kelly)
cc: Andrew Gordon ,
        FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Wed, 17 Dec 1997 04:21:36 GMT."
             <349851b2.97675708@mail.cetlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 14:40:28 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> >(no longer available) Ultra here?
> 
> I have about 200.

Hmm.  Large installed base?

> >Testing with FTP (on a 486), I get about 600-700kbyte/sec
> >with NE2000s, and 900-1000kbyte/s with SMC Ultra.
> 
> Interesting.  I've never seen my Ultras go above 700.  I'll keep
> poking around to see if I'm doing something wrong.

Which OS version, and on what CPU?  I've seen over 1000K/sec on NE2000 
clones doing PIO, (RTL8019, Accton 5332, etc.) and likewise on
memory-mapped SMC clones (NS83901, NS83905, etc), mostly it's 2.2 
variants that stick in my memory, and mostly on low-end pentium systems.

mike



From owner-freebsd-hackers  Tue Dec 16 20:21:46 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA05372
          for hackers-outgoing; Tue, 16 Dec 1997 20:21:46 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 UAA05358
          for ; Tue, 16 Dec 1997 20:21:35 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id OAA01477;
	Wed, 17 Dec 1997 14:46:08 +1030 (CST)
Message-Id: <199712170416.OAA01477@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: jak@cetlink.net (John Kelly)
cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Wed, 17 Dec 1997 05:09:35 GMT."
             <349a59c3.99678713@mail.cetlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Wed, 17 Dec 1997 14:46:08 +1030
From: Mike Smith 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAA05359
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> On Wed, 17 Dec 1997 14:04:26 +1030, Mike Smith 
> wrote:
> 
> >"AT Bus Design" (Edward Solari, Annabooks)
> 
> BTW, I checked on getting that book and it seems to be no longer
> available.

Hmm.  I'd better steal this copy then.  If you're doing AT bus design 
work it's invaluable, if a bit terse.  8)

> >Now, if you take into account just a little CPU overhead, interrupt 
> >cycle overhead, metadata overhead, you will quickly see that you're 
> >not going to route 4MB/sec aggregate traffic through anything on the ISA
> >bus, period.
> 
> I seem to have one 486 board running at 12 MHz ISA and clock doubled
> 50/100MHz DX4-100 CPU will no apparent problems.  This has reduced my
> (measured) 8 bit I/O cycle time to 0.65 usec.  I don't have a suitable
> method for measuring the 16-bit cycle time, but I'm hoping for nearly
> 4MB through this supercharged bus in 16-bit mode. 

You can expect that it will be half, based on the 6 clock/3 clock 
ratio, so about 325ns.

> I'm only getting
> about 700K per card, so I don't think I need a full 4MB anyway.  I
> might even be able to use five interfaces -- they won't be saturated
> all the time.

Yup.  The other significant point is that you are routing, not 
bridging, so you are more concerned with through traffic than 
all-networks-aggregate.
 
> >Personally, I'd recommend a 4-port Zynx card.
> 
> I have a small truckload of SMC Ultras I need to use.

That does constrain you somewhat.  8)

mike



From owner-freebsd-hackers  Tue Dec 16 20:29:24 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA06271
          for hackers-outgoing; Tue, 16 Dec 1997 20:29:24 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA05839
          for ; Tue, 16 Dec 1997 20:24:08 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-13.cetlink.net [209.54.58.13])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id XAA19210;
          Tue, 16 Dec 1997 23:23:29 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Mike Smith 
Cc: Andrew Gordon ,
        FreeBSD Hackers 
Subject: SMC Ultra 16
Date: Wed, 17 Dec 1997 05:24:26 GMT
Message-ID: <349b6066.101378203@mail.cetlink.net>
References: <199712170410.OAA01443@word.smith.net.au>
In-Reply-To: <199712170410.OAA01443@word.smith.net.au>
X-Mailer: Forte Agent 1.01/16.397
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 UAA05858
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 17 Dec 1997 14:40:28 +1030, Mike Smith 
wrote:

>> >(no longer available) Ultra here?
>> 
>> I have about 200.
>
>Hmm.  Large installed base?

No, bought at auction.  TP model are new, BNC model are SMC refurb but
good as new.  All in SMC plastic case.

>> Interesting.  I've never seen my Ultras go above 700.  I'll keep
>> poking around to see if I'm doing something wrong.
>
>Which OS version, and on what CPU?

2.2-stable. 486 DX4-100.

John




From owner-freebsd-hackers  Tue Dec 16 20:33:24 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA06653
          for hackers-outgoing; Tue, 16 Dec 1997 20:33:24 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA06647
          for ; Tue, 16 Dec 1997 20:33:18 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-13.cetlink.net [209.54.58.13])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id XAA20131;
          Tue, 16 Dec 1997 23:33:12 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Mike Smith 
Cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
Date: Wed, 17 Dec 1997 05:34:09 GMT
Message-ID: <349c63b3.102223169@mail.cetlink.net>
References: <199712170416.OAA01477@word.smith.net.au>
In-Reply-To: <199712170416.OAA01477@word.smith.net.au>
X-Mailer: Forte Agent 1.01/16.397
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 UAA06649
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 17 Dec 1997 14:46:08 +1030, Mike Smith 
wrote:

>> I seem to have one 486 board running at 12 MHz ISA and clock doubled
>> 50/100MHz DX4-100 CPU will no apparent problems.  This has reduced my
>> (measured) 8 bit I/O cycle time to 0.65 usec.  I don't have a suitable
>> method for measuring the 16-bit cycle time, but I'm hoping for nearly
>> 4MB through this supercharged bus in 16-bit mode. 
>
>You can expect that it will be half, based on the 6 clock/3 clock 
>ratio, so about 325ns.

That would be an upper limit of 6MB, so with overhead maybe 4MB is
attainable.  I'll learn more when I get around to setting up the
router and testing it.

John



From owner-freebsd-hackers  Tue Dec 16 20:34:41 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA06879
          for hackers-outgoing; Tue, 16 Dec 1997 20:34:41 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from m16.boston.juno.com (m16.boston.juno.com [205.231.101.192])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA06858
          for ; Tue, 16 Dec 1997 20:34:34 -0800 (PST)
          (envelope-from wakkym@juno.com)
Received: (from wakkym@juno.com)
 by m16.boston.juno.com (queuemail) id XYV23667; Tue, 16 Dec 1997 23:33:34 EST
To: moncrg@bt340707.res.ray.com
Cc: hackers@freebsd.org
Subject: Re: atapi.c || wierd hardware
Message-ID: <19971216.233119.5295.1.wakkym@juno.com>
References: <199712170044.TAA21293@bt340707.res.ray.com>
X-Mailer: Juno 1.15
X-Juno-Line-Breaks: 0,2-14,17
From: wakkym@juno.com (Lee Cremeans)
Date: Tue, 16 Dec 1997 23:33:34 EST
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Tue, 16 Dec 1997 19:44:08 -0500 (EST) "Gregory D. Moncreaff"
 writes:
>
>I've got a couple of IDE cdroms that, on boot/probe, 
>put a line as follows in the log:
>
>wdc1: unit 0 (atapi): , 
>removable, dma, iordy
>
>(lots of whitespace between 'NEC' and 'CD')
>
>what I'm wondering about is if NEC has a strange string in its
>firmware or if atapi.c needs to clean up for this or both

It's the firmware. I've seen this on store-demo Packard Bells with NEC
drives...the BIOS itself shows the whitespace (yes, I'm the kind of
person who reboots store-demo machines...;).

From owner-freebsd-hackers  Tue Dec 16 21:07:31 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA08771
          for hackers-outgoing; Tue, 16 Dec 1997 21:07:31 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 VAA08764
          for ; Tue, 16 Dec 1997 21:07:22 -0800 (PST)
          (envelope-from imp@village.org)
Received: from harmony [10.0.0.6] 
	by rover.village.org with esmtp (Exim 1.71 #1)
	id 0xiBhY-0000dM-00; Tue, 16 Dec 1997 22:07:20 -0700
Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id WAA02379; Tue, 16 Dec 1997 22:07:29 -0700 (MST)
Message-Id: <199712170507.WAA02379@harmony.village.org>
To: asami@cs.berkeley.edu (Satoshi Asami)
Subject: Re: Question about making a new machine from an old one 
Cc: hackers@freebsd.org
In-reply-to: Your message of "Tue, 16 Dec 1997 17:55:33 PST."
		<199712170155.RAA04988@vader.cs.berkeley.edu> 
References: <199712170155.RAA04988@vader.cs.berkeley.edu>  
Date: Tue, 16 Dec 1997 22:07:29 -0700
From: Warner Losh 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199712170155.RAA04988@vader.cs.berkeley.edu> Satoshi Asami writes:
: That's how I duplicated the 20 machines in our disk array here.  (Of
: course, you probably don't want the "/home" to be copied, but you get
: the idea.)

Yes, but I need to have machine number 1 in this infinite series
first.  Since I don't have a a -stable machine to clone from, I
thought I'd do it from my -stable build tree.  I have many -current
machines that I could clone, but I didn't think downgrading from
-current to -stable was possible...

Warner

From owner-freebsd-hackers  Tue Dec 16 21:13:26 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA09225
          for hackers-outgoing; Tue, 16 Dec 1997 21:13:26 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA09215
          for ; Tue, 16 Dec 1997 21:13:17 -0800 (PST)
          (envelope-from sclawson@bottles.cs.utah.edu)
Received: from bottles.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs)
	id WAA05905; Tue, 16 Dec 1997 22:13:02 -0700 (MST)
Received: by bottles.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id WAA03545; Tue, 16 Dec 1997 22:13:01 -0700
From: sclawson@bottles.cs.utah.edu (steve clawson)
Message-Id: <199712170513.WAA03545@bottles.cs.utah.edu>
Subject: Re: panic: blkfree: freeling free block/frag
To: ivt@gamma.ru (Igor Timkin)
Date: Tue, 16 Dec 1997 22:13:01 -0700 (MST)
Cc: tlambert@primenet.com, ivt@gamma.ru, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199712161442.RAA24936@crocus.gamma.ru> from "Igor Timkin" at Dec 16, 97 05:42:10 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Igor Timkin uttered:
> Unfortunally, I still have this problem.
> I had make newfs 5 days ago. But yestarday I got the same panic
> (uptime 5.2 days):

     I've been getting ``freeing free block'' panics fairly often when
our main server is doing a bunch of large compiles.  A couple weeks
ago I finally caught it in the act.  One of my compiles died and I
found a source file with exactly 8k of gunk, sitting nicely on an 8k
boundary (this was on an 8k/1k filesystem).  The interesting thing
about the file was it's list of direct blocks:

0: 179bb8
1: 179bc0
2: 179bc8
3: 179bd0
4: 179bd8
5:  79be0
6: 179be8
7:      0

     All nicely clustered...except for that sixth one.  At first I
thought that the clustering code was at fault, but disk block 79be0
was untouched, and the `real' disk block (179be0) had the correct data
for the new file.  So, the list of blocks in the inode was corrupted
sometime after the data blocks for the file were written.

     Unfortunately the crash dumps from subsequent panics were the
result of trying to delete an older file that had one of it's blocks
hijacked in this way, so I haven't been able to gather any more data
about it.  Could you check the list of direct blocks in the dinode
part of the in-core inode struct and see if there's corruption I'd be
grateful.



steve

-- 
// stephen clawson				sclawson@cs.utah.edu
// university of utah			        



From owner-freebsd-hackers  Tue Dec 16 21:13:46 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA09290
          for hackers-outgoing; Tue, 16 Dec 1997 21:13:46 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.systemresc.com (dave@[207.198.60.196])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA09257
          for ; Tue, 16 Dec 1997 21:13:36 -0800 (PST)
          (envelope-from dave@ns.systemresc.com)
From: dave@ns.systemresc.com
Received: from localhost (dave@localhost)
	by ns.systemresc.com (8.8.5/8.8.5) with SMTP id AAA10119
	for ; Wed, 17 Dec 1997 00:11:24 -0500 (EST)
Date: Wed, 17 Dec 1997 00:11:23 -0500 (EST)
To: freebsd-hackers@freebsd.org
Subject: cy driver over flows
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


Would someone be so kind as up upload the message with the fix
for the cy driver silo overflow problem...I have the Cyclades SM16 and had 
saved the message only to findout it was a reply and not the code that
needed to be changed...

dave...

System Resource
Internet Provider
Buffalo, Niagara Falls NY 



From owner-freebsd-hackers  Tue Dec 16 21:20:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA10188
          for hackers-outgoing; Tue, 16 Dec 1997 21:20:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 VAA10138;
          Tue, 16 Dec 1997 21:20:05 -0800 (PST)
          (envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
	id 0xiBia-0001Pr-00; Tue, 16 Dec 1997 21:08:24 -0800
Date: Tue, 16 Dec 1997 21:08:24 -0800 (PST)
From: Tom 
To: Charles Mott 
cc: chat@freebsd.org, softweyr@xmission.com, hackers@freebsd.org,
        isp@freebsd.org
Subject: Re: Support for secure http protocols
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 Dec 1997, Charles Mott wrote:

> "anonymous" ssh server on the web server, and then have the client

  Except that this does not deal with authentication.  This is what the
SSL certificate system does for you.

  Suggestion?  Go SSL.  It is standard now.  It can be used for
many protocols, as it can encapsulate nearly socket type date (stands for
"secure sockets layer").

  You can get apache-ssl from ports.  Get a certificate from a
certificate granting authority (ex.  Verisign), and your done.  Works with
all standard browser now.

Tom


From owner-freebsd-hackers  Tue Dec 16 22:09:22 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA13788
          for hackers-outgoing; Tue, 16 Dec 1997 22:09:22 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13783
          for ; Tue, 16 Dec 1997 22:09:17 -0800 (PST)
          (envelope-from tlambert@usr09.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id XAA16654;
	Tue, 16 Dec 1997 23:09:15 -0700 (MST)
Received: from usr09.primenet.com(206.165.6.209)
 via SMTP by smtp03.primenet.com, id smtpd016648; Tue Dec 16 23:09:15 1997
Received: (from tlambert@localhost)
	by usr09.primenet.com (8.8.5/8.8.5) id XAA12007;
	Tue, 16 Dec 1997 23:09:10 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712170609.XAA12007@usr09.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: avalon@coombs.anu.edu.au (Darren Reed)
Date: Wed, 17 Dec 1997 06:09:10 +0000 (GMT)
Cc: tlambert@primenet.com, daniel_sobral@voga.com.br, hackers@FreeBSD.ORG
In-Reply-To: <199712162159.OAA22556@smtp01.primenet.com> from "Darren Reed" at Dec 17, 97 08:58:30 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > No.  I said prerequisites could be automatically handled by the KLD
> > code, and so they are not necessary to specify in a kernel config.
> > This is very different than say they are not useful (frankly, with
> > the number of appeals I've made for graphical soloutions to problems,
> > I'm surprised you could even think I meant that ;-)).
> 
> Or you can try a kludge like solaris and have a symbol in a driver like
> "_depends_on" specify any pre/co-requisites.

Yes.  I'd say that this was no more of a kludge than "ldconfig", since
it's really nothing more than a cached value.  You could get the same
effect with ELF if you wanted by dynamically adding a new section of
type symbol with one value in it for each module you depend upon
once they've been identified.


> > So far, it's always been fixable with probe order.  Probe order can
> > be specified using a priority field in the data in the driver image
> > itself, and doesn't require a config file (or us one, in fact; the
> > priority for the LANCE probe in the GENERIC image, for example).
> 
> Bzzt.  You have to load all the drivers then, to determine all the
> priorities so you can probe them in the correct order.  For small
> memory machines, this might be somewhat of a problem when we get
> to the stage of having megabytes of driver modules.

Bzzt.  You only need to be able to access the symbol tables of all the
drivers (in pageable kernel memory) to be able to determine if a
particular driver exports a symbol the driver you are loading cares
about.

In point of fact, there may be multiple drivers exporting a needed
symbol, so you can't determine if the driver currently being checked
needs to be loaded after one or the other.  The correct way to deal
with this is probably to delay the driver in question until you try
one of the other driver(s) that export the needed symbol(s), and
they load successfully.

Then you can create an ELF section and cache the drivers the driver
in question needs to load after -- a prerequisites, but one that
is calculated dynamically without needing a human to intervene because
the kernel is too stupid on its own.


> My suggestion would be to have knowledge of *some* drivers builtin
> to the kernel and then have init load the rest in an order specified
> by some file.  If the file is corrupt or shit happens, bailout and start
> /sbin/sh.

Sure.  This is called "statically linking the drivers into the kernel
such that they can be discarded and their space reclaimed if the driver
is not used".


Typically this will be unnecessary, since a driver will always have
a lower priority than those drivers it depends on, unless the programmer
screwed up.  So if it gets to the point where the kernel will try to
load it, then if the external references are not present, the load
simply fails.

This avoids the problem with your "prerequisites" scheme where you could
potentially get into infinite loops because your dependency graph is
not acyclic like it should be.


> > The order of operation is dictated by the initialization order preference
> > data.  For your example of a third party driver to replace a FreeBSD
> > driver, the obvious answer is to give the third party driver a higher
> > priority.  If present, it will get to the hardware first, and the
> > FreeBSD driver's probe will fail, and it will be unloaded.
> 
> How about just replacing the file (i.e. module) on the disk ?  Renaming
> it, if you like.  That has worked for me in the past when dealing with
> these sorts of problems.  Or if you have a config file which mentions
> drivers to use, etc, you remove the FreeBSD one and add the 3rd party
> one instead.

No.  A config file implies a configurator.  We don't want one of those.

> btw, I can see FreeBSD taking a long time to bootup...

I can't.  We are presuming we can map the files for the drivers into
the kernel address space.

At the very least, this implies that we will only pull in the probe
sections, if we don't go further and page driver code not in the
paging path.

We may want to mark the sections "preload" if the device is a swap
critical or boot critical (before swap is going) device.


> > If the driver is not boot critical, and you don't want it loaded
> > (ie: an embedded system with a sound chip on the board but no
> > speakers attached, etc.), then don't put the module binary into
> > the directory where the kernel looks for module binaries.
> 
> This solution also handles the multiple revisions of the same driver
> problem.

Yes.  Not as neatly as giving the new version a higher priority.  The
problem here is that the old and new are likely to have the same name,
and you would have a namespace collision on the file name in any case.

This isn't as neat because you may need to down-rev a driver when the
new one fails to run.


> > This handles the "need/want to be loaded" cases.
> > 
> > Your kernel configurator is /bin/ln, /bin/rm, and /bin/cp.
> 
> How about /bin/mv ?  It's a start, but a bit more would be nice.

Well, I was thinking hard linking the module (or copying it, for
those people who don't trust hard links -- the same people who type
"ls' after deleting a file to make sure it's gone, from my experience
;-)) into the module directory from some common "possible modules"
directory.  I would prefer "cp" from the install media, but there's
still the "downrev the driver" scenario.


> > I haven't.  I've only discussed how the problems you are attempting to
> > solve via a kernel configurator should be solved instead, so that they
> > require less user intervention, and do not violate the principle of
> > least astonishment.
> 
> How about the KISS approach ?  Or has that fallen out of favour ?

Well, it's much simpler to not have something a user has to run than
to have something that the user has to run... that's KISS for user
interface.  If you mean KISS for implementation -- complexity for
programmers is the natural result of implementing KISS for user
interfaces, I'm afraid.  An elephant wearing size 9 jeans is going to
stick out somewhere...


					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  Tue Dec 16 22:38:15 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA15206
          for hackers-outgoing; Tue, 16 Dec 1997 22:38:15 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA14714
          for ; Tue, 16 Dec 1997 22:26:17 -0800 (PST)
          (envelope-from tlambert@usr09.primenet.com)
Received: (from daemon@localhost)
	by smtp02.primenet.com (8.8.8/8.8.8) id XAA03667;
	Tue, 16 Dec 1997 23:26:16 -0700 (MST)
Received: from usr09.primenet.com(206.165.6.209)
 via SMTP by smtp02.primenet.com, id smtpd003650; Tue Dec 16 23:26:05 1997
Received: (from tlambert@localhost)
	by usr09.primenet.com (8.8.5/8.8.5) id XAA12538;
	Tue, 16 Dec 1997 23:26:02 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712170626.XAA12538@usr09.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: j_mini@efn.org
Date: Wed, 17 Dec 1997 06:26:02 +0000 (GMT)
Cc: tlambert@primenet.com, daniel_sobral@voga.com.br, hackers@FreeBSD.ORG
In-Reply-To: <19971216174321.03686@micron.mini.net> from "Jonathan Mini" at Dec 16, 97 05:43:21 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>   Please understand that I am attacking this as two seperate systems :
> 
> 	1) A system which manages building of multiple options or modules into
> 	one or more modules which together make a "kernel." (this means support
> 	for both a static kernel and a completely dynamic kernel. Both extremes
> 	will be useful to different people, but the majority of us will want
> 	something in the middle)

This is useful, but I would claim it's a second system problem, ie: it's
not something you want to solve in an initial revision.  Since it's
logically seperate, you won't architect it into impossibility no matter
what your approach on the other problem.


> 	2) Another system which manages that management. This is the "kernel
> 	configuratior" and one will be neccisary to build static kernels, no
> 	matter how you look at the problem. While I am all for dynamic kernels,
> 	a static kernel is still very useful, and I VERY much do not want to
> 	see that possibility go away.

The static kernel is, I think, an ld option to the Makefile for the
kernel, probably set in /etc/make.conf.

The ld option dictates what sections you choose to link, and is
referenced via /usr/share/bsd.kern.mk.

As a rough example (this is not verbatim, no syntactic attacks, please),
boot-critical devices would have:

#pragma section('text',SECT_TEXT_BOOT_CRITICAL)
#pragma section('data',SECT_DATA_BOOT_CRITICAL)

At the top.

For dynamically loadable devices, you would have:

#pragma section('text',SECT_TEXT_DYNAMIC)
#pragma section('data',SECT_DATA_DYNAMIC)

One option would tell ld to link both *_BOOT_CRITICAL and *_DYNAMIC
ELF sections into the kernel file.

The other setting would tell ld to link only *_BOOT_CRITICAL ELF
sections into the kernel file, and to place objects with *_DYNAMIC
sections into /libexec/drivers (or wherever dynamic driver files
go so the kernel can find them).


Neither of these options require a configurator, only a programmer.  8-).


> 	  It should also be noted that this tool will be needed to configure
> 	compile-time options of the modules.

Compile time options should go away.  Period.  All of them.  They
are bogus.

Runtime options are manipulable by causing the registration of sets
of symbol/type/default_value/validation_function into a MIB.  sysctl
is a MIB manager.  LDAP is a MIB manager.  SNMP is a MIB manager.

Management of the values is via MIB manager.  Values are persistent
unless their type dictates otherwise, and you can always get ther
default back later, if necessary.


>   Currently, I haven't even begun to think about part 2, but am instead trying
> to come up with an easy-to-maintain and extendable method of implementing part
> 1. I am to replace the config(8) utility and it's underlying build method with
> something that will remove many of the problems of config(8). 

Or... you could remove all of the problems by removing config in
its entirety instead of providing a replacement.  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  Tue Dec 16 22:41:58 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA15561
          for hackers-outgoing; Tue, 16 Dec 1997 22:41:58 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 WAA15554
          for ; Tue, 16 Dec 1997 22:41:51 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id RAA01913;
	Wed, 17 Dec 1997 17:05:39 +1030 (CST)
Message-Id: <199712170635.RAA01913@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: sclawson@bottles.cs.utah.edu (steve clawson)
cc: ivt@gamma.ru (Igor Timkin), tlambert@primenet.com,
        freebsd-hackers@freebsd.org
Subject: Re: panic: blkfree: freeling free block/frag 
In-reply-to: Your message of "Tue, 16 Dec 1997 22:13:01 PDT."
             <199712170513.WAA03545@bottles.cs.utah.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 17:05:38 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>      I've been getting ``freeing free block'' panics fairly often when
> our main server is doing a bunch of large compiles.  A couple weeks
> ago I finally caught it in the act.  One of my compiles died and I
> found a source file with exactly 8k of gunk, sitting nicely on an 8k
> boundary (this was on an 8k/1k filesystem).  The interesting thing
> about the file was it's list of direct blocks:
> 
> 0: 179bb8
> 1: 179bc0
> 2: 179bc8
> 3: 179bd0
> 4: 179bd8
> 5:  79be0
> 6: 179be8
> 7:      0
> 
>      All nicely clustered...except for that sixth one.  At first I
> thought that the clustering code was at fault, but disk block 79be0
> was untouched, and the `real' disk block (179be0) had the correct data
> for the new file.  So, the list of blocks in the inode was corrupted
> sometime after the data blocks for the file were written.

Single-bit memory error, perhaps?  Still, keep an eye on it...

mike



From owner-freebsd-hackers  Tue Dec 16 23:18:39 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA17743
          for hackers-outgoing; Tue, 16 Dec 1997 23:18:39 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 XAA17706
          for ; Tue, 16 Dec 1997 23:18:13 -0800 (PST)
          (envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 19824 invoked by uid 1001); 17 Dec 1997 07:17:47 +0000 (GMT)
To: grog@lemis.com
Cc: hackers@FreeBSD.ORG
Subject: Re: 3com 3c509 card
In-Reply-To: Your message of "Wed, 17 Dec 1997 11:38:01 +1030"
References: <19971217113801.53802@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: Wed, 17 Dec 1997 08:17:47 +0100
Message-ID: <19822.882343067@verdi.nethelp.no>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> I've been doing some experiments with ftps on my local network, but
> the results have been puzzling, and until I know what's going on, I'm
> not going to go into too much detail.  But I've noticed that I'm
> getting very high interrupt times on a P5/133 (up to over 50%) when
> receiving large files (40 MB).  I've also noticed that the transfer
> starts at about 1 MB/s, but after about 10 MB there are problems, and
> the final transfer rate is often less than 500 kB/s.  This is not what
> I measured on the same systems about a year ago.  I may follow up on
> this if I find time.

If you're trying to measure measure network performance, why don't you
use a tool which is suitable for the job? FTP is definitely not a good
tool for this job. I'd suggest ttcp or NetPerf.

Btw, I've measured more than a megabyte/s myself with NE2000 clones
(Kingston) on a 486, using ttcp.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

From owner-freebsd-hackers  Tue Dec 16 23:28:56 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA18503
          for hackers-outgoing; Tue, 16 Dec 1997 23:28:56 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 XAA18486
          for ; Tue, 16 Dec 1997 23:28:29 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id RAA01879;
          Wed, 17 Dec 1997 17:57:21 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971217175721.26785@lemis.com>
Date: Wed, 17 Dec 1997 17:57:21 +1030
From: Greg Lehey 
To: sthaug@nethelp.no
Cc: hackers@FreeBSD.ORG
Subject: Re: 3com 3c509 card
References: <19971217113801.53802@lemis.com> <19822.882343067@verdi.nethelp.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <19822.882343067@verdi.nethelp.no>; from sthaug@nethelp.no on Wed, Dec 17, 1997 at 08:17:47AM +0100
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, Dec 17, 1997 at 08:17:47AM +0100, sthaug@nethelp.no wrote:
>> I've been doing some experiments with ftps on my local network, but
>> the results have been puzzling, and until I know what's going on, I'm
>> not going to go into too much detail.  But I've noticed that I'm
>> getting very high interrupt times on a P5/133 (up to over 50%) when
>> receiving large files (40 MB).  I've also noticed that the transfer
>> starts at about 1 MB/s, but after about 10 MB there are problems, and
>> the final transfer rate is often less than 500 kB/s.  This is not what
>> I measured on the same systems about a year ago.  I may follow up on
>> this if I find time.
>
> If you're trying to measure measure network performance, why don't you
> use a tool which is suitable for the job? FTP is definitely not a good
> tool for this job.

Good idea.  This wasn't so much "testing" as confirmation of what I
had seen before.  The results surprised me, so I took a closer look.

> I'd suggest ttcp or NetPerf.

Thanks.  Where do I get them?

> Btw, I've measured more than a megabyte/s myself with NE2000 clones
> (Kingston) on a 486, using ttcp.

Yes, there's more to this than meets the eye.  But I don't know if I
have time to look at it.

Greg

From owner-freebsd-hackers  Tue Dec 16 23:47:57 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA20087
          for hackers-outgoing; Tue, 16 Dec 1997 23:47:57 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA20074
          for ; Tue, 16 Dec 1997 23:47:51 -0800 (PST)
          (envelope-from sclawson@bottles.cs.utah.edu)
Received: from bottles.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs)
	id AAA07935; Wed, 17 Dec 1997 00:47:38 -0700 (MST)
Received: by bottles.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id AAA04275; Wed, 17 Dec 1997 00:47:33 -0700
From: sclawson@bottles.cs.utah.edu (steve clawson)
Message-Id: <199712170747.AAA04275@bottles.cs.utah.edu>
Subject: Re: panic: blkfree: freeling free block/frag
To: mike@smith.net.au (Mike Smith)
Date: Wed, 17 Dec 1997 00:47:32 -0700 (MST)
Cc: sclawson@bottles.cs.utah.edu, ivt@gamma.ru, tlambert@primenet.com,
        freebsd-hackers@freebsd.org
In-Reply-To: <199712170635.RAA01913@word.smith.net.au> from "Mike Smith" at Dec 17, 97 05:05:38 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Mike Smith uttered:
> Single-bit memory error, perhaps?  Still, keep an eye on it...

     Probably.  The only real culprit for parity problems right now is
the L2 cache of the processor, since we've got the version of the
Pentium II that dosen't do ECC on it's L2 cache, and the memory in the
machine is 36bit (yes, parity checking was/is enabled).  Unfortunately
when we were buying the machine we didn't know there were two
different versions of the chip.


steve

-- 
// stephen clawson				sclawson@cs.utah.edu
// university of utah			        


From owner-freebsd-hackers  Tue Dec 16 23:51:17 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA20378
          for hackers-outgoing; Tue, 16 Dec 1997 23:51:17 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 XAA20368
          for ; Tue, 16 Dec 1997 23:51:10 -0800 (PST)
          (envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 20088 invoked by uid 1001); 17 Dec 1997 07:51:04 +0000 (GMT)
To: grog@lemis.com
Cc: hackers@FreeBSD.ORG
Subject: Re: 3com 3c509 card
In-Reply-To: Your message of "Wed, 17 Dec 1997 17:57:21 +1030"
References: <19971217175721.26785@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: Wed, 17 Dec 1997 08:51:04 +0100
Message-ID: <20086.882345064@verdi.nethelp.no>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > I'd suggest ttcp or NetPerf.
> 
> Thanks.  Where do I get them?

NetPerf is in the ports collection, benchmarks/netperf. ttcp exists in
several slightly different versions on the net, see for instance

	ftp://ftp.ntnu.no/pub/unix/network/ttcp/

The original is from SGI, and is still on one of their servers as far as
I remember. Be especially aware of the -s option, which has different
meanings in different versions.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

From owner-freebsd-hackers  Wed Dec 17 00:41:38 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA23251
          for hackers-outgoing; Wed, 17 Dec 1997 00:41:38 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from isdn-kukulies.dialup.rwth-aachen.de (isdn-kukulies.dialup.RWTH-Aachen.DE [137.226.145.27])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA23212;
          Wed, 17 Dec 1997 00:41:26 -0800 (PST)
          (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE)
Received: (from kuku@localhost) by isdn-kukulies.dialup.rwth-aachen.de (8.8.6/8.6.9) id JAA20651; Wed, 17 Dec 1997 09:41:24 +0100 (MET)
Date: Wed, 17 Dec 1997 09:41:24 +0100 (MET)
From: "Christoph P. Kukulies" 
Message-Id: <199712170841.JAA20651@isdn-kukulies.dialup.rwth-aachen.de>
To: ports@freebsd.org
Subject: Wine success story
Cc: freebsd-hackers@freebsd.org
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Just FYI:

I installed the most recent version of Wine (Wine-971130 from sunsite).
And despite one quirk in memory/virtual.c where I had to get
acoross the fact that FreeBSD doesn't do synchronuous memory
syncs (Linux: ) I was able to throw it at my
C:\WIN95 directory.

I ran 

wine progman

and voila, my Win95 desktop appeared neatly sorted in progman program groups.
The fonts and the colors/hatching/dithering a bit strange though.

Now, the big success: Freecell works!

So, no more need to boot a Win95/NT System :-)

Kidding aside, a lot of 32 bit apps do not work since so many functions
of the 32 bit API if any at all are unimplemented but they seem on a
good trip to there.

What I'm concerned about though is the fact of this unimplemented
MS_SYNC feature. That's why I'm cross posting this to -hackers also.

--
Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de

From owner-freebsd-hackers  Wed Dec 17 01:16:47 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA25327
          for hackers-outgoing; Wed, 17 Dec 1997 01:16:47 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 BAA25319;
          Wed, 17 Dec 1997 01:16:41 -0800 (PST)
          (envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
	by dyson.iquest.net (8.8.8/8.8.8) id EAA02416;
	Wed, 17 Dec 1997 04:16:24 -0500 (EST)
	(envelope-from toor)
Message-Id: <199712170916.EAA02416@dyson.iquest.net>
Subject: Re: Wine success story
In-Reply-To: <199712170841.JAA20651@isdn-kukulies.dialup.rwth-aachen.de> from "Christoph P. Kukulies" at "Dec 17, 97 09:41:24 am"
To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph P. Kukulies)
Date: Wed, 17 Dec 1997 04:16:24 -0500 (EST)
Cc: ports@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
From: "John S. Dyson" 
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

Christoph P. Kukulies said:
> 
> What I'm concerned about though is the fact of this unimplemented
> MS_SYNC feature. That's why I'm cross posting this to -hackers also.
> 
You are right, I neglected to define a symbol for MS_SYNC :-(.  It has
caused a few troubles, and I recently added an MS_SYNC to /sys/sys/mman.h
in both -current and -stable (however, that does not retrofit CDROMS :-).)
If you add a local definition of "0" to MS_SYNC in either your
/usr/include/sys/mman.h file or in one of the wine include files, it should
work:

#define MS_SYNC 0

-- 
John                  | Never try to teach a pig to sing,
dyson@freebsd.org     | it just makes you look stupid,
jdyson@nc.com         | and it irritates the pig.

From owner-freebsd-hackers  Wed Dec 17 02:30:03 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA29040
          for hackers-outgoing; Wed, 17 Dec 1997 02:30:03 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA29004
          for ; Wed, 17 Dec 1997 02:29:56 -0800 (PST)
          (envelope-from abial@korin.warman.org.pl)
Received: from localhost (abial@localhost)
	by korin.warman.org.pl (8.8.8/8.8.5) with SMTP id LAA09072;
	Wed, 17 Dec 1997 11:32:19 +0100 (CET)
Date: Wed, 17 Dec 1997 11:32:18 +0100 (CET)
From: Andrzej Bialecki 
To: Lee Cremeans 
cc: moncrg@bt340707.res.ray.com, hackers@FreeBSD.ORG
Subject: Re: atapi.c || wierd hardware
In-Reply-To: <19971216.233119.5295.1.wakkym@juno.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 Tue, 16 Dec 1997, Lee Cremeans wrote:

> 
> On Tue, 16 Dec 1997 19:44:08 -0500 (EST) "Gregory D. Moncreaff"
>  writes:
> >
> >I've got a couple of IDE cdroms that, on boot/probe, 
> >put a line as follows in the log:
> >
> >wdc1: unit 0 (atapi): , 
> >removable, dma, iordy
> >
> >(lots of whitespace between 'NEC' and 'CD')

And how about this:

wdc1: unit 0 (atapi): , removable, intr, dma, iordy
wcd0: 1377Kb/sec, 256Kb cache, audio play, 255 volume levels, ejectable tray
wcd0: no disc inside, unlocked
wdc1: unit 1 (atapi): <\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?/\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?>, removable, cmd3, drq3, ovlap, idma, 
iordis
wdc1: unit 1: unknown ATAPI protocol=3

But it works ok... I simply got used to this.

Now, inside my home machine I have a Pioneer ATAPI unit, which is reported
by kernel as  - little/big endian confusion on part of
manufacturer :-)

I conclude from this that vendors often have peculiar understanding of
"standards"...

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  Wed Dec 17 03:24:12 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA01703
          for hackers-outgoing; Wed, 17 Dec 1997 03:24:12 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA01652
          for ; Wed, 17 Dec 1997 03:23:39 -0800 (PST)
          (envelope-from daniel_sobral@voga.com.br)
From: daniel_sobral@voga.com.br
Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997))  id 03256570.003E9584 ; Wed, 17 Dec 1997 08:23:35 -0300
X-Lotus-FromDomain: VOGA
To: tlambert@primenet.com
cc: hackers@FreeBSD.ORG
Message-ID: <83256570.003AE6C5.00@papagaio.voga.com.br>
Date: Wed, 17 Dec 1997 08:23:33 -0300
Subject: Re: Why so many steps to build new kernel?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


> No.  I said prerequisites could be automatically handled by the KLD
> code, and so they are not necessary to specify in a kernel config.
> This is very different than say they are not useful (frankly, with
> the number of appeals I've made for graphical soloutions to problems,
> I'm surprised you could even think I meant that ;-)).

Well, I was surprised you seemed to say that.

> So far, it's always been fixable with probe order.  Probe order can
> be specified using a priority field in the data in the driver image
> itself, and doesn't require a config file (or us one, in fact; the
> priority for the LANCE probe in the GENERIC image, for example).

[and]

> If the driver is not boot critical, and you don't want it loaded
> (ie: an embedded system with a sound chip on the board but no
> speakers attached, etc.), then don't put the module binary into
> the directory where the kernel looks for module binaries.

How do you propose I do that? Go around on /whatever, using whatis and mv
to remove unwanted files*? I'd rather use a graphical tool.

And that's the whole point. At *some* point in the process, I _must_ have
the _option_ of choosing what goes in and what stays out of kernel, no
matter when or how that thing is loaded. It would be nice to have a
nice-looking tool to do that, though that's of secondary concern. That tool
must use a file with the metainformation it needs (e.g., sound drivers are
likely to get cascaded, and, thus, the higher level ones has the lower
level ones as prereq).

It is about this file we are talking about, not about how the kernel gets
configured. We could _change_ the way the kernel gets configured (e.g.,
sysctl instead of compile-time) without changing this file, because the
content remains the same: what options do I have? how are they related to
each other? what the hell that option really mean?

Going further,

> Well, I think you don't need to tune the syscons buffer the way
> you are presenting tuning it.  I think that if it's a tunable, it
> should be a runtime tunable, and you should be able to access it
> via a persistant MIB.  A directory.  If this is what got you
> confused about rc.conf (many sysctl "MIB" tunables persistance are
> kludged by existing in rc.conf now), then you misaprehended me.

At _some_ point the syscon buffer must be configured. Like IRQ on my ISA
ed0 must configured at some point. Like the choice between vt and syscon
must be made at some point.
Since these are all features of the "kernel", that's obviously the "kernel
configuration". Though the process by which the kernel gets configured may
(should) change, the user must still have control over all these options
(well, most of them). How the kernel configurator will do it's work will
change, but not the need for it.

As a side point,

> I think rc.conf is an abomination before God.  For one thing,
> it lives in a directory which, in my ideal world, is mounted
> read-only.  So you wouldn't be able to "conf" the thing anyway.

The sysctl options and rc.conf may as well be included, at a later time, in
the "kernel configurator".


*  You also said:

> Your kernel configurator is /bin/ln, /bin/rm, and /bin/cp.

[visions of Solaris' way of rc -- I hope you didn't think through on the
above]



From owner-freebsd-hackers  Wed Dec 17 03:35:43 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA02254
          for hackers-outgoing; Wed, 17 Dec 1997 03:35:43 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA02249
          for ; Wed, 17 Dec 1997 03:35:35 -0800 (PST)
          (envelope-from daniel_sobral@voga.com.br)
From: daniel_sobral@voga.com.br
Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997))  id 03256570.003FAE48 ; Wed, 17 Dec 1997 08:35:33 -0300
X-Lotus-FromDomain: VOGA
To: avalon@coombs.anu.edu.au
cc: tlambert@primenet.com, hackers@FreeBSD.ORG
Message-ID: <83256570.003F9B60.00@papagaio.voga.com.br>
Date: Wed, 17 Dec 1997 08:35:32 -0300
Subject: Re: Why so many steps to build new kernel?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


> How about the KISS approach ?  Or has that fallen out of favour ?

It did...



From owner-freebsd-hackers  Wed Dec 17 03:50:35 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA03090
          for hackers-outgoing; Wed, 17 Dec 1997 03:50:35 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from crocus.gamma.ru (crocus.gamma.ru [193.124.255.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA03064
          for ; Wed, 17 Dec 1997 03:50:25 -0800 (PST)
          (envelope-from ivt@crocus.gamma.ru)
Received: (from ivt@localhost) by crocus.gamma.ru (8.8.5/8.7.3) id OAA09853; Wed, 17 Dec 1997 14:49:38 +0300 (MSK)
Message-Id: <199712171149.OAA09853@crocus.gamma.ru>
Subject: Re: panic: blkfree: freeling free block/frag
In-Reply-To: <3497337D.4487EB71@whistle.com> from Julian Elischer at "Dec 16, 97 06:05:49 pm"
To: julian@whistle.com (Julian Elischer)
Date: Wed, 17 Dec 1997 14:49:38 +0300 (MSK)
Cc: tlambert@primenet.com, ivt@gamma.ru, freebsd-hackers@freebsd.org
From: "Igor Timkin" 
Organization: Gamma Ltd., Moscow, Russia
X-Class: Fast
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

Julian Elischer writes:
> hey!
> how come all this kernel is linked to run at 0xe0000000
> rather than 0xf0000000?

Yes:
LOAD_ADDRESS?=		E0100000
#define NKPDE		127	/* addressable number of page tables/pde's */
#define VM_KMEM_SIZE	(96 * 1024 * 1024)


From owner-freebsd-hackers  Wed Dec 17 04:00:26 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA03787
          for hackers-outgoing; Wed, 17 Dec 1997 04:00:26 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA03775
          for ; Wed, 17 Dec 1997 04:00:16 -0800 (PST)
          (envelope-from daniel_sobral@voga.com.br)
From: daniel_sobral@voga.com.br
Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997))  id 03256570.0041EA5C ; Wed, 17 Dec 1997 08:59:58 -0300
X-Lotus-FromDomain: VOGA
To: tlambert@primenet.com
cc: hackers@FreeBSD.ORG
Message-ID: <83256570.0041CF6C.00@papagaio.voga.com.br>
Date: Wed, 17 Dec 1997 08:59:55 -0300
Subject: Re: Why so many steps to build new kernel?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


> Neither of these options require a configurator, only a programmer.  8-).

I see...



From owner-freebsd-hackers  Wed Dec 17 04:02:17 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA03973
          for hackers-outgoing; Wed, 17 Dec 1997 04:02:17 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 EAA03961
          for ; Wed, 17 Dec 1997 04:02:10 -0800 (PST)
          (envelope-from ernie!bert.kts.org!hm@ppp.net)
Received: from ernie by casparc.ppp.net with uucp
	(Smail3.1.28.1 #1) id m0xiIAs-0032iBC; Wed, 17 Dec 97 13:02 MET
Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org
	via sendmail with smtp
	id 
	for ; Wed, 17 Dec 1997 11:48:32 +0100 (MET)
	(Smail-3.2.0.91 1997-Jan-14 #2 built 1997-Feb-8)
Received: by bert.kts.org
	via sendmail with stdio
	id 
	for hackers@FreeBSD.ORG; Wed, 17 Dec 1997 11:40:12 +0100 (CET)
	(Smail-3.2.0.94 1997-Apr-22 #7 built 1997-Jul-4)
Message-Id: 
From: hm@kts.org (Hellmuth Michaelis)
Subject: Re: 3com 3c509 card
In-Reply-To: <20086.882345064@verdi.nethelp.no> from "sthaug@nethelp.no" at "Dec 17, 97 08:51:04 am"
To: sthaug@nethelp.no
Date: Wed, 17 Dec 1997 11:40:12 +0100 (CET)
Cc: hackers@FreeBSD.ORG
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

sthaug@nethelp.no wrote:

> NetPerf is in the ports collection, benchmarks/netperf. ttcp exists in
> several slightly different versions on the net, see for instance

There is a new version of ttcp available, nttcp. Its also in the ports ....

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  Wed Dec 17 06:07:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA13325
          for hackers-outgoing; Wed, 17 Dec 1997 06:07:42 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from klokan.sh.cvut.cz (klokan.sh.cvut.cz [193.84.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA13320
          for ; Wed, 17 Dec 1997 06:07:35 -0800 (PST)
          (envelope-from J.Klaus@sh.cvut.cz)
Received: from skunk.sh.cvut.cz (skunk.sh.cvut.cz [194.108.141.194]) by klokan.sh.cvut.cz (8.6.12/8.6.9) with ESMTP id PAA01602 for ; Wed, 17 Dec 1997 15:06:50 +0100
Received: from SKUNK/SpoolDir by skunk.sh.cvut.cz (Mercury 1.31);
    17 Dec 97 15:06:50 +0100
Received: from SpoolDir by SKUNK (Mercury 1.31); 17 Dec 97 15:06:26 +0100
From: "Jaroslav Klaus" 
Organization:  sh 11
To: freebsd-hackers@freebsd.org
Date:          Wed, 17 Dec 1997 15:06:21 +0100 (MET)
Subject:       How to close(kill) sockets?
X-Confirm-Reading-To: "Jaroslav Klaus" 
X-pmrqc:       1
Priority: normal
X-mailer: Pegasus Mail v3.40
Message-ID: <255CD94D87@skunk.sh.cvut.cz>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hello,

I killed nmbd (netbios) but socket is still opened. Is it possible to 
close(kill) this socket as root? I don't want to wait for timeout.
Thank U 
----
Jarda

From owner-freebsd-hackers  Wed Dec 17 07:06:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA16577
          for hackers-outgoing; Wed, 17 Dec 1997 07:06:42 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 HAA16561
          for ; Wed, 17 Dec 1997 07:06:36 -0800 (PST)
          (envelope-from dennis@etinc.com)
Received: from dbsys.etinc.com (dbsys.etinc.com [204.141.95.138]) by etinc.com (8.8.3/8.6.9) with SMTP id KAA13478; Wed, 17 Dec 1997 10:09:33 -0500 (EST)
Message-Id: <3.0.32.19971217100825.00d45930@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 17 Dec 1997 10:08:26 -0500
To: Greg Lehey 
From: dennis 
Subject: Re: ifconfig reports bogus netmask
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 11:34 AM 12/17/97 +1030, Greg Lehey wrote:
>On Tue, Dec 16, 1997 at 07:38:10PM -0500, dennis wrote:
>> At 08:59 AM 12/17/97 +1030, you wrote:
>>> On Tue, Dec 16, 1997 at 10:39:08AM -0500, dennis wrote:
>>>>
>>>> Is there any chance of this getting fixed? Its been broken forever. I'm
>>>> talking about PTP interfaces, where the routes are inherently host
>>>> mask routes. ifconfig reports the natural mask or whatever you give
>>>> it....and its rather confusing trying to explain to the woodchucks that
>>>> its wrong.
>>>
>>> Well, ifconfig reports the net mask that is set.  And yes, it's
>>> inappropriate for "real" point-to-point interfaces.  But it's not the
>>> reporting that's wrong, it's the setting.  Just set all ones when
>>> setting the interface, and you'll be OK.
>>>
>>> I suppose I should mention that there's a sizeable minority who think
>>> this is the way the net mask *should* be.  Maybe one of them will
>>> explain, I keep forgetting.
>>
>> I disagree. The route is expicitly set by the command to be a host route,
>> but the mask (and I'm talking about the case where no mask is specified
>> in the ifconfig) is set to the natural mask (class, that is).
>
>I'm not sure what you're disagreeing with here.  I said that ifconfig
>is just reporting the net mask.  I believe this to be true.  I also
>said that ifconfig will set the net mask based on the address class,
>not on the type of connection.  You seem to be saying the same thing.
>What are you disagreeing with?

A non-host mask implies that the interface is on a network with that mask,
which is not the case with a PTP connection.

>
>> Even if you specifiy a non-host mask, a host route is set...if that is the
>> case then only a host mask should be allowed, and a host mask should
>> be forced. You SHOULD be able to override the host setting, that is, if a
>> mask is specified explicitly then the route should be set according to the
>> netmask.
>
>Good point.  I suppose we could consider it a bug.  But, as I say,
>some people expect a different net mask.  My ISP (Telstra, Australia's
>telco, and a reasonably experienced provider) asks me to set a net
>mask of 0xffffffc0 for some reason.  I wonder why.  I notice now that
>I look at it that I'm not complying.

Your ISP, unfortunately, most likely uses Ciscos, which CANNOT route to
hosts. Ciscos can only route to nets, so you must set the PTP interface
to a subnet mask. This is  a waste of a net and arguably wrong (since there
is, in fact, no network), but we live in a world of ciscoheads. With unix
you only need use 2 addresses per  PTP interface..with ciscos you need to
use an entire subnet.

Dennis

From owner-freebsd-hackers  Wed Dec 17 07:40:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA19102
          for hackers-outgoing; Wed, 17 Dec 1997 07:40:51 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA19091
          for ; Wed, 17 Dec 1997 07:40:42 -0800 (PST)
          (envelope-from rivers@dignus.com)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
          by elvis.vnet.net (8.8.8/8.8.4) with ESMTP
	  id KAA25287; Wed, 17 Dec 1997 10:40:11 -0500 (EST)
Received: from lakes.dignus.com (lakes [10.0.0.3])
	by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id LAA20906;
	Wed, 17 Dec 1997 11:03:04 -0500 (EST)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.7/8.6.9) id KAA17178; Wed, 17 Dec 1997 10:45:50 -0500 (EST)
Date: Wed, 17 Dec 1997 10:45:50 -0500 (EST)
From: Thomas David Rivers 
Message-Id: <199712171545.KAA17178@lakes.dignus.com>
To: mike@smith.net.au, sclawson@bottles.cs.utah.edu
Subject: Re: panic: blkfree: freeling free block/frag
Cc: freebsd-hackers@FreeBSD.ORG, ivt@gamma.ru, tlambert@primenet.com
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> Mike Smith uttered:
> > Single-bit memory error, perhaps?  Still, keep an eye on it...
> 
>      Probably.  The only real culprit for parity problems right now is
> the L2 cache of the processor, since we've got the version of the
> Pentium II that dosen't do ECC on it's L2 cache, and the memory in the
> machine is 36bit (yes, parity checking was/is enabled).  Unfortunately
> when we were buying the machine we didn't know there were two
> different versions of the chip.

 While I wouldn't discount such a possibility - I'd point out that
I've been able to reproduce this problem on three machines.  It seems
unlikely that all three had the same parity errors (each has parity
ram, and would thus, presumably, get NMIs for any RAM problems.)

	- Dave Rivers -


From owner-freebsd-hackers  Wed Dec 17 07:47:28 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA19792
          for hackers-outgoing; Wed, 17 Dec 1997 07:47:28 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA19238
          for ; Wed, 17 Dec 1997 07:42:21 -0800 (PST)
          (envelope-from karl@Mars.mcs.net)
Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id JAA08123; Wed, 17 Dec 1997 09:41:57 -0600 (CST)
Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id JAA04382; Wed, 17 Dec 1997 09:41:57 -0600 (CST)
Message-ID: <19971217094157.37862@mcs.net>
Date: Wed, 17 Dec 1997 09:41:57 -0600
From: Karl Denninger  
To: dennis 
Cc: Greg Lehey , hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask
References: <3.0.32.19971217100825.00d45930@etinc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <3.0.32.19971217100825.00d45930@etinc.com>; from dennis on Wed, Dec 17, 1997 at 10:08:26AM -0500
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, Dec 17, 1997 at 10:08:26AM -0500, dennis wrote:
> At 11:34 AM 12/17/97 +1030, Greg Lehey wrote:
> Your ISP, unfortunately, most likely uses Ciscos, which CANNOT route to
> hosts. Ciscos can only route to nets, so you must set the PTP interface
> to a subnet mask. This is  a waste of a net and arguably wrong (since there
> is, in fact, no network), but we live in a world of ciscoheads. With unix
> you only need use 2 addresses per  PTP interface..with ciscos you need to
> use an entire subnet.
> 
> Dennis

Balderdash.

CISCOs can run un-numbered interfaces (the proper way to do a PTP link where
the terminal end is not a network) and further, can in fact handle and 
advertise host routes.

--
-- 
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly to FULL DS-3 Service
			     | NEW! K56Flex support on ALL modems
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost

From owner-freebsd-hackers  Wed Dec 17 08:28:05 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA22139
          for hackers-outgoing; Wed, 17 Dec 1997 08:28:05 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from borges.uol.com.br (borges.uol.com.br [200.246.5.87])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA22099
          for ; Wed, 17 Dec 1997 08:27:49 -0800 (PST)
          (envelope-from capriotti@geocities.com)
Received: from com-pipp01 (node03.mpc.com.br [200.246.0.3])
	by borges.uol.com.br (8.8.8/8.8.8) with SMTP id OAA22388;
	Wed, 17 Dec 1997 14:27:36 -0200 (EDT)
Message-Id: <3.0.1.32.19971216232646.00766974@pop.mpc.com.br>
X-Sender: capriotti@pop.mpc.com.br
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Tue, 16 Dec 1997 23:26:46 -0200
To: sthaug@nethelp.no, grog@lemis.com
From: Capriotti 
Subject: Re: 3com 3c509 card
Cc: hackers@FreeBSD.ORG
In-Reply-To: <19822.882343067@verdi.nethelp.no>
References: 
 <19971217113801.53802@lemis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've heard that some 3com cards have only 3KB buffer; Have any of you 
heard of it ?


-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBNJcqVPL8xjieM8CoEQJYhgCfcspDe1IS5pYoPhGfNcPyyZL9iM4AmgNZ
tlBiMFukwknZYap4TNxsr4uZ
=+Scl
-----END PGP SIGNATURE-----


From owner-freebsd-hackers  Wed Dec 17 08:30:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA22310
          for hackers-outgoing; Wed, 17 Dec 1997 08:30:04 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from echonyc.com (echonyc.com [198.67.15.2])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA22267
          for ; Wed, 17 Dec 1997 08:29:59 -0800 (PST)
          (envelope-from benedict@echonyc.com)
Received: from localhost (benedict@localhost)
	by echonyc.com (8.8.7/8.8.7) with SMTP id LAA24014;
	Wed, 17 Dec 1997 11:29:34 -0500 (EST)
Date: Wed, 17 Dec 1997 11:29:33 -0500 (EST)
From: Snob Art Genre 
To: dennis 
cc: Greg Lehey , hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask
In-Reply-To: <3.0.32.19971217100825.00d45930@etinc.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 Dec 1997, dennis wrote:

> Your ISP, unfortunately, most likely uses Ciscos, which CANNOT route to
> hosts. Ciscos can only route to nets, so you must set the PTP interface
> to a subnet mask. This is  a waste of a net and arguably wrong (since there
> is, in fact, no network), but we live in a world of ciscoheads. With unix
> you only need use 2 addresses per  PTP interface..with ciscos you need to
> use an entire subnet.

Tsk -- you haven't read your Stevens.  You only need one address per PTP
interface, on the downlink side.  The host acting as terminal server can
use one IP address for all its PTP interfaces.



 Ben

"You have your mind on computers, it seems." 


From owner-freebsd-hackers  Wed Dec 17 10:48:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA01497
          for hackers-outgoing; Wed, 17 Dec 1997 10:48:21 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01061
          for ; Wed, 17 Dec 1997 10:43:11 -0800 (PST)
          (envelope-from abial@korin.warman.org.pl)
Received: from localhost (abial@localhost)
	by korin.warman.org.pl (8.8.8/8.8.5) with SMTP id TAA01174;
	Wed, 17 Dec 1997 19:44:10 +0100 (CET)
Date: Wed, 17 Dec 1997 19:44:08 +0100 (CET)
From: Andrzej Bialecki 
To: Karl Denninger 
cc: dennis , Greg Lehey ,
        hackers@FreeBSD.ORG
Subject: Re: ifconfig reports bogus netmask
In-Reply-To: <19971217094157.37862@mcs.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 Wed, 17 Dec 1997, Karl Denninger wrote:

> On Wed, Dec 17, 1997 at 10:08:26AM -0500, dennis wrote:

> > use an entire subnet.
> > 
> > Dennis
> 
> Balderdash.
> 
> CISCOs can run un-numbered interfaces (the proper way to do a PTP link where
> the terminal end is not a network) and further, can in fact handle and 
> advertise host routes.

And even if you don't want to run unnumbered interface, you waste only 4
addresses (x.x.x.x/255.255.255.252), and even these can be private (e.g.
10.x.x.x)... So I don't see that much waste here.

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  Wed Dec 17 10:48:39 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA01538
          for hackers-outgoing; Wed, 17 Dec 1997 10:48:39 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01054
          for ; Wed, 17 Dec 1997 10:42:55 -0800 (PST)
          (envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
	by smtp01.primenet.com (8.8.8/8.8.8) id LAA14741;
	Wed, 17 Dec 1997 11:42:50 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
 via SMTP by smtp01.primenet.com, id smtpd014684; Wed Dec 17 11:42:45 1997
Received: (from tlambert@localhost)
	by usr02.primenet.com (8.8.5/8.8.5) id LAA02077;
	Wed, 17 Dec 1997 11:42:40 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712171842.LAA02077@usr02.primenet.com>
Subject: Re: panic: blkfree: freeling free block/frag
To: mike@smith.net.au (Mike Smith)
Date: Wed, 17 Dec 1997 18:42:38 +0000 (GMT)
Cc: sclawson@bottles.cs.utah.edu, ivt@gamma.ru, tlambert@primenet.com,
        freebsd-hackers@freebsd.org
In-Reply-To: <199712170635.RAA01913@word.smith.net.au> from "Mike Smith" at Dec 17, 97 05:05: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 been getting ``freeing free block'' panics fairly often when
> > our main server is doing a bunch of large compiles.  A couple weeks
> > ago I finally caught it in the act.  One of my compiles died and I
> > found a source file with exactly 8k of gunk, sitting nicely on an 8k
> > boundary (this was on an 8k/1k filesystem).  The interesting thing
> > about the file was it's list of direct blocks:
> > 
> > 0: 179bb8
> > 1: 179bc0
> > 2: 179bc8
> > 3: 179bd0
> > 4: 179bd8
> > 5:  79be0
> > 6: 179be8
> > 7:      0
> > 
> >      All nicely clustered...except for that sixth one.  At first I
> > thought that the clustering code was at fault, but disk block 79be0
> > was untouched, and the `real' disk block (179be0) had the correct data
> > for the new file.  So, the list of blocks in the inode was corrupted
> > sometime after the data blocks for the file were written.
> 
> Single-bit memory error, perhaps?  Still, keep an eye on it...

If this panic'ed, you need to look at the stack.  I would prefer you look
at the stack for #5.

I do not believe this is a single bit error.  I believe this is the same
problem I have been seeing.

Does your ethernet hardware address begin with 00 00?


Look at the stack for the routines up from the routine in which it
panic'ed, and see if (and how) it might have been stomped.  There
is no such thing as random data in the kernel (I will argue the
random device with you nit-pickers, if you insist ;-)).


					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 Dec 17 11:08:16 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA02898
          for hackers-outgoing; Wed, 17 Dec 1997 11:08:16 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA02801;
          Wed, 17 Dec 1997 11:07:54 -0800 (PST)
          (envelope-from archie@whistle.com)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA09301; Wed, 17 Dec 1997 11:07:21 -0800 (PST)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
	id sma009293; Wed Dec 17 11:07:15 1997
Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id LAA26924; Wed, 17 Dec 1997 11:07:15 -0800 (PST)
From: Archie Cobbs 
Message-Id: <199712171907.LAA26924@bubba.whistle.com>
Subject: Re: Support for secure http protocols
In-Reply-To: <34973506.B112548D@xmission.com> from Wes Peters at "Dec 16, 97 07:12:22 pm"
To: chat@freebsd.org, softweyr@xmission.com
Date: Wed, 17 Dec 1997 11:07:15 -0800 (PST)
Cc: chat@freebsd.org, questions@freesbd.org, hackers@freebsd.org,
        isp@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

Wes Peters writes:
> So, my question is: if I have the capability (time, interest, etc) to 
> implement only ONE secure http transport, which one should it be?  There
> is a draft ieft standard for S-HTTP, but Netscape et al HTTP-SSL seems to
> have garnered more support in the real world.

I think SSL is more prevalent than SHTTP. Also, there already exists
a version of Apache (called Stronghold I think) that includes SSL.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

From owner-freebsd-hackers  Wed Dec 17 11:12:45 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA03390
          for hackers-outgoing; Wed, 17 Dec 1997 11:12:45 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03382
          for ; Wed, 17 Dec 1997 11:12:40 -0800 (PST)
          (envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
	by smtp01.primenet.com (8.8.8/8.8.8) id MAA23112;
	Wed, 17 Dec 1997 12:12:34 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
 via SMTP by smtp01.primenet.com, id smtpd023085; Wed Dec 17 12:12:31 1997
Received: (from tlambert@localhost)
	by usr02.primenet.com (8.8.5/8.8.5) id MAA04021;
	Wed, 17 Dec 1997 12:12:28 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712171912.MAA04021@usr02.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: daniel_sobral@voga.com.br
Date: Wed, 17 Dec 1997 19:12:28 +0000 (GMT)
Cc: tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <83256570.003AE6C5.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 17, 97 08:23:33 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > If the driver is not boot critical, and you don't want it loaded
> > (ie: an embedded system with a sound chip on the board but no
> > speakers attached, etc.), then don't put the module binary into
> > the directory where the kernel looks for module binaries.
> 
> How do you propose I do that? Go around on /whatever, using whatis and mv
> to remove unwanted files*? I'd rather use a graphical tool.
> 
> And that's the whole point. At *some* point in the process, I _must_ have
> the _option_ of choosing what goes in and what stays out of kernel, no
> matter when or how that thing is loaded. It would be nice to have a
> nice-looking tool to do that, though that's of secondary concern. That tool
> must use a file with the metainformation it needs (e.g., sound drivers are
> likely to get cascaded, and, thus, the higher level ones has the lower
> level ones as prereq).

You get to click "OK" or "Cancel" when it says "FreeBSD has detected new
hardware; install drivers?".

That's taking it to the ridiculous extreme, but the assumption that
you'd want to remove drivers for existing hardware is just as ridiculous:
why would you have installed them in the first place?

I'm trying for POLA.  POLA says "whatever you have in the machine, it
just works".


> It is about this file we are talking about, not about how the kernel gets
> configured. We could _change_ the way the kernel gets configured (e.g.,
> sysctl instead of compile-time) without changing this file, because the
> content remains the same: what options do I have? how are they related to
> each other? what the hell that option really mean?

An option means the OS programmers have failed to abstract the need
to explicitly select between alternatives.  It's a failure of the
machine to "do what I need".  Note that even if we allow "do what I
say", that still doesn't necessarily get the user "do what I need".
I would go further, and say that it *probably* doesn't get the
user "do what I need".

Humans can only deal with a set of 5-9 items in a limited set (like the
set of digits) at one time.  This is why phone numbers are 7 digits,
and why UI design guides stress a msmall number of items on a menu bar,
and a small number of items on each submenu on the bar, and a small
number of controls in the dialog selecting one of those items brings up,
etc..

I view a 12k memory recovery as equivalent to Mac-dinking a document
until all the pixels are in exactly "the right place".  Either you
will accept "close enough for 99%", or you will be one of those 1%
remaining who understands the issues well enough actually go in with
rm, ln, cp, mv, or whatever, and perform large diddles for questionable
benefit, to their hearts content.


> At _some_ point the syscon buffer must be configured.

Yes.  At the time the programmer puts a right-hand-side on:

	#define DEFAULT_SYSCONS_BUFFER_SIZE

After that, it only needs to be diddled for people for whom the
default was a bad choice.  These people will post to -questions,
and we will have a measure of how bad the choice was, and we can
then change the right-hand-side value to optimize for the smallest
number of questions.


> Like IRQ on my ISA ed0 must configured at some point.

This is to be done by the driver probe.  The IRQ can only take on a
limited subset of the available values.  This limitation is device
specific, and should be encoded in device specific data.  If a new
device comes out without the limitations, there needs to be a probe
distinction so that the limitation difference can be objectively
determined, and the device specific data should be changed.

None of this requires a human at runtime, only at codetime.


> Like the choice between vt and syscon must be made at some point.

This is more fuzzy.  These are equivalent drivers.

I would argue that the preference should be expressed by installing
or not installing the vt driver.  This is an install script issue.
This is persistent state that is maintained across rebuilds, since
the existance of the driver object is easily detectable.


> Since these are all features of the "kernel", that's obviously the "kernel
> configuration". Though the process by which the kernel gets configured may
> (should) change, the user must still have control over all these options
> (well, most of them). How the kernel configurator will do it's work will
> change, but not the need for it.

If you want to call the MIB manager or the install tools a "kernel
configurator", I'll call it a stretch, but I'll agree "yes, that's
an acceptable mechanism, since it saves the user from having to
make a choice without a full understanding of the consequences".

You could argue that users should be educated, and then I'll argue
by the same token that users should run FreeBSD instead of Microsoft
OS's, but that there is a large gap between "should" and "do".


> *  You also said:
> 
> > Your kernel configurator is /bin/ln, /bin/rm, and /bin/cp.
> 
> [visions of Solaris' way of rc -- I hope you didn't think through on the
> above]

I did.  I believe the Solaris rc.d mechanism is a better mechanism
for allowing the installation of third party components which must
be started at system startup, stopped at system shutdown, and reset
by administrative fiat at the administrators whim.

Tell me how to modularly add and remove a "postgres" package without
it munging existing rc files, and without me munging the existing rc
files so it doesn't have to, and you may be able to change my mind.
Probably not, though, since IBCS2 ABI compatability (for which most
commercial x86 UNIX software is written, like "Sybase", "Oracle", etc.)
specifies an rc.d mechanism.


					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 Dec 17 11:17:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA03810
          for hackers-outgoing; Wed, 17 Dec 1997 11:17:21 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03794
          for ; Wed, 17 Dec 1997 11:17:15 -0800 (PST)
          (envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.8/8.8.8) id MAA05624;
	Wed, 17 Dec 1997 12:23:35 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
 via SMTP by smtp04.primenet.com, id smtpd005562; Wed Dec 17 12:23:24 1997
Received: (from tlambert@localhost)
	by usr02.primenet.com (8.8.5/8.8.5) id MAA04225;
	Wed, 17 Dec 1997 12:16:54 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712171916.MAA04225@usr02.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: daniel_sobral@voga.com.br
Date: Wed, 17 Dec 1997 19:16:54 +0000 (GMT)
Cc: tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <83256570.0041CF6C.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 17, 97 08:59:55 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > Neither of these options require a configurator, only a programmer.  8-).
> 
> I see...

You haven't seen my compiler quote yet, have you?

It applies here:

	Since compiler users outnumber compiler writers 1000:1, if it's
	possible to save a compiler user 1 hour, it's worth 1000 hours
	of the compiler writer's time.

Now:

	Since OS users outnumber OS writers 1000: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 Dec 17 11:25:32 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA04572
          for hackers-outgoing; Wed, 17 Dec 1997 11:25:32 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA04556
          for ; Wed, 17 Dec 1997 11:25:28 -0800 (PST)
          (envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
	by smtp02.primenet.com (8.8.8/8.8.8) id MAA01568;
	Wed, 17 Dec 1997 12:25:27 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
 via SMTP by smtp02.primenet.com, id smtpd001499; Wed Dec 17 12:25:12 1997
Received: (from tlambert@localhost)
	by usr02.primenet.com (8.8.5/8.8.5) id MAA04539;
	Wed, 17 Dec 1997 12:25:10 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712171925.MAA04539@usr02.primenet.com>
Subject: Re: 3com 3c509 card
To: sthaug@nethelp.no
Date: Wed, 17 Dec 1997 19:25:10 +0000 (GMT)
Cc: grog@lemis.com, hackers@freebsd.org
In-Reply-To: <19822.882343067@verdi.nethelp.no> from "sthaug@nethelp.no" at Dec 17, 97 08:17:47 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> If you're trying to measure measure network performance, why don't you
> use a tool which is suitable for the job? FTP is definitely not a good
> tool for this job. I'd suggest ttcp or NetPerf.

Uh, if "typical usage" is FTP, then how is that going to reflect what
he can expect in typical usage?

A car that can go 120MPH on the test track where there is no more than
a 3% grade, but drops to 5MPH on real roads, is not a good car, no
matter how well it benchmarks.


					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 Dec 17 11:34:35 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA05448
          for hackers-outgoing; Wed, 17 Dec 1997 11:34:35 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from kai.communique.net (Kai.communique.net [204.27.67.90])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05430
          for ; Wed, 17 Dec 1997 11:34:24 -0800 (PST)
          (envelope-from nectar@kai.communique.net)
Received: (from smap@localhost)
	by kai.communique.net (8.8.8/8.8.7) id NAA09724;
	Wed, 17 Dec 1997 13:39:35 -0600 (CST)
Message-Id: <199712171939.NAA09724@kai.communique.net>
X-Authentication-Warning: kai.communique.net: smap set sender to  using -f
Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0)
	id xma009716; Wed, 17 Dec 97 13:39:16 -0600
From: Jacques Vidrine 
To: Karl Denninger 
cc: dennis@etinc.com, freebsd-hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask 
In-reply-to: <19971217094157.37862@mcs.net> 
References: <3.0.32.19971217100825.00d45930@etinc.com> <19971217094157.37862@mcs.net>
Date: Wed, 17 Dec 1997 13:39:16 -0600
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Once upon a time Dennis sent me a few raving email messages because 
I had configured a customer he was working with with an unnumbered 
interface and he wanted it the other way: numbered.  I obliged.  This 
was back in September 1995.

So he knows this is entirely untrue from direct experience.  And
it seems his cry below contradicts what he wrote me back then.

He even wrote the following because of my default configuration 
choice:

"I've been trying to help a customer (B. Harper) and it is very 
difficult to help him when his provider has provided him with a 
defective configuration."

"The only conclusion that I can reach is that you are trying to 
sabatoge the connection so that you can get the customer
to buy a Cisco router from you. Many ISPs engage in the same 
practice."

Dennis, 

You'll be happy to know that I configure numbered interfaces
by default now.  Nothing to do with you, we just found it easier
that way over the long term.

Hee hee.  I even see that back on Oct 31, 1995 you wrote on 
-hackers praising unnumbered interfaces:

"When using unnumbered interfaces, all of the interfaces have 
a "local" address of 192.1.1.1. This is nice because all 
transactions from the host have the same source address, and you 
also save addresses by not having to use one for each
logical or physical connection."

This only a month after you flamed me for configuring a customer
unnumbered. 

Jacques Vidrine 

On 17 December 1997 at 9:41, Karl Denninger  wrote:
> On Wed, Dec 17, 1997 at 10:08:26AM -0500, dennis wrote:
> > At 11:34 AM 12/17/97 +1030, Greg Lehey wrote:
> > Your ISP, unfortunately, most likely uses Ciscos, which CANNOT route to
> > hosts. Ciscos can only route to nets, so you must set the PTP interface
> > to a subnet mask. This is  a waste of a net and arguably wrong (since there
> > is, in fact, no network), but we live in a world of ciscoheads. With unix
> > you only need use 2 addresses per  PTP interface..with ciscos you need to
> > use an entire subnet.
> > 
> > Dennis
> 
> Balderdash.
> 
> CISCOs can run un-numbered interfaces (the proper way to do a PTP link where
> the terminal end is not a network) and further, can in fact handle and 
> advertise host routes.
> 
> --
> -- 
> Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
> http://www.mcs.net/          | T1's from $600 monthly to FULL DS-3 Service
> 			     | NEW! K56Flex support on ALL modems
> Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
> Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost

From owner-freebsd-hackers  Wed Dec 17 11:36:57 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA05807
          for hackers-outgoing; Wed, 17 Dec 1997 11:36:57 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from kai.communique.net (Kai.communique.net [204.27.67.90])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05765
          for ; Wed, 17 Dec 1997 11:36:49 -0800 (PST)
          (envelope-from nectar@kai.communique.net)
Received: (from smap@localhost)
	by kai.communique.net (8.8.8/8.8.7) id NAA09739
	for ; Wed, 17 Dec 1997 13:42:05 -0600 (CST)
Message-Id: <199712171942.NAA09739@kai.communique.net>
X-Authentication-Warning: kai.communique.net: smap set sender to  using -f
Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0)
	id xma009731; Wed, 17 Dec 97 13:41:54 -0600
From: Jacques Vidrine 
To: freebsd-hackers@freebsd.org
Subject: ack! apologies
Date: Wed, 17 Dec 1997 13:41:53 -0600
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


I owe an apology to Dennis and Karl I think -- a message that I 
meant to sent privately I copied to -hackers because I neglected
to double-check my headers before hitting send.

I realized immediately, kind of like when you lock your keys in
your car :-)

Jacques Vidrine 

From owner-freebsd-hackers  Wed Dec 17 11:46:37 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA06735
          for hackers-outgoing; Wed, 17 Dec 1997 11:46:37 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 LAA06728
          for ; Wed, 17 Dec 1997 11:46:23 -0800 (PST)
          (envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
	id 0xiPCD-0001nq-00; Wed, 17 Dec 1997 11:31:53 -0800
Date: Wed, 17 Dec 1997 11:31:40 -0800 (PST)
From: Tom 
To: Andrzej Bialecki 
cc: Karl Denninger , dennis ,
        Greg Lehey , hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask
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 Dec 1997, Andrzej Bialecki wrote:

> And even if you don't want to run unnumbered interface, you waste only 4
> addresses (x.x.x.x/255.255.255.252), and even these can be private (e.g.
> 10.x.x.x)... So I don't see that much waste here.

  Except that using private network numbers on p2p links has a number of
bad affects, basically all certering around the fact that the router will
use the private number as a source IP.

> 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.
> ---------------------+---------------------------------------------------------
> 
> 
> 

Tom


From owner-freebsd-hackers  Wed Dec 17 11:54:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA07385
          for hackers-outgoing; Wed, 17 Dec 1997 11:54:51 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA07376
          for ; Wed, 17 Dec 1997 11:54:24 -0800 (PST)
          (envelope-from daniel_sobral@voga.com.br)
From: daniel_sobral@voga.com.br
Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997))  id 03256570.006D4CE2 ; Wed, 17 Dec 1997 16:53:51 -0300
X-Lotus-FromDomain: VOGA
To: tlambert@primenet.com
cc: hackers@FreeBSD.ORG
Message-ID: <83256570.006A7EAF.00@papagaio.voga.com.br>
Date: Wed, 17 Dec 1997 16:53:43 -0300
Subject: Re: Why so many steps to build new kernel?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


> That's taking it to the ridiculous extreme, but the assumption that
> you'd want to remove drivers for existing hardware is just as
> ridiculous: why would you have installed them in the first place?

Easy. Bugs. Eg.:

     - Driver being developed in current incorrectly identifies my card as
being of the same model, causing all sorts of problem.

     - Recent bug fix in stable made a previously undetected bug appear in
a driver, rendering the system unstable.

     - Fill in your example of Bug Horror Story.

Notice that, in both case, the configuration must be made not at the time
the hardware is detected, but at a later time.

> I'm trying for POLA.  POLA says "whatever you have in the machine, it
> just works".

Except when it doesn't.

I'm trying for: yeah, ok, you do know a lot about what you are doing, but
you do not know what *I* am doing, so let me do what *I* want to do. Let me
shoot myself in the foot. Otherwise, why use Unix instead of Windows (et
cetera) at all?

> An option means the OS programmers have failed to abstract the need
> to explicitly select between alternatives.  It's a failure of the
> machine to "do what I need".

It let's the end-user avoid short sightedness such as shown above. For
instance, I fail to see how the system my decide that I "need" a blue
background, or that I don't "need" more than a single screen worth of
history buffer.

An option means that the computer can't read the mind of the people who is
using it.

> Humans can only deal with a set of 5-9 items in a limited set (like the
> set of digits) at one time.  This is why phone numbers are 7 digits,
> and why UI design guides stress a msmall number of items on a menu bar,
> and a small number of items on each submenu on the bar, and a small
> number of controls in the dialog selecting one of those items brings up,
etc..

So? I suppose a programmer shouldn't code programs of more than nine lines
worth of code because of that? Or what applies to the system manager does
not apply to the programmer? And the same things goes between end user and
the two above?

> I view a 12k memory recovery as equivalent to Mac-dinking a document
> until all the pixels are in exactly "the right place".  Either you
> will accept "close enough for 99%", or you will be one of those 1%
> remaining who understands the issues well enough actually go in with
> rm, ln, cp, mv, or whatever, and perform large diddles for questionable
> benefit, to their hearts content.

Of course, as far as RL goes, there are many people out there who belongs
to the former group but have a job requiring the skills of the later. We
have two choices: we ignore them or we don't.

Besides, computers are used to automate jobs. Why automate so many tasks,
and then fail to automate this single task because people who do it should
know how to do it by hand? Well, I know how to write with pen and paper,
but I still prefer to use a word processor if the job is large enough.

> > At _some_ point the syscon buffer must be configured.

> Yes.  At the time the programmer puts a right-hand-side on:

> #define DEFAULT_SYSCONS_BUFFER_SIZE

> After that, it only needs to be diddled for people for whom the
> default was a bad choice.  These people will post to -questions,
> and we will have a measure of how bad the choice was, and we can
> then change the right-hand-side value to optimize for the smallest
> number of questions.

Recompile the kernel to change the buffer size???????????? That should be
possible to do at run-time, without stopping the machine at all.

Besides, compile time options suck. IMHO, but that's an O not likely to
change in the near future. And certainly not with an argument such as
"well, you know how to do it the hard way, so that's the way you should
pick."

> > Like IRQ on my ISA ed0 must configured at some point.

> This is to be done by the driver probe.

Well, I have yet to see any OS correctly identify how my ed0 is configured.
I have been taking that as an indication that it is simply not possible.

> Like the choice between vt and syscon must be made at some point.

> This is more fuzzy.  These are equivalent drivers.

> I would argue that the preference should be expressed by installing
> or not installing the vt driver.  This is an install script issue.
> This is persistent state that is maintained across rebuilds, since
> the existance of the driver object is easily detectable.

Well, the current method of selecting between vt and syscon is the one
above. It is being done through a file that is run through a program called
"config". This file should be edited by hand, something that fashion many
people, but many more would like an easier interface. The development of an
easier interface is the topic of this thread.

So... I may presume that you do, indeed, see the need for "kernel
configuration", as long as it is not called that? :-)

> I did.  I believe the Solaris rc.d mechanism is a better mechanism
> for allowing the installation of third party components which must
> be started at system startup, stopped at system shutdown, and reset
> by administrative fiat at the administrators whim.

Well, I consider the Solaris rc.d mechanism akin to killing all the
homeless people in the world to solve their problem. It kind of works, but
it is not acceptable.

--
Daniel C. Sobral                      (8-DCS)
Daniel_Sobral@voga.com.br



From owner-freebsd-hackers  Wed Dec 17 11:57:17 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA07606
          for hackers-outgoing; Wed, 17 Dec 1997 11:57:17 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA07596
          for ; Wed, 17 Dec 1997 11:57:06 -0800 (PST)
          (envelope-from daniel_sobral@voga.com.br)
From: daniel_sobral@voga.com.br
Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997))  id 03256570.006D8D5B ; Wed, 17 Dec 1997 16:56:36 -0300
X-Lotus-FromDomain: VOGA
To: tlambert@primenet.com
cc: hackers@FreeBSD.ORG
Message-ID: <83256570.006D585F.00@papagaio.voga.com.br>
Date: Wed, 17 Dec 1997 16:56:33 -0300
Subject: Re: Why so many steps to build new kernel?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


> > > Neither of these options require a configurator, only a programmer.
8-).
>
> > I see...

> You haven't seen my compiler quote yet, have you?

> It applies here:

 > Since compiler users outnumber compiler writers 1000:1, if it's
 > possible to save a compiler user 1 hour, it's worth 1000 hours
 > of the compiler writer's time.

> Now:

 > Since OS users outnumber OS writers 1000:1...

I noticed you failed to mention that the person choosing between the
options will probably belong to the former group, not the later.

--
Daniel C. Sobral                      (8-DCS)
Daniel_Sobral@voga.com.br



From owner-freebsd-hackers  Wed Dec 17 11:59:39 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA07795
          for hackers-outgoing; Wed, 17 Dec 1997 11:59:39 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 LAA07783
          for ; Wed, 17 Dec 1997 11:59:25 -0800 (PST)
          (envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 24912 invoked by uid 1001); 17 Dec 1997 19:59:15 +0000 (GMT)
To: tlambert@primenet.com
Cc: hackers@freebsd.org
Subject: Re: 3com 3c509 card
In-Reply-To: Your message of "Wed, 17 Dec 1997 19:25:10 +0000 (GMT)"
References: <199712171925.MAA04539@usr02.primenet.com>
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Wed, 17 Dec 1997 20:59:15 +0100
Message-ID: <24910.882388755@verdi.nethelp.no>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > If you're trying to measure measure network performance, why don't you
> > use a tool which is suitable for the job? FTP is definitely not a good
> > tool for this job. I'd suggest ttcp or NetPerf.
> 
> Uh, if "typical usage" is FTP, then how is that going to reflect what
> he can expect in typical usage?

If you're trying to solve a problem, it's much easier if you can look
at smaller parts of the problem in isolation. Using ttcp or NetPerf is
an effective way of removing the disk subsystem from the chain.

If you're getting 1 MByte/s with ttcp/NetPerf, combined with reasonable
CPU usage, *then* it may be time to look at why the CPU usage is not
reasonable with FTP.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

From owner-freebsd-hackers  Wed Dec 17 12:02:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA08129
          for hackers-outgoing; Wed, 17 Dec 1997 12:02:51 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 MAA08116
          for ; Wed, 17 Dec 1997 12:02:42 -0800 (PST)
          (envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 24947 invoked by uid 1001); 17 Dec 1997 20:02:29 +0000 (GMT)
To: abial@korin.warman.org.pl
Cc: hackers@FreeBSD.ORG
Subject: Re: ifconfig reports bogus netmask
In-Reply-To: Your message of "Wed, 17 Dec 1997 19:44:08 +0100 (CET)"
References: 
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Wed, 17 Dec 1997 21:02:29 +0100
Message-ID: <24945.882388949@verdi.nethelp.no>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> And even if you don't want to run unnumbered interface, you waste only 4
> addresses (x.x.x.x/255.255.255.252), and even these can be private (e.g.
> 10.x.x.x)... So I don't see that much waste here.

Wasting 4 addresses (instead of 2) for point to point links is not a big
deal, and we do it all the time.

Using RFC 1918 addresses for point to point links on the Internet is not
a good idea, because:

- You'll get ICMP messages with RFC 1918 addresses as source (think of
traceroute).

- Many organizations filter RFC 1918 source addresses at their border
routers. Thus the corresponding ICMPs will never arrive.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

From owner-freebsd-hackers  Wed Dec 17 12:14:53 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA09056
          for hackers-outgoing; Wed, 17 Dec 1997 12:14:53 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from m16.boston.juno.com (m16.boston.juno.com [205.231.101.192])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09037
          for ; Wed, 17 Dec 1997 12:14:42 -0800 (PST)
          (envelope-from wakkym@juno.com)
Received: (from wakkym@juno.com)
 by m16.boston.juno.com (queuemail) id PFB18751; Wed, 17 Dec 1997 15:13:18 EST
To: abial@korin.warman.org.pl
Cc: hackers@freebsd.org
Subject: Re: atapi.c || wierd hardware
Message-ID: <19971217.151114.5295.0.wakkym@juno.com>
References: 
X-Mailer: Juno 1.15
X-Juno-Line-Breaks: 0,2-24,26-32,37-43,46-51
From: wakkym@juno.com (Lee Cremeans)
Date: Wed, 17 Dec 1997 15:13:18 EST
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Wed, 17 Dec 1997 11:32:18 +0100 (CET) Andrzej Bialecki
 writes:
>On Tue, 16 Dec 1997, Lee Cremeans wrote:
>
>> 
>> On Tue, 16 Dec 1997 19:44:08 -0500 (EST) "Gregory D. Moncreaff"
>>  writes:
>> >
>> >I've got a couple of IDE cdroms that, on boot/probe, 
>> >put a line as follows in the log:
>> >
>> >wdc1: unit 0 (atapi): , 
>> >removable, dma, iordy
>> >
>> >(lots of whitespace between 'NEC' and 'CD')
>
>And how about this:
>
>wdc1: unit 0 (atapi): , removable, intr, 
>dma, iordy
>wcd0: 1377Kb/sec, 256Kb cache, audio play, 255 volume levels, 
>ejectable tray
>wcd0: no disc inside, unlocked
>wdc1: unit 1 (atapi): 
><\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?/\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?>,

>removable, cmd3, drq3, ovlap, idma, 
>iordis
>wdc1: unit 1: unknown ATAPI protocol=3
>
>But it works ok... I simply got used to this.

Aie, I get this too...this is on a Mitsumi FX001DE connected to a Triton
FX DMA IDE controller. I noticed it started happening here when I bumped
my local-bus speed to 66 MHz (from 50MHz). It may well be a bug in the
Oak OTI-011 ATAPI-interface chip inside my drive...you may want to tear
yours down (assuming it's not under warranty :) and look for an OTI-011.

>Now, inside my home machine I have a Pioneer ATAPI unit, which is 
>reported
>by kernel as  - little/big endian confusion on part of
>manufacturer :-)

I've seen this on at least one old IDE hard drive (the WDC 93044 and its
siblings)...ATA model strings are ALWAYS supposed to be big-endian, as
far as I can tell. 

>I conclude from this that vendors often have peculiar understanding of
>"standards"...

Yep... :/

From owner-freebsd-hackers  Wed Dec 17 13:33:46 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA15607
          for hackers-outgoing; Wed, 17 Dec 1997 13:33:46 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA15593
          for ; Wed, 17 Dec 1997 13:33:06 -0800 (PST)
          (envelope-from tlambert@usr07.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.8/8.8.8) id OAA15723;
	Wed, 17 Dec 1997 14:39:35 -0700 (MST)
Received: from usr07.primenet.com(206.165.6.207)
 via SMTP by smtp04.primenet.com, id smtpd015646; Wed Dec 17 14:39:19 1997
Received: (from tlambert@localhost)
	by usr07.primenet.com (8.8.5/8.8.5) id OAA16469;
	Wed, 17 Dec 1997 14:32:44 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712172132.OAA16469@usr07.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: daniel_sobral@voga.com.br
Date: Wed, 17 Dec 1997 21:32:43 +0000 (GMT)
Cc: tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <83256570.006D585F.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 17, 97 04:56:33 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > It applies here:
> 
>  > Since compiler users outnumber compiler writers 1000:1, if it's
>  > possible to save a compiler user 1 hour, it's worth 1000 hours
>  > of the compiler writer's time.
> 
> > Now:
> 
>  > Since OS users outnumber OS writers 1000:1...
> 
> I noticed you failed to mention that the person choosing between the
> options will probably belong to the former group, not the later.

I'm willing to be democratic here.  But the polls are running 1000:1
in favor, aren't they?  It's pretty sure how the vote will turn out...


					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 Dec 17 14:05:46 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA18477
          for hackers-outgoing; Wed, 17 Dec 1997 14:05:46 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from echonyc.com (echonyc.com [198.67.15.2])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA18449
          for ; Wed, 17 Dec 1997 14:05:32 -0800 (PST)
          (envelope-from benedict@echonyc.com)
Received: from localhost (benedict@localhost)
	by echonyc.com (8.8.7/8.8.7) with SMTP id RAA23962;
	Wed, 17 Dec 1997 17:05:09 -0500 (EST)
Date: Wed, 17 Dec 1997 17:05:09 -0500 (EST)
From: Snob Art Genre 
To: sthaug@nethelp.no
cc: abial@korin.warman.org.pl, hackers@FreeBSD.ORG
Subject: Re: ifconfig reports bogus netmask
In-Reply-To: <24945.882388949@verdi.nethelp.no>
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 only a problem if you want everyone to see your network topology.
But why would someone need to traceroute you from another AS?

On Wed, 17 Dec 1997 sthaug@nethelp.no wrote:

> > And even if you don't want to run unnumbered interface, you waste only 4
> > addresses (x.x.x.x/255.255.255.252), and even these can be private (e.g.
> > 10.x.x.x)... So I don't see that much waste here.
> 
> Wasting 4 addresses (instead of 2) for point to point links is not a big
> deal, and we do it all the time.
> 
> Using RFC 1918 addresses for point to point links on the Internet is not
> a good idea, because:
> 
> - You'll get ICMP messages with RFC 1918 addresses as source (think of
> traceroute).
> 
> - Many organizations filter RFC 1918 source addresses at their border
> routers. Thus the corresponding ICMPs will never arrive.
> 
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
> 



 Ben

"You have your mind on computers, it seems." 


From owner-freebsd-hackers  Wed Dec 17 14:15:34 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA19403
          for hackers-outgoing; Wed, 17 Dec 1997 14:15:34 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19387
          for ; Wed, 17 Dec 1997 14:15:20 -0800 (PST)
          (envelope-from tlambert@usr07.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.8/8.8.8) id PAA28907;
	Wed, 17 Dec 1997 15:21:49 -0700 (MST)
Received: from usr07.primenet.com(206.165.6.207)
 via SMTP by smtp04.primenet.com, id smtpd028817; Wed Dec 17 15:21:41 1997
Received: (from tlambert@localhost)
	by usr07.primenet.com (8.8.5/8.8.5) id PAA18891;
	Wed, 17 Dec 1997 15:15:04 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712172215.PAA18891@usr07.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: daniel_sobral@voga.com.br
Date: Wed, 17 Dec 1997 22:15:04 +0000 (GMT)
Cc: tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <83256570.006A7EAF.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 17, 97 04:53:43 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > That's taking it to the ridiculous extreme, but the assumption that
> > you'd want to remove drivers for existing hardware is just as
> > ridiculous: why would you have installed them in the first place?
> 
> Easy. Bugs. Eg.:
> 
>      - Driver being developed in current incorrectly identifies my card as
> being of the same model, causing all sorts of problem.

Run the install for it again.  This time give it the "-d" option.


>      - Recent bug fix in stable made a previously undetected bug appear in
> a driver, rendering the system unstable.

Run the install for the bugfix again.  This time give it the "-d" option.


>      - Fill in your example of Bug Horror Story.
> 
> Notice that, in both case, the configuration must be made not at the time
> the hardware is detected, but at a later time.

The driver/bugfix must be installed not at the time the hardware is
detected, but at an earlier time.  What is your point?  That install
and usage are disconnected?  I'll give you that one for free.


> > I'm trying for POLA.  POLA says "whatever you have in the machine, it
> > just works".
> 
> Except when it doesn't.

I find something not working to be astonishing.  That' doesn't fall
into what POLA says (I suppose I could argue this from the definition
of "*Least*" if you wanted to press me on it).


> I'm trying for: yeah, ok, you do know a lot about what you are doing, but
> you do not know what *I* am doing, so let me do what *I* want to do. Let me
> shoot myself in the foot. Otherwise, why use Unix instead of Windows (et
> cetera) at all?

I don't think that's a compelling argument, or most everyone would be
running UNIX instead of Windows on their desktop.

Something can be both easy and assinine, but just because something is
easy doesn't necessarily make it assinine.  You can't tar an easy to
use UNIX system with athe Windows brush.


> > An option means the OS programmers have failed to abstract the need
> > to explicitly select between alternatives.  It's a failure of the
> > machine to "do what I need".
> 
> It let's the end-user avoid short sightedness such as shown above. For
> instance, I fail to see how the system my decide that I "need" a blue
> background, or that I don't "need" more than a single screen worth of
> history buffer.

I fail to see how you can come up with a reasonable definition for
the ESC [  m attributes, where  is 1, 2, 3, 4, 5, 6, or 7 when
you define the background/foreground away from the defaults, unless you
are constrained to define all other attribute pairs at the same time.
There's no other way to ensure the attribute pairs are unique from each
other, so that they may be distinguished by a user.

If you define background as black, and foreground as "high white" instead
of "low white" (defining the value for ESC [ 0 m), then what is pair
that comes frm ESC [ 5 m ("bold")?

You damage the ability to use standard ISO or even nonstandard SCO
color escape sequences when you define away from the defaults.

You can come up with all of the examples you want to where the user
chooses to consciously and intentionally violate POLA, and then point
at them and say "see!  Your model violates POLA!".

As far as needing multiple screens of history buffer... sysctl it.  Once.
It should stick and be that way forever after, if the system is working
like it should be.


> An option means that the computer can't read the mind of the people who is
> using it.

These are not things which should be configured at kernel build time.
Provide a user interface to sysctl, if you want to, such that you can
ensure consistency between attribute settings in syscons, and refuse to
save POLA-violating combinations, for your definition of POLA.  I could
make the argument that not allowing the text to be set to black-on-black
violates POLA, for a user who is least astonished by a system that lets
them shoot themselves in the foot.


> > Humans can only deal with a set of 5-9 items in a limited set (like the
> > set of digits) at one time.  This is why phone numbers are 7 digits,
> > and why UI design guides stress a msmall number of items on a menu bar,
> > and a small number of items on each submenu on the bar, and a small
> > number of controls in the dialog selecting one of those items brings up,
> etc..
> 
> So? I suppose a programmer shouldn't code programs of more than nine lines
> worth of code because of that? Or what applies to the system manager does
> not apply to the programmer? And the same things goes between end user and
> the two above?

What applies to the programmer does not apply to the user, of course.
This is why it takes an engineer to do programming, and why it should
*not* take an enginneer to be a user.


> > I view a 12k memory recovery as equivalent to Mac-dinking a document
> > until all the pixels are in exactly "the right place".  Either you
> > will accept "close enough for 99%", or you will be one of those 1%
> > remaining who understands the issues well enough actually go in with
> > rm, ln, cp, mv, or whatever, and perform large diddles for questionable
> > benefit, to their hearts content.
> 
> Of course, as far as RL goes, there are many people out there who belongs
> to the former group but have a job requiring the skills of the later. We
> have two choices: we ignore them or we don't.
> 
> Besides, computers are used to automate jobs. Why automate so many tasks,
> and then fail to automate this single task because people who do it should
> know how to do it by hand? Well, I know how to write with pen and paper,
> but I still prefer to use a word processor if the job is large enough.

Why fail to automate those options for which correct values can be
determined without a human?

Why set up exactly 4 BPF devices when the user might need 5?  Why 4
when the user might need 0?  Why not use a cloning device driver in a
devfs framework instead?

OK, now apply that to other devices.  PTY's.

Do you need a WDC driver?  I don't know... why don't you load one, then
load it and load the probe code an probe the wd0/wd1 devices, and if they
probe as not being there, unload the probe code and unload the WDC driver,
instead of having the user specify the thing in the config file?

Do you need NFS?  I don't know... why don't you wait until the user asks
for an NFS mount before loading the code into the kernel?

Do you need a net card driver?  I don't know, why don't you wait for
an IP address family or some other address family to need one before
loading the driver?

Do you need IP?  I don't know, why don't you wait for TCP or UDP
sockets to be opened...

Etc..


Let me ask another question: what kernel configuration options do you
need?  We can take them on a case-by-case basis and make them work
as tunables without the tuning needing to be done at compile time --
I'm sure of it.


> > > At _some_ point the syscon buffer must be configured.
> >
> > Yes.  At the time the programmer puts a right-hand-side on:
> >
> > #define DEFAULT_SYSCONS_BUFFER_SIZE
> >
> > After that, it only needs to be diddled for people for whom the
> > default was a bad choice.  These people will post to -questions,
> > and we will have a measure of how bad the choice was, and we can
> > then change the right-hand-side value to optimize for the smallest
> > number of questions.
> 
> Recompile the kernel to change the buffer size???????????? That should be
> possible to do at run-time, without stopping the machine at all.

You are arguing my case for me.  I am the one claiming you do not need to
have a configuration utility at kernel build time.  If something can be
tuned at runtime, it should not be a build time option.

Once you get rid of all build time options, you are in my camp, that
no kernel configurator is necessary.


> Besides, compile time options suck. IMHO, but that's an O not likely to
> change in the near future. And certainly not with an argument such as
> "well, you know how to do it the hard way, so that's the way you should
> pick."


Well, it will certainly not change in the near future if there is an
existing tuning mechanism that has to be replaced for the change to
be accepted.  A kernel configurator that operates at compile time
*causes* sucky compile time options, it doesn't alleviate them.


> > > Like IRQ on my ISA ed0 must configured at some point.
> >
> > This is to be done by the driver probe.
> 
> Well, I have yet to see any OS correctly identify how my ed0 is configured.
> I have been taking that as an indication that it is simply not possible.

Does the manufacturer utility get the information right?

> > Like the choice between vt and syscon must be made at some point.
> >
> > This is more fuzzy.  These are equivalent drivers.
> >
> > I would argue that the preference should be expressed by installing
> > or not installing the vt driver.  This is an install script issue.
> > This is persistent state that is maintained across rebuilds, since
> > the existance of the driver object is easily detectable.
> 
> Well, the current method of selecting between vt and syscon is the one
> above.

So?  The current method is wrong.  Death to the current method.


> So... I may presume that you do, indeed, see the need for "kernel
> configuration", as long as it is not called that? :-)

A set of kernel data that is persistent across boots and upgrades?
I see that.  It's called a directory.  It contains things like the
credentials information for the accounts needed to get the machine
at least to the point were it can contact other directory servers
for additional credentials information, at a minimum, or locally
maintain addition credential information.

Does this data include hardware configuration information?  Not
for baseline functionaility, it doesn't.  That information is in
the drivers, where it belongs, where the user can't do anything
to it to make it quit working.


> > I did.  I believe the Solaris rc.d mechanism is a better mechanism
> > for allowing the installation of third party components which must
> > be started at system startup, stopped at system shutdown, and reset
> > by administrative fiat at the administrators whim.
> 
> Well, I consider the Solaris rc.d mechanism akin to killing all the
> homeless people in the world to solve their problem. It kind of works, but
> it is not acceptable.

What toes does it step on, other than "Not Invented Here"?  Killing
homeless people steps on real toes, not religious authority that
exists without justification, other than the continuation of the
institutionalization of religious authority.  The two are not
analogous.


					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 Dec 17 14:17:16 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA19638
          for hackers-outgoing; Wed, 17 Dec 1997 14:17:16 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 OAA19094
          for ; Wed, 17 Dec 1997 14:11:48 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id IAA02345;
          Thu, 18 Dec 1997 08:41:32 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971218084132.64227@lemis.com>
Date: Thu, 18 Dec 1997 08:41:32 +1030
From: Greg Lehey 
To: Terry Lambert 
Cc: sthaug@nethelp.no, hackers@freebsd.org
Subject: Re: 3com 3c509 card
References: <19822.882343067@verdi.nethelp.no> <199712171925.MAA04539@usr02.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <199712171925.MAA04539@usr02.primenet.com>; from Terry Lambert on Wed, Dec 17, 1997 at 07:25:10PM +0000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, Dec 17, 1997 at 07:25:10PM +0000, Terry Lambert wrote:
>> If you're trying to measure measure network performance, why don't you
>> use a tool which is suitable for the job? FTP is definitely not a good
>> tool for this job. I'd suggest ttcp or NetPerf.
>
> Uh, if "typical usage" is FTP, then how is that going to reflect what
> he can expect in typical usage?

Divide and conquer.  It will help determine where the bottleneck is.
At the moment, we don't know whether it's ftp or the driver.

> A car that can go 120MPH on the test track where there is no more
> than a 3% grade, but drops to 5MPH on real roads, is not a good car,
> no matter how well it benchmarks.

Right.  And roads that slow all cars down to 8 km/h aren't good roads,
either.  We were talking about roads, not cars.

Greg

From owner-freebsd-hackers  Wed Dec 17 14:21:09 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA20022
          for hackers-outgoing; Wed, 17 Dec 1997 14:21:09 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 OAA20017
          for ; Wed, 17 Dec 1997 14:21:00 -0800 (PST)
          (envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA24323
  (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Wed, 17 Dec 1997 23:20:48 +0100
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id VAA02676; Wed, 17 Dec 1997 21:07:35 +0100 (MET)
From: Wilko Bulte 
Message-Id: <199712172007.VAA02676@yedi.iaf.nl>
Subject: Re: volume control on SCSI Toshiba CDdrive
To: wilko@yedi.iaf.nl (Wilko Bulte)
Date: Wed, 17 Dec 1997 21:07:35 +0100 (MET)
Cc: syssgm@dtir.qld.gov.au, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199711242012.VAA02289@yedi.iaf.nl> from "Wilko Bulte" at Nov 24, 97 09:12:09 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 Wilko Bulte wrote...
> As Stephen McKay wrote...
> 
> > On Friday, 21st November 1997, Wilko Bulte wrote:
> > 
> > >I just changed my old 4x Toshiba cdrom to a 12x Toshiba.
> > >To be precise, it is a TOSHIBA  CD-ROM XM-5701TA 3136.
> > >
> > >The 4x Toshiba audio volume was controllable using the WorkMan 'slide'.
> > >It seems that the 12x Toshiba does not respond to this. AFAIK 
> > >the volume stuff is part of the SCSI standard these days. 
> > >
> > >Any comments of fellow XM5701 owners?
> > 
> > I have the same problem.  Everything else works. :-)
> > 
> > xmcd could control volume on my old NEC 4x, but the new Toshiba ignores it.
> > It's just about impossible to keep a list of good working hardware. :-(
> > 
> > Does anyone have an inside contack at Toshiba?  Maybe there is a workaround.
> > If not, at least they will be able to club somebody!
> 
> I'll try to find out at work. Digital buys a lot of Toshiba drives, so
> maybe I can get more info on this.

Well it took some time, but I haven't given up:

TOSHIBA CD-ROM XM-5701TA 0557

is a firmware rev that has *working* audio control. I found out by borrowing
a Digital RRD46 which is a XM5701 in disguise. It contains the RRD46
firmware, but also the XM-5701TA 0557 firmware. Jumper selectable by the
parity jumper (parity is for our firmware always enabled, the jumper is
'borrowed' so the hardware can remain as-is). I'm not sure if there are
two completely seperate firmware revs, or only some settings/mode pages
are changed. I suspect it is the latter.

The firmware itself lives in a socketed SMD PROM.

As far as getting in touch with a contact in Toshiba I did not have as much
luck. 

Is there anybody on the list that has the right contact within Toshiba
to get the music loving XM-5701TA owners a working firmware? It is at least
proven by now that Toshiba has the technology ;-)

Wilko
_     ______________________________________________________________________
 |   / o / /  _  Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko
 |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
----------------  Support your local daemons: run [Free,Net]BSD Unix  ------

From owner-freebsd-hackers  Wed Dec 17 14:23:32 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA20256
          for hackers-outgoing; Wed, 17 Dec 1997 14:23:32 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20244
          for ; Wed, 17 Dec 1997 14:23:20 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA11161;
	Wed, 17 Dec 1997 15:22:43 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id PAA14359; Wed, 17 Dec 1997 15:22:41 -0700
Date: Wed, 17 Dec 1997 15:22:41 -0700
Message-Id: <199712172222.PAA14359@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: daniel_sobral@voga.com.br, hackers@freebsd.org
Subject: Re: Why so many steps to build new kernel?
In-Reply-To: <199712172132.OAA16469@usr07.primenet.com>
References: <83256570.006D585F.00@papagaio.voga.com.br>
	<199712172132.OAA16469@usr07.primenet.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >  > Since compiler users outnumber compiler writers 1000:1, if it's
> >  > possible to save a compiler user 1 hour, it's worth 1000 hours
> >  > of the compiler writer's time.
> 
> I'm willing to be democratic here.

Since when was development ever claimed to be a democratic process?

Heck, I've got 10-20 people willing to be added to the 'FS-101' list by
you, but up till now very little progress has been made.  Why do you
expect other developers to spend the 1000 hours of work add new features
to make your life easier when you aren't willing to spend 1-2 to get
things started.


Nate

From owner-freebsd-hackers  Wed Dec 17 14:31:24 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA21043
          for hackers-outgoing; Wed, 17 Dec 1997 14:31:24 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA21029
          for ; Wed, 17 Dec 1997 14:31:18 -0800 (PST)
          (envelope-from tlambert@usr07.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.8/8.8.8) id PAA04902;
	Wed, 17 Dec 1997 15:37:51 -0700 (MST)
Received: from usr07.primenet.com(206.165.6.207)
 via SMTP by smtp04.primenet.com, id smtpd004770; Wed Dec 17 15:37:35 1997
Received: (from tlambert@localhost)
	by usr07.primenet.com (8.8.5/8.8.5) id PAA19752;
	Wed, 17 Dec 1997 15:30:56 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712172230.PAA19752@usr07.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: nate@mt.sri.com (Nate Williams)
Date: Wed, 17 Dec 1997 22:30:55 +0000 (GMT)
Cc: tlambert@primenet.com, daniel_sobral@voga.com.br, hackers@freebsd.org
In-Reply-To: <199712172222.PAA14359@mt.sri.com> from "Nate Williams" at Dec 17, 97 03:22:41 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > >  > Since compiler users outnumber compiler writers 1000:1, if it's
> > >  > possible to save a compiler user 1 hour, it's worth 1000 hours
> > >  > of the compiler writer's time.
> > 
> > I'm willing to be democratic here.
> 
> Since when was development ever claimed to be a democratic process?
> 
> Heck, I've got 10-20 people willing to be added to the 'FS-101' list by
> you, but up till now very little progress has been made.  Why do you
> expect other developers to spend the 1000 hours of work add new features
> to make your life easier when you aren't willing to spend 1-2 to get
> things started.

Heh.  Committers outnumber contributors...


					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 Dec 17 14:35:30 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA21375
          for hackers-outgoing; Wed, 17 Dec 1997 14:35:30 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA21364
          for ; Wed, 17 Dec 1997 14:35:21 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA11236;
	Wed, 17 Dec 1997 15:34:33 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id PAA14402; Wed, 17 Dec 1997 15:34:31 -0700
Date: Wed, 17 Dec 1997 15:34:31 -0700
Message-Id: <199712172234.PAA14402@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), daniel_sobral@voga.com.br,
        hackers@freebsd.org
Subject: Re: Why so many steps to build new kernel?
In-Reply-To: <199712172230.PAA19752@usr07.primenet.com>
References: <199712172222.PAA14359@mt.sri.com>
	<199712172230.PAA19752@usr07.primenet.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > Heck, I've got 10-20 people willing to be added to the 'FS-101' list by
> > you, but up till now very little progress has been made.  Why do you
> > expect other developers to spend the 1000 hours of work add new features
> > to make your life easier when you aren't willing to spend 1-2 to get
> > things started.
> 
> Heh.  Committers outnumber contributors...

Actually, only 2 are committers.  You still haven't answered the
question though.  Why are you willing to donate *my* time yet you aren't
willing to donate anytime of your own?


Nate

From owner-freebsd-hackers  Wed Dec 17 14:39:36 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA21864
          for hackers-outgoing; Wed, 17 Dec 1997 14:39:36 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 OAA21834
          for ; Wed, 17 Dec 1997 14:39:22 -0800 (PST)
          (envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 26768 invoked by uid 1001); 17 Dec 1997 22:39:08 +0000 (GMT)
To: benedict@echonyc.com
Cc: hackers@FreeBSD.ORG
Subject: Re: ifconfig reports bogus netmask
In-Reply-To: Your message of "Wed, 17 Dec 1997 17:05:09 -0500 (EST)"
References: 
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Wed, 17 Dec 1997 23:39:07 +0100
Message-ID: <26766.882398347@verdi.nethelp.no>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> This is only a problem if you want everyone to see your network topology.
> But why would someone need to traceroute you from another AS?

- I traceroute to other ASes every day, and I find it extremely useful
to see for instance where a path stops.

- traceroute is not the only use for ICMP.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

From owner-freebsd-hackers  Wed Dec 17 15:43:20 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA26877
          for hackers-outgoing; Wed, 17 Dec 1997 15:43:20 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA26865
          for ; Wed, 17 Dec 1997 15:43:00 -0800 (PST)
          (envelope-from fullermd@futuresouth.com)
Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21])
	by shell.futuresouth.com (8.8.8/8.8.8) with SMTP id RAA29092;
	Wed, 17 Dec 1997 17:42:39 -0600 (CST)
Date: Wed, 17 Dec 1997 17:42:39 -0600 (CST)
From: "Matthew D. Fuller" 
To: sthaug@nethelp.no
cc: benedict@echonyc.com
Subject: Re: ifconfig reports bogus netmask
In-Reply-To: <26766.882398347@verdi.nethelp.no>
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 Dec 1997 sthaug@nethelp.no wrote:

> > This is only a problem if you want everyone to see your network topology.
> > But why would someone need to traceroute you from another AS?
> 
> - I traceroute to other ASes every day, and I find it extremely useful
> to see for instance where a path stops.
> 
> - traceroute is not the only use for ICMP.
Finding private adresses in traceroutes IS annoying.  For instance, from
my box here at home,
 1  anp-as10.erols.com (10.65.34.20)  229.273 ms  280.448 ms  199.593 ms
 2  10.65.34.1 (10.65.34.1)  219.927 ms  271.672 ms  208.069 ms
 3  10.2.4.50 (10.2.4.50)  277.771 ms  257.309 ms  248.005 ms
 4  10.2.2.61 (10.2.2.61)  257.946 ms  228.212 ms  221.258 ms
 5  207.124.117.209 (207.124.117.209)  199.419 ms  227.504 ms  177.854 ms
 6  dcb-7513-2-h8-0.cwi.net (207.124.105.77)  267.632 ms  317.036 ms

So, coming from the other direction,
 9  blb-7513-1-h3-0.cwix.net (207.124.105.78)  61.949 ms  82.938 ms
10  207.124.117.210 (207.124.117.210)  97.334 ms * *
11  * * *
12  * * *
13  * * *
14  * anp-as10s19.erols.com (207.172.150.146)  274.060 ms  270.059 ms

Now, if that was happening with the private adresses at the end AWAY from
me, it really wouldn't help me figure out where the problem is.  From the
other end, I might well assume the problem would be in cwix.net, instead
of erols.com where all those *'s really are.  Not too helpful in sending
complaints/notices.

I'm going to exercise a little discretion here; I think this particular
line has reached the end of it's useful life on -hackers.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
|       FreeBSD; the way computers were meant to be       |
* "The only reason I'm burning my candle at both ends, is *
| that I haven't figured out how to light the middle yet."|
*    fullermd@futuresouth.com      :-}  MAtthew Fuller    *
|      http://keystone.westminster.edu/~fullermd          |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*




From owner-freebsd-hackers  Wed Dec 17 15:43:53 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA26970
          for hackers-outgoing; Wed, 17 Dec 1997 15:43:53 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 PAA26897
          for ; Wed, 17 Dec 1997 15:43:25 -0800 (PST)
          (envelope-from brian@awfulhak.org)
Received: from gate.lan.awfulhak.org (localhost [127.0.0.1])
	by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id XAA08846;
	Wed, 17 Dec 1997 23:32:37 GMT
	(envelope-from brian@gate.lan.awfulhak.org)
Message-Id: <199712172332.XAA08846@awfulhak.demon.co.uk>
X-Mailer: exmh version 2.0zeta 7/24/97
To: dennis 
cc: Greg Lehey , hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask 
In-reply-to: Your message of "Tue, 16 Dec 1997 19:38:10 EST."
             <3.0.32.19971216193810.00b3b480@etinc.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 23:32:36 +0000
From: Brian Somers 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

[.....]
> Even if you specifiy a non-host mask, a host route is set...if that is the
> case then only a host mask should be allowed, and a host mask should
> be forced. You SHOULD be able to override the host setting, that is, if a
> mask is specified explicitly then the route should be set according to the
> netmask.

I agree, and I'll implement the change unless someone has a good 
reason not to..... any takers ?

> Dennis

-- 
Brian , , 
      
Don't _EVER_ lose your sense of humour....



From owner-freebsd-hackers  Wed Dec 17 15:47:39 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA27443
          for hackers-outgoing; Wed, 17 Dec 1997 15:47:39 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from mail.calweb.com (mail.calweb.com [208.131.56.11])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA27384
          for ; Wed, 17 Dec 1997 15:47:22 -0800 (PST)
          (envelope-from dlangley@calweb.com)
Received:  by mail.calweb.com (8.8.6/8.8.6) with SMTP id PAA19507
	for ; Wed, 17 Dec 1997 15:47:14 -0800 (PST)
X-SMTP: helo ip74.dlangley.calweb.com from dlangley@calweb.com server @ip74.dlangley.calweb.com ip 207.173.133.74
Message-Id: <3.0.5.32.19971217154730.007c6100@pop.calweb.com>
X-Sender: dlangley@pop.calweb.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 17 Dec 1997 15:47:30 -0800
To: freebsd-hackers@freebsd.org
From: Doug Langley 
Subject: A question about virtual consoles
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 attempting to port some Braille and Speech software to FreeBSD.
These packages work by reading text from the current virtual
console and piping it to a process wich either translates it to braille,
dumps it to a serial port with an external speech synthesizer hooked to
it, or converts it to a wave file for output from mbrola.  I'm having
difficulty accessing the screen and the typed text from the currently
active Virtual console, and piping it somewhere else for processing.  Is
there some way the snoop device can be used for this project?  If it helps
anyone, the  software we are porting is linux-
based and relies on the /dev/vcs? and /dev/vcsa? devices.  From what I'm
given to understand, /dev/vcsa0 contains the text of the currently active
virtual console, and /dev/vcs0 contains the complete current console,
including
scrollback.  All of the programs make use of the /dev/vcsa0 device.  If
anyone can give me some ideas on where to find the text from the  local
VCS (ttyv0, ttyv1) I would greatly appreciate the help.  Please email me
privately as well, since I'm not on the list.

Thanks!



From owner-freebsd-hackers  Wed Dec 17 15:49:14 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA27641
          for hackers-outgoing; Wed, 17 Dec 1997 15:49:14 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 PAA26934
          for ; Wed, 17 Dec 1997 15:43:42 -0800 (PST)
          (envelope-from brian@awfulhak.org)
Received: from gate.lan.awfulhak.org (localhost [127.0.0.1])
	by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id XAA08835;
	Wed, 17 Dec 1997 23:30:21 GMT
	(envelope-from brian@gate.lan.awfulhak.org)
Message-Id: <199712172330.XAA08835@awfulhak.demon.co.uk>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Archie Cobbs 
cc: grog@lemis.com (Greg Lehey), dennis@etinc.com, hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask 
In-reply-to: Your message of "Tue, 16 Dec 1997 18:21:38 PST."
             <199712170221.SAA17619@bubba.whistle.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 23:30:21 +0000
From: Brian Somers 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> Greg Lehey writes:
> > On Tue, Dec 16, 1997 at 10:39:08AM -0500, dennis wrote:
> > >
> > > Is there any chance of this getting fixed? Its been broken forever. I'm
> > > talking about PTP interfaces, where the routes are inherently host
> > > mask routes. ifconfig reports the natural mask or whatever you give
> > > it....and its rather confusing trying to explain to the woodchucks that
> > > its wrong.
> > 
> > Well, ifconfig reports the net mask that is set.  And yes, it's
> > inappropriate for "real" point-to-point interfaces.  But it's not the
> > reporting that's wrong, it's the setting.  Just set all ones when
> > setting the interface, and you'll be OK.
> > 
> > I suppose I should mention that there's a sizeable minority who think
> > this is the way the net mask *should* be.  Maybe one of them will
> > explain, I keep forgetting.
> 
> I agree with Dennis..
> 
> The bottom line is that no matter what you set the netmask to,
> it has absolutely no effect on anything.
> 
> So unless the current behavior is going to be changed, the netmask
> should be removed from the display (at least) because it serves only
> to confuse people.

Has this always been like this ?  I would *expect* the netmask to 
control who's on the other side, so an interface with

  inet 10.0.2.1 --> 10.0.1.1 netmask 0xffffff00

should create a route with

  10.0.1/24 10.0.2.1 UH ..... tun0

This clearly isn't the case - the mask is lost when the route is 
created at SIOCAIFADDR time.

This, IMHO is wrong.  ioctl(SIOCAIFADDR) should provide RTA_NETMASK 
as a part of rtm_addrs !

> -Archie
> 
> ___________________________________________________________________________
> Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

-- 
Brian , , 
      
Don't _EVER_ lose your sense of humour....



From owner-freebsd-hackers  Wed Dec 17 16:14:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA29325
          for hackers-outgoing; Wed, 17 Dec 1997 16:14:42 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 QAA29315
          for ; Wed, 17 Dec 1997 16:14:25 -0800 (PST)
          (envelope-from dennis@etinc.com)
Received: from dbsys.etinc.com (dbsys.etinc.com [204.141.95.138]) by etinc.com (8.8.3/8.6.9) with SMTP id TAA16836; Wed, 17 Dec 1997 19:18:24 -0500 (EST)
Message-Id: <3.0.32.19971217191713.00d44320@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 17 Dec 1997 19:17:13 -0500
To: Karl Denninger  
From: dennis 
Subject: Re: ifconfig reports bogus netmask
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 09:41 AM 12/17/97 -0600, you wrote:
>On Wed, Dec 17, 1997 at 10:08:26AM -0500, dennis wrote:
>> At 11:34 AM 12/17/97 +1030, Greg Lehey wrote:
>> Your ISP, unfortunately, most likely uses Ciscos, which CANNOT route to
>> hosts. Ciscos can only route to nets, so you must set the PTP interface
>> to a subnet mask. This is  a waste of a net and arguably wrong (since there
>> is, in fact, no network), but we live in a world of ciscoheads. With unix
>> you only need use 2 addresses per  PTP interface..with ciscos you need to
>> use an entire subnet.
>> 
>> Dennis
>
>Balderdash.
>
>CISCOs can run un-numbered interfaces (the proper way to do a PTP link where
>the terminal end is not a network) and further, can in fact handle and 
>advertise host routes.

Ha, ha. "Unnumbered Interfaces" are a kludge created by Cisco to correct
the fact
that their interfaces must be on a net. Unnumbered interfaces break the
rules of
 routing.


Dennis

From owner-freebsd-hackers  Wed Dec 17 17:22:22 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA03628
          for hackers-outgoing; Wed, 17 Dec 1997 17:22:22 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03609
          for ; Wed, 17 Dec 1997 17:21:43 -0800 (PST)
          (envelope-from arg@arg1.demon.co.uk)
Received: (from arg@localhost)
	by arg1.demon.co.uk (8.8.5/8.8.5) id BAA17875;
	Thu, 18 Dec 1997 01:21:29 GMT
Date: Thu, 18 Dec 1997 01:21:29 +0000 (GMT)
From: Andrew Gordon 
X-Sender: arg@server.arg.sj.co.uk
cc: benedict@echonyc.com, hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask
In-Reply-To: <26766.882398347@verdi.nethelp.no>
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 Dec 1997 sthaug@nethelp.no wrote:

> > This is only a problem if you want everyone to see your network topology.
> > But why would someone need to traceroute you from another AS?
> 
> - I traceroute to other ASes every day, and I find it extremely useful
> to see for instance where a path stops.
> 
> - traceroute is not the only use for ICMP.

Notably, TCP path MTU discovery - where not seeing the ICMP messages
rejecting your too-big packets can stop things working altogether.

From owner-freebsd-hackers  Wed Dec 17 17:22:52 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA03687
          for hackers-outgoing; Wed, 17 Dec 1997 17:22:52 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03353
          for ; Wed, 17 Dec 1997 17:17:16 -0800 (PST)
          (envelope-from arg@arg1.demon.co.uk)
Received: (from arg@localhost)
	by arg1.demon.co.uk (8.8.5/8.8.5) id BAA17849;
	Thu, 18 Dec 1997 01:15:51 GMT
Date: Thu, 18 Dec 1997 01:15:50 +0000 (GMT)
From: Andrew Gordon 
X-Sender: arg@server.arg.sj.co.uk
To: Mike Smith 
cc: FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-Reply-To: <199712170334.OAA01300@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

On Wed, 17 Dec 1997, Mike Smith wrote:
> > If I can't route 4 ethernet interfaces with SMC Ultras then a rigorous
> > academic exercise has no value for my purposes.  I just want a rough
> > projection that's reasonably accurate.
> 
> "AT Bus Design" (Edward Solari, Annabooks), p 6-101, quoted without 
> permission, excerpt from table 6-3: ISA AND E-ISA PLATFORM STANDARD 
> ACCESS MEMORY CYCLE LENGTH

Note that a _standard_ cycle isn't the fastest possible cycle: 16-bit
memory cycles have one wait state, but a board can generate 0 w/s
cycles by holding NOWS* low.  Since this is only applicable to memory
cycles, this is the reason the WD/SMC boards (memory mapped) used
to be considered superior to NE2000 clones (I/O cycles, hence 1 w/s min).

> 
> BUS OWNER	CYCLE BEGINS	CYCLE ENDS	CYCLE	CYCLE
> 						SIZE	LENGTH
> ---------------------------------------------------------------
> PLAT FORM (sic)	.5 TCLK TO	END COMMAND	 8 BITS	6 TCLK
> CPU		ACT BALE	ACT PERIOD	16 BITS	3 TCLK
> 
> For reference, TCLK is the period of BCLK, ie. 1 TCLK ~= 120ns for the 
> standard 8.33MHz BCLK.
> So a 16-bit memory cycle on the ISA bus takes at least 360ns.
> If you flip that the other way around and account for the other .5 TCLK 
> idle before BALE can go active again,

??? You appear to be double-counting here - that 0.5 cycle before BALE
is included in the 3 cycles (or 2 cycles at 0 w/s).  After all, since
the polarity of BCLK doesn't change, the interval between successive
accesses (assuming no other activity on the ISA bus) _must_ be an
integer number of cycles, so the answer can't possibly be 2.5.

>  you get about 2.5 16-bit cycles 
> per microsecond, or about 5MB/sec ISA memory bandwidth.

If you can actually generate back-to-back 16-bit 0 w/s memory cycles,
you get 8Mbyte/sec.  Ability to do so presumably depends substantially on 
the behaviour of the ISA bridge behaviour in the chipset on modern 
machines; the relationship of the ISA bus to CPU cycles is non-obvious.


From owner-freebsd-hackers  Wed Dec 17 17:32:15 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA04437
          for hackers-outgoing; Wed, 17 Dec 1997 17:32:15 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cynic.portal.ca (root@cynic.portal.ca [204.174.36.7])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA04379
          for ; Wed, 17 Dec 1997 17:31:37 -0800 (PST)
          (envelope-from cjs@portal.ca)
Received: from localhost ([[UNIX: localhost]])
	by cynic.portal.ca (8.8.5/8.8.5) with SMTP id RAA06382;
	Wed, 17 Dec 1997 17:30:47 -0800 (PST)
X-Authentication-Warning: cynic.portal.ca: cjs owned process doing -bs
Date: Wed, 17 Dec 1997 17:30:46 -0800 (PST)
From: Curt Sampson 
To: Warner Losh 
cc: Gary Palmer , itojun@itojun.org, hackers@freebsd.org
Subject: Re: Beginning SPARC port 
In-Reply-To: <199712141900.MAA04338@harmony.village.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 Sun, 14 Dec 1997, Warner Losh wrote:

> For a long time Linux has used outb/inb (and maybe still does) for
> accessing I/O space.

Yup. And for a long time Linux has had eleven different drivers
for the Lance Ethernet chip, depending on which combination of
machine and bus you're using. (NetBSD has one for all machines,
with a handful of small bus-dependent front ends for the driver.)

cjs

Curt Sampson    cjs@portal.ca	   Info at http://www.portal.ca/
Internet Portal Services, Inc.	   Through infinite mist, software reverberates
Vancouver, BC  (604) 257-9400	   In code possess'd of invisible folly.


From owner-freebsd-hackers  Wed Dec 17 19:20:35 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA11656
          for hackers-outgoing; Wed, 17 Dec 1997 19:20:35 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA11395
          for ; Wed, 17 Dec 1997 19:17:39 -0800 (PST)
          (envelope-from tlambert@usr07.primenet.com)
Received: (from daemon@localhost)
	by smtp01.primenet.com (8.8.8/8.8.8) id UAA23252;
	Wed, 17 Dec 1997 20:17:36 -0700 (MST)
Received: from usr07.primenet.com(206.165.6.207)
 via SMTP by smtp01.primenet.com, id smtpd023234; Wed Dec 17 20:17:31 1997
Received: (from tlambert@localhost)
	by usr07.primenet.com (8.8.5/8.8.5) id UAA07959;
	Wed, 17 Dec 1997 20:17:27 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712180317.UAA07959@usr07.primenet.com>
Subject: Re: Why so many steps to build new kernel?
To: nate@mt.sri.com (Nate Williams)
Date: Thu, 18 Dec 1997 03:17:26 +0000 (GMT)
Cc: tlambert@primenet.com, nate@mt.sri.com, daniel_sobral@voga.com.br,
        hackers@freebsd.org
In-Reply-To: <199712172234.PAA14402@mt.sri.com> from "Nate Williams" at Dec 17, 97 03:34:31 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > Heck, I've got 10-20 people willing to be added to the 'FS-101' list by
> > > you, but up till now very little progress has been made.  Why do you
> > > expect other developers to spend the 1000 hours of work add new features
> > > to make your life easier when you aren't willing to spend 1-2 to get
> > > things started.
> > 
> > Heh.  Committers outnumber contributors...
> 
> Actually, only 2 are committers.  You still haven't answered the
> question though.  Why are you willing to donate *my* time yet you aren't
> willing to donate anytime of your own?

What you have asked for is actually a hell of a lot more work than
just supplying the patches... it's basically an explanation of the
reasoning behind my FS worldview, and why I approach solving FS
problems the way I do, and exactly what makes me think something
is a problem or not.

It's a lot harder to provide this information in a coherent fashion
than it is to burn of a set of patches and say "apply these and call
me in the morning".

I have to actually block out a large chunk of time to be able to do
this in a way that isn't half-assed.  I'm a bit cautious here as well:
if I say something that is half-assed, then there'll be something to
point at and say "that's half-assed".  This is very different, again,
than patches, where the worst you can say is "hey, those don't work".

I'm willing to open myself up for a critique of my philosophy, but
only if I can present it coherently without making assumptions about
the audience that will make me look either patronizing or technobabling.
It's a hell of a line to be asked to walk.

As far as donating your time... with the kernel configurator discussion,
I'm actually asking people to *not* donate their time.


					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 Dec 17 19:28:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA12133
          for hackers-outgoing; Wed, 17 Dec 1997 19:28:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 TAA12036;
          Wed, 17 Dec 1997 19:27:17 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id NAA13167;
          Thu, 18 Dec 1997 13:56:32 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971218135632.16344@lemis.com>
Date: Thu, 18 Dec 1997 13:56:32 +1030
From: Greg Lehey 
To: Steve Price 
Cc: questions@FreeBSD.org, FreeBSD Hackers 
Subject: Re: Sony GDM-1692B in text mode?
References:  <19971218131942.58757@lemis.com> <3498969C.2F1CF0FB@hiwaay.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <3498969C.2F1CF0FB@hiwaay.net>; from Steve Price on Wed, Dec 17, 1997 at 09:21:00PM -0600
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, Dec 17, 1997 at 09:21:00PM -0600, Steve Price wrote:
> Greg Lehey wrote:
>> I don't know that particular model.  Is there a problem with it?  Do
>> you have any documentation about it?  What kind of connector does it
>> have?  If it comes with a 15 pin VGA connector, it'll probably work
>> fine in VGA mode.
>
> Actually the subject line is incorrect, it should say GDM-1962B.

Yes, you mentioned that elsewhere.

> The cable is a D15 male to 13W3 female.  It won't work in just
> any VGA mode.  This monitor is a fixed frequency, color monitor
> that originally was shipped with a Sun IPC that I bought at work
> around 1992.

Ah.  That's good news.  That will be 61.8 kHz horizontal, 65 Hz
vertical.

>> If you can't get it to display text, one alternative would be to keep
>> the 13" monitor for text, and use the Sony for X.  This would mean
>> adding a second board, of course.  I think the #9 will coexist with a
>> cheap standard VGA.
>
> My only concern is the boot messages really, since I run
> -current and sometimes things can go awry.  I have thought
> of doing something along the lines of what you are suggesting
> but with a Video A/B selector box.  The big problem I have
> is lack of desk space on which to put a third monitor, which
> is why I asked if anybody had this beast working in text mode. :)

I know the problem.  One of my monitors is on the floor under the
desk.

> I don't profess to know much about video cards, but is there
> anyway for it to tell that it is attached to a fixed frequency
> monitor?  Or is it possible to kludge up a kernel to set the
> required HSYNC/VSYNC frequencies early on in the boot sequence?

I was wondering whether it wouldn't be worthwhile writing a version of
the console driver which would start up in a different mode.  It would
require more work than it appears, since VGAs normally do the text
display themselves, but that wouldn't be possible in graphics mode.

> Hmm... maybe I should ask the above questions in -hackers
> instead of -questions? :)

Good idea.  I'm sure Terry will find many reasons why it won't work
:-)  Following up to -hackers.

Greg

From owner-freebsd-hackers  Wed Dec 17 19:34:49 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA12854
          for hackers-outgoing; Wed, 17 Dec 1997 19:34:49 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from kai.communique.net (Kai.communique.net [204.27.67.90])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA12267
          for ; Wed, 17 Dec 1997 19:29:08 -0800 (PST)
          (envelope-from nectar@kai.communique.net)
Received: (from smap@localhost)
	by kai.communique.net (8.8.8/8.8.7) id VAA10624;
	Wed, 17 Dec 1997 21:34:44 -0600 (CST)
Message-Id: <199712180334.VAA10624@kai.communique.net>
X-Authentication-Warning: kai.communique.net: smap set sender to  using -f
Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0)
	id xma010621; Wed, 17 Dec 97 21:34:36 -0600
From: Jacques Vidrine 
To: Andrew Gordon 
cc: benedict@echonyc.com, hackers@freebsd.org
Subject: Re: ifconfig reports bogus netmask 
In-reply-to:  
References: 
Date: Wed, 17 Dec 1997 21:34:36 -0600
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


I feel I should point out that I think this is avoidable ...

If one uses RFC1918 addresses, and one wishes to avoid problems with
Path MTU Discovery, one could simply pick MTUs for the interfaces with
RFC1918 addresses that are at least as large as the largest MTU found
on any of the other interfaces on that router.

There's probably a more concise way of saying that ...

Jacques Vidrine 

On 18 December 1997 at 1:21, Andrew Gordon  wrote:
> Notably, TCP path MTU discovery - where not seeing the ICMP messages
> rejecting your too-big packets can stop things working altogether.

From owner-freebsd-hackers  Wed Dec 17 21:53:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA20882
          for hackers-outgoing; Wed, 17 Dec 1997 21:53:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA19908
          for ; Wed, 17 Dec 1997 21:35:03 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id WAA13528;
	Wed, 17 Dec 1997 22:11:12 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id WAA15280; Wed, 17 Dec 1997 22:11:09 -0700
Date: Wed, 17 Dec 1997 22:11:09 -0700
Message-Id: <199712180511.WAA15280@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), daniel_sobral@voga.com.br,
        hackers@freebsd.org
Subject: Re: Why so many steps to build new kernel?
In-Reply-To: <199712180317.UAA07959@usr07.primenet.com>
References: <199712172234.PAA14402@mt.sri.com>
	<199712180317.UAA07959@usr07.primenet.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> What you have asked for is actually a hell of a lot more work than
> just supplying the patches... it's basically an explanation of the
> reasoning behind my FS worldview, and why I approach solving FS
> problems the way I do, and exactly what makes me think something
> is a problem or not.

I never said it wasn't work.  But, much *less* so than making a compiler
work that much faster or generate measurably faster code, which takes a
*LOT* nowadays.

We're not comparing 'apply these patches' vs. 'explain FS design'.
We're comparing 'volunteering a bunch of FreeBSD volunteers to re-write
LKM, move to ELF, build pageable kernels, build faster compilers,
implement VM86, change the way swap is allocated, make the kernel's
locking much more fine-grained, architecture independant build system,
etc...'.

> I have to actually block out a large chunk of time to be able to do
> this in a way that isn't half-assed.

See above.  For useful/robust solutions to the above, a person needs
large chunks of time to keep everything straight, since at least a
portion of the above problems are at least as complex in terms of
keeping lots of things straight.



Nate

From owner-freebsd-hackers  Wed Dec 17 22:22:03 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA23226
          for hackers-outgoing; Wed, 17 Dec 1997 22:22:03 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from hotmail.com (F87.hotmail.com [207.82.250.193])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA23218
          for ; Wed, 17 Dec 1997 22:21:54 -0800 (PST)
          (envelope-from olagappan@hotmail.com)
Received: (qmail 24294 invoked by uid 0); 18 Dec 1997 06:21:23 -0000
Message-ID: <19971218062123.24293.qmail@hotmail.com>
Received: from 192.86.155.92 by www.hotmail.com with HTTP;
	Wed, 17 Dec 1997 22:21:23 PST
X-Originating-IP: [192.86.155.92]
From: "muthu olagappan" 
To: freebsd-hackers@freebsd.org
Subject: Volunteer for coding
Content-Type: text/plain
Date: Wed, 17 Dec 1997 22:21:23 PST
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,


    Iam interested in  doing coding for freebsd. I have read the 
internals of freebsd. Please do respond to this mail.


With regards,
Muthu.o.L.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From owner-freebsd-hackers  Thu Dec 18 03:24:26 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA10387
          for hackers-outgoing; Thu, 18 Dec 1997 03:24:26 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp10.portal.net.au [202.12.71.110])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA10377
          for ; Thu, 18 Dec 1997 03:24:15 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id VAA00374;
	Thu, 18 Dec 1997 21:48:18 +1030 (CST)
Message-Id: <199712181118.VAA00374@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Andrew Gordon 
cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Thu, 18 Dec 1997 01:15:50 -0000."
              
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 18 Dec 1997 21:48:18 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> On Wed, 17 Dec 1997, Mike Smith wrote:
> > > If I can't route 4 ethernet interfaces with SMC Ultras then a rigorous
> > > academic exercise has no value for my purposes.  I just want a rough
> > > projection that's reasonably accurate.
> > 
> > "AT Bus Design" (Edward Solari, Annabooks), p 6-101, quoted without 
> > permission, excerpt from table 6-3: ISA AND E-ISA PLATFORM STANDARD 
> > ACCESS MEMORY CYCLE LENGTH
> 
> Note that a _standard_ cycle isn't the fastest possible cycle: 16-bit
> memory cycles have one wait state, but a board can generate 0 w/s
> cycles by holding NOWS* low.  Since this is only applicable to memory
> cycles, this is the reason the WD/SMC boards (memory mapped) used
> to be considered superior to NE2000 clones (I/O cycles, hence 1 w/s min).

Correct.  However 0WS operation was recently enabled for the 'ed' 
driver and WD cards, but it had to be backed out for reliability 
reasons.  The only other cards that I've met with 0WS jumpers have had
loud warnings in the manual involving fire and the loss of your 
first-born.

> > BUS OWNER	CYCLE BEGINS	CYCLE ENDS	CYCLE	CYCLE
> > 						SIZE	LENGTH
> > ---------------------------------------------------------------
> > PLAT FORM (sic)	.5 TCLK TO	END COMMAND	 8 BITS	6 TCLK
> > CPU		ACT BALE	ACT PERIOD	16 BITS	3 TCLK
> > 
> > For reference, TCLK is the period of BCLK, ie. 1 TCLK ~= 120ns for the 
> > standard 8.33MHz BCLK.
> > So a 16-bit memory cycle on the ISA bus takes at least 360ns.
> > If you flip that the other way around and account for the other .5 TCLK 
> > idle before BALE can go active again,
> 
> ??? You appear to be double-counting here - that 0.5 cycle before BALE
> is included in the 3 cycles (or 2 cycles at 0 w/s).  After all, since
> the polarity of BCLK doesn't change, the interval between successive
> accesses (assuming no other activity on the ISA bus) _must_ be an
> integer number of cycles, so the answer can't possibly be 2.5.

Hmm.  My reading of the timing diagram infers that for the cycle to 
complete you've slopped into the 4th TCLK, ie. you can't back-to-back 
ISA memory cycles.  (Humble admission, I've only done ISA I/O adapters, 
so I can't quote from any of my notes...)

> >  you get about 2.5 16-bit cycles 
> > per microsecond, or about 5MB/sec ISA memory bandwidth.
> 
> If you can actually generate back-to-back 16-bit 0 w/s memory cycles,
> you get 8Mbyte/sec.  Ability to do so presumably depends substantially on 
> the behaviour of the ISA bridge behaviour in the chipset on modern 
> machines; the relationship of the ISA bus to CPU cycles is non-obvious.

No joke.  And if you think that's bad, try working on the other side of 
a PCI-to-generic bridge.  8)

mike


From owner-freebsd-hackers  Thu Dec 18 03:50:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA11825
          for hackers-outgoing; Thu, 18 Dec 1997 03:50:42 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 DAA11820
          for ; Thu, 18 Dec 1997 03:50:34 -0800 (PST)
          (envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id DAA06505;
          Thu, 18 Dec 1997 03:50:33 -0800 (PST)
Message-ID: <19971218035032.46460@hydrogen.nike.efn.org>
Date: Thu, 18 Dec 1997 03:50:32 -0800
From: John-Mark Gurney 
To: FreeBSD Hackers 
Subject: converting drivers to dynamic memory...
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

well...  one of the things that will need to be done in preperation
for moving to a dynamic system which will be required by the bus/device
code, we will need to eliminate ALL static datat that depends upon
Ndevice to size itself.

There are two ways that we can fix this problem.  The first (and
technically the best) is to be extend many of the calling functions
to pass around a void * pointer that will point to that devices
resources.  Though this is technically best, it will require that
most major parts of the kernel be significantly changes.

The second solution is to continue to use the major/minor code scheme,
but use a binary tree or a B-tree to obtain the private data.  This
can cause a performance impact if we use if for things like the sio,
but this can be fixed by changing the interrupt interface.

I think that we should go with the second solution as it will be
initalially easier to do.  I have B-tree code already writen, (I was
writing it for another use in my bus/device code) which we could use
to access this information.  (Some people will say, why not linked
lists, and then I will say, sio, I have 12 ports on my term server,
plus you get better data density)

On another note, how do people feel about more complex data structures
becoming standard parts of the kernel.  I think there are a number of
places that using a more complex data structure would be a big win.
I have code for both Fibonacci Heaps and B-tree's that just need some
cleaning up to be generally useful.  The code bloat would actually be
quite small.  The Fib heap code is under 3k, and the B-tree code is
4736 bytes, but this includes some debuging code (printing tree and
checking that the tree is in order).

Timings:
	Fibonacci heap (amortized):
		Make-Heap	theta(1)
		Insert		theta(1)
		Minimum		theta(1)
		Extract-min	O(lg n)
		Union		theta(1)
		Decrease-key	theta(1)
		Delete		O(lg n)
	B-Tree (each node has between t - 1 and 2t -1 keys)
		Create		O(1)
		Search		O(t logt n) soon to be O(lg t * logt n)
		Insert		  "
		Delete		  "

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking					  P.O. Box 5693, 97405

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-hackers  Thu Dec 18 04:17:47 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA13592
          for hackers-outgoing; Thu, 18 Dec 1997 04:17:47 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA13580
          for ; Thu, 18 Dec 1997 04:17:34 -0800 (PST)
          (envelope-from avalon@coombs.anu.edu.au)
Message-Id: <199712181217.EAA13580@hub.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA233727408; Thu, 18 Dec 1997 23:16:48 +1100
From: Darren Reed 
Subject: Re: converting drivers to dynamic memory...
To: gurney_j@resnet.uoregon.edu
Date: Thu, 18 Dec 1997 23:16:48 +1100 (EDT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <19971218035032.46460@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 18, 97 03:50:32 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from John-Mark Gurney, sie said:
> 
> well...  one of the things that will need to be done in preperation
> for moving to a dynamic system which will be required by the bus/device
> code, we will need to eliminate ALL static datat that depends upon
> Ndevice to size itself.
> 
> There are two ways that we can fix this problem.  The first (and
> technically the best) is to be extend many of the calling functions
> to pass around a void * pointer that will point to that devices
> resources.  Though this is technically best, it will require that
> most major parts of the kernel be significantly changes.
> 
> The second solution is to continue to use the major/minor code scheme,
> but use a binary tree or a B-tree to obtain the private data.  This
> can cause a performance impact if we use if for things like the sio,
> but this can be fixed by changing the interrupt interface.

> I think that we should go with the second solution as it will be
> initalially easier to do.  I have B-tree code already writen, (I was
> writing it for another use in my bus/device code) which we could use
> to access this information.  (Some people will say, why not linked
> lists, and then I will say, sio, I have 12 ports on my term server,
> plus you get better data density)

I guess the question is, do you want a `quick hack' or a real solution to
fix and addres the problem ?

How many hours did you spend on the B-Tree stuff and how many do you
expect it would take to do it the other way ?

"Do it once and do it right."


From owner-freebsd-hackers  Thu Dec 18 04:26:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA14114
          for hackers-outgoing; Thu, 18 Dec 1997 04:26:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA14102
          for ; Thu, 18 Dec 1997 04:26:07 -0800 (PST)
          (envelope-from syssgm@dtir.qld.gov.au)
Received: by ren.dtir.qld.gov.au; id WAA04715; Thu, 18 Dec 1997 22:33:03 +1000 (EST)
Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2)
	id xma004713; Thu, 18 Dec 97 22:33:01 +1000
Received: from troll.dtir.qld.gov.au (troll.dtir.qld.gov.au [167.123.8.1])
	by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with ESMTP id WAA08219;
	Thu, 18 Dec 1997 22:26:52 +1000 (EST)
Received: from localhost (syssgm@localhost)
	by troll.dtir.qld.gov.au (8.8.5/8.8.5) with SMTP id WAA03180;
	Thu, 18 Dec 1997 22:26:48 +1000 (EST)
Message-Id: <199712181226.WAA03180@troll.dtir.qld.gov.au>
X-Authentication-Warning: troll.dtir.qld.gov.au: syssgm@localhost didn't use HELO protocol
To: Wilko Bulte 
cc: freebsd-hackers@FreeBSD.ORG, syssgm@dtir.qld.gov.au
Subject: Re: volume control on SCSI Toshiba CDdrive 
References: <199712172007.VAA02676@yedi.iaf.nl>
In-Reply-To: <199712172007.VAA02676@yedi.iaf.nl>
    from Wilko Bulte at "Wed, 17 Dec 1997 21:07:35 +0100"
Date: Thu, 18 Dec 1997 22:26:48 +1000
From: Stephen McKay 
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wednesday, 17th December 1997, Wilko Bulte wrote:

>Well it took some time, but I haven't given up:
>
>TOSHIBA CD-ROM XM-5701TA 0557
>
>is a firmware rev that has *working* audio control...

This is good news!  But how do we know it's *only* the firmware that is
different?  Maybe it's new firmware that just happens to be present on a
working hardware revision.  Still, I can hope.

>As far as getting in touch with a contact in Toshiba I did not have as much
>luck. 

Sigh.  I know nobody with such contacts.  But I'll hassle everyone that I
think might know someone who knows someone!

Stephen.

From owner-freebsd-hackers  Thu Dec 18 04:26:28 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA14143
          for hackers-outgoing; Thu, 18 Dec 1997 04:26:28 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA14133
          for ; Thu, 18 Dec 1997 04:26:23 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-52.cetlink.net [209.54.58.52])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id HAA23897;
          Thu, 18 Dec 1997 07:26:08 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Andrew Gordon 
Cc: Mike Smith , FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
Date: Thu, 18 Dec 1997 13:27:04 GMT
Message-ID: <34992437.46914518@mail.cetlink.net>
References: 
In-Reply-To: 
X-Mailer: Forte Agent 1.01/16.397
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 EAA14137
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Thu, 18 Dec 1997 01:15:50 +0000 (GMT), Andrew Gordon
 wrote:


>Note that a _standard_ cycle isn't the fastest possible cycle: 16-bit
>memory cycles have one wait state, but a board can generate 0 w/s
>cycles by holding NOWS* low.  Since this is only applicable to memory
>cycles

What prevents use of 0 WS for I/O cycles?



John



From owner-freebsd-hackers  Thu Dec 18 04:48:24 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA15379
          for hackers-outgoing; Thu, 18 Dec 1997 04:48:24 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 EAA15373
          for ; Thu, 18 Dec 1997 04:48:15 -0800 (PST)
          (envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id EAA09244;
          Thu, 18 Dec 1997 04:48:05 -0800 (PST)
Message-ID: <19971218044804.38303@hydrogen.nike.efn.org>
Date: Thu, 18 Dec 1997 04:48:04 -0800
From: John-Mark Gurney 
To: Darren Reed 
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory...
References: <19971218035032.46460@hydrogen.nike.efn.org> <199712181217.EAA24070@resnet.uoregon.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199712181217.EAA24070@resnet.uoregon.edu>; from Darren Reed on Thu, Dec 18, 1997 at 11:16:48PM +1100
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

Darren Reed scribbled this message on Dec 18:
> In some mail from John-Mark Gurney, sie said:
> > well...  one of the things that will need to be done in preperation
> > for moving to a dynamic system which will be required by the bus/device
> > code, we will need to eliminate ALL static datat that depends upon
> > Ndevice to size itself.
> > 
> > There are two ways that we can fix this problem.  The first (and
> > technically the best) is to be extend many of the calling functions
> > to pass around a void * pointer that will point to that devices
> > resources.  Though this is technically best, it will require that
> > most major parts of the kernel be significantly changes.
> > 
> > The second solution is to continue to use the major/minor code scheme,
> > but use a binary tree or a B-tree to obtain the private data.  This
> > can cause a performance impact if we use if for things like the sio,
> > but this can be fixed by changing the interrupt interface.
> 
> > I think that we should go with the second solution as it will be
> > initalially easier to do.  I have B-tree code already writen, (I was
> > writing it for another use in my bus/device code) which we could use
> > to access this information.  (Some people will say, why not linked
> > lists, and then I will say, sio, I have 12 ports on my term server,
> > plus you get better data density)
> 
> I guess the question is, do you want a `quick hack' or a real solution to
> fix and addres the problem ?
> 
> How many hours did you spend on the B-Tree stuff and how many do you
> expect it would take to do it the other way ?

the B-tree code is generic, I wasn't writing it to solve the above
problem, just so that I would have the code in my archives for use
when I need it.. :)  so, time taken to write the B-Tree code shouldn't
be counted in the equation...

the reason I say the second solution is that it MIGHT take a person
two hours for the largest device to convert from the current table of
static data to dynamic...

if you do it right, you have to touch almost the ENTIRE system... and
modify any part of the system that calls drivers.. that means changing
the tty, char, block, and net interface code...  ALONG with doing the
modifications to the driver...  I personally haven't looked at the
interface layer for any of that code yet, so I don't know how long it
would take to modify the whole system...

if you do the second method, 90% of the work you do in that step will
be able to be reused for when you finally make the step to the first
method...  so, it's more along the lines of, lets get the system into
a state that I can continue to do my work, and then when I or someone
else has time, finish the job.  In the short term, getting the bus/device
code is a greater benifit then the minor loss of this "hack" to get it
working.

Reminds me of my social science teacher in high school.  She said,
most people think that the cost of college is just that of the tuition
you pay, but you have to also figure in the loss of not being able to
use your time to work.

> "Do it once and do it right."

"If you have time to do it right, do it right, else get it working." :)

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking					  P.O. Box 5693, 97405

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-hackers  Thu Dec 18 04:56:05 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA15912
          for hackers-outgoing; Thu, 18 Dec 1997 04:56:05 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA15907
          for ; Thu, 18 Dec 1997 04:56:01 -0800 (PST)
          (envelope-from jak@cetlink.net)
Received: from hot1.auctionfever.com (ts1-cltnc-11.cetlink.net [209.54.58.11])
          by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id HAA25182;
          Thu, 18 Dec 1997 07:55:49 -0500 (EST)
From: jak@cetlink.net (John Kelly)
To: Mike Smith 
Cc: Andrew Gordon , Mike Smith ,
        FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
Date: Thu, 18 Dec 1997 13:56:46 GMT
Message-ID: <349a26d6.47585537@mail.cetlink.net>
References: <199712181118.VAA00374@word.smith.net.au>
In-Reply-To: <199712181118.VAA00374@word.smith.net.au>
X-Mailer: Forte Agent 1.01/16.397
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 EAA15908
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Thu, 18 Dec 1997 21:48:18 +1030, Mike Smith 
wrote:

>Correct.  However 0WS operation was recently enabled for the 'ed' 
>driver and WD cards, but it had to be backed out for reliability 
>reasons.

Ah, you didn't mention that before.  I would like to review the
changes to enable 0WS in the 'ed' driver with the hope of getting my
cards to work at 0WS.  Can you tell me where to find those changes?

I've got the databook for the chipset on that 486 motherboard I
mentioned earlier, the one I'm running at 50MHz local bus and 12MHz
ISA bus.  I'm going to poke around in the chipset registers to see how
fast I can make it run without exploding.  It has 8 ISA slots, so who
knows, maybe I can jam six SMC Ultra ethernet adapters, a video card,
and a disk controller in the thing and set a record for ISA bus
ethernet routing.  I've got to do something with all these SMC Ultra
adapters stacked up in my closet. :-)

>The only other cards that I've met with 0WS jumpers have had
>loud warnings in the manual involving fire and the loss of your 
>first-born.

If the hardware ain't smoking, IT'S RUNNING TOO SLOW!

John




From owner-freebsd-hackers  Thu Dec 18 05:06:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA16668
          for hackers-outgoing; Thu, 18 Dec 1997 05:06:55 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA16658
          for ; Thu, 18 Dec 1997 05:06:46 -0800 (PST)
          (envelope-from arg@arg1.demon.co.uk)
Received: (from arg@localhost)
	by arg1.demon.co.uk (8.8.5/8.8.5) id NAA18771;
	Thu, 18 Dec 1997 13:05:52 GMT
Date: Thu, 18 Dec 1997 13:05:51 +0000 (GMT)
From: Andrew Gordon 
X-Sender: arg@server.arg.sj.co.uk
To: Mike Smith 
cc: FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-Reply-To: <199712181118.VAA00374@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

On Thu, 18 Dec 1997, Mike Smith wrote:
> > Note that a _standard_ cycle isn't the fastest possible cycle: 16-bit
> > memory cycles have one wait state, but a board can generate 0 w/s
> > cycles by holding NOWS* low.  Since this is only applicable to memory
> > cycles, this is the reason the WD/SMC boards (memory mapped) used
> > to be considered superior to NE2000 clones (I/O cycles, hence 1 w/s min).
> 
> Correct.  However 0WS operation was recently enabled for the 'ed' 
> driver and WD cards, but it had to be backed out for reliability 
> reasons.  The only other cards that I've met with 0WS jumpers have had
> loud warnings in the manual involving fire and the loss of your 
> first-born.

Hmm.  Problem here seems to be the wide variety of cards the ed driver
supports (besides the wide variety of machines people plug them into...)
Some of the problems noted in the commit log against that change don't
really relate to the 16-bit memory accesses at all (eg. failure to read 
the MAC address from the EEPROM on warm boot).

> > ??? You appear to be double-counting here - that 0.5 cycle before BALE
> > is included in the 3 cycles (or 2 cycles at 0 w/s).  After all, since
> > the polarity of BCLK doesn't change, the interval between successive
> > accesses (assuming no other activity on the ISA bus) _must_ be an
> > integer number of cycles, so the answer can't possibly be 2.5.
> 
> Hmm.  My reading of the timing diagram infers that for the cycle to 
> complete you've slopped into the 4th TCLK, ie. you can't back-to-back 
> ISA memory cycles.  (Humble admission, I've only done ISA I/O adapters, 
> so I can't quote from any of my notes...)

You can get back-to-back cycles, at least on a real ISA bus machine: 
there is a degree of overlap (depending which point you consider to be the
'start' of the cycle, either the high-order addresses have started to
appear before the end of the previous cycle, or the data bus is still in
use during the start of the next cycle). 

This probably does mean that you miss a cycle doing individual accesses 
across a PCI->ISA bridge (because you don't get the next address available), 
but a good bridge ought to be able to pipeline a burst of memory accesses.
Mind you, I don't suppose chipset manufacturers care too much about their 
ISA performance these days, considering the ISA bus just to be there 
for legacy devices - if the customer cared about performance, they'd 
have bought a PCI Card, wouldn't they?

Either way, this doesn't affect the advantage of 0WS over 1WS: it's just 
a question of whether it is 2 cycles vs 3, or 3 vs 4.  Just a shame we 
can't use it; perhaps a flags option in the ed driver would be in order 
to enable 0WS for the benefit of speed-freaks with carefully chosen hardware?

From owner-freebsd-hackers  Thu Dec 18 05:10:41 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA16956
          for hackers-outgoing; Thu, 18 Dec 1997 05:10:41 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA16944
          for ; Thu, 18 Dec 1997 05:10:30 -0800 (PST)
          (envelope-from arg@arg1.demon.co.uk)
Received: (from arg@localhost)
	by arg1.demon.co.uk (8.8.5/8.8.5) id NAA18799;
	Thu, 18 Dec 1997 13:10:03 GMT
Date: Thu, 18 Dec 1997 13:10:03 +0000 (GMT)
From: Andrew Gordon 
X-Sender: arg@server.arg.sj.co.uk
To: John Kelly 
cc: FreeBSD Hackers 
Subject: Re: 3com 3c509 card 
In-Reply-To: <34992437.46914518@mail.cetlink.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 Thu, 18 Dec 1997, John Kelly wrote:
> On Thu, 18 Dec 1997 01:15:50 +0000 (GMT), Andrew Gordon
>  wrote:
>
> >Note that a _standard_ cycle isn't the fastest possible cycle: 16-bit
> >memory cycles have one wait state, but a board can generate 0 w/s
> >cycles by holding NOWS* low.  Since this is only applicable to memory
> >cycles
> 
> What prevents use of 0 WS for I/O cycles?
> 

The ISA bus.  The NOWS* signal is defined to apply only to memory 
cycles.  This dates back to 286 machines with their main memory on the 
ISA bus: making the memory run at full speed was critical, dropping an 
extra cycle for I/O devices (many of which would insert even more wait 
states of their own) was not.

From owner-freebsd-hackers  Thu Dec 18 05:28:03 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA17872
          for hackers-outgoing; Thu, 18 Dec 1997 05:28:03 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA17836
          for ; Thu, 18 Dec 1997 05:27:50 -0800 (PST)
          (envelope-from avalon@coombs.anu.edu.au)
Message-Id: <199712181327.FAA17836@hub.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA239771384; Fri, 19 Dec 1997 00:23:04 +1100
From: Darren Reed 
Subject: Re: converting drivers to dynamic memory...
To: gurney_j@resnet.uoregon.edu
Date: Fri, 19 Dec 1997 00:23:04 +1100 (EDT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <19971218044804.38303@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 18, 97 04:48:04 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from John-Mark Gurney, sie said:
> 
> Darren Reed scribbled this message on Dec 18:
> > In some mail from John-Mark Gurney, sie said:
> > > well...  one of the things that will need to be done in preperation
> > > for moving to a dynamic system which will be required by the bus/device
> > > code, we will need to eliminate ALL static datat that depends upon
> > > Ndevice to size itself.
> > > 
> > > There are two ways that we can fix this problem.  The first (and
> > > technically the best) is to be extend many of the calling functions
> > > to pass around a void * pointer that will point to that devices
> > > resources.  Though this is technically best, it will require that
> > > most major parts of the kernel be significantly changes.
> > > 
> > > The second solution is to continue to use the major/minor code scheme,
> > > but use a binary tree or a B-tree to obtain the private data.  This
> > > can cause a performance impact if we use if for things like the sio,
> > > but this can be fixed by changing the interrupt interface.
> > 
> > > I think that we should go with the second solution as it will be
> > > initalially easier to do.  I have B-tree code already writen, (I was
> > > writing it for another use in my bus/device code) which we could use
> > > to access this information.  (Some people will say, why not linked
> > > lists, and then I will say, sio, I have 12 ports on my term server,
> > > plus you get better data density)
> > 
> > I guess the question is, do you want a `quick hack' or a real solution to
> > fix and addres the problem ?
> > 
> > How many hours did you spend on the B-Tree stuff and how many do you
> > expect it would take to do it the other way ?
> 
> the B-tree code is generic, I wasn't writing it to solve the above
> problem, just so that I would have the code in my archives for use
> when I need it.. :)  so, time taken to write the B-Tree code shouldn't
> be counted in the equation...
> 
> the reason I say the second solution is that it MIGHT take a person
> two hours for the largest device to convert from the current table of
> static data to dynamic...
[....]
> if you do the second method, 90% of the work you do in that step will
> be able to be reused for when you finally make the step to the first
> method...  so, it's more along the lines of, lets get the system into
> a state that I can continue to do my work, and then when I or someone
> else has time, finish the job.  In the short term, getting the bus/device
> code is a greater benifit then the minor loss of this "hack" to get it
> working.

Hmmm.  So how exactly does the B-tree solve the problem ?  You're allocating
the dynamic data and storing it on the B-Tree and then have to look it up by
searching the B-tree ?  Aren't there better ways of allocating data and then
looking up where it is (what about asking the driver itself) ?

Why isn't it ok to just free/allocate and the memory when it is (un)loaded ?

If, I load a device like BPF and tell it I want "NBPF" to be 4, then what
else besides the BPF driver needs to know that NBPF is 4 ?  (I hope I've
picked a very simple case :).  What else cares about those buffers ?

> Reminds me of my social science teacher in high school.  She said,
> most people think that the cost of college is just that of the tuition
> you pay, but you have to also figure in the loss of not being able to
> use your time to work.

*groan* no kidding.  Going to conferences, as a contractor is *very*
expensive.

> > "Do it once and do it right."
> 
> "If you have time to do it right, do it right, else get it working." :)

Touche!

From owner-freebsd-hackers  Thu Dec 18 05:39:13 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA18569
          for hackers-outgoing; Thu, 18 Dec 1997 05:39:13 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 FAA18559
          for ; Thu, 18 Dec 1997 05:39:05 -0800 (PST)
          (envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id FAA09421;
          Thu, 18 Dec 1997 05:38:40 -0800 (PST)
Message-ID: <19971218053840.15389@hydrogen.nike.efn.org>
Date: Thu, 18 Dec 1997 05:38:40 -0800
From: John-Mark Gurney 
To: Darren Reed 
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory...
References: <19971218044804.38303@hydrogen.nike.efn.org> <199712181323.FAA04229@resnet.uoregon.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199712181323.FAA04229@resnet.uoregon.edu>; from Darren Reed on Fri, Dec 19, 1997 at 12:23:04AM +1100
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

Darren Reed scribbled this message on Dec 19:
> In some mail from John-Mark Gurney, sie said:
> > 
> > Darren Reed scribbled this message on Dec 18:
> > > In some mail from John-Mark Gurney, sie said:
> > > > well...  one of the things that will need to be done in preperation
> > > > for moving to a dynamic system which will be required by the bus/device
> > > > code, we will need to eliminate ALL static datat that depends upon
> > > > Ndevice to size itself.
> > > > 
> > > > There are two ways that we can fix this problem.  The first (and
> > > > technically the best) is to be extend many of the calling functions
> > > > to pass around a void * pointer that will point to that devices
> > > > resources.  Though this is technically best, it will require that
> > > > most major parts of the kernel be significantly changes.
> > > > 
> > > > The second solution is to continue to use the major/minor code scheme,
> > > > but use a binary tree or a B-tree to obtain the private data.  This
> > > > can cause a performance impact if we use if for things like the sio,
> > > > but this can be fixed by changing the interrupt interface.
> > > 
> > > > I think that we should go with the second solution as it will be
> > > > initalially easier to do.  I have B-tree code already writen, (I was
> > > > writing it for another use in my bus/device code) which we could use
> > > > to access this information.  (Some people will say, why not linked
> > > > lists, and then I will say, sio, I have 12 ports on my term server,
> > > > plus you get better data density)
> > > 
> > > I guess the question is, do you want a `quick hack' or a real solution to
> > > fix and addres the problem ?
> > > 
> > > How many hours did you spend on the B-Tree stuff and how many do you
> > > expect it would take to do it the other way ?
> > 
> > the B-tree code is generic, I wasn't writing it to solve the above
> > problem, just so that I would have the code in my archives for use
> > when I need it.. :)  so, time taken to write the B-Tree code shouldn't
> > be counted in the equation...
> > 
> > the reason I say the second solution is that it MIGHT take a person
> > two hours for the largest device to convert from the current table of
> > static data to dynamic...
> [....]
> > if you do the second method, 90% of the work you do in that step will
> > be able to be reused for when you finally make the step to the first
> > method...  so, it's more along the lines of, lets get the system into
> > a state that I can continue to do my work, and then when I or someone
> > else has time, finish the job.  In the short term, getting the bus/device
> > code is a greater benifit then the minor loss of this "hack" to get it
> > working.
> 
> Hmmm.  So how exactly does the B-tree solve the problem ?  You're allocating
> the dynamic data and storing it on the B-Tree and then have to look it up by
> searching the B-tree ?  Aren't there better ways of allocating data and then
> looking up where it is (what about asking the driver itself) ?

correct.. this is EXACTLY what the code does.. the problem is that
right now the data is stored in a static table,  because of this, you
can't just say, hey, I need another instance of you to attach to this
card...   we could even go with a small array of pointers that gets
realloced/resized each time a driver gets attached...  (which might be
better, I happen to have just finished testing the btree code, so that
influenced my choice.. :) )..

> Why isn't it ok to just free/allocate and the memory when it is (un)loaded ?

well, the problem is mapping the major/minor number that the kernel
gives you to the proper private data structs...

> If, I load a device like BPF and tell it I want "NBPF" to be 4, then what
> else besides the BPF driver needs to know that NBPF is 4 ?  (I hope I've
> picked a very simple case :).  What else cares about those buffers ?

nothing else cares about those buffers, but the problem is:
static struct bpf_d     bpf_dtab[NBPFILTER];
and
        d = &bpf_dtab[minor(dev)];

how do you dynamicly add another bpf device if you have static data
that is required?  (say you only compiled four, but need just one more)..

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking					  P.O. Box 5693, 97405

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-hackers  Thu Dec 18 05:41:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA18766
          for hackers-outgoing; Thu, 18 Dec 1997 05:41:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp8.portal.net.au [202.12.71.108])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA18759
          for ; Thu, 18 Dec 1997 05:40:56 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id AAA00353;
	Fri, 19 Dec 1997 00:05:19 +1030 (CST)
Message-Id: <199712181335.AAA00353@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: John-Mark Gurney 
cc: FreeBSD Hackers 
Subject: Re: converting drivers to dynamic memory... 
In-reply-to: Your message of "Thu, 18 Dec 1997 03:50:32 -0800."
             <19971218035032.46460@hydrogen.nike.efn.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Dec 1997 00:05:18 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> well...  one of the things that will need to be done in preperation
> for moving to a dynamic system which will be required by the bus/device
> code, we will need to eliminate ALL static datat that depends upon
> Ndevice to size itself.

This is traditionally the softc array (or pointer array), and not much 
else.

> There are two ways that we can fix this problem.  The first (and
> technically the best) is to be extend many of the calling functions
> to pass around a void * pointer that will point to that devices
> resources.  Though this is technically best, it will require that
> most major parts of the kernel be significantly changes.
>
> The second solution is to continue to use the major/minor code scheme,
> but use a binary tree or a B-tree to obtain the private data.  This
> can cause a performance impact if we use if for things like the sio,
> but this can be fixed by changing the interrupt interface.
>
> I think that we should go with the second solution as it will be

I do not.  And you have missed the most obvious (and most widely 
discussed) solution, which various people are already working on.

Understand that when DEVFS hits us properly (and all that's holding it 
up now are buggy consumers), dev_t will cease to be what it currently 
is.  The dev_t argument is present everywhere that you want to 
reference your device softc.

So, when you create your DEVFS node, one of the objects you pass in 
will be stored in the device token that's passed back on all your 
devices references.  In the normal case, this will be a pointer to your 
softc, which you can retrieve in the normal fashion.

There will be no major/minor numbers soon.

mike
"Real hackers run -current with DEVFS and SLICE on their laptops"


From owner-freebsd-hackers  Thu Dec 18 06:03:40 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA20021
          for hackers-outgoing; Thu, 18 Dec 1997 06:03:40 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from crocus.gamma.ru (crocus.gamma.ru [193.124.255.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA19999
          for ; Thu, 18 Dec 1997 06:03:27 -0800 (PST)
          (envelope-from ivt@crocus.gamma.ru)
Received: (from ivt@localhost) by crocus.gamma.ru (8.8.5/8.7.3) id RAA00517; Thu, 18 Dec 1997 17:01:15 +0300 (MSK)
Message-Id: <199712181401.RAA00517@crocus.gamma.ru>
Subject: Re: panic: blkfree: freeling free block/frag
In-Reply-To: <199712171842.LAA02077@usr02.primenet.com> from Terry Lambert at "Dec 17, 97 06:42:38 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Thu, 18 Dec 1997 17:01:15 +0300 (MSK)
Cc: mike@smith.net.au, sclawson@bottles.cs.utah.edu, ivt@gamma.ru,
        tlambert@primenet.com, freebsd-hackers@freebsd.org
From: "Igor Timkin" 
Organization: Gamma Ltd., Moscow, Russia
X-Class: Fast
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

Terry Lambert writes:
> I do not believe this is a single bit error.  I believe this is the same
> problem I have been seeing.
> 
> Does your ethernet hardware address begin with 00 00?

news.gamma.ru (158.250.39.26) at 0:0:c0:a4:2e:61
Is there a problem with 0:0 ?

From owner-freebsd-hackers  Thu Dec 18 06:22:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA21334
          for hackers-outgoing; Thu, 18 Dec 1997 06:22:51 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from crocus.gamma.ru (crocus.gamma.ru [193.124.255.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA21296
          for ; Thu, 18 Dec 1997 06:22:13 -0800 (PST)
          (envelope-from ivt@crocus.gamma.ru)
Received: (from ivt@localhost) by crocus.gamma.ru (8.8.5/8.7.3) id RAA00967; Thu, 18 Dec 1997 17:21:11 +0300 (MSK)
Message-Id: <199712181421.RAA00967@crocus.gamma.ru>
Subject: Re: panic: blkfree: freeling free block/frag
In-Reply-To: <199712161919.MAA20145@usr01.primenet.com> from Terry Lambert at "Dec 16, 97 07:19:15 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Thu, 18 Dec 1997 17:21:10 +0300 (MSK)
Cc: ivt@gamma.ru, tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG
From: "Igor Timkin" 
Organization: Gamma Ltd., Moscow, Russia
X-Class: Fast
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert writes:
> > #2  0xe0188c57 in ffs_blkfree (ip=0xe3e50500, bno=10, size=4096)
> >     at ../../ufs/ffs/ffs_alloc.c:1230
> > #3  0xe018b09a in ffs_indirtrunc (ip=0xe3e50500, lbn=-12, dbn=394248, 
> >     lastbn=-1, level=0, countp=0xdfbffd9c) at ../../ufs/ffs/ffs_inode.c:500
(kgdb) print *bp
$22 = {b_hash = {le_next = 0xe911197c, le_prev = 0xe01d8cd4}, b_vnbufs = {
    le_next = 0x0, le_prev = 0xe3b12830}, b_freelist = {tqe_next = 0xe927ce4c, 
    tqe_prev = 0xe01d93d8}, b_act = {tqe_next = 0xe9140970, 
    tqe_prev = 0xe3059f94}, b_proc = 0x0, b_flags = 1049104, b_qindex = 0, 
  b_usecount = 4 '\004', b_error = 0, b_bufsize = 4096, b_bcount = 4096, 
  b_resid = 0, b_dev = 5378, b_un = {
    b_addr = 0xea134000 "Path: Gamma.RU!srcc!newsfeed.sovam.com!sovam!news.maxwell.syr.edu!news-peer.sprintlink.net!news.sprintlink.net!Sprint!news-peer.gip.net!news.gsl.net!gip.net!spring.edu.tw!news.nctu.edu.tw!news.ntnu.ed"...}, 
  b_kvabase = 0xea134000 "Path: Gamma.RU!srcc!newsfeed.sovam.com!sovam!news.maxwell.syr.edu!news-peer.sprintlink.net!news.sprintlink.net!Sprint!news-peer.gip.net!news.gsl.net!gip.net!spring.edu.tw!news.nctu.edu.tw!news.ntnu.ed"..., 
  b_kvasize = 4096, b_saveaddr = 0x0, b_lblkno = -12, b_blkno = 394248, 
  b_iodone = 0, b_iodone_chain = 0x0, b_vp = 0xe3b12800, b_dirtyoff = 0, 
  b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_validoff = 0, 
  b_validend = 0, b_pblkno = 3187606, b_savekva = 0x0, b_driver1 = 0x0, 
  b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = {
      tqh_first = 0xe9154844, tqh_last = 0xe92698a0}, cluster_entry = {
      tqe_next = 0xe9154844, tqe_prev = 0xe92698a0}}, b_pages = {0xe07c98dc, 
    0x0 }, b_npages = 958773}

It's look like a bad indirect disk blocks data.
(kgdb) printf "%s",bp->b_un.b_addr
Path: Gamma.RU!srcc!newsfeed.sovam.com!sovam!news.maxwell.syr.edu!news-peer.sprintlink.net!news.sprintlink.net!Sprint!news-peer.gip.net!news.gsl.net!gip.net!spring.edu.tw!news.nctu.edu.tw!news.ntnu.edu.tw!elfBBS!bbs
From: hazn.bbs@bbs.ntnu.edu.tw („i¼¦Ŗŗ¤H¶Ā„Õ¤H„Ķ)
Newsgroups: tw.bbs.soc.taipei
Subject: ½Š°Ż¦³ØS¦³¤HŖ¾¹Dŗæ²śØČ³Ķ²śŗt°Ū·|?
Date: 12 Dec 1997 10:02:07 GMT
Organization: ®v¤j­p¤¤(ŗėĘF¤§«°)
Message-ID: <3M6Q8W$jCT@bbs.ntnu.edu.tw>
X-Filename: TaipeiLife/M.881920928.A
Lines: 7
Xref: Gamma.RU tw.bbs.soc.taipei:34040

           ¤£Ŗ¾¹D¦³ØS¦³¤HŖ¾¹D¦o³o¦ģ¤Ń¦Z¤°»ņ®É­Ō­nØÓ„xĘW¶}ŗt°Ū·|?
           ¦pŖG­n¶Rŗt°Ū·|Ŗŗ²¼”A¤£Ŗ¾­n„hØŗøĢ¶R?·Q„²¤@©wØS¦³¤HŖ¾¹D
           ”A„u©źµŪ¤@¤ł¤p¤pŖŗ§Ę±ę”C§Ę±ę¦³¦oŗq°gŖŗ¤H”AÆą“£ØѤ@¤U
           ®ų®§”AĮĀĮĀ...........

--
”° ØÓ·½: ®v¤jŗėĘF¤§«°  ”» From: 140.122.197.17

If I understand right, this buffer is 0 level inderect dick blocks
(b_blkno = 394248).


> > #4  0xe018aac8 in ffs_truncate (ap=0xdfbffe74) at ../../ufs/ffs/ffs_inode.c:317
> > #5  0xe018e6a5 in ufs_inactive (ap=0xdfbffea0) at vnode_if.h:1003
(kgdb) print *ip
$23 = {i_next = 0xe4461600, i_prev = 0xe3099690, i_vnode = 0xe3b12800, 
  i_devvp = 0xe3867380, i_flag = 8, i_dev = 5378, i_number = 12450, inode_u = {
    fs = 0xe3d8f800, lfs = 0xe3d8f800, e2fs = 0xe3d8f800}, i_dquot = {0x0, 
    0x0}, i_modrev = 0x3495787e51e6cc01, i_lockf = 0x0, i_lockholder = 0, 
  i_lockwaiter = 0, i_count = 0, i_endoff = 0, i_diroff = 0, i_offset = 0, 
  i_ino = 0, i_reclen = 0, i_lockcount = 0, i_spare = {0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0}, i_din = {di_mode = 33188, di_nlink = 0, di_u = {oldids = {0, 0}, 
      inumber = 0}, di_size = 71262, di_atime = {tv_sec = 881773802, 
      tv_nsec = 0}, di_mtime = {tv_sec = 882210955, tv_nsec = 0}, di_ctime = {
      tv_sec = 882210955, tv_nsec = 0}, di_db = {224656, 224664, 224672, 
      224680, 224688, 224696, 224704, 224712, 224720, 224728, 224736, 224744}, 
    di_ib = {394248, 0, 0}, di_flags = 0, di_blocks = 152, 
             ^^^^^^
    di_gen = 1403844452, di_uid = 8, di_gid = 8, di_spare = {0, 0}}}

> Start at unlink, and look at the arguments all the way down to see
> if they are reasonable.

and
tail -1000 /usr/local/news/crash/vmcore.1 | strings
[...]
<3>pid 585 (fastrm), uid 8 on /var/spool/news: bad block
bad block 537543585, ino 12450
<3>pid 585 (fastrm), uid 8 on /var/spool/news: bad block
bad block -1581822542, ino 12450
<3>pid 585 (fastrm), uid 8 on /var/spool/news: bad block
bad block -71795529, ino 12450
<3>pid 585 (fastrm), uid 8 on /var/spool/news: bad block
dev = 0x1502, block = 10, fs = /var/spool/news
panic: blkfree: freeing free block
syncing disks... 291 290 261 212 149 66 12 3 3 3 3 3 3 3 3 3 3 3 3 3 giving up

I run fastrm via `idprio 10'. May be this error - synchronyzation error ?
innd is run as normal proccess.

From owner-freebsd-hackers  Thu Dec 18 06:32:03 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA22045
          for hackers-outgoing; Thu, 18 Dec 1997 06:32:03 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA22000
          for ; Thu, 18 Dec 1997 06:31:57 -0800 (PST)
          (envelope-from avalon@coombs.anu.edu.au)
Message-Id: <199712181431.GAA22000@hub.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA247585503; Fri, 19 Dec 1997 01:31:43 +1100
From: Darren Reed 
Subject: Re: converting drivers to dynamic memory...
To: gurney_j@resnet.uoregon.edu
Date: Fri, 19 Dec 1997 01:31:43 +1100 (EDT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <19971218053840.15389@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 18, 97 05:38:40 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from John-Mark Gurney, sie said:
> 
> > Hmmm.  So how exactly does the B-tree solve the problem ?  You're
> > allocating
> > the dynamic data and storing it on the B-Tree and then have to look
> > it up by
> > searching the B-tree ?  Aren't there better ways of allocating data
> > and then
> > looking up where it is (what about asking the driver itself) ?
> 
> correct.. this is EXACTLY what the code does.. the problem is that
> right now the data is stored in a static table,  because of this, you
> can't just say, hey, I need another instance of you to attach to this
> card...   we could even go with a small array of pointers that gets
> realloced/resized each time a driver gets attached...  (which might be
> better, I happen to have just finished testing the btree code, so that
> influenced my choice.. :) )..

Now I've got more clues so I can understand where you're going with all
of this :)

Well, FWIW, Solaris2 does the "extra pointer" thing in its DDI :)

However, if you are using multiple instances, you do need to keep track
of which is which (guess you could use B-Trees for this :) yourself.

Their function call interface consists of over 120 functions which support
using the extra pointer (they call their void * type dev_info_t).

Hmmm, on second thoughts maybe instead of option 1 and option 2, option 2
should be phase 1 and option 1 should be phase 2 ? :-)

Darren

From owner-freebsd-hackers  Thu Dec 18 06:36:41 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA22373
          for hackers-outgoing; Thu, 18 Dec 1997 06:36:41 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 GAA22362
          for ; Thu, 18 Dec 1997 06:36:33 -0800 (PST)
          (envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id GAA09652;
          Thu, 18 Dec 1997 06:36:06 -0800 (PST)
Message-ID: <19971218063606.31535@hydrogen.nike.efn.org>
Date: Thu, 18 Dec 1997 06:36:06 -0800
From: John-Mark Gurney 
To: Mike Smith 
Cc: FreeBSD Hackers 
Subject: Re: converting drivers to dynamic memory...
References: <19971218035032.46460@hydrogen.nike.efn.org> <199712181335.AAA00353@word.smith.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199712181335.AAA00353@word.smith.net.au>; from Mike Smith on Fri, Dec 19, 1997 at 12:05:18AM +1030
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

Mike Smith scribbled this message on Dec 19:
> > well...  one of the things that will need to be done in preperation
> > for moving to a dynamic system which will be required by the bus/device
> > code, we will need to eliminate ALL static datat that depends upon
> > Ndevice to size itself.
> 
> This is traditionally the softc array (or pointer array), and not much 
> else.

yes, but a few has multiple arrays (sio has two)...

> > There are two ways that we can fix this problem.  The first (and
> > technically the best) is to be extend many of the calling functions
> > to pass around a void * pointer that will point to that devices
> > resources.  Though this is technically best, it will require that
> > most major parts of the kernel be significantly changes.
> >
> > The second solution is to continue to use the major/minor code scheme,
> > but use a binary tree or a B-tree to obtain the private data.  This
> > can cause a performance impact if we use if for things like the sio,
> > but this can be fixed by changing the interrupt interface.
> >
> > I think that we should go with the second solution as it will be
> 
> I do not.  And you have missed the most obvious (and most widely 
> discussed) solution, which various people are already working on.

so, your saying that the rest of the frame would already exists, it
just needs to be fixed?

> Understand that when DEVFS hits us properly (and all that's holding it 
> up now are buggy consumers), dev_t will cease to be what it currently 
> is.  The dev_t argument is present everywhere that you want to 
> reference your device softc.

ok, if this is the case, can you tell me where this is currently??
I just looked at sio's devfs_add_devswf...  the closest thing was
the passing of it's unit number in, but then it gets or'd with the
flag of what that entry does... PLUS, that "minor" number gets merged
with the major number, so you won't be able to store a void * in there...

so, two questions, where does devfs does this magic pointer?  and how
will it co-exist with passing back the type of device that was opened?

> So, when you create your DEVFS node, one of the objects you pass in 
> will be stored in the device token that's passed back on all your 
> devices references.  In the normal case, this will be a pointer to your 
> softc, which you can retrieve in the normal fashion.
> 
> There will be no major/minor numbers soon.

so, how long till this happens??  is this going to be completed in the
next few months?

the reason I ask is that once the bus/device code is writen, I'm going
to have to pretty much rewrite ALL of the device drivers for the new
scheme, and I don't want to do more than I have to... changing how a
function is called is a LOT more work than just changing the internals
of a function...

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking					  P.O. Box 5693, 97405

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-hackers  Thu Dec 18 06:52:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA23447
          for hackers-outgoing; Thu, 18 Dec 1997 06:52:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 GAA23427
          for ; Thu, 18 Dec 1997 06:51:55 -0800 (PST)
          (envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id GAA09688;
          Thu, 18 Dec 1997 06:51:08 -0800 (PST)
Message-ID: <19971218065107.10999@hydrogen.nike.efn.org>
Date: Thu, 18 Dec 1997 06:51:07 -0800
From: John-Mark Gurney 
To: Darren Reed 
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory...
References: <19971218053840.15389@hydrogen.nike.efn.org> <199712181431.GAA14258@resnet.uoregon.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199712181431.GAA14258@resnet.uoregon.edu>; from Darren Reed on Fri, Dec 19, 1997 at 01:31:43AM +1100
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

Darren Reed scribbled this message on Dec 19:
> In some mail from John-Mark Gurney, sie said:
> > 
> > > Hmmm.  So how exactly does the B-tree solve the problem ?  You're
> > > allocating
> > > the dynamic data and storing it on the B-Tree and then have to look
> > > it up by
> > > searching the B-tree ?  Aren't there better ways of allocating data
> > > and then
> > > looking up where it is (what about asking the driver itself) ?
> > 
> > correct.. this is EXACTLY what the code does.. the problem is that
> > right now the data is stored in a static table,  because of this, you
> > can't just say, hey, I need another instance of you to attach to this
> > card...   we could even go with a small array of pointers that gets
> > realloced/resized each time a driver gets attached...  (which might be
> > better, I happen to have just finished testing the btree code, so that
> > influenced my choice.. :) )..
> 
> Now I've got more clues so I can understand where you're going with all
> of this :)
> 
> Well, FWIW, Solaris2 does the "extra pointer" thing in its DDI :)
> 
> However, if you are using multiple instances, you do need to keep track
> of which is which (guess you could use B-Trees for this :) yourself.
> 
> Their function call interface consists of over 120 functions which support
> using the extra pointer (they call their void * type dev_info_t).

yep, I think that would be a great addition...  IMO, once devfs has
finally been completed, we will still need a minor number of the void *
(I happen to like the name dev_info_t), the minor so that we know what
part of the device driver we are accessing...  else we would need to
allocate a bunch of small structs like:
struct {
	int option;
	struct devicedata data;
}

which would be really wasteful of precious memory resources...

> Hmmm, on second thoughts maybe instead of option 1 and option 2, option 2
> should be phase 1 and option 1 should be phase 2 ? :-)

I completely agree...  I'll probably end up doing phase 1 of the project
myself, unless there are others who are willing to do the work.. and
if there are, I'll put together the frame work neccessary (basicly,
fix up the btree code, and do a driver as an example)...

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking					  P.O. Box 5693, 97405

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-hackers  Thu Dec 18 07:18:56 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA24986
          for hackers-outgoing; Thu, 18 Dec 1997 07:18:56 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from mail.aerotek.com ([204.176.123.139])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA24974
          for ; Thu, 18 Dec 1997 07:18:34 -0800 (PST)
          (envelope-from mharris@aerotek.com)
From: mharris@aerotek.com
Received: from WHIT-SA-1007695 ([10.2.193.158]) by mail.aerotek.com
          (Netscape Messaging Server 3.01)  with SMTP id AAA835
          for ;
          Thu, 18 Dec 1997 10:17:57 -0500
Message-ID: <34993EEE.1247@aerotek.com>
Date: Thu, 18 Dec 1997 10:19:10 -0500
Reply-To: mharris@aerotek.com
Organization: Aerotek, Inc.
X-Mailer: Mozilla 3.0 (WinNT; I)
MIME-Version: 1.0
To: freebsd-hackers@freefall.FreeBSD.org
Subject: help
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Fdear sir

From owner-freebsd-hackers  Thu Dec 18 07:27:58 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA25555
          for hackers-outgoing; Thu, 18 Dec 1997 07:27:58 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from gatekeeper.ray.com (gatekeeper.ray.com [138.125.162.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA25540
          for ; Thu, 18 Dec 1997 07:27:51 -0800 (PST)
          (envelope-from moncrg@bt340707.res.ray.com)
Received: (mailer@localhost) by gatekeeper.ray.com (8.8.7/8.8.7) id KAA21967 for ; Thu, 18 Dec 1997 10:27:45 -0500
Received: from bt340707.res.ray.com/138.125.142.35()
	by gatekeeper.ray.com
	id sma.882457971.015695; Thu Dec 18 10:12:51 1997
Received: (from moncrg@localhost)
	by bt340707.res.ray.com (8.8.7/8.8.7) id KAA05628;
	Thu, 18 Dec 1997 10:08:28 -0500 (EST)
	(envelope-from moncrg)
Date: Thu, 18 Dec 1997 10:08:28 -0500 (EST)
Message-Id: <199712181508.KAA05628@bt340707.res.ray.com>
From: "Gregory D. Moncreaff" 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: freebsd-hackers@FreeBSD.ORG
Subject: sockaddr <-> sockaddr_* conversion macros
X-Mailer: VM 6.31 under 20.2 XEmacs Lucid
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

it seems that these keep being created over
and over in different source and header files...
as well as the tons of (struct sockaddr.... ) casts

[look for satosin, sintosa, in netinet for example

why not "standardize" them:

sys/socket.h: #define SA ((struct sockaddr *)s) 
netinet/in.h: #define SIN ((struct sockaddr_in *)s)
netatalk/at.h: #define SAT ((struct sockaddr_at *)s)
etc...

the define of SA is of general user utility especially
with any level of prototype warnings enabled....


From owner-freebsd-hackers  Thu Dec 18 08:08:01 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA28348
          for hackers-outgoing; Thu, 18 Dec 1997 08:08:01 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from roguetrader.com (cold.org [206.81.134.103])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA28080
          for ; Thu, 18 Dec 1997 08:02:51 -0800 (PST)
          (envelope-from brandon@roguetrader.com)
Received: from localhost (brandon@localhost)
	by roguetrader.com (8.8.5/8.8.5) with SMTP id JAA05360
	for ; Thu, 18 Dec 1997 09:02:53 -0700 (MST)
Date: Thu, 18 Dec 1997 09:02:52 -0700 (MST)
From: Brandon Gillespie 
To: freebsd-hackers@freebsd.org
Subject: Increasing maximum file descriptors (for max sockets)
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 server running that needs several hundred connections.  Just now
we ran into a problem (at the time we had 200+ conns to the server in
question) and the whole box froze (current version is 2.2.2-R).  logs:

Dec 17 14:20:24 ice syslogd: /var/run/utmp: Too many open files in system
Dec 17 14:20:24 ice /kernel: file: table is full 
Dec 17 14:20:24 ice last message repeated 96 times

And so on.  On first glimpse through the kernel config file I can't seem
to find anything to increase the amount of file descriptors.  Where is
this done?  I cannot find anything about it in the docs...

-Brandon



From owner-freebsd-hackers  Thu Dec 18 09:08:31 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA03699
          for hackers-outgoing; Thu, 18 Dec 1997 09:08:31 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from echonyc.com (echonyc.com [198.67.15.2])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA03667
          for ; Thu, 18 Dec 1997 09:08:23 -0800 (PST)
          (envelope-from benedict@echonyc.com)
Received: from localhost (benedict@localhost)
	by echonyc.com (8.8.7/8.8.7) with SMTP id MAA28908;
	Thu, 18 Dec 1997 12:08:12 -0500 (EST)
Date: Thu, 18 Dec 1997 12:08:12 -0500 (EST)
From: Snob Art Genre 
To: muthu olagappan 
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Volunteer for coding
In-Reply-To: <19971218062123.24293.qmail@hotmail.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

Take a look at http://www.freebsd.org/handbook/handbook242.html#contrib.

On Wed, 17 Dec 1997, muthu olagappan wrote:

> Hi,
> 
> 
>     Iam interested in  doing coding for freebsd. I have read the 
> internals of freebsd. Please do respond to this mail.
> 
> 
> With regards,
> Muthu.o.L.
> 
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
> 



 Ben

"You have your mind on computers, it seems." 


From owner-freebsd-hackers  Thu Dec 18 11:30:19 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA15655
          for hackers-outgoing; Thu, 18 Dec 1997 11:30:19 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15636
          for ; Thu, 18 Dec 1997 11:30:03 -0800 (PST)
          (envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.8/8.8.8) id MAA06766;
	Thu, 18 Dec 1997 12:29:59 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
 via SMTP by smtp04.primenet.com, id smtpd006752; Thu Dec 18 12:29:53 1997
Received: (from tlambert@localhost)
	by usr05.primenet.com (8.8.5/8.8.5) id MAA11029;
	Thu, 18 Dec 1997 12:29:51 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712181929.MAA11029@usr05.primenet.com>
Subject: Re: converting drivers to dynamic memory...
To: gurney_j@resnet.uoregon.edu
Date: Thu, 18 Dec 1997 19:29:51 +0000 (GMT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <19971218035032.46460@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 18, 97 03:50:32 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> There are two ways that we can fix this problem.  The first (and
> technically the best) is to be extend many of the calling functions
> to pass around a void * pointer that will point to that devices
> resources.  Though this is technically best, it will require that
> most major parts of the kernel be significantly changes.
> 
> The second solution is to continue to use the major/minor code scheme,
> but use a binary tree or a B-tree to obtain the private data.  This
> can cause a performance impact if we use if for things like the sio,
> but this can be fixed by changing the interrupt interface.
> 
> I think that we should go with the second solution as it will be
> initalially easier to do.  I have B-tree code already writen, (I was
> writing it for another use in my bus/device code) which we could use
> to access this information.  (Some people will say, why not linked
> lists, and then I will say, sio, I have 12 ports on my term server,
> plus you get better data density)

I think this will be a problem, since Julian intends to make majors and
minors "go away".  This is a very good thing, but it will require you
use your first apprach.

I don't think the change should be all that difficult.  The main issue
is how to convert one driver at a time.  I think this can be done with
common glue code on top to make them look like the old drivers for the
near term.


> On another note, how do people feel about more complex data structures
> becoming standard parts of the kernel.  I think there are a number of
> places that using a more complex data structure would be a big win.
> I have code for both Fibonacci Heaps and B-tree's that just need some
> cleaning up to be generally useful.  The code bloat would actually be
> quite small.  The Fib heap code is under 3k, and the B-tree code is
> 4736 bytes, but this includes some debuging code (printing tree and
> checking that the tree is in order).

I would like to see the Fibonacci code in there... the B-tree code, I
don't know; is there a plan to convert the routing code?  8-) 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  Thu Dec 18 11:32:11 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA15865
          for hackers-outgoing; Thu, 18 Dec 1997 11:32:11 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15860
          for ; Thu, 18 Dec 1997 11:32:05 -0800 (PST)
          (envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
	by smtp02.primenet.com (8.8.8/8.8.8) id MAA12269;
	Thu, 18 Dec 1997 12:31:59 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
 via SMTP by smtp02.primenet.com, id smtpd012250; Thu Dec 18 12:31:57 1997
Received: (from tlambert@localhost)
	by usr05.primenet.com (8.8.5/8.8.5) id MAA11145;
	Thu, 18 Dec 1997 12:31:54 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712181931.MAA11145@usr05.primenet.com>
Subject: Re: converting drivers to dynamic memory...
To: gurney_j@resnet.uoregon.edu
Date: Thu, 18 Dec 1997 19:31:54 +0000 (GMT)
Cc: avalon@coombs.anu.edu.au, freebsd-hackers@freebsd.org
In-Reply-To: <19971218044804.38303@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 18, 97 04:48:04 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > "Do it once and do it right."
> 
> "If you have time to do it right, do it right, else get it working." :)

...And then do it all over again later.


					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 Dec 18 12:07:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA18312
          for hackers-outgoing; Thu, 18 Dec 1997 12:07:04 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 MAA18285
          for ; Thu, 18 Dec 1997 12:06:51 -0800 (PST)
          (envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA09263
  (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Thu, 18 Dec 1997 21:07:00 +0100
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA13146; Thu, 18 Dec 1997 19:11:15 +0100 (MET)
From: Wilko Bulte 
Message-Id: <199712181811.TAA13146@yedi.iaf.nl>
Subject: Re: volume control on SCSI Toshiba CDdrive
To: syssgm@dtir.qld.gov.au (Stephen McKay)
Date: Thu, 18 Dec 1997 19:11:15 +0100 (MET)
Cc: freebsd-hackers@FreeBSD.ORG, syssgm@dtir.qld.gov.au
In-Reply-To: <199712181226.WAA03180@troll.dtir.qld.gov.au> from "Stephen McKay" at Dec 18, 97 10:26:48 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 Stephen McKay wrote...
> 
> On Wednesday, 17th December 1997, Wilko Bulte wrote:
> 
> >Well it took some time, but I haven't given up:
> >
> >TOSHIBA CD-ROM XM-5701TA 0557
> >
> >is a firmware rev that has *working* audio control...
> 
> This is good news!  But how do we know it's *only* the firmware that is
> different?  Maybe it's new firmware that just happens to be present on a

Well, I'm going to try to copy the eprom and put the copy in my own drive.
This will prove whether it's hardware or firmware (I hope...)

Have to find a SMD capable programmer and a SMD EPROM first...

> working hardware revision.  Still, I can hope.
> 
> >As far as getting in touch with a contact in Toshiba I did not have as much
> >luck. 
> 
> Sigh.  I know nobody with such contacts.  But I'll hassle everyone that I
> think might know someone who knows someone!

Great. I'll report back to the list as soon as I have tested the new ROM.

Wilko
_     ______________________________________________________________________
 |   / o / /  _  Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko
 |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
----------------  Support your local daemons: run [Free,Net]BSD Unix  ------

From owner-freebsd-hackers  Thu Dec 18 12:08:54 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA18539
          for hackers-outgoing; Thu, 18 Dec 1997 12:08:54 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18519
          for ; Thu, 18 Dec 1997 12:08:46 -0800 (PST)
          (envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
	by smtp02.primenet.com (8.8.8/8.8.8) id NAA20835;
	Thu, 18 Dec 1997 13:08:45 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
 via SMTP by smtp02.primenet.com, id smtpd020815; Thu Dec 18 13:08:41 1997
Received: (from tlambert@localhost)
	by usr05.primenet.com (8.8.5/8.8.5) id NAA13665;
	Thu, 18 Dec 1997 13:08:40 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712182008.NAA13665@usr05.primenet.com>
Subject: Re: converting drivers to dynamic memory...
To: avalon@coombs.anu.edu.au (Darren Reed)
Date: Thu, 18 Dec 1997 20:08:39 +0000 (GMT)
Cc: gurney_j@resnet.uoregon.edu, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199712181327.FAA17836@hub.freebsd.org> from "Darren Reed" at Dec 19, 97 00:23:04 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Why isn't it ok to just free/allocate and the memory when it is (un)loaded ?
> 
> If, I load a device like BPF and tell it I want "NBPF" to be 4, then what
> else besides the BPF driver needs to know that NBPF is 4 ?  (I hope I've
> picked a very simple case :).  What else cares about those buffers ?

There's a fundamental flaw here: that 4 should be anything other than
a soft limit.

The BPF is one of those devices, like pty's or the tun or vn devices,
that is best modelled with a cloning interface.


Initially, I would think you would do something like:

static void *contexts[ NBPFILTER];

fake_bpf_device_op( minor, ...)
{
	return real_bpf_device_op( contexts[ minor], ...);
}

This should make the transition relatively painless.

There would probably need to be a new function for instancing in
the bpf_cdevsw entry, which would be called to instance into the
static contexts value appropriate for the device being referenced,
and a reflexive one for destroying those same contexts.

But this would let you change one device at a time fairly trivially,
and, assuming a recompile an placement of the create/delet at the
end of the struct cdevsw, the values would default to NULL for all
unconverted devices.


					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 Dec 18 12:14:27 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA19076
          for hackers-outgoing; Thu, 18 Dec 1997 12:14:27 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18844
          for ; Thu, 18 Dec 1997 12:11:43 -0800 (PST)
          (envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id NAA21146;
	Thu, 18 Dec 1997 13:11:26 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
 via SMTP by smtp03.primenet.com, id smtpd021114; Thu Dec 18 13:11:19 1997
Received: (from tlambert@localhost)
	by usr05.primenet.com (8.8.5/8.8.5) id NAA13788;
	Thu, 18 Dec 1997 13:11:14 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712182011.NAA13788@usr05.primenet.com>
Subject: Re: panic: blkfree: freeling free block/frag
To: ivt@gamma.ru (Igor Timkin)
Date: Thu, 18 Dec 1997 20:11:14 +0000 (GMT)
Cc: tlambert@primenet.com, mike@smith.net.au, sclawson@bottles.cs.utah.edu,
        ivt@gamma.ru, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199712181401.RAA00517@crocus.gamma.ru> from "Igor Timkin" at Dec 18, 97 05:01:15 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Terry Lambert writes:
> > I do not believe this is a single bit error.  I believe this is the same
> > problem I have been seeing.
> > 
> > Does your ethernet hardware address begin with 00 00?
> 
> news.gamma.ru (158.250.39.26) at 0:0:c0:a4:2e:61
> Is there a problem with 0:0 ?

Look at your corrupt variables and nearby variables in the stack, and
see if your ethernet address is being blown onto the stack somewhere.

There is no problem with the 0:0, but it reinforces my feeling that
this could be resulting from a trashed kernel 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  Thu Dec 18 13:44:48 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA24913
          for hackers-outgoing; Thu, 18 Dec 1997 13:44:48 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from thunderdome.plutotech.com (root@thunderdome.plutotech.com [206.168.67.122])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24906
          for ; Thu, 18 Dec 1997 13:44:39 -0800 (PST)
          (envelope-from ken@panzer.plutotech.com)
Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125])
          by thunderdome.plutotech.com (8.8.7/8.8.5) with ESMTP id OAA22567;
          Thu, 18 Dec 1997 14:44:34 -0700 (MST)
Received: (from ken@localhost)
          by panzer.plutotech.com (8.8.8/8.8.5) id OAA27429;
          Thu, 18 Dec 1997 14:44:30 -0700 (MST)
Message-Id: <199712182144.OAA27429@panzer.plutotech.com>
Subject: Re: panic: blkfree: freeling free block/frag
In-Reply-To: <199712182011.NAA13788@usr05.primenet.com> from Terry Lambert at "Dec 18, 97 08:11:14 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Thu, 18 Dec 1997 14:44:30 -0700 (MST)
Cc: ivt@gamma.ru, tlambert@primenet.com, mike@smith.net.au,
        sclawson@bottles.cs.utah.edu, freebsd-hackers@FreeBSD.ORG
From: Kenneth Merry 
X-Mailer: ELM [version 2.4ME+ PL28s (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert wrote...
> > Terry Lambert writes:
> > > I do not believe this is a single bit error.  I believe this is the same
> > > problem I have been seeing.
> > > 
> > > Does your ethernet hardware address begin with 00 00?
> > 
> > news.gamma.ru (158.250.39.26) at 0:0:c0:a4:2e:61
> > Is there a problem with 0:0 ?
> 
> Look at your corrupt variables and nearby variables in the stack, and
> see if your ethernet address is being blown onto the stack somewhere.
> 
> There is no problem with the 0:0, but it reinforces my feeling that
> this could be resulting from a trashed kernel stack.

	I doubt that his ethernet address indicates any problems.  00:00:c0
is an SMC ethernet address prefix.  I've got two SMC 10/100 cards in one of
my systems, and a SMC Elite Ultra 16 (or something to that effect) in
another system, and all of the ethernet addresses begin with 00:00:c0.

Ken
-- 
Kenneth Merry
ken@plutotech.com

From owner-freebsd-hackers  Thu Dec 18 14:39:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA28926
          for hackers-outgoing; Thu, 18 Dec 1997 14:39:55 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from tyger.inna.net (root@tyger.inna.net [209.48.124.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28901
          for ; Thu, 18 Dec 1997 14:39:40 -0800 (PST)
          (envelope-from tom@tyger.inna.net)
Received: (from tom@localhost)
	by tyger.inna.net (8.8.8/8.8.8) id RAA03455;
	Thu, 18 Dec 1997 17:39:34 -0500 (EST)
Message-ID: <19971218173934.01968@tyger.inna.net>
Date: Thu, 18 Dec 1997 17:39:34 -0500
From: GothGeek Sysadmin 
To: Andrzej Bialecki 
Cc: hackers@freebsd.org
Subject: Re: atapi.c || wierd hardware
Reply-To: tom@inna.net
References: <19971216.233119.5295.1.wakkym@juno.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: ; from Andrzej Bialecki on Wed, Dec 17, 1997 at 11:32:18AM +0100
Organization: TBI, Ltd
X-Operating-System: FreeBSD 2.1.0-RELEASE
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


> I conclude from this that vendors often have peculiar understanding of
> "standards"...

The best thing about Standards is there are so many to choose from.

-- 
 ------------------------------------------------------------------------
 - Tom Arnold -       And Lycius' arms were empty of delight,           - 
 - SysAdmin   -       As were his limbs of life, from that same night.  -
 - TBI, Ltd   -       On the high couch he lay!--his friends came round-- 
 -------------------- Supported him--no pulse, or breath they found,    -
 - Keats, Lamia II :  And, in its marriage robe, the heavy body wound.  -

From owner-freebsd-hackers  Thu Dec 18 14:42:29 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA29237
          for hackers-outgoing; Thu, 18 Dec 1997 14:42:29 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp3.portal.net.au [202.12.71.103])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28618
          for ; Thu, 18 Dec 1997 14:35:44 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id JAA01661;
	Fri, 19 Dec 1997 09:00:03 +1030 (CST)
Message-Id: <199712182230.JAA01661@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: John-Mark Gurney 
cc: Darren Reed , freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory... 
In-reply-to: Your message of "Thu, 18 Dec 1997 06:51:07 -0800."
             <19971218065107.10999@hydrogen.nike.efn.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Dec 1997 09:00:02 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> yep, I think that would be a great addition...  IMO, once devfs has
> finally been completed, we will still need a minor number of the void *
> (I happen to like the name dev_info_t), the minor so that we know what
> part of the device driver we are accessing...  else we would need to
> allocate a bunch of small structs like:
> struct {
> 	int option;
> 	struct devicedata data;
> }
> 
> which would be really wasteful of precious memory resources...

No.  I take your point about wanting to have multiple DEVFS entries 
referencing a single softc structure though; you might want to have 
something like:

struct devfs_softc_reference
{
	void	*softc;
	int	token;
}

inside the devfs_node structure.

Forget the btree model; it's not going to fly in the face of a direct 
reference approach. 

mike


From owner-freebsd-hackers  Thu Dec 18 14:50:31 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA29719
          for hackers-outgoing; Thu, 18 Dec 1997 14:50:31 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 OAA29707
          for ; Thu, 18 Dec 1997 14:50:16 -0800 (PST)
          (envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id OAA11174;
          Thu, 18 Dec 1997 14:50:06 -0800 (PST)
Message-ID: <19971218145005.37073@hydrogen.nike.efn.org>
Date: Thu, 18 Dec 1997 14:50:05 -0800
From: John-Mark Gurney 
To: Mike Smith 
Cc: Darren Reed , freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory...
References: <19971218065107.10999@hydrogen.nike.efn.org> <199712182230.JAA01661@word.smith.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199712182230.JAA01661@word.smith.net.au>; from Mike Smith on Fri, Dec 19, 1997 at 09:00:02AM +1030
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

Mike Smith scribbled this message on Dec 19:
> > yep, I think that would be a great addition...  IMO, once devfs has
> > finally been completed, we will still need a minor number of the void *
> > (I happen to like the name dev_info_t), the minor so that we know what
> > part of the device driver we are accessing...  else we would need to
> > allocate a bunch of small structs like:
> > struct {
> > 	int option;
> > 	struct devicedata data;
> > }
> > 
> > which would be really wasteful of precious memory resources...
> 
> No.  I take your point about wanting to have multiple DEVFS entries 
> referencing a single softc structure though; you might want to have 
> something like:
> 
> struct devfs_softc_reference
> {
> 	void	*softc;
> 	int	token;
> }
> 
> inside the devfs_node structure.

yep, that's what I'd like...

> Forget the btree model; it's not going to fly in the face of a direct 
> reference approach. 

I will once devfs and the driver interface supports it...  but devfs and
the interface doesn't even support passing a token yet (well, it does if
you call minor number a token)... I just proposed a simple stop gap
meassure that would get the ball rolling..

when did I ever say that we should in the long run choose using a
btree over the "correct" way to do it??  I only said it would require
an interface change (which hasn't even started to happen, sure the
devfs code is in place, but actually USING it to pass tokens hasn't
even begun), which I stated, I wasn't going to do... but I proposed
using the btree method as a stepping stone to get to the final
destination...

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking					  P.O. Box 5693, 97405

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-hackers  Thu Dec 18 14:56:46 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA00245
          for hackers-outgoing; Thu, 18 Dec 1997 14:56:46 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29773
          for ; Thu, 18 Dec 1997 14:51:18 -0800 (PST)
          (envelope-from tlambert@usr01.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id PAA02707;
	Thu, 18 Dec 1997 15:51:16 -0700 (MST)
Received: from usr01.primenet.com(206.165.6.201)
 via SMTP by smtp03.primenet.com, id smtpd002686; Thu Dec 18 15:51:09 1997
Received: (from tlambert@localhost)
	by usr01.primenet.com (8.8.5/8.8.5) id PAA11470;
	Thu, 18 Dec 1997 15:51:09 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712182251.PAA11470@usr01.primenet.com>
Subject: Re: panic: blkfree: freeling free block/frag
To: ken@plutotech.com (Kenneth Merry)
Date: Thu, 18 Dec 1997 22:51:08 +0000 (GMT)
Cc: tlambert@primenet.com, ivt@gamma.ru, mike@smith.net.au,
        sclawson@bottles.cs.utah.edu, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199712182144.OAA27429@panzer.plutotech.com> from "Kenneth Merry" at Dec 18, 97 02:44: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 do not believe this is a single bit error.  I believe this is the same
> > > > problem I have been seeing.
> > > > 
> > > > Does your ethernet hardware address begin with 00 00?
> > > 
> > > news.gamma.ru (158.250.39.26) at 0:0:c0:a4:2e:61
> > > Is there a problem with 0:0 ?
> > 
> > Look at your corrupt variables and nearby variables in the stack, and
> > see if your ethernet address is being blown onto the stack somewhere.
> > 
> > There is no problem with the 0:0, but it reinforces my feeling that
> > this could be resulting from a trashed kernel stack.
> 
> 	I doubt that his ethernet address indicates any problems.  00:00:c0
> is an SMC ethernet address prefix.  I've got two SMC 10/100 cards in one of
> my systems, and a SMC Elite Ultra 16 (or something to that effect) in
> another system, and all of the ethernet addresses begin with 00:00:c0.

You are missing it.

There exists a bug such that a struct sockaddr can be written to an
arbitrary kernel stack.  This struct sockaddr contains a source addr,
a dest addr (your machine), a protocol type of 0x8000, and so on.  I
have a system dump that procves this is occurring.  I still don't know
why, but I *do* know that it is.  Probably it involves a stack address
being erroneously stored over a sleep and then referenced at interrupt
time.

I am asking him to look to see if his problem is because his kernel
stack was tromped by this bug.

To do that, he has to look at the kernel stack around the error and see
if he sees something that looks like a sockaddr has been written to
his stack.

He will have to x/16x (or whatever) his stack, and ignore whether or
not something belongs in one variable or another.  Where things belong
and where things are are two different things for this crash.

The reason I asked about his address at all was to see if his address
could account for the particular instance of damage he reported.  I
think it can because the thing is in reverse order (ie: not Intel byte
order ie: network byte order ie: God's byte order).  This means that
it will blow zero's at the front of anything it only partially corrupts.


					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 Dec 18 16:30:03 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA06091
          for hackers-outgoing; Thu, 18 Dec 1997 16:30:03 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from unix.tfs.net (pm3-p25.tfs.net [206.154.183.217])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06015
          for ; Thu, 18 Dec 1997 16:27:20 -0800 (PST)
          (envelope-from jbryant@unix.tfs.net)
Received: (from jbryant@localhost)
	by unix.tfs.net (8.8.8/8.8.5) id SAA08439;
	Thu, 18 Dec 1997 18:26:54 -0600 (CST)
From: Jim Bryant 
Message-Id: <199712190026.SAA08439@unix.tfs.net>
Subject: Re: FreeBSD description in the UNIX FAQ
In-Reply-To: <199712182103.WAA19845@uriah.heep.sax.de> from J Wunsch at "Dec 18, 97 10:03:36 pm"
To: joerg_wunsch@uriah.heep.sax.de
Date: Thu, 18 Dec 1997 18:26:53 -0600 (CST)
Cc: freebsd-hackers@freebsd.org
Reply-to: jbryant@unix.tfs.net
X-Windows: R00LZ!@#  MS-Winbl0wz DR00LZ!@#
X-Operating-System: FreeBSD 3.0-CURRENT #0: Mon Dec  1 15:51:40 CST 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:
> Sire Lancelot du Lac  wrote:
> 
> > Can someone from the core team write a new description for FreeBSD and
> > submit it to the maintainer of the UNIX FAQ (tmatimar@isgtec.com).
> 
> Why don't _you_ do it but expect us to do all the work?  I'm pretty
> sure, as long as your description is basically correct (and it's hard
> to imagine it might come out that wrong for what might become a
> 10-liner), nobody would mind you sending it to the FAQ maintainer in
> the name of FreeBSD.
> 
> If you think you need explicit approval, you can always send it to
> core@freebsd.org before.

well, having been back working for the last couple of weeks, i'm
finally getting caught up on my email [been learning our hw config at
work...  4 hp-9000's k220 & k400's, hp-serviceguard, etc, blah blah
blah]...

how about this [flames to /dev/null, please]:

	FreeBSD: The most advanced version of BSD available on PC's.

	[if it ain't, it's damn close].

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  Thu Dec 18 16:50:10 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA07335
          for hackers-outgoing; Thu, 18 Dec 1997 16:50:10 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 QAA06965
          for ; Thu, 18 Dec 1997 16:44:52 -0800 (PST)
          (envelope-from pallenby@zibbi.mikom.csir.co.za)
Received: (from pallenby@localhost)
	by zibbi.mikom.csir.co.za (8.8.8/8.8.7) id CAA07300
	for freebsd-hackers@freebsd.org; Fri, 19 Dec 1997 02:28:08 +0200 (SAT)
From: Paul Allenby 
Message-Id: <199712190028.CAA07300@zibbi.mikom.csir.co.za>
Subject: wd and DMA
To: freebsd-hackers@freebsd.org
Date: Fri, 19 Dec 1997 02:28:08 +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
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi all

A few days ago I mailed this to freebsd-current, but never received a reply.

------------------------------------------------------------------------
A while ago John Hood spotted a bug in his isa DMA code which he fixed
with the following:


--- pci/ide_pci.c       Sat Nov  8 02:22:48 1997
+++ /tmp/ide_pci.c      Mon Nov 10 23:35:00 1997
@@ -714,7 +714,7 @@
                u_long word40;
 
                /* can drive do PIO 4 and MW DMA 2? */
-               if (!(mwdma_mode(wp) >= 4 && pio_mode(wp) >= 4)) 
+               if (!(mwdma_mode(wp) >= 2 && pio_mode(wp) >= 4)) 
                        return 0;
 
                word40 = pci_conf_read(cookie->tag, 0x40);

I had this patch in my source tree until I moved /sys to a different
disk and had to re-checkout -current's kernel code.

After booting with a new kernel, DMA was no longer reported by the wd 
driver. So, my request is that would someone please commit this change :)

Paul

-------------------------------------------------------------------------

The commitlogs also show that this has not been committed.
Any responses?

Paul

From owner-freebsd-hackers  Thu Dec 18 18:27:12 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA12702
          for hackers-outgoing; Thu, 18 Dec 1997 18:27:12 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 SAA12694
          for ; Thu, 18 Dec 1997 18:26:48 -0800 (PST)
          (envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
	by dyson.iquest.net (8.8.8/8.8.8) id VAA00252;
	Thu, 18 Dec 1997 21:26:17 -0500 (EST)
	(envelope-from toor)
From: "John S. Dyson" 
Message-Id: <199712190226.VAA00252@dyson.iquest.net>
Subject: Re: wd and DMA
In-Reply-To: <199712190028.CAA07300@zibbi.mikom.csir.co.za> from Paul Allenby at "Dec 19, 97 02:28:08 am"
To: pallenby@zibbi.mikom.csir.co.za (Paul Allenby)
Date: Thu, 18 Dec 1997 21:26:17 -0500 (EST)
Cc: 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

Paul Allenby said:
> Hi all
> 
> A few days ago I mailed this to freebsd-current, but never received a reply.
> 
I'll do it right now.

-- 
John                  | Never try to teach a pig to sing,
dyson@freebsd.org     | it just makes you look stupid,
jdyson@nc.com         | and it irritates the pig.

From owner-freebsd-hackers  Thu Dec 18 18:40:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA13444
          for hackers-outgoing; Thu, 18 Dec 1997 18:40:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from tahiti.oss.uswest.net (tahiti.oss.uswest.net [204.147.85.151])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA13395
          for ; Thu, 18 Dec 1997 18:39:57 -0800 (PST)
          (envelope-from rantapaa@uswest.net)
Received: (from rantapaa@localhost) by tahiti.oss.uswest.net (8.8.5/8.6.12) id UAA09438; Thu, 18 Dec 1997 20:39:55 -0600 (CST)
Date: Thu, 18 Dec 1997 20:39:55 -0600 (CST)
From: Erik E Rantapaa 
To: freebsd-hackers@freebsd.org
Subject: close() on a modem taking a long time?
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


Hello fellow-FreeBSD'ers,

I've been tracking down a problem we've been having with sendpage
and it appears that close() on a serial line attached to a modem
can sometimes take a long time (like 20 minutes or more).
Can anyone think of a reason why this might be happening
(and more importantly, how to get around it)?

(btw, this is with 2.2.5)

--
Erik Rantapaa
rantapaa@uswest.net

From owner-freebsd-hackers  Thu Dec 18 19:20:48 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA15573
          for hackers-outgoing; Thu, 18 Dec 1997 19:20:48 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 TAA15564
          for ; Thu, 18 Dec 1997 19:20:44 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id TAA24307;
	Thu, 18 Dec 1997 19:19:29 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd024302; Thu Dec 18 19:19:28 1997
Message-ID: <3499E71A.167EB0E7@whistle.com>
Date: Thu, 18 Dec 1997 19:16:42 -0800
From: Julian Elischer 
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: John-Mark Gurney 
CC: Mike Smith , Darren Reed ,
        freebsd-hackers@freebsd.org
Subject: Re: converting drivers to dynamic memory...
References: <19971218065107.10999@hydrogen.nike.efn.org> <199712182230.JAA01661@word.smith.net.au> <19971218145005.37073@hydrogen.nike.efn.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

John-Mark Gurney wrote:

For compatibility with the existing system,
devfs accesses all the devices through the standard
major/minor system.

this si so that the same driver can run with both devfs and 
non-devfs systems.

The AIM is that after a cut-over to devfs,
drivers could be modified to take more generalised arguments.

the minor number can be interpretted as a cookie that can be used to
look something up in a hash-table or similar.

That's what I do in slice/slice_device.c
the minor number there is just a cookie, that is used to find 
a softc structure. In a more generalised situation.
the minor could be used to find a small structure
which in turn contains a pointer to the softc, plus a unique
sub-identifier.

eventually, the minor number might be interpretted directly as a 
pointer to this structure.

Since teh minor number is supplied by the driver and never 
alterable by the user, this is safe. it might also be 
possible to make it not print out at all in 'ls'
as that would just be confusing.

What I'm saying is that the minor number can be interpretted
as the driver sees fit, however in the current system it must 
be a static thing and that is very limiting. (not to mention 
we only have 24 bits)


> 
> Mike Smith scribbled this message on Dec 19:
> > > yep, I think that would be a great addition...  IMO, once devfs has
> > > finally been completed, we will still need a minor number of the void *
> > > (I happen to like the name dev_info_t), the minor so that we know what
> > > part of the device driver we are accessing...  else we would need to
> > > allocate a bunch of small structs like:
> > > struct {
> > >     int option;
> > >     struct devicedata data;
> > > }
> > >
> > > which would be really wasteful of precious memory resources...
> >
> > No.  I take your point about wanting to have multiple DEVFS entries
> > referencing a single softc structure though; you might want to have
> > something like:
> >
> > struct devfs_softc_reference
> > {
> >       void    *softc;
> >       int     token;
> > }
> >
> > inside the devfs_node structure.
> 
> yep, that's what I'd like...
> 
> > Forget the btree model; it's not going to fly in the face of a direct
> > reference approach.
> 
> I will once devfs and the driver interface supports it...  but devfs and
> the interface doesn't even support passing a token yet (well, it does if
> you call minor number a token)... I just proposed a simple stop gap
> meassure that would get the ball rolling..
> 
> when did I ever say that we should in the long run choose using a
> btree over the "correct" way to do it??  I only said it would require
> an interface change (which hasn't even started to happen, sure the
> devfs code is in place, but actually USING it to pass tokens hasn't
> even begun), which I stated, I wasn't going to do... but I proposed
> using the btree method as a stepping stone to get to the final
> destination...
> 
> --
>   John-Mark Gurney                          Modem/FAX: +1 541 683 6954
>   Cu Networking                                   P.O. Box 5693, 97405
> 
>   Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-hackers  Thu Dec 18 19:22:14 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA15651
          for hackers-outgoing; Thu, 18 Dec 1997 19:22:14 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA15641
          for ; Thu, 18 Dec 1997 19:22:05 -0800 (PST)
          (envelope-from sclawson@bottles.cs.utah.edu)
Received: from bottles.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs)
	id UAA27882; Thu, 18 Dec 1997 20:21:57 -0700 (MST)
Received: by bottles.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id UAA18957; Thu, 18 Dec 1997 20:21:51 -0700
From: sclawson@bottles.cs.utah.edu (steve clawson)
Message-Id: <199712190321.UAA18957@bottles.cs.utah.edu>
Subject: Re: panic: blkfree: freeling free block/frag
To: tlambert@primenet.com (Terry Lambert)
Date: Thu, 18 Dec 1997 20:21:51 -0700 (MST)
Cc: mike@smith.net.au, sclawson@bottles.cs.utah.edu, ivt@gamma.ru,
        tlambert@primenet.com, freebsd-hackers@freebsd.org
In-Reply-To: <199712171842.LAA02077@usr02.primenet.com> from "Terry Lambert" at Dec 17, 97 06:42:38 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert uttered:
> > >      All nicely clustered...except for that sixth one.  At first I
> > > thought that the clustering code was at fault, but disk block 79be0
> > > was untouched, and the `real' disk block (179be0) had the correct data
> > > for the new file.  So, the list of blocks in the inode was corrupted
> > > sometime after the data blocks for the file were written.
> > 
> > Single-bit memory error, perhaps?  Still, keep an eye on it...
>
> If this panic'ed, you need to look at the stack.  I would prefer you look
> at the stack for #5.

    I don't have a crash dump of it, since I found the affected files
before someone decided to try and delete them and panic the system.
Not that it would have helped much in this case, since the corruption
happened long before the panic.  Basically the problem I'm seeing
leaves these time bombs sitting in the filesystem for you. =(

> I do not believe this is a single bit error.  I believe this is the same
> problem I have been seeing.
> 
> Does your ethernet hardware address begin with 00 00?

     Yes.  The machine has 3 active ether cards, all of which have
hardware addresses that begin with 00 00.
     

steve

-- 
// stephen clawson				sclawson@cs.utah.edu
// university of utah			        


From owner-freebsd-hackers  Thu Dec 18 19:48:41 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA17486
          for hackers-outgoing; Thu, 18 Dec 1997 19:48:41 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA17475
          for ; Thu, 18 Dec 1997 19:48:30 -0800 (PST)
          (envelope-from tlambert@usr01.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.8/8.8.8) id UAA25173;
	Thu, 18 Dec 1997 20:48:24 -0700 (MST)
Received: from usr01.primenet.com(206.165.6.201)
 via SMTP by smtp04.primenet.com, id smtpd025155; Thu Dec 18 20:48:18 1997
Received: (from tlambert@localhost)
	by usr01.primenet.com (8.8.5/8.8.5) id UAA02489;
	Thu, 18 Dec 1997 20:48:18 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712190348.UAA02489@usr01.primenet.com>
Subject: Re: panic: blkfree: freeling free block/frag
To: sclawson@bottles.cs.utah.edu (steve clawson)
Date: Fri, 19 Dec 1997 03:48:18 +0000 (GMT)
Cc: tlambert@primenet.com, mike@smith.net.au, sclawson@bottles.cs.utah.edu,
        ivt@gamma.ru, freebsd-hackers@freebsd.org
In-Reply-To: <199712190321.UAA18957@bottles.cs.utah.edu> from "steve clawson" at Dec 18, 97 08:21:51 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

[ ... random panic's ... ]

Archie Cobb has fixed the cause of the panic I've been thinking of.

The panic would only occur in the case of a ip firewall TCP reject
rule being present.

If you do not have any ip firewall code active, then ignore what I've
said so far about the stack correuption bug.

If you have ip firewall code active, then you should probably apply
Archie's fix as soon as he makes it available.


					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 Dec 18 19:53:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA17943
          for hackers-outgoing; Thu, 18 Dec 1997 19:53:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA17930
          for ; Thu, 18 Dec 1997 19:53:07 -0800 (PST)
          (envelope-from tlambert@usr01.primenet.com)
Received: (from daemon@localhost)
	by smtp02.primenet.com (8.8.8/8.8.8) id UAA04848;
	Thu, 18 Dec 1997 20:53:06 -0700 (MST)
Received: from usr01.primenet.com(206.165.6.201)
 via SMTP by smtp02.primenet.com, id smtpd004836; Thu Dec 18 20:53:02 1997
Received: (from tlambert@localhost)
	by usr01.primenet.com (8.8.5/8.8.5) id UAA02805;
	Thu, 18 Dec 1997 20:53:02 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712190353.UAA02805@usr01.primenet.com>
Subject: Re: close() on a modem taking a long time?
To: rantapaa@uswest.net (Erik E Rantapaa)
Date: Fri, 19 Dec 1997 03:53:01 +0000 (GMT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To:  from "Erik E Rantapaa" at Dec 18, 97 08:39:55 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 been tracking down a problem we've been having with sendpage
> and it appears that close() on a serial line attached to a modem
> can sometimes take a long time (like 20 minutes or more).
> Can anyone think of a reason why this might be happening
> (and more importantly, how to get around it)?
> 
> (btw, this is with 2.2.5)

Close attemptsd to flush output, I believe.

This delay could occur if the modem has dropped RTS, if the DCD is
still active.  I believe the flush occursbefore the DTR drop to
reset the modem.

If the modem is internal, well, then you get what you deserve (internal
modems suck).

If it's external, try power cycling the modem and see if that fixes it;
if it does, it points the way toward a fix... probably modem configuration,
since a modem in command mode should not be asserting DCD and the driver
should ignore RTS if DCD is not asserted.  Alternately, it should assert
RTS if it's not asserting DCD.


					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 Dec 18 20:02:07 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA18552
          for hackers-outgoing; Thu, 18 Dec 1997 20:02:07 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA18537
          for ; Thu, 18 Dec 1997 20:02:00 -0800 (PST)
          (envelope-from archie@whistle.com)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id UAA22657; Thu, 18 Dec 1997 20:01:29 -0800 (PST)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
	id sma022653; Thu Dec 18 20:01:01 1997
Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id UAA23662; Thu, 18 Dec 1997 20:01:01 -0800 (PST)
From: Archie Cobbs 
Message-Id: <199712190401.UAA23662@bubba.whistle.com>
Subject: Re: close() on a modem taking a long time?
In-Reply-To:  from Erik E Rantapaa at "Dec 18, 97 08:39:55 pm"
To: rantapaa@uswest.net (Erik E Rantapaa)
Date: Thu, 18 Dec 1997 20:01:00 -0800 (PST)
Cc: 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

Erik E Rantapaa writes:
> 
> I've been tracking down a problem we've been having with sendpage
> and it appears that close() on a serial line attached to a modem
> can sometimes take a long time (like 20 minutes or more).
> Can anyone think of a reason why this might be happening
> (and more importantly, how to get around it)?

Serial ports usually wait for output to finish on a close (I think).
You may be able to disable this feature.. see man termios (HUPCL?).

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

From owner-freebsd-hackers  Thu Dec 18 20:04:40 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA18766
          for hackers-outgoing; Thu, 18 Dec 1997 20:04:40 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA18742
          for ; Thu, 18 Dec 1997 20:04:27 -0800 (PST)
          (envelope-from koshy@india.hp.com)
Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1])
	by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id UAA03560;
	Thu, 18 Dec 1997 20:04:10 -0800 (PST)
Message-Id: <199712190404.UAA03560@palrel1.hp.com>
Received: from localhost by postbox.india.hp.com with ESMTP
	(1.39.111.2/16.2) id AA141794235; Fri, 19 Dec 1997 09:33:55 +0530
To: freebsd-hackers@freebsd.org
Cc: gurney_j@efn.org
Subject: Re: converting drivers to dynamic memory
Date: Fri, 19 Dec 1997 09:33:54 +0530
From: A Joseph Koshy 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>>>>>> John-Mark Gurney  said:

Hi John-Mark,

If you are proposing new in-kernel structures, it may be convenient to 
choose those that can be later be easily parallelized.  This can then avoid 
unnecessary serialization on the data structure if/when the degree of
processor parallelism supported by FreeBSD increases in the future.

> Timings:
>         Fibonacci heap (amortized):
>                 Make-Heap       theta(1)
>                 Insert          theta(1)
>                 Minimum         theta(1)
>                 Extract-min     O(lg n)
>                 Union           theta(1)
>                 Decrease-key    theta(1)
>                 Delete          O(lg n)
>         B-Tree (each node has between t - 1 and 2t -1 keys)
>                 Create          O(1)
>                 Search          O(t logt n) soon to be O(lg t * logt n)
>                 Insert            "
>                 Delete            "

(I'll have to read up on Fibonacci heaps).

For example, concurrent B-trees are supposedly very complex to implement,
so typically people get by locking the root node and taking the serialization
hit.

> quite small.  The Fib heap code is under 3k, and the B-tree code is
> 4736 bytes, but this includes some debugkuing code (printing tree and

Did you look at skiplists too?  Typical skiplist implementations tend to be
small and can be coded to use the cache nicely.  Further, combined with 
non-blocking primitives like compare-and-swap (x86-post-P5), or 
load-linked/store-conditional (Alpha) (we are going to have FreeBSD/Alpha 
some day aren't we? :)) it can really shine.

Koshy
#include STD_DISCLAIMER

From owner-freebsd-hackers  Thu Dec 18 20:10:15 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA19228
          for hackers-outgoing; Thu, 18 Dec 1997 20:10:15 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 UAA19216
          for ; Thu, 18 Dec 1997 20:10:08 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id UAA25320
	for ; Thu, 18 Dec 1997 20:06:04 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd025307; Thu Dec 18 20:05:59 1997
Message-ID: <3499F202.794BDF32@whistle.com>
Date: Thu, 18 Dec 1997 20:03:14 -0800
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: ipfw fix
Content-Type: multipart/mixed; boundary="------------1CFBAE3959E2B60015FB7483"
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

This is a multi-part message in MIME format.

--------------1CFBAE3959E2B60015FB7483
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If you use ipfw and the "reset tcp" option,
you may want to apply the following patch.
In fact you may want to do it if you MIGHT in the future do that.

stops random kernel panics due to kernel stack overwrites.

this fix is valid for 2.2.5 and 3.0

It has just been checked in..

--------------1CFBAE3959E2B60015FB7483
Content-Type: text/plain; charset=us-ascii; name="knarlybugfix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="knarlybugfix.patch"

*** netinet/ip_fw.c	1997/11/22 13:00:48	1.51.2.6
--- new/netinet/ip_fw.c	1997/12/19 02:54:54
***************
*** 576,598 ****
  		  {
  			struct tcphdr *const tcp =
  				(struct tcphdr *) ((u_long *)ip + ip->ip_hl);
! 			struct tcpiphdr ti;
  
  			if (offset != 0 || (tcp->th_flags & TH_RST))
  				break;
  			ti.ti_i = *((struct ipovly *) ip);
  			ti.ti_t = *tcp;
! 			NTOHL(ti.ti_seq);
! 			NTOHL(ti.ti_ack);
! 			ti.ti_len = ip->ip_len - hlen - (ti.ti_off << 2);
  			if (tcp->th_flags & TH_ACK) {
! 				tcp_respond(NULL, &ti, *m,
  				    (tcp_seq)0, ntohl(tcp->th_ack), TH_RST);
  			} else {
  				if (tcp->th_flags & TH_SYN)
! 					ti.ti_len++;
! 				tcp_respond(NULL, &ti, *m, ti.ti_seq
! 				    + ti.ti_len, (tcp_seq)0, TH_RST|TH_ACK);
  			}
  			*m = NULL;
  			break;
--- 576,599 ----
  		  {
  			struct tcphdr *const tcp =
  				(struct tcphdr *) ((u_long *)ip + ip->ip_hl);
! 			struct tcpiphdr ti, *const tip = (struct tcpiphdr *) ip;
  
  			if (offset != 0 || (tcp->th_flags & TH_RST))
  				break;
  			ti.ti_i = *((struct ipovly *) ip);
  			ti.ti_t = *tcp;
! 			bcopy(&ti, ip, sizeof(ti));
! 			NTOHL(tip->ti_seq);
! 			NTOHL(tip->ti_ack);
! 			tip->ti_len = ip->ip_len - hlen - (tip->ti_off << 2);
  			if (tcp->th_flags & TH_ACK) {
! 				tcp_respond(NULL, tip, *m,
  				    (tcp_seq)0, ntohl(tcp->th_ack), TH_RST);
  			} else {
  				if (tcp->th_flags & TH_SYN)
! 					tip->ti_len++;
! 				tcp_respond(NULL, tip, *m, tip->ti_seq
! 				    + tip->ti_len, (tcp_seq)0, TH_RST|TH_ACK);
  			}
  			*m = NULL;
  			break;
*** netinet/tcp_subr.c	1997/09/30 16:25:11	1.31.2.3
--- new/netinet/tcp_subr.c	1997/12/19 03:01:16
***************
*** 168,173 ****
--- 168,175 ----
   *
   * In any case the ack and sequence number of the transmitted
   * segment are as specified by the parameters.
+  *
+  * NOTE: If m != NULL, then ti must point to *inside* the mbuf.
   */
  void
  tcp_respond(tp, ti, m, ack, seq, flags)

--------------1CFBAE3959E2B60015FB7483--


From owner-freebsd-hackers  Thu Dec 18 20:11:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA19333
          for hackers-outgoing; Thu, 18 Dec 1997 20:11:04 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 UAA19320
          for ; Thu, 18 Dec 1997 20:11:00 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id UAA25416;
	Thu, 18 Dec 1997 20:10:05 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd025414; Thu Dec 18 20:10:01 1997
Message-ID: <3499F2F4.3F54BC7E@whistle.com>
Date: Thu, 18 Dec 1997 20:07:16 -0800
From: Julian Elischer 
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: steve clawson 
CC: Terry Lambert , mike@smith.net.au, ivt@gamma.ru,
        freebsd-hackers@FreeBSD.ORG
Subject: Re: panic: blkfree: freeling free block/frag
References: <199712190321.UAA18957@bottles.cs.utah.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

we just solved the problem terry was seeing.
if you are not using ipfw that aint it...

julian

steve clawson wrote:
> 
> Terry Lambert uttered:
> > > >      All nicely clustered...except for that sixth one.  At first I
> > > > thought that the clustering code was at fault, but disk block 79be0
> > > > was untouched, and the `real' disk block (179be0) had the correct data
> > > > for the new file.  So, the list of blocks in the inode was corrupted
> > > > sometime after the data blocks for the file were written.
> > >
> > > Single-bit memory error, perhaps?  Still, keep an eye on it...
> >
> > If this panic'ed, you need to look at the stack.  I would prefer you look
> > at the stack for #5.
> 
>     I don't have a crash dump of it, since I found the affected files
> before someone decided to try and delete them and panic the system.
> Not that it would have helped much in this case, since the corruption
> happened long before the panic.  Basically the problem I'm seeing
> leaves these time bombs sitting in the filesystem for you. =(
> 
> > I do not believe this is a single bit error.  I believe this is the same
> > problem I have been seeing.
> >
> > Does your ethernet hardware address begin with 00 00?
> 
>      Yes.  The machine has 3 active ether cards, all of which have
> hardware addresses that begin with 00 00.
> 
> 
> steve
> 
> --
> // stephen clawson                              sclawson@cs.utah.edu
> // university of utah

From owner-freebsd-hackers  Thu Dec 18 21:11:20 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA22696
          for hackers-outgoing; Thu, 18 Dec 1997 21:11:20 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 VAA22675
          for ; Thu, 18 Dec 1997 21:10:35 -0800 (PST)
          (envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id UAA11721;
          Thu, 18 Dec 1997 20:43:34 -0800 (PST)
Message-ID: <19971218204334.41263@hydrogen.nike.efn.org>
Date: Thu, 18 Dec 1997 20:43:34 -0800
From: John-Mark Gurney 
To: A Joseph Koshy 
Cc: freebsd-hackers@freebsd.org
Subject: Re: converting drivers to dynamic memory
References: <199712190404.UAA03560@palrel1.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199712190404.UAA03560@palrel1.hp.com>; from A Joseph Koshy on Fri, Dec 19, 1997 at 09:33:54AM +0530
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

A Joseph Koshy scribbled this message on Dec 19:
> >>>>>> John-Mark Gurney  said:
> If you are proposing new in-kernel structures, it may be convenient to 
> choose those that can be later be easily parallelized.  This can then avoid 
> unnecessary serialization on the data structure if/when the degree of
> processor parallelism supported by FreeBSD increases in the future.

hmm...  good point...  I'll have to talk with a professor of mine that
knows data structures a bit better than I for suggestions...  this isn't
something that they normally cover in a 300 or 400 level classes... :(

> > Timings:
> >         Fibonacci heap (amortized):
> >                 Make-Heap       theta(1)
> >                 Insert          theta(1)
> >                 Minimum         theta(1)
> >                 Extract-min     O(lg n)
> >                 Union           theta(1)
> >                 Decrease-key    theta(1)
> >                 Delete          O(lg n)
> >         B-Tree (each node has between t - 1 and 2t -1 keys)
> >                 Create          O(1)
> >                 Search          O(t logt n) soon to be O(lg t * logt n)
> >                 Insert            "
> >                 Delete            "
> 
> (I'll have to read up on Fibonacci heaps).
> 
> For example, concurrent B-trees are supposedly very complex to implement,
> so typically people get by locking the root node and taking the serialization
> hit.
> 
> > quite small.  The Fib heap code is under 3k, and the B-tree code is
> > 4736 bytes, but this includes some debugkuing code (printing tree and
> 
> Did you look at skiplists too?  Typical skiplist implementations tend to be
> small and can be coded to use the cache nicely.  Further, combined with 
> non-blocking primitives like compare-and-swap (x86-post-P5), or 
> load-linked/store-conditional (Alpha) (we are going to have FreeBSD/Alpha 
> some day aren't we? :)) it can really shine.

hmm...  can you point me to a book that has 'em?

talking about cache's..  using a btree with a node size of 128 bytes
is a significant performance boost...  even on an old Intel 486DX2/66
processor...

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking					  P.O. Box 5693, 97405

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-hackers  Thu Dec 18 21:53:48 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA25360
          for hackers-outgoing; Thu, 18 Dec 1997 21:53:48 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from bb.cc.wa.us (root@aries.bb.cc.wa.us [134.39.181.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA25352
          for ; Thu, 18 Dec 1997 21:53:42 -0800 (PST)
          (envelope-from chris@bb.cc.wa.us)
Received: from localhost (chris@localhost) by bb.cc.wa.us (8.8.5/8.6.9) with SMTP id VAA23074; Thu, 18 Dec 1997 21:52:19 -0800 (PST)
Date: Thu, 18 Dec 1997 21:52:19 -0800 (PST)
From: Chris Coleman 
To: Terry Lambert 
cc: Nate Williams , daniel_sobral@voga.com.br,
        hackers@FreeBSD.ORG
Subject: Re: Why so many steps to build new kernel?
In-Reply-To: <199712180317.UAA07959@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

> > > > Heck, I've got 10-20 people willing to be added to the 'FS-101'
list by

	How may people would we need to round up before you would be
willing to "block out a large chunk of time" and do an 'FS-101'. I am sure
I have a handful of people over here.  (me included) :-).  Do I need to do
a roll call ? ;-)

> 
> I have to actually block out a large chunk of time to be able to do
> this in a way that isn't half-assed.  I'm a bit cautious here as well:
> 
> 					Terry Lambert
> 					terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
> 


Christopher J. Coleman (chris@bb.cc.wa.us)
Computer Support Analyst I  (509)-766-8873
FreeBSD Book Project:  http://www.vmunix.com/fbsd-book/

On Thu, 18 Dec 1997, Terry Lambert wrote:




From owner-freebsd-hackers  Thu Dec 18 23:19:36 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA29600
          for hackers-outgoing; Thu, 18 Dec 1997 23:19:36 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA29593
          for ; Thu, 18 Dec 1997 23:19:31 -0800 (PST)
          (envelope-from michaelh@cet.co.jp)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id HAA05505; Fri, 19 Dec 1997 07:18:42 GMT
Date: Fri, 19 Dec 1997 16:18:42 +0900 (JST)
From: Michael Hancock 
To: John-Mark Gurney 
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory...
In-Reply-To: <19971218145005.37073@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 Thu, 18 Dec 1997, John-Mark Gurney wrote:

> > Forget the btree model; it's not going to fly in the face of a direct 
> > reference approach. 
> 
> I will once devfs and the driver interface supports it...  but devfs and
> the interface doesn't even support passing a token yet (well, it does if
> you call minor number a token)... I just proposed a simple stop gap
> meassure that would get the ball rolling..
> 
> when did I ever say that we should in the long run choose using a
> btree over the "correct" way to do it??  I only said it would require

Hashing for example is very good in the kernel, even in cases where you
think btrees would be better.  The reasoning is along the lines of what
Koshy was talking about.  If you can abstract things well enough so that
you can make a change later on very easily, by all means carry on. 
Someone will find a use for your Btrees elsewhere most likely. 


Mike Hancock


From owner-freebsd-hackers  Thu Dec 18 23:38:30 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA00542
          for hackers-outgoing; Thu, 18 Dec 1997 23:38:30 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA00537
          for ; Thu, 18 Dec 1997 23:38:27 -0800 (PST)
          (envelope-from michaelh@cet.co.jp)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id HAA05630; Fri, 19 Dec 1997 07:37:36 GMT
Date: Fri, 19 Dec 1997 16:37:36 +0900 (JST)
From: Michael Hancock 
To: Chris Coleman 
cc: Terry Lambert , Nate Williams ,
        FreeBSD Hackers 
Subject: Re: Why so many steps to build new kernel?
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 Dec 1997, Chris Coleman wrote:

> > > > > Heck, I've got 10-20 people willing to be added to the 'FS-101'
> list by
> 
> 	How may people would we need to round up before you would be
> willing to "block out a large chunk of time" and do an 'FS-101'. I am sure
> I have a handful of people over here.  (me included) :-).  Do I need to do
> a roll call ? ;-)

FS-101 should be web pages containing a design document that explains the
problems with the current model and the benefits the new proposed model
will provide and how.  More time should be spent spent covering the
architecture before any patches are committed for such a central
subsystem.

I want to know where I'm going before I commit time to using and testing a
new FS system that can possibly corrupt my disk partitions.  This is
highly possible no matter how god-like the FS designer/coder is.  It's a
complex piece of code.

Regards,


Mike Hancock


From owner-freebsd-hackers  Thu Dec 18 23:44:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA01009
          for hackers-outgoing; Thu, 18 Dec 1997 23:44:21 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from acaxp (acaxp.physik.rwth-aachen.de [137.226.33.200])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA00999;
          Thu, 18 Dec 1997 23:44:08 -0800 (PST)
          (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE)
Received: from gilberto by acaxp; (5.65v3.2/1.1.8.2/17Mar96-1112AM)
	id AA28116; Fri, 19 Dec 1997 08:44:06 +0100
Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.8/8.6.9) id IAA20860; Fri, 19 Dec 1997 08:44:12 +0100 (MET)
Message-Id: <19971219084412.46153@gil.physik.rwth-aachen.de>
Date: Fri, 19 Dec 1997 08:44:12 +0100
From: Christoph Kukulies 
To: Stefan Esser 
Cc: "Christoph P. Kukulies" , ports@freebsd.org,
        freebsd-hackers@freebsd.org
Subject: Re: Wine success story
References: <199712170841.JAA20651@isdn-kukulies.dialup.rwth-aachen.de> <19971217235738.48757@mi.uni-koeln.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <19971217235738.48757@mi.uni-koeln.de>; from Stefan Esser on Wed, Dec 17, 1997 at 11:57:38PM +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id XAA01001
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, Dec 17, 1997 at 11:57:38PM +0100, Stefan Esser wrote:
> On 1997-12-17 09:41 +0100, "Christoph P. Kukulies"  wrote:
> > 
> > Just FYI:
> > 
> > I installed the most recent version of Wine (Wine-971130 from sunsite).
> > And despite one quirk in memory/virtual.c where I had to get
> > acoross the fact that FreeBSD doesn't do synchronuous memory
> > syncs (Linux: ) I was able to throw it at my
> > C:\WIN95 directory.
> 
> Hi Christoph!
> 
> Hmmm, didn't you build Wine from within the ports tree ?
> If you did, then the second chunk in patch-an should have
> taken care of defining MS_SYNC:

Actually the story went this way:

I compiled wine from the ports tree and it gave a bad system call
in the first place. Hmm, thought I, should the port be broken? Maybe.
Anywat, let's try the latest version (971130) and while doing this
it came to mind that SYSVSHM might be the cause for the bad system call.

Then it worked and while being at the newer version anyway I didn't care
to fall back to previous (ports) release).

Strange though that the patch didn't apply. 

> 
> *** memory/virtual.c~   Mon Dec  1 23:13:06 1997
> --- memory/virtual.c    Mon Dec  1 23:24:57 1997
> ***************
> *** 1098,1101 ****
> --- 1098,1104 ----
>       }
>       if (!cbFlush) cbFlush = view->size;
> + #ifndef MS_SYNC
> + #define MS_SYNC 0
> + #endif MS_SYNC
>       if (!msync( addr, cbFlush, MS_SYNC )) return TRUE;
>       SetLastError( ERROR_INVALID_PARAMETER );
> 
> I had added that patch before John Dyson added MS_SYNC
> to sys/mman.h. AFAIK, we didn't need it, because it is
> the default behaviour of msync() (that's where the name
> comes from :), and a flag value of 0 could have been 
> used in WINE.
> 
> > wine progman
> > 
> > and voila, my Win95 desktop appeared neatly sorted in progman program groups.
> > The fonts and the colors/hatching/dithering a bit strange though.
> 
> You may need to edit your $(PREFIX)/etc/wine.conf file,
> if it contains font alias lines as required by earlier
> releases of WINE. See the sample wine.ini file found in
> the work directory.
> 
> > Now, the big success: Freecell works!
> > 
> > So, no more need to boot a Win95/NT System :-)
> 
> Quite some more stuff is working under WINE! I've been
> using it to look at MS-Word .doc files. Both Winword and
> the free Word viewer work reasonably well under WINE for
> more than one year, already!
> 

[...]

> 
> You can always choose to execute the real Windows DLLs, 
> instead of the emulation code that comes with WINE.

Ah, that's interesting. Didn' t know that.

Actually, the reason why I tried wine againe was that I was in seek of
running some applications , a 8051 cross compiler, under DOS (emu or
whatever).

pcemu though running fine turned out to be insufficient since
it doesn't support DPMI resp. 386 architecture.

So my hopes concentrated on running a DOS Command Prompt box under Wine.
It doesn't seem to work with me here.

> 
> > What I'm concerned about though is the fact of this unimplemented
> > MS_SYNC feature. That's why I'm cross posting this to -hackers also.
> 
> Well, it always was kind of implemented ... 
> You only had to use its other name: "0" :)
> 
> Regards, STefan

Thanks.

-- 
Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de

From owner-freebsd-hackers  Fri Dec 19 01:06:38 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA05290
          for hackers-outgoing; Fri, 19 Dec 1997 01:06:38 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA05283
          for ; Fri, 19 Dec 1997 01:06:32 -0800 (PST)
          (envelope-from rb@gid.co.uk)
Received: from gid.co.uk (uucp@localhost)
          by isbalham.ist.co.uk (8.8.7/8.8.4) with UUCP
	  id JAA21882; Fri, 19 Dec 1997 09:04:58 GMT
Received: from grimbling (cwa240 [192.168.0.240]) by cwagate (8.6.12/8.6.12) with ESMTP id IAA18965; Fri, 19 Dec 1997 08:51:18 GMT
Message-Id: <199712190851.IAA18965@cwagate>
From: "Bob Bishop" 
To: 
Cc: 
Subject: I'm not normally paranoid, but...
Date: Fri, 19 Dec 1997 08:50:21 -0000
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

I've been investigating trouble with a client's dial-on-demand PPP (FBSD
2.1.5, but I don't think it matters). Most of the time it works just fine.
The specific problem is that sometimes the link fails to disconnect when it
is (or should be) idle; timeout is set to 3 min. Tcpdump says:

07:47:14.537061 207.68.137.75.http > [client's address].1369: . 0:1(1) ack
1 w
in 17520
07:47:14.537422 [client's address].1369 > 207.68.137.75.http: R 773:773(0)
win
 0
07:48:14.467440 207.68.137.75.http > [client's address].1369: . 0:1(1) ack
1 w
in 17520
07:48:14.467906 [client's address].1369 > 207.68.137.75.http: R 773:773(0)
win
 0
07:49:14.477160 207.68.137.75.http > [client's address].1369: . 0:1(1) ack
1 w
in 17520
07:49:14.477588 [client's address].1369 > 207.68.137.75.http: R 773:773(0)
win
 0

There is no PTR for 207.68.137.75 and it doesn't ping. However, guess whose
web site http://207.68.137.75 leads to :-{

So why does it insist on flogging a dead connexion?
And is there anything I can do about it, short of reducing the idle timeout
to < 1min (which doesn't seem sensible)? TIA
--
Bob Bishop                                   +44 118 977 4017
rb@gid.co.uk

From owner-freebsd-hackers  Fri Dec 19 01:23:28 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA06178
          for hackers-outgoing; Fri, 19 Dec 1997 01:23:28 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA06150
          for ; Fri, 19 Dec 1997 01:23:16 -0800 (PST)
          (envelope-from michaelh@cet.co.jp)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id JAA06354; Fri, 19 Dec 1997 09:21:19 GMT
Date: Fri, 19 Dec 1997 18:21:18 +0900 (JST)
From: Michael Hancock 
To: John-Mark Gurney 
cc: A Joseph Koshy , freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory
In-Reply-To: <19971218204334.41263@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 Thu, 18 Dec 1997, John-Mark Gurney wrote:

> A Joseph Koshy scribbled this message on Dec 19:
> > >>>>>> John-Mark Gurney  said:
> > If you are proposing new in-kernel structures, it may be convenient to 
> > choose those that can be later be easily parallelized.  This can then avoid 
> > unnecessary serialization on the data structure if/when the degree of
> > processor parallelism supported by FreeBSD increases in the future.
> 
> hmm...  good point...  I'll have to talk with a professor of mine that
> knows data structures a bit better than I for suggestions...  this isn't
> something that they normally cover in a 300 or 400 level classes... :(
> 

Here's an interesting link which covers why some data structures are
better than others for use in an OS kernel,
http://www-dsg.stanford.edu/michaelg/.

Algorithms in C by Robert Sedgewick, a former student of Donald Knuth, is
also pretty good.  The book is in the bibliography of the BSD book by
McKusick, et al.  The book covers radix tries which are in the networking
code.

Regards,


Mike Hancock


From owner-freebsd-hackers  Fri Dec 19 05:24:40 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA16567
          for hackers-outgoing; Fri, 19 Dec 1997 05:24:40 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA16562
          for ; Fri, 19 Dec 1997 05:24:36 -0800 (PST)
          (envelope-from dec@phoenix.its.rpi.edu)
Received: from localhost (dec@localhost)
	by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id IAA21139;
	Fri, 19 Dec 1997 08:24:17 -0500 (EST)
	(envelope-from dec@phoenix.its.rpi.edu)
Date: Fri, 19 Dec 1997 08:24:17 -0500 (EST)
From: "David E. Cross" 
To: Bob Bishop 
cc: hackers@FreeBSD.ORG
Subject: Re: I'm not normally paranoid, but...
In-Reply-To: <199712190851.IAA18965@cwagate>
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 Dec 1997, Bob Bishop wrote:

> Hi,
> 
> I've been investigating trouble with a client's dial-on-demand PPP (FBSD
> 2.1.5, but I don't think it matters). Most of the time it works just fine.
> The specific problem is that sometimes the link fails to disconnect when it
> is (or should be) idle; timeout is set to 3 min. Tcpdump says:
> 
I have seen this problem before here.  The problem here is that the
terminal servers occasionally send traffic to the connected machines (RIP
traffic, although it can be disabled on a per connection basis)... That
would serve to reset the idle time on the connection.


> 
> There is no PTR for 207.68.137.75 and it doesn't ping. However, guess whose
> web site http://207.68.137.75 leads to :-{

I am not sure how this is related to the above, but 'httpd' is sending
your hostname(1) back to the connecting computer, that is how it would get
your 'real' hostname, even without a PTR record.

--
David Cross
ACS Consultant


From owner-freebsd-hackers  Fri Dec 19 06:10:12 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA19063
          for hackers-outgoing; Fri, 19 Dec 1997 06:10:12 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cozumel.saidev.com (cozumel.saidev.com [207.67.52.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA19012
          for ; Fri, 19 Dec 1997 06:09:48 -0800 (PST)
          (envelope-from derek@cozumel.saidev.com)
Received: (from derek@localhost) by cozumel.saidev.com (8.7.1/8.7.1) id IAA05556; Fri, 19 Dec 1997 08:09:14 -0600 (CST)
Message-ID: <19971219080913.17939@saidev.com>
Date: Fri, 19 Dec 1997 08:09:13 -0600
From: Derek Inksetter 
To: freebsd-hackers@freebsd.org
Subject: ppp multi-device?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

How much interest is there in making user-mode ppp handle multiple devices
for dial-out?  My company uses ppp with "ip aliasing" and some
modifications to deal with multiple modems.  basically our ppp.conf has a
line that looks like this:

set device /dev/cuaa0,/dev/cuaa1,...

A setup like this, coupled with setting the box up as a gateway, allows our
office to support several customers (accessible only through PPP) with a
limited number of dial-out modems.  My company's been using this for close
to a year, and I can attest to its stability, at least in our case.

Let me know what you think.

Derek

(Here's a patch to the -current ppp.  Caveat: This is a re-write for
current. My office is running on 2.1.5)

diff -c ./command.c ../ppp/command.c
*** ./command.c	Wed Dec 17 22:47:41 1997
--- ../ppp/command.c	Fri Dec 19 07:46:01 1997
***************
*** 1347,1356 ****
        LogPrintf(LogWARN, "Cannot change device to \"%s\" when \"%s\" is open\n",
                  argp, VarDevice);
      else {
!       strncpy(VarDevice, argp, sizeof(VarDevice) - 1);
!       VarDevice[sizeof(VarDevice) - 1] = '\0';
!       VarBaseDevice = strrchr(VarDevice, '/');
!       VarBaseDevice = VarBaseDevice ? VarBaseDevice + 1 : "";
      }
      break;
    case VAR_ACCMAP:
--- 1347,1354 ----
        LogPrintf(LogWARN, "Cannot change device to \"%s\" when \"%s\" is open\n",
                  argp, VarDevice);
      else {
!       strncpy(VarDeviceList, argp, sizeof(VarDeviceList) - 1);
!       VarDeviceList[sizeof(VarDeviceList) - 1] = '\0';
      }
      break;
    case VAR_ACCMAP:
***************
*** 1421,1427 ****
    {"ctsrts", NULL, SetCtsRts, LOCAL_AUTH,
    "Use CTS/RTS modem signalling", "set ctsrts [on|off]"},
    {"device", "line", SetVariable, LOCAL_AUTH, "Set modem device name",
!   "set device|line device-name", (const void *) VAR_DEVICE},
    {"dfilter", NULL, SetDfilter, LOCAL_AUTH,
    "Set demand filter", "set dfilter ..."},
    {"dial", NULL, SetVariable, LOCAL_AUTH,
--- 1419,1425 ----
    {"ctsrts", NULL, SetCtsRts, LOCAL_AUTH,
    "Use CTS/RTS modem signalling", "set ctsrts [on|off]"},
    {"device", "line", SetVariable, LOCAL_AUTH, "Set modem device name",
!   "set device|line device-name[,device-name]", (const void *) VAR_DEVICE},
    {"dfilter", NULL, SetDfilter, LOCAL_AUTH,
    "Set demand filter", "set dfilter ..."},
    {"dial", NULL, SetVariable, LOCAL_AUTH,
diff -c ./modem.c ../ppp/modem.c
*** ./modem.c	Wed Dec 17 22:47:42 1997
--- ../ppp/modem.c	Thu Dec 18 20:33:24 1997
***************
*** 434,439 ****
--- 434,441 ----
    int oldflag;
    char *host, *port;
    char *cp;
+   char tmpDeviceList[sizeof(VarDeviceList)];
+   char *tmpDevice;
  
    if (modem >= 0)
      LogPrintf(LogDEBUG, "OpenModem: Modem is already open!\n");
***************
*** 464,507 ****
        return modem = 0;
      }
    } else {
!     if (strncmp(VarDevice, "/dev/", 5) == 0) {
!       if (LockModem() == -1)
!         return (-1);
!       modem = ID0open(VarDevice, O_RDWR | O_NONBLOCK);
!       if (modem < 0) {
! 	LogPrintf(LogERROR, "OpenModem failed: %s: %s\n", VarDevice,
! 		  strerror(errno));
! 	UnlockModem();
! 	return (-1);
!       }
!       HaveModem();
!       LogPrintf(LogDEBUG, "OpenModem: Modem is %s\n", VarDevice);
!     } else {
!       /* PPP over TCP */
!       cp = strchr(VarDevice, ':');
!       if (cp) {
! 	*cp = '\0';
! 	host = VarDevice;
! 	port = cp + 1;
! 	if (*host && *port) {
! 	  modem = OpenConnection(host, port);
! 	  *cp = ':';		/* Don't destroy VarDevice */
! 	  if (modem < 0)
  	    return (-1);
!           HaveModem();
!           LogPrintf(LogDEBUG, "OpenModem: Modem is socket %s\n", VarDevice);
  	} else {
! 	  *cp = ':';		/* Don't destroy VarDevice */
! 	  LogPrintf(LogERROR, "Invalid host:port: \"%s\"\n", VarDevice);
  	  return (-1);
  	}
-       } else {
- 	LogPrintf(LogERROR,
- 		  "Device (%s) must be in /dev or be a host:port pair\n",
- 		  VarDevice);
- 	return (-1);
        }
      }
    }
  
    /*
--- 466,527 ----
        return modem = 0;
      }
    } else {
!     strncpy(tmpDeviceList, VarDeviceList, sizeof(tmpDeviceList));
!     tmpDeviceList[sizeof(tmpDeviceList)-1] = '\0';
! 
!     for(tmpDevice=strtok(tmpDeviceList, ","); tmpDevice && (modem < 0);
! 	tmpDevice=strtok(NULL,",")) {
!       strncpy(VarDevice, tmpDevice, sizeof(VarDevice));
!       VarDevice[sizeof(VarDevice)-1]= '\0';
!       VarBaseDevice = strrchr(VarDevice, '/');
!       VarBaseDevice = VarBaseDevice ? VarBaseDevice + 1 : "";
! 
!       if (strncmp(VarDevice, "/dev/", 5) == 0) {
! 	if (LockModem() == -1) {
! 	  modem = -1;
! 	}
! 	else {
! 	  modem = ID0open(VarDevice, O_RDWR | O_NONBLOCK);
! 	  if (modem < 0) {
! 	    LogPrintf(LogERROR, "OpenModem failed: %s: %s\n", VarDevice,
! 		      strerror(errno));
! 	    UnlockModem();
! 	    modem = -1;
! 	  }
! 	  else {
! 	    HaveModem();
! 	    LogPrintf(LogDEBUG, "OpenModem: Modem is %s\n", VarDevice);
! 	  }
! 	}
!       } else {
! 	/* PPP over TCP */
! 	cp = strchr(VarDevice, ':');
! 	if (cp) {
! 	  *cp = '\0';
! 	  host = VarDevice;
! 	  port = cp + 1;
! 	  if (*host && *port) {
! 	    modem = OpenConnection(host, port);
! 	    *cp = ':';		/* Don't destroy VarDevice */
! 	    if (modem < 0)
! 	      return (-1);
! 	    HaveModem();
! 	    LogPrintf(LogDEBUG, "OpenModem: Modem is socket %s\n", VarDevice);
! 	  } else {
! 	    *cp = ':';		/* Don't destroy VarDevice */
! 	    LogPrintf(LogERROR, "Invalid host:port: \"%s\"\n", VarDevice);
  	    return (-1);
! 	  }
  	} else {
! 	  LogPrintf(LogERROR,
! 		    "Device (%s) must be in /dev or be a host:port pair\n",
! 		    VarDevice);
  	  return (-1);
  	}
        }
      }
+ 
+     if (modem < 0) return modem;
    }
  
    /*
diff -c ./ppp.8 ../ppp/ppp.8
*** ./ppp.8	Wed Dec 17 22:47:42 1997
--- ../ppp/ppp.8	Fri Dec 19 07:45:04 1997
***************
*** 2077,2084 ****
  .It set ctsrts
  This sets hardware flow control and is the default.
  
! .It set device|line value
! This sets the device to which
  .Nm
  will talk to the given
  .Dq value .
--- 2077,2084 ----
  .It set ctsrts
  This sets hardware flow control and is the default.
  
! .It set device|line value[,value...]
! This sets the device(s) to which
  .Nm
  will talk to the given
  .Dq value .
***************
*** 2098,2104 ****
  .Dq port .
  Refer to the section on
  .Em PPP OVER TCP
! above for further details.
  
  .It set dial chat-script
  This specifies the chat script that will be used to dial the other
--- 2098,2109 ----
  .Dq port .
  Refer to the section on
  .Em PPP OVER TCP
! above for further details.  If multiple
! .Dq values
! are specified,
! .Nm
! will attempt to open each one in turn until it succeeds or runs out of
! devices.
  
  .It set dial chat-script
  This specifies the chat script that will be used to dial the other
diff -c ./vars.c ../ppp/vars.c
*** ./vars.c	Fri Dec 12 18:47:01 1997
--- ../ppp/vars.c	Thu Dec 18 22:28:13 1997
***************
*** 73,79 ****
  struct pppvars pppVars = {
    DEF_MRU, DEF_MTU, 0, MODEM_SPEED, CS8, MODEM_CTSRTS, 180, 30, 3,
    RECONNECT_TIMER, RECONNECT_TRIES, REDIAL_PERIOD,
!   NEXT_REDIAL_PERIOD, 1, 1, MODEM_DEV, BASE_MODEM_DEV,
    OPEN_ACTIVE, LOCAL_NO_AUTH, 0
  };
  
--- 73,79 ----
  struct pppvars pppVars = {
    DEF_MRU, DEF_MTU, 0, MODEM_SPEED, CS8, MODEM_CTSRTS, 180, 30, 3,
    RECONNECT_TIMER, RECONNECT_TRIES, REDIAL_PERIOD,
!   NEXT_REDIAL_PERIOD, 1, 1, MODEM_DEV, "", BASE_MODEM_DEV,
    OPEN_ACTIVE, LOCAL_NO_AUTH, 0
  };
  
diff -c ./vars.h ../ppp/vars.h
*** ./vars.h	Wed Dec  3 17:28:02 1997
--- ../ppp/vars.h	Thu Dec 18 20:49:45 1997
***************
*** 70,75 ****
--- 70,76 ----
    int redial_next_timeout;	/* Redial next timeout value */
    int dial_tries;		/* Dial attempts before giving up, 0 == inf */
    int loopback;			/* Turn around packets addressed to me */
+   char modem_devlist[500];	/* Comma-separated list of devices */
    char modem_dev[40];		/* Name of device / host:port */
    const char *base_modem_dev;	/* Pointer to base of modem_dev */
    int open_mode;		/* LCP open mode */
***************
*** 102,107 ****
--- 103,109 ----
  #define VarMRU			pppVars.var_mru
  #define VarPrefMTU		pppVars.pref_mtu
  #define	VarDevice		pppVars.modem_dev
+ #define	VarDeviceList		pppVars.modem_devlist
  #define	VarBaseDevice		pppVars.base_modem_dev
  #define	VarSpeed		pppVars.modem_speed
  #define	VarParity		pppVars.modem_parity

From owner-freebsd-hackers  Fri Dec 19 06:23:57 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA19938
          for hackers-outgoing; Fri, 19 Dec 1997 06:23:57 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp6.portal.net.au [202.12.71.106])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA19925
          for ; Fri, 19 Dec 1997 06:23:45 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id AAA00414;
	Sat, 20 Dec 1997 00:47:34 +1030 (CST)
Message-Id: <199712191417.AAA00414@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Michael Hancock 
cc: John-Mark Gurney ,
        freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory... 
In-reply-to: Your message of "Fri, 19 Dec 1997 16:18:42 +0900."
              
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 20 Dec 1997 00:47:33 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > > Forget the btree model; it's not going to fly in the face of a direct 
> > > reference approach. 
...
> > when did I ever say that we should in the long run choose using a
> > btree over the "correct" way to do it??  I only said it would require
> 
> Hashing for example is very good in the kernel, even in cases where you
> think btrees would be better.  The reasoning is along the lines of what
> Koshy was talking about.  If you can abstract things well enough so that
> you can make a change later on very easily, by all means carry on. 
> Someone will find a use for your Btrees elsewhere most likely. 

... but of course dereferencing a pointer (hardly) requires any 
parallelisation.  Why go to all this complexity when all you are 
interesting in doing is taking an opaque token and obtaining the 
address of a (reasonably non-motile) structure?

Perhaps I'm missing something; let's take the opposite tack.  What 
advantages (in real terms) do we gain by storing the address of the 
control structure in some fashion and then requiring a token in order 
to obtain it?  Is this advantage significant in the face of the not 
insubstantial performance penalties?

mike



From owner-freebsd-hackers  Fri Dec 19 07:05:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA22479
          for hackers-outgoing; Fri, 19 Dec 1997 07:05:55 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from nash.pr.mcs.net (nash.pr.mcs.net [204.95.47.72])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA22445;
          Fri, 19 Dec 1997 07:05:36 -0800 (PST)
          (envelope-from alex@nash.pr.mcs.net)
Received: (from alex@localhost)
	by nash.pr.mcs.net (8.8.7/8.8.7) id JAA25458;
	Fri, 19 Dec 1997 09:04:02 -0600 (CST)
	(envelope-from alex)
Message-Id: <199712191504.JAA25458@nash.pr.mcs.net>
Date: Fri, 19 Dec 1997 09:04:02 -0600 (CST)
From: Alex Nash 
Reply-To: nash@mcs.com
Subject: Re: Wine success story
To: kuku@gilberto.physik.RWTH-Aachen.DE
cc: se@freebsd.org, kuku@gilberto, ports@freebsd.org,
        freebsd-hackers@freebsd.org
In-Reply-To: <19971219084412.46153@gil.physik.rwth-aachen.de>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On 19 Dec, Christoph Kukulies wrote:
> Actually, the reason why I tried wine againe was that I was in seek of
> running some applications , a 8051 cross compiler, under DOS (emu or
> whatever).
> 
> pcemu though running fine turned out to be insufficient since
> it doesn't support DPMI resp. 386 architecture.
> 
> So my hopes concentrated on running a DOS Command Prompt box under Wine.
> It doesn't seem to work with me here.

Try bochs, its emulation of a 386 is good enough to run Windows 95, so
there's a good chance it will run your cross compiler (albeit slowly).

You can get it from the ports tree or from http://world.std.com/~bochs.

Alex



From owner-freebsd-hackers  Fri Dec 19 07:41:34 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA24464
          for hackers-outgoing; Fri, 19 Dec 1997 07:41:34 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from hotmail.com ([207.82.251.5])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA24448
          for ; Fri, 19 Dec 1997 07:41:29 -0800 (PST)
          (envelope-from sumankaji@hotmail.com)
Received: (qmail 25487 invoked by uid 0); 19 Dec 1997 15:33:43 -0000
Message-ID: <19971219153343.25486.qmail@hotmail.com>
Received: from 198.205.63.135 by www.hotmail.com with HTTP;
	Fri, 19 Dec 1997 07:33:43 PST
X-Originating-IP: [198.205.63.135]
From: "Suman Kaji Manandhar" 
To: freebsd-hackers@freebsd.org
Subject: I want to join a group to develop s/w
Content-Type: text/plain
Date: Fri, 19 Dec 1997 07:33:43 PST
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,
I've in the past worked with BSDI 2.2 (Intel) to develop network
drivers and stack. So if you need somebody who knows the internal
of BSD, count me in.
>>Suman

Tel.:(703)-858-1264 

(evng. in weekdays, and in weekends any time).

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From owner-freebsd-hackers  Fri Dec 19 07:52:31 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA25298
          for hackers-outgoing; Fri, 19 Dec 1997 07:52:31 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA25293
          for ; Fri, 19 Dec 1997 07:52:24 -0800 (PST)
          (envelope-from cy@cschuber.net.gov.bc.ca)
Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id HAA13230 for ; Fri, 19 Dec 1997 07:52:22 -0800 (PST)
Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com"
 via SMTP by passer.osg.gov.bc.ca, id smtpdaaDvga; Fri Dec 19 07:52:19 1997
Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id HAA01050 for ; Fri, 19 Dec 1997 07:52:17 -0800 (PST)
Message-Id: <199712191552.HAA01050@cwsys.cwsent.com>
Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys"
 via SMTP by localhost.cwsent.com, id smtpd001040; Fri Dec 19 15:51:24 1997
X-Mailer: exmh version 2.0zeta 7/24/97
Reply-to: Cy Schubert - ITSD Open Systems Group 
From: Cy Schubert - ITSD Open Systems Group 
X-Sender: cy
To: freebsd-hackers@freebsd.org
Subject: Nullfs Problems
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Dec 1997 07:51:24 -0800
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I may have a solution for the nullfs, umapfs, and unionfs panics.  The panics 
are caused by a divide by zero trap when bsize is zero.  I've tested this 
against the ftp server problem posted a short while back.  I've been testing 
this for a short while and since I am not a FreeBSD kernel hacker (my 
background was originally MVS kernel), I'd like to get some opinions about 
this before submitting a PR to implement this.

--- src/sys/vm/vnode_pager.c.orig2	Sun Dec  7 13:11:03 1997
+++ src/sys/vm/vnode_pager.c	Fri Dec 19 06:30:27 1997
@@ -231,10 +231,12 @@
 	blocksperpage = 0;
 	if (pagesperblock > 0) {
 		reqblock = pindex / pagesperblock;
-	} else {
+	} else if (bsize > 0)  {
 		blocksperpage = (PAGE_SIZE / bsize);
 		reqblock = pindex * blocksperpage;
-	}
+	} else
+		return FALSE;
+
 	err = VOP_BMAP(vp, reqblock, (struct vnode **) 0, &bn,
 		after, before);
 	if (err)



Regards,                       Phone:  (250)387-8437
Cy Schubert                      Fax:  (250)387-5766
UNIX Support                   OV/VM:  BCSC02(CSCHUBER)
ITSD                          BITNET:  CSCHUBER@BCSC02.BITNET
Government of BC            Internet:  cschuber@uumail.gov.bc.ca
                                       Cy.Schubert@gems8.gov.bc.ca

		"Quit spooling around, JES do it."






From owner-freebsd-hackers  Fri Dec 19 09:30:30 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA01408
          for hackers-outgoing; Fri, 19 Dec 1997 09:30:30 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 JAA01376
          for ; Fri, 19 Dec 1997 09:30:07 -0800 (PST)
          (envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA25397
  (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Fri, 19 Dec 1997 18:29:55 +0100
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id SAA00300; Fri, 19 Dec 1997 18:24:24 +0100 (MET)
From: Wilko Bulte 
Message-Id: <199712191724.SAA00300@yedi.iaf.nl>
Subject: Re: volume control on SCSI Toshiba CDdrive
To: wilko@yedi.iaf.nl (Wilko Bulte)
Date: Fri, 19 Dec 1997 18:24:24 +0100 (MET)
Cc: syssgm@dtir.qld.gov.au, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199712181811.TAA13146@yedi.iaf.nl> from "Wilko Bulte" at Dec 18, 97 07:11:15 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 Wilko Bulte wrote...
> As Stephen McKay wrote...
> > 
> > On Wednesday, 17th December 1997, Wilko Bulte wrote:
> > 
> > >Well it took some time, but I haven't given up:
> > >
> > >TOSHIBA CD-ROM XM-5701TA 0557
> > >
> > >is a firmware rev that has *working* audio control...
> > 
> > This is good news!  But how do we know it's *only* the firmware that is
> > different?  Maybe it's new firmware that just happens to be present on a
> 
> Well, I'm going to try to copy the eprom and put the copy in my own drive.
> This will prove whether it's hardware or firmware (I hope...)

I have transplanted the aforementioned firmware into my own drive, and
this fixes the problem altogether. There is no hardware problem, just the
firmware was broken.

> > >As far as getting in touch with a contact in Toshiba I did not have as much
> > >luck. 
> > 
> > Sigh.  I know nobody with such contacts.  But I'll hassle everyone that I
> > think might know someone who knows someone!

Maybe someone with a drive that is still under warranty can push Toshiba a
bit? I'd settle for a firmware image being made available on their Website
or something like that.

Wilko
_     ______________________________________________________________________
 |   / o / /  _  Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko
 |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
----------------  Support your local daemons: run [Free,Net]BSD Unix  ------

From owner-freebsd-hackers  Fri Dec 19 12:20:33 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA14748
          for hackers-outgoing; Fri, 19 Dec 1997 12:20:33 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 MAA14737
          for ; Fri, 19 Dec 1997 12:20:17 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id MAA13747;
	Fri, 19 Dec 1997 12:12:32 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd013745; Fri Dec 19 12:12:28 1997
Message-ID: <349AD486.41C67EA6@whistle.com>
Date: Fri, 19 Dec 1997 12:09:42 -0800
From: Julian Elischer 
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Derek Inksetter 
CC: freebsd-hackers@FreeBSD.ORG
Subject: Re: ppp multi-device?
References: <19971219080913.17939@saidev.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Derek Inksetter wrote:
> 
> How much interest is there in making user-mode ppp handle multiple devices
> for dial-out?  My company uses ppp with "ip aliasing" and some
> modifications to deal with multiple modems.  basically our ppp.conf has a
> line that looks like this:
> 
> set device /dev/cuaa0,/dev/cuaa1,...
> 

see mpd
(in ports)

From owner-freebsd-hackers  Fri Dec 19 12:54:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA17395
          for hackers-outgoing; Fri, 19 Dec 1997 12:54:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from cozumel.saidev.com (cozumel.saidev.com [207.67.52.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17376
          for ; Fri, 19 Dec 1997 12:54:08 -0800 (PST)
          (envelope-from derek@cozumel.saidev.com)
Received: (from derek@localhost) by cozumel.saidev.com (8.7.1/8.7.1) id OAA08097; Fri, 19 Dec 1997 14:53:34 -0600 (CST)
Message-ID: <19971219145334.52794@saidev.com>
Date: Fri, 19 Dec 1997 14:53:34 -0600
From: Derek Inksetter 
To: Julian Elischer 
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: ppp multi-device?
References: <19971219080913.17939@saidev.com> <349AD486.41C67EA6@whistle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88
In-Reply-To: <349AD486.41C67EA6@whistle.com>; from Julian Elischer on Fri, Dec 19, 1997 at 12:09:42PM -0800
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Julian Elischer allegedly wrote:
> Derek Inksetter wrote:
> > 
> > How much interest is there in making user-mode ppp handle multiple devices
> > for dial-out?  My company uses ppp with "ip aliasing" and some
> > modifications to deal with multiple modems.  basically our ppp.conf has a
> > line that looks like this:
> > 
> > set device /dev/cuaa0,/dev/cuaa1,...
> > 
> 
> see mpd
> (in ports)

mpd, as I understand it, is a true multilink PPP package, no?  What I have
is much simpler...if a device is busy it just spins around to the next one.
It still uses a single device at a time, it just gets to choose from a list.
-- 
Derek Inksetter 
"The sooner you get behind, the more time you'll have to catch up" --Unknown

From owner-freebsd-hackers  Fri Dec 19 14:01:20 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA23238
          for hackers-outgoing; Fri, 19 Dec 1997 14:01:20 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23222
          for ; Fri, 19 Dec 1997 14:01:13 -0800 (PST)
          (envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
	by smtp01.primenet.com (8.8.8/8.8.8) id PAA00688;
	Fri, 19 Dec 1997 15:01:12 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
 via SMTP by smtp01.primenet.com, id smtpd000664; Fri Dec 19 15:01:10 1997
Received: (from tlambert@localhost)
	by usr05.primenet.com (8.8.5/8.8.5) id PAA17466;
	Fri, 19 Dec 1997 15:01:06 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712192201.PAA17466@usr05.primenet.com>
Subject: Re: converting drivers to dynamic memory...
To: julian@whistle.com (Julian Elischer)
Date: Fri, 19 Dec 1997 22:01:05 +0000 (GMT)
Cc: gurney_j@resnet.uoregon.edu, mike@smith.net.au, avalon@coombs.anu.edu.au,
        freebsd-hackers@FreeBSD.ORG
In-Reply-To: <3499E71A.167EB0E7@whistle.com> from "Julian Elischer" at Dec 18, 97 07:16:42 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> The AIM is that after a cut-over to devfs,
> drivers could be modified to take more generalised arguments.
> 
> the minor number can be interpretted as a cookie that can be used to
> look something up in a hash-table or similar.
> 
> That's what I do in slice/slice_device.c
> the minor number there is just a cookie, that is used to find 
> a softc structure. In a more generalised situation.
> the minor could be used to find a small structure
> which in turn contains a pointer to the softc, plus a unique
> sub-identifier.
> 
> eventually, the minor number might be interpretted directly as a 
> pointer to this structure.
> 
> Since teh minor number is supplied by the driver and never 
> alterable by the user, this is safe. it might also be 
> possible to make it not print out at all in 'ls'
> as that would just be confusing.
> 
> What I'm saying is that the minor number can be interpretted
> as the driver sees fit, however in the current system it must 
> be a static thing and that is very limiting. (not to mention 
> we only have 24 bits)

One thing that kind of concerns me... there will remain a need to
be able to NFS export statically generated device nodes of the old
style.

FreeBSD won't need them, but... you could be net-booting a diskless
or dataless client off a FreeBSD box.  Such a client would need the
traditional device nodes.

This is more an issue to deal with mknod, and not necessarily through
the provision of a specfs hook in your FS that you are exporting (ie:
it's a referential issue that FreeBSD itself can ignore, so long as
mknod can make the nodes that the client can interpret through its
own specfs).


					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 Dec 19 14:15:30 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA24512
          for hackers-outgoing; Fri, 19 Dec 1997 14:15:30 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 OAA24440
          for ; Fri, 19 Dec 1997 14:15:05 -0800 (PST)
          (envelope-from imp@village.org)
Received: from harmony [10.0.0.6] 
	by rover.village.org with esmtp (Exim 1.71 #1)
	id 0xjAhC-0002D8-00; Fri, 19 Dec 1997 15:15:02 -0700
Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id PAA00275 for ; Fri, 19 Dec 1997 15:14:46 -0700 (MST)
Message-Id: <199712192214.PAA00275@harmony.village.org>
To: hackers@freebsd.org
Subject: crash help
Date: Fri, 19 Dec 1997 15:14:46 -0700
From: Warner Losh 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


I have an odd crash that I need some help tracking down.

I have a PPro with a built in aic7880, ide controller, etc.  today for
the first time I put an ide drive into the machine.  since I wanted to
see what on it (and hopefully to mount it and do a make install).

when I did an fsck on the drive, it fixed a few problems and then it
paniced.  so i tried it again, and got an identical panic.  I'm
running 
uname -a

FreeBSD harmony.village.org 3.0-CURRENT 
FreeBSD 3.0-CURRENT #0: Sun Dec 14 16:50:40 MST 1997
imp@harmony.village.org:/home/imp/FreeBSD/src/sys/compile/HARMONY
i386

these sources were checked out just before the build from my cvs tree
here that is updated via ctm.

does this crash look familiar to anybody?  any ideas where to go from
here?  Thanks for any help you might be able to give me.  I can
provide additional inforation if that is needed.

Warner

sudo gdb -k /var/crash/*.0
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd), 
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
IdlePTD 26d000
current pcb at 2446fc
panic: unknown/reserved trap
#0  0xf011544f in boot ()
(kgdb) where
#0  0xf011544f in boot ()
#1  0xf011571e in panic ()
#2  0xf01dba3e in trap_fatal ()
#3  0xf01db25a in trap ()
#4  0xf021e95b in wdstart ()
#5  0xf021e2c2 in wdstrategy ()
#6  0xf0113232 in physio ()
#7  0xf01133aa in rawwrite ()
#8  0xf013e61b in spec_write ()
#9  0xf01bad0d in ufsspec_write ()
#10 0xf01bb211 in ufs_vnoperatespec ()
#11 0xf01386f7 in vn_write ()
#12 0xf011ce4b in write ()
#13 0xf01dbcc3 in syscall ()
#14 0x28c25 in ?? ()
#15 0xa6d6 in ?? ()
#16 0xa848 in ?? ()
#17 0x4657 in ?? ()
#18 0x3dc1 in ?? ()
#19 0x107d in ?? ()

% dmesg

Copyright (c) 1992-1997 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California. All rights reserved.
FreeBSD 3.0-CURRENT #0: Sun Dec 14 16:50:40 MST 1997
    imp@harmony.village.org:/home/imp/FreeBSD/src/sys/compile/HARMONY
CPU: Pentium Pro (199.43-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x617  Stepping=7
  Features=0xfbff
real memory  = 67108864 (65536K bytes)
avail memory = 62410752 (60948K bytes)
Probing for devices on PCI bus 0:
Correcting Natoma config for non-SMP
chip0:  rev 0x02 on pci0.0.0
chip1:  rev 0x01 on pci0.7.0
ide_pci0:  rev 0x00 on pci0.7.1
ahc0:  rev 0x00 int a irq 10 on pci0.16.0
ahc0: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs
ahc0: waiting for scsi devices to settle
scbus0 at ahc0 bus 0
ahc0:A:0: refuses WIDE negotiation.  Using 8bit transfers
ahc0: target 0 Tagged Queuing Device
sd0 at scbus0 target 0 lun 0
sd0:  type 0 fixed SCSI 2
sd0: Direct-Access 3067MB (6281856 512 byte sectors)
ahc0:A:1: refuses WIDE negotiation.  Using 8bit transfers
ahc0: target 1 Tagged Queuing Device
sd1 at scbus0 target 1 lun 0
sd1:  type 0 removable SCSI 2
sd1: Direct-Access 
sd1: ILLEGAL REQUEST asc:24,0 Invalid field in CDB
sd1 could not mode sense (4). Using ficticious geometry
1021MB (2091050 512 byte sectors)
de0:  rev 0x11 int a irq 9 on pci0.18.0
de0: 21041 [10Mb/s] pass 1.1
de0: address 00:c0:f0:14:e1:b4
vga0:  rev 0x06 int a irq 11 on pci0.19.0
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
ed0 not found at 0x280
fe0 not found at 0x300
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
lpt0 at 0x378-0x37f irq 7 on isa
lpt0: Interrupt-driven port
lp0: TCP/IP capable interface
lpt1 not found
mse0 not found at 0x23c
psm0 not found at 0x60
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
wdc0 not found at 0x1f0
wdc1 at 0x170-0x177 irq 15 on isa
wdc1: unit 0 (wd2): 
wd2: 329MB (675450 sectors), 790 cyls, 15 heads, 57 S/T, 512 B/S
bt0 not found at 0x330
uha0 not found at 0x330
aha0 not found at 0x330
aic0 at 0x340-0x35f irq 11 on isa
aic0: waiting for scsi devices to settle
scbus1 at aic0 bus 0
nca0 not found at 0x1f88
nca1 not probed due to I/O address conflict with aic0 at 0x350
sea0 not found
wt0 not found at 0x300
mcd0 not found at 0x300
matcdc0 not found at 0x230
scd0 not found at 0x230
ie0: unknown board_id: f000
ie0 not found at 0x300
ep0 not found at 0x300
ex0 not found
le0 not found at 0x300
lnc0 not found at 0x280
npx0 on motherboard
npx0: INT 16 interface
de0: enabling 10baseT port
Initializing PC-card drivers: aic ed ep fe sio
changing root device to sd0a
WARNING: / was not properly dismounted.

From owner-freebsd-hackers  Fri Dec 19 14:21:59 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA25216
          for hackers-outgoing; Fri, 19 Dec 1997 14:21:59 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 OAA25200
          for ; Fri, 19 Dec 1997 14:21:47 -0800 (PST)
          (envelope-from phk@critter.freebsd.dk)
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 XAA04165
	for ; Fri, 19 Dec 1997 23:18:45 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: hackers@freebsd.org
Subject: NTP stratum 1 with GPS on FreeBSD
From: Poul-Henning Kamp 
Date: Fri, 19 Dec 1997 23:18:45 +0100
Message-ID: <4163.882569925@critter.freebsd.dk>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


If anybody is interested in getting their FreeBSD box to run as a
stratum 1 NTP server using GPS, I have been playing with a Motorola
"UT Oncore" evaluation kit, which so far gives excellent results.

Price: $1K here in Denmark.

It Interfaces via one COM port and one LPT port (for the PPS signal).

Send me email if you are interested in this.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-hackers  Fri Dec 19 14:30:22 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA26081
          for hackers-outgoing; Fri, 19 Dec 1997 14:30:22 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 OAA26068
          for ; Fri, 19 Dec 1997 14:30:16 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id OAA18269
	for ; Fri, 19 Dec 1997 14:27:50 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd018261; Fri Dec 19 14:27:43 1997
Message-ID: <349AF439.446B9B3D@whistle.com>
Date: Fri, 19 Dec 1997 14:24:57 -0800
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: FreeBSD CVS problem: /etc/protocols
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

/etc/protocols never got branched for RELENG_2_2
the tag RELENG_2_2 is a non branch tag

I could fix this if I'm given the ok..
the question is what to do about 2.2.5 which used the mainline 1.7

I guess I could retag that to be a correct version.
(same data, differnt rev number.)

anyone care to fix this?
(or if not, can I do so?)

p.s. /etc/protocols doesn't check out for me in -current..
I'm tryingto work out why..

julian

From owner-freebsd-hackers  Fri Dec 19 14:53:32 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA28538
          for hackers-outgoing; Fri, 19 Dec 1997 14:53:32 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28523
          for ; Fri, 19 Dec 1997 14:53:24 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id XAA04467
	for freebsd-hackers@freebsd.org; Fri, 19 Dec 1997 23:53:19 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id XAA26589;
	Fri, 19 Dec 1997 23:42:28 +0100 (MET)
Date: Fri, 19 Dec 1997 23:42:28 +0100 (MET)
Message-Id: <199712192242.XAA26589@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <3.0.32.19971216193810.00b3b480@etinc.com>
    <199712172332.XAA08846@awfulhak.demon.co.uk>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: ifconfig reports bogus netmask
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Brian Somers  wrote:

> I agree, and I'll implement the change unless someone has a good 
> reason not to..... any takers ?

I think it's really best to just not display the netmask in the output
of ifconfig iff IFF_POINTOPOINT is set.

Routes to the remote end apart from the implied host route seem to be
dangerous to me, and they break the current behaviour (i.e. could
cause surprises for people who are used to how it's done now).  It's
not always that the IP address of the remote end is indeed identical
with the remote network address.

-- 
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 Dec 19 14:53:56 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA28572
          for hackers-outgoing; Fri, 19 Dec 1997 14:53:56 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28552
          for ; Fri, 19 Dec 1997 14:53:37 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id XAA04469
	for freebsd-hackers@freebsd.org; Fri, 19 Dec 1997 23:53:27 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id XAA26606;
	Fri, 19 Dec 1997 23:50:34 +0100 (MET)
Date: Fri, 19 Dec 1997 23:50:34 +0100 (MET)
Message-Id: <199712192250.XAA26606@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <199712150834.JAA03985@uriah.heep.sax.de>
    
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: 132 Column mode on VGA Consoles
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

hm@kts.org (Hellmuth Michaelis) wrote:

>> This used to be possible for some (now rather obsolete) hardware in
>> the pcvt console driver.
> 
> Obsolete ? No !

I didn't have much luck with any recent S3 chip except the old
928 in my old EISA card.
-- 
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 Dec 19 14:58:45 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA29193
          for hackers-outgoing; Fri, 19 Dec 1997 14:58:45 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28517
          for ; Fri, 19 Dec 1997 14:53:17 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id XAA04459
	for freebsd-hackers@freebsd.org; Fri, 19 Dec 1997 23:53:12 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id XAA26562;
	Fri, 19 Dec 1997 23:33:32 +0100 (MET)
Date: Fri, 19 Dec 1997 23:33:32 +0100 (MET)
Message-Id: <199712192233.XAA26562@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: 
    <199712190401.UAA23662@bubba.whistle.com>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: close() on a modem taking a long time?
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Archie Cobbs  wrote:

> Serial ports usually wait for output to finish on a close (I think).
> You may be able to disable this feature.. see man termios (HUPCL?).

Nope, that's not the solution.  comcontrol(8) is, you can set
drainwait to a number of seconds you prefer.

It's probably better to fix the application to wait until all output
has been drained.

-- 
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 Dec 19 15:38:19 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA01938
          for hackers-outgoing; Fri, 19 Dec 1997 15:38:19 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01545;
          Fri, 19 Dec 1997 15:32:51 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA28354;
	Fri, 19 Dec 1997 16:32:50 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id QAA22850; Fri, 19 Dec 1997 16:32:49 -0700
Date: Fri, 19 Dec 1997 16:32:49 -0700
Message-Id: <199712192332.QAA22850@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: hackers@freebsd.org
Subject: Re: NTP stratum 1 with GPS on FreeBSD
In-Reply-To: <4163.882569925@critter.freebsd.dk>
References: <4163.882569925@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

> If anybody is interested in getting their FreeBSD box to run as a
> stratum 1 NTP server using GPS, I have been playing with a Motorola
> "UT Oncore" evaluation kit, which so far gives excellent results.

How does it intergate with ntpd?  Did you have to write the code to have
it talk to ntpd, or was that part of the kit.


Nate

From owner-freebsd-hackers  Fri Dec 19 16:12:07 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA04224
          for hackers-outgoing; Fri, 19 Dec 1997 16:12:07 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04169
          for ; Fri, 19 Dec 1997 16:11:57 -0800 (PST)
          (envelope-from michaelh@cet.co.jp)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id AAA10445; Sat, 20 Dec 1997 00:10:37 GMT
Date: Sat, 20 Dec 1997 09:10:37 +0900 (JST)
From: Michael Hancock 
To: Mike Smith 
cc: John-Mark Gurney ,
        freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory... 
In-Reply-To: <199712191417.AAA00414@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

On Sat, 20 Dec 1997, Mike Smith wrote:

> > > > Forget the btree model; it's not going to fly in the face of a direct 
> > > > reference approach. 
> ...
> > > when did I ever say that we should in the long run choose using a
> > > btree over the "correct" way to do it??  I only said it would require
> > 
> > Hashing for example is very good in the kernel, even in cases where you
> > think btrees would be better.  The reasoning is along the lines of what
> > Koshy was talking about.  If you can abstract things well enough so that
> > you can make a change later on very easily, by all means carry on. 
> > Someone will find a use for your Btrees elsewhere most likely. 
> 
> ... but of course dereferencing a pointer (hardly) requires any 
> parallelisation.  Why go to all this complexity when all you are 
> interesting in doing is taking an opaque token and obtaining the 
> address of a (reasonably non-motile) structure?

Sorry, I haven't been following the thread.  I jumped in when I noticed
talk about data structures.  If the structure is read-only then you don't
have a problem.

If it is volatile, then you do need to lock down structures and hashes are
good because you can just lock the bucket list header localizing
contention to the bucket.
 
> Perhaps I'm missing something; let's take the opposite tack.  What 
> advantages (in real terms) do we gain by storing the address of the 
> control structure in some fashion and then requiring a token in order 
> to obtain it?  Is this advantage significant in the face of the not 
> insubstantial performance penalties?

I think the opacity benefits are significant.  I also think that "some
fashion" is very important in the kernel.  People expect the kernel to
work correctly and perform very well.

Regards,


Mike Hancock

> mike
> 
> 

--
michaelh@cet.co.jp                                http://www.cet.co.jp
CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku,
Tokyo 105 Japan              Tel: +81-3-3437-1761 Fax: +81-3-3437-1766


From owner-freebsd-hackers  Fri Dec 19 16:16:02 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA04646
          for hackers-outgoing; Fri, 19 Dec 1997 16:16:02 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04620
          for ; Fri, 19 Dec 1997 16:15:51 -0800 (PST)
          (envelope-from michaelh@cet.co.jp)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id AAA10465; Sat, 20 Dec 1997 00:13:32 GMT
Date: Sat, 20 Dec 1997 09:13:32 +0900 (JST)
From: Michael Hancock 
To: John-Mark Gurney 
cc: A Joseph Koshy , freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory
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 Dec 1997, Michael Hancock wrote:

> Here's an interesting link which covers why some data structures are
> better than others for use in an OS kernel,
> http://www-dsg.stanford.edu/michaelg/.

Umm. Altavista gave me this link which is mostly broken, but backing up to
the top page and selecting Michael Greenwald gives me
http://www-dsg.stanford.edu/MichaelGreenwald.html which has the hypertext
version of his paper.

> Algorithms in C by Robert Sedgewick, a former student of Donald Knuth, is
> also pretty good.  The book is in the bibliography of the BSD book by
> McKusick, et al.  The book covers radix tries which are in the networking
> code.
> 
> Regards,
> 
> 
> Mike Hancock
> 
> 

--
michaelh@cet.co.jp                                http://www.cet.co.jp
CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku,
Tokyo 105 Japan              Tel: +81-3-3437-1761 Fax: +81-3-3437-1766


From owner-freebsd-hackers  Fri Dec 19 16:47:26 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA07080
          for hackers-outgoing; Fri, 19 Dec 1997 16:47:26 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from keaggy.canonware.com (canonware.com [206.184.206.112])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA07069;
          Fri, 19 Dec 1997 16:46:57 -0800 (PST)
          (envelope-from jasone@keaggy.canonware.com)
Received: from localhost (jasone@localhost)
	by keaggy.canonware.com (8.8.7/8.8.7) with SMTP id QAA03932;
	Fri, 19 Dec 1997 16:48:14 -0800 (PST)
	(envelope-from jasone@keaggy.canonware.com)
Date: Fri, 19 Dec 1997 16:48:14 -0800 (PST)
From: Jason Evans 
To: Poul-Henning Kamp 
cc: hackers@freebsd.org
Subject: Re: NTP stratum 1 with GPS on FreeBSD
In-Reply-To: <4163.882569925@critter.freebsd.dk>
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 Dec 1997, Poul-Henning Kamp wrote:
> If anybody is interested in getting their FreeBSD box to run as a
> stratum 1 NTP server using GPS, I have been playing with a Motorola
> "UT Oncore" evaluation kit, which so far gives excellent results.
> 
> Price: $1K here in Denmark.
> 
> It Interfaces via one COM port and one LPT port (for the PPS signal).
> 
> Send me email if you are interested in this.

Last summer I wrote some code to talk to a Trimble GPS receiver (in TSIP
mode) that extracts the necessary info to do this (among other things). 
Some of the code is relatively ugly, but the packet parser is very nice. 
If anyone wants to make one of these cards work, let me know, and I'll see
if I can find the code.  Of course, you could just use the NMEA format
with Trimble receivers, since you probably already have code for that... 

Jason


From owner-freebsd-hackers  Fri Dec 19 17:40:02 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA10011
          for hackers-outgoing; Fri, 19 Dec 1997 17:40:02 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09720;
          Fri, 19 Dec 1997 17:34:42 -0800 (PST)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id SAA29125;
	Fri, 19 Dec 1997 18:34:41 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id SAA23288; Fri, 19 Dec 1997 18:34:38 -0700
Date: Fri, 19 Dec 1997 18:34:38 -0700
Message-Id: <199712200134.SAA23288@mt.sri.com>
From: Nate Williams 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Jason Evans 
Cc: Poul-Henning Kamp , hackers@freebsd.org
Subject: Re: NTP stratum 1 with GPS on FreeBSD
In-Reply-To: 
References: <4163.882569925@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

> Last summer I wrote some code to talk to a Trimble GPS receiver (in TSIP
> mode) that extracts the necessary info to do this (among other
> things). 

I've got a Java class that does it as well, although it uses NMEA mode.
Does your code interface with the NTP daemon, since that's what I'm
missing.


Nate

From owner-freebsd-hackers  Fri Dec 19 18:01:22 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA10979
          for hackers-outgoing; Fri, 19 Dec 1997 18:01:22 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from keaggy.canonware.com (canonware.com [206.184.206.112])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA10970;
          Fri, 19 Dec 1997 18:01:10 -0800 (PST)
          (envelope-from jasone@keaggy.canonware.com)
Received: from localhost (jasone@localhost)
	by keaggy.canonware.com (8.8.7/8.8.7) with SMTP id SAA04247;
	Fri, 19 Dec 1997 18:02:22 -0800 (PST)
	(envelope-from jasone@keaggy.canonware.com)
Date: Fri, 19 Dec 1997 18:02:22 -0800 (PST)
From: Jason Evans 
To: Nate Williams 
cc: Poul-Henning Kamp , hackers@freebsd.org
Subject: Re: NTP stratum 1 with GPS on FreeBSD
In-Reply-To: <199712200134.SAA23288@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

On Fri, 19 Dec 1997, Nate Williams wrote:
> > Last summer I wrote some code to talk to a Trimble GPS receiver (in TSIP
> > mode) that extracts the necessary info to do this (among other
> > things). 
> 
> I've got a Java class that does it as well, although it uses NMEA mode.
> Does your code interface with the NTP daemon, since that's what I'm
> missing.

No, it doesn't interface with ntpd, since I wrote it under  Windows
NT, in C++, no less.  Still, the TSIP parsing code would have been useful,
if that were what you needed.

Jason


From owner-freebsd-hackers  Fri Dec 19 20:18:09 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA17202
          for hackers-outgoing; Fri, 19 Dec 1997 20:18:09 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ultra.ultra.net.au (chaos@ultra.ultra.net.au [203.20.237.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA17187;
          Fri, 19 Dec 1997 20:17:56 -0800 (PST)
          (envelope-from chaos@ultra.net.au)
Received: from localhost (chaos@localhost) by ultra.ultra.net.au (8.8.8/8.8.8) with SMTP id OAA21724; Sat, 20 Dec 1997 14:19:31 +1000 (EST)
Date: Sat, 20 Dec 1997 14:19:31 +1000 (EST)
From: Simon Coggins 
To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org
Subject: Segate Tape stor 3200MB
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 know/have running the Seagate Tape Stor 3200MB tape drive that
connect to the floppy cable? (it has it's own card for high speed
transfers.. was wondering that would work too..

I'm interested in buying one but I want to know if I can use it on FreeBSD
or not..

The details on the drive are:

Model Number: TST3200R

I think it's called a Tape Store Traven.




Regards
Simon



From owner-freebsd-hackers  Fri Dec 19 23:43:07 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA27305
          for hackers-outgoing; Fri, 19 Dec 1997 23:43:07 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA27281;
          Fri, 19 Dec 1997 23:42:58 -0800 (PST)
          (envelope-from bkogawa@primenet.com)
Received: (from daemon@localhost)
	by smtp01.primenet.com (8.8.8/8.8.8) id AAA13921;
	Sat, 20 Dec 1997 00:42:28 -0700 (MST)
Received: from mailhost02.primenet.com(206.165.5.53), claiming to be "primenet.com"
 via SMTP by smtp01.primenet.com, id smtpd013905; Sat Dec 20 00:42:25 1997
Received: from foo.primenet.com (ip207.sjc.primenet.com [206.165.96.207])
	by primenet.com (8.8.5/8.8.5) with ESMTP id AAA29521;
	Sat, 20 Dec 1997 00:42:23 -0700 (MST)
Received: (from bkogawa@localhost)
	by foo.primenet.com (8.8.6/8.8.6) id XAA28993;
	Fri, 19 Dec 1997 23:43:19 -0800 (PST)
Date: Fri, 19 Dec 1997 23:43:19 -0800 (PST)
Message-Id: <199712200743.XAA28993@foo.primenet.com>
To: chaos@ultra.net.au
Subject: Re: Segate Tape stor 3200MB
Newsgroups: localhost.freebsd.questions
References:  
From: "Bryan K. Ogawa" 
Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org
X-Newsreader: NN version 6.5.0 #1 (NOV)
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In localhost.freebsd.questions you write:

>Does anyone know/have running the Seagate Tape Stor 3200MB tape drive that
>connect to the floppy cable? (it has it's own card for high speed
>transfers.. was wondering that would work too..

>I'm interested in buying one but I want to know if I can use it on FreeBSD
>or not..

>The details on the drive are:

>Model Number: TST3200R

>I think it's called a Tape Store Traven.

While I can't speak to the specific model you're talking about here,
generally speaking floppy tape drives are poorly supported or entirely
unsupported under FreeBSD.

Most people instead recommend SCSI tape drives of some stripe or
another (Travan, 8mm, 4mm (DDS/DAT), DLT).

I have a very cheap 4mm tape drive that I'm using right now, and while
not perfect, FreeBSD works with it well.

If you're worried about price, www.corpsys.com, for example, often
sells referbished drives quite cheaply.  At the moment, the cheapest
SCSI drive they have is a 4 4mm changer for US$380 , which is a good
price, I think, but probably overkill for most home users.  I bought
mine from them, but I have the advantage of living a few miles from
several of their outlets (ah, Silicon Valley).

I just noticed you're not in the US, so the shipping costs may drive
up your price excessively; I'm not sure what to recommend to you in
this case, but my understanding is that these sorts of drives are not
recommended.


-- 
bryan k ogawa     http://www.primenet.com/~bkogawa/

From owner-freebsd-hackers  Sat Dec 20 00:22:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA28792
          for hackers-outgoing; Sat, 20 Dec 1997 00:22:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 AAA28786
          for ; Sat, 20 Dec 1997 00:22:09 -0800 (PST)
          (envelope-from phk@critter.freebsd.dk)
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 JAA07500;
	Sat, 20 Dec 1997 09:19:36 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Nate Williams 
cc: hackers@freebsd.org
Subject: Re: NTP stratum 1 with GPS on FreeBSD 
In-reply-to: Your message of "Fri, 19 Dec 1997 16:32:49 MST."
             <199712192332.QAA22850@mt.sri.com> 
Date: Sat, 20 Dec 1997 09:19:35 +0100
Message-ID: <7498.882605975@critter.freebsd.dk>
From: Poul-Henning Kamp 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199712192332.QAA22850@mt.sri.com>, Nate Williams writes:
>> If anybody is interested in getting their FreeBSD box to run as a
>> stratum 1 NTP server using GPS, I have been playing with a Motorola
>> "UT Oncore" evaluation kit, which so far gives excellent results.
>
>How does it intergate with ntpd?  Did you have to write the code to have
>it talk to ntpd, or was that part of the kit.

I'm busy writing it.  Unfortunately our kernel doesn't really do nS 
timing yet, only uS, so my jitter is in the < 10 uS Peak-to-Peak range 
still.

BTW:
All you need to do to interface the "UT Oncore Evaluation Kit" to a PC
is some custom cabling.  No level Converters or anything needed :-)

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-hackers  Sat Dec 20 01:51:13 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA02557
          for hackers-outgoing; Sat, 20 Dec 1997 01:51:13 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA02549;
          Sat, 20 Dec 1997 01:51:03 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id KAA11622;
	Sat, 20 Dec 1997 10:50:55 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id KAA29207;
	Sat, 20 Dec 1997 10:30:52 +0100 (MET)
Date: Sat, 20 Dec 1997 10:30:52 +0100 (MET)
Message-Id: <199712200930.KAA29207@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <349AF439.446B9B3D@whistle.com>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: FreeBSD CVS problem: /etc/protocols
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
cc: peter@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Julian Elischer  wrote:

> /etc/protocols never got branched for RELENG_2_2
> the tag RELENG_2_2 is a non branch tag

> anyone care to fix this?

This should be left to Peter Wemm.

-- 
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 Dec 20 01:51:36 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA02631
          for hackers-outgoing; Sat, 20 Dec 1997 01:51:36 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA02598
          for ; Sat, 20 Dec 1997 01:51:27 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id KAA11630;
	Sat, 20 Dec 1997 10:51:25 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id KAA29224;
	Sat, 20 Dec 1997 10:41:08 +0100 (MET)
Date: Sat, 20 Dec 1997 10:41:08 +0100 (MET)
Message-Id: <199712200941.KAA29224@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: 
    <199712200743.XAA28993@foo.primenet.com>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: Segate Tape stor 3200MB
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
cc: Simon Coggins 
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

"Bryan K. Ogawa"  wrote:

> While I can't speak to the specific model you're talking about here,
> generally speaking floppy tape drives are poorly supported or entirely
> unsupported under FreeBSD.

That's right.  Further, the floppy controller hardware makes a rather
poort tape interface hardware.  You need to format your tape in advance
into `sectors' (which takes a huge amount of time), and you're bound
to the FDC clock rates that are used for floppies, thus only get the
same basic speed as a floppy.  In FreeBSD, currently only 500 kbps are
supported as the highest rate, this yields something around 30 KB/s
for a floppy disk.  I doubt it will be much more for a `floppy' tape.

Compare this to >100 KB/s even for the simplest SCSI drives, like an
ancient Archive Viper 150, or to (180...) 300...500 KB/s for modern
drives.

> Most people instead recommend SCSI tape drives of some stripe or
> another (Travan, 8mm, 4mm (DDS/DAT), DLT).

I wouldn't even recommend any Travan tape.  There have been a number
of questions regarding the SCSI ones popping up in freebsd-scsi, and
the net result is their SCSI firmware implementation is poor enough so
you often can't call the result `SCSI' at all (since they violate
things that are flagged `mandatory' in the standard).

> If you're worried about price, www.corpsys.com, for example, often
> sells referbished drives quite cheaply.

See also Jonathan Breslers recommendation for a QIC drive in the
handbook.  I think it was a 1 GB drive (1.3 GB with XL cartridges),
not too expensive, and damn fast.  There are a number of happy campers
using Tandberg drives (like me :), but these ones aren't what one
would call `cheap' right away.  But they are rock-solid, and that's
what counted more to me.

-- 
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 Dec 20 01:51:53 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA02695
          for hackers-outgoing; Sat, 20 Dec 1997 01:51:53 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA02649
          for ; Sat, 20 Dec 1997 01:51:39 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id KAA11638
	for freebsd-hackers@freebsd.org; Sat, 20 Dec 1997 10:51:37 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id KAA29231;
	Sat, 20 Dec 1997 10:42:55 +0100 (MET)
Date: Sat, 20 Dec 1997 10:42:55 +0100 (MET)
Message-Id: <199712200942.KAA29231@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <19971219080913.17939@saidev.com>
    <349AD486.41C67EA6@whistle.com> <19971219145334.52794@saidev.com>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: ppp multi-device?
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Derek Inksetter  wrote:

> mpd, as I understand it, is a true multilink PPP package, no?  What
> I have is much simpler...if a device is busy it just spins around to
> the next one.  It still uses a single device at a time, it just gets
> to choose from a list.

I thought this was already possible?  Hmm, no, only multiple phone
numbers...  So well, it sounds interesting, yep.  Don't forget to talk
to Brian.

-- 
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 Dec 20 01:52:00 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA02722
          for hackers-outgoing; Sat, 20 Dec 1997 01:52:00 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA02671
          for ; Sat, 20 Dec 1997 01:51:45 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id KAA11640
	for freebsd-hackers@freebsd.org; Sat, 20 Dec 1997 10:51:42 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id KAA29242;
	Sat, 20 Dec 1997 10:45:41 +0100 (MET)
Date: Sat, 20 Dec 1997 10:45:41 +0100 (MET)
Message-Id: <199712200945.KAA29242@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: 
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: Increasing maximum file descriptors (for max sockets)
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Brandon Gillespie  wrote:

> And so on.  On first glimpse through the kernel config file I can't seem
> to find anything to increase the amount of file descriptors.  Where is
> this done?

In /sys/conf/param.c.  It's:

#define NPROC (20 + 16 * MAXUSERS)
int     maxproc = NPROC;        /* maximum # of processes */
....
int     maxfiles = NPROC*2;     /* system wide open files limit */

So basically, bumping maxusers in your config file is the fastest way
out.

-- 
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 Dec 20 02:21:05 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA04665
          for hackers-outgoing; Sat, 20 Dec 1997 02:21:05 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA04650
          for ; Sat, 20 Dec 1997 02:20:58 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA11771
	for freebsd-hackers@freebsd.org; Sat, 20 Dec 1997 11:20:55 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id LAA29298;
	Sat, 20 Dec 1997 11:01:26 +0100 (MET)
Date: Sat, 20 Dec 1997 11:01:26 +0100 (MET)
Message-Id: <199712201001.LAA29298@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <19822.882343067@verdi.nethelp.no>
    <3.0.1.32.19971216232646.00766974@pop.mpc.com.br>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: 3com 3c509 card
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Capriotti  wrote:

> I've heard that some 3com cards have only 3KB buffer; Have any of you 
> heard of it ?

No, i think the smallest possible constellation is 8 KB.  The
programming documents IMHO offer some possible diversity which you can
probe at runtime.

The tricky thing with these cards is the buffer space is a FIFO which
you have to divide into a Tx and an Rx segment.  The actual options
how to divide it depend on the total FIFO size, IIRC the 8 KB FIFO
could only be divided into 2 KB Tx and 6 KB Rx FIFO.

A total of 8 KB only is rather dangerous if your machine is slow, and
you're doing NFS.  The default NFS block size is 8 KB, and with only 6
KB Rx buffer space, your machine must have fetched the first packet
from the buffer before the last one from the NFS server arrived at the
NIC (that's ~ 5 ms of time).  If you failed to do this, the entire NFS
block (consisting of 6 Ethernet packets) was lost, and the server
retransmitted it -- with the same problem again.  This was a rather
widely known NFS deadlock situation back in the days of slower CPUs,
and with 3c503's only having 8 KB of buffer space.  (You had to mount
the server with a smaller blocksize, like 1 KB so each NFS block fits
into a single Ethernet packet.  That's the ``Slow NFS'' option in
sysinstall.)

-- 
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 Dec 20 02:21:10 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA04688
          for hackers-outgoing; Sat, 20 Dec 1997 02:21:10 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA04663
          for ; Sat, 20 Dec 1997 02:21:03 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA11777
	for freebsd-hackers@freebsd.org; Sat, 20 Dec 1997 11:21:01 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id LAA29305;
	Sat, 20 Dec 1997 11:03:08 +0100 (MET)
Date: Sat, 20 Dec 1997 11:03:08 +0100 (MET)
Message-Id: <199712201003.LAA29305@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <199712181118.VAA00374@word.smith.net.au>
    <349a26d6.47585537@mail.cetlink.net>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: 3com 3c509 card
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

jak@cetlink.net (John Kelly) wrote:

>>Correct.  However 0WS operation was recently enabled for the 'ed' 
>>driver and WD cards, but it had to be backed out for reliability 
>>reasons.
> 
> Ah, you didn't mention that before.  I would like to review the
> changes to enable 0WS in the 'ed' driver with the hope of getting my
> cards to work at 0WS.  Can you tell me where to find those changes?

Just review the CVS logs for sys/i386/isa/if_ed.c.

-- 
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 Dec 20 02:21:20 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA04728
          for hackers-outgoing; Sat, 20 Dec 1997 02:21:20 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA04697
          for ; Sat, 20 Dec 1997 02:21:11 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA11781
	for freebsd-hackers@freebsd.org; Sat, 20 Dec 1997 11:21:09 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id LAA29331;
	Sat, 20 Dec 1997 11:12:02 +0100 (MET)
Date: Sat, 20 Dec 1997 11:12:02 +0100 (MET)
Message-Id: <199712201012.LAA29331@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <199712170155.RAA04988@vader.cs.berkeley.edu>
    <199712170507.WAA02379@harmony.village.org>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: Question about making a new machine from an old one
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Warner Losh  wrote:

> Yes, but I need to have machine number 1 in this infinite series
> first.  Since I don't have a a -stable machine to clone from, I
> thought I'd do it from my -stable build tree.  I have many -current
> machines that I could clone, but I didn't think downgrading from
> -current to -stable was possible...

You can always make a release. ;-)

`make release' is very paranoid now about the various pitfalls that
could happen if the hosting and the target version of the system are
different.  Since `make release' requires you to offer a chroot
directory, you end up with a completely and cleanly bootstrapped
target tree.  There's nobody telling you the chroot target dir can't
be an entire tree of mounted filesystems.

You can abort the process by the time the chroot environment has
finished its own chroot'ed `make world', before you're starting to
roll the various distribution tarballs (which takes another good deal
of time to complete).

-- 
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 Dec 20 02:21:15 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA04706
          for hackers-outgoing; Sat, 20 Dec 1997 02:21:15 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA04676
          for ; Sat, 20 Dec 1997 02:21:07 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA11779
	for freebsd-hackers@freebsd.org; Sat, 20 Dec 1997 11:21:05 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id LAA29318;
	Sat, 20 Dec 1997 11:07:18 +0100 (MET)
Date: Sat, 20 Dec 1997 11:07:18 +0100 (MET)
Message-Id: <199712201007.LAA29318@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: freebsd-chat@FreeBSD.ORG
Organization: Private BSD site, Dresden
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
References: <19971216.233119.5295.1.wakkym@juno.com>
    
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: atapi.c || wierd hardware
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@FreeBSD.ORG
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

(Please, honor the reply-to header.)

Andrzej Bialecki  wrote:

> I conclude from this that vendors often have peculiar understanding of
> "standards"...

The so-called ATA `standard' always makes for a good laugh at carneval
time.  Go, and fetch a copy before the next carneval season is
coming. ;-)

I'm always surprised that the drives manufactured after this document
do still work to an astonishing degree.  IMHO, this required more
research on the manufacturer's end than just a copy of that document.

-- 
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 Dec 20 02:21:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA04741
          for hackers-outgoing; Sat, 20 Dec 1997 02:21:21 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA04716
          for ; Sat, 20 Dec 1997 02:21:16 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA11786;
	Sat, 20 Dec 1997 11:21:13 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id LAA29341;
	Sat, 20 Dec 1997 11:15:55 +0100 (MET)
Date: Sat, 20 Dec 1997 11:15:55 +0100 (MET)
Message-Id: <199712201015.LAA29341@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: 
    <199712162123.WAA03783@rvc1.informatik.ba-stuttgart.de>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: Compiling Kernels on remote machine & using 'wrong' versions
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Cc: Karl Pielorz 
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Wolfgang Helbig  wrote:

> Just build the kernel in
> /home/phoenix/usr/src/sys/compile/.  AFAIK, the sources
> below the usr/src/sys directory are used exclusively for the kernel,
> regardless of the pathname of this directory.

There might be some minor things like the inclusion of standard
(non-kenel) header files in `genassym' or `aicasm'.  I've always been
able to resolve these issues at least manually (i.e.. by building those
two tools on the slow machine, aborting the `make' there, and
continuing the process on the fast machine in the NFS directory).

-- 
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 Dec 20 06:13:00 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA18717
          for hackers-outgoing; Sat, 20 Dec 1997 06:13:00 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 GAA18712
          for ; Sat, 20 Dec 1997 06:12:55 -0800 (PST)
          (envelope-from root@implode.root.com)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.5/8.8.5) with ESMTP id GAA01870;
	Sat, 20 Dec 1997 06:14:38 -0800 (PST)
Message-Id: <199712201414.GAA01870@implode.root.com>
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Sat, 20 Dec 1997 11:01:26 +0100."
             <199712201001.LAA29298@uriah.heep.sax.de> 
From: David Greenman 
Reply-To: dg@root.com
Date: Sat, 20 Dec 1997 06:14:38 -0800
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Capriotti  wrote:
>
>> I've heard that some 3com cards have only 3KB buffer; Have any of you 
>> heard of it ?
>
>No, i think the smallest possible constellation is 8 KB.  The

   The 3c509 has a 4K FIFO buffer which is divided into 2K send and a 2K
receive FIFOs. This is indeed quite small. The FIFO can easily be overrun,
causing packet loss.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project

From owner-freebsd-hackers  Sat Dec 20 07:50:13 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA23586
          for hackers-outgoing; Sat, 20 Dec 1997 07:50:13 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from gaia.coppe.ufrj.br (cisigw.coppe.ufrj.br [146.164.5.200])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA23579
          for ; Sat, 20 Dec 1997 07:50:07 -0800 (PST)
          (envelope-from jonny@coppe.ufrj.br)
Received: (from jonny@localhost)
	by gaia.coppe.ufrj.br (8.8.8/8.8.8) id NAA24065;
	Sat, 20 Dec 1997 13:49:55 -0200 (EDT)
	(envelope-from jonny)
From: Joao Carlos Mendes Luis 
Message-Id: <199712201549.NAA24065@gaia.coppe.ufrj.br>
Subject: Re: Increasing maximum file descriptors (for max sockets)
In-Reply-To:  from Brandon Gillespie at "Dec 18, 97 09:02:52 am"
To: brandon@roguetrader.com (Brandon Gillespie)
Date: Sat, 20 Dec 1997 13:49:55 -0200 (EDT)
Cc: freebsd-hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

#define quoting(Brandon Gillespie)
// And so on.  On first glimpse through the kernel config file I can't seem
// to find anything to increase the amount of file descriptors.  Where is
// this done?  I cannot find anything about it in the docs...

One thing I love in the BSD 4.4 approach is the sysctl !  Why recompile
a kernel if you can do this with the system running ?

Take a look at these two systcls:

kern.maxfiles
kern.maxfilesperproc

					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  Sat Dec 20 07:55:35 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA23911
          for hackers-outgoing; Sat, 20 Dec 1997 07:55:35 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA23904
          for ; Sat, 20 Dec 1997 07:55:29 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id QAA15429
	for freebsd-hackers@freebsd.org; Sat, 20 Dec 1997 16:55:21 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id QAA00383;
	Sat, 20 Dec 1997 16:44:48 +0100 (MET)
Date: Sat, 20 Dec 1997 16:44:48 +0100 (MET)
Message-Id: <199712201544.QAA00383@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <199712201001.LAA29298@uriah.heep.sax.de>
    <199712201414.GAA01870@implode.root.com>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: 3com 3c509 card
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

David Greenman  wrote:

>>Capriotti  wrote:
>>No, i think the smallest possible constellation is 8 KB.  The
> 
>    The 3c509 has a 4K FIFO buffer which is divided into 2K send and a 2K
> receive FIFOs.

I've apparently confused it with the 3c59x series, or my memory is
flakey (i don't have that programming specs around anymore).

-- 
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 Dec 20 08:32:43 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA26185
          for hackers-outgoing; Sat, 20 Dec 1997 08:32:43 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp10.portal.net.au [202.12.71.110])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA26179
          for ; Sat, 20 Dec 1997 08:32:37 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id CAA00362;
	Sun, 21 Dec 1997 02:56:22 +1030 (CST)
Message-Id: <199712201626.CAA00362@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Michael Hancock 
cc: Mike Smith ,
        John-Mark Gurney ,
        freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory... 
In-reply-to: Your message of "Sat, 20 Dec 1997 09:10:37 +0900."
              
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 21 Dec 1997 02:56:21 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > ... but of course dereferencing a pointer (hardly) requires any 
> > parallelisation.  Why go to all this complexity when all you are 
> > interesting in doing is taking an opaque token and obtaining the 
> > address of a (reasonably non-motile) structure?
> 
> Sorry, I haven't been following the thread.  I jumped in when I noticed
> talk about data structures.  If the structure is read-only then you don't
> have a problem.

We're talking about replacing dev_t with something more opaque; in this 
case something that can be dereferenced appropriately in order to 
immediately obtain a value (normally the softc structure address) saved 
when the device node was created.

mike



From owner-freebsd-hackers  Sat Dec 20 10:54:15 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA04467
          for hackers-outgoing; Sat, 20 Dec 1997 10:54:15 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04404
          for ; Sat, 20 Dec 1997 10:53:33 -0800 (PST)
          (envelope-from tlambert@usr09.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.8/8.8.8) id LAA07022;
	Sat, 20 Dec 1997 11:53:29 -0700 (MST)
Received: from usr09.primenet.com(206.165.6.209)
 via SMTP by smtp04.primenet.com, id smtpd007007; Sat Dec 20 11:53:28 1997
Received: (from tlambert@localhost)
	by usr09.primenet.com (8.8.5/8.8.5) id LAA09179;
	Sat, 20 Dec 1997 11:53:23 -0700 (MST)
From: Terry Lambert 
Message-Id: <199712201853.LAA09179@usr09.primenet.com>
Subject: Re: close() on a modem taking a long time?
To: joerg_wunsch@uriah.heep.sax.de
Date: Sat, 20 Dec 1997 18:53:22 +0000 (GMT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199712192233.XAA26562@uriah.heep.sax.de> from "J Wunsch" at Dec 19, 97 11:33:32 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > Serial ports usually wait for output to finish on a close (I think).
> > You may be able to disable this feature.. see man termios (HUPCL?).
> 
> Nope, that's not the solution.  comcontrol(8) is, you can set
> drainwait to a number of seconds you prefer.
> 
> It's probably better to fix the application to wait until all output
> has been drained.

Better to fix the driver to ignore/assert RTS/CTS while DCD remains off,
and to take an on-to-off DCD transition as indicating "flush output to
null".

THen the error won't happen in the first place.


					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 Dec 20 12:01:48 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA09908
          for hackers-outgoing; Sat, 20 Dec 1997 12:01:48 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from pinky.dyn.ml.org (host77-69.airnet.net [209.64.77.69])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09784;
          Sat, 20 Dec 1997 12:00:57 -0800 (PST)
          (envelope-from kris@ninbsdbox.dyn.ml.org)
Received: from ninbsdbox.dyn.ml.org (ninbsdbox [10.1.0.7])
	by pinky.dyn.ml.org (8.8.5/8.8.5) with ESMTP id NAA00300; 
	Sat, 20 Dec 1997 13:59:37 -0600 (CST)
Message-ID: <349C23AC.350A8E28@ninbsdbox.dyn.ml.org>
Date: Sat, 20 Dec 1997 13:59:40 -0600
From: "Kris Kirby, KE4AHR" 
Reply-To: kris@airnet.net
Organization: Absolutely None!
X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386)
MIME-Version: 1.0
To: questions@freebsd.org
CC: hackers@freebsd.org, multimedia@freebsd.org, majordomo@freebsd.org,
        chat@freebsd.org
Subject: PnP soundcard init without DOS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

subscribe freebsd-chat
end

I have an OPTi 931 PnP sound card and I am rather tired of rebooting the
machine into M$DO$ to get my soundcard working. I would like to know if
anyone has a PnP sound card addition to the kernel, or has made one that
hasn't been incorporated into the RELEASE. My Soundcard is SB compatible
and MSS compatible, depending on how the card setup utility writes it.
Thanks 
-- 

Kris Kirby 
-------------------------------------------
A Person is smart. People are dumb, panicky, dangerous animals
and you know it.
	-- Kay, in MiB, copyright Sony Pictures Imageworks

From owner-freebsd-hackers  Sat Dec 20 15:36:56 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA22876
          for hackers-outgoing; Sat, 20 Dec 1997 15:36:56 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from ns1.yes.no (ns1.yes.no [195.119.24.10])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA22870
          for ; Sat, 20 Dec 1997 15:36:50 -0800 (PST)
          (envelope-from eivind@bitbox.follo.net)
Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36])
	by ns1.yes.no (8.8.7/8.8.7) with ESMTP id XAA02459;
	Sat, 20 Dec 1997 23:30:55 GMT
Received: (from eivind@localhost)
	by bitbox.follo.net (8.8.6/8.8.6) id AAA11124;
	Sun, 21 Dec 1997 00:30:40 +0100 (MET)
X-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
To: freebsd-hackers@FreeBSD.ORG, Karl Pielorz 
Subject: Re: Compiling Kernels on remote machine & using 'wrong' versions
References:      <199712162123.WAA03783@rvc1.informatik.ba-stuttgart.de> <199712201015.LAA29341@uriah.heep.sax.de>
From: Eivind Eklund 
Date: 21 Dec 1997 00:30:39 +0100
In-Reply-To: j@uriah.heep.sax.de's message of Sat, 20 Dec 1997 11:15:55 +0100 (MET)
Message-ID: <86u3c3vbhc.fsf@bitbox.follo.net>
Lines: 26
X-Mailer: Gnus v5.4.52/XEmacs 20.2
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

j@uriah.heep.sax.de (J Wunsch) writes:

> Wolfgang Helbig  wrote:
> 
> > Just build the kernel in
> > /home/phoenix/usr/src/sys/compile/.  AFAIK, the sources
> > below the usr/src/sys directory are used exclusively for the kernel,
> > regardless of the pathname of this directory.
> 
> There might be some minor things like the inclusion of standard
> (non-kenel) header files in `genassym' or `aicasm'.  I've always been
> able to resolve these issues at least manually (i.e.. by building those
> two tools on the slow machine, aborting the `make' there, and
> continuing the process on the fast machine in the NFS directory).

The easiest way to solve this is to just extract the include
directory, too.  You want it like this:

src/sys/
src/include/

A directory named 'include' in the same directory as your sys
directory will always be preferred over the includes installed on the
machine.

Eivind.

From owner-freebsd-hackers  Sat Dec 20 15:53:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA23790
          for hackers-outgoing; Sat, 20 Dec 1997 15:53:55 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA23771
          for ; Sat, 20 Dec 1997 15:53:49 -0800 (PST)
          (envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
	by sax.sax.de (8.8.8/8.8.8) with UUCP id AAA20450
	for freebsd-hackers@freebsd.org; Sun, 21 Dec 1997 00:53:45 +0100 (CET)
	(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.8/8.8.5) id AAA05219;
	Sun, 21 Dec 1997 00:49:37 +0100 (MET)
Date: Sun, 21 Dec 1997 00:49:37 +0100 (MET)
Message-Id: <199712202349.AAA05219@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
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
References: <199712192233.XAA26562@uriah.heep.sax.de>
    <199712201853.LAA09179@usr09.primenet.com>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: close() on a modem taking a long time?
X-Original-Newsgroups: local.freebsd.hackers
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert  wrote:

>> It's probably better to fix the application to wait until all output
>> has been drained.
> 
> Better to fix the driver to ignore/assert RTS/CTS while DCD remains off,
> and to take an on-to-off DCD transition as indicating "flush output to
> null".

You're only considering modems.  How would you force a mouse into
delivering DCD or CTS?  (That's where the problem happened to me
recently, XFree86's server attempted to send something to my mouse,
but the mouse, being a plain old MouseSystems one, is only receptive
to cat's signals but not to RS-232 signals.)

-- 
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 Dec 20 18:35:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA01081
          for hackers-outgoing; Sat, 20 Dec 1997 18:35:51 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 SAA01058
          for ; Sat, 20 Dec 1997 18:35:42 -0800 (PST)
          (envelope-from dkelly@nospam.hiwaay.net)
Received: from nospam.hiwaay.net (tnt2-74.HiWAAY.net [208.147.148.74])
	by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id UAA12642
	for ; Sat, 20 Dec 1997 20:35:36 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
          by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP
	  id UAA14247 for ; Sat, 20 Dec 1997 20:12:54 -0600 (CST)
Message-Id: <199712210212.UAA14247@nospam.hiwaay.net>
X-Mailer: exmh version 2.0zeta 7/24/97
To: freebsd-hackers@freebsd.org
From: David Kelly 
Subject: Re: Segate Tape stor 3200MB 
In-reply-to: Message from j@uriah.heep.sax.de (J Wunsch) 
   of "Sat, 20 Dec 1997 10:41:08 +0100." <199712200941.KAA29224@uriah.heep.sax.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 20 Dec 1997 20:12:53 -0600
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Joerg Wunsch writes:
> 
> See also Jonathan Breslers recommendation for a QIC drive in the
> handbook.  I think it was a 1 GB drive (1.3 GB with XL cartridges),
> not too expensive, and damn fast.  There are a number of happy campers
> using Tandberg drives (like me :), but these ones aren't what one
> would call `cheap' right away.  But they are rock-solid, and that's
> what counted more to me.

That would be an Arcive Anaconda 2750? QIC-9130, uses the *real* QIC 
tapes such as QIC-150 a.k.a. DC6150, and eveything in between. Think I 
got my two at Onsale for about $139 each. Last time I looked Corpsys 
was selling them for $169. Its a good value. OTOH Archive DDS-1 drives 
have been aproaching the $225 price. DDS-2's with compression are under 
$500, I have one of those also too.

(ahc0:5:0): "ARCHIVE Python 28388-XXX 4.CM" type 1 removable SCSI 2
st0(ahc0:5:0): Sequential-Access density code 0x13,  drive empty
(ahc0:6:0): "ARCHIVE ANCDA 2750 28077 -003" type 1 removable SCSI 2
st1(ahc0:6:0): Sequential-Access density code 0x0,  drive empty

I don't know what it does different, but a 9130 tape for 1.35G runs an 
honest screaming 30MB/minute. But a 9100 tape (QIC-1000) only runs 
12MB/minute. I bought a bunch of QIC-1000's for about $6 each, so I'll 
live with the performance hit.

My DDS-2 drive does about 25MB/minute.

--
David Kelly N4HHE, dkelly@nospam.hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.



From owner-freebsd-hackers  Sat Dec 20 18:46:41 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA01945
          for hackers-outgoing; Sat, 20 Dec 1997 18:46:41 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp7.portal.net.au [202.12.71.107])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA01891
          for ; Sat, 20 Dec 1997 18:45:59 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id NAA01912;
	Sun, 21 Dec 1997 13:10:13 +1030 (CST)
Message-Id: <199712210240.NAA01912@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: John-Mark Gurney 
cc: Mike Smith ,
        FreeBSD Hackers 
Subject: Re: converting drivers to dynamic memory... 
In-reply-to: Your message of "Thu, 18 Dec 1997 06:36:06 -0800."
             <19971218063606.31535@hydrogen.nike.efn.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 21 Dec 1997 13:10:12 +1030
From: Mike Smith 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > I do not.  And you have missed the most obvious (and most widely 
> > discussed) solution, which various people are already working on.
> 
> so, your saying that the rest of the frame would already exists, it
> just needs to be fixed?

Framework?  Yes, it's almost all there already.  When your device is 
currently operated on, the dev_t value is constructed and passed in to 
the driver using the values from the device node.  That construction 
will be replaced with the passing in of the devfs token for the node.

> > Understand that when DEVFS hits us properly (and all that's holding it 
> > up now are buggy consumers), dev_t will cease to be what it currently 
> > is.  The dev_t argument is present everywhere that you want to 
> > reference your device softc.
> 
> ok, if this is the case, can you tell me where this is currently??

I'm not sure what you mean by "where this is".  Do you mean "where are 
the code samples"?  There are none yet; they wouldn't fit the current 
model.

> I just looked at sio's devfs_add_devswf...  the closest thing was
> the passing of it's unit number in, but then it gets or'd with the
> flag of what that entry does... PLUS, that "minor" number gets merged
> with the major number, so you won't be able to store a void * in there...
>
> so, two questions, where does devfs does this magic pointer?  and how
> will it co-exist with passing back the type of device that was opened?

The pointer will be stored in the devfs node.  I'm not sure I 
understand what you mean by "the type of device" though.  When you 
create a devfs node, there is an association between the node and the 
device switch.  The functions in the device switch will be passed the 
devfs token when the node is operated on.
 
> > There will be no major/minor numbers soon.
> 
> so, how long till this happens??  is this going to be completed in the
> next few months?

This is entirely contingent on the acceptance of devfs as "the way to 
go", and the encompassing of the various prerequisite tasks (such as 
persistence and fixing buggy devfs support in drivers).

> the reason I ask is that once the bus/device code is writen, I'm going
> to have to pretty much rewrite ALL of the device drivers for the new
> scheme, and I don't want to do more than I have to... changing how a
> function is called is a LOT more work than just changing the internals
> of a function...

I think that devfs will be a goer for 3.0.  I don't know what sort of 
timetable you're on for your bus restructuring, but I suspect you may 
be looking at 3.1 for that.

mike



From owner-freebsd-hackers  Sat Dec 20 19:22:16 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA03649
          for hackers-outgoing; Sat, 20 Dec 1997 19:22:16 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 TAA03643
          for ; Sat, 20 Dec 1997 19:22:09 -0800 (PST)
          (envelope-from brian@awfulhak.org)
Received: from gate.lan.awfulhak.org (localhost [127.0.0.1])
	by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id DAA17601;
	Sun, 21 Dec 1997 03:21:55 GMT
	(envelope-from brian@gate.lan.awfulhak.org)
Message-Id: <199712210321.DAA17601@awfulhak.demon.co.uk>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Derek Inksetter 
cc: freebsd-hackers@freebsd.org
Subject: Re: ppp multi-device? 
In-reply-to: Your message of "Fri, 19 Dec 1997 08:09:13 CST."
             <19971219080913.17939@saidev.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 21 Dec 1997 03:21:55 +0000
From: Brian Somers 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> How much interest is there in making user-mode ppp handle multiple devices
> for dial-out?  My company uses ppp with "ip aliasing" and some
> modifications to deal with multiple modems.  basically our ppp.conf has a
> line that looks like this:
> 
> set device /dev/cuaa0,/dev/cuaa1,...
> 
[.....]
> +   char modem_devlist[500];	/* Comma-separated list of devices */
[.....]

I changed the 500 to LINE_LEN (in case it's changed in the future), but 
apart from that, thanks - they're applied.
-- 
Brian , , 
      
Don't _EVER_ lose your sense of humour....



From owner-freebsd-hackers  Sat Dec 20 19:31:00 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA04110
          for hackers-outgoing; Sat, 20 Dec 1997 19:31:00 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from wartch.rih.org (ppp-207-214-209-51.snfc21.pacbell.net [207.214.209.51])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA04102
          for ; Sat, 20 Dec 1997 19:30:55 -0800 (PST)
          (envelope-from peterh@wartch.rih.org)
Received: from wartch.rih.org (localhost [127.0.0.1])
	by wartch.rih.org (8.8.8/8.8.8) with ESMTP id TAA00216
	for ; Sat, 20 Dec 1997 19:30:18 -0800 (PST)
	(envelope-from peterh@wartch.rih.org)
Message-Id: <199712210330.TAA00216@wartch.rih.org>
To: freebsd-hackers@freebsd.org
Subject: I broke my mouse.
From: psh1@cornell.edu
Date: Sat, 20 Dec 1997 19:30:18 -0800
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


I have been fiddling with the sio driver in current and I think this may
have somehow messed up my mouse. I'm basically getting the sio driver to
work with this card I have that has a UART 16C750 and a 14MHz clock. Anyway,
I had adjusted the divisor for the baud rate to be based off the 14MHz clock
instead of the 1MHz clock and now my psm0 mouse port doesn't work. It
doesn't even work on the original, unmodified kernel (or Windows95 for that
matter). The mouse itself works on other computers, but not on this one. 

I turned on some debugging in the kbdio and psm drivers and here's the
result:

Dec 20 18:22:44 wartch /kernel: psm0: current command byte:0065
Dec 20 18:22:44 wartch /kernel: kbdio: new command byte:0054 (set_controller...)
Dec 20 18:22:44 wartch /kernel: kbdio: TEST_AUX_PORT status:0000
Dec 20 18:22:44 wartch /kernel: kbdio: RESET_AUX return code:00fe
Dec 20 18:22:44 wartch last message repeated 2 times
Dec 20 18:22:44 wartch /kernel: kbdio: DIAGNOSE status:0055
Dec 20 18:22:44 wartch /kernel: kbdio: TEST_KBD_PORT status:0000
Dec 20 18:22:44 wartch /kernel: kbdio: new command byte:0065 (set_controller...)
Dec 20 18:22:44 wartch /kernel: psm0: failed to reset the aux device.
Dec 20 18:22:45 wartch /kernel: psm0 not found at 0x60

Return code 00fe is apparently PSM_RESEND, but I don't know what that means.

Anyone got any ideas?

From owner-freebsd-hackers  Sat Dec 20 20:04:47 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA05993
          for hackers-outgoing; Sat, 20 Dec 1997 20:04:47 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA05967
          for ; Sat, 20 Dec 1997 20:04:35 -0800 (PST)
          (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp)
Received: by outmail.utsunomiya-u.ac.jp id AA24115; Sun, 21 Dec 1997 13:04:26 +0900
Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP
	id NAA17120; Sun, 21 Dec 1997 13:11:22 +0900 (JST)
Message-Id: <199712210411.NAA17120@zodiac.mech.utsunomiya-u.ac.jp>
To: psh1@cornell.edu
Cc: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: I broke my mouse. 
In-Reply-To: Your message of "Sat, 20 Dec 1997 19:30:18 PST."
             <199712210330.TAA00216@wartch.rih.org> 
References: <199712210330.TAA00216@wartch.rih.org> 
Date: Sun, 21 Dec 1997 13:10:31 +0900
From: Kazutaka YOKOTA 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>I have been fiddling with the sio driver in current and I think this may
>have somehow messed up my mouse. I'm basically getting the sio driver to
>work with this card I have that has a UART 16C750 and a 14MHz clock. Anyway,
>I had adjusted the divisor for the baud rate to be based off the 14MHz clock
>instead of the 1MHz clock and now my psm0 mouse port doesn't work. It
>doesn't even work on the original, unmodified kernel (or Windows95 for that
>matter). The mouse itself works on other computers, but not on this one. 

I am not sure which type of mouse you own, the PS/2 mouse or the
serial mouse?

The psm driver is for the PS/2 mouse, not for the serial mouse. 
Modification to the sio driver will have no effect on the psm driver
and the PS/2 mouse which is connected to the PS/2 mouse port.

Are you sure what you have is a PS/2 mouse and it's correctly
connected to the PS/2 mouse port?

>I turned on some debugging in the kbdio and psm drivers and here's the
>result:
>
>Dec 20 18:22:44 wartch /kernel: psm0: current command byte:0065
>Dec 20 18:22:44 wartch /kernel: kbdio: new command byte:0054 (set_controller..
>.)
>Dec 20 18:22:44 wartch /kernel: kbdio: TEST_AUX_PORT status:0000
>Dec 20 18:22:44 wartch /kernel: kbdio: RESET_AUX return code:00fe
>Dec 20 18:22:44 wartch last message repeated 2 times
>Dec 20 18:22:44 wartch /kernel: kbdio: DIAGNOSE status:0055
>Dec 20 18:22:44 wartch /kernel: kbdio: TEST_KBD_PORT status:0000
>Dec 20 18:22:44 wartch /kernel: kbdio: new command byte:0065 (set_controller..
>.)
>Dec 20 18:22:44 wartch /kernel: psm0: failed to reset the aux device.
>Dec 20 18:22:45 wartch /kernel: psm0 not found at 0x60
>
>Return code 00fe is apparently PSM_RESEND, but I don't know what that means.

The above log suggests nothing is connected to the PS/2 mouse port.

If you do have a PS/2 mouse, it is connected to the PS/2 mouse port,
and it works on other computers, there may be a hardware problem: a)
the PS/2 mouse port on this motherboard may be broken, b) or the
cabling between the motherboard and the PS/2 mouse port connector on
you computer case is somewhat bad.

Kazu

From owner-freebsd-hackers  Sat Dec 20 21:06:58 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA08488
          for hackers-outgoing; Sat, 20 Dec 1997 21:06:58 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from wartch.rih.org (ppp-206-170-3-47.okld03.pacbell.net [206.170.3.47])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA08483
          for ; Sat, 20 Dec 1997 21:06:53 -0800 (PST)
          (envelope-from peterh@wartch.rih.org)
Received: (from peterh@localhost)
	by wartch.rih.org (8.8.8/8.8.8) id VAA00290
	for freebsd-hackers@freebsd.org; Sat, 20 Dec 1997 21:06:36 -0800 (PST)
	(envelope-from peterh)
Date: Sat, 20 Dec 1997 21:06:36 -0800 (PST)
From: Peter Haight 
Message-Id: <199712210506.VAA00290@wartch.rih.org>
To: freebsd-hackers@freebsd.org
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Subject: Re: I broke my mouse. 
In-reply-to: Your message of "Sun, 21 Dec 1997 13:10:31 +0900."
             <199712210411.NAA17120@zodiac.mech.utsunomiya-u.ac.jp> 
From: psh1@cornell.edu
--------
>I am not sure which type of mouse you own, the PS/2 mouse or the
>serial mouse?

It is definitely a PS/2 mouse. I have been using it with the psm0 driver for
a few weeks now.

>The psm driver is for the PS/2 mouse, not for the serial mouse. 
>Modification to the sio driver will have no effect on the psm driver
>and the PS/2 mouse which is connected to the PS/2 mouse port.

That's what I thought. I thought they might be associated because the mouse
stopped working sometime in the middle of my changes to sio.c.

>If you do have a PS/2 mouse, it is connected to the PS/2 mouse port,
>and it works on other computers, there may be a hardware problem: a)
>the PS/2 mouse port on this motherboard may be broken, b) or the
>cabling between the motherboard and the PS/2 mouse port connector on
>you computer case is somewhat bad.

How can I confirm or deny either of these two problems?

From owner-freebsd-hackers  Sat Dec 20 21:10:49 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA08747
          for hackers-outgoing; Sat, 20 Dec 1997 21:10:49 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from onyx.atipa.com (user20067@ns.atipa.com [208.128.22.10])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA08738
          for ; Sat, 20 Dec 1997 21:10:43 -0800 (PST)
          (envelope-from freebsd@atipa.com)
Received: (qmail-queue invoked by uid 1018); 21 Dec 1997 05:16:54 -0000
Date: Sat, 20 Dec 1997 22:16:54 -0700 (MST)
From: Atipa 
X-Sender: freebsd@dot.ishiboo.com
To: psh1@cornell.edu
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: I broke my mouse.
In-Reply-To: <199712210330.TAA00216@wartch.rih.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


Is the mouse plugged in when the system boots? The BIOS needs to hook
IRQ 12 at boot; if you try to plug in the mouse after boot, it won't be 
properly recognized. Looks like the driver can't reset the device because it 
can not physically locate it.

You may have fried your mouse port on your motherboard. What type of 
mouse and motherboard are you using?

Kevin

> I have been fiddling with the sio driver in current and I think this may
> have somehow messed up my mouse. I'm basically getting the sio driver to
> work with this card I have that has a UART 16C750 and a 14MHz clock. Anyway,
> I had adjusted the divisor for the baud rate to be based off the 14MHz clock
> instead of the 1MHz clock and now my psm0 mouse port doesn't work. It
> doesn't even work on the original, unmodified kernel (or Windows95 for that
> matter). The mouse itself works on other computers, but not on this one. 
> 
> I turned on some debugging in the kbdio and psm drivers and here's the
> result:
> 
> Dec 20 18:22:44 wartch /kernel: psm0: current command byte:0065
> Dec 20 18:22:44 wartch /kernel: kbdio: new command byte:0054 (set_controller...)
> Dec 20 18:22:44 wartch /kernel: kbdio: TEST_AUX_PORT status:0000
> Dec 20 18:22:44 wartch /kernel: kbdio: RESET_AUX return code:00fe
> Dec 20 18:22:44 wartch last message repeated 2 times
> Dec 20 18:22:44 wartch /kernel: kbdio: DIAGNOSE status:0055
> Dec 20 18:22:44 wartch /kernel: kbdio: TEST_KBD_PORT status:0000
> Dec 20 18:22:44 wartch /kernel: kbdio: new command byte:0065 (set_controller...)
> Dec 20 18:22:44 wartch /kernel: psm0: failed to reset the aux device.
> Dec 20 18:22:45 wartch /kernel: psm0 not found at 0x60
> 
> Return code 00fe is apparently PSM_RESEND, but I don't know what that means.
> 
> Anyone got any ideas?
> 

From owner-freebsd-hackers  Sat Dec 20 21:23:52 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA09268
          for hackers-outgoing; Sat, 20 Dec 1997 21:23:52 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from wartch.rih.org (ppp-206-170-3-152.okld03.pacbell.net [206.170.3.152])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA09263
          for ; Sat, 20 Dec 1997 21:23:47 -0800 (PST)
          (envelope-from peterh@wartch.rih.org)
Received: from wartch.rih.org (localhost [127.0.0.1])
	by wartch.rih.org (8.8.8/8.8.8) with ESMTP id VAA00426;
	Sat, 20 Dec 1997 21:23:12 -0800 (PST)
	(envelope-from peterh@wartch.rih.org)
Message-Id: <199712210523.VAA00426@wartch.rih.org>
To: Atipa 
cc: freebsd-hackers@freebsd.org
Subject: Re: I broke my mouse. 
In-reply-to: Your message of "Sat, 20 Dec 1997 22:16:54 MST."
              
Date: Sat, 20 Dec 1997 21:23:11 -0800
From: Peter Haight 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>Is the mouse plugged in when the system boots? 

Yep.

>You may have fried your mouse port on your motherboard. What type of 
>mouse and motherboard are you using?

The mouse is a Logitech MouseMan and the motherboard is an MSI-6111 (440LX).

From owner-freebsd-hackers  Sat Dec 20 22:05:58 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA10892
          for hackers-outgoing; Sat, 20 Dec 1997 22:05:58 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from m16.boston.juno.com (m16.boston.juno.com [205.231.101.192])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA10883
          for ; Sat, 20 Dec 1997 22:05:53 -0800 (PST)
          (envelope-from wakkym@juno.com)
Received: (from wakkym@juno.com)
 by m16.boston.juno.com (queuemail) id ByI07763; Sun, 21 Dec 1997 01:05:22 EST
To: psh1@cornell.edu, hackers@freebsd.org
Subject: Re: I broke my mouse.
Message-ID: <19971221.010303.5295.3.wakkym@juno.com>
References: 
X-Mailer: Juno 1.15
X-Juno-Line-Breaks: 0,2-13,17
From: wakkym@juno.com (Lee Cremeans)
Date: Sun, 21 Dec 1997 01:05:22 EST
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Sat, 20 Dec 1997 22:16:54 -0700 (MST) Atipa 
writes:
>
>Is the mouse plugged in when the system boots? The BIOS needs to hook
>IRQ 12 at boot; if you try to plug in the mouse after boot, it won't 
>be 
>properly recognized. Looks like the driver can't reset the device 
>because it 
>can not physically locate it.
>
>You may have fried your mouse port on your motherboard. What type of 
>mouse and motherboard are you using?

Actually, it may be something that's not as bad...many newer motherboards
have fuses on the keyboard and PS/2 mouse ports. If you're handy with a
soldering iron and a multimeter, this is pretty easy to fix, but in any
case, you may not need to replace the whole board.

From owner-freebsd-hackers  Sat Dec 20 22:13:45 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA11251
          for hackers-outgoing; Sat, 20 Dec 1997 22:13:45 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA11246
          for ; Sat, 20 Dec 1997 22:13:41 -0800 (PST)
          (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp)
Received: by outmail.utsunomiya-u.ac.jp id AA24075; Sun, 21 Dec 1997 15:13:32 +0900
Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP
	id PAA19069; Sun, 21 Dec 1997 15:20:38 +0900 (JST)
Message-Id: <199712210620.PAA19069@zodiac.mech.utsunomiya-u.ac.jp>
To: Peter Haight 
Cc: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp
In-Reply-To: Your message of "Sat, 20 Dec 1997 21:06:36 PST."
             <199712210506.VAA00290@wartch.rih.org> 
References: <199712210506.VAA00290@wartch.rih.org> 
Date: Sun, 21 Dec 1997 15:20:37 +0900
From: Kazutaka YOKOTA 
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>I am not sure which type of mouse you own, the PS/2 mouse or the
>>serial mouse?
>
>It is definitely a PS/2 mouse. I have been using it with the psm0 driver for
>a few weeks now.
[snip]
>>If you do have a PS/2 mouse, it is connected to the PS/2 mouse port,
>>and it works on other computers, there may be a hardware problem: a)
>>the PS/2 mouse port on this motherboard may be broken, b) or the
>>cabling between the motherboard and the PS/2 mouse port connector on
>>you computer case is somewhat bad.
>
>How can I confirm or deny either of these two problems?

If you have an AT style motherboard, it is most likely that there is a
flat cable from the motherboard to the PS/2 mouse port connector. If
you have a spare flat cable around you, you swap the cable and see if
the mouse works.  If the motherboard is of the ATX type, the connector
is soldered on the motherboard, thus, there is no possibility b)
above.

I understand that the PS/2 mouse, the motherboard and the psm driver
have been working until lately. Have you ever plug or unplug the PS/2
mouse from the system while power to the system is ON? The PS/2 mouse
interface and the keyboard interface appear to be very sensitive to
noise and can be fried easily. I have known a couple of people around
me who did unplug or plug the PS/2 mouse while the system is running
and ruined the interface.

Kazu


From owner-freebsd-hackers  Sat Dec 20 23:19:34 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA13608
          for hackers-outgoing; Sat, 20 Dec 1997 23:19:34 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from watermarkgroup.com (luoqi.watermarkgroup.com [207.202.73.170])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA13603
          for ; Sat, 20 Dec 1997 23:19:29 -0800 (PST)
          (envelope-from luoqi@watermarkgroup.com)
Received: (from luoqi@localhost)
	by watermarkgroup.com (8.8.8/8.8.7) id BAA11974
	for hackers@freebsd.org; Sun, 21 Dec 1997 01:58:40 -0500 (EST)
	(envelope-from luoqi)
Date: Sun, 21 Dec 1997 01:58:40 -0500 (EST)
From: Luoqi Chen 
Message-Id: <199712210658.BAA11974@watermarkgroup.com>
To: hackers@freebsd.org
Subject: msdosfs win95 long file name support
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I know someone (Robert Nordier?) has been working on a replacement for msdosfs.
But my patience ran out after more than one year of waiting, so I took up
the matter myself. After about two weekends of work, I got a set of working
code. If anyone's interested, I have uploaded the diff to ftp://ftp.cdrom.com/
pub/FreeBSD/incoming/msdosfs-vfat.diff.gz. Since I have been working on a
2.2-stable machine, the diff was taken against the 2.2.5 release. I haven't
done much testing on this, so use at your own risk. Please send feedbacks
to luoqi@watermarkgroup.com. And Merry Chrismas to everyone.

-lq

From owner-freebsd-hackers  Sat Dec 20 23:35:57 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA14495
          for hackers-outgoing; Sat, 20 Dec 1997 23:35:57 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
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 XAA14483
          for ; Sat, 20 Dec 1997 23:35:45 -0800 (PST)
          (envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA25262;
          Sat, 20 Dec 1997 23:33:51 -0800 (PST)
Message-ID: <19971220233351.10621@hydrogen.nike.efn.org>
Date: Sat, 20 Dec 1997 23:33:51 -0800
From: John-Mark Gurney 
To: Mike Smith 
Cc: FreeBSD Hackers 
Subject: Re: converting drivers to dynamic memory...
References: <19971218063606.31535@hydrogen.nike.efn.org> <199712210240.NAA01912@word.smith.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199712210240.NAA01912@word.smith.net.au>; from Mike Smith on Sun, Dec 21, 1997 at 01:10:12PM +1030
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

Mike Smith scribbled this message on Dec 21:

[...]

my point was that this "framework" that you said was debunking my changes
ISN'T complete and working, even though you said it was... I will be
needing it in a couple months...

> > > There will be no major/minor numbers soon.
> > 
> > so, how long till this happens??  is this going to be completed in the
> > next few months?
> 
> This is entirely contingent on the acceptance of devfs as "the way to 
> go", and the encompassing of the various prerequisite tasks (such as 
> persistence and fixing buggy devfs support in drivers).

so, until that happens, can I procede with phase one (that Darren Reed
was so nice to name :) )...  almost ALL of that work will be able to
easily translate once devfs is complete..

> > the reason I ask is that once the bus/device code is writen, I'm going
> > to have to pretty much rewrite ALL of the device drivers for the new
> > scheme, and I don't want to do more than I have to... changing how a
> > function is called is a LOT more work than just changing the internals
> > of a function...
> 
> I think that devfs will be a goer for 3.0.  I don't know what sort of 
> timetable you're on for your bus restructuring, but I suspect you may 
> be looking at 3.1 for that.

I'm hoping for having the bus/device code completely written and
functional with in the next two months...  of course, after the bus/device
code is done, it will require massive changes to the device drivers...
I've thought about this, and it's probably best to have both in the
tree at the same time, and just move device drivers over...  else we
would need a complete device driver freeze, which I'm sure no one
wants...  (the more people that would help would make a freeze that
much shorter)..

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking					  P.O. Box 5693, 97405

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD