From owner-freebsd-hackers Sun Jan 26 00:05:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA25806 for hackers-outgoing; Sun, 26 Jan 1997 00:05:51 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25800 for ; Sun, 26 Jan 1997 00:05:46 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id TAA22463; Sun, 26 Jan 1997 19:05:31 +1100 Date: Sun, 26 Jan 1997 19:05:31 +1100 From: Bruce Evans Message-Id: <199701260805.TAA22463@godzilla.zeta.org.au> To: j@uriah.heep.sax.de, jmz@cabri.obs-besancon.fr Subject: Re: fdisk headache Cc: freebsd-hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> The real problem is then when I want to label the disk: I get >> >> ioctl DIOCWLABEL: Operation not supported by device >> sd4s4: type 0xa5, start 1, end = 6265199, size 6265199 >> sd4s4: C/H/S end 666/5/55 (220109) != end 6265199: invalid > >The slice code knows about various BIOS problems. It assumes a few >bogus geometry values (including the 1024 cylinders one). However, >the total number of sectors in the BSD slice must still match the `c' >partition value -- 6265199. There is one fatal error here and one warning. The fatal DIOCWLABEL error is probably caused by attempting to label a device that doesn't support labeling. Surprise :-). /dev/rsd4 does not support labeling. /dev/rsd4s4c (or its alias /dev/rsd4s4, or if s4 is the first BSD slice, its alias /dev/rsd4c) supports labeling. The fatal error may mask another fatal error. The disk size and the `c' partition size in the label should both match the size of the slice -- 6265199 (it may work to use a smaller size at least for the `c' partition, but there is normally no reason to). The warning about the slice size mismatch is printed to help diagnose errors like this. Unfortunately, it is only printed if the `bootverbose' flag is set (it is normally set by booting with -v), and the warning about the invalid BIOS geometry is also printed. (The BIOS geometry is irrelevant here. It is probably caused by the installer not rounding the slice size to a cylinder boundary.) Bruce From owner-freebsd-hackers Sun Jan 26 00:24:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26435 for hackers-outgoing; Sun, 26 Jan 1997 00:24:15 -0800 (PST) Received: from csd.cs.technion.ac.il (csd.cs.technion.ac.il [132.68.32.8]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA26424 for ; Sun, 26 Jan 1997 00:24:10 -0800 (PST) Received: from localhost (nadav@localhost) by csd.cs.technion.ac.il (8.6.11/8.6.10) with SMTP id KAA29628; Sun, 26 Jan 1997 10:19:55 +0200 X-Authentication-Warning: csd.cs.technion.ac.il: nadav owned process doing -bs Date: Sun, 26 Jan 1997 10:19:55 +0200 (IST) From: Nadav Eiron X-Sender: nadav@csd To: Terry Lambert cc: Tom Samplonius , garman@phs.k12.ar.us, freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? In-Reply-To: <199701252030.NAA00669@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Jan 1997, Terry Lambert wrote: > > > L*nux has an option `hda=serialize' to do this. Is there any chance > > > FreeBSD could have an CMD640B_SUCKS_ROCKS_SERIALIZE_REQUESTS option in the > > > kernel config file? > > > > Considering that a perfectly good, brand new EIDE controller with > >primary and secondary, and dual 16550 UARTs, and printer for $50, why > > bother? > > So that FreeBSD will run on hardware as it comes from the manufacturer > so that people who want to run FreeBSD can be pure computer users > instead of a combination of computer user, petty cash drawer, and > hardware hacker? And another reason: I (for one) have a machine with a built-in CMD640 and no free PCI slots... > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Nadav From owner-freebsd-hackers Sun Jan 26 00:35:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26871 for hackers-outgoing; Sun, 26 Jan 1997 00:35:58 -0800 (PST) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26858 for ; Sun, 26 Jan 1997 00:35:56 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id BAA01692; Sun, 26 Jan 1997 01:35:51 -0700 (MST) From: Don Yuniskis Message-Id: <199701260835.BAA01692@seagull.rtd.com> Subject: Re: suggestion for kernel printk() ? To: bde@zeta.org.au (Bruce Evans) Date: Sun, 26 Jan 1997 01:35:50 -0700 (MST) Cc: bde@zeta.org.au, dgy@rtd.com, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199701260649.RAA20345@godzilla.zeta.org.au> from "Bruce Evans" at Jan 26, 97 05:49:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> I use a serial console and `terminalprogram | tee foo' to capture > >> the output. > > > >Yes, but I would have had to have built the kernel with COMCONSOLE > >(which I didn't). > > COMCONSOLE hasn't been necessary for 2 years in -current (just boot > with -h) but is still necessary in -stable. Sigh. Hmmm... this is a 2.1R box. I'll have to check next time I reboot... > >However, is it worthwhile for the mechanism that printk() ?? uses to > >observe some kind of flow control? It did not recognize scroll_lock, > >pause, ^S, etc. This would have at least enabled me to read some > >(i.e. one screen full) of the messages to see what the kernel was > >complaining about. > > Scroll lock and scrollback don't work until interrupts are enabled after Yes, that's what I had suspected. > probing all the devices. printf() doesn't have any flow control. It > can't afford to pause once the system is up because that would freeze > the whole system. Freezing for 1 msec per character to for output at > 9600 bps is bad enough. But would it actually *break* anything? Perhaps I'll hack in a two line patch next time I rebuild a kernel and see what happens... Thx! --don From owner-freebsd-hackers Sun Jan 26 01:02:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA27680 for hackers-outgoing; Sun, 26 Jan 1997 01:02:39 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA27675 for ; Sun, 26 Jan 1997 01:02:35 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id TAA23790; Sun, 26 Jan 1997 19:56:20 +1100 Date: Sun, 26 Jan 1997 19:56:20 +1100 From: Bruce Evans Message-Id: <199701260856.TAA23790@godzilla.zeta.org.au> To: bde@zeta.org.au, dgy@rtd.com Subject: Re: suggestion for kernel printk() ? Cc: freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> probing all the devices. printf() doesn't have any flow control. It >> can't afford to pause once the system is up because that would freeze >> the whole system. Freezing for 1 msec per character to for output at >> 9600 bps is bad enough. > >But would it actually *break* anything? Perhaps I'll hack in a two line >patch next time I rebuild a kernel and see what happens... Yes, it would steal characters from the foreground console unless the keyboard is dedicated to low-level console input. Bruce From owner-freebsd-hackers Sun Jan 26 01:22:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA28584 for hackers-outgoing; Sun, 26 Jan 1997 01:22:18 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA28579 for ; Sun, 26 Jan 1997 01:22:15 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA15968; Sun, 26 Jan 1997 10:22:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA27732; Sun, 26 Jan 1997 10:20:27 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 10:20:27 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: garman@phs.k12.ar.us, tom@sdf.com, freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? References: <199701260222.VAA14109@dyson.iquest.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701260222.VAA14109@dyson.iquest.net>; from John S. Dyson on Jan 25, 1997 21:22:53 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John S. Dyson wrote: > I can 'fix' the problem but am overloaded with work this weekend. We > haven't encountered this problem very often, and any solution to the > problem is a bit of a 'wart.' If you are willing to wait for approx > 1-2wks, I might be able to hack the wd driver. (In fact, it might > be a good kernel initiation project for YOU :-)). :-) If anybody starts it, please don't make it an option, but a controller flag. This way, it can be manipulated from boot -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 Sun Jan 26 01:38:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29252 for hackers-outgoing; Sun, 26 Jan 1997 01:38:49 -0800 (PST) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA29246 for ; Sun, 26 Jan 1997 01:38:46 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id CAA07377; Sun, 26 Jan 1997 02:38:38 -0700 (MST) From: Don Yuniskis Message-Id: <199701260938.CAA07377@seagull.rtd.com> Subject: Re: suggestion for kernel printk() ? To: bde@zeta.org.au (Bruce Evans) Date: Sun, 26 Jan 1997 02:38:37 -0700 (MST) Cc: bde@zeta.org.au, dgy@rtd.com, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199701260856.TAA23790@godzilla.zeta.org.au> from "Bruce Evans" at Jan 26, 97 07:56:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> probing all the devices. printf() doesn't have any flow control. It > >> can't afford to pause once the system is up because that would freeze > >> the whole system. Freezing for 1 msec per character to for output at > >> 9600 bps is bad enough. > > > >But would it actually *break* anything? Perhaps I'll hack in a two line > >patch next time I rebuild a kernel and see what happens... > > Yes, it would steal characters from the foreground console unless the > keyboard is dedicated to low-level console input. I guess a single character pushback isn't supported at that level? --don From owner-freebsd-hackers Sun Jan 26 01:50:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29661 for hackers-outgoing; Sun, 26 Jan 1997 01:50:49 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29656 for ; Sun, 26 Jan 1997 01:50:46 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA16398 for freebsd-hackers@FreeBSD.ORG; Sun, 26 Jan 1997 10:50:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA27916; Sun, 26 Jan 1997 10:46:01 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 10:46:01 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: fdisk headache References: <199701260706.SAA20817@godzilla.zeta.org.au> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701260706.SAA20817@godzilla.zeta.org.au>; from Bruce Evans on Jan 26, 1997 18:06:48 +1100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >> I think it is bad form to do this.. > > > >Mmmaybe. > > >Of course, there's one thing that won't work with this method: > >nextboot. > Boot selectors won't work either. Since there's nothing to select from. ;-) Right now, there are three reasons to still call it ``dangerously dedicated'': . Since the MBR is identical to the BSD bootstrap, there's no room for things like `nextboot' after the MBR, and you can't replace the MBR by fancy things like a boot selector. Hence, in a system that is not FreeBSD-only, you could at best make drives != #0 ``DD'', and you won't be able to boot select away from that drive once you switched there. (Normally, booteasy allows to wander around back and forth through all the drives.) . Some known rogues like Win95 will happily clobber the dummy fdisk table (and thus the BSD bootstrap) when they first visit the drive -- of course, without asking the operator, since they interpret the term ``Plug and play'' this way. . Some operating systems might choke on that fdisk table afterwards, so if you are going to install something else on such a drive later, it's best do do a ``dd if=/dev/zero of=/dev/rXXX count=100'' before recycling the drive to another task. (The fourth reason has been fixed since: disklabel -B used to clobber sysinstall's fdisk table, and thus invalidated the sliced device names sysinstall leaves in /etc/fstab.) The plus side is: . It's the simplest way to setup a drive at all, since you can use the total number of blocks of the drive for FreeBSD. The drives are run in a mode that is basically the same as workstation and minicomputer Unices used to do for years. . The number of BIOS geometry constraints to care for reduces drastic- ally, so you can usually (*) ignore any geometry issues. (*) I.e., the BIOS's geometry idea involves at least 15 sectors per track, 4 heads, and the root file system is not larger than 30 MB. To summarize: this mode is intended for those who only want to run FreeBSD, and nothing else. I never advised people with mixed configurations to use it. Those who don't spend the slightest idea into using their machine with other operating systems can however simplify their life by using it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Jan 26 01:51:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29709 for hackers-outgoing; Sun, 26 Jan 1997 01:51:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29702 for ; Sun, 26 Jan 1997 01:51:08 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA16410; Sun, 26 Jan 1997 10:51:03 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA27928; Sun, 26 Jan 1997 10:48:09 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 10:48:09 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: 3.0-970124-SNAP on ftp.freebsd.org References: <199701260133.UAA15694@lakes.water.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701260133.UAA15694@lakes.water.net>; from Thomas David Rivers on Jan 25, 1997 20:33:32 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Thomas David Rivers wrote: > Is there a 2.2 boot/fixit with Justin's SCSI changes (I'm assuming > there the ones 2.2 is waiting on.) That's why we want to make a 2.2-GAMMA. > Or, would it be as meaningful to run my test on the 3.0 snap? Well, give it a try if the 2 MB traffic for the boot + fixit floppy don't hurt you. -- 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 Jan 26 02:02:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA00215 for hackers-outgoing; Sun, 26 Jan 1997 02:02:15 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA00210 for ; Sun, 26 Jan 1997 02:02:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA25500; Sun, 26 Jan 1997 20:59:33 +1100 Date: Sun, 26 Jan 1997 20:59:33 +1100 From: Bruce Evans Message-Id: <199701260959.UAA25500@godzilla.zeta.org.au> To: bde@zeta.org.au, dgy@rtd.com Subject: Re: suggestion for kernel printk() ? Cc: freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Yes, it would steal characters from the foreground console unless the >> keyboard is dedicated to low-level console input. > >I guess a single character pushback isn't supported at that level? >--don Right. The low level console driver is very primitive. It does no buffering. Doing anything in it would have reentrancy problems, since it may be called from interrupt handlers. BTW, there _are_ reentrancy problems in the syscons and pcvt output routines. Don't use /dev/ttyv0 in syscons if you want the system to stay up forever. Bruce From owner-freebsd-hackers Sun Jan 26 02:15:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA00751 for hackers-outgoing; Sun, 26 Jan 1997 02:15:53 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA00738 for ; Sun, 26 Jan 1997 02:15:46 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id VAA25791; Sun, 26 Jan 1997 21:11:30 +1100 Date: Sun, 26 Jan 1997 21:11:30 +1100 From: Bruce Evans Message-Id: <199701261011.VAA25791@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: CMD640b ide controller bug workarounds? Cc: garman@phs.k12.ar.us, tom@sdf.com Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >If anybody starts it, please don't make it an option, but a controller >flag. This way, it can be manipulated from boot -c. This is barely possible. There are only 4 controller flags to spare, because 28 bits are misused for drive flags. Bruce From owner-freebsd-hackers Sun Jan 26 02:58:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA01837 for hackers-outgoing; Sun, 26 Jan 1997 02:58:43 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA01832 for ; Sun, 26 Jan 1997 02:58:40 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id VAA26848; Sun, 26 Jan 1997 21:51:12 +1100 Date: Sun, 26 Jan 1997 21:51:12 +1100 From: Bruce Evans Message-Id: <199701261051.VAA26848@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: fdisk headache Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Boot selectors won't work either. > >Since there's nothing to select from. ;-) >Right now, there are three reasons to still call it ``dangerously >dedicated'': > >. Since the MBR is identical to the BSD bootstrap, there's no room for > things like `nextboot' after the MBR, and you can't replace the MBR > by fancy things like a boot selector. Hence, in a system that is > not FreeBSD-only, you could at best make drives != #0 ``DD'', and > you won't be able to boot select away from that drive once you > switched there. (Normally, booteasy allows to wander around back > and forth through all the drives.) There may be 512(*) sd drives, 512 od drives, 16 cd drives and a small number of wd and fd drives :-). That's a lot to select from. (*) Actually at most 128(**) floppy drives and 128(**) hard drives altogether (because of the BIOS interface limit). (**) Your BIOS may vary. >. Some operating systems might choke on that fdisk table afterwards, > so if you are going to install something else on such a drive later, > it's best do do a ``dd if=/dev/zero of=/dev/rXXX count=100'' before ^^^^^^^^^ > recycling the drive to another task. Should be count=1. If 1 won't work, then 100 may not be enough either, and you'd better know what you are doing. E.g., if there is a FreeBSD slice at offset 100000, then there will be a BSD label at offset 100001, and it should be zeroed to prevent it being resurrected if a BSD slice is created at offset 100000 a year later and the label hasn't been changed. >The plus side is: >... >. The number of BIOS geometry constraints to care for reduces drastic- > ally, so you can usually (*) ignore any geometry issues. > > (*) I.e., the BIOS's geometry idea involves at least 15 sectors per > track, 4 heads, and the root file system is not larger than 30 MB. Actually if the root file system is below cylinder 1024 in the BIOS translation mode. I think the 15 sectors/track limit only applies for floppies. Bruce From owner-freebsd-hackers Sun Jan 26 03:17:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02206 for hackers-outgoing; Sun, 26 Jan 1997 03:17:03 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA02201 for ; Sun, 26 Jan 1997 03:17:00 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA27794 for hackers@freebsd.org; Sun, 26 Jan 1997 11:35:10 +0100 From: Luigi Rizzo Message-Id: <199701261035.LAA27794@labinfo.iet.unipi.it> Subject: help for a floppy boot sector To: hackers@freebsd.org Date: Sun, 26 Jan 1997 11:35:10 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I am looking for some floppy boot code which allows you to build a bootable floppy which can start a .COM file without the need for MSDOS. Two applications: netboot (which produces a .COM file) for people who cannot burn an eprom, and my bridge code (available from my home page, based on netboot), same problem. Ideally I would do something like cat bootcode nb8390.com | dd of=/dev/fd0a to produce a bootable floppy. I figure out I could perhaps use the standard boot sectors for an a.out executable, but patching them to handle .COM file is probably more trouble than necessary. Maybe the bootcode in use for PCEMU can do the job ? Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sun Jan 26 03:24:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02480 for hackers-outgoing; Sun, 26 Jan 1997 03:24:43 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02472 for ; Sun, 26 Jan 1997 03:24:37 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.4/8.7.3) id MAA05236; Sun, 26 Jan 1997 12:25:55 +0100 (MET) From: Søren Schmidt Message-Id: <199701261125.MAA05236@ravenock.cybercity.dk> Subject: Re: suggestion for kernel printk() ? In-Reply-To: <199701260959.UAA25500@godzilla.zeta.org.au> from Bruce Evans at "Jan 26, 97 08:59:33 pm" To: bde@zeta.org.au (Bruce Evans) Date: Sun, 26 Jan 1997 12:25:46 +0100 (MET) Cc: bde@zeta.org.au, dgy@rtd.com, freebsd-hackers@freefall.freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Bruce Evans who wrote: > >> Yes, it would steal characters from the foreground console unless the > >> keyboard is dedicated to low-level console input. > > > >I guess a single character pushback isn't supported at that level? > >--don > > Right. The low level console driver is very primitive. It does no > buffering. Doing anything in it would have reentrancy problems, since > it may be called from interrupt handlers. BTW, there _are_ reentrancy > problems in the syscons and pcvt output routines. Don't use /dev/ttyv0 > in syscons if you want the system to stay up forever. Erhm, why ?? I've not seen any problems and ttyv0 is the only tty I use on my WS (its used almost only under X otherwise) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Sun Jan 26 03:37:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02826 for hackers-outgoing; Sun, 26 Jan 1997 03:37:42 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02821 for ; Sun, 26 Jan 1997 03:37:40 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id LAA21972; Sun, 26 Jan 1997 11:36:44 GMT Date: Sun, 26 Jan 1997 20:36:44 +0900 (JST) From: Michael Hancock To: proff@suburbia.net cc: hackers@freebsd.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <19970126042316.10096.qmail@suburbia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997 proff@suburbia.net wrote: > Can anyone inform me what a SLAB allocator is, and if so, would freebsd > benefit from one? > It's a chunk of memory that you put multiple kernel objects of the same type into. We have a modified mach zone allocator. They're both type stable memory allocators. Maybe John or David will explain how our allocator differs from the original zone allocator in 4.4BSD borrowed from Mach. I not sure how much benefit the SLAB allocator would offer over what we have. There's some extra overhead in maintaining a SLAB. BTW, SLAB is used in Solaris. Regards, Mike Hancock From owner-freebsd-hackers Sun Jan 26 03:40:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02934 for hackers-outgoing; Sun, 26 Jan 1997 03:40:59 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02929; Sun, 26 Jan 1997 03:40:42 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id NAA12413; Sun, 26 Jan 1997 13:38:28 +0200 (EET) Date: Sun, 26 Jan 1997 13:38:28 +0200 (EET) From: Narvi To: Terry Lambert cc: Jake Hamby , hasty@rah.star-gate.com, multimedia@freebsd.org, hackers@freebsd.org Subject: Re: New Bt848 Video capture driver for FreeBSD In-Reply-To: <199701252133.OAA00739@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Jan 1997, Terry Lambert wrote: > > For the record, somebody wrote a bt848 driver for BeOS, and there's a demo > > of the new 3DKit which allows you to drop live video and/or QuickTime > > movies onto the faces of a 3D object (cube, sphere, pulsing thing, book > > pages), and spin it around in realtime. It looks _real_ sweet playing > > about 6 QT movies simultaneously on a PowerMac 8500, all texture-mapped > > onto various 3D objects, but a live video feed is even cooler. Man, I'd > > love to have the source code to that! > > I bet you $1 that they are only transferring data for the one, two, or > three visible faces of the cube. What do you think of them being fools? Everybody knows most things just drop a lot of frames when displaying video on the screen. Dropping a (at the current point of time) invisible video stream is not cheating, I even wouldn't consider using a hack that did not do so. But they still need to move the reference to the current frame in the six other movies. > > You could easily render a projection matrix to do this: > > o Start with a cube showing one face (ie: the vector from > your viewpoint through the center of the cube is perpendicular > to the plane of the face). > [snip - I don't care about checking the validity at the moment] Sander > > o For more complex rotations, you will rotate the cube center > as if it were attached to an axis with a fixed center by > moving the cube center relative. This is topologically > equivalent to rotating the cube about any point. You will > need to make another matrix for perspective, since if you > rotate about a point other than the body center, the average > distance to the body center will get farther (the cube will > "get smaller") or closer (the cube will "get larger"). > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Sun Jan 26 03:52:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA03334 for hackers-outgoing; Sun, 26 Jan 1997 03:52:35 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA03328 for ; Sun, 26 Jan 1997 03:52:31 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA18608; Sun, 26 Jan 1997 12:52:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id MAA05258; Sun, 26 Jan 1997 12:33:44 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 12:33:44 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: hackers@freebsd.org Subject: Re: help for a floppy boot sector References: <199701261035.LAA27794@labinfo.iet.unipi.it> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701261035.LAA27794@labinfo.iet.unipi.it>; from Luigi Rizzo on Jan 26, 1997 11:35:10 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Luigi Rizzo wrote: > Maybe the bootcode in use for PCEMU can do the job ? Probably. Well, no. It doesn't provide for any DOS functions, it just uses the BIOS only. But you should be able to use the loader 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 Sun Jan 26 04:36:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA05281 for hackers-outgoing; Sun, 26 Jan 1997 04:36:04 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA05276 for ; Sun, 26 Jan 1997 04:36:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id EAA06772; Sun, 26 Jan 1997 04:35:36 -0800 (PST) Message-Id: <199701261235.EAA06772@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Hancock cc: proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 20:36:44 +0900." From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 04:35:36 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On Sun, 26 Jan 1997 proff@suburbia.net wrote: > >> Can anyone inform me what a SLAB allocator is, and if so, would freebsd >> benefit from one? >> > >It's a chunk of memory that you put multiple kernel objects of the same >type into. We have a modified mach zone allocator. They're both type >stable memory allocators. The memory allocator in BSD is *not* type-stable. >Maybe John or David will explain how our allocator differs from the >original zone allocator in 4.4BSD borrowed from Mach. There isn't a lot of difference. Just some performance improvements. >I not sure how much benefit the SLAB allocator would offer over what we >have. There's some extra overhead in maintaining a SLAB. > >BTW, SLAB is used in Solaris. The allocator in BSD is designed to be as fast as possible and trades space efficiency for performance. I'm very skeptical that a SLAB allocator would be any faster than the current allocation algorithm, although it would likely be more space efficient. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 04:58:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA06543 for hackers-outgoing; Sun, 26 Jan 1997 04:58:09 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA06537 for ; Sun, 26 Jan 1997 04:58:07 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id EAA23753 for ; Sun, 26 Jan 1997 04:59:21 -0800 (PST) Received: (qmail 19510 invoked by uid 110); 26 Jan 1997 12:57:47 -0000 Message-ID: <19970126125747.19508.qmail@suburbia.net> Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701261235.EAA06772@root.com> from David Greenman at "Jan 26, 97 04:35:36 am" To: dg@root.com Date: Sun, 26 Jan 1997 23:57:47 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I not sure how much benefit the SLAB allocator would offer over what we > >have. There's some extra overhead in maintaining a SLAB. > > > >BTW, SLAB is used in Solaris. > > The allocator in BSD is designed to be as fast as possible and trades > space efficiency for performance. I'm very skeptical that a SLAB allocator > would be any faster than the current allocation algorithm, although it > would likely be more space efficient. > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > I presume the idea is that the cache efficiency of small allocations would be substantially improved? Cheers, Julian From owner-freebsd-hackers Sun Jan 26 05:40:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09170 for hackers-outgoing; Sun, 26 Jan 1997 05:40:52 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA09165 for ; Sun, 26 Jan 1997 05:40:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id FAA06943; Sun, 26 Jan 1997 05:40:21 -0800 (PST) Message-Id: <199701261340.FAA06943@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: proff@suburbia.net cc: hackers@freebsd.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 23:57:47 +1100." <19970126125747.19508.qmail@suburbia.net> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 05:40:21 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >I not sure how much benefit the SLAB allocator would offer over what we >> >have. There's some extra overhead in maintaining a SLAB. >> > >> >BTW, SLAB is used in Solaris. >> >> The allocator in BSD is designed to be as fast as possible and trades >> space efficiency for performance. I'm very skeptical that a SLAB allocator >> would be any faster than the current allocation algorithm, although it >> would likely be more space efficient. ... >I presume the idea is that the cache efficiency of small allocations >would be substantially improved? We already order the allocations to take advantage of the cache by putting freed chunks at the head of the list within the bucket (thus making them the first candidates for re-allocation). This isn't perfect, of course, but it does get you most of the way there. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 05:59:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09649 for hackers-outgoing; Sun, 26 Jan 1997 05:59:16 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA09644; Sun, 26 Jan 1997 05:59:10 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA28121; Sun, 26 Jan 1997 14:17:13 +0100 From: Luigi Rizzo Message-Id: <199701261317.OAA28121@labinfo.iet.unipi.it> Subject: Re: exec bug To: dg@root.com, dyson@freebsd.org Date: Sun, 26 Jan 1997 14:17:12 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199701261336.FAA06928@root.com> from "David Greenman" at Jan 26, 97 05:35:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> In the case of NFS, the read should block indefinately. I'm not sure what > >> will happen if the NFS is mounted "soft", however. > > > >that would be a major problem then! > > Not any more so than any other read blocking indefinately. I was referring to the soft case. the blocking read only leaves the process hung, and possibly not dying at shutdown. But an nfs 'soft' read timing out with a failure, isn't it a time-bomb ? > > Wouldn't it be possible to track > >the exact reason of the fault inside the handler and avoid panicing ? > >After all there are no performance problems at that point.. > > ...and just how do you tell the exec code that a page fault that occured > while it was accessing the image header was "fatal"? The only mechanism we you mean "was not fatal" dont you ? > have for this is signals, and that doesn't work when you're executing in the > kernel like this. I don't know the "big picture" so this could be totally nonsense, but how about creating a "page_probe()" function, cooperating with the fault handler, which tries to access the page, returning 1 if any page fault occur in the kernel address space while running ? Then exec_aout_imgact() (or any other critical function) could first page_probe() the required page, then either continue or fail. There shouldn't be much penalty in doing this since at most the page gets paged in, something that would be necessary anyways. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sun Jan 26 06:46:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA10778 for hackers-outgoing; Sun, 26 Jan 1997 06:46:23 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA10773 for ; Sun, 26 Jan 1997 06:46:20 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id BAA00334; Mon, 27 Jan 1997 01:43:47 +1100 Date: Mon, 27 Jan 1997 01:43:47 +1100 From: Bruce Evans Message-Id: <199701261443.BAA00334@godzilla.zeta.org.au> To: bde@zeta.org.au, sos@ravenock.cybercity.dk Subject: Re: suggestion for kernel printk() ? Cc: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> it may be called from interrupt handlers. BTW, there _are_ reentrancy >> problems in the syscons and pcvt output routines. Don't use /dev/ttyv0 >> in syscons if you want the system to stay up forever. > >Erhm, why ?? I've not seen any problems and ttyv0 is the only tty I >use on my WS (its used almost only under X otherwise) Syscons is not reentrant and doesn't mask interrupts at all while it is doing output, so there must be races when it is reentered. This problem can't be fixed by masking interrupts, because it is important that kernel messages get printed no matter what, and in any case the the console driver is used for unmaskable traps (mainly debugger traps) and NMIs. Here's an LKM to demonstrate the problem. It just prints a "*" every 100 msec in its timeout interrupt handler. Running it together with `hd /* >/dev/ttyv0' usually causes a panic in 10-20 seconds on a 486/33. Use `make; make load' to run it. Reduce the timeout to panic faster. I often use ttyv0 and rarely use X and haven't seen the problem either. Kernel printfs are rare, but 10-20 seconds worth of printfs at 10/sec isn't many either. There are obviously more problems at line and page boundaries; perhaps the problems are rarer for kernel messages because most messages are newline-terminated. Bruce #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'Makefile' <<'END_OF_FILE' XBINDIR= /tmp XSRCS= foo.c XKMOD= foo_mod XNOMAN= none X XCLEANFILES+= ${KMOD} X X.include END_OF_FILE if test 97 -ne `wc -c <'Makefile'`; then echo shar: \"'Makefile'\" unpacked with wrong size! fi # end of 'Makefile' fi if test -f 'foo.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'foo.c'\" else echo shar: Extracting \"'foo.c'\" \(725 characters\) sed "s/^X//" >'foo.c' <<'END_OF_FILE' X#include X#include X#include X#include X#include X XMOD_MISC(foo); X Xstatic void Xfoo(void *arg) X{ X#if 0 X sccnputc(0, '*'); X timeout(foo, NULL, 1); X#else X /* X * Fills up log if done every tick so only do it every 10 ticks and X * wait a bit longer for races. X */ X printf("*"); X timeout(foo, NULL, 10); X#endif X} X Xint Xfoo_mod(struct lkm_table *lkmtp, int cmd, int ver) X{ X DISPATCH(lkmtp, cmd, ver, foo_load, foo_unload, lkm_nullcmd); X} X Xstatic int Xfoo_load(struct lkm_table *lkmtp, int cmd) X{ X timeout(foo, NULL, 1); X return 0; X} X Xstatic int Xfoo_unload(struct lkm_table *lkmtp, int cmd) X{ X int s; X X s = splsoftclock(); X untimeout(foo, NULL); X splx(s); X return 0; X} END_OF_FILE if test 725 -ne `wc -c <'foo.c'`; then echo shar: \"'foo.c'\" unpacked with wrong size! fi # end of 'foo.c' fi echo shar: End of shell archive. exit 0 From owner-freebsd-hackers Sun Jan 26 07:09:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA11603 for hackers-outgoing; Sun, 26 Jan 1997 07:09:01 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA11598 for ; Sun, 26 Jan 1997 07:08:58 -0800 (PST) Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0voWCV-000Qa4C; Sun, 26 Jan 97 16:08 MET Received: (grog@localhost) by freebie.lemis.de (8.8.4/8.6.12) id PAA04577; Sun, 26 Jan 1997 15:59:09 +0100 (MET) From: grog@lemis.de Message-Id: <199701261459.PAA04577@freebie.lemis.de> Subject: Re: bisdn In-Reply-To: <23118.853940980@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 22, 97 05:49:40 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 26 Jan 1997 15:59:08 +0100 (MET) Cc: hackers@freebsd.org (FreeBSD Hackers), isdn@muc.ditec.de (FreeBSD ISDN Distribution List) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Reply-to: grog@lemis.de (Greg Lehey) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: >> and greatly appreciated, too ! Several people will be working on getting >> this integrated into -current (aka 3.0). > > Really? Awesome! I'd just about given up! :-) What's the problem? I've been running bisdn on 2.2-CURRENT and 3.0-CURRENT since last May. Greg From owner-freebsd-hackers Sun Jan 26 08:21:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA13718 for hackers-outgoing; Sun, 26 Jan 1997 08:21:25 -0800 (PST) Received: from feephi.phofarm.com ([206.21.77.129]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA13703 for ; Sun, 26 Jan 1997 08:20:49 -0800 (PST) Received: from feephi.phofarm.com (feephi.phofarm.com [206.21.77.130]) by feephi.phofarm.com (8.8.4/8.7.3) with SMTP id LAA00348; Sun, 26 Jan 1997 11:17:50 -0500 (EST) Message-ID: <32EB83A7.41C67EA6@phofarm.com> Date: Sun, 26 Jan 1997 11:17:43 -0500 From: "Danny J. Zerkel" Organization: Photon Farmers X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: hackers@freefall.freebsd.org CC: toor@dyson.iquest.net Subject: Re: CMD640b ide controller bug workarounds? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I can 'fix' the problem but am overloaded with work this weekend. We > haven't encountered this problem very often, and any solution to the > problem is a bit of a 'wart.' If you are willing to wait for approx > 1-2wks, I might be able to hack the wd driver. (In fact, it might > be a good kernel initiation project for YOU :-)). > > John > dyson@freebsd.org If he's not interested, I am. I have one of these controllers on my motherboard (Micronics). I would also like to access the PCI side of this controller, instead of the ISA side. I only have one disk hanging off this controller, just a 540 that I use for Windows95 (when forced at gun point). I also use it as a secondary boot partition for FreeBSD if I need to mess with the boot partitions on my SCSI disks. Danny J. Zerkel Photon Farmers dzerkel@phofarm.com. From owner-freebsd-hackers Sun Jan 26 09:55:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16795 for hackers-outgoing; Sun, 26 Jan 1997 09:55:49 -0800 (PST) Received: from risc6.unisa.ac.za (risc6.unisa.ac.za [163.200.97.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16787 for ; Sun, 26 Jan 1997 09:55:44 -0800 (PST) Received: by risc6.unisa.ac.za (AIX 4.1/UCB 5.64/4.03) id AA27426; Sun, 26 Jan 1997 19:44:14 +0200 From: radova@risc6.unisa.ac.za (A. Radovanovic) Message-Id: <9701261744.AA27426@risc6.unisa.ac.za> Subject: Help - can't login To: hackers@freebsd.org Date: Sun, 26 Jan 1997 19:44:13 +0200 (USAST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My freebsd ran out of disk space in /. Unfortunately I rebooted the system and now I can't get in - no username or password are accepted. If I boot in a single user mode, the file system is mounted as a read only and I can't do anything with the passwd file. Is there any way to get in and repair the damage? Alex From owner-freebsd-hackers Sun Jan 26 10:22:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17664 for hackers-outgoing; Sun, 26 Jan 1997 10:22:18 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA17659 for ; Sun, 26 Jan 1997 10:22:15 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2-biteme) with ESMTP id MAA15107; Sun, 26 Jan 1997 12:22:03 -0600 (CST) Received: from Mercury.mcs.net (Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.5/8.8.2) with ESMTP id MAA24555; Sun, 26 Jan 1997 12:22:02 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.5/8.8.2) id MAA01165; Sun, 26 Jan 1997 12:21:58 -0600 (CST) From: Karl Denninger Message-Id: <199701261821.MAA01165@Mercury.mcs.net> Subject: Re: Help - can't login To: radova@risc6.unisa.ac.za (A. Radovanovic) Date: Sun, 26 Jan 1997 12:21:58 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: <9701261744.AA27426@risc6.unisa.ac.za> from "A. Radovanovic" at Jan 26, 97 07:44:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > My freebsd ran out of disk space in /. Unfortunately I rebooted the > system and now I can't get in - no username or password are accepted. > If I boot in a single user mode, the file system is mounted as a read > only and I can't do anything with the passwd file. > > Is there any way to get in and repair the damage? > > Alex > Boot single-user. Type "fsck -p" Wait. IF AND ONLY IF ALL FILESYSTEMS CHECK CLEAN: mount -vat ufs This should mount all filesystems on local disks, including remounting root as read/write. Then you should be able to have at it. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Sun Jan 26 11:25:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA19833 for hackers-outgoing; Sun, 26 Jan 1997 11:25:23 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA19827 for ; Sun, 26 Jan 1997 11:25:18 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id OAA00337; Sun, 26 Jan 1997 14:24:58 -0500 (EST) Message-Id: <199701261924.OAA00337@spoon.beta.com> To: Andrew.Gordon@net-tel.co.uk cc: mcgovern@spoon.beta.com, hackers@FreeBSD.org, mcgovern@spoon.beta.com Subject: Re: Overdrive question... In-reply-to: Your message of "Sun, 26 Jan 1997 02:40:12 GMT." <"6af-970126023959-804F*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> Date: Sun, 26 Jan 1997 14:24:58 -0500 From: "Brian J. McGovern" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Thanks for the heads up. I tinkered with it quite a bit more (rougly 20+ times what the manual says it should take), and I'm getting reasonable performance out of it. Turns out they don't like my ATI wonder card (16 bit SVGA w/1MB of ram), and my S3 Trio VLB VGA card. After 10 or so hours now, I've gotten both machines running reasonably. My next stop is to see if I can find a 50 Mhz crystal for one of my machines, so I can wring every bit of processing speed out of it. -Brian From owner-freebsd-hackers Sun Jan 26 11:25:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA19880 for hackers-outgoing; Sun, 26 Jan 1997 11:25:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA19866 for ; Sun, 26 Jan 1997 11:25:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02101; Sun, 26 Jan 1997 12:07:40 -0700 From: Terry Lambert Message-Id: <199701261907.MAA02101@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: tom@sdf.com (Tom Samplonius) Date: Sun, 26 Jan 1997 12:07:40 -0700 (MST) Cc: terry@lambert.org, garman@phs.k12.ar.us, freebsd-hackers@freebsd.org In-Reply-To: from "Tom Samplonius" at Jan 25, 97 06:26:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > So that FreeBSD will run on hardware as it comes from the manufacturer > > so that people who want to run FreeBSD can be pure computer users > > instead of a combination of computer user, petty cash drawer, and > > hardware hacker? > > You're dreaming. As long as hw manufactures make crap, computer usage > will never be "pure". Even the Linux solution requires the user to > diagnose the problem as hw, and add the "hda=serialize" option. It's possible to diagnose the chipset and automatically invoke the workaround. Linux has fallen down. See the test program on www.intel.com for the controller bug. 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 Jan 26 12:16:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA21577 for hackers-outgoing; Sun, 26 Jan 1997 12:16:49 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA21565 for ; Sun, 26 Jan 1997 12:16:44 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02186; Sun, 26 Jan 1997 12:58:33 -0700 From: Terry Lambert Message-Id: <199701261958.MAA02186@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: garman@phs.k12.ar.us Date: Sun, 26 Jan 1997 12:58:33 -0700 (MST) Cc: tom@sdf.com, freebsd-hackers@freebsd.org In-Reply-To: from "Jason Garman" at Jan 25, 97 07:44:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I realize that this is a hardware flaw, but the computer manufacturer is > completely unresponsive to any requests (besides this machine is not > under warranty any more anyhow. If anyone has any suggestions as to how > to deal with the manufacturer, I'd love to hear those too) > > Their stock response is to have the OS `vendor' fix the `problem' in their > software. Sigh. Do they have a FAX machine? Fax them the chip specs. and ask again. The specs imply both channels can be active at the same time. Also, correct them: "fix the 'problem'" should be "work around the 'problem'", since the problem will still exist. Point out to them that you are objecting to the problem existing, not to the fact that it can be worked around in software. Ask them for an example of the software workaround for your OS. In general, be vocal and annoying until they do something in response to the irritation (even if they encapsulate you in pearl by replacing your motherboard, like an oyster would do, your problem will be solved). > Btw- an interesting side note... the `checkide' program that intel is > peddling to check the problem freezes my machine. Heh. Sad part is that > Intel refuses to even fix their program because my motherboard isn't an > Intel one. There are two check programs. You need to search for "+IDE +CMD640" on AltaVista. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jan 26 12:41:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA22669 for hackers-outgoing; Sun, 26 Jan 1997 12:41:07 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA22664 for ; Sun, 26 Jan 1997 12:41:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA02217; Sun, 26 Jan 1997 13:24:13 -0700 From: Terry Lambert Message-Id: <199701262024.NAA02217@phaeton.artisoft.com> Subject: Re: cvs commit: src/sys/kern kern_lockf.c To: michaelh@cet.co.jp Date: Sun, 26 Jan 1997 13:24:13 -0700 (MST) Cc: bde@freefall.freebsd.org, Hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Jan 26, 97 01:15:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > All of the argument checking seems out of place here. The call trace is > like this: > > fcntl => VOP_ADVLOCK => lf_advlock > > or > > open => VOP_ADVLOCK => lf_advlock > > Garbage input should be stopped at the source and lf_advlock should be > completely free from arg checking. The original coder wanted to factor > error checking into lf_advlock, but it seems incorrect to allow garbage to > come in so far. > > A consistent division of arg checking responsibilities would make it > easier for people to decide where to do the checks. We would need some > comments or preconditions specified in lf_advlock to communicate what was > expected so that we would know what to do in fcntl and open. > > Any comments? Yes. The syntactic checking should be in the system call layer, and the grammatic checking should be in the lf_advlock layer, which should be called from the system call layer. A system call interface is a consumer of VFS services, just as an NFS or NetWare or SMB or Lantastic or AppleTalk server may be a consumer of VFS services without being a consumer of the system call layer. This is one of the things I am always on about. The call trace should be: fcntl(lock) <- check call syntax here lf_advlock(lock) <- check arg values here if( !VOP_ADVLOCK(lock)) lf_advlock(unlock) And the FS specific VOP_ADVLOCK should simply return 0 in all cases for most FS's. For fan-out layers (like union mount, where 1 VOP_ADVLOCK needs to apply to potentially more than one underlying stack), union.VOP_ADVLOCK(lock) if( rv = lf_advlock(lock)) <- underlying vnode 1 return( rv); <- FAIL if( underlying1.VOP_ADVLOCK(lock)) { lf_advlock(unlock); <- underlying vnode 1 return( 1); <- FAIL } if( rv = lf_advlock(lock)) { <- underlying vnode 2 underlying1.VOP_ADVLOCK(unlock); lf_advlock(unlock); <- underlying vnode 1 return( rv); <-- FAIL } if( underlying2.VOP_ADVLOCK(lock)) { lf_advlock(unlock); <- underlying vnode 2 underlying1.VOP_ADVLOCK(unlock); lf_advlock(unlock); <- underlying vnode 1 return( 1); <- FAIL } return( 0); With unwind in case the locking really needs to do something. Probably the easiest way to do this would be a list + recursion, and let a union only union 2 FS's (union does this, but make it a rule for others). Clearly, this would benefit from negative logic to enable a single point of exit from the unionfs code. It's as shown to make control flow obvious, but negative logic is best for SMP and kernel reentrancy of the routine to enable clean tracking of entry/exit lock state. All functions should be single-entry/single-exit, if possible, so as to not damage the ability to later implement SMP reentrancy and kernel multithreading as quickly and error-free as humanly possible. The veto architecture is needed to make union FS's not accidently lf_advlock() the same vnode twice. For example, say I have a quota and a non-quota "view" onto the same FS. The quota implementation is a stacking layer so that all FS's can have quotas. The vnode is passed through the quota layer, because all the quota layer does is a name space incursion to subtract out the quota file on the FS root. A lock on the quota vnode and the non-quota vnode would be a lock on the same vnode. For NFS, nfs.VOP_ADVLOCK(lock) #ifdef NFS_CLIENT_LOCKING return( nfs_client_lock(lock)); #else /* !NFS_CLIENT_LOCKING*/ return( 0); /* always succeed; current implementation*/ #endif /* !NFS_CLIENT_LOCKING*/ This has the advantage of a local lock on the same file failing before NFS has to hit actually the wire. The place for the checking is either fcntl + open, or lf_advlock, depending on who pulls the arguments in. The Lite2 locking implementation is slightly different, but can be handled the same way, since it's just a lock manager issue, not a hierarchy issue. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jan 26 12:49:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA23026 for hackers-outgoing; Sun, 26 Jan 1997 12:49:16 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA23016 for ; Sun, 26 Jan 1997 12:49:12 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0voTme-0006VY-00; Sun, 26 Jan 1997 04:34:04 -0800 Date: Sun, 26 Jan 1997 04:34:04 -0800 (PST) From: Tom Samplonius To: Terry Lambert cc: garman@phs.k12.ar.us, freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? In-Reply-To: <199701261907.MAA02101@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, Terry Lambert wrote: > > > So that FreeBSD will run on hardware as it comes from the manufacturer > > > so that people who want to run FreeBSD can be pure computer users > > > instead of a combination of computer user, petty cash drawer, and > > > hardware hacker? > > > > You're dreaming. As long as hw manufactures make crap, computer usage > > will never be "pure". Even the Linux solution requires the user to > > diagnose the problem as hw, and add the "hda=serialize" option. > > It's possible to diagnose the chipset and automatically invoke the > workaround. Linux has fallen down. > > See the test program on www.intel.com for the controller bug. I've been told by the user in question, that the ide check program from Intel hangs on his system. Not too useful. "Pure computer usage" will not be possible until a "pure computer" exists. As it stands, sw people need to keep "adapting" to new hw bugs. > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. Tom From owner-freebsd-hackers Sun Jan 26 12:52:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA23236 for hackers-outgoing; Sun, 26 Jan 1997 12:52:47 -0800 (PST) Received: from pegasus.my.domain (capt-39.ppp.hooked.net [206.80.9.167]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA23231 for ; Sun, 26 Jan 1997 12:52:43 -0800 (PST) Received: from pegasus.my.domain (localhost [127.0.0.1]) by pegasus.my.domain (8.7.6/8.7.3) with SMTP id MAA12067 for ; Sun, 26 Jan 1997 12:53:09 -0800 Message-ID: <32EBC435.63297F3E@hooked.net> Date: Sun, 26 Jan 1997 12:53:09 -0800 From: RHS Linux User X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i686) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: What to do about the 2.0 GNU libc? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I must appologize for my past posts to this mail list. I now see that freebsd is the way it is for a reason. Also the handling of ppp connections in linux and most other OS's really sucks. FreeBSD has the best implimentation I have ever seen. I am curious about the up and comming GNU 2.0 libc. Since the BSD's have their own libc will you be replacing yours with the GNU one? Not that I like GNU to much (it seams to be becomming the Microsoft of the free software world) but it would save a lot of developement time if you didn't have to worry about your own library. Since this the GNU libc will be used by Linux it would be hard to go wrong. FreeBSD would be using the same libc are it's chief competitor. FreeBSD would then only have the userland commands to deal with, since Linux of course has GNU maintaining those. I hate GNU binutils. The next question is. Is the GNU libc 2.0 being ported? I saw that someone was doing a port for BSDI2.0, is this not the same as FreeBSD? I am very interested the GNU libc 2.0 for its posix threads and the fact that it is rentrant (which it has to be of course for threads). What is the status of kernel-threads in FreeBSD? I heard that you where getting there. Since you have linux compatibility (except for clone() right?) would it not be possible to just use the GNU libc 2.0 the way it is? Does it ever have to be ported? I am sure Linux will always have presidence with GNU anyway. This of course looks really bad since eventually freebsd will have linux's kernel calls. But think about it. It is only externel, just as the GNU libc is externel. Is FreeBSD BSD without the BSD libc? Good question. I have many more questions.... Thanks... From owner-freebsd-hackers Sun Jan 26 13:01:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA24013 for hackers-outgoing; Sun, 26 Jan 1997 13:01:19 -0800 (PST) Received: from pegasus.my.domain (capt-39.ppp.hooked.net [206.80.9.167]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24008 for ; Sun, 26 Jan 1997 13:01:15 -0800 (PST) Received: from pegasus.my.domain (localhost [127.0.0.1]) by pegasus.my.domain (8.7.6/8.7.3) with SMTP id NAA12098 for ; Sun, 26 Jan 1997 13:01:41 -0800 Message-ID: <32EBC635.4F86F1D5@hooked.net> Date: Sun, 26 Jan 1997 13:01:41 -0800 From: RHS Linux User X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i686) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: What is the default for async in /etc/fstab? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am having trouble determining the disk IO performace of FreeBSD vs. Linux. I recently ran a test on FreeBSD and the write performance wasn't so great. However, I didn't think to see if async was set in the /etc/fstab file. I installed from a 2.1 CDROM initially and then cvsuped different versions. So what is the default for async in the 2.1 /etc/fstab? Have other people tested ufs vs. ext2? The only docs I could find where for ext2. A comparison with FreeBSD 2.0 I think, although it could have been older. This was for some old Linux 1.xx. Hardware. Adapt. 2940UW, and Quantum 4.3gig Atlas, 7200rpm. 8.5ms. Thanks. From owner-freebsd-hackers Sun Jan 26 13:23:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25041 for hackers-outgoing; Sun, 26 Jan 1997 13:23:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25036 for ; Sun, 26 Jan 1997 13:23:41 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02273; Sun, 26 Jan 1997 14:05:45 -0700 From: Terry Lambert Message-Id: <199701262105.OAA02273@phaeton.artisoft.com> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: proff@suburbia.net Date: Sun, 26 Jan 1997 14:05:45 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <19970126042316.10096.qmail@suburbia.net> from "proff@suburbia.net" at Jan 26, 97 03:23:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'm going to try feveriously to get the SLAB allocator integrated into > > Linus's sources over the next two days. For the most part my > > incentive is so that people think about it when they design memory > > object allocation subsystems. > > > > For example, even right now, look at the way struct sock's are indeed > > allocated. Alan's recent change to add sock_init_data() and the fact > > that my sources already use SLAB for struct sock sparked this idea. > > > > We could in this case just make sock_init_data() the constructor > > routine for the sock SLAB. So for a warm SLAB cache this code never > > gets run as long as users of sock's are not forgetful and leave a sock > > in a reasonable state when they free them. (ie. don't leave crap on > > the receive queue etc.) > > Can anyone inform me what a SLAB allocator is, and if so, would freebsd > benefit from one? In simple terms, it allocates "slabs" of memory for memory pools of a particular type, generally in units of pages. It is basically a variant of the zone allocator (per MACH). You can implement memory zoning, per MACH, to tag object persistance within a SLAB allocator. Assuming you allocate the kernel space itself with the SLAB allocator, and the kernel image is assembled on SLAB boundries, you can even do things like zone discard, which let you throw away initialization code once the system is up, and reclaim the memory for reuse by the system. One of the reasons I want ELF is to allow zone discard. Technically, FreeBSD already does SLAB allocation, or at least its interface looks like it does. The sys/malloc.h values M_MBUF, M_SOCKET, M_NAMEI, etc. used by the kernel malloc, are all SLAB identifiers. --- In a kernel multithreading or SMP environment, you don't *want* a SLAB allocator... at least, not a pure one, as the base level for allocation. You want a global page-pool allocator instead, and then you will implement your allocator on top of the page pool. There are even reasons you might want to have this on a simple UP system. Because the kernel is reeentrant, you can reenter the allocator on a SLAB id. FreeBSD currently copes with this (badly) on its fault/interrupt reentrancy case... for example, allocating an mbuf at interrupt level requires that the mbuf SLAB be guarded against reentrancy by running the allocation to completion at high SPL so that it is never really reentered while the data structure is in an indeterminate state. This adds to processing latency in the kernel. In reality, each context wants its own set of SLABs. This may be overkill for exception reentrancy, actually. The way Microsoft does this in Windows95 and NT is dividing the interrupt service routines into "upper" and "lower", with "lower" running at interrupt mode, and "upper" running in non-interrupt mode. In Windows95 and NT, you do not do memory allocation at interrupt level; you must preallocate the memory at driver init, and allocate it again in "upper" code if the preallocated object is consumed by the "lower" code. If you don't want to make this restriction on the use of allocators (there are several places where the preallocation overhead would be exhorbitant, like FDDI or ATM with large card buffers), then you must provide a seperate set of SLABs for a context. In terms of context SLABs, you *do* want seperate SLABs for each processor context in SMP. The reason you want this is that using a global SLAB pool, like in SVR4 or Solaris, you must line up all your processors behind the IPI in order to synchronize access to the SLAB control object for the object type you are allocating. The correct method, first demonstrated in Sequent Dynix, is to have per processor page pools. The synchronization is not required unless you need to refill the page pool from (low water mark) or drain the page pool to (high watermark) the global system page pool. This method is documented in: "UNIX Internals: The New Frontiers" Uresh Vahalia, _Prentice Hall_ ISBN 0-13-101908-2 Chapter 12 _Kernel Memory Allocation_ Section 12.9 _A Hierarchical Allocator for Multiprocessors Sequent failed to implement SLAB allocation on top of this page pool abstraction, and so Vahalia's Analysis is rather harsh, compared to his analysis of SLAB allocation (covered Section 12.10). But it is incorrect to call the SLAB allocation itself superior. Vahalia cites a paper: "Efficient Kernel Memory Allocation on Shared Memory Multiprocessors" McKenney, P.E. and Slingwine, J. Proceedings of USENIX, Winter, 1993 Which shows the sequent code to be faster than the McKusick-Karels algorithm by a factor of three to five on a UP, and a factor of one hundred to one thousand on a 25 processor system. Clearly, if we considered contexts as owning pools instead of CPU's, we should expect a three to nine times improvement for UP BSD from having seperate contexts for interrupt vs. exception vs. normal allocations (in place of running the allocations to completion at high SPL). This might not have more than a 10% scaled effect on a heavily interrupting FreeBSD system, but a 10% improvement is an improvement. There are a number of issues, like object garbage collection, which you would do using cache invalidation at IPI synchronization time to determine if a low water mark hit is real or not. For instance, I may allocate an mbuf on CPU 1 and pass it's address to CPU 2 for use by a user process context entered in the TCP code. If the CPU 2 process then deallocates the MBUF, the cache line indicating the allocation will not have been invalidated. Effectively, this means that there must be an allocation map with each object, and that it must be dynamically scoped. This lets CPU2 mark the map entry as invalid, even though CPU1 did the allocating. CPU1 would sync his picture to that of the global picture at low water mark, reclaiming released buffers at that time. In reality, it's probably better to have a message interface per SLAB per CPU to propagate deallocation messages... if you didn't do that, then a deallocation on CPU1 or CPU3 could cause a corrupt cache line to be written. Rather than fighting between CPU's and being careful at the cache line level, the IPI synchronization should allow message delivery at IPI; this will generally be very fast, since the memory can be preallocated with page attributes so the que pointer ownership is toggled at IPI time. We can go into this in detail if anyone wants to, but the SMP list is probably a better forum for these issues. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jan 26 13:25:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25104 for hackers-outgoing; Sun, 26 Jan 1997 13:25:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25096; Sun, 26 Jan 1997 13:25:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02284; Sun, 26 Jan 1997 14:08:43 -0700 From: Terry Lambert Message-Id: <199701262108.OAA02284@phaeton.artisoft.com> Subject: Re: Possible projects? To: hsu@freefall.freebsd.org (Jeffrey Hsu) Date: Sun, 26 Jan 1997 14:08:43 -0700 (MST) Cc: kneel@ishiboo.com, hackers@freefall.freebsd.org In-Reply-To: <199701260732.XAA23320@freefall.freebsd.org> from "Jeffrey Hsu" at Jan 25, 97 11:32:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > You could try converting the kernel memory allocator to a slab > allocator. See the Unix Frontiers books for more details and > ideas for other projects. Please see my other posting. I know it isn't a pure SLAB allocator, but the interface is we use is a SLAB interface. Also, there are many cases where a pure SLAB allocator is a very, very bad idea. Using an impure allocator could win 1.1 times performance over a SLAB allocator in the up case, and 100 to 1000 time performance in the MP 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 Sun Jan 26 13:30:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25427 for hackers-outgoing; Sun, 26 Jan 1997 13:30:47 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25422; Sun, 26 Jan 1997 13:30:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id NAA08138; Sun, 26 Jan 1997 13:30:26 -0800 (PST) Message-Id: <199701262130.NAA08138@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Luigi Rizzo cc: dyson@freebsd.org, hackers@freebsd.org Subject: Re: exec bug In-reply-to: Your message of "Sun, 26 Jan 1997 14:17:12 +0100." <199701261317.OAA28121@labinfo.iet.unipi.it> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 13:30:26 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >> In the case of NFS, the read should block indefinately. I'm not sure what >> >> will happen if the NFS is mounted "soft", however. >> > >> >that would be a major problem then! >> >> Not any more so than any other read blocking indefinately. > >I was referring to the soft case. the blocking read only leaves >the process hung, and possibly not dying at shutdown. But an nfs >'soft' read timing out with a failure, isn't it a time-bomb ? Like I said, I'm not sure what will happen. The system might just leave a zeroed page in memory which would cause execve() to return a exec format failure to the process. On the other hand, it probably will return a fault failure and cause a panic...I just don't know for sure. In any case, using 'soft' mounts for executables is a bad idea no matter how you slice it...it shouldn't kill the system, however. >> > Wouldn't it be possible to track >> >the exact reason of the fault inside the handler and avoid panicing ? >> >After all there are no performance problems at that point.. >> >> ...and just how do you tell the exec code that a page fault that occured >> while it was accessing the image header was "fatal"? The only mechanism we > >you mean "was not fatal" dont you ? No, I mean that you only take special action in the failure case, so that is the case you want to know about. >> have for this is signals, and that doesn't work when you're executing in the >> kernel like this. > >I don't know the "big picture" so this could be totally nonsense, >but how about creating a "page_probe()" function, cooperating with >the fault handler, which tries to access the page, returning 1 if >any page fault occur in the kernel address space while running ? >Then exec_aout_imgact() (or any other critical function) could >first page_probe() the required page, then either continue or fail. >There shouldn't be much penalty in doing this since at most the >page gets paged in, something that would be necessary anyways. See my last reply to Bruce. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 13:33:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25587 for hackers-outgoing; Sun, 26 Jan 1997 13:33:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25581 for ; Sun, 26 Jan 1997 13:33:01 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02297; Sun, 26 Jan 1997 14:14:46 -0700 From: Terry Lambert Message-Id: <199701262114.OAA02297@phaeton.artisoft.com> Subject: Re: fdisk headache To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 26 Jan 1997 14:14:45 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "J Wunsch" at Jan 26, 97 10:46:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Boot selectors won't work either. > > Since there's nothing to select from. ;-) > > Right now, there are three reasons to still call it ``dangerously > dedicated'': > > . Since the MBR is identical to the BSD bootstrap, there's no room for > things like `nextboot' after the MBR, and you can't replace the MBR > by fancy things like a boot selector. Hence, in a system that is > not FreeBSD-only, you could at best make drives != #0 ``DD'', and > you won't be able to boot select away from that drive once you > switched there. (Normally, booteasy allows to wander around back > and forth through all the drives.) This is evil. The purpose of the DOS MBR and partition table is to make BIOS happy and to allow multiboot. We don't do ourselves any favors by sabotoging that for other OS's. > The plus side is: [ ... ] > . The number of BIOS geometry constraints to care for reduces drastic- > ally, so you can usually (*) ignore any geometry issues. > > (*) I.e., the BIOS's geometry idea involves at least 15 sectors per > track, 4 heads, and the root file system is not larger than 30 MB. This is a bogus argument based on the assumption that we wouldn't put an absolute sector address in the partition entry like we should so a sector-offset based driver (BSD) could still use the partition table entry without multiplying out C/H/S values. Note that we should put the entry there for our parttition: we should not rely on a DOS tool to do it correctly for us. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jan 26 13:33:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25602 for hackers-outgoing; Sun, 26 Jan 1997 13:33:16 -0800 (PST) Received: from jason.garman.net (pm106-02.dialip.mich.net [192.195.231.204]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25597 for ; Sun, 26 Jan 1997 13:33:11 -0800 (PST) Received: (qmail 917 invoked by uid 1000); 26 Jan 1997 21:33:04 -0000 Message-ID: Date: Sun, 26 Jan 1997 16:33:04 -0500 From: garman@jason.garman.net (Jason Garman) To: terry@lambert.org (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? References: <199701261958.MAA02186@phaeton.artisoft.com> X-Mailer: Mutt 0.58 Mime-Version: 1.0 Reply-To: garman@phs.k12.ar.us X-Phase-Of-Moon: The Moon is Waning Gibbous (92% of Full) X-Operating-System: FreeBSD/i386 2.1.5-RELEASE In-Reply-To: <199701261958.MAA02186@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 12:58:33 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > Fax them the chip specs. and ask again. The specs imply both channels > can be active at the same time. > I have the specs sitting right in front of me (it's available in pdf format from their ftp server). Not that any tech drone I'm going to get on the phone is going to understand these specs...and why they imply that both channels can be active simultaneously. > Also, correct them: "fix the 'problem'" should be "work around the > 'problem'", since the problem will still exist. Point out to them > that you are objecting to the problem existing, not to the fact that > it can be worked around in software. > Good point. Thanks for the tip. > In general, be vocal and annoying until they do something in response > to the irritation (even if they encapsulate you in pearl by replacing > your motherboard, like an oyster would do, your problem will be solved). > I've done this type of thing before (with packard bell of all companies-- and actually got results...), so I guess I can try again. The last time I called they were `overloaded with holiday orders and tech questions' (yeah right) and would hand you off to an automated answering machine where you could leave your name and number. Needless to say, they never called back. The company is Zenon Technology, 818-935-1828. They also have an 800 number but I don't have that sitting in front of me right now... > There are two check programs. You need to search for "+IDE +CMD640" on > AltaVista. > EIDEtest you mean? I just grabbed it. Going to try it in a sec. for anyone else who's interested. Enjoy, -- Jason Garman http://www.nesc.k12.ar.us/~garman/ Student, Eleanor Roosevelt High School garman@phs.k12.ar.us From owner-freebsd-hackers Sun Jan 26 13:35:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25804 for hackers-outgoing; Sun, 26 Jan 1997 13:35:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25793 for ; Sun, 26 Jan 1997 13:35:42 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02314; Sun, 26 Jan 1997 14:16:41 -0700 From: Terry Lambert Message-Id: <199701262116.OAA02314@phaeton.artisoft.com> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 26 Jan 1997 14:16:41 -0700 (MST) Cc: proff@suburbia.net, hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Jan 26, 97 08:36:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Can anyone inform me what a SLAB allocator is, and if so, would freebsd > > benefit from one? > > It's a chunk of memory that you put multiple kernel objects of the same > type into. We have a modified mach zone allocator. They're both type > stable memory allocators. A SLAB allocator is also a modified MACH zone allocator. > I not sure how much benefit the SLAB allocator would offer over what we > have. There's some extra overhead in maintaining a SLAB. There is significant cache benefit. See Vahalia. > BTW, SLAB is used in Solaris. Yes, "pure SLAB"... and it handicaps their SMP something fierce. 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 Jan 26 13:38:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA26060 for hackers-outgoing; Sun, 26 Jan 1997 13:38:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA26055 for ; Sun, 26 Jan 1997 13:38:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02324; Sun, 26 Jan 1997 14:18:45 -0700 From: Terry Lambert Message-Id: <199701262118.OAA02324@phaeton.artisoft.com> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: dg@root.com Date: Sun, 26 Jan 1997 14:18:45 -0700 (MST) Cc: michaelh@cet.co.jp, proff@suburbia.net, hackers@FreeBSD.ORG In-Reply-To: <199701261235.EAA06772@root.com> from "David Greenman" at Jan 26, 97 04:35:36 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The allocator in BSD is designed to be as fast as possible and trades > space efficiency for performance. I'm very skeptical that a SLAB allocator > would be any faster than the current allocation algorithm, although it > would likely be more space efficient. Are you looking at the TLB overhead for SLAB? Technically, the FreeBSD allocator meets the interface criteria for SLAB, though it's not SLAB (as you point out, it's not type-stable). 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 Jan 26 13:49:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA26673 for hackers-outgoing; Sun, 26 Jan 1997 13:49:17 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA26655 for ; Sun, 26 Jan 1997 13:49:11 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02357; Sun, 26 Jan 1997 14:29:38 -0700 From: Terry Lambert Message-Id: <199701262129.OAA02357@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: tom@sdf.com (Tom Samplonius) Date: Sun, 26 Jan 1997 14:29:38 -0700 (MST) Cc: terry@lambert.org, garman@phs.k12.ar.us, freebsd-hackers@FreeBSD.org In-Reply-To: from "Tom Samplonius" at Jan 26, 97 04:34:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > See the test program on www.intel.com for the controller bug. > > I've been told by the user in question, that the ide check program from > Intel hangs on his system. Not too useful. There are two programs. I pointed at the wrong one. I posted an AltaVista search string that will find the other. > "Pure computer usage" will not be possible until a "pure computer" > exists. As it stands, sw people need to keep "adapting" to new hw bugs. Yes. And this is a case where they have not adapted, such that the user can't assume the sw platform is reliable on any hardware. I'm seperating the idea of a sw platform user from a sw user on that platform -- maybe that's the confusion? 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 Jan 26 13:58:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27031 for hackers-outgoing; Sun, 26 Jan 1997 13:58:16 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27026 for ; Sun, 26 Jan 1997 13:58:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id NAA08258; Sun, 26 Jan 1997 13:56:14 -0800 (PST) Message-Id: <199701262156.NAA08258@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: michaelh@cet.co.jp, bde@freefall.freebsd.org, Hackers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_lockf.c In-reply-to: Your message of "Sun, 26 Jan 1997 13:24:13 MST." <199701262024.NAA02217@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 13:56:14 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >This is one of the things I am always on about. > > >The call trace should be: > > fcntl(lock) <- check call syntax here > lf_advlock(lock) <- check arg values here > if( !VOP_ADVLOCK(lock)) > lf_advlock(unlock) > >And the FS specific VOP_ADVLOCK should simply return 0 in all cases for >most FS's. I disagree. The call trace should be: fcntl(lock) VOP_ADVLOCK(lock) lf_advlock(lock) This works properly with unusual filesystem stacking and is more flexible. >The veto architecture is needed to make union FS's not accidently >lf_advlock() the same vnode twice. For example, say I have a quota >and a non-quota "view" onto the same FS. The quota implementation >is a stacking layer so that all FS's can have quotas. The vnode >is passed through the quota layer, because all the quota layer does >is a name space incursion to subtract out the quota file on the FS >root. A lock on the quota vnode and the non-quota vnode would be >a lock on the same vnode. Only leaf filesystems should call lf_advlock(), so upper layers don't matter. union_advlock should just be a pass-through. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 14:01:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27228 for hackers-outgoing; Sun, 26 Jan 1997 14:01:40 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27220 for ; Sun, 26 Jan 1997 14:01:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA08317; Sun, 26 Jan 1997 14:01:12 -0800 (PST) Message-Id: <199701262201.OAA08317@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: RHS Linux User cc: freebsd-hackers@freebsd.org Subject: Re: What to do about the 2.0 GNU libc? In-reply-to: Your message of "Sun, 26 Jan 1997 12:53:09 PST." <32EBC435.63297F3E@hooked.net> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 14:01:12 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I must appologize for my past posts to this mail list. I now see that >freebsd is the way it is for a reason. Also the handling of ppp >connections in linux and most other OS's really sucks. FreeBSD has the >best implimentation I have ever seen. > >I am curious about the up and comming GNU 2.0 libc. Since the BSD's have >their own libc will you be replacing yours with the GNU one? Not that I >like GNU to much (it seams to be becomming the Microsoft of the free >software world) but it would save a lot of developement time if you >didn't have to worry about your own library. Since this the GNU libc >will be used by Linux it would be hard to go wrong. FreeBSD would be >using the same libc are it's chief competitor. FreeBSD would then only >have the userland commands to deal with, since Linux of course has GNU >maintaining those. I hate GNU binutils. No, the GNU libc is GPL'd which would cause distribution restrictions for everything that is linked with it. Unlike GNU, we actually encourage commercial re-use of FreeBSD code (in embedded systems, for example). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 14:10:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27554 for hackers-outgoing; Sun, 26 Jan 1997 14:10:03 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27538 for ; Sun, 26 Jan 1997 14:09:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA08360; Sun, 26 Jan 1997 14:07:28 -0800 (PST) Message-Id: <199701262207.OAA08360@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: michaelh@cet.co.jp, proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 14:18:45 MST." <199701262118.OAA02324@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 14:07:28 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The allocator in BSD is designed to be as fast as possible and trades >> space efficiency for performance. I'm very skeptical that a SLAB allocator >> would be any faster than the current allocation algorithm, although it >> would likely be more space efficient. > >Are you looking at the TLB overhead for SLAB? See my other reply regarding ordering of allocations. Memory that was recently freed is re-used before memory that was freed long ago, which should have both better cache effects and less TLB overhead (than the original BSD allocator). This should compare well to the slab allocator, but it would perhaps be interesting to actually do a formal comparison. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 14:16:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27945 for hackers-outgoing; Sun, 26 Jan 1997 14:16:46 -0800 (PST) Received: from jason.garman.net (pm106-09.dialip.mich.net [192.195.231.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA27931 for ; Sun, 26 Jan 1997 14:16:32 -0800 (PST) Received: (qmail 363 invoked by uid 1000); 26 Jan 1997 22:16:25 -0000 Message-ID: Date: Sun, 26 Jan 1997 17:16:25 -0500 From: garman@jason.garman.net (Jason Garman) To: terry@lambert.org (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? References: <199701261958.MAA02186@phaeton.artisoft.com> X-Mailer: Mutt 0.58 Mime-Version: 1.0 Reply-To: garman@phs.k12.ar.us X-Phase-Of-Moon: The Moon is Waning Gibbous (91% of Full) X-Operating-System: FreeBSD/i386 2.1.5-RELEASE In-Reply-To: <199701261958.MAA02186@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 12:58:33 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > There are two check programs. You need to search for "+IDE +CMD640" on > AltaVista. > EIDEtest (if that's the other one you're referring to) simply asks you to do background I/O operations on, say, the second interface drives while the program does I/O on the first interface... since that causes the machine to freeze, the same would happen here. The old rztest program that Intel put out at the beginning of all this mess didn't even test for this particular flaw, because it doesn't exist in the RZ1000 chip that it checked for. Regarding automatic detection mechanisms- FreeBSD already notices that I have the flawed chip: ... *** pci0:12: CMD, device=0x0640, class=storage (ide) int a irq 14 [no driver assigned] ... wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 696MB (1427328 sectors), 1416 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): , removable, accel, dma, iordy wcd0: 344Kb/sec, 256Kb cache, audio play, 256 volume levels, ejectable tray wcd0: medium type unknown, unlocked wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (wd2): wd2: 1916MB (3924144 sectors), 3893 cyls, 16 heads, 63 S/T, 512 B/S And as for L*nux, looking through AltaVista's search results for the query you gave me, it seems that L*nux _does_ automatically and non-destructively detect and work around the CMD 640b bugs. (no hda=serialize needed after all, apparently) Detecting a VLB board using this chip would be harder (is it even possible)? Enjoy, -- Jason Garman http://www.nesc.k12.ar.us/~garman/ Student, Eleanor Roosevelt High School garman@phs.k12.ar.us From owner-freebsd-hackers Sun Jan 26 14:28:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA28552 for hackers-outgoing; Sun, 26 Jan 1997 14:28:01 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA28540 for ; Sun, 26 Jan 1997 14:27:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA08492; Sun, 26 Jan 1997 14:25:45 -0800 (PST) Message-Id: <199701262225.OAA08492@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 14:05:45 MST." <199701262105.OAA02273@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 14:25:45 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Vahalia cites a paper: > "Efficient Kernel Memory Allocation on Shared Memory > Multiprocessors" > McKenney, P.E. and Slingwine, J. > Proceedings of USENIX, Winter, 1993 > >Which shows the sequent code to be faster than the McKusick-Karels >algorithm by a factor of three to five on a UP, and a factor of >one hundred to one thousand on a 25 processor system. I haven't read that paper, but I suspect that the numbers are wrong due to spl* having high overhead back then. Since Bruce's "fast interrupt" code, spl* is almost free, and this changes things greatly. The situation might change slightly in MP systems, but the total time inside of malloc is so small that I really doubt that synchronization/serialization will ever be a significant problem. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 14:44:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA29537 for hackers-outgoing; Sun, 26 Jan 1997 14:44:07 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA29508 for ; Sun, 26 Jan 1997 14:44:02 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id OAA17789; Sun, 26 Jan 1997 14:37:51 -0800 (PST) Message-ID: <32EBDC19.794BDF32@whistle.com> Date: Sun, 26 Jan 1997 14:35:05 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: proff@suburbia.net CC: dg@root.com, hackers@freebsd.org, alan.cox@linux.org Subject: Re: SLAB stuff, and applications to current net code (fwd) References: <19970126125747.19508.qmail@suburbia.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk proff@suburbia.net wrote: > > > >I not sure how much benefit the SLAB allocator would offer over what we > > >have. There's some extra overhead in maintaining a SLAB. > > > > > >BTW, SLAB is used in Solaris. > > > > The allocator in BSD is designed to be as fast as possible and trades > > space efficiency for performance. I'm very skeptical that a SLAB allocator > > would be any faster than the current allocation algorithm, although it > > would likely be more space efficient. > > > > -DG > > > > David Greenman > > Core-team/Principal Architect, The FreeBSD Project > > > > I presume the idea is that the cache efficiency of small allocations > would be substantially improved? > > Cheers, > Julian I talked with alan about this at the USENIX conf. He told me that originally he looked at using a BSD style allocator, but that small allocations of mbufs etc all hit the same cache lines as they were always on powers of two. (obviously) especially when working on the headers of large packets. he saw a noticable problem with cache overwrites. I didn't get it all but probably he could tell us more.. I've CC'd him. He seems very knowledgable about BSD internals and not at all the screaming fanatic that we sometimes see in the linux camp so I really enjoyed the conversation.. julian From owner-freebsd-hackers Sun Jan 26 15:02:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00470 for hackers-outgoing; Sun, 26 Jan 1997 15:02:02 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00465 for ; Sun, 26 Jan 1997 15:01:59 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id OAA18010; Sun, 26 Jan 1997 14:57:15 -0800 (PST) Message-ID: <32EBE0A4.3F54BC7E@whistle.com> Date: Sun, 26 Jan 1997 14:54:28 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: dg@root.com CC: RHS Linux User , freebsd-hackers@FreeBSD.ORG Subject: Re: What to do about the 2.0 GNU libc? References: <199701262201.OAA08317@root.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote: > > >I must appologize for my past posts to this mail list. I now see that > >freebsd is the way it is for a reason. Also the handling of ppp > >connections in linux and most other OS's really sucks. FreeBSD has the > >best implimentation I have ever seen. > > > >I am curious about the up and comming GNU 2.0 libc. Since the BSD's have > >their own libc will you be replacing yours with the GNU one? Not that I > >like GNU to much (it seams to be becomming the Microsoft of the free > >software world) but it would save a lot of developement time if you > >didn't have to worry about your own library. Since this the GNU libc > >will be used by Linux it would be hard to go wrong. FreeBSD would be > >using the same libc are it's chief competitor. FreeBSD would then only > >have the userland commands to deal with, since Linux of course has GNU > >maintaining those. I hate GNU binutils. > > No, the GNU libc is GPL'd which would cause distribution restrictions > for everything that is linked with it. Unlike GNU, we actually encourage > commercial re-use of FreeBSD code (in embedded systems, for example). > Gnu libc is LGPL'd of course, which has much lighter restrictions.. (dont ha ve to do all the source redistribution stuff for linked binaries etc.) > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Jan 26 15:27:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA01529 for hackers-outgoing; Sun, 26 Jan 1997 15:27:28 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA01524 for ; Sun, 26 Jan 1997 15:27:24 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id XAA25209; Sun, 26 Jan 1997 23:26:48 GMT Date: Mon, 27 Jan 1997 08:26:48 +0900 (JST) From: Michael Hancock To: David Greenman cc: proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701261235.EAA06772@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, David Greenman wrote: > >On Sun, 26 Jan 1997 proff@suburbia.net wrote: > > > >> Can anyone inform me what a SLAB allocator is, and if so, would freebsd > >> benefit from one? > >> > > > >It's a chunk of memory that you put multiple kernel objects of the same > >type into. We have a modified mach zone allocator. They're both type > >stable memory allocators. > > The memory allocator in BSD is *not* type-stable. For SMP it might more make sense to create typed global pools to allocate objects per zone, than putting effort into a SLAB allocator. > The allocator in BSD is designed to be as fast as possible and trades > space efficiency for performance. I'm very skeptical that a SLAB allocator > would be any faster than the current allocation algorithm, although it > would likely be more space efficient. It did seem easier to color the cache with the SLAB implementation. I don't remember the results of John's page coloring work to distribute hits in the cache. > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > From owner-freebsd-hackers Sun Jan 26 15:41:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02310 for hackers-outgoing; Sun, 26 Jan 1997 15:41:52 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA02305 for ; Sun, 26 Jan 1997 15:41:49 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id XAA25270; Sun, 26 Jan 1997 23:40:49 GMT Date: Mon, 27 Jan 1997 08:40:49 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: bde@freefall.freebsd.org, FreeBSD Hackers Subject: Re: cvs commit: src/sys/kern kern_lockf.c In-Reply-To: <199701262024.NAA02217@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, Terry Lambert wrote: > > All of the argument checking seems out of place here. The call trace is > > like this: > > > > fcntl => VOP_ADVLOCK => lf_advlock > > > > or > > > > open => VOP_ADVLOCK => lf_advlock > > > > Garbage input should be stopped at the source and lf_advlock should be > > completely free from arg checking. The original coder wanted to factor > > error checking into lf_advlock, but it seems incorrect to allow garbage to > > come in so far. > > > > A consistent division of arg checking responsibilities would make it > > easier for people to decide where to do the checks. We would need some > > comments or preconditions specified in lf_advlock to communicate what was > > expected so that we would know what to do in fcntl and open. > > > > Any comments? > > Yes. The syntactic checking should be in the system call layer, and > the grammatic checking should be in the lf_advlock layer, which should > be called from the system call layer. [..] > The call trace should be: > > fcntl(lock) <- check call syntax here > lf_advlock(lock) <- check arg values here > if( !VOP_ADVLOCK(lock)) > lf_advlock(unlock) > [..] > The place for the checking is either fcntl + open, or lf_advlock, > depending on who pulls the arguments in. Taking the preposterous lengths checking example, checking isn't necessary in open case since it is initialized to zero in the body of open. The cases you need to check are directly triggered externally in fcntl by user programs. This is why I think arg values should be checked at the system call level in this case. Regards, Mike From owner-freebsd-hackers Sun Jan 26 15:42:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02337 for hackers-outgoing; Sun, 26 Jan 1997 15:42:00 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA02329 for ; Sun, 26 Jan 1997 15:41:56 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id PAA09975; Sun, 26 Jan 1997 15:41:53 -0800 (PST) To: grog@lemis.de (Greg Lehey) cc: hackers@freebsd.org (FreeBSD Hackers), isdn@muc.ditec.de (FreeBSD ISDN Distribution List) Subject: Re: bisdn In-reply-to: Your message of "Sun, 26 Jan 1997 15:59:08 +0100." <199701261459.PAA04577@freebie.lemis.de> Date: Sun, 26 Jan 1997 15:41:53 -0800 Message-ID: <9971.854322113@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I don't think that the problems are technical so much as political, something which generally sucks given that the last thing the free software community needs to be doing is shooting its feet off and generally handing the boys at microsoft an even more overwhelming advantage ("you can't crush us! hah! we plan to commit suicide through sheer stupidity and ego way before we'll let that happen!" :-) Oh well. Sigh! :-) Jordan > Jordan K. Hubbard writes: > >> and greatly appreciated, too ! Several people will be working on getting > >> this integrated into -current (aka 3.0). > > > > Really? Awesome! I'd just about given up! :-) > > What's the problem? I've been running bisdn on 2.2-CURRENT and > 3.0-CURRENT since last May. > > Greg > From owner-freebsd-hackers Sun Jan 26 15:50:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02827 for hackers-outgoing; Sun, 26 Jan 1997 15:50:48 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA02818 for ; Sun, 26 Jan 1997 15:50:45 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA24199; Sun, 26 Jan 1997 18:50:13 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sun, 26 Jan 1997 18:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id PAA01530 for ; Sun, 26 Jan 1997 15:29:05 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id PAA00352 for freebsd-hackers@freefall.cdrom.com; Sun, 26 Jan 1997 15:33:00 -0500 (EST) Date: Sun, 26 Jan 1997 15:33:00 -0500 (EST) From: Thomas David Rivers Message-Id: <199701262033.PAA00352@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Problems bootin 3.0 SNAP-970124. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just a quick problem report. I found that I was unable to boot the SNAP without disabling ed1. I have a different setup- ed0 is in irq 9 (2), at port 0x300. So, the default probe doesn't find it; and the probe for ed1 will "find" it - but it's irq will be wrong. Apparently, this causes the ed1 probe to lock up.... - Dave Rivers - From owner-freebsd-hackers Sun Jan 26 16:50:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA07951 for hackers-outgoing; Sun, 26 Jan 1997 16:50:52 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA07946 for ; Sun, 26 Jan 1997 16:50:49 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA14004 for freebsd-hackers@FreeBSD.ORG; Mon, 27 Jan 1997 01:50:47 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id BAA08259; Mon, 27 Jan 1997 01:27:04 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 01:27:03 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: fdisk headache References: <199701262114.OAA02297@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701262114.OAA02297@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 14:14:45 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > Right now, there are three reasons to still call it ``dangerously > > dedicated'': > > > > . Since the MBR is identical to the BSD bootstrap, there's no room for > > things like `nextboot' after the MBR, and you can't replace the MBR > > by fancy things like a boot selector. > This is evil. You consider it evil -- some (many?) others don't. See the first sentence above: it's called ``dangerously'' dedicated mode. It's just for those who want and love this way. Those who prefer fighting against braindead 1024-cylinder or foobar megabyte limits are free to do so, and we even do them the favour to make these struggles (i.e., the DOS-compatible way) the default variant. -- 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 Jan 26 16:51:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA07975 for hackers-outgoing; Sun, 26 Jan 1997 16:51:01 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA07970 for ; Sun, 26 Jan 1997 16:50:59 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA14006 for freebsd-hackers@freebsd.org; Mon, 27 Jan 1997 01:50:51 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id BAA08268; Mon, 27 Jan 1997 01:29:18 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 01:29:17 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: fdisk headache References: <199701262114.OAA02297@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701262114.OAA02297@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 14:14:45 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > . The number of BIOS geometry constraints to care for reduces drastic- > > ally, so you can usually (*) ignore any geometry issues. > This is a bogus argument based on the assumption that we wouldn't put > an absolute sector address in the partition entry like we should so > a sector-offset based driver (BSD) could still use the partition > table entry without multiplying out C/H/S values. > > Note that we should put the entry there for our parttition: we should > not rely on a DOS tool to do it correctly for us. p.s.: You apparently don't understand what i'm writing about. There's no DOS tool ever involved in DD mode (and little red daemons will jump out of the disk if you ever come close to those disks with some DOS tool at all :-). -- 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 Jan 26 16:51:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08012 for hackers-outgoing; Sun, 26 Jan 1997 16:51:16 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA08002 for ; Sun, 26 Jan 1997 16:51:13 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id TAA20481; Sun, 26 Jan 1997 19:51:03 -0500 (EST) From: "John S. Dyson" Message-Id: <199701270051.TAA20481@dyson.iquest.net> Subject: Re: What is the default for async in /etc/fstab? To: dicen@hooked.net (RHS Linux User) Date: Sun, 26 Jan 1997 19:51:03 -0500 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <32EBC635.4F86F1D5@hooked.net> from "RHS Linux User" at Jan 26, 97 01:01:41 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Have other people tested ufs vs. ext2? The only docs I could find where > for ext2. A comparison with FreeBSD 2.0 I think, although it could have > been older. This was for some old Linux 1.xx. > The performance that I have measured (sequential -- IOZONE) is that FreeBSD is faster in both read/write. However, our metadata performance is slower (filecreates/deletes.) With -async, our metadata is still slower, but not by orders of magnitude. FreeBSD's cache perf is much faster (by factors of 3-4.) Much of it is due to the default block size (8K vs. 1K.) But the fragment size of an 8K UFS filesystem is the *same* as a 1K ext2fs. Both are very fast though. John From owner-freebsd-hackers Sun Jan 26 16:54:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08245 for hackers-outgoing; Sun, 26 Jan 1997 16:54:23 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA08228 for ; Sun, 26 Jan 1997 16:54:18 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA14101; Mon, 27 Jan 1997 01:54:13 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id BAA08470; Mon, 27 Jan 1997 01:46:40 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 01:46:40 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: dicen@hooked.net (RHS Linux User) Cc: freebsd-hackers@freebsd.org Subject: Re: What is the default for async in /etc/fstab? References: <32EBC635.4F86F1D5@hooked.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32EBC635.4F86F1D5@hooked.net>; from RHS Linux User on Jan 26, 1997 13:01:41 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As RHS Linux User wrote: ^^^^^^^^^^^^^^ What a weird name. :-/ > So what is the default for async in the 2.1 > /etc/fstab? j@uriah 1204% fgrep async /etc/fstab /dev/sd1g /usr/release ufs rw,async 0 4 /dev/sd1h /tmp ufs rw,async 0 3 -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Jan 26 17:35:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA10163 for hackers-outgoing; Sun, 26 Jan 1997 17:35:34 -0800 (PST) Received: from llaic.univ-bpclermont.fr (llaic.univ-bpclermont.fr [192.54.142.163]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA10146 for ; Sun, 26 Jan 1997 17:35:22 -0800 (PST) Message-Id: <199701270135.RAA10146@freefall.freebsd.org> Received: by llaic.univ-bpclermont.fr (1.38.193.4/16.2) id AA28403; Mon, 27 Jan 1997 02:34:52 +0100 From: Roger Espel Llima Subject: Re: hackers-digest V3 #36 To: hackers@freefall.freebsd.org Date: Mon, 27 Jan 1997 02:34:51 +0100 (MET) In-Reply-To: <199701262133.NAA25596@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Jan 26, 97 01:33:06 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I am curious about the up and comming GNU 2.0 libc. Since the BSD's have > their own libc will you be replacing yours with the GNU one? Not that I > like GNU to much (it seams to be becomming the Microsoft of the free > software world) but it would save a lot of developement time if you > didn't have to worry about your own library. Since this the GNU libc > will be used by Linux it would be hard to go wrong. FreeBSD would be > using the same libc are it's chief competitor. FreeBSD would then only > have the userland commands to deal with, since Linux of course has GNU > maintaining those. Not only the userland commands -- what about the kernel? I don't really think FreeBSD should change to a completely different libc; the GNU libc has some very nice features (reentrancy...) but a system's libc is usually very closely tied to the kernel, so it's good that the same team (or almost...) develops both, as is the case with FreeBSD. > I hate GNU binutils. Really? GNU binutils are gcc, gas, ld and other related commands (nm, objdump...). Are you sure you don't mean GNU fileutils? (ls, cp, rm and all those). I personally like the GNU fileutils and their BSD equivalents pretty much the same. > The next question is. Is the GNU libc 2.0 being ported? I saw that > someone was doing a port for BSDI2.0, is this not the same as FreeBSD? A port for BSDi could probably be adapted very easily for FreeBSD. Even if it isn't used as the default libc, a port is always a good thing... > I am very interested the GNU libc 2.0 for its posix threads and the fact > that it is rentrant (which it has to be of course for threads). What is > the status of kernel-threads in FreeBSD? I heard that you where getting > there. Current kernels already support rfork(), which should be the basis for kernel threads just like clone() is under Linux. > Since you have linux compatibility (except for clone() right?) would it > not be possible to just use the GNU libc 2.0 the way it is? Does it ever > have to be ported? I am sure Linux will always have presidence with GNU > anyway. This of course looks really bad since eventually freebsd will > have linux's kernel calls. But think about it. It is only externel, just > as the GNU libc is externel. Is FreeBSD BSD without the BSD libc? Good > question. That just means that when Linux starts using GNU libc 2.0 (aka Linux libc 6.0), FreeBSD's linux compatibility libc will be changed to a copy of it. That isn't the one BSD commands use though, obviously. Roger -- e-mail: roger.espel.llima@ens.fr WWW page & PGP key: http://www.eleves.ens.fr:8080/home/espel/index.html From owner-freebsd-hackers Sun Jan 26 17:36:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA10284 for hackers-outgoing; Sun, 26 Jan 1997 17:36:45 -0800 (PST) Received: from notes.bookcase.com (root@notes.bookcase.com [207.22.115.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA10269 for ; Sun, 26 Jan 1997 17:36:42 -0800 (PST) Received: from localhost (chadf@localhost) by notes.bookcase.com (8.6.12/8.6.12) with SMTP id TAA02200 for ; Sun, 26 Jan 1997 19:38:39 -0500 Date: Sun, 26 Jan 1997 20:38:38 -0400 (EDT) From: "Chad M. Fraleigh" X-Sender: chadf@notes To: freebsd-hackers@freebsd.org Subject: Re: Local X packages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 21 Jan 1997, John Fieber wrote: > compile with X11R6, I don't ever want to see another imake file! The first time I saw Imakefiles I hated them. I mean for something that is suppose to make things more portable and easier, it seems to be very good at making things harder. > However, if someone can figure out how to do it, I'm sure many > would be *very* grateful; it takes me far longer to upgrade X > than it does the rest of FreeBSD, and something always gets > spammed in the process. Since I refuse to install most X packages in the /usr/X11R6 directory (I think xview was my only expection I've made). While doing this is sometimes a pain because I have to modify several files, for the most part it's trival. Adding these lines at the begining of the Imakefile (or .tmpl if there is one) file after doing the patches and before doing the configure will probably fix about 80-90% of them: BINDIR = $(PREFIX)/bin MANPATH = $(PREFIX)/man LIBDIR = $(PREFIX)/lib/X11 INCROOT = $(PREFIX)/include TOP_INCLUDES = -I$(PREFIX)/include -I/usr/X11R6/include -I/usr/local/include EXTRA_LIBRARIES = -L/usr/local/lib I don't see why this couldn't easily be added to the patches for each package. Of course to fully integrate this would reguire that it's don't to all the applications first, and then to the libraries (like xpm, xview, etc..). That way you don't break anything that expects them in /usr/X11R6 when they're in /usr/local. Since I'm using $(PREFIX) instead of /usr/local I need to do my makes with PREFIX=/usr/local to override it using /usr/X11R6 when USE_IMAKE is set. To impliment it for the real thing a new setting would be needed (perhaps IMAKE_PREFIX with a default of /usr/X11R6) that could be set in their environment. -Chad From owner-freebsd-hackers Sun Jan 26 17:45:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA10779 for hackers-outgoing; Sun, 26 Jan 1997 17:45:53 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA10773 for ; Sun, 26 Jan 1997 17:45:48 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id RAA19636 for ; Sun, 26 Jan 1997 17:42:26 -0800 (PST) Message-ID: <32EC0752.446B9B3D@whistle.com> Date: Sun, 26 Jan 1997 17:39:30 -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: Why is this not a kernel memory leak? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk in route.c in rtrequest() in the RTM_DELETE: clause. the clause ends with: /* * If the caller wants it, then it can have it, but it's * up to it to free the rtentry as we won't be doing it. */ if (ret_nrt) *ret_nrt = rt; else if (rt->rt_refcnt <= 0) { rt->rt_refcnt++; /* make a 1->0 transition */ rtfree(rt); } break; now in the case when (ret_nrt) is NULL, and the reference count is 1, we never call rtfree(rt). If we did, the count would go to 0 and the block would be freed, which, since we are trying to delete it would seem a reasonable thing.. why leave the eference count as 1? doesn't this defeat the whole point of reference counts? This smells of "kludge" to me.. I'm going to go hunting and hopefully I can find out what's going on enough to clean up the ref counts enough so that they become useful again.. julian From owner-freebsd-hackers Sun Jan 26 18:19:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11695 for hackers-outgoing; Sun, 26 Jan 1997 18:19:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA11655 for ; Sun, 26 Jan 1997 18:18:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA02602; Sun, 26 Jan 1997 18:57:06 -0700 From: Terry Lambert Message-Id: <199701270157.SAA02602@phaeton.artisoft.com> Subject: Re: cvs commit: src/sys/kern kern_lockf.c To: dg@root.com Date: Sun, 26 Jan 1997 18:57:05 -0700 (MST) Cc: terry@lambert.org, michaelh@cet.co.jp, bde@freefall.freebsd.org, Hackers@freebsd.org In-Reply-To: <199701262156.NAA08258@root.com> from "David Greenman" at Jan 26, 97 01:56:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >This is one of the things I am always on about. > > > > > >The call trace should be: > > > > fcntl(lock) <- check call syntax here > > lf_advlock(lock) <- check arg values here > > if( !VOP_ADVLOCK(lock)) > > lf_advlock(unlock) > > > >And the FS specific VOP_ADVLOCK should simply return 0 in all cases for > >most FS's. > > I disagree. The call trace should be: > > fcntl(lock) > VOP_ADVLOCK(lock) > lf_advlock(lock) > > This works properly with unusual filesystem stacking and is more flexible. ??? How so? Can you give me a stacking situation example where this would be true? The Heidemann paper specifically references null function bodies in a layering design, and the Rosental paper specifically talks about "collapsing" call graphs for null function elements in layers. I can think of several layers where you would want to affect the data operands, but not the hierarchy operands: an encryption layer, etc.. I can also think of several situations where you would want ti affect the hiearchy operands instead of the data operands: a quota layer, an ACL layer, a UMSDOS attribution layer, etc.. I can think of no situation in which I would want to hit the wire for a network FS call, when the given operation will fail remotely and will also fail locally (ie: VOP_ADVLOCK). All you succeed in doing is increasing latency, for no good reason. We can discuss the race conditions using this same call-down type of implementation in VOP_LOCK for directory traversal in an MSDOSFS, and the possibility for error when each FS implementor is required to reimplement upcalls (violating the abstract interface definition) in an identical way. These are obvious, and the related PR's are long-standing. Further, we can identify issues of NFS export resulting from the same style of coding in the mount calls being expected to process the exposed mount points, and of root vs. non-root FS mouninting being valid in some FS's and not in others because of the absurd per FS reimplementation requirements. If even we accepted you as being correct, we could implement the toplogically equivalent arrangement in a veto architecture by mounting an "advisory locking implementation layer" immediately above the terminal layer, and have it make the lf_advlock calls instead. Finally, this neglects fan-out architectures in which there may be a pseudo-vnode as a container object for more than one underlying vnode: it is necessary to lock the container object as well, since a user can legally have a "view" onto any FS "root" in any stack of FS layers (indeed, this *must* happen for most of the existing FS's NFS export implementations). > Only leaf filesystems should call lf_advlock(), so upper layers don't > matter. union_advlock should just be a pass-through. This assumes that a leaf element is rigidly defined (ie: it assumes that the bottom end of the stack will directly access media via a system specific mechanism for doing raw I/O). In the Rosenthal paper, a design is discussed where the bottom end is the same interface as the top end, even for nodes that structure storage. You can think of the bottom ends layer being a layer with a flat name space (not imposing directory hierarchy) and the namespace as being numeric (this is one of the problems with the current "FS responsible for namei buffer deallocation" scheme -- it implies a buffer as opposed to some otherwise opaque layer specific statite). In reality, the bottom end system interface wants to be system specific, but the design of a VFS layer itself (even one like UFS) doesn't want to be system specific. Ie: the FFS module should operate the same way without regard to whether it's running in a Linux environment, or a BSD environment, or a Windows environment: it shouldn't matter. We can see the beginnings of this by looking at the existing FFS/UFS layering split, where the imposition of a directory hierarchy is done in a seperate stacking layer (UFS) from the imposition of a flat numeric name space layer (FFS inodes). It is eminently logical to extend this to the idea that a flat numeric namespace of groups of blocks (the inode layer) be implemented on a flat numeric namespace of blocks (that is, device access via VFS interface). We can either decide that the current UFS/FFS interface is wrong, or we can decide that the current FFS/VM interface is wrong. Since the former is more flexible, it's an easy choice to make. This is also why it's a mistake to make FFS/UFS specific code for the "soft updates" implementation: it seperates the UFS-with-soft-updates used by FFS from the UFS-without-soft-updates used by LFS, and is a move *away* from code reuse. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jan 26 18:58:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12777 for hackers-outgoing; Sun, 26 Jan 1997 18:58:32 -0800 (PST) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA12766 for ; Sun, 26 Jan 1997 18:57:53 -0800 (PST) Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id UAA20141; Sun, 26 Jan 1997 20:56:21 -0600 Message-Id: <3.0.1.32.19970126205619.00684ee4@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 beta 7 (32) Date: Sun, 26 Jan 1997 20:56:19 -0600 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), graichen@rzpd.de (Thomas Graichen) From: Tony Overfield Subject: Re: magic of western digital disks ... ? Cc: tech@OpenBSD.org, hackers@FreeBSD.org In-Reply-To: References: <199701191244.NAA00878@prospero.at.home> <199701191244.NAA00878@prospero.at.home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: >As Thomas Graichen wrote: >> ...on another machine i get errors like "hard error reading block >> ..." - but the disk is completely ok and works fine with FreeBSD - >> it also works fine if it is entered into the bios (... btw. after >> getting the "hard error ..." messages i was short before throwing >> the disk away - until i discovered that setting it in the bios >> helped :-) > >This sounds like an initialization problem. If you register it with >the BIOS, the BIOS does some initialization on the disk. Specifically, many IDE drives will not accept media (read/write) commands until a geometry has been specified using the INITIALIZE DEVICE PARAMETERS (0x91) command. A BIOS will always do this for drives that it recognizes. The FreeBSD driver issues this command, but perhaps the OpenBSD driver doesn't (I haven't looked at it). From owner-freebsd-hackers Sun Jan 26 19:48:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA14704 for hackers-outgoing; Sun, 26 Jan 1997 19:48:19 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA14696 for ; Sun, 26 Jan 1997 19:48:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA04555; Sun, 26 Jan 1997 20:31:08 -0700 From: Terry Lambert Message-Id: <199701270331.UAA04555@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: garman@phs.k12.ar.us Date: Sun, 26 Jan 1997 20:31:08 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: from "Jason Garman" at Jan 26, 97 05:16:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > And as for L*nux, looking through AltaVista's search results for the query > you gave me, it seems that L*nux _does_ automatically and > non-destructively detect and work around the CMD 640b bugs. (no > hda=serialize needed after all, apparently) > > Detecting a VLB board using this chip would be harder (is it even > possible)? Well, for PCI, yes. For VLB, there's no slot identification data (which is why, like ISA, it sucks). If the Linux code is working around the hardware problem, it probably has code to detect it, which you could examine to determine their algorithm. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jan 26 20:37:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA16604 for hackers-outgoing; Sun, 26 Jan 1997 20:37:59 -0800 (PST) Received: from threadway.teeny.org (root@threadway.teeny.org [204.245.200.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA16597 for ; Sun, 26 Jan 1997 20:37:55 -0800 (PST) Received: from localhost (downsj@localhost.teeny.org [127.0.0.1]) by threadway.teeny.org (8.8.5/8.6.12) with ESMTP id UAA00246; Sun, 26 Jan 1997 20:36:21 -0800 (PST) Message-Id: <199701270436.UAA00246@threadway.teeny.org> To: Tony Overfield cc: Joerg Wunsch , Thomas Graichen , tech@openbsd.org, hackers@freebsd.org Subject: Re: magic of western digital disks ... ? In-reply-to: Your message of "Sun, 26 Jan 1997 20:56:19 CST." <3.0.1.32.19970126205619.00684ee4@bugs.us.dell.com> Date: Sun, 26 Jan 1997 20:36:19 -0800 From: Jason Downs Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <3.0.1.32.19970126205619.00684ee4@bugs.us.dell.com>, Tony Overfield writes: >J Wunsch wrote: >>As Thomas Graichen wrote: >>> ...on another machine i get errors like "hard error reading block >>> ..." - but the disk is completely ok and works fine with FreeBSD - >>> it also works fine if it is entered into the bios (... btw. after >>> getting the "hard error ..." messages i was short before throwing >>> the disk away - until i discovered that setting it in the bios >>> helped :-) >> >>This sounds like an initialization problem. If you register it with >>the BIOS, the BIOS does some initialization on the disk. > >Specifically, many IDE drives will not accept media (read/write) >commands until a geometry has been specified using the INITIALIZE >DEVICE PARAMETERS (0x91) command. A BIOS will always do this for >drives that it recognizes. The FreeBSD driver issues this command, >but perhaps the OpenBSD driver doesn't (I haven't looked at it). Yes, it does. It wouldn't exactly conform to specs if it didn't. The OpenBSD driver runs disks on things like Amigas, which in way have any sort of BIOS sending initialization commands. -- Jason Downs (503) 256-8535 -/- (503) 952-3749 downsj@teeny.org --> teeny.org: Free Software for a Free Internet <-- http://www.teeny.org/ Little. Yellow. Secure. http://www.openbsd.org/ From owner-freebsd-hackers Sun Jan 26 21:50:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18301 for hackers-outgoing; Sun, 26 Jan 1997 21:50:38 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18296 for ; Sun, 26 Jan 1997 21:50:35 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id FAA27728; Mon, 27 Jan 1997 05:49:42 GMT Date: Mon, 27 Jan 1997 14:49:41 +0900 (JST) From: Michael Hancock To: proff@suburbia.net cc: hackers@freebsd.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, Michael Hancock wrote: > On Sun, 26 Jan 1997 proff@suburbia.net wrote: > > > Can anyone inform me what a SLAB allocator is, and if so, would freebsd > > benefit from one? > > > > It's a chunk of memory that you put multiple kernel objects of the same > type into. We have a modified mach zone allocator. They're both type > stable memory allocators. Oops, as David mentioned, I goofed. The major objects are mach zone and when freed can be allocated as another type later on. The way vnodes are allocated and deallocated is almost TSM, if it weren't for the special allocation case when more vnodes are needed than originally allocated at boot. I'll have to look into how Solaris' SLAB deallocates memory, it's probably not TSM either. Regards, Mike Hancock From owner-freebsd-hackers Sun Jan 26 21:56:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18467 for hackers-outgoing; Sun, 26 Jan 1997 21:56:27 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18462 for ; Sun, 26 Jan 1997 21:56:22 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id QAA25341; Mon, 27 Jan 1997 16:53:51 +1100 Date: Mon, 27 Jan 1997 16:53:51 +1100 From: Bruce Evans Message-Id: <199701270553.QAA25341@godzilla.zeta.org.au> To: dicen@hooked.net, toor@dyson.iquest.net Subject: Re: What is the default for async in /etc/fstab? Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Have other people tested ufs vs. ext2? The only docs I could find where >> ... >The performance that I have measured (sequential -- IOZONE) is that >FreeBSD is faster in both read/write. However, our metadata performance >is slower (filecreates/deletes.) With -async, our metadata is still >slower, but not by orders of magnitude. FreeBSD's cache perf is much >faster (by factors of 3-4.) Much of it is due to the default block >size (8K vs. 1K.) But the fragment size of an 8K UFS filesystem is >the *same* as a 1K ext2fs. In my tests, ext2fs is fastest for huge sequential i/o's when the block sizes are closer (8K vs 4K), but there was only a small difference (less than 10%) between the best and worst cases (best: ext2fs under FreeBSD, next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, which was 66% faster under Linux than under FreeBSD. Cache performance also catches up (46MB/sec for FreeBSD-current-last-November, 41MB/sec for Linux-2.0.20). A 4K fragment size wastes space probably wastes time in most cases. Bruce From owner-freebsd-hackers Sun Jan 26 23:56:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA24793 for hackers-outgoing; Sun, 26 Jan 1997 23:56:29 -0800 (PST) Received: from weenix.guru.org (kmitch@unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA24788 for ; Sun, 26 Jan 1997 23:56:25 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id CAA03562 for hackers@freebsd.org; Mon, 27 Jan 1997 02:56:24 -0500 (EST) From: Keith Mitchell Message-Id: <199701270756.CAA03562@weenix.guru.org> Subject: DUMP problem To: hackers@freebsd.org Date: Mon, 27 Jan 1997 02:56:23 -0500 (EST) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Every so often, I get dump errors from amanda: | DUMP: Date of this level 1 dump: Mon Jan 27 00:32:08 1997 | DUMP: Date of last level 0 dump: Sun Jan 26 16:15:36 1997 | DUMP: Dumping /dev/rsd2g (/var) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 11763 tape blocks. | DUMP: too many slaves, 1 (recompile smaller): Resource temporarily unavailab le | DUMP: The ENTIRE dump is aborted. Does anyone know how to fix this too many slaves error condition that keeps popping up?? From owner-freebsd-hackers Mon Jan 27 00:08:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA25173 for hackers-outgoing; Mon, 27 Jan 1997 00:08:32 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25096; Mon, 27 Jan 1997 00:05:14 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id IAA28518; Mon, 27 Jan 1997 08:05:07 GMT Date: Mon, 27 Jan 1997 17:05:07 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: David Greenman cc: FreeBSD Hackers , freebsd-smp@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701262225.OAA08492@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Added cc to smp] On Sun, 26 Jan 1997, David Greenman wrote: > >Vahalia cites a paper: > > "Efficient Kernel Memory Allocation on Shared Memory > > Multiprocessors" > > McKenney, P.E. and Slingwine, J. > > Proceedings of USENIX, Winter, 1993 > > > >Which shows the sequent code to be faster than the McKusick-Karels > >algorithm by a factor of three to five on a UP, and a factor of > >one hundred to one thousand on a 25 processor system. > > I haven't read that paper, but I suspect that the numbers are wrong due > to spl* having high overhead back then. Since Bruce's "fast interrupt" code, > spl* is almost free, and this changes things greatly. The situation might > change slightly in MP systems, but the total time inside of malloc is so small > that I really doubt that synchronization/serialization will ever be a > significant problem. > If subsystems used TSM it would be faster still at the expense of being even less space efficient. Objects would never be free'd in the malloc/free sense, but put on a typed free list. The operations of moving from list to list is even cheaper than malloc/free and synchronization/serialization is easier, even more so in MP environments. In this case, the performance of malloc/free would be largely irrelevant. However, the underlying allocator's ability to distribute hot objects across the processor cache might become more important. TSM probably wouldn't go over with those that want to run FBSD on systems with 8MB of RAM. It'd probably be the way to go for SMP systems though. BTW, SLAB isn't type stable either. There's an operation kmem_cache_reap() that returns a SLAB whose objects are all free to the page level allocator. TSM on top of a SLAB allocator might be interesting. It would negate the extra management overhead of the SLABs and be able to take advantage of processor cache coloring at the same time. Regards, Mike Hancock From owner-freebsd-hackers Mon Jan 27 00:09:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA25238 for hackers-outgoing; Mon, 27 Jan 1997 00:09:26 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25233 for ; Mon, 27 Jan 1997 00:09:22 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id IAA28611; Mon, 27 Jan 1997 08:08:59 GMT Date: Mon, 27 Jan 1997 17:08:59 +0900 (JST) From: Michael Hancock To: Bruce Evans cc: dicen@hooked.net, freebsd-hackers@freebsd.org Subject: Re: What is the default for async in /etc/fstab? In-Reply-To: <199701270553.QAA25341@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Bruce Evans wrote: > In my tests, ext2fs is fastest for huge sequential i/o's when the block > sizes are closer (8K vs 4K), but there was only a small difference (less > than 10%) between the best and worst cases (best: ext2fs under FreeBSD, > next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, next: and worst: are the same here. ;-) From owner-freebsd-hackers Mon Jan 27 00:52:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26456 for hackers-outgoing; Mon, 27 Jan 1997 00:52:31 -0800 (PST) Received: from pegasus.my.domain (sole-11.ppp.hooked.net [206.80.9.203]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26451 for ; Mon, 27 Jan 1997 00:52:28 -0800 (PST) Received: from pegasus.my.domain (localhost [127.0.0.1]) by pegasus.my.domain (8.7.6/8.7.3) with SMTP id AAA00605 for ; Mon, 27 Jan 1997 00:52:53 -0800 Message-ID: <32EC6CE5.64E60DE1@hooked.net> Date: Mon, 27 Jan 1997 00:52:53 -0800 From: dicen X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i686) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Performance of ufs vs. ext2. References: <199701270553.QAA25341@godzilla.zeta.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > >> Have other people tested ufs vs. ext2? The only docs I could find where > >> ... > >The performance that I have measured (sequential -- IOZONE) is that > >FreeBSD is faster in both read/write. However, our metadata performance > >is slower (filecreates/deletes.) With -async, our metadata is still > >slower, but not by orders of magnitude. FreeBSD's cache perf is much > >faster (by factors of 3-4.) Much of it is due to the default block > >size (8K vs. 1K.) But the fragment size of an 8K UFS filesystem is > >the *same* as a 1K ext2fs. > > In my tests, ext2fs is fastest for huge sequential i/o's when the block > sizes are closer (8K vs 4K), but there was only a small difference (less > than 10%) between the best and worst cases (best: ext2fs under FreeBSD, > next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, > which was 66% faster under Linux than under FreeBSD. Cache performance > also catches up (46MB/sec for FreeBSD-current-last-November, 41MB/sec > for Linux-2.0.20). A 4K fragment size wastes space probably wastes time > in most cases. > > Bruce Okay cool some real numbers. When you speak of "rewrite" are you talking about the creation and deletion of files (Metadata)? There seams to be a significant speed difference between the creation and deletion of files on linux ext2 vs. Freebsd ufs. Linux ext2 is way faster. I suppose I could just run ext2 under FreeBSD right? It sure would make a "make world" faster. You know if someone were to setup a news server it would seam to make more sence to use ext2. From owner-freebsd-hackers Mon Jan 27 00:52:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26494 for hackers-outgoing; Mon, 27 Jan 1997 00:52:47 -0800 (PST) Received: from mailserv.tversu.ac.ru (root@mailserv.tversu.ac.ru [193.233.128.3]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA26476 for ; Mon, 27 Jan 1997 00:52:38 -0800 (PST) Received: from localhost (vadim@localhost) by mailserv.tversu.ac.ru (8.6.12/8.6.12) with SMTP id LAA15371 for ; Mon, 27 Jan 1997 11:53:57 +0300 Date: Mon, 27 Jan 1997 11:53:54 +0300 (MSK) From: Vadim Kolontsov To: hackers@freebsd.org Subject: in_rtqtimo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, what does this kernel message mean? /kernel: in_rtqtimo: adjusted rtq_reallyold to 2400 Best regards, Vadim. -------------------------------------------------------------------------- Vadim Kolontsov SysAdm/Programmer Tver Regional Center of New Information Technologies Networks Lab From owner-freebsd-hackers Mon Jan 27 01:10:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA27118 for hackers-outgoing; Mon, 27 Jan 1997 01:10:03 -0800 (PST) Received: from clipper.cs.kiev.ua (root@cs-demon.ua.net [193.124.48.251]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA27085 for ; Mon, 27 Jan 1997 01:09:48 -0800 (PST) Received: from dog.farm.org by clipper.cs.kiev.ua with uucp id m0von18-000t3EC; Mon, 27 Jan 97 11:06 WET Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id AAA00505; Mon, 27 Jan 1997 00:57:34 -0800 (PST) Date: Mon, 27 Jan 1997 00:57:34 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199701270857.AAA00505@dog.farm.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: freebsd-hackers@freebsd.org Subject: Re: help for a floppy boot sector Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701261035.LAA27794@labinfo.iet.unipi.it> you wrote: > I am looking for some floppy boot code which allows you to build a > bootable floppy which can start a .COM file without the need for MSDOS. I have written just this thing for the same reason - a standalone .COM-file loader which is smart enough to read MSDOS FAT from a floppy and load a single file. It fits into 512 bytes. It's available (with source code) from: ftp://ftp.cs.kiev.ua/csrt/unix/dkbooter-1.0.zip [ I beleive I have announced this some time ago on -hackers. ] The source code uses DOS TASM, but rewrite to GAS should be easy. (ask me if you need it). > Ideally I would do something like > cat bootcode nb8390.com | dd of=/dev/fd0a > to produce a bootable floppy. oh, with my code, you have to do: ; mformat a: ; dd if=dkboot of=/dev/fd0a bs=1b ; mcopy nb8390.com a:loader.com p.s. because that site can be slow, I have uploaded a copy into ftp://ftp.freebsd.org/pub/FreeBSD/incoming/dkbooter-1.0.zip -- "I want to die peacefully in my sleep like my grandfather. Not screaming in terror like his passengers." From owner-freebsd-hackers Mon Jan 27 01:58:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA28632 for hackers-outgoing; Mon, 27 Jan 1997 01:58:15 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA28627 for ; Mon, 27 Jan 1997 01:58:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA32722; Mon, 27 Jan 1997 20:52:47 +1100 Date: Mon, 27 Jan 1997 20:52:47 +1100 From: Bruce Evans Message-Id: <199701270952.UAA32722@godzilla.zeta.org.au> To: bde@zeta.org.au, michaelh@cet.co.jp Subject: Re: What is the default for async in /etc/fstab? Cc: dicen@hooked.net, freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> In my tests, ext2fs is fastest for huge sequential i/o's when the block >> sizes are closer (8K vs 4K), but there was only a small difference (less >> than 10%) between the best and worst cases (best: ext2fs under FreeBSD, >> next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, > >next: and worst: are the same here. ;-) Oops. worst: ufs under FreeBSD. Here is the data. Environment: - ASUS P5/133, 32MB, 2.1GB Quantum FireballTM IDE drive with identical configurations under FreeBSD and Linux (16 sectors/interrupt, 32-bit i/o, PIO mode 4). - all on the same empty partition (except mke2fs puts lost+found there) at offset about 320MB and size about 1024MB. - I thought I used the same block size of 4K in all cases, but some of my notes say that I used 8K for ufs. The ufs fragment size was certainly not 4K as it should have been to match the ext2fs fragment size. bonnie.ext2fs-under-freebsd-current (fs block size 4K) ----------------------------------- -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 512 3786 71.8 5220 18.7 1556 9.1 3904 70.7 5204 14.5 47.6 2.8 bonnie.ext2fs-under-linux-2.0.20 (fs block size 4K) -------------------------------- -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 512 3836 96.2 4517 25.0 2500 35.0 3488 91.2 5156 19.8 44.8 2.0 bonnie.ufs-under-freebsd-current (fs block/frag size 8K/1K or 4K/?) -------------------------------- -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 512 3543 70.9 4627 19.1 1459 8.1 3891 70.5 4875 13.4 45.0 2.6 Bruce From owner-freebsd-hackers Mon Jan 27 02:04:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA28943 for hackers-outgoing; Mon, 27 Jan 1997 02:04:02 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA28899 for ; Mon, 27 Jan 1997 02:03:06 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id VAA23833 for hackers@freebsd.org; Mon, 27 Jan 1997 21:03:19 +1100 (EST) From: Julian Assange Message-Id: <199701271003.VAA23833@profane.iq.org> Subject: gomoku To: hackers@freebsd.org Date: Mon, 27 Jan 1997 21:03:19 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any reason that gomoku from Lite2 is missing from /usr/src/games? Gomoku is a "connect 4" type game. -- Cheers, Julian. From owner-freebsd-hackers Mon Jan 27 02:11:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA29122 for hackers-outgoing; Mon, 27 Jan 1997 02:11:14 -0800 (PST) Received: from snowcrash.cymru.net (root@snowcrash.cymru.net [163.164.160.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA29117 for ; Mon, 27 Jan 1997 02:11:10 -0800 (PST) Received: (from alan@localhost) by snowcrash.cymru.net (8.7.1/8.7.1) id KAA26279; Mon, 27 Jan 1997 10:08:17 GMT From: Alan Cox Message-Id: <199701271008.KAA26279@snowcrash.cymru.net> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: julian@whistle.com (Julian Elischer) Date: Mon, 27 Jan 1997 10:08:09 +0000 (GMT) Cc: proff@suburbia.net, dg@root.com, hackers@freebsd.org, alan.cox@linux.org In-Reply-To: <32EBDC19.794BDF32@whistle.com> from "Julian Elischer" at Jan 26, 97 02:35:05 pm Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > He told me that originally he looked at using a BSD style allocator, > but that small allocations of mbufs etc all hit the same cache > lines as they were always on powers of two. (obviously) > especially when working on the headers of large packets. > > he saw a noticable problem with cache overwrites. > > I didn't get it all but probably he could tell us more.. > I've CC'd him. He seems very knowledgable about BSD internals > and not at all the screaming fanatic that we sometimes see in the linux > camp so I really enjoyed the conversation.. I'm flattered 8) The problem occuring was one that seems to occur with a lot of allocators. Linux like most other OS's tends to do things of the form object=some_malloc(size_of_object) With the older Linux allocator and all the buddy based allocators object has the property that the lower bits are 0, and the next few bits are 0 with a passably higher probability. In other words the start of the object tends to be at something0000000000 and the 0000000000 tends to include the bits used to select an L1 cache line. Its pretty trivial to inspect the Linux and BSD code to see that almost all objects are of the form struct { most used field regularly used field buf[blah]; /* rarely accessed */ } [memory allocator slop - never used] In the end I pulled some messy tricks in Linux 2.0 to keep the cache a bit saner by building sk_buff's (mbufs to the BSD world) with the buffer structure at the tail of the object .. ie ptr=malloc(size+struct+15) struct=ptr-sizeof(struct) round_down(ptr,16); struct->data=ptr That combined with the fact most linux sk_buff's have the major headers on the 2nd and 3rd cache line into the buffer gave me a performance improvement I could benchmark. The right answer in current literature is undoubtedly a SLAB allocator and that is where we are going at the moment. Alan From owner-freebsd-hackers Mon Jan 27 02:12:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA29201 for hackers-outgoing; Mon, 27 Jan 1997 02:12:38 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA29186 for ; Mon, 27 Jan 1997 02:12:32 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id VAA00439; Mon, 27 Jan 1997 21:08:56 +1100 Date: Mon, 27 Jan 1997 21:08:56 +1100 From: Bruce Evans Message-Id: <199701271008.VAA00439@godzilla.zeta.org.au> To: dicen@hooked.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Performance of ufs vs. ext2. Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Okay cool some real numbers. When you speak of "rewrite" are you talking >about the creation and deletion of files (Metadata)? There seams to be a It's whatever the bonnie benchmark does. Something like rewriting the data in an existing file using a too-small blocksize. The small blocksize forces blocks to be written to be pre-read unless the OS is very smart. It is normally at least twice as slow as an append with a too-small blocksize because it involves twice as much i/o. Under FreeBSD it is about 3 times as slow. Under Linux it is only twice as slow. >significant speed difference between the creation and deletion of files >on linux ext2 vs. Freebsd ufs. Linux ext2 is way faster. I suppose I This is caused mainly by a different default for synchronization of writes: FreeBSD: mount -o -noasync: usually safer but always slower. Linux: mount -o -async: usually less safe but always faster. >could just run ext2 under FreeBSD right? It sure would make a "make >world" faster. You know if someone were to setup a news server it would >seam to make more sence to use ext2. No, the file system has very little to do with the speed of create/delete. FreeBSD uses the same mount default for ext2fs and ufs. `mount -o async' speeds them up almost equally so that they are both slightly slower for create/delete than Linux. They are slower because Linux has better support for its default setting. Bruce From owner-freebsd-hackers Mon Jan 27 02:22:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA29510 for hackers-outgoing; Mon, 27 Jan 1997 02:22:48 -0800 (PST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA29505 for ; Mon, 27 Jan 1997 02:22:40 -0800 (PST) Received: from sol1.gud.siemens.co.at ([10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id LAA15874 for ; Mon, 27 Jan 1997 11:23:18 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0vooBs-000211C; Mon, 27 Jan 97 11:21 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA267670327; Mon, 27 Jan 1997 11:18:47 +0100 From: "Hr.Ladavac" Message-Id: <199701271018.AA267670327@ws2301.gud.siemens.co.at> Subject: Re: What is the default for async in /etc/fstab? To: dicen@hooked.net (RHS Linux User) Date: Mon, 27 Jan 1997 11:18:46 +0100 (MEZ) Cc: freebsd-hackers@freebsd.org In-Reply-To: <32EBC635.4F86F1D5@hooked.net> from "RHS Linux User" at Jan 26, 97 01:01:41 pm 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk E-mail message from RHS Linux User contained: > I am having trouble determining the disk IO performace of FreeBSD vs. > Linux. I recently ran a test on FreeBSD and the write performance wasn't > so great. However, I didn't think to see if async was set in the > /etc/fstab file. I installed from a 2.1 CDROM initially and then cvsuped > different versions. So what is the default for async in the 2.1 > /etc/fstab? Default is sync metadata, async file contents. If you set any value to your filesystem, and if it cannot be easily reproduced (i.e. you're not doing an initial installation or zero level restore,) I would advise very strongly against async metadata. Losing half a filesystem because fsck had to use heuristics to repair it and found a wrong consistent FS state is not my kind of fun. > > Have other people tested ufs vs. ext2? The only docs I could find where > for ext2. A comparison with FreeBSD 2.0 I think, although it could have > been older. This was for some old Linux 1.xx. Dunno. But you could try :) You seem to have both OS's. /Marino > > Hardware. Adapt. 2940UW, and Quantum 4.3gig Atlas, 7200rpm. 8.5ms. > > Thanks. > From owner-freebsd-hackers Mon Jan 27 04:45:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA04828 for hackers-outgoing; Mon, 27 Jan 1997 04:45:48 -0800 (PST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA04820 for ; Mon, 27 Jan 1997 04:45:41 -0800 (PST) Received: from sol1.gud.siemens.co.at ([10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id NAA19098 for ; Mon, 27 Jan 1997 13:46:24 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0voqQL-000213C; Mon, 27 Jan 97 13:44 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA114238913; Mon, 27 Jan 1997 13:41:53 +0100 From: "Hr.Ladavac" Message-Id: <199701271241.AA114238913@ws2301.gud.siemens.co.at> Subject: Re: Performance of ufs vs. ext2. To: dicen@hooked.net (dicen) Date: Mon, 27 Jan 1997 13:41:53 +0100 (MEZ) Cc: freebsd-hackers@freebsd.org In-Reply-To: <32EC6CE5.64E60DE1@hooked.net> from "dicen" at Jan 27, 97 00:52:53 am 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk E-mail message from dicen contained: > Bruce Evans wrote: > > > > >> Have other people tested ufs vs. ext2? The only docs I could find where > > >> ... > > >The performance that I have measured (sequential -- IOZONE) is that > > >FreeBSD is faster in both read/write. However, our metadata performance > > >is slower (filecreates/deletes.) With -async, our metadata is still > > >slower, but not by orders of magnitude. FreeBSD's cache perf is much > > >faster (by factors of 3-4.) Much of it is due to the default block > > >size (8K vs. 1K.) But the fragment size of an 8K UFS filesystem is > > >the *same* as a 1K ext2fs. > > > > In my tests, ext2fs is fastest for huge sequential i/o's when the block > > sizes are closer (8K vs 4K), but there was only a small difference (less > > than 10%) between the best and worst cases (best: ext2fs under FreeBSD, > > next: ext2fs under Linux, worst: ext2fs under Linux) except for rewrite, > > which was 66% faster under Linux than under FreeBSD. Cache performance > > also catches up (46MB/sec for FreeBSD-current-last-November, 41MB/sec > > for Linux-2.0.20). A 4K fragment size wastes space probably wastes time > > in most cases. > > > > Bruce > > Okay cool some real numbers. When you speak of "rewrite" are you talking > about the creation and deletion of files (Metadata)? There seams to be a > significant speed difference between the creation and deletion of files > on linux ext2 vs. Freebsd ufs. Linux ext2 is way faster. I suppose I > could just run ext2 under FreeBSD right? It sure would make a "make > world" faster. You know if someone were to setup a news server it would > seam to make more sence to use ext2. Doubt it. You could run FFS async (the way the Linuxers run ext2fs) and pray to Deity-of-your-choice not to lose the filesystem (the way the Linuxers who run ex2fs should do but do not, presumably out of ignorance). For a news server, you can run FFS noatime, and have a big win without endangering your data. Joe Greco made a series of posts on the matter. /Marino > From owner-freebsd-hackers Mon Jan 27 05:21:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA05875 for hackers-outgoing; Mon, 27 Jan 1997 05:21:18 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA05870 for ; Mon, 27 Jan 1997 05:21:15 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id IAA19691; Mon, 27 Jan 1997 08:20:14 -0500 Date: Mon, 27 Jan 1997 08:20:13 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: RHS Linux User cc: freebsd-hackers@FreeBSD.org Subject: Re: What to do about the 2.0 GNU libc? In-Reply-To: <32EBC435.63297F3E@hooked.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I just wanted to mention that: rfork as it now exists on openbsd/freebsd does as much as clone does on my latest linux 2.x. Actually judging by the comments in my kernel source it is possible that rfork on freebsd is somewhat more useful than clone on linux. ron Ron Minnich |"Failure is not an option" -- Gene Kranz rminnich@sarnoff.com | -- except, of course, on Microsoft products (609)-734-3120 | ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html From owner-freebsd-hackers Mon Jan 27 07:20:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA09733 for hackers-outgoing; Mon, 27 Jan 1997 07:20:40 -0800 (PST) Received: from itsdsv1.enc.edu (itsdsv1.enc.edu [207.95.42.241]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA09728 for ; Mon, 27 Jan 1997 07:20:37 -0800 (PST) Received: from dingo.its.enc.edu (dingo.its.enc.edu [207.95.222.250]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id KAA01836; Mon, 27 Jan 1997 10:17:52 -0500 (EST) Date: Mon, 27 Jan 1997 10:26:23 -0500 (EST) From: Charles Owens X-Sender: owensc@dingo.its.enc.edu Reply-To: Charles Owens To: Julian Elischer cc: hackers list FreeBSD Subject: Re: [Fwd: LDAP object schema for NIS/UNIX/KERB ] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > http://www.xedoc.com.au/~lukeh/ldap/schema.html > Julian, What's your interest in this area? I make heavy production use of FreeBSD NIS but am planning a move to LDAP. This is my next big project... I expect to spend a few months on it. One of the main goals is to provide generic directory services that Web applications can leverage, but I was planning on some sort of gateway to NIS to keep the user passwords in sync. From the URL above it seems that this NIS intergration is being seriously considered. I hope I can make use of their work. I read Bill Paul's reply about not having any time. If I make any progress that seems integratable into FreeBSD I will of course submit it to someone for consideration. Do you have any plans to work in this area? It would be nice to have some folks to bounce my stuff off of. Do you know what has been done by FreeBSD folks with LDAP in general? (other than the port of the umich package). Are there any official plans to make use of it in any real way? thanks, --- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Network & Systems Administrator Information Technology Services "Outside of a dog, a book is man's Eastern Nazarene College best friend. Inside of a dog it's too dark to read." - Groucho Marx ------------------------------------------------------------------------- From owner-freebsd-hackers Mon Jan 27 08:01:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA11435 for hackers-outgoing; Mon, 27 Jan 1997 08:01:48 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA11429 for ; Mon, 27 Jan 1997 08:01:45 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id IAA25609 for ; Mon, 27 Jan 1997 08:01:44 -0800 (PST) From: Greg Lehey Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0votTg-000QaIC; Mon, 27 Jan 97 17:00 MET Received: (grog@localhost) by freebie.lemis.de (8.8.4/8.6.12) id PAA11832; Mon, 27 Jan 1997 15:42:05 +0100 (MET) Message-Id: <199701271442.PAA11832@freebie.lemis.de> Subject: Re: bisdn In-Reply-To: <9971.854322113@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 26, 97 03:41:53 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 27 Jan 1997 15:42:04 +0100 (MET) Cc: isdn@muc.ditec.de (FreeBSD ISDN Distribution List), hackers@freebsd.org (FreeBSD Hackers) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Reply-to: grog@lemis.de (Greg Lehey) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > I don't think that the problems are technical so much as political, > something which generally sucks given that the last thing the free > software community needs to be doing is shooting its feet off and > generally handing the boys at microsoft an even more overwhelming > advantage ("you can't crush us! hah! we plan to commit suicide > through sheer stupidity and ego way before we'll let that happen!" :-) > > Oh well. Sigh! :-) Well, to be fair, Gary Jennejohn replied and told me that this related to ppp, which I don't use. I think the problem there is that not many people use ppp over here, so it's not surprising that it's taking a long time. In that connection, you may be interested to know that I finally succeeded in getting a Teles card to somebody in the US who plans to use it with FreeBSD. He's a device driver engineer who works for Tandem in Austin, and I won't mention his name until I have his permission to do so, but he's a member of a startup planning to build an intelligent ISDN router. I'd guess that he will also contribute to the FreeBSD effort, which should open it up to a wider audience. I'll ask him to announce himself if he wants. Greg From owner-freebsd-hackers Mon Jan 27 09:20:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA14573 for hackers-outgoing; Mon, 27 Jan 1997 09:20:49 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA14567 for ; Mon, 27 Jan 1997 09:20:46 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA19495; Mon, 27 Jan 1997 12:20:06 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 27 Jan 1997 12:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id JAA00421 for ; Mon, 27 Jan 1997 09:26:38 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id JAA01879 for freebsd-hackers@freefall.cdrom.com; Mon, 27 Jan 1997 09:30:23 -0500 (EST) Date: Mon, 27 Jan 1997 09:30:23 -0500 (EST) From: Thomas David Rivers Message-Id: <199701271430.JAA01879@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: 2.2-BETA and 1.2meg floppies? Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm not sure if Jordan had included this in the "4-meg won't be supported" announcement. But - I was just scrounging together a test-bed machine to let me try these things out ahead of time. Unfortunately, the only floppy drive I could cheaply (i.e. free) acquire is a 1.2 meg floppy. Now, the 2.2-BETA boot floppy, boot.flp, will fit - it's 1177088 bytes long. But, I don't believe the fixit floppy, fixit.flp will since it's 1474560 bytes. [A 5-1/4" floppy has 1228800 bytes.] total 5220 -rw-r--r-- 1 rivers wheel 153 Dec 25 21:52 CHECKSUM.MD5 -rw-r--r-- 1 rivers wheel 699 Dec 23 23:00 README.TXT -rw-r--r-- 1 rivers wheel 1177088 Dec 25 21:42 boot.flp -rw-r--r-- 1 rivers wheel 1474560 Dec 25 21:44 fixit.flp I understand; and agree with the arguments that 1.44 meg floppies are cheap (~$60) - but, I'm under serious austerity measures now and don't think I'll stumble into that $60 any time soon. [We're trying to pay off the house early, you know how it goes - and if not, read last Decemeber's Money Magazine.] So - I was wondering if we can produce a smaller "fixit.flp". Perhaps one without "vi" (just ed would be enough.) might bring it into the 1.2 meg range. I put this together with left-overs from previous projects and some other people's junk they were just going to throw away [cases, monitors, etc..] I was able to scrounge; at absolutely no additional cost was: 386dx-33, 12 meg memory. Aha 1542B, a 5-1/4" floppy, and an old 500 meg SCSI. Serial card with 16450's wired on-board. IDE controller and 40 meg IDE drive (which I saved for another day.) Hercules adapter and a nice Princeton monochrome monitor; plus a used "tilty" monitor stand. NE2000 clone card Ancient/dirty keyboard (switchable between XT/AT, with ESC in the wrong place.) Of course, some of these are parts I had purchased years ago; so I suppose you could say there was some cost; but that should be amatorized across about 6-7 years. - Dave Rivers - From owner-freebsd-hackers Mon Jan 27 09:44:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA15890 for hackers-outgoing; Mon, 27 Jan 1997 09:44:17 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA15881 for ; Mon, 27 Jan 1997 09:44:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05718; Mon, 27 Jan 1997 10:26:54 -0700 From: Terry Lambert Message-Id: <199701271726.KAA05718@phaeton.artisoft.com> Subject: Re: What is the default for async in /etc/fstab? To: dicen@hooked.net (RHS Linux User) Date: Mon, 27 Jan 1997 10:26:53 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <32EBC635.4F86F1D5@hooked.net> from "RHS Linux User" at Jan 26, 97 01:01:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I am having trouble determining the disk IO performace of FreeBSD vs. > Linux. I recently ran a test on FreeBSD and the write performance wasn't > so great. However, I didn't think to see if async was set in the > /etc/fstab file. I installed from a 2.1 CDROM initially and then cvsuped > different versions. So what is the default for async in the 2.1 > /etc/fstab? Default is "reliable"... ie: off. > Have other people tested ufs vs. ext2? The only docs I could find where > for ext2. A comparison with FreeBSD 2.0 I think, although it could have > been older. This was for some old Linux 1.xx. Is there a FFS for Linux yet? I think you will only find BSD numbers. Comparing EXT2 on Linux to FFS on FreeBSD, you are more likely comparing Linux and FreeBSD, not the FS's themselves. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jan 27 09:47:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16106 for hackers-outgoing; Mon, 27 Jan 1997 09:47:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16088 for ; Mon, 27 Jan 1997 09:47:35 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05738; Mon, 27 Jan 1997 10:30:13 -0700 From: Terry Lambert Message-Id: <199701271730.KAA05738@phaeton.artisoft.com> Subject: Re: CMD640b ide controller bug workarounds? To: terry@lambert.org (Terry Lambert) Date: Mon, 27 Jan 1997 10:30:13 -0700 (MST) Cc: garman@phs.k12.ar.us, terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: <199701270331.UAA04555@phaeton.artisoft.com> from "Terry Lambert" at Jan 26, 97 08:31:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Well, for PCI, yes. For VLB, there's no slot identification data > (which is why, like ISA, it sucks). > > If the Linux code is working around the hardware problem, it probably > has code to detect it, which you could examine to determine their > algorithm. I now have it on good authority that Linux has working chip detection code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jan 27 09:50:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16473 for hackers-outgoing; Mon, 27 Jan 1997 09:50:51 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16464 for ; Mon, 27 Jan 1997 09:50:47 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA22832; Mon, 27 Jan 1997 12:50:15 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 27 Jan 1997 12:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id MAA08123 for ; Mon, 27 Jan 1997 12:32:56 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id MAA02158 for freebsd-hackers@freefall.cdrom.com; Mon, 27 Jan 1997 12:36:55 -0500 (EST) Date: Mon, 27 Jan 1997 12:36:55 -0500 (EST) From: Thomas David Rivers Message-Id: <199701271736.MAA02158@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: panic: ffs_valloc: dup alloc with 2.2-BETA. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok - Here's the first fruit from my reliable reproduction of my "nightly" panics. I can now readily cause the problem with 2.2-BETA. This implies that whatever fixes were postulated during the 2.2 development don't address the problem, or weren't complete somehow. Anyway, I get a nice: panic: ffs_valloc: dup alloc during the install's newfs of my root file system. At this point; since I can readily reproduce the problem - and have a machine dedicated to that end... I'm in a position to try out anything anyone wants to try! My only limitation is a 5-1/4" floppy drive... - Dave Rivers - From owner-freebsd-hackers Mon Jan 27 09:51:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16527 for hackers-outgoing; Mon, 27 Jan 1997 09:51:12 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16516 for ; Mon, 27 Jan 1997 09:51:07 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA22711; Mon, 27 Jan 1997 12:50:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 27 Jan 1997 12:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id MAA07293 for ; Mon, 27 Jan 1997 12:06:40 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id MAA02068 for freebsd-hackers@freefall.cdrom.com; Mon, 27 Jan 1997 12:10:38 -0500 (EST) Date: Mon, 27 Jan 1997 12:10:38 -0500 (EST) From: Thomas David Rivers Message-Id: <199701271710.MAA02068@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Reproduction of ffs_valloc: dup alloc (finally!) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Finally, I have a reproduction of the ffs_valloc problem in 2.1.6.1. I can attempt to install 2.1.6.1 (from the Walnut Creek CDROM) on a particular machine and consistently get the dup alloc when the installation attempts to do the newfs of the file system. If I alter the newfs parameters; I don't get the problem. I'm going to try it with 2.2-BETA and see what happens.... - Dave Rivers - From owner-freebsd-hackers Mon Jan 27 09:52:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16635 for hackers-outgoing; Mon, 27 Jan 1997 09:52:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16618 for ; Mon, 27 Jan 1997 09:52:12 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05765; Mon, 27 Jan 1997 10:34:30 -0700 From: Terry Lambert Message-Id: <199701271734.KAA05765@phaeton.artisoft.com> Subject: Re: bisdn To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 27 Jan 1997 10:34:30 -0700 (MST) Cc: grog@lemis.de, hackers@FreeBSD.ORG, isdn@muc.ditec.de In-Reply-To: <9971.854322113@time.cdrom.com> from "Jordan K. Hubbard" at Jan 26, 97 03:41:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >> and greatly appreciated, too ! Several people will be working on getting > > >> this integrated into -current (aka 3.0). > > > > > > Really? Awesome! I'd just about given up! :-) > > > > What's the problem? I've been running bisdn on 2.2-CURRENT and > > 3.0-CURRENT since last May. > > I don't think that the problems are technical so much as political, > something which generally sucks given that the last thing the free > software community needs to be doing is shooting its feet off and > generally handing the boys at microsoft an even more overwhelming > advantage ("you can't crush us! hah! we plan to commit suicide > through sheer stupidity and ego way before we'll let that happen!" :-) > > Oh well. Sigh! :-) Clearly your process for adding committers and/or having committers do your code reviews has failed to keep up with the BISDN folk's ability to generate code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jan 27 09:56:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16904 for hackers-outgoing; Mon, 27 Jan 1997 09:56:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA16887 for ; Mon, 27 Jan 1997 09:56:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05784; Mon, 27 Jan 1997 10:39:04 -0700 From: Terry Lambert Message-Id: <199701271739.KAA05784@phaeton.artisoft.com> Subject: Re: fdisk headache To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 27 Jan 1997 10:39:04 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "J Wunsch" at Jan 27, 97 01:27:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > . Since the MBR is identical to the BSD bootstrap, there's no room for > > > things like `nextboot' after the MBR, and you can't replace the MBR > > > by fancy things like a boot selector. > > > This is evil. > > You consider it evil -- some (many?) others don't. See the first > sentence above: it's called ``dangerously'' dedicated mode. It's just > for those who want and love this way. Those who prefer fighting > against braindead 1024-cylinder or foobar megabyte limits are free to > do so, and we even do them the favour to make these struggles (i.e., > the DOS-compatible way) the default variant. "Fighting against the 1024 cylinder limit" is an irrelevant supposition. That limit is not present in LBA-aware MBR's, such as the OnTrack 7.x stuff which also happens to install a BIOS TSR that supplies the LBA BIOS entry points. The limit in that case, or in the case of native LBA support in the IDE controller BIOS, is the FreeBSD OS specific boot code. Again, removing the ability to install other OS's without reinstalling BSD is evil. I don't care if it's non-default or not. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jan 27 09:57:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA17014 for hackers-outgoing; Mon, 27 Jan 1997 09:57:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA17009 for ; Mon, 27 Jan 1997 09:57:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05796; Mon, 27 Jan 1997 10:40:15 -0700 From: Terry Lambert Message-Id: <199701271740.KAA05796@phaeton.artisoft.com> Subject: Re: fdisk headache To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 27 Jan 1997 10:40:15 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "J Wunsch" at Jan 27, 97 01:29:17 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > . The number of BIOS geometry constraints to care for reduces drastic- > > > ally, so you can usually (*) ignore any geometry issues. > > > This is a bogus argument based on the assumption that we wouldn't put > > an absolute sector address in the partition entry like we should so > > a sector-offset based driver (BSD) could still use the partition > > table entry without multiplying out C/H/S values. > > > > Note that we should put the entry there for our parttition: we should > > not rely on a DOS tool to do it correctly for us. > > p.s.: You apparently don't understand what i'm writing about. There's > no DOS tool ever involved in DD mode (and little red daemons will jump > out of the disk if you ever come close to those disks with some DOS > tool at all :-). The BIOS real mode POST-based MBR load is a "DOS tool"... unless you are claiming you can make BIOS calls in protected mode? 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 Jan 27 10:12:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17977 for hackers-outgoing; Mon, 27 Jan 1997 10:12:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17971 for ; Mon, 27 Jan 1997 10:12:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05820; Mon, 27 Jan 1997 10:53:52 -0700 From: Terry Lambert Message-Id: <199701271753.KAA05820@phaeton.artisoft.com> Subject: Re: SLAB stuff, and applications to current net code (fwd) To: alan@cymru.net (Alan Cox) Date: Mon, 27 Jan 1997 10:53:52 -0700 (MST) Cc: julian@whistle.com, proff@suburbia.net, dg@root.com, hackers@freebsd.org, alan.cox@linux.org In-Reply-To: <199701271008.KAA26279@snowcrash.cymru.net> from "Alan Cox" at Jan 27, 97 10:08:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The right answer in current literature is undoubtedly a SLAB allocator and > that is where we are going at the moment. > > Alan Have you read Vahalia, 12.9, regarding per context page pooling? You can build a SLAB allocator on top of that, and the 12.10 analysis about SLAB vs. page pooling incorrectly bias toward SLAB because the page pooling had zone implemented on top of it (and zone is worse than SLAB). You will probably want to zone discard between contexts to allow freeing in one context after allocation in another. This is covered (a little) in "UNIX for Modern Architectures" for the SMP case, but applies to allocation at interrupt time and freeing at run time, and vice versa. This is important when you note that you could consider the two as seperate contexts, and you become worried about disabling interrupts during allocation (and potentially during page reclaimation to satisfy the request in the "BLOCK_OK" case). This is an issue of concurrency of operation, even in the UP case, if you do that. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jan 27 10:16:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA18145 for hackers-outgoing; Mon, 27 Jan 1997 10:16:09 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA18133 for ; Mon, 27 Jan 1997 10:16:03 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id KAA12328; Mon, 27 Jan 1997 10:15:12 -0800 (PST) To: Terry Lambert cc: grog@lemis.de, hackers@FreeBSD.ORG, isdn@muc.ditec.de Subject: Re: bisdn In-reply-to: Your message of "Mon, 27 Jan 1997 10:34:30 MST." <199701271734.KAA05765@phaeton.artisoft.com> Date: Mon, 27 Jan 1997 10:15:11 -0800 Message-ID: <12324.854388911@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Clearly your process for adding committers and/or having committers do > your code reviews has failed to keep up with the BISDN folk's ability > to generate code. An excellent try, Terry. Here's a cookie. You're completely and utterly wrong as usual, but it was still a nice try. Actually, we've been waiting for many months for the BISDN code and if people over there could only stop threatening to sue one another if anything were ever actually released, I'm sure it would be much further ahead. Fortunately, I think and hope that this litigious phase has passed with the BISDN group and we may soon get something which can be released without getting anyone's noses out of joint. For details, please contact the isdn folks - I've just been the bystander watching events with dismay up to now. Jordan From owner-freebsd-hackers Mon Jan 27 10:53:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA21911 for hackers-outgoing; Mon, 27 Jan 1997 10:53:06 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA21904 for ; Mon, 27 Jan 1997 10:53:04 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05959; Mon, 27 Jan 1997 11:35:23 -0700 From: Terry Lambert Message-Id: <199701271835.LAA05959@phaeton.artisoft.com> Subject: Re: bisdn To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 27 Jan 1997 11:35:23 -0700 (MST) Cc: terry@lambert.org, grog@lemis.de, hackers@freebsd.org, isdn@muc.ditec.de In-Reply-To: <12324.854388911@time.cdrom.com> from "Jordan K. Hubbard" at Jan 27, 97 10:15:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Actually, we've been waiting for many months for the BISDN code and if > people over there could only stop threatening to sue one another if > anything were ever actually released, I'm sure it would be much > further ahead. Fortunately, I think and hope that this litigious > phase has passed with the BISDN group and we may soon get something > which can be released without getting anyone's noses out of joint. > > For details, please contact the isdn folks - I've just been the > bystander watching events with dismay up to now. Ah. I misinterpreted your "shoot our own foot off" statement as containing a possessive "our". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jan 27 11:03:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA22570 for hackers-outgoing; Mon, 27 Jan 1997 11:03:14 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22560 for ; Mon, 27 Jan 1997 11:03:12 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id NAA00312 for ; Mon, 27 Jan 1997 13:03:06 -0600 (CST) Received: from jaguar (jaguar.vale.com [204.117.217.146]) by crocodile.vale.com (8.8.3/8.7.3) with SMTP id NAA21464 for ; Mon, 27 Jan 1997 13:03:05 -0600 (CST) Message-ID: <32ECFBE9.10E8@vailsys.com> Date: Mon, 27 Jan 1997 13:03:05 -0600 From: Hal Snyder Reply-To: hal@vailsys.com Organization: Vail Systems, Inc. X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: directory conventions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just got the following from Blair Zajac, who is working on the next release of amanda: > I'm working on Amanda 2.3.0.4 right this minute. It's got a lot of > patches included in it, but probably the biggest deal is that it now > uses automake and autoconf to build the sources. ... > Finally, since I've been converting this to automake, GNU has some standard > places where it likes to shove things. Right now Amanda 2.3.0.4 uses the > following distribution: > > $prefix/bin Amanda server side programs > $prefix/libexec Amanda backup client programs > $prefix/share/amanda Runtime configuration files > $prefix/share/amanda-index Directory for index of dumps > $prefix/var/amanda Directory for database & log files > > I figure that the configuration files and the indexing files can go under > share, since they are in a format that all OS'es can understand. However, > the log files and the database (curinfo) files may be OS dependent and should > go into another directory, say var. This is all customizable using the > options that configure provides to change the locations of where stuff gets > installed. Does anybody have any good ideas or comments on this? Prefix for BSD's is /usr/local. My guess is that config files should go to /usr/local/etc. What is the diff in purpose between /usr/local/libexec and /usr/local/bin? What is /usr/local/share for? Portable bits, as Blair suggests? And what of /usr/local/var? From owner-freebsd-hackers Mon Jan 27 17:06:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA01230 for hackers-outgoing; Mon, 27 Jan 1997 17:06:44 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA01224 for ; Mon, 27 Jan 1997 17:06:35 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id BAA19092; Tue, 28 Jan 1997 01:01:11 GMT Message-Id: <199701280101.BAA19092@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: fredriks@mcs.com cc: hackers@freebsd.org Subject: Re: Modifications to pppd to make it log connecton times In-reply-to: Your message of "Thu, 23 Jan 1997 00:59:29 CST." <32E70C51.41C67EA6@mcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 1997 01:01:10 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This is a multi-part message in MIME format. > > --------------446B9B3D2781E494167EB0E7 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Hi, > Here are context diffs to pppd that makes pppd log the total > time in minutes that it has been connected(similar to what ppp does). > I don't know if I have caught every way pppd can exit(it obviously > doesn't do this if it dumps core or the machine panics) to make sure > the data is printed out, but it does work for the normal cases for sure. [.....] I havn't got to look at these yet, but I'll give you a shout when I do. Thanks -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Mon Jan 27 17:19:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA01973 for hackers-outgoing; Mon, 27 Jan 1997 17:19:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA01940 for ; Mon, 27 Jan 1997 17:19:35 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id QAA28209 for ; Mon, 27 Jan 1997 16:25:35 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id QAA10324 for ; Mon, 27 Jan 1997 16:17:59 -0800 (PST) Message-ID: <32ED4558.446B9B3D@whistle.com> Date: Mon, 27 Jan 1997 16:16:24 -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: Network interfaces: removal of. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a system with frame relay interfaces, and virtual circuits are reflected by virtual 'interfaces' e.g vc0, vc2 etc. the trouble is that there is no support in the kernel for REMOVING an interface! does anyone have any ideas on this? removal of an interface requires that the interface addresses be freed. this in turn requires that any routes that access that ifa (e.g in a TCP pcb) discover that it is invalid the next time they try use it, and try get a new rtentry/ifa. None of this happens at the moment. Add to that the fact that the linked list of interfaces has no support for removing entries, and that the interface array has no support for re-using entries. The reference counting on rtentries and IFAs is next to useless as so many places don't use them rigorously, which requires hacks to keep them allingned with anything even close to reality.. Is there anyone in the group who feels as though they understand the situation well enough to work with me in trying to clean this up a bit? I have the interest in doing it, but I need someone to guide me a bit as the routing table system still confuses me on a regular basis. julian From owner-freebsd-hackers Mon Jan 27 17:23:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02924 for hackers-outgoing; Mon, 27 Jan 1997 17:23:08 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA02897 for ; Mon, 27 Jan 1997 17:23:03 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA27491 for ; Mon, 27 Jan 1997 14:49:48 -0800 (PST) Received: from seagull.rtd.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vozqO-0008yFC; Mon, 27 Jan 97 14:48 PST Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id PAA15452; Mon, 27 Jan 1997 15:44:19 -0700 (MST) From: Don Yuniskis Message-Id: <199701272244.PAA15452@seagull.rtd.com> Subject: Re: suggestion for kernel printk() ? To: Shimon@i-Connect.Net (Simon Shapiro) Date: Mon, 27 Jan 1997 15:44:19 -0700 (MST) Cc: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org, bde@zeta.org.au In-Reply-To: from "Simon Shapiro" at Jan 27, 97 02:23:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems that Simon Shapiro said: > > > > I just spent some time fighting a kernel that died miserably > > > >on boot :-( I was inundated with an endless stream of kernel > > > >messages (in highlighted text) followed promptly by a hard reset. > > > >It was quite frustrating to find that there doesn't seem to be a > > > >mechanism to pause the display at this point! > > > > However, is it worthwhile for the mechanism that printk() ?? uses to > > observe some kind of flow control? It did not recognize scroll_lock, > > pause, ^S, etc. This would have at least enabled me to read some > > (i.e. one screen full) of the messages to see what the kernel was > > complaining about. > > I may be offbase here, but scroll-lock, etc. are INPUT, while printk is Yes. But all of those mechanisms tie in to provide flow control for regular console output functions. Apparently, however, this happens at a higher level than I had hoped/assumed (i.e. more stuff has to be functional before this mechanism works). > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to > a circular buffer andanother mechanism dumps it to ``the console''. > If you like ugly, (if memory serves), you can either pass an additional arg > to the output routine (A la Linux) or designate the first character in the > string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. I was suggesting having printk() examine the keyboard buffer for a pending "pause" key and blocking in this event. However, it appears that the system couldn't handle that crude of an implementation... --don From owner-freebsd-hackers Mon Jan 27 17:23:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02985 for hackers-outgoing; Mon, 27 Jan 1997 17:23:19 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA02946 for ; Mon, 27 Jan 1997 17:23:12 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id OAA27524 for ; Mon, 27 Jan 1997 14:54:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA12253; Mon, 27 Jan 1997 14:52:37 -0800 (PST) Message-Id: <199701272252.OAA12253@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Jon Moldenhauer cc: freebsd-hackers@freebsd.org Subject: Re: Intel EtherExpress Pro 10B PCI In-reply-to: Your message of "Sat, 25 Jan 1997 20:22:58 PST." <199701260422.UAA15008@almond.elite.net> From: David Greenman Reply-To: dg@root.com Date: Mon, 27 Jan 1997 14:52:37 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Up till now, I hadn't seen anyone say they had gotten the 10B >card to work. Well, I did get it to work. Basically, the 10B >uses the same chip as the 100B (the i82557) and so the fxp >driver recognizes the card when FreeBSD boots. Unfortunately, >the fxp driver assumes the card is a 100B card which may not >always be the case. To remedy this, I hacked up the fxp >driver so it is possible to use the link0 and link1 flags to >ifconfig to tell the driver how to configure the card. For >users of the 100B card, nothing changes. For users of the 10B >card, you add 'link0 link1' to the ifconfig line for the card. > >The reason for two flags is this: link0 controls whether the >card is set up in nibble-wide (100Mbit) or bit-wide (10Mbit) >mode, and link1 controls whether the card is willing to do >full-duplex or will refuse to do full-duplex. Again, the >default settings of ifconfig are to work the way the driver >did before so you have to explicitly give the link0 flag to >put the card into bit-wide mode and explicitly give the link1 >flag to tell the card to refuse full-duplex mode. > >Anyway, thats probably more than anyone wants to know and >there must be a better way to tell the driver whether the >card is a 10B or 100B but since I don't have a 100B card I >couldn't figure out a reliable way (ethernet addresses >might work, but I would need to see some 100B ethernet >addresses to be sure). What you're saying above is all correct, and I agree that the flags isn't the right way to accomplish the 'mediatype' card setting - the driver needs to figure out what type of card you have. Unfortunately, I haven't found a way to easily do this, either, which is why the Pro/10 wasn't supported (the fact I don't _have_ a Pro/10 also has something to do with it :-)). Anyway, your investigation and patches are very useful in that they 1) will get people going right away, and more importantly, 2) show that this is all that is needed to get the driver working with the Pro/10. Probably the "right" solution to the probing will be to actually look at the PHY type and base the mediatype mode setting on the results of that. ...but I'll need to get a Pro/10 before I can write the code for this. Thanks! -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jan 27 17:24:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03284 for hackers-outgoing; Mon, 27 Jan 1997 17:24:07 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03237 for ; Mon, 27 Jan 1997 17:24:03 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id OAA27335 for ; Mon, 27 Jan 1997 14:24:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA12114; Mon, 27 Jan 1997 14:23:00 -0800 (PST) Message-Id: <199701272223.OAA12114@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Vadim Kolontsov cc: hackers@freebsd.org Subject: Re: in_rtqtimo In-reply-to: Your message of "Mon, 27 Jan 1997 11:53:54 +0300." From: David Greenman Reply-To: dg@root.com Date: Mon, 27 Jan 1997 14:23:00 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hello, > > what does this kernel message mean? > > /kernel: in_rtqtimo: adjusted rtq_reallyold to 2400 It means that your machine had a lot of clone routes and was adjusting the expiration time down a bit (to 2400 seconds). You can safely ignore it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jan 27 17:24:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03359 for hackers-outgoing; Mon, 27 Jan 1997 17:24:22 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03325 for ; Mon, 27 Jan 1997 17:24:14 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA27389 for ; Mon, 27 Jan 1997 14:32:04 -0800 (PST) Received: (qmail 3717 invoked by uid 1000); 27 Jan 1997 23:30:07 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701252032.NAA20427@seagull.rtd.com> Date: Mon, 27 Jan 1997 14:23:10 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Don Yuniskis Subject: Re: suggestion for kernel printk() ? Cc: freebsd-hackers@freefall.freebsd.org, (Bruce Evans) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Don Yuniskis; On 25-Jan-97 you wrote: > It seems that Bruce Evans said: > > > > > I just spent some time fighting a kernel that died miserably > > >on boot :-( I was inundated with an endless stream of kernel > > >messages (in highlighted text) followed promptly by a hard reset. > > >It was quite frustrating to find that there doesn't seem to be a > > >mechanism to pause the display at this point! > > > > I use a serial console and `terminalprogram | tee foo' to capture > > the output. > > Yes, but I would have had to have built the kernel with COMCONSOLE > (which I didn't). > > > > OK, reboot from /kernel.old and look through the logs. Hmmm... > > >nothing here! Probably the filesystem wasn't even functional when > > >the boot ran into trouble. > > > > Boot messages are supposed to be preserved in the message buffer > > across reboots. However, many PC BIOSes and/or memory systems do > > something that invalidates the message buffer even for a soft reboot. > > Well, I wasn't observant enough to notice what type of restart the > PC went through (two different varieties here -- one of which actually > rampages through memory, etc.) but suspect this is the problem. > > However, is it worthwhile for the mechanism that printk() ?? uses to > observe some kind of flow control? It did not recognize scroll_lock, > pause, ^S, etc. This would have at least enabled me to read some > (i.e. one screen full) of the messages to see what the kernel was > complaining about. I may be offbase here, but scroll-lock, etc. are INPUT, while printk is output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to a circular buffer andanother mechanism dumps it to ``the console''. If you like ugly, (if memory serves), you can either pass an additional arg to the output routine (A la Linux) or designate the first character in the string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. Simon From owner-freebsd-hackers Mon Jan 27 17:24:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03402 for hackers-outgoing; Mon, 27 Jan 1997 17:24:29 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03377 for ; Mon, 27 Jan 1997 17:24:25 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA27390 for ; Mon, 27 Jan 1997 14:32:04 -0800 (PST) Received: (qmail 3725 invoked by uid 1000); 27 Jan 1997 23:30:08 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 27 Jan 1997 14:27:12 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: (Joerg Wunsch) Subject: Re: fdisk headache Cc: freebsd-hackers@freebsd.org, (Jean-Marc Zucconi) , (J Wunsch) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi J Wunsch; On 25-Jan-97 you wrote: > As Jean-Marc Zucconi wrote: > > > I try to add another disk, but it seems that something has changed > > since my last drive installation because fdisk doesnt want to write a > > correct information. > > Why are you using fdisk at all? You are running Unix, you aren't > running on a PC, you are not supposed to use fdisk (unless other > systems on your disk force you to this step). Slow down.... The gentleman has a valid point, methinks. If not, please show me how to build 120 filesystems on a disk that is 750GB large. Impossible/stupid numbers? not really when considering a large disk array with a very large database. >From what I have seen, FreeBSD gives me 6 partitions (slices) per device. not quite enough. I am running 22 filessystems on a 16GB ccd conglomerate and porting/qriting a driver for the DPT controller that allows, easily, 4 wide controllers, 3 busses each, 15 targets per drive, 15 LUNS per target. Shall I go on? > > :-) > > > My new drive is probed as: > > (ncr1:6:0): "QUANTUM FIREBALL_TM3200S 300N" type 0 fixed SCSI 2 > > sd4(ncr1:6:0): Direct-Access > > sd4(ncr1:6:0): 10.0 MB/s (100 ns, offset 8) > > 3067MB (6281856 512 byte sectors) > > sd4(ncr1:6:0): with 6810 cyls, 5 heads, and an average 184 > > sectors/track > > (why 6810*5*184 != 6281856 ???) > > So, if you don't understand it -- why do you boot with -v at all? We > deliberately took this line out of the default messages: > > sd4(ncr1:6:0): with 6810 cyls, 5 heads, and an average 184 > ^^^^^^^^^^^^^^ > > ...and this should be taken as a good indication that nobody claims > the equation C*H*S = should assumed to be > true. It's just the other way round: the SCSI drive can report about > its number of heads, cylinders, and total number of blocks. Since it > can't report about the number of sectors per track (and this number > would barely make sense at all), the boot message calculates that > average from the other three figures. > > > When I start fdisk it tells me that the drive has 19035cyl, 6heads, > > 55sec/trk. Wanting to change the values to 6810/5/184, I get > > You can't. You are limited by the BIOS constraints in an fdisk table. > The best you could do is changing it to 1024/x/y where x and y match > the emulation your BIOS is using. > > > The data for partition 3 is: > > sysid 165,(FreeBSD/NetBSD/386BSD) > > start 1, size 6265199 (3059 Meg), flag 80 > > beg: cyl 0/ sector 2/ head 0; > > end: cyl 666/ sector 55/ head 5 > > The last value is obviously wrong, but if try to change it to > > something more realistic, eg. 6810/5/183, fdisk interpret my values as > > 666/55/5 !!!!! > > Because it will be (silently) masked by 0x3ff. > > > The real problem is then when I want to label the disk: I get > > > > ioctl DIOCWLABEL: Operation not supported by device > > sd4s4: type 0xa5, start 1, end = 6265199, size 6265199 > > sd4s4: C/H/S end 666/5/55 (220109) != end 6265199: invalid > > The slice code knows about various BIOS problems. It assumes a few > bogus geometry values (including the 1024 cylinders one). However, > the total number of sectors in the BSD slice must still match the `c' > partition value -- 6265199. > > > Is there a solution? I don't care if the geometry is incorrect as long > > I can disklabel/newfs the drive and use the 3067 Mb!!! > > The simplest solution (assuming you only want FreeBSD there) is: > > . wipe out your junked fdisk table: dd if=/dev/zero of=/dev/rsd4 count=10 > . give the entire disk to FreeBSD: disklabel -Brw sd4 auto > . edit the partitions as you need: disklabel -e sd4 > > -- > 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 Jan 27 17:24:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03459 for hackers-outgoing; Mon, 27 Jan 1997 17:24:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03441 for ; Mon, 27 Jan 1997 17:24:35 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id PAA27716 for ; Mon, 27 Jan 1997 15:16:41 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id PAA24291 for ; Mon, 27 Jan 1997 15:16:33 -0800 (PST) Received: (qmail 3638 invoked by uid 110); 27 Jan 1997 23:14:54 -0000 MBOX-Line: From owner-netdev@roxanne.nuclecu.unam.mx Mon Jan 27 19:05:01 1997 remote from suburbia.net Delivered-To: proff@suburbia.net Received: (qmail 8369 invoked from network); 27 Jan 1997 19:04:55 -0000 Received: from roxanne.nuclecu.unam.mx (132.248.29.2) by suburbia.net with SMTP; 27 Jan 1997 19:04:55 -0000 Received: (from root@localhost) by roxanne.nuclecu.unam.mx (8.6.12/8.6.11) id MAA03684 for netdev-outgoing; Mon, 27 Jan 1997 12:46:36 -0600 Received: from athena.nuclecu.unam.mx (athena.nuclecu.unam.mx [132.248.29.9]) by roxanne.nuclecu.unam.mx (8.6.12/8.6.11) with ESMTP id MAA03679 for ; Mon, 27 Jan 1997 12:46:33 -0600 Received: (from miguel@localhost) by athena.nuclecu.unam.mx (8.6.12/8.6.11) id MAA08310; Mon, 27 Jan 1997 12:37:25 -0600 Date: Mon, 27 Jan 1997 12:37:25 -0600 Message-Id: <199701271837.MAA08310@athena.nuclecu.unam.mx> From: Miguel de Icaza To: netdev@roxanne.nuclecu.unam.mx, dah@pe.net CC: davem@jenolan.rutgers.edu In-reply-to: <199701261640.IAA18757@magnolia.pe.net> (message from David Heitmann on Sun, 26 Jan 1997 08:40:17 -0800) Subject: Re: SLAB stuff, and applications to current net code X-Lost: In case of doubt, make it sound convincing Reply-To: netdev@roxanne.nuclecu.unam.mx, Miguel de Icaza Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm going to try feveriously to get the SLAB allocator integrated into > > Linus's sources over the next two days. For the most part my > > incentive is so that people think about it when they design memory > > object allocation subsystems. > > Could someone post where to get more (detailed) information about > SLAB allocators? You can find a nice explanation on Uresh Vahalia's "Unix Internals: The New Frontiers". I have also placed the Postscript paper that I got from somewere on the net on my web page: http://luthien.nuclecu.unam.mx/~miguel Miguel. From owner-freebsd-hackers Mon Jan 27 17:27:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04124 for hackers-outgoing; Mon, 27 Jan 1997 17:27:02 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04102 for ; Mon, 27 Jan 1997 17:26:53 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id NAA26916 for ; Mon, 27 Jan 1997 13:26:50 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA15384; Mon, 27 Jan 1997 22:25:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA12677; Mon, 27 Jan 1997 22:08:45 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 22:08:45 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: 2.2-BETA and 1.2meg floppies? References: <199701271430.JAA01879@lakes.water.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701271430.JAA01879@lakes.water.net>; from Thomas David Rivers on Jan 27, 1997 09:30:23 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Thomas David Rivers wrote: > I'm not sure if Jordan had included this in the "4-meg won't be > supported" announcement. Yes, he did. > Now, the 2.2-BETA boot floppy, boot.flp, will fit - it's 1177088 > bytes long. That's surprising. At least at one stage in the game, we ran out of space on the 1.2 MB floppies, and decided that we don't have the energy to deal any longer with this. (It's been a continous hunt for just a few bytes on the install floppy.) > So - I was wondering if we can produce a smaller "fixit.flp". It's not very difficult to do this. However, Julian didn't seem to be very interested in maintaining his floppy build submission that doesn't require an entire `make release' before, so it's currently a little orphaned. I'm not sure whether it will be possible for you to just create a fixit floppy without building an entire release... With a little Makefile tweaking, you should be able however. It's not much more than just some `crunchgen' stuff. Have a look into /usr/src/release/*. I could probably put up a fixit image without a vi, but this one will become outdated fairly soon. -- 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 Jan 27 17:27:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04159 for hackers-outgoing; Mon, 27 Jan 1997 17:27:10 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04122 for ; Mon, 27 Jan 1997 17:27:02 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id NAA26974 for ; Mon, 27 Jan 1997 13:34:51 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2-biteme) with ESMTP id PAA27780 for ; Mon, 27 Jan 1997 15:34:49 -0600 (CST) Received: from Venus.mcs.net (ljo@Venus.mcs.com [192.160.127.92]) by Mailbox.mcs.com (8.8.5/8.8.2) with ESMTP id PAA02541; Mon, 27 Jan 1997 15:34:39 -0600 (CST) Received: (from ljo@localhost) by Venus.mcs.net (8.8.5/8.8.2) id PAA10766; Mon, 27 Jan 1997 15:34:20 -0600 (CST) From: Lars Jonas Olsson Message-Id: <199701272134.PAA10766@Venus.mcs.net> Subject: de0 timeouts w 486 CPU To: hackers@freebsd.org Date: Mon, 27 Jan 1997 15:34:19 -0600 (CST) Cc: ljo@Mcs.Net X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a 486DX4-100 system that is doing make worlds fine, but generates a lot of: de0: system error: master abort messages with a current kernel. With a 2.1R kernel it was generating illegal interrupt errors for de0. Any guess if this is bug in the if_de.c driver or a hardware problem? The rate of messages is 5-30/hour on a system not doing much networking. Jonas Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Fri Jan 24 14:59:03 CST 1997 root@mail-new.accumed-int.com:/usr/src/sys/compile/MAIL-NEW Calibrating clock(s) relative to mc146818A clock ... i8254 clock: 1193260 Hz CPU: i486 DX4 (486-class CPU) Origin = "GenuineIntel" Id = 0x480 Stepping=0 Features=0x3 real memory = 16777216 (16384K bytes) avail memory = 14741504 (14396K bytes) Probing for devices on PCI bus 0: chip0 rev 49 on pci0:5:0 de0 rev 32 int a irq 10 on pci0:10:0 de0: 21140A [10-100Mb/s] pass 2.0 de0: address 00:80:c8:3e:48:bf de0: enabling 100baseTX port vga0 rev 34 int a irq 11 on pci0:11: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 ed1 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 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 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1039MB (2128896 sectors), 2112 cyls, 16 heads, 63 S/T, 512 B/S npx0 on motherboard npx0: INT 16 interface de0: system error: master abort de0: system error: master abort From owner-freebsd-hackers Mon Jan 27 17:28:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04392 for hackers-outgoing; Mon, 27 Jan 1997 17:28:08 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04365 for ; Mon, 27 Jan 1997 17:28:04 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26741 for ; Mon, 27 Jan 1997 12:57:13 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA14787 for hackers@freebsd.org; Mon, 27 Jan 1997 21:55:50 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA12559; Mon, 27 Jan 1997 21:44:13 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 21:44:13 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: gomoku References: <199701271003.VAA23833@profane.iq.org> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701271003.VAA23833@profane.iq.org>; from Julian Assange on Jan 27, 1997 21:03:19 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Assange wrote: > Is there any reason that gomoku from Lite2 is missing from > /usr/src/games? Yes: nobody ever did start a full userland Lite2 merge (not even a vendor-branch import, but that's already a large part of the work to be done). -- 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 Jan 27 17:28:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04414 for hackers-outgoing; Mon, 27 Jan 1997 17:28:12 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04388 for ; Mon, 27 Jan 1997 17:28:07 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26727 for ; Mon, 27 Jan 1997 12:56:14 -0800 (PST) Received: (qmail 21759 invoked by uid 1000); 25 Jan 1997 05:09:19 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 24 Jan 1997 21:06:30 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: garman@phs.k12.ar.us Subject: RE: CMD640b ide controller bug workarounds? Cc: freebsd-hackers@freebsd.org, (Jason Garman) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Jason Garman; On 25-Jan-97 you wrote: > Does anyone have one of these lame ide controllers? These things, in > addition to having the rz1000 flaws, also freeze the machine when both ide > channels are accessed on the machine. Is there any chance for a > workaround in the FreeBSD wdc driver? I have a nice 2 gig drive sitting > here spinning its heads for nothing :-( > > I tried doing some modifications myself, but as the extraordinary novice > kernel hacker I am, I only got it to hang the specific process doing the > disk access, not the entire machine. A little improvement, I guess :-/ > > L*nux has an option `hda=serialize' to do this. Is there any chance > FreeBSD could have an CMD640B_SUCKS_ROCKS_SERIALIZE_REQUESTS option in the > kernel config file? Linux also hasa specific RZ100 option, if I am not mistaken. Simon From owner-freebsd-hackers Mon Jan 27 17:28:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04476 for hackers-outgoing; Mon, 27 Jan 1997 17:28:23 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04447 for ; Mon, 27 Jan 1997 17:28:18 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26719 for ; Mon, 27 Jan 1997 12:55:42 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA14741; Mon, 27 Jan 1997 21:53:41 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA12541; Mon, 27 Jan 1997 21:38:18 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 21:38:18 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: kmitch@weenix.guru.org (Keith Mitchell) Cc: hackers@freebsd.org Subject: Re: DUMP problem References: <199701270756.CAA03562@weenix.guru.org> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701270756.CAA03562@weenix.guru.org>; from Keith Mitchell on Jan 27, 1997 02:56:23 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Keith Mitchell wrote: > | DUMP: too many slaves, 1 (recompile smaller): Resource temporarily unavailab > le > | DUMP: The ENTIRE dump is aborted. > > > Does anyone know how to fix this too many slaves error condition that keeps > popping up?? if (socketpair(AF_UNIX, SOCK_STREAM, 0, cmd) < 0 || (slaves[i].pid = fork()) < 0) quit("too many slaves, %d (recompile smaller): %s\n", i, strerror(errno)); It translates into ``Cannot fork''. Seems you reached the process limit of the user running amanda. See limits (in the csh), or ulimit (in Bourne-alike shells). -- 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 Jan 27 17:28:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04542 for hackers-outgoing; Mon, 27 Jan 1997 17:28:36 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04511 for ; Mon, 27 Jan 1997 17:28:31 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26694 for ; Mon, 27 Jan 1997 12:54:56 -0800 (PST) Received: (qmail 9817 invoked by uid 1000); 25 Jan 1997 04:21:22 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 24 Jan 1997 20:12:49 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: hackers@freebsd.org Subject: 3.0-970118 Compile... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Trying to compile said release... 1. Fails in gnu/lib/readline with: cc -fpic -DPIC -O -I/usr/src/gnu/lib/libreadline -I/usr/src/gnu/lib/libreadline/../../../contrib/libreadline -DHAVE_CONFIG_H -c /usr/src/gnu/lib/libreadline/tilde.c -o tilde.so building shared readline library (version 3.0) histfile.so: Definition of symbol `_write_history' (multiply defined) histfile.so: Definition of symbol `_append_history' (multiply defined) histfile.so: Definition of symbol `_read_history_range' (multiply defined) .... .... *** Error code 1 2. Fails in contrib/texinfo with: ===> libtxi cc -O -c /usr/src/gnu/usr.bin/texinfo/libtxi/../../../../contrib/texinfo/libtxi/getop t.c -o getopt.o cc -O -c /usr/src/gnu/usr.bin/texinfo/libtxi/../../../../contrib/texinfo/libtxi/getop t1.c -o getopt1.o building standard txi library ranlib libtxi.a ===> makeinfo cc -O -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_ TIME_H=1 -DHAVE_SYS_FCNTL_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_ALLOCA=1 -DHAVE_SETVBUF=1 -DHAVE_GETCWD=1 -DHAVE_MEMSET=1 -DHAVE_BZERO =1 -DHAVE_STRCHR=1 -DHAVE_STRCASECMP=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_STRERROR=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSET MASK=1 -I../libtxi -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/libtxi -c /usr/src/gnu/usr.bin/texinfo /makeinfo/makeinfo.c cc -O -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_ TIME_H=1 -DHAVE_SYS_FCNTL_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_ALLOCA=1 -DHAVE_SETVBUF=1 -DHAVE_GETCWD=1 -DHAVE_MEMSET=1 -DHAVE_BZERO =1 -DHAVE_STRCHR=1 -DHAVE_STRCASECMP=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_STRERROR=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSET MASK=1 -I../libtxi -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/libtxi -c /usr/src/gnu/usr.bin/texinfo /makeinfo/../../../../contrib/texinfo/makeinfo/multi.c cc -O -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_ TIME_H=1 -DHAVE_SYS_FCNTL_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_ALLOCA=1 -DHAVE_SETVBUF=1 -DHAVE_GETCWD=1 -DHAVE_MEMSET=1 -DHAVE_BZERO =1 -DHAVE_STRCHR=1 -DHAVE_STRCASECMP=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_STRERROR=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSET MASK=1 -I../libtxi -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/libtxi -o makeinfo makeinfo.o multi.o -L../libtxi -ltxi multi.o: Undefined symbol `_multitable_active' referenced from text segment multi.o: Undefined symbol `_multitable_active' referenced from text segment multi.o: Undefined symbol `_multitable_active' referenced from text segment multi.o: Undefined symbol `_multitable_active' referenced from text segment multi.o: Undefined symbol `_multitable_active' referenced from text segment *** Error code 1 Stop. *** Error code 1 More to come... Question: How does one obtain a current, but compilable source tree? Reason of Asking: Attempt to be current with long range development... Thanx Again... Simon From owner-freebsd-hackers Mon Jan 27 17:28:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04549 for hackers-outgoing; Mon, 27 Jan 1997 17:28:37 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04520 for ; Mon, 27 Jan 1997 17:28:32 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA26702 for ; Mon, 27 Jan 1997 12:55:08 -0800 (PST) Received: (qmail 9815 invoked by uid 1000); 25 Jan 1997 04:21:22 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 24 Jan 1997 19:18:56 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: hackers@freebsd.org Subject: 2.2-BETA Questions Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Y'all; Some questions about 2.2-BETA 1. Does anyone care? Coming from (too much) Linux, and seeing 2.1.6, 2.2-BETa, 3.0... it is not a stupid question. 2. Assunming #1 is true, listen to this (Network Failure System; AKA NFS) scenario: * Linux NFS server, Debian 1.2, Kernel 2.0.27, etc. (nomis) with this in /etc/exports: /usr/src/FreeBSD sendero.i-connect.net(rw,no_root_squash) * FreeBSD 2.2-BETA client doing: # mkdir /NewStuff # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff # ls -al /NewStuff ls: /NewStuff: Permission denied ls -al / .... drwxr-xr-x 2 root wheel 512 Jan 3 00:08 Linux-Transfers drwxr-xr-x 2 root wheel 512 Jan 23 18:01 NewRoot drwxrwxrwt 13 root sys 512 Jan 8 12:02 SourceControl [ /NewStuff is not there? ] It is, but... ? # umount /NewStuff umount: nomis:/usr/src/FreeBSD: No such file or directory # umount nomis:/usr/src/FreeBSD # ls -altotal 2 drwxr-xr-x 2 root wheel 512 Jan 5 02:36 . drwxr-xr-x 28 root wheel 1024 Jan 24 19:16 ../NewStuff Dunno about you but smells like a bug to me... BTW, works fine the other way around.... 3. Made a kernel with sound, etc... Worked fine until some days ago. Now, all of the sudden, without me doing anything (really :-): # xmcd -debug .... Lock file: /tmp/.cdaudio/lock.f02 Cannot open /dev/rcd0c: errno=6 Lock file: /tmp/.cdaudio/lock.f02 Cannot open /dev/rcd0c: errno=6 .... # ls -al /dev/rcd0c crw-r----- 1 root operator 15, 2 Jan 24 16:01 /dev/rcd0c # ls -al /usr/X11R6/bin/xmcd -rws--x--x 1 root bin 1490836 Dec 4 03:03 /usr/X11R6/bin/xmcd # rm /dev/rcd0c rm: /dev/rcd0c: Read-only file system # df /dev Filesystem 512-blocks Used Avail Capacity Mounted on fdesc 2 2 0 100% /dev # umount /dev # xmcd -debug .... Lock file: /tmp/.cdaudio/lock.f02 Cannot open /dev/rcd0c: errno=6 Lock file: /tmp/.cdaudio/lock.f02 Cannot open /dev/rcd0c: errno=6 .... What Gives? Yes, I tried MAKEDEV. Same difference. 4. Shutdown questions: a. When init goes to single user, prompts, asking for a shell. You press ENTER and it sits on ``(.???msg - Cannot exactly remember) not found'' ^C will get you a prompt, most of the time. Sometimes you get a fast roll talking about some malloc() failure. Sometimes a ^C will stop it, sometimes it will not. b. umount -a will leave things not in /etc/fstab mounted. It always leaves root mounted RW, only to fsck it at boot. Seems lie an unnecessary risk. 5. More CD fun. Once a music CD is played, you cannot mount a data cd because ``device is busy''. Reboot cures. 6. AHA-2940W with iomega Jaz connected; * If Jaz is not spinning, driver (?) complains about ``board did not respond'' or some such. If you reboot, you stand a good chance to crash the system. Workaround: Setup the AHA to include Jaz in BIOS scan, and to send the Jaz a Start Unit command. Also, do not daydream when booting so jaz is still spinning when aic7xxx.c looks for it. 7. trying /stand/sysinstall from a live system dumps core either on (the equivalent of) fdisk or disklabel. 8. Education Question: What is the logic in assigning slice ID's? I understand c to be the entire disk (why `c'? Why not?) Why does sysinstall assign 'e', 'f', but (almost) never 'd'? 9. Some safety checks in disklabel and newfs and/or kernel slice- partition handling could be nice. If you create an 'a' partition which is exactly an overlap of a 'c' in a slice that dominates the disk, newfs will FREEZE the system. Workaround: Make the 'a' partition 64 sectors smaller than the 'c', skipping that many sectors at the beginning. 10. Kernel Question: On an i386 PC, how does one make sure that another driver does not use the same ISA ports as you do? You are trying to be nice and NOT use something someone else is already using. There is a Linux thing to do that... 11. Another Kernel question: A device driver for a controller that is available in ISA, EISA and PCI. How do you split the code? We put the PCI part in pci, the ISA/EISA parts in i386/{isa,eisa}? But the code is NOT i386 dependant. We are putting it in dev/dpt. Is that a good choice? Thanx a million. Simon From owner-freebsd-hackers Mon Jan 27 17:32:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05436 for hackers-outgoing; Mon, 27 Jan 1997 17:32:22 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05425 for ; Mon, 27 Jan 1997 17:32:20 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id BAA04689; Tue, 28 Jan 1997 01:30:46 GMT Date: Tue, 28 Jan 1997 10:30:46 +0900 (JST) From: Michael Hancock To: Alan Cox cc: Julian Elischer , proff@suburbia.net, dg@root.com, hackers@freebsd.org, alan.cox@linux.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701271008.KAA26279@snowcrash.cymru.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Alan Cox wrote: > Its pretty trivial to inspect the Linux and BSD code to see that almost all > objects are of the form > > > struct > { > most used field > regularly used field > buf[blah]; /* rarely accessed */ > } > [memory allocator slop - never used] > > In the end I pulled some messy tricks in Linux 2.0 to keep the cache a bit > saner by building sk_buff's (mbufs to the BSD world) with the buffer > structure at the tail of the object .. ie > > > ptr=malloc(size+struct+15) > struct=ptr-sizeof(struct) > round_down(ptr,16); > struct->data=ptr > > That combined with the fact most linux sk_buff's have the major headers on > the 2nd and 3rd cache line into the buffer gave me a performance improvement > I could benchmark. > > The right answer in current literature is undoubtedly a SLAB allocator and > that is where we are going at the moment. I wonder what would actually perform better in practice, struct member order hackery or a SLAB allocator with its processor cache coloring along with all it's overhead in maintaining a linked list of memory slabs with embedded object arrays and "in-band" free object lists. On the call side the abstraction sure is pretty with it's object constructor and destructor args. It seems that there are things to be gained and things that will be lost. This will be an interesting development to follow. Regards, Mike Hancock From owner-freebsd-hackers Mon Jan 27 17:32:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05530 for hackers-outgoing; Mon, 27 Jan 1997 17:32:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05508 for ; Mon, 27 Jan 1997 17:32:33 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id LAA26035 for ; Mon, 27 Jan 1997 11:34:34 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vop4l-00031u-00; Mon, 27 Jan 1997 03:18:11 -0800 Date: Mon, 27 Jan 1997 03:18:10 -0800 (PST) From: Tom Samplonius To: Hal Snyder cc: hackers@freebsd.org Subject: Re: directory conventions In-Reply-To: <32ECFBE9.10E8@vailsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Hal Snyder wrote: > I just got the following from Blair Zajac, who is working on the next > release of amanda: > > > I'm working on Amanda 2.3.0.4 right this minute. It's got a lot of > > patches included in it, but probably the biggest deal is that it now > > uses automake and autoconf to build the sources. > ... > > Finally, since I've been converting this to automake, GNU has some standard > > places where it likes to shove things. Right now Amanda 2.3.0.4 uses the > > following distribution: > > > > $prefix/bin Amanda server side programs > > $prefix/libexec Amanda backup client programs > > $prefix/share/amanda Runtime configuration files > > $prefix/share/amanda-index Directory for index of dumps > > $prefix/var/amanda Directory for database & log files > > > > I figure that the configuration files and the indexing files can go under > > share, since they are in a format that all OS'es can understand. However, > > the log files and the database (curinfo) files may be OS dependent and should > > go into another directory, say var. This is all customizable using the > > options that configure provides to change the locations of where stuff gets > > installed. Does anybody have any good ideas or comments on this? > > Prefix for BSD's is /usr/local. > > My guess is that config files should go to /usr/local/etc. > > What is the diff in purpose between /usr/local/libexec and > /usr/local/bin? libexec is for executables that are generally executed by other programs (ie. backends). It normaly doesn't make any sense to exec program here directly, and libexec is never in the stanard PATH. > What is /usr/local/share for? Portable bits, as Blair suggests? Arch independant ASCII files, normally. > And what of /usr/local/var? /var has always been "local". You you should probably "man hier" Tom From owner-freebsd-hackers Mon Jan 27 17:50:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA06908 for hackers-outgoing; Mon, 27 Jan 1997 17:50:31 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA06897 for ; Mon, 27 Jan 1997 17:50:10 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id MAA05913; Tue, 28 Jan 1997 12:55:00 +1100 (EST) Date: Tue, 28 Jan 1997 12:54:59 +1100 (EST) From: "Daniel O'Callaghan" To: Brian Somers cc: fredriks@mcs.com, hackers@freebsd.org Subject: Re: Modifications to pppd to make it log connecton times In-Reply-To: <199701280101.BAA19092@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Brian Somers wrote: > > Hi, > > Here are context diffs to pppd that makes pppd log the total > > time in minutes that it has been connected(similar to what ppp does). > > I don't know if I have caught every way pppd can exit(it obviously > > doesn't do this if it dumps core or the machine panics) to make sure > > the data is printed out, but it does work for the normal cases for sure. > [.....] I did this using an external program. The user's login shell is a Bourne shell script with a 'checkin' facility, run before execing pppd. Getty is run from a script which has a 'checkout' facility. That way, whenever pppd exits, and getty is run, the user on that tty is checked out. Danny From owner-freebsd-hackers Mon Jan 27 18:42:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10104 for hackers-outgoing; Mon, 27 Jan 1997 18:42:30 -0800 (PST) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA10099 for ; Mon, 27 Jan 1997 18:42:27 -0800 (PST) Received: from w2xo.pgh.pa.us (localhost [127.0.0.1]) by w2xo.pgh.pa.us (8.8.4/8.8.4) with SMTP id VAA22721; Mon, 27 Jan 1997 21:42:41 -0500 (EST) Message-ID: <32ED67A1.446B9B3D@w2xo.pgh.pa.us> Date: Mon, 27 Jan 1997 21:42:41 -0500 From: Jim Durham Organization: Dis- X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: "A. Radovanovic" CC: hackers@freebsd.org Subject: Re: Help - can't login References: <9701261744.AA27426@risc6.unisa.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A. Radovanovic wrote: > > My freebsd ran out of disk space in /. Unfortunately I rebooted the > system and now I can't get in - no username or password are accepted. > If I boot in a single user mode, the file system is mounted as a read > only and I can't do anything with the passwd file. > > Is there any way to get in and repair the damage? > Wow..finally a question I can answer! I too have done this deed... You need to mount your root partion with "/". This will make the file system read/write. As in, "mount /dev/wd0a / " . regards, Jim Durham From owner-freebsd-hackers Mon Jan 27 19:16:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA12525 for hackers-outgoing; Mon, 27 Jan 1997 19:16:51 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA12519 for ; Mon, 27 Jan 1997 19:16:48 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA06348; Tue, 28 Jan 1997 13:46:24 +1030 (CST) From: Michael Smith Message-Id: <199701280316.NAA06348@genesis.atrad.adelaide.edu.au> Subject: Re: 2.2-BETA Questions In-Reply-To: from Simon Shapiro at "Jan 24, 97 07:18:56 pm" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 28 Jan 1997 13:46:23 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro stands accused of saying: > Some questions about 2.2-BETA > > 1. Does anyone care? Coming from (too much) Linux, and seeing 2.1.6, > 2.2-BETa, 3.0... it is not a stupid question. Er, yes. Lots of people care. 2.2-BETA is the leadup to 2.2-RELEASE, the next production-level version. 3.0 is the current 'development' version, which will lead to a release probably sometime late this year. Exposing the devlopment process like this means that everyone can see where things are going. > 2. Assunming #1 is true, listen to this (Network Failure System; AKA NFS) > scenario: > > * Linux NFS server, Debian 1.2, Kernel 2.0.27, etc. (nomis) with this > in /etc/exports: > > /usr/src/FreeBSD sendero.i-connect.net(rw,no_root_squash) > > * FreeBSD 2.2-BETA client doing: > > # mkdir /NewStuff > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff > # ls -al /NewStuff > ls: /NewStuff: Permission denied What are the permissions on "NewStuff" on the server? Try "ls" without any other flags first. > Dunno about you but smells like a bug to me... It looks to me like the server is being _very_ weird. Someone else (Doug R.?) might have a better idea about that. > 3. Made a kernel with sound, etc... Worked fine until some days ago. > Now, all of the sudden, without me doing anything (really :-): > > # xmcd -debug > .... > Lock file: /tmp/.cdaudio/lock.f02 > Cannot open /dev/rcd0c: errno=6 Is there a CD in the drive? 6 is "not configured", which xmcd should be telling you. A list of the boot-time probe messages (output of 'dmesg') would be handy here, as I suspect that your CD wasn't found. > 4. Shutdown questions: > > a. When init goes to single user, prompts, asking for a shell. > You press ENTER and it sits on ``(.???msg - Cannot exactly > remember) not found'' > ^C will get you a prompt, most of the time. Sometimes you get > a fast roll talking about some malloc() failure. Sometimes a > ^C will stop it, sometimes it will not. Er "init goes to single user"? How are you shutting down? > b. umount -a will leave things not in /etc/fstab mounted. > It always leaves root mounted RW, only to fsck it at boot. > Seems lie an unnecessary risk. You're _definitely_ not shutting down correctly. 'man shutdown'. > 5. More CD fun. Once a music CD is played, you cannot mount a data > cd because ``device is busy''. Reboot cures. Try exiting the CD-playing program first, if you aren't already. > 8. Education Question: What is the logic in assigning slice ID's? > I understand c to be the entire disk > (why `c'? Why not?) > Why does sysinstall assign 'e', 'f', > but (almost) never 'd'? You mean partition names. Tradition, mostly. 'a' is traditionally used for a root filesystem, 'b' for swap, 'c' for the whole disk, and d-h for 'other' partitions. For a while, 'd' was used by various 386 BSD's to deal with the disparity between "the whole disk" and "the whole part of the disk that BSD uses"; this is obsoleted by the 'slice' paradigm. > 9. Some safety checks in disklabel and newfs and/or kernel slice- > partition handling could be nice. If you create an 'a' partition > which is exactly an overlap of a 'c' in a slice that dominates > the disk, newfs will FREEZE the system. Novel. I've never seen that, and I've done it many times. > 10. Kernel Question: On an i386 PC, how does one make sure that > another driver does not use the same ISA ports as you do? > You are trying to be nice and NOT use something someone else is > already using. There is a Linux thing to do that... ISA resource allocation is a particularly noisome can of worms. Currently, if your driver is configured with a base address in a region previously claimed by another driver, your probe routine won't be called. That can obviously cause problems if you plan to probe several possible port ranges in a single probe routine. If you have any particular ideas or requests here, please raise them, as we're always open to suggestions on cleaning this up. > 11. Another Kernel question: A device driver for a controller that > is available in ISA, EISA and PCI. How do you split the code? > We put the PCI part in pci, the ISA/EISA parts in i386/{isa,eisa}? > But the code is NOT i386 dependant. We are putting it in dev/dpt. > Is that a good choice? Perhaps: - have three seperate drivers (bad idea). - look at the 'ahc' and 'bt' drivers; the former is pci/eisa, the latter is pci/isa. The 'ahc' driver also has code in dev/. > Simon -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jan 27 19:19:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA12693 for hackers-outgoing; Mon, 27 Jan 1997 19:19:47 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA12680 for ; Mon, 27 Jan 1997 19:19:43 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA06367; Tue, 28 Jan 1997 13:49:15 +1030 (CST) From: Michael Smith Message-Id: <199701280319.NAA06367@genesis.atrad.adelaide.edu.au> Subject: Re: Help - can't login In-Reply-To: <32ED67A1.446B9B3D@w2xo.pgh.pa.us> from Jim Durham at "Jan 27, 97 09:42:41 pm" To: durham@w2xo.pgh.pa.us (Jim Durham) Date: Tue, 28 Jan 1997 13:49:14 +1030 (CST) Cc: radova@risc6.unisa.ac.za, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk First : this should have gone to -questions, not -hackers. Jim Durham stands accused of saying: > A. Radovanovic wrote: > > > > My freebsd ran out of disk space in /. Unfortunately I rebooted the > > system and now I can't get in - no username or password are accepted. > > If I boot in a single user mode, the file system is mounted as a read > > only and I can't do anything with the passwd file. Don't "do anything with the passwd file". FreeBSD uses a dabase-based shadow password system, and changing /etc/passwd won't do you any good at all. > > Is there any way to get in and repair the damage? > > > Wow..finally a question I can answer! I too have done this deed... > > You need to mount your root partion with "/". This will make the > file system read/write. As in, "mount /dev/wd0a / " . It's easier to say 'mount /' actually. Then you'll want 'mount /usr', and then 'passwd' to change root's password. This should be (is probably) in the FAQ. > Jim Durham -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jan 27 19:31:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13458 for hackers-outgoing; Mon, 27 Jan 1997 19:31:21 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA13442 for ; Mon, 27 Jan 1997 19:31:17 -0800 (PST) Received: (qmail 7563 invoked by uid 1000); 28 Jan 1997 04:30:21 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701272244.PAA15452@seagull.rtd.com> Date: Mon, 27 Jan 1997 20:21:06 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Don Yuniskis Subject: Re: suggestion for kernel printk() ? Cc: bde@zeta.org.au, freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Don Yuniskis; On 27-Jan-97 you wrote: > It seems that Simon Shapiro said: > > > > > I just spent some time fighting a kernel that died miserably > > > > >on boot :-( I was inundated with an endless stream of kernel > > > > >messages (in highlighted text) followed promptly by a hard reset. > > > > >It was quite frustrating to find that there doesn't seem to be a > > > > >mechanism to pause the display at this point! > > > > > > However, is it worthwhile for the mechanism that printk() ?? uses to > > > observe some kind of flow control? It did not recognize scroll_lock, > > > pause, ^S, etc. This would have at least enabled me to read some > > > (i.e. one screen full) of the messages to see what the kernel was > > > complaining about. > > > > I may be offbase here, but scroll-lock, etc. are INPUT, while printk is > > Yes. But all of those mechanisms tie in to provide flow control for > regular console output functions. Apparently, however, this happens > at a higher level than I had hoped/assumed (i.e. more stuff has to be > functional before this mechanism works). Unfortunately, this makes some sense, as there are no interrupts during some of this. I solved this porblems on a SVR4.2 port by providing the UART witha polled mode. Added a walloping 20 lines of code to the driver. What that means in a PC console I really do not know. Real computers should have only serial consoles. Preferebly an LA34. Right? :-) > > > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to > > a circular buffer andanother mechanism dumps it to ``the console''. > > If you like ugly, (if memory serves), you can either pass an additional arg > > to the output routine (A la Linux) or designate the first character in the > > string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. > > I was suggesting having printk() examine the keyboard buffer for a pending > "pause" key and blocking in this event. However, it appears that the > system couldn't handle that crude of an implementation... > > --don I am so new to FreeBSD that I did not even see that there is a printk(). How does that relate to printf() is see everywhere? Simon From owner-freebsd-hackers Mon Jan 27 19:32:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13608 for hackers-outgoing; Mon, 27 Jan 1997 19:32:36 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13531 for ; Mon, 27 Jan 1997 19:32:10 -0800 (PST) Message-Id: <199701280332.TAA13531@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA164182291; Tue, 28 Jan 1997 14:31:31 +1100 From: Darren Reed Subject: Re: Network interfaces: removal of. To: julian@whistle.com (Julian Elischer) Date: Tue, 28 Jan 1997 14:31:31 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: <32ED4558.446B9B3D@whistle.com> from "Julian Elischer" at Jan 27, 97 04:16:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Julian Elischer, sie said: > > I have a system with frame relay interfaces, and virtual circuits > are reflected by virtual 'interfaces' e.g vc0, vc2 > etc. > > the trouble is that there is no support in the kernel for REMOVING > an interface! > > does anyone have any ideas on this? Hmmm, I once modified the "if_vsr" LKM to be unloadable as an exercise on SunOS4...but even then... > removal of an interface requires that the interface addresses > be freed. this in turn requires that any routes that access that > ifa (e.g in a TCP pcb) discover that it is invalid the next time they > try use it, and try get a new rtentry/ifa. Yup. I did all that myself. Worst part is that it needs to be splimp(). > None of this happens at the moment. > > Add to that the fact that the linked list of interfaces has no support > for removing entries, and that the interface array has no support for > re-using entries. Unless it is all done manually. > The reference counting on rtentries and IFAs is next to useless > as so many places don't use them rigorously, which requires > hacks to keep them allingned with anything even close to reality.. Don't bother. > Is there anyone in the group who feels as though they understand the > situation well enough to work with me in trying to clean this up a bit? There's a few tips, but I worked under a much narrower operational conditions (i.e. I could make sure all the programs using the vif were dead, etc, before I unloaded). There may be a version of that or a more hacked version of it that works better somewhere on the 'net. Darren From owner-freebsd-hackers Mon Jan 27 20:02:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA15252 for hackers-outgoing; Mon, 27 Jan 1997 20:02:35 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA15243 for ; Mon, 27 Jan 1997 20:02:28 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.3/8.7.3) with SMTP id XAA03991; Mon, 27 Jan 1997 23:02:20 -0500 (EST) Message-Id: <199701280402.XAA03991@whizzo.transsys.com> X-Mailer: exmh version 2.0alpha 12/3/96 To: Julian Elischer cc: hackers@freebsd.org From: "Louis A. Mamakos" Subject: Re: Network interfaces: removal of. References: <32ED4558.446B9B3D@whistle.com> In-reply-to: Your message of "Mon, 27 Jan 1997 16:16:24 PST." <32ED4558.446B9B3D@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 1997 23:02:20 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > does anyone have any ideas on this? One idea: add a new message for the routing socket which can notify routing daemons that you want to delete an interface (or, like it or not, it's gone now). Hopefully they can then arrange to have active references to the interface be removed. I recall another system which had a the ability to "delete" a network interface. What it really did was cheat: it essentially overwrote the interface name, and shoved the data structure off into a corner. It was still around, though, so that if there was some errant reference to it, nothing "bad" would happen. Clearly, this is just a hack. However, it seems to work "well enough", so from a pragmatic perspective, you can't dismiss it completely. While I'm sure that the modules that reference interfaces are finite, there's nothing to allocate references to them. This would require a level of discipline unknown to the BSD net code. Hell, you might just as well wish for locks on the data structures to make the code SMP safe :-) louie From owner-freebsd-hackers Mon Jan 27 20:58:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17727 for hackers-outgoing; Mon, 27 Jan 1997 20:58:03 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17721 for ; Mon, 27 Jan 1997 20:58:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id UAA13857; Mon, 27 Jan 1997 20:57:43 -0800 (PST) Message-Id: <199701280457.UAA13857@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Lars Jonas Olsson cc: hackers@freebsd.org Subject: Re: de0 timeouts w 486 CPU In-reply-to: Your message of "Mon, 27 Jan 1997 15:34:19 CST." <199701272134.PAA10766@Venus.mcs.net> From: David Greenman Reply-To: dg@root.com Date: Mon, 27 Jan 1997 20:57:43 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I have a 486DX4-100 system that is doing make worlds fine, but >generates a lot of: > >de0: system error: master abort > >messages with a current kernel. With a 2.1R kernel it was >generating illegal interrupt errors for de0. > Any guess if this is bug in the if_de.c driver or a hardware problem? >The rate of messages is 5-30/hour on a system not doing much >networking. I would guess that it's a PCI DMA problem on the motherboard. There were quite a few 486 PCI machines that had really bad PCI performance (perhaps due to incorrect chipset configuration?). You may wish to look for any BIOS settings related to PCI write buffer, etc.. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jan 27 21:09:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18409 for hackers-outgoing; Mon, 27 Jan 1997 21:09:56 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18402 for ; Mon, 27 Jan 1997 21:09:46 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id XAA01957 for ; Mon, 27 Jan 1997 23:09:38 -0600 (CST) Received: (from driley@localhost) by crocodile.vale.com (8.8.3/8.7.3) id XAA24269; Mon, 27 Jan 1997 23:09:38 -0600 (CST) Date: Mon, 27 Jan 1997 23:09:38 -0600 (CST) From: Dan Riley To: freebsd-hackers@freefall.freebsd.org Subject: Re: suggestion for kernel printk() ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think this question may be slightly related to this topic or maybe not, but in any event, after compiling a new kernel (based on a cp of LINT) I never not get any output to the screen while booting the new kernel. What option in LINT disables the boot messages from the kernel so that the first thing(only thing) you see is the login prompt after a restart? The messages are ther once I login and dmesg or check messages... This never seems to happen when I start with a kernel based on the GENERIC example. Thanks On Mon, 27 Jan 1997, Simon Shapiro wrote: > > Hi Don Yuniskis; On 25-Jan-97 you wrote: > > It seems that Bruce Evans said: > > > > > > > I just spent some time fighting a kernel that died miserably > > > >on boot :-( I was inundated with an endless stream of kernel > > > >messages (in highlighted text) followed promptly by a hard reset. > > > >It was quite frustrating to find that there doesn't seem to be a > > > >mechanism to pause the display at this point! > > > > > > I use a serial console and `terminalprogram | tee foo' to capture > > > the output. > > > > Yes, but I would have had to have built the kernel with COMCONSOLE > > (which I didn't). > > > > > > OK, reboot from /kernel.old and look through the logs. Hmmm... > > > >nothing here! Probably the filesystem wasn't even functional when > > > >the boot ran into trouble. > > > > > > Boot messages are supposed to be preserved in the message buffer > > > across reboots. However, many PC BIOSes and/or memory systems do > > > something that invalidates the message buffer even for a soft reboot. > > > > Well, I wasn't observant enough to notice what type of restart the > > PC went through (two different varieties here -- one of which actually > > rampages through memory, etc.) but suspect this is the problem. > > > > However, is it worthwhile for the mechanism that printk() ?? uses to > > observe some kind of flow control? It did not recognize scroll_lock, > > pause, ^S, etc. This would have at least enabled me to read some > > (i.e. one screen full) of the messages to see what the kernel was > > complaining about. > > I may be offbase here, but scroll-lock, etc. are INPUT, while printk is > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to > a circular buffer andanother mechanism dumps it to ``the console''. > If you like ugly, (if memory serves), you can either pass an additional arg > to the output routine (A la Linux) or designate the first character in the > string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. > > Simon > From owner-freebsd-hackers Mon Jan 27 21:34:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA19501 for hackers-outgoing; Mon, 27 Jan 1997 21:34:58 -0800 (PST) Received: from monk.via.net (monk.via.net [140.174.204.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA19495 for ; Mon, 27 Jan 1997 21:34:56 -0800 (PST) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id VAA23113 for hackers@freebsd.org; Mon, 27 Jan 1997 21:27:19 -0800 Date: Mon, 27 Jan 1997 21:27:19 -0800 From: Joe McGuckin Message-Id: <199701280527.VAA23113@monk.via.net> To: hackers@freebsd.org Subject: Ethernet bug - 2.1.6-RELEASE X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've noticed that if I disconnect the ethernet cable from my de0 NIC, I no longer see the warning message about the cable being unplugged. Also, when I plug it back in, I no longer see the message about the UTP cable being plugged in. Also, once disconnected, the ethernet port no longer works and the machine must be rebooted to restore functionality. joe From owner-freebsd-hackers Mon Jan 27 22:58:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA24416 for hackers-outgoing; Mon, 27 Jan 1997 22:58:49 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24403 for ; Mon, 27 Jan 1997 22:58:43 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id RAA13038; Tue, 28 Jan 1997 17:52:44 +1100 Date: Tue, 28 Jan 1997 17:52:44 +1100 From: Bruce Evans Message-Id: <199701280652.RAA13038@godzilla.zeta.org.au> To: dgy@rtd.com, Shimon@i-Connect.Net Subject: Re: suggestion for kernel printk() ? Cc: bde@zeta.org.au, freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Yes. But all of those mechanisms tie in to provide flow control for >> regular console output functions. Apparently, however, this happens >> at a higher level than I had hoped/assumed (i.e. more stuff has to be >> functional before this mechanism works). > >Unfortunately, this makes some sense, as there are no interrupts during >some of this. I solved this porblems on a SVR4.2 port by providing the >UART witha polled mode. Added a walloping 20 lines of code to the driver. >What that means in a PC console I really do not know. Real computers >should have only serial consoles. Preferebly an LA34. Right? :-) It takes 200 lines in sio.c.. >> > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go >to >> > a circular buffer andanother mechanism dumps it to ``the console''. >> > If you like ugly, (if memory serves), you can either pass an additional >arg >> > to the output routine (A la Linux) or designate the first character in >the >> > string to tell what to do, as in ~==console and buffer, !=bufferonly, >etc. In BSD, printf output goes to the message buffer and the console. The syscons driver also duplicates it in the scrollback buffer. The problem is getting at this output. Scrollback doesn't work at the panic prompt. I think it was broken when syscons started using timeouts for screen updates. >> I was suggesting having printk() examine the keyboard buffer for a pending > >I am so new to FreeBSD that I did not even see that there is a printk(). >How does that relate to printf() is see everywhere? printk() doesn't exist. There is also uprintf() for printing to the controlling tty of the current process, tprintf() for printing to the controlling terminal of the specified session, ttyprintf() for printing to the specified terminal, and log() which prints to the console if the log device is not open. printf() and log() are supposed to work in interrupt handlers so they normally have to use polled output. The others are higher level. Bruce From owner-freebsd-hackers Mon Jan 27 23:15:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA25161 for hackers-outgoing; Mon, 27 Jan 1997 23:15:26 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA25150 for ; Mon, 27 Jan 1997 23:15:24 -0800 (PST) Received: from ghpc6.ihf.rwth-aachen.de (ghpc6.ihf.RWTH-Aachen.DE [134.130.90.6]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id XAA29001 for ; Mon, 27 Jan 1997 23:15:22 -0800 (PST) Received: (from thomas@localhost) by ghpc6.ihf.rwth-aachen.de (8.6.12/8.6.9) id IAA03145; Tue, 28 Jan 1997 08:13:51 +0100 From: Thomas Gellekum Message-Id: <199701280713.IAA03145@ghpc6.ihf.rwth-aachen.de> Subject: Re: 2.2-BETA Questions To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 28 Jan 1997 08:13:50 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: from Simon Shapiro at "Jan 24, 97 07:18:56 pm" Organization: Institut f. Hochfrequenztechnik, RWTH Aachen X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > 2. Assunming #1 is true, listen to this (Network Failure System; AKA NFS) > scenario: > > * Linux NFS server, Debian 1.2, Kernel 2.0.27, etc. (nomis) with this > in /etc/exports: > > /usr/src/FreeBSD sendero.i-connect.net(rw,no_root_squash) > > * FreeBSD 2.2-BETA client doing: > > # mkdir /NewStuff > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff Should be # mount -t nfs -o ro,resvport nomis:/usr/src/FreeBSD /NewStuff tg From owner-freebsd-hackers Mon Jan 27 23:36:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA26848 for hackers-outgoing; Mon, 27 Jan 1997 23:36:37 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA26839 for ; Mon, 27 Jan 1997 23:36:32 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id XAA02691 for ; Mon, 27 Jan 1997 23:37:42 -0800 (PST) Received: (qmail 11240 invoked by uid 110); 28 Jan 1997 07:36:04 -0000 Message-ID: <19970128073604.11239.qmail@suburbia.net> Subject: Re: gomoku In-Reply-To: from J Wunsch at "Jan 27, 97 09:44:13 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 28 Jan 1997 18:36:03 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Julian Assange wrote: > > > Is there any reason that gomoku from Lite2 is missing from > > /usr/src/games? > > Yes: nobody ever did start a full userland Lite2 merge (not even a > vendor-branch import, but that's already a large part of the work to > be done). > > -- > 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. ;-) > I've almost finished my lite2 libc merge. The most interesting addition so far is union extensions for readdir(). Would any of the doc people like to volunteer for merging the man pages? Cheers, Julian From owner-freebsd-hackers Mon Jan 27 23:42:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA27577 for hackers-outgoing; Mon, 27 Jan 1997 23:42:20 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA27562 for ; Mon, 27 Jan 1997 23:42:15 -0800 (PST) Received: (qmail 25535 invoked by uid 1000); 28 Jan 1997 08:41:29 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701280316.NAA06348@genesis.atrad.adelaide.edu.au> Date: Tue, 28 Jan 1997 00:00:34 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Michael Smith Subject: Re: 2.2-BETA Questions Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Michael Smith; On 28-Jan-97 you wrote: > > 1. Does anyone care? Coming from (too much) Linux, and seeing 2.1.6, > > 2.2-BETa, 3.0... it is not a stupid question. > > Er, yes. Lots of people care. 2.2-BETA is the leadup to 2.2-RELEASE, > the next production-level version. 3.0 is the current 'development' > version, which will lead to a release probably sometime late this > year. Exposing the devlopment process like this means that everyone > can see where things are going. Good. Coming from another freely distributed ``O/S'' over the last couple of years, I am used to bi-weekly versions, etc. This is why I asked. > > # mkdir /NewStuff > > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff > > # ls -al /NewStuff > > ls: /NewStuff: Permission denied > > What are the permissions on "NewStuff" on the server? Try "ls" without > any other flags first. Permissions matter not. Can be 777, 1777 755, ... The mount point simply disappears. > It looks to me like the server is being _very_ weird. Someone else > (Doug R.?) might have a better idea about that. Yea, I figured this much, but the Linux ``gurus'' insist, theirs is the only ``correct'' NFS server... As I said, it works (very well!) the other way around... > > > 3. Made a kernel with sound, etc... Worked fine until some days ago. > > Now, all of the sudden, without me doing anything (really :-): > > > > # xmcd -debug > > .... > > Lock file: /tmp/.cdaudio/lock.f02 > > Cannot open /dev/rcd0c: errno=6 > > Is there a CD in the drive? 6 is "not configured", which xmcd should be > telling you. A list of the boot-time probe messages (output of 'dmesg') > would be handy here, as I suspect that your CD wasn't found. Yup. So much so that sysinstall tells me it is not a current installation CD! (Yes, it IS music, not iso9660 - Kitaro ``Ten Years''). Actually, the problem may arise because there was a GNU distribution CD in the drive at boot time. Works for data, does not for music, until the next boot. Ugly. Just checked. I can mount an is09660 CD with no problem (even a Linux one :-), but all the CD music tools I found cannot open /dev/rcd0c crw------- 1 root wheel 15, 536870912 Jan 24 16:01/dev/rcd0.ctl crw-r----- 1 root operator 15, 0 Jan 24 16:01 /dev/rcd0a crw-r----- 1 root operator 15, 2 Jan 24 16:01 /dev/rcd0c crw-r----- 1 root operator 15, 3 Sep 15 18:16 /dev/rcd0d What is the kernel config option for CD audio support? > > > 4. Shutdown questions: > > > > a. When init goes to single user, prompts, asking for a shell. > > You press ENTER and it sits on ``(.???msg - Cannot exactly > > remember) not found'' > > ^C will get you a prompt, most of the time. Sometimes you get > > a fast roll talking about some malloc() failure. Sometimes a > > ^C will stop it, sometimes it will not. > > Er "init goes to single user"? How are you shutting down? # shutdown now > > > b. umount -a will leave things not in /etc/fstab mounted. > > It always leaves root mounted RW, only to fsck it at boot. > > Seems lie an unnecessary risk. > > You're _definitely_ not shutting down correctly. 'man shutdown'. Thanx. But ``shutdown now'' is a valid option, generates no complaints and gives the results indicated. > > 5. More CD fun. Once a music CD is played, you cannot mount a data > > cd because ``device is busy''. Reboot cures. > > Try exiting the CD-playing program first, if you aren't already. Yup. Done that, been there. To no avail. Something IS wron. > > 8. Education Question: What is the logic in assigning slice ID's? > > I understand c to be the entire disk > > (why `c'? Why not?) > > Why does sysinstall assign 'e', 'f', > > but (almost) never 'd'? > > You mean partition names. Tradition, mostly. 'a' is traditionally > used for a root filesystem, 'b' for swap, 'c' for the whole disk, and > d-h for 'other' partitions. For a while, 'd' was used by various > 386 BSD's to deal with the disparity between "the whole disk" and > "the whole part of the disk that BSD uses"; this is obsoleted by > the 'slice' paradigm. Thanx! now I know. > > 9. Some safety checks in disklabel and newfs and/or kernel slice- > > partition handling could be nice. If you create an 'a' partition > > which is exactly an overlap of a 'c' in a slice that dominates > > the disk, newfs will FREEZE the system. > > Novel. I've never seen that, and I've done it many times. I checked some more. It has to do with the manner in which disklabel is called. If you have it use /etc/disktab, all is well. The -e is only safe if you initialized with the (-rwB?) /etc/disktab option. > > 10. Kernel Question: On an i386 PC, how does one make sure that > > another driver does not use the same ISA ports as you do? > > You are trying to be nice and NOT use something someone else is > > already using. There is a Linux thing to do that... > > ISA resource allocation is a particularly noisome can of worms. > Currently, if your driver is configured with a base address in a > region previously claimed by another driver, your probe routine won't > be called. That can obviously cause problems if you plan to probe > several possible port ranges in a single probe routine. Perfect! Linux drivers seem to explicitly call some routine that registers the addresses. I like hte BSD solution better. > If you have any particular ideas or requests here, please raise them, > as we're always open to suggestions on cleaning this up. A blow torch and a stick of dynamite :-) Reason for asking is a PCI controller that can be configured (via BIOS) to ``sit'' in ISA adress range. The Linux driver probes to see that it does not (essentially) overlap with an IDE controller which it can emulate... > > 11. Another Kernel question: A device driver for a controller that > > is available in ISA, EISA and PCI. How do you split the code? > > We put the PCI part in pci, the ISA/EISA parts in i386/{isa,eisa}? > > But the code is NOT i386 dependant. We are putting it in dev/dpt. > > Is that a good choice? > > Perhaps: > - have three seperate drivers (bad idea). > - look at the 'ahc' and 'bt' drivers; the former is pci/eisa, the latter > is pci/isa. The 'ahc' driver also has code in dev/. Yes, but pieces still sit in i386. We will avoid that. Thanx! Simon From owner-freebsd-hackers Tue Jan 28 00:21:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA00112 for hackers-outgoing; Tue, 28 Jan 1997 00:21:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA00107 for ; Tue, 28 Jan 1997 00:21:05 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA25648 for freebsd-hackers@freebsd.org; Tue, 28 Jan 1997 09:21:03 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA15436; Tue, 28 Jan 1997 09:04:40 +0100 (MET) Message-ID: Date: Tue, 28 Jan 1997 09:04:40 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: fdisk headache References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Jan 27, 1997 14:27:12 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > > Why are you using fdisk at all? You are running Unix, you aren't > > running on a PC, you are not supposed to use fdisk (unless other > > systems on your disk force you to this step). > > Slow down.... The gentleman has a valid point, methinks. If not, ...well, and you've cut my smiley. ;-) > please show me how to build 120 filesystems on a disk that is 750GB > large. Impossible/stupid numbers? not really when considering a large > disk array with a very large database. _You_ have a valid point with this, but Jean-Marc didn't -- he wants to use a plain 4-partition only system. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Jan 28 00:43:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA01137 for hackers-outgoing; Tue, 28 Jan 1997 00:43:58 -0800 (PST) Received: from ghpc6.ihf.rwth-aachen.de (ghpc6.ihf.RWTH-Aachen.DE [134.130.90.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA01130 for ; Tue, 28 Jan 1997 00:43:55 -0800 (PST) Received: (from thomas@localhost) by ghpc6.ihf.rwth-aachen.de (8.6.12/8.6.9) id JAA03366; Tue, 28 Jan 1997 09:43:40 +0100 From: Thomas Gellekum Message-Id: <199701280843.JAA03366@ghpc6.ihf.rwth-aachen.de> Subject: Re: 2.2-BETA Questions To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 28 Jan 1997 09:43:39 +0100 (MET) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG In-Reply-To: from Simon Shapiro at "Jan 28, 97 00:00:34 am" Organization: Institut f. Hochfrequenztechnik, RWTH Aachen X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: [Charset iso-8859-8 unsupported, filtering to ASCII...] > What is the kernel config option for CD audio support? There's nothing special. Could you post the lines from the probe messages (see dmesg(8))? xmcd works fine with a Hitachi drive I have here (CDR-7930, ATAPI, in case someone's interested; xmcd linked with lesstif-0.75a). tg From owner-freebsd-hackers Tue Jan 28 00:51:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA01339 for hackers-outgoing; Tue, 28 Jan 1997 00:51:50 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA01333 for ; Tue, 28 Jan 1997 00:51:47 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA25976; Tue, 28 Jan 1997 09:51:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA15524; Tue, 28 Jan 1997 09:21:53 +0100 (MET) Message-ID: Date: Tue, 28 Jan 1997 09:21:53 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Shimon@i-Connect.Net (Simon Shapiro) Cc: hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Jan 24, 1997 19:18:56 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > 1. Does anyone care? Coming from (too much) Linux, and seeing 2.1.6, > 2.2-BETa, 3.0... it is not a stupid question. 2.1.6 is the latest release. 2.2 is the next release, currently in post-BETA. 3.0 is the head of the development (``3.0-current'') > # mkdir /NewStuff > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff > # ls -al /NewStuff > ls: /NewStuff: Permission denied > ls -al / > .... > drwxr-xr-x 2 root wheel 512 Jan 3 00:08 Linux-Transfers > drwxr-xr-x 2 root wheel 512 Jan 23 18:01 NewRoot > drwxrwxrwt 13 root sys 512 Jan 8 12:02 SourceControl > > [ /NewStuff is not there? ] It is, but... ? That's funny. Never seen this, but i never had an occasion to test against a Linux NFS server. > # xmcd -debug > .... > Lock file: /tmp/.cdaudio/lock.f02 > Cannot open /dev/rcd0c: errno=6 ENXIO. You `cd' driver seems confused. You could hook a few printf's into /sys/scsi/cd.c (inside cd_open()) to see which of the ENXIO's hits. Either the drive claims there's no medium inside, or it fails a READ CAPACITY command. What drive is it? > # ls -al /dev/rcd0c > crw-r----- 1 root operator 15, 2 Jan 24 16:01 /dev/rcd0c Of course, all this doesn't matter. ENXIO must not be confused with any part on the device node itself. It's a plain driver message. > 4. Shutdown questions: > > a. When init goes to single user, prompts, asking for a shell. > You press ENTER and it sits on ``(.???msg - Cannot exactly > remember) not found'' > ^C will get you a prompt, most of the time. Sometimes you get > a fast roll talking about some malloc() failure. Sometimes a > ^C will stop it, sometimes it will not. David Greenman has been the only one by now who also reported such a behaviour. > b. umount -a will leave things not in /etc/fstab mounted. Well, that's what the `-a' means: umount everything in fstab. The options are as follows: -a All of the file systems described in fstab(5) are unmounted. > 5. More CD fun. Once a music CD is played, you cannot mount a data > cd because ``device is busy''. Reboot cures. That's probably related to the error above. Btw., try `cdcontrol' to play your audio CD, and see if it does make a difference. xmcd is a little too funny to trust it as a generic debugging tool. They have a tendency to hack on the SCSI bus, so i wouldn't be surprised if this leaves the driver confused if something behaves different on your drive. > 8. Education Question: What is the logic in assigning slice ID's? > I understand c to be the entire disk > (why `c'? Why not?) > Why does sysinstall assign 'e', 'f', > but (almost) never 'd'? That's explained in section 2.15 of the FAQ (near the bottom). The short answer: for hysterical raisons. > 9. Some safety checks in disklabel and newfs and/or kernel slice- > partition handling could be nice. If you create an 'a' partition > which is exactly an overlap of a 'c' in a slice that dominates > the disk, newfs will FREEZE the system. This seems to happen only on your system, for whatever reason. I know of several people who are running a partition that is full-size the slice (or entire disk). > 10. Kernel Question: On an i386 PC, how does one make sure that > another driver does not use the same ISA ports as you do? If it's assigned using the config stuff, the ISA bus driver code will assure this. Some drivers (like syscons) don't fit right; they use too many ports to describe in config's syntax. The number of ports used by this driver is returned from the driver attach routine. > 11. Another Kernel question: A device driver for a controller that > is available in ISA, EISA and PCI. How do you split the code? > We put the PCI part in pci, the ISA/EISA parts in i386/{isa,eisa}? > But the code is NOT i386 dependant. We are putting it in dev/dpt. > Is that a good choice? Probably the best you could do by now. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Jan 28 01:20:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA02272 for hackers-outgoing; Tue, 28 Jan 1997 01:20:41 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA02267 for ; Tue, 28 Jan 1997 01:20:37 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA26418; Tue, 28 Jan 1997 10:20:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA15638; Tue, 28 Jan 1997 09:54:59 +0100 (MET) Message-ID: Date: Tue, 28 Jan 1997 09:54:58 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: driley@vailsys.com (Dan Riley) Cc: freebsd-hackers@freefall.freebsd.org Subject: Re: suggestion for kernel printk() ? References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Dan Riley on Jan 27, 1997 23:09:38 -0600 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Dan Riley wrote: > I think this question may be slightly related to this topic or maybe not, > but in any event, after compiling a new kernel (based on a cp of LINT) I > never not get any output to the screen while booting the new kernel. What > option in LINT disables the boot messages from the kernel so that the first > thing(only thing) you see is the login prompt after a restart? :-)) You forgot to take out options COMCONSOLE again. *smile* LINT is not a good template to base your own kernel upon. Use GENERIC, and add stuff from LINT once you're sure about the meaning. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Jan 28 01:46:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA03127 for hackers-outgoing; Tue, 28 Jan 1997 01:46:51 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA03121 for ; Tue, 28 Jan 1997 01:46:49 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id BAA07493; Tue, 28 Jan 1997 01:46:43 -0800 (PST) To: Simon Shapiro cc: hackers@freebsd.org Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Fri, 24 Jan 1997 19:18:56 PST." Date: Tue, 28 Jan 1997 01:46:43 -0800 Message-ID: <7489.854444803@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > # mkdir /NewStuff > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff # mount -t nfs -o ro,resvport nomis:/usr/src/FreeBSD /NewStuff Now try it. > 3. Made a kernel with sound, etc... Worked fine until some days ago. > Now, all of the sudden, without me doing anything (really :-): Hmph. Sound still works just fine for me using this morning's kernel. I don't believe you. :-) You must have mucked something else up, though you're probably looking in the wrong place for "something" right now. > a. When init goes to single user, prompts, asking for a shell. > You press ENTER and it sits on ``(.???msg - Cannot exactly > remember) not found'' I would like to know what that message is. It works fine. > 5. More CD fun. Once a music CD is played, you cannot mount a data > cd because ``device is busy''. Reboot cures. Can't reproduce. Are you SURE that xcdplayer or whatever player you're using isn't still running somewhere? > 7. trying /stand/sysinstall from a live system dumps core either on > (the equivalent of) fdisk or disklabel. Fixed in later versions. > 10. Kernel Question: On an i386 PC, how does one make sure that > another driver does not use the same ISA ports as you do? "you" being whom in this example? The question doesn't quite parse into anything I can immediately answer. One answer might be "boot -c", but that's assuming a certain value for the question. :-) > 11. Another Kernel question: A device driver for a controller that > is available in ISA, EISA and PCI. How do you split the code? 3 probe routines and one common set of driver code, if possible. See how the Buslogic driver is done, for example. Jordan From owner-freebsd-hackers Tue Jan 28 02:20:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA04351 for hackers-outgoing; Tue, 28 Jan 1997 02:20:38 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA04314; Tue, 28 Jan 1997 02:20:26 -0800 (PST) Received: from nanguo.chalmers.com.au (chalmers.com.au) by mail.crl.com with SMTP id AA21426 (5.65c/IDA-1.5); Tue, 28 Jan 1997 02:19:52 -0800 Received: (from robert@localhost) by nanguo.chalmers.com.au (8.7.6/8.7.3) id UAA00874; Tue, 28 Jan 1997 20:02:03 +1000 (EST) From: Robert Chalmers Message-Id: <199701281002.UAA00874@nanguo.chalmers.com.au> Subject: progress report on connection problems To: freebsd-questions@freebsd.org (bsd) Date: Tue, 28 Jan 1997 20:02:02 +1000 (EST) Cc: freebsd-isp@freebsd.org (FreeBSD ISP), hackers@freebsd.org 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In the hopes that someone more knowledgable than I may have an explanation. I realise this is not in bug report format. FreeBSD nanguo.chalmers.com.au 2.2-961014-SNAP FreeBSD 2.2-961014-SNAP #0: Tue Jan 28 14:23:53 EST 1997 root@nanguo.chalmers.com.au:/usr/src/sys/compile/MYKERNEL i386 I am connected to the carrier (ISP) through my Stallion EasyServer 8 Port. This is an Annex the same as the XYLogics Annex. Running V9.xx software erpcd. The problem that has surfaced; Some, not all, sites around the world are not able to connect to any of my FreeBSD servers to exchange information. Let me rephrase that: They can connect, but not exchange information past that point. I have no idea what OSs the other sites are using. The number of sites is not large, but significant. I am currently logging over 4000 connections a month from individual places. Well over 1GB of data transferred. the Problem. examples: 1. mail (sendmail) to some sites can only deliver 1 line messages. To other sites not at all. The sites report back with timeout and other messages indicating a failure to complete transactions with my site 2. ftp from other sites into the ftp server will connect then hang, and the connection is reset. Most interestingly, one freebsd site changed to a Linux server, and connected fine, and completed the transfer. 3. http/web servers will connect and hang, others will go so slowly that they are as good as unusable. Most notable are yahoo.com and linkexchange.com. All the other search engines connect and exchange data with no worries. It should be noted that linkexchange.com will talk happily to this site, EXCEPT when it is required to SUBMIT my banner for its archive. It connects, then I get a server error from Linkexchanges server. Yahoo simply fails all together. The error returned is a timeout. Systems known to work with my site with no worries. SCO Unix BSDI NT '95 I can connect to, and be connected to these OSs with no worries. I have tried setting tcp_extensions NO and YES. If set to YES, I am unable to ftp to another FBSD site that also has tcp_extensions set YES (on). The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection worked fine, the other end being (on). The same happened at the other end, when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. The only constant is the Annex. However, why does it pass _most_ traffic, if it is the fault of the Annex, and only fail on some.? If FreeBSD is going to be so fussy about its tcp/ip flow, shouldn't it be reworked. The world is still full of less than leading edge hardware! Some of it brand new... If anyone wants to comment or offer help, I'mm happy to keep trying to track this bug(ger) down. cheers, Robert -- Triple-W: P.O. Box 2003. Mackay. 4740 +61-0412-079025 robert@chalmers.com.au for Whirled Peas http://www.chalmers.com.au Location: Whitsunday Web Works. 21'7" S, 149'14" E. From owner-freebsd-hackers Tue Jan 28 03:47:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA09832 for hackers-outgoing; Tue, 28 Jan 1997 03:47:40 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA09824; Tue, 28 Jan 1997 03:47:32 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.4/8.7.3) id MAA17415; Tue, 28 Jan 1997 12:48:53 +0100 (MET) From: Søren Schmidt Message-Id: <199701281148.MAA17415@ravenock.cybercity.dk> Subject: Re: progress report on connection problems In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> from Robert Chalmers at "Jan 28, 97 08:02:02 pm" To: robert@nanguo.chalmers.com.au (Robert Chalmers) Date: Tue, 28 Jan 1997 12:48:44 +0100 (MET) Cc: freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Robert Chalmers who wrote: [lots o descriptions deleted] > I can connect to, and be connected to these OSs with no worries. > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > to ftp to another FBSD site that also has tcp_extensions set YES (on). > The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection > worked fine, the other end being (on). The same happened at the other end, > when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? Hmm, I'm seeing problems with the Annex's too if I run with tcp_extensions enabled. Somehow the Annex's turn some of the trafic into "chernobyl" packets (ie all lamps and bells set). This is only a problem if the other end also supports the extensions (ie a FreeBSD box). However all problems dissapear if I disable the extensions. I guess the only solution is to bug the vendor to implement a modern IP stackc... > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... Disable the tcp_extentions is the only solution to the problems I'm seeing as it is not the FreeBSD end that is at fault, and hence I cannot fix it :( -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Tue Jan 28 05:06:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA13075 for hackers-outgoing; Tue, 28 Jan 1997 05:06:35 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA13070 for ; Tue, 28 Jan 1997 05:06:32 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id XAA24970; Tue, 28 Jan 1997 23:56:44 +1100 Date: Tue, 28 Jan 1997 23:56:44 +1100 From: Bruce Evans Message-Id: <199701281256.XAA24970@godzilla.zeta.org.au> To: msmith@atrad.adelaide.edu.au, Shimon@i-Connect.Net Subject: Re: 2.2-BETA Questions Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > 9. Some safety checks in disklabel and newfs and/or kernel slice- >> > partition handling could be nice. If you create an 'a' partition >> > which is exactly an overlap of a 'c' in a slice that dominates >> > the disk, newfs will FREEZE the system. >> >> Novel. I've never seen that, and I've done it many times. > >I checked some more. It has to do with the manner in which disklabel is >called. If you have it use /etc/disktab, all is well. The -e is only safe >if you initialized with the (-rwB?) /etc/disktab option. `disklabel -e' should not start unless the label already exists. Perhaps you had a wrong label and reinitializing it fixed it. >> > 10. Kernel Question: On an i386 PC, how does one make sure that >> > another driver does not use the same ISA ports as you do? >> > You are trying to be nice and NOT use something someone else is >> > already using. There is a Linux thing to do that... >> >> ISA resource allocation is a particularly noisome can of worms. >> Currently, if your driver is configured with a base address in a >> region previously claimed by another driver, your probe routine won't >> be called. That can obviously cause problems if you plan to probe >> several possible port ranges in a single probe routine. > >Perfect! Linux drivers seem to explicitly call some routine that registers >the addresses. I like hte BSD solution better. It's simpler when it works, but inadequate. Bruce From owner-freebsd-hackers Tue Jan 28 06:03:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA15141 for hackers-outgoing; Tue, 28 Jan 1997 06:03:35 -0800 (PST) Received: from buffnet4.buffnet.net (root@buffnet4.buffnet.net [205.246.19.13]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA15131; Tue, 28 Jan 1997 06:03:30 -0800 (PST) Received: from buffnet1.buffnet.net (mmdf@buffnet1.buffnet.net [205.246.19.10]) by buffnet4.buffnet.net (8.6.12/8.6.9) with SMTP id IAA04331; Tue, 28 Jan 1997 08:45:49 -0500 Received: from buffnet11.buffnet.net by buffnet1.buffnet.net id aa13578; 28 Jan 97 9:03 EST Date: Tue, 28 Jan 1997 09:03:16 -0500 (EST) From: Steve To: Robert Chalmers cc: bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? > > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... I had similar problems using annexes as term servers with user - and have posted numerous times that this problem only exists with freebsd - sco, linux, etc doesnt have trouble - only every time I post it I get bashed about the head and lectured on freebsd having perfect tcp/ip and everything else in the world having faulty tcp/ip. So good luck to you sir! From owner-freebsd-hackers Tue Jan 28 06:09:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA15508 for hackers-outgoing; Tue, 28 Jan 1997 06:09:31 -0800 (PST) Received: from ami.tom.computerworks.net (root@AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA15503 for ; Tue, 28 Jan 1997 06:09:27 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #1) id m0vpEDI-0021VbC; Tue, 28 Jan 97 09:08 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id IAA04275; Tue, 28 Jan 1997 08:04:43 -0600 Date: Tue, 28 Jan 1997 08:04:43 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199701281404.IAA04275@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: file locking / firewalling based on uid/gid Newsgroups: taronga.freebsd.hackers In-Reply-To: <199701031720.SAA00624@yedi.iaf.nl> References: <199701030443.UAA28355@freefall.freebsd.org> Organization: none Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701031720.SAA00624@yedi.iaf.nl>, Wilko Bulte wrote: >And who does the chown() to allow users to get at their mail? This is only a problem because in 2.7 or so chown() for regular users was disabled to allow for the use of chown() in the "handin" program to verify assignment turn-in for users on the EECS 11/70. Later it was pointed out that you could do it by making the files created by turnin setuid, since chowning disabled the setuid bit, but by then the damage was done. The only reason for disabling chown any more is for quotas, and quotas don't work right anyway. I'd like to recommend going back to the USG semantics for chown(). From owner-freebsd-hackers Tue Jan 28 06:33:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA16699 for hackers-outgoing; Tue, 28 Jan 1997 06:33:35 -0800 (PST) Received: from beauty.nacamar.de (root@beauty.nacamar.de [194.112.16.36]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA16688 for ; Tue, 28 Jan 1997 06:33:32 -0800 (PST) Received: from petzi (petzi.nacamar.de [194.162.54.13]) by beauty.nacamar.de (8.8.4/8.7.3) with SMTP id PAA18909 for ; Tue, 28 Jan 1997 15:33:27 +0100 Message-Id: <2.2.32.19970128143327.00b74300@mail.nacamar.de> X-Sender: petzi@mail.nacamar.de X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Jan 1997 15:33:27 +0100 To: hackers@freebsd.org From: Michael Beckmann Subject: 2.2 sources ? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there, I wonder where one can get the current FreeBSD 2.2 source tree. It seems that the -current tree is FreeBSD 3.0 now. The reason why I ask is that I want to build a kernel from newer sources than 2.2-BETA. Cheers, Michael From owner-freebsd-hackers Tue Jan 28 06:43:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA17178 for hackers-outgoing; Tue, 28 Jan 1997 06:43:49 -0800 (PST) Received: from atena.eurocontrol.fr (atena.uneec.eurocontrol.fr [147.196.69.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA17170 for ; Tue, 28 Jan 1997 06:43:41 -0800 (PST) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA29277; Tue, 28 Jan 1997 15:43:36 +0100 Received: (from roberto@localhost) by caerdonn.eurocontrol.fr (8.8.5/caerdonn-1.1) id PAA26987; Tue, 28 Jan 1997 15:43:32 +0100 (MET) Message-Id: <19970128154332.HX30377@caerdonn.eurocontrol.fr> Date: Tue, 28 Jan 1997 15:43:32 +0100 From: roberto@eurocontrol.fr (Ollivier Robert) To: freebsd-hackers@FreeBSD.ORG (FreeBSD Hackers' list) Subject: MAXMEM and userconfig X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk When one has more than 64 MB of RAM, for now, one has to add the MAXMEM option to the kernel configuration file and recompile. I (and others) think that it would be a valuable addition to Userconfig or the bootblock (providing that we have the space of course)... Comments ? -- Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr Usenet Canal Historique From owner-freebsd-hackers Tue Jan 28 07:11:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA18385 for hackers-outgoing; Tue, 28 Jan 1997 07:11:09 -0800 (PST) Received: from ns.ge.com (ns.ge.com [192.35.39.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA18379; Tue, 28 Jan 1997 07:11:05 -0800 (PST) Received: from thomas.ge.com (thomas.ge.com [3.47.28.21]) by ns.ge.com (8.8.4/8.7.3) with ESMTP id KAA22402; Tue, 28 Jan 1997 10:07:36 -0500 (EST) Received: from crissy.gemis.ge.com (crissy-ether.gemis.ge.com [3.29.7.204]) by thomas.ge.com (8.8.4/8.7.5) with SMTP id KAA24853; Tue, 28 Jan 1997 10:10:28 -0500 (EST) Received: from terrapin.salem.ge.com (terrapin.salem.ge.com [3.29.6.145]) by crissy.gemis.ge.com (8.6.11/8.6.11) with ESMTP id KAA28015; Tue, 28 Jan 1997 10:01:39 -0500 Received: from combs.salem.ge.com (combs.salem.ge.com [3.29.5.200]) by terrapin.salem.ge.com (8.8.3/8.8.3) with ESMTP id KAA01129; Tue, 28 Jan 1997 10:01:35 -0500 (EST) Received: from localhost (steve@localhost) by combs.salem.ge.com (8.8.3/8.8.3) with SMTP id KAA00635; Tue, 28 Jan 1997 10:01:35 -0500 (EST) Date: Tue, 28 Jan 1997 10:01:34 -0500 (EST) From: "Stephen F. Combs" To: Steve cc: Robert Chalmers , bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Xylogics Annex terminal servers running a s/w release PRIOR to 10.1 don't pass the RFC1323 and RFC 1644 stuff properly. If you set your 'tcp_extensions=NO' it should work just fine. Also tell your ISP to upgrade! I did and it works just fine! ---- Stephen F. Combs Internet: CombsSF@Salem.GE.COM GE Industrial Systems Voice: 540.387.8828 Network Services Home: CombsSF-Home@Salem.GE.COM 1501 Roanoke Blvd FAX: 540.387.7106 Salem, VA 24153 LapTop: CombsSF-Mobile@Salem.GE.COM On Tue, 28 Jan 1997, Steve wrote: > Date: Tue, 28 Jan 1997 09:03:16 -0500 (EST) > From: Steve > To: Robert Chalmers > Cc: bsd , > FreeBSD ISP , hackers@freebsd.org > Subject: Re: progress report on connection problems > > > > > The only constant is the Annex. However, why does it pass _most_ traffic, > > if it is the fault of the Annex, and only fail on some.? > > > > If FreeBSD is > > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > > The world is still full of less than leading edge hardware! Some of it > > brand new... > > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. > > So good luck to you sir! > > From owner-freebsd-hackers Tue Jan 28 07:24:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA19068 for hackers-outgoing; Tue, 28 Jan 1997 07:24:37 -0800 (PST) Received: from frig.mt.cs.keio.ac.jp (frig.mt.cs.keio.ac.jp [131.113.32.7]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA19062 for ; Tue, 28 Jan 1997 07:24:33 -0800 (PST) Received: (from hosokawa@localhost) by frig.mt.cs.keio.ac.jp (8.6.12+2.4W/3.4Wbeta3) id AAA18649; Wed, 29 Jan 1997 00:23:24 +0900 Date: Wed, 29 Jan 1997 00:23:24 +0900 Message-Id: <199701281523.AAA18649@frig.mt.cs.keio.ac.jp> To: roberto@eurocontrol.fr Cc: freebsd-hackers@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: MAXMEM and userconfig In-Reply-To: Your message of Tue, 28 Jan 1997 15:43:32 +0100. <19970128154332.HX30377@caerdonn.eurocontrol.fr> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19970128154332.HX30377@caerdonn.eurocontrol.fr> roberto@eurocontrol.fr writes: >> I (and others) think that it would be a valuable addition to Userconfig or >> the bootblock (providing that we have the space of course)... I second this proposal. I also think that some device-dependent options should be replaced with flags for device driver because of same reasons. -- HOSOKAWA, Tatsumi E-mail: hosokawa@mt.cs.keio.ac.jp WWW homepage: http://www.mt.cs.keio.ac.jp/person/hosokawa.html Department of Computer Science, Keio University, Yokohama, Japan From owner-freebsd-hackers Tue Jan 28 07:46:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA20331 for hackers-outgoing; Tue, 28 Jan 1997 07:46:06 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA20322 for ; Tue, 28 Jan 1997 07:46:02 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id CAA28783; Wed, 29 Jan 1997 02:44:14 +1100 Date: Wed, 29 Jan 1997 02:44:14 +1100 From: Bruce Evans Message-Id: <199701281544.CAA28783@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, roberto@eurocontrol.fr Subject: Re: MAXMEM and userconfig Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >When one has more than 64 MB of RAM, for now, one has to add the MAXMEM >option to the kernel configuration file and recompile. >I (and others) think that it would be a valuable addition to Userconfig or >the bootblock (providing that we have the space of course)... It's already hacked into config and userconfig: iosiz npx0 See LINT. Bruce From owner-freebsd-hackers Tue Jan 28 07:52:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA20743 for hackers-outgoing; Tue, 28 Jan 1997 07:52:45 -0800 (PST) Received: from atena.eurocontrol.fr (atena.uneec.eurocontrol.fr [147.196.69.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA20737 for ; Tue, 28 Jan 1997 07:52:41 -0800 (PST) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA30019; Tue, 28 Jan 1997 16:52:31 +0100 Received: (from roberto@localhost) by caerdonn.eurocontrol.fr (8.8.5/caerdonn-1.1) id QAA27479; Tue, 28 Jan 1997 16:52:31 +0100 (MET) Message-Id: <19970128165230.SU09584@caerdonn.eurocontrol.fr> Date: Tue, 28 Jan 1997 16:52:30 +0100 From: roberto@eurocontrol.fr (Ollivier Robert) To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-hackers@freebsd.org Subject: Re: MAXMEM and userconfig References: <199701281544.CAA28783@godzilla.zeta.org.au> X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT In-Reply-To: <199701281544.CAA28783@godzilla.zeta.org.au>; from Bruce Evans on Jan 29, 1997 02:44:14 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Bruce Evans: > It's already hacked into config and userconfig: > > iosiz npx0 > > See LINT. Thanks, I must have missed the commit. I guess it is only for CURRENT and won't be available for 2.2 ? -- Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr Usenet Canal Historique From owner-freebsd-hackers Tue Jan 28 08:36:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA22721 for hackers-outgoing; Tue, 28 Jan 1997 08:36:04 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA22684; Tue, 28 Jan 1997 08:35:54 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id SAA02793; Tue, 28 Jan 1997 18:34:26 +0200 (EET) Date: Tue, 28 Jan 1997 18:34:26 +0200 (EET) From: Narvi To: Robert Chalmers cc: bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Have you tried switching off the TCP extensions? See /etc/sysconfig, you can turn of support for two related rfc-s there... Sander On Tue, 28 Jan 1997, Robert Chalmers wrote: > In the hopes that someone more knowledgable than I may have an explanation. > > I realise this is not in bug report format. > FreeBSD nanguo.chalmers.com.au 2.2-961014-SNAP FreeBSD 2.2-961014-SNAP #0: Tue Jan 28 14:23:53 EST 1997 root@nanguo.chalmers.com.au:/usr/src/sys/compile/MYKERNEL i386 > > I am connected to the carrier (ISP) through my Stallion EasyServer 8 Port. > This is an Annex the same as the XYLogics Annex. Running V9.xx software erpcd. > > > The problem that has surfaced; > > Some, not all, sites around the world are not able to connect > to any of my FreeBSD servers to exchange information. Let me rephrase that: > They can connect, but not exchange information past that point. > I have no idea what OSs the other sites are using. The number of sites is > not large, but significant. I am currently logging over 4000 connections a > month from individual places. Well over 1GB of data transferred. > > the Problem. > examples: > 1. mail (sendmail) to some sites can only deliver 1 line > messages. To other sites not at all. The sites report back > with timeout and other messages indicating a failure to > complete transactions with my site > > 2. ftp from other sites into the ftp server will connect then > hang, and the connection is reset. > Most interestingly, one freebsd site changed to a Linux > server, and connected fine, and completed the transfer. > > 3. http/web servers will connect and hang, others will go so > slowly that they are as good as unusable. > Most notable are yahoo.com and linkexchange.com. > > All the > other search engines connect and exchange data with no > worries. > > It should be noted that linkexchange.com will talk happily > to this site, EXCEPT when it is required to SUBMIT my > banner for its archive. It connects, then I get a server > error from Linkexchanges server. Yahoo simply fails > all together. The error returned is a timeout. > > > Systems known to work with my site with no worries. > SCO Unix > BSDI > NT > '95 > > I can connect to, and be connected to these OSs with no worries. > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > to ftp to another FBSD site that also has tcp_extensions set YES (on). > The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection > worked fine, the other end being (on). The same happened at the other end, > when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? > > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... > > If anyone wants to comment or offer help, I'mm happy to keep trying to > track this bug(ger) down. > > cheers, > Robert > > -- > Triple-W: P.O. Box 2003. Mackay. 4740 +61-0412-079025 > robert@chalmers.com.au for Whirled Peas http://www.chalmers.com.au > Location: Whitsunday Web Works. 21'7" S, 149'14" E. > From owner-freebsd-hackers Tue Jan 28 08:40:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA23005 for hackers-outgoing; Tue, 28 Jan 1997 08:40:59 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA22999 for ; Tue, 28 Jan 1997 08:40:56 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id DAA29955; Wed, 29 Jan 1997 03:36:49 +1100 Date: Wed, 29 Jan 1997 03:36:49 +1100 From: Bruce Evans Message-Id: <199701281636.DAA29955@godzilla.zeta.org.au> To: bde@zeta.org.au, roberto@eurocontrol.fr Subject: Re: MAXMEM and userconfig Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> iosiz npx0 > >Thanks, I must have missed the commit. I guess it is only for CURRENT and >won't be available for 2.2 ? It's for 2.2 and also for -current. -current doesn't really need it, since -current gets compiled every day (else it isn't current :-), so you need to configure the memory size at compile time to avoid entering it in userconfig too often. Bruce From owner-freebsd-hackers Tue Jan 28 09:11:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24271 for hackers-outgoing; Tue, 28 Jan 1997 09:11:39 -0800 (PST) Received: from hamby1.lightside.net (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24262; Tue, 28 Jan 1997 09:11:34 -0800 (PST) Received: from localhost (jehamby@localhost) by hamby1.lightside.net (8.8.4/8.8.2) with SMTP id JAA00338; Tue, 28 Jan 1997 09:10:45 -0800 (PST) X-Authentication-Warning: hamby1.lightside.net: jehamby owned process doing -bs Date: Tue, 28 Jan 1997 09:10:44 -0800 (PST) From: Jake Hamby X-Sender: jehamby@hamby1 Reply-To: Jake Hamby To: Terry Lambert cc: hasty@rah.star-gate.com, multimedia@freebsd.org, hackers@freebsd.org Subject: Re: New Bt848 Video capture driver for FreeBSD In-Reply-To: <199701252133.OAA00739@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I strongly doubt that the person who wrote the demo used such sneaky speed-ups, since it was designed to show off the new general-purpose texture-mapping routines that will be in the 3D Kit for BeOS DR9. Besides the cube, there was a sphere, an open book, and a pulsing surface that looked like water that a pebble has been dropped into. Furthermore, the cube could be rotated by the user dragging the mouse. In general, texture mapping is straightforward enough, and a PowerPC 604 has enough horsepower to solve it in the general case, that I'm sure that's what they did. In other words, of course the hidden surfaces wouldn't be rendered, but your other suggestions sound a little wacky. Anyway, I didn't mean to bring BeOS into this, except that it's curious that you should announce a driver for a card that I first heard of in connection with the Be demo at MacWorld. I'll have to buy the card and let you know how it works. Maybe I can sneak it into work one day and try it out on the MBONE to FreeBSD Lounge, if I can find a Pentium to sneak FreeBSD onto. :) P.S. I just saw a demo of SGI's new Octane system on the MBONE. Using Alias Wavefront, they did a real-time walkthrough of a robot walking along a street with rain and streetlights! They also showed a dragon flapping its wings rendered in real-time with SoftImage, and emphasized the fact that even though they're a subsidiary of Microsoft now, it still runs best on SGI's! If only I had $25,000 (or whatever the price is after educational discount :) ... ------------------------------------------------------------------------------ |Jake Hamby| Ask me about Unix, FreeBSD, Solaris, The Tick, BeOS, or NT, eh? | ------------------------------------------------------------------------------ "This space intentionally left blank." From owner-freebsd-hackers Tue Jan 28 09:17:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24649 for hackers-outgoing; Tue, 28 Jan 1997 09:17:16 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24642 for ; Tue, 28 Jan 1997 09:17:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA08236; Tue, 28 Jan 1997 09:59:03 -0700 From: Terry Lambert Message-Id: <199701281659.JAA08236@phaeton.artisoft.com> Subject: Re: Network interfaces: removal of. To: louie@TransSys.COM (Louis A. Mamakos) Date: Tue, 28 Jan 1997 09:59:03 -0700 (MST) Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199701280402.XAA03991@whizzo.transsys.com> from "Louis A. Mamakos" at Jan 27, 97 11:02:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > While I'm sure that the modules that reference interfaces are finite, > there's nothing to allocate references to them. This would require a > level of discipline unknown to the BSD net code. Hell, you might just > as well wish for locks on the data structures to make the code SMP safe :-) Locking data is not as useful as locking context for SMP-izing them for kernel reentrancy/preemption. Specifically, if you lock data, you must place all your locks in a hierarchical graph, and then compute transitive closure over the entire graph when you go to assert any lock. If you lock, and group locks, by context (subsystem), then you only need to compute transitive closure of the region of the graph that the context is in. Further, if you use intention mode locking, you can precompute everything but the last pass of Warshall's algorithm for the intention nodes, and then compute closure almost instantaneously when an actual assert takes place. On the order of 6,000 times more locks per second than the Tuxedo system is capable of, on the same hardware, actually. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jan 28 09:25:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25192 for hackers-outgoing; Tue, 28 Jan 1997 09:25:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA25186 for ; Tue, 28 Jan 1997 09:25:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08287; Tue, 28 Jan 1997 10:07:18 -0700 From: Terry Lambert Message-Id: <199701281707.KAA08287@phaeton.artisoft.com> Subject: Re: 2.2-BETA Questions To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 28 Jan 1997 10:07:18 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org In-Reply-To: from "Simon Shapiro" at Jan 28, 97 00:00:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Yea, I figured this much, but the Linux ``gurus'' insist, theirs is the > only ``correct'' NFS server... As I said, it works (very well!) the other > way around... Is it still in user space so that each packet in and out is required to cross a protection domain in each direction, and if it contains data to be read or written, another protection domain to obtain/save the data? PS: man mount_nfs (-P), man mount (-o resvport) 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 Jan 28 09:28:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25395 for hackers-outgoing; Tue, 28 Jan 1997 09:28:01 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA25380 for ; Tue, 28 Jan 1997 09:27:56 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id LAA03626; Tue, 28 Jan 1997 11:27:49 -0600 (CST) Received: from jaguar (jaguar.vale.com [204.117.217.146]) by crocodile.vale.com (8.8.3/8.7.3) with SMTP id LAA01160; Tue, 28 Jan 1997 11:27:43 -0600 (CST) Message-ID: <32EE370F.7CDD@vailsys.com> Date: Tue, 28 Jan 1997 11:27:43 -0600 From: Hal Snyder Reply-To: hal@vailsys.com Organization: Vail Systems, Inc. X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org CC: pete@sms.fi Subject: best mtu for lo0? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While searching FreeBSD archived mail items, I found that Petri Helenius wrote: > What's your lo0 MTU? If it's the 16384 that some > non-tcp-knowledgeable person put in sometime in the past > I think what you are seeing is called "TCP deadlock" which appears when > window size is equal or smaller than the MTU. This makes TCP to be > stop-and-go protocol (remember XMODEM? or non-windowing kermit) and thus > the troughput of the protocol is pretty horrible. This happens on ATM also > if you are running with 4096 or 8192 window sizes and the RFC1577 default > MTU of 9180. > Fortunately not too many applications use the 127.0.0.1 address but use > the loopback provided by the ethernet-interface. (and thus get the MTU of > 1500) Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should this be reduced to 1500? Will it affect performance of aliased IP addresses, for which a static route through lo0 is usually specified? From owner-freebsd-hackers Tue Jan 28 09:35:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25977 for hackers-outgoing; Tue, 28 Jan 1997 09:35:15 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA25934; Tue, 28 Jan 1997 09:35:05 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vp9h3-0000Ds-00; Tue, 28 Jan 1997 01:19:05 -0800 Date: Tue, 28 Jan 1997 01:19:05 -0800 (PST) From: Tom Samplonius To: Steve cc: Robert Chalmers , bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Steve wrote: > > The only constant is the Annex. However, why does it pass _most_ traffic, > > if it is the fault of the Annex, and only fail on some.? > > > > If FreeBSD is > > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > > The world is still full of less than leading edge hardware! Some of it > > brand new... > > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. > > So good luck to you sir! FreeBSD implements T/TCP. You can disable this via by turning tcp_extensions off. SCO, Linux do not implement T/TCP, which is to their disadvantage. T/TCP gives you big wins if opening and closing a lot of TCP connections. Broken boxes like the Annex don't like T/TCP (it is broken, because if the Annex properly implemented IP/TCP, it wouldn't have a problem). Newer software releases for the Annex fix this problem. I'm not aware of any equipment that doesn't like T/TCP that couldn't be fixed with a software upgrade. Tom From owner-freebsd-hackers Tue Jan 28 09:36:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26113 for hackers-outgoing; Tue, 28 Jan 1997 09:36:20 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26108; Tue, 28 Jan 1997 09:36:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08314; Tue, 28 Jan 1997 10:18:00 -0700 From: Terry Lambert Message-Id: <199701281718.KAA08314@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: robert@nanguo.chalmers.com.au (Robert Chalmers) Date: Tue, 28 Jan 1997 10:18:00 -0700 (MST) Cc: freebsd-questions@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> from "Robert Chalmers" at Jan 28, 97 08:02:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I can connect to, and be connected to these OSs with no worries. > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > to ftp to another FBSD site that also has tcp_extensions set YES (on). > The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection > worked fine, the other end being (on). The same happened at the other end, > when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? > > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... > > If anyone wants to comment or offer help, I'mm happy to keep trying to > track this bug(ger) down. I don't understand what you are saying here; if you are saying that it works with extensions off, then it is easy to explain: o All TCP/IP implementations *must* support extension negotiation for locally unsupported extensions (they are to negotiate them "off"). Not all TCP/IP implementations are conforming. o All TCP/IP implementations *must* support data in SYN packets, even though most implementations do not generate data in SYN packets. T/TCP will generate data in SYN packets; so will the FreeBSD "finger" (man finger). Not all TCP/IP implementations are conforming. If you detect a non-conforming implementation: 1) Contact the vendor for a fix; one probably exists. 2) If no fix is available, turn extension off on the FreeBSD system, and submit a bug report to the vendor so that a fix will happen. If you think things are bad now, wait until the net begins migrating to IPv6 at the router level. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jan 28 09:46:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26627 for hackers-outgoing; Tue, 28 Jan 1997 09:46:47 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26608 for ; Tue, 28 Jan 1997 09:46:15 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.8.3/8.7.3) id TAA25913; Tue, 28 Jan 1997 19:45:36 +0200 (EET) Date: Tue, 28 Jan 1997 19:45:36 +0200 (EET) Message-Id: <199701281745.TAA25913@silver.sms.fi> From: Petri Helenius To: hal@vailsys.com Cc: hackers@freebsd.org Subject: best mtu for lo0? In-Reply-To: <32EE370F.7CDD@vailsys.com> References: <32EE370F.7CDD@vailsys.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hal Snyder writes: > While searching FreeBSD archived mail items, I found that > > Petri Helenius wrote: > > > What's your lo0 MTU? If it's the 16384 that some > > non-tcp-knowledgeable person put in sometime in the past > > I think what you are seeing is called "TCP deadlock" which appears when > > window size is equal or smaller than the MTU. This makes TCP to be > > stop-and-go protocol (remember XMODEM? or non-windowing kermit) and thus > > the troughput of the protocol is pretty horrible. This happens on ATM also > > if you are running with 4096 or 8192 window sizes and the RFC1577 default > > MTU of 9180. > > Fortunately not too many applications use the 127.0.0.1 address but use > > the loopback provided by the ethernet-interface. (and thus get the MTU of > > 1500) > > Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should > this be reduced to 1500? Will it affect performance of aliased IP > addresses, for which a static route through lo0 is usually specified? Want me to comment on this (I'm not on the hackers list any longer though)? The above still stands true that if you set your TCPWIN < MTU you'll experience TCP 'deadlock' which ends up being of horrible performance. Pete From owner-freebsd-hackers Tue Jan 28 09:48:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26789 for hackers-outgoing; Tue, 28 Jan 1997 09:48:47 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26727; Tue, 28 Jan 1997 09:48:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA01087 ; Tue, 28 Jan 1997 09:48:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08351; Tue, 28 Jan 1997 10:28:29 -0700 From: Terry Lambert Message-Id: <199701281728.KAA08351@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: shovey@buffnet.net (Steve) Date: Tue, 28 Jan 1997 10:28:28 -0700 (MST) Cc: robert@nanguo.chalmers.com.au, freebsd-questions@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Steve" at Jan 28, 97 09:03:16 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. Please notify Annex that their TCP/IP implementation is non-conforming int the area of option negotiation (the "Cherynobl packets", where if any option bits are set, all option bits get set). They are non-compliant with forwarding of SYN packets containing data, since they strip the data. They are also nominally non-compliant with extention negotiation, since they should negotiate with the host to turn extensions they do not support off (ie: RFC 1323 and RFC 1644). They also do not implement RFC 1323 or RFC 1644 (they *must* implement *all* extensions they fail to negotiate off). In short, we *claim* they are broken because they *are* broken. If you wish to be able to interoperate with faulty implementations, you can always turn off the extensions which trigger the problem with the faulty implementation. Meanwhile, it provides a nice diagnostic for detecting bad TCP/IP implementations, which will only be going to hell in a big way all at once when IPv6 gating comes online, otherwise. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jan 28 09:50:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26983 for hackers-outgoing; Tue, 28 Jan 1997 09:50:33 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26970 for ; Tue, 28 Jan 1997 09:50:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08366; Tue, 28 Jan 1997 10:32:22 -0700 From: Terry Lambert Message-Id: <199701281732.KAA08366@phaeton.artisoft.com> Subject: Re: file locking / firewalling based on uid/gid To: peter@taronga.com (Peter da Silva) Date: Tue, 28 Jan 1997 10:32:22 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199701281404.IAA04275@bonkers.taronga.com> from "Peter da Silva" at Jan 28, 97 08:04:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The only reason for disabling chown any more is for quotas, and quotas don't > work right anyway. I'd like to recommend going back to the USG semantics for > chown(). This is for giving files away to other users, right? There are a number of nasty exploits available via NFS doing this (you can get root on almost any old SGI system this way; check the CERT advisory log). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jan 28 09:53:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA27173 for hackers-outgoing; Tue, 28 Jan 1997 09:53:10 -0800 (PST) Received: from magigimmix.xs4all.nl (magigimmix.xs4all.nl [194.109.6.25]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27160 for ; Tue, 28 Jan 1997 09:53:01 -0800 (PST) Received: from asterix.xs4all.nl (asterix.xs4all.nl [194.109.6.11]) by magigimmix.xs4all.nl (8.7.6/XS4ALL) with ESMTP id SAA22412 for ; Tue, 28 Jan 1997 18:52:21 +0100 (MET) Received: from plm.xs4all.nl (uucp@localhost) by asterix.xs4all.nl (8.7.5/8.7.2) with UUCP id SAA07368 for freebsd-hackers@freebsd.org; Tue, 28 Jan 1997 18:43:10 +0100 (MET) Received: (from plm@localhost) by plm.xs4all.nl (8.8.4/8.7.3) id HAA03234; Tue, 28 Jan 1997 07:47:21 +0100 (MET) To: freebsd-hackers@freebsd.org Subject: Re: bisdn References: <87n2tuz4hf.fsf@totally-fudged-out-message-id> From: Peter Mutsaers Date: 28 Jan 1997 07:47:21 +0100 In-Reply-To: Greg Lehey's message of Mon, 27 Jan 1997 15:42:04 +0100 (MET) Message-ID: <8720b6wb2e.fsf@localhost.xs4all.nl> Lines: 12 X-Mailer: Gnus v5.2.39/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> On Mon, 27 Jan 1997 15:42:04 +0100 (MET), Greg Lehey >> said: GL> Well, to be fair, Gary Jennejohn replied and told me that this GL> related to ppp, which I don't use. I think the problem there GL> is that not many people use ppp over here, so it's not GL> surprising that it's taking a long time. Yes, that is the problem for most people. I'm surprised that you don't use PPP! Here all ISP's offer ISDN access only through syncPPP. I can't even think of another way. If you don't use PPP, then how do you get TCP/IP over ISDN? From owner-freebsd-hackers Tue Jan 28 10:00:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27607 for hackers-outgoing; Tue, 28 Jan 1997 10:00:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA27601; Tue, 28 Jan 1997 10:00:46 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08399; Tue, 28 Jan 1997 10:41:40 -0700 From: Terry Lambert Message-Id: <199701281741.KAA08399@phaeton.artisoft.com> Subject: Re: New Bt848 Video capture driver for FreeBSD To: jehamby@lightside.com Date: Tue, 28 Jan 1997 10:41:40 -0700 (MST) Cc: terry@lambert.org, hasty@rah.star-gate.com, multimedia@freebsd.org, hackers@freebsd.org In-Reply-To: from "Jake Hamby" at Jan 28, 97 09:10:44 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I strongly doubt that the person who wrote the demo used such sneaky > speed-ups, since it was designed to show off the new general-purpose > texture-mapping routines that will be in the 3D Kit for BeOS DR9. Besides > the cube, there was a sphere, an open book, and a pulsing surface that > looked like water that a pebble has been dropped into. Furthermore, the > cube could be rotated by the user dragging the mouse. In general, texture > mapping is straightforward enough, and a PowerPC 604 has enough horsepower > to solve it in the general case, that I'm sure that's what they did. > > In other words, of course the hidden surfaces wouldn't be rendered, but > your other suggestions sound a little wacky. Wacky enough to do the same sort of thing with a cube on a Commodore64... obviously, they were anim files, not Quicktime. "64K?!?! My God! How will you ever fill that up?!?". 8-). Just the knowledge that sneaky is available makes it a little less impressive on a PPC604, though. The old debate between whether you should throw fast hardware or clever software at a problem, I guess... (PS: the correct answer is "both". 8-)). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jan 28 10:05:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA28000 for hackers-outgoing; Tue, 28 Jan 1997 10:05:41 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA27995 for ; Tue, 28 Jan 1997 10:05:35 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vpAAb-0000Jh-00; Tue, 28 Jan 1997 01:49:37 -0800 Date: Tue, 28 Jan 1997 01:49:37 -0800 (PST) From: Tom Samplonius To: Joe McGuckin cc: hackers@freebsd.org Subject: Re: Ethernet bug - 2.1.6-RELEASE In-Reply-To: <199701280527.VAA23113@monk.via.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Joe McGuckin wrote: > I've noticed that if I disconnect the ethernet cable from my > de0 NIC, I no longer see the warning message about the cable > being unplugged. Also, when I plug it back in, I no longer > see the message about the UTP cable being plugged in. > > Also, once disconnected, the ethernet port no longer works and > the machine must be rebooted to restore functionality. > > joe This seems somewhat dependant on the kind of card used. A SMC Etherpower 10/UTP behaves correctly, if disconnected and reconnected. A D-Link (DE-650?) with BNC/UTP did not do this properly. Fooling about with "ifconfig de0 -linkX" did manage to get it working again. I think the problem is that some cards don't properly indicate whether a particular interface is working, or not working, to the driver, except on power-on. Tom From owner-freebsd-hackers Tue Jan 28 10:08:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA28161 for hackers-outgoing; Tue, 28 Jan 1997 10:08:17 -0800 (PST) Received: from buffnet4.buffnet.net (root@buffnet4.buffnet.net [205.246.19.13]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA28149; Tue, 28 Jan 1997 10:08:12 -0800 (PST) Received: from buffnet1.buffnet.net (mmdf@buffnet1.buffnet.net [205.246.19.10]) by buffnet4.buffnet.net (8.6.12/8.6.9) with SMTP id MAA06131; Tue, 28 Jan 1997 12:50:56 -0500 Received: from buffnet11.buffnet.net by buffnet1.buffnet.net id aa18045; 28 Jan 97 13:08 EST Date: Tue, 28 Jan 1997 13:08:44 -0500 (EST) From: Steve To: Terry Lambert cc: Robert Chalmers , freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281718.KAA08314@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 1) Contact the vendor for a fix; one probably exists. > > 2) If no fix is available, turn extension off on the FreeBSD > system, and submit a bug report to the vendor so that a > fix will happen. Turning extensions off does not stop the problem. From owner-freebsd-hackers Tue Jan 28 10:48:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA01275 for hackers-outgoing; Tue, 28 Jan 1997 10:48:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA01262; Tue, 28 Jan 1997 10:48:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08629; Tue, 28 Jan 1997 11:30:09 -0700 From: Terry Lambert Message-Id: <199701281830.LAA08629@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: shovey@buffnet.net (Steve) Date: Tue, 28 Jan 1997 11:30:09 -0700 (MST) Cc: terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Steve" at Jan 28, 97 01:08:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 1) Contact the vendor for a fix; one probably exists. > > > > 2) If no fix is available, turn extension off on the FreeBSD > > system, and submit a bug report to the vendor so that a > > fix will happen. > > Turning extensions off does not stop the problem. Does the remote system triggering the problem have extensions enabled? I believe the extensions setting in FreeBSD just changes the default state, and if a remote host negotiates them on, they will be on for that session. Are extensions off on *both* ends? If so, *exactly* what do you see happening, and for what programs? 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 Jan 28 10:54:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA01779 for hackers-outgoing; Tue, 28 Jan 1997 10:54:18 -0800 (PST) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA01774 for ; Tue, 28 Jan 1997 10:54:16 -0800 (PST) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.4/8.6.12) with SMTP id KAA13963; Tue, 28 Jan 1997 10:53:43 -0800 (PST) Date: Tue, 28 Jan 1997 10:53:43 -0800 (PST) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Dan Nelson cc: hackers@FreeBSD.ORG Subject: Re: Erroneous Ierrs from vx0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 22 Jan 1997, Dan Nelson wrote: > I've noticed that when I run 3Com's DOS config program that the card > reports 5K of receive buffers and 3K of send buffers. Is this really > all there is on the card? If so, I can understand the NFS problem, but > I can't believe a 100mbit card woud have such small buffers. A followup to this. I went twiddling around in the 3c90x config program. The option 'Network Driver Optimization' has a direct bearing on this. I set it from .. I think 'better performance' to 'normal' and the bad packets disappeared. FYI. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-hackers Tue Jan 28 11:01:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA02430 for hackers-outgoing; Tue, 28 Jan 1997 11:01:48 -0800 (PST) Received: from buffnet4.buffnet.net (root@buffnet4.buffnet.net [205.246.19.13]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA02425; Tue, 28 Jan 1997 11:01:45 -0800 (PST) Received: from buffnet1.buffnet.net (mmdf@buffnet1.buffnet.net [205.246.19.10]) by buffnet4.buffnet.net (8.6.12/8.6.9) with SMTP id NAA06657; Tue, 28 Jan 1997 13:44:28 -0500 Received: from buffnet11.buffnet.net by buffnet1.buffnet.net id aa26569; 28 Jan 97 14:02 EST Date: Tue, 28 Jan 1997 14:02:15 -0500 (EST) From: Steve To: Terry Lambert cc: robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281830.LAA08629@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Terry Lambert wrote: > > > 1) Contact the vendor for a fix; one probably exists. > > > > > > 2) If no fix is available, turn extension off on the FreeBSD > > > system, and submit a bug report to the vendor so that a > > > fix will happen. > > > > Turning extensions off does not stop the problem. > > Does the remote system triggering the problem have extensions enabled? Nope. > > Are extensions off on *both* ends? If so, *exactly* what do you > see happening, and for what programs? Yup - It was with users - only some - same problem as the other guy has.. They would connect to the news server, and not be able to pull headers - or to the web server, and get the text but not the graphics. It would stall. The bandaide I put on it was to number all freebsd boxes on class C's other than those of my annexes, forcing the packets thru my cisco. Everything cleared. From owner-freebsd-hackers Tue Jan 28 11:13:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA03152 for hackers-outgoing; Tue, 28 Jan 1997 11:13:28 -0800 (PST) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03138 for ; Tue, 28 Jan 1997 11:13:24 -0800 (PST) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.4/8.8.4) id OAA29909; Tue, 28 Jan 1997 14:13:11 -0500 (EST) From: Charles Henrich Message-Id: <199701281913.OAA29909@crh.cl.msu.edu> Subject: Re: setpwfile: Why was it removed? To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 28 Jan 1997 14:13:11 -0500 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from J Wunsch at "Jan 25, 97 05:29:33 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If you look into the CVS history and the HISTORY section, you will > notice that it has never been a part of 4.4BSD. > > Btw., which file would you pass to it? There are 4 files to mention, > pwd.db, spwd.db, master.passwd, and passwd. Give it a directory? or four arguments? -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Tue Jan 28 11:27:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA04290 for hackers-outgoing; Tue, 28 Jan 1997 11:27:11 -0800 (PST) Received: from ns.ge.com (ns.ge.com [192.35.39.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04272; Tue, 28 Jan 1997 11:27:04 -0800 (PST) Received: from thomas.ge.com (thomas.ge.com [3.47.28.21]) by ns.ge.com (8.8.4/8.7.3) with ESMTP id OAA26048; Tue, 28 Jan 1997 14:21:06 -0500 (EST) Received: from crissy.gemis.ge.com (crissy-ether.gemis.ge.com [3.29.7.204]) by thomas.ge.com (8.8.4/8.7.5) with SMTP id OAA07246; Tue, 28 Jan 1997 14:23:54 -0500 (EST) Received: from terrapin.salem.ge.com (terrapin.salem.ge.com [3.29.6.145]) by crissy.gemis.ge.com (8.6.11/8.6.11) with ESMTP id OAA08092; Tue, 28 Jan 1997 14:15:04 -0500 Received: from combs.salem.ge.com (combs.salem.ge.com [3.29.5.200]) by terrapin.salem.ge.com (8.8.3/8.8.3) with ESMTP id OAA02045; Tue, 28 Jan 1997 14:13:55 -0500 (EST) Received: from localhost (steve@localhost) by combs.salem.ge.com (8.8.3/8.8.3) with SMTP id OAA00684; Tue, 28 Jan 1997 14:13:53 -0500 (EST) Date: Tue, 28 Jan 1997 14:13:53 -0500 (EST) From: "Stephen F. Combs" To: Steve cc: Terry Lambert , Robert Chalmers , freebsd-questions@FreeBSD.org, freebsd-isp@FreeBSD.org, hackers@FreeBSD.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Then something else is wrong! I used to have to turn the tcp extensions off to connect to my annex but after upgrading to 10.1 it went away entirely! I've got about 400 users using my annex at this time, most from windoz[95-n/t], but quite a few using freebsd. works like a champ! ---- Stephen F. Combs Internet: CombsSF@Salem.GE.COM GE Industrial Systems Voice: 540.387.8828 Network Services Home: CombsSF-Home@Salem.GE.COM 1501 Roanoke Blvd FAX: 540.387.7106 Salem, VA 24153 LapTop: CombsSF-Mobile@Salem.GE.COM On Tue, 28 Jan 1997, Steve wrote: > Date: Tue, 28 Jan 1997 13:08:44 -0500 (EST) > From: Steve > To: Terry Lambert > Cc: Robert Chalmers , > freebsd-questions@FreeBSD.org, freebsd-isp@FreeBSD.org, > hackers@FreeBSD.org > Subject: Re: progress report on connection problems > > > > > 1) Contact the vendor for a fix; one probably exists. > > > > 2) If no fix is available, turn extension off on the FreeBSD > > system, and submit a bug report to the vendor so that a > > fix will happen. > > Turning extensions off does not stop the problem. > > From owner-freebsd-hackers Tue Jan 28 11:36:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA05085 for hackers-outgoing; Tue, 28 Jan 1997 11:36:36 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05080 for ; Tue, 28 Jan 1997 11:36:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id LAA16507; Tue, 28 Jan 1997 11:36:05 -0800 (PST) Message-Id: <199701281936.LAA16507@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Petri Helenius cc: hal@vailsys.com, hackers@freebsd.org Subject: Re: best mtu for lo0? In-reply-to: Your message of "Tue, 28 Jan 1997 19:45:36 +0200." <199701281745.TAA25913@silver.sms.fi> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 11:36:05 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Petri Helenius wrote: > > > > > What's your lo0 MTU? If it's the 16384 that some > > > non-tcp-knowledgeable person put in sometime in the past > > > I think what you are seeing is called "TCP deadlock" which appears when > > > window size is equal or smaller than the MTU. This makes TCP to be ... > > Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should > > this be reduced to 1500? Will it affect performance of aliased IP > > addresses, for which a static route through lo0 is usually specified? > >Want me to comment on this (I'm not on the hackers list any longer >though)? > >The above still stands true that if you set your TCPWIN < MTU you'll >experience TCP 'deadlock' which ends up being of horrible performance. Pete is likely correct that window < MTU is a problem (that's obvious, right?), but he's wrong that this is occuring in recent versions of FreeBSD. The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 12:05:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06809 for hackers-outgoing; Tue, 28 Jan 1997 12:05:20 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06800 for ; Tue, 28 Jan 1997 12:05:17 -0800 (PST) Received: from spooky.rwwa.com (rwwa.com) by mail.crl.com with SMTP id AA17652 (5.65c/IDA-1.5 for ); Tue, 28 Jan 1997 12:04:46 -0800 Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.7.5/8.7.3) with ESMTP id PAA01969 for ; Tue, 28 Jan 1997 15:02:43 -0500 (EST) Message-Id: <199701282002.PAA01969@spooky.rwwa.com> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-hackers@freebsd.org Subject: ATAPI: corrupted data? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 1997 15:02:42 -0500 From: Robert Withrow Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I didn't get anything on the newsgroup: I have a P6-200/VS440FX/2.1.5 system in which I have tried two different ATAPI CDROM drives (a Creative 8x and a toshiba 4x). I get corrupt data when I read large files (like FreeBSD distribution tarballs.) If I repeatedly mount/md5/dismount I get different MD5 checksums for large files each time. If I boot W95 and copy the file, then reboot FreeBSD, the MD5 checksums are OK. Since I have two IDE hard drives on the other channel of this system (working fine on FreeBSD) and the CDROM works on W95 I am reluctant to think the hardware is broken. I thought only the probing of ATAPI CDROM drives was broken. Is reading them (once probed) also broken, or what? ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM From owner-freebsd-hackers Tue Jan 28 12:05:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06832 for hackers-outgoing; Tue, 28 Jan 1997 12:05:25 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06825 for ; Tue, 28 Jan 1997 12:05:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA08806; Tue, 28 Jan 1997 12:46:53 -0700 From: Terry Lambert Message-Id: <199701281946.MAA08806@phaeton.artisoft.com> Subject: Re: Erroneous Ierrs from vx0 To: dwhite@resnet.uoregon.edu Date: Tue, 28 Jan 1997 12:46:53 -0700 (MST) Cc: dnelson@emsphone.com, hackers@freebsd.org In-Reply-To: from "Doug White" at Jan 28, 97 10:53:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've noticed that when I run 3Com's DOS config program that the card > > reports 5K of receive buffers and 3K of send buffers. Is this really > > all there is on the card? If so, I can understand the NFS problem, but > > I can't believe a 100mbit card woud have such small buffers. > > A followup to this. > > I went twiddling around in the 3c90x config program. The option 'Network > Driver Optimization' has a direct bearing on this. I set it from .. I > think 'better performance' to 'normal' and the bad packets disappeared. Most cards have a "server" setting, which is a bad thing to select; it's for using the cords in a NetWare server, and optimizes the buffer arrangement for the NetWare server stack utilization patterns (which are moderately pessimal, since they depends on cooperative tasking for thread switching, so can run to completion). 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 Jan 28 12:06:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06935 for hackers-outgoing; Tue, 28 Jan 1997 12:06:56 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06922; Tue, 28 Jan 1997 12:06:53 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA08815; Tue, 28 Jan 1997 12:48:39 -0700 From: Terry Lambert Message-Id: <199701281948.MAA08815@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: shovey@buffnet.net (Steve) Date: Tue, 28 Jan 1997 12:48:39 -0700 (MST) Cc: terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Steve" at Jan 28, 97 02:02:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Are extensions off on *both* ends? If so, *exactly* what do you > > see happening, and for what programs? > > Yup - It was with users - only some - same problem as the other guy has.. > They would connect to the news server, and not be able to pull headers - > or to the web server, and get the text but not the graphics. It would > stall. > > The bandaide I put on it was to number all freebsd boxes on class C's > other than those of my annexes, forcing the packets thru my cisco. > Everything cleared. And you are positive that you are using Annex software 10.1 or better, and/or none of the machines are sending data in the SYN packets? The TCP extensions do not bear on whether or not data will be sent in the SYN packet, I don't think. 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 Jan 28 12:56:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA09522 for hackers-outgoing; Tue, 28 Jan 1997 12:56:35 -0800 (PST) Received: from narcissus.ml.org (root@brosenga.st.pitzer.edu [134.173.120.201]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09506 for ; Tue, 28 Jan 1997 12:56:03 -0800 (PST) Received: (from ben@localhost) by narcissus.ml.org (8.7.5/8.7.3) id MAA27936; Tue, 28 Jan 1997 12:54:28 -0800 (PST) Date: Tue, 28 Jan 1997 12:54:28 -0800 (PST) From: Snob Art Genre To: Robert Withrow cc: freebsd-hackers@FreeBSD.org Subject: Re: ATAPI: corrupted data? In-Reply-To: <199701282002.PAA01969@spooky.rwwa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk This may be a dumb question but have you tried swapping out the IDE cable in favor of a [new | known good] one? On Tue, 28 Jan 1997, Robert Withrow wrote: > I didn't get anything on the newsgroup: > > I have a P6-200/VS440FX/2.1.5 system in which I have tried two > different ATAPI CDROM drives (a Creative 8x and a toshiba 4x). > I get corrupt data when I read large files (like FreeBSD distribution > tarballs.) If I repeatedly mount/md5/dismount I get different > MD5 checksums for large files each time. If I boot W95 and copy the > file, then reboot FreeBSD, the MD5 checksums are OK. > > Since I have two IDE hard drives on the other channel of this > system (working fine on FreeBSD) and the CDROM works on W95 I am > reluctant to think the hardware is broken. > > I thought only the probing of ATAPI CDROM drives was broken. Is > reading them (once probed) also broken, or what? > > ----------------------------------------------------------------------------- > Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM > > > Ben The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-hackers Tue Jan 28 14:11:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA14240 for hackers-outgoing; Tue, 28 Jan 1997 14:11:02 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14193; Tue, 28 Jan 1997 14:10:47 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA10781; Wed, 29 Jan 1997 09:14:51 +1100 (EST) Date: Wed, 29 Jan 1997 09:14:51 +1100 (EST) From: "Daniel O'Callaghan" To: Søren Schmidt cc: Robert Chalmers , freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: <199701281148.MAA17415@ravenock.cybercity.dk> 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 freefall.freebsd.org id OAA14200 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Søren Schmidt wrote: > In reply to Robert Chalmers who wrote: > [lots o descriptions deleted] > > I can connect to, and be connected to these OSs with no worries. > > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > > > > The only constant is the Annex. However, why does it pass _most_ traffic, > > if it is the fault of the Annex, and only fail on some.? > > Hmm, I'm seeing problems with the Annex's too if I run with tcp_extensions > enabled. Somehow the Annex's turn some of the trafic into "chernobyl" > packets (ie all lamps and bells set). This is only a problem > if the other end also supports the extensions (ie a FreeBSD box). > However all problems dissapear if I disable the extensions. > I guess the only solution is to bug the vendor to implement a > modern IP stackc... Just wondering, but would it be possible to detect these bogus packets from the Annex and revert to no-rfc1323 for the connection? And for Robert: If you read RFC 1323, you'll find that it deals with TCP sequence number wrapping on log fat pipes, so unless you have a 155 Mbps ATM connection to Melbourne, you won't need RFC 1323. After having problems like this with someone in Melbourne who could not send me mail, or read my WWW server, I have disabled RFC 1323 extensions on my main boxes so that Annex-crippled people around the world can talk to me. My 512kbps link means that there is no point to the extensions anyway I'll send you the RFC. regards, Danny From owner-freebsd-hackers Tue Jan 28 14:36:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA15548 for hackers-outgoing; Tue, 28 Jan 1997 14:36:20 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA15527; Tue, 28 Jan 1997 14:36:12 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA10906; Wed, 29 Jan 1997 09:40:22 +1100 (EST) Date: Wed, 29 Jan 1997 09:40:21 +1100 (EST) From: "Daniel O'Callaghan" To: Steve cc: Robert Chalmers , FreeBSD ISP , hackers@freebsd.org Subject: RFC 1323 default settings (was Re: progress report on connection problems) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Steve wrote: [ Robert writes about his problem with FreeBSD machines and his Annex] > > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. Well, turns out that a Linux 2.0 box also stalled on this. However, methinks it might be time to raise the issue of default settings for RFC 1323 extensions in FreeBSD boxes. Since RFC 1323 deals with long fat pipes, which very few of us have, it would make sense to turn the extensions off in the shipped /etc/sysconfig. Those people who are communicating with TCP between the two ends of a 1.5 Mbps satellite link, or an intercontinental 45 Mbps link, probably know who they are and can turn the extensions on. I know that some people in the continental USA can claim a 45 Mbps path to their favourite ftp site 4 states away, but surely those paths are used by others, reducing the 'fatness' of the pipe for RFC 1323 purposes. Local area ATM might be 'fat' but generally is not 'long' enough to cause the problems with RFC 1323 addresses. Leaving the extensions on by default causes much grief for people with old Annexes, prevents people whose ISPs use Annexes from reading FreeBSD box web pages or sending mail to FreeBSD boxes, and generates enormous amounts of traffic on the FreeBSD mailing lists. regards, Danny From owner-freebsd-hackers Tue Jan 28 14:45:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16017 for hackers-outgoing; Tue, 28 Jan 1997 14:45:14 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16007; Tue, 28 Jan 1997 14:45:07 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id JAA13081; Wed, 29 Jan 1997 09:13:32 +1030 (CST) From: Michael Smith Message-Id: <199701282243.JAA13081@genesis.atrad.adelaide.edu.au> Subject: Re: progress report on connection problems In-Reply-To: from Steve at "Jan 28, 97 01:08:44 pm" To: shovey@buffnet.net (Steve) Date: Wed, 29 Jan 1997 09:13:31 +1030 (CST) Cc: terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve stands accused of saying: > > > > 1) Contact the vendor for a fix; one probably exists. > > > > 2) If no fix is available, turn extension off on the FreeBSD > > system, and submit a bug report to the vendor so that a > > fix will happen. > > Turning extensions off does not stop the problem. Ah, but it does. It's just that other FreeBSD systems (like Yahoo) still have them turned on, so the Annex is dropping its guts regardless. As has been mentioned, the _correct_ response is to tell your provider that their Annex is _BROKEN_, and that they need to upgrade its software (which I believe is a free exercise, but you can ransack Xylogics' website for details there) preferably before you take your business elsewhere. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue Jan 28 14:45:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16117 for hackers-outgoing; Tue, 28 Jan 1997 14:45:32 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16008; Tue, 28 Jan 1997 14:45:07 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA10980; Wed, 29 Jan 1997 09:50:41 +1100 (EST) Date: Wed, 29 Jan 1997 09:50:40 +1100 (EST) From: "Daniel O'Callaghan" To: Tom Samplonius cc: bsd , FreeBSD ISP , hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Tom Samplonius wrote: > > FreeBSD implements T/TCP. You can disable this via by turning > tcp_extensions off. SCO, Linux do not implement T/TCP, which is to their > disadvantage. T/TCP gives you big wins if opening and closing a lot of > TCP connections. > > Broken boxes like the Annex don't like T/TCP (it is broken, because if > the Annex properly implemented IP/TCP, it wouldn't have a problem). Newer > software releases for the Annex fix this problem. > > I'm not aware of any equipment that doesn't like T/TCP that couldn't be > fixed with a software upgrade. We are not using T/TCP. That is RFC 1644. T/TCP may well be broken in Annexes, but it is RFC 1323 extensions which cause the current grief. regards, Danny From owner-freebsd-hackers Tue Jan 28 15:33:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA18721 for hackers-outgoing; Tue, 28 Jan 1997 15:33:18 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA18716; Tue, 28 Jan 1997 15:33:14 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA03832; Tue, 28 Jan 1997 23:51:17 +0100 From: Luigi Rizzo Message-Id: <199701282251.XAA03832@labinfo.iet.unipi.it> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 28 Jan 1997 23:51:17 +0100 (MET) Cc: shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Daniel O'Callaghan" at Jan 29, 97 09:40:02 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Since RFC 1323 deals with long fat pipes, which very few of us have, it > would make sense to turn the extensions off in the shipped /etc/sysconfig. agreed, although it is sad that such an approach practically bans any TCP extension because some broken equipment won't support it. > Those people who are communicating with TCP between the two ends of a 1.5 > Mbps satellite link, or an intercontinental 45 Mbps link, probably know > who they are and can turn the extensions on. I know that some people in not that it helps much since in many cases the application have hardwired settings for small (<64K) windows. As a matter of fact, has anyone been able to _actually_ make use of >64K windows (i.e. withouth the system changing settings under your feet) ? If yes, which version of FreeBSD ? > 'fatness' of the pipe for RFC 1323 purposes. Local area ATM might be > 'fat' but generally is not 'long' enough to cause the problems with RFC fast ethernet also peaks around 10 KB/ms, which means that going through a couple of (fast) local routers (not switches) might as well bring you close to BW*RTT > 64K Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Tue Jan 28 15:40:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19282 for hackers-outgoing; Tue, 28 Jan 1997 15:40:26 -0800 (PST) Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA19265; Tue, 28 Jan 1997 15:40:21 -0800 (PST) Received: from ww.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA17172; Tue, 28 Jan 97 17:40:19 -0600 From: jpt@msc.edu (Joseph Thomas) Received: (jpt@localhost) by ww.msc.edu (8.7.1/8.6.6) id RAA10860; Tue, 28 Jan 1997 17:40:18 -0600 (CST) Message-Id: <199701282340.RAA10860@ww.msc.edu> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 28 Jan 1997 17:40:18 -0600 (CST) Cc: shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Daniel O'Callaghan" at Jan 29, 97 09:40:21 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > On Tue, 28 Jan 1997, Steve wrote: > > [ Robert writes about his problem with FreeBSD machines and his Annex] > > > > I had similar problems using annexes as term servers with user - and have > > posted numerous times that this problem only exists with freebsd - sco, > > linux, etc doesnt have trouble - only every time I post it I get bashed > > about the head and lectured on freebsd having perfect tcp/ip and > > everything else in the world having faulty tcp/ip. > > Well, turns out that a Linux 2.0 box also stalled on this. However, > methinks it might be time to raise the issue of default settings for RFC > 1323 extensions in FreeBSD boxes. > > Since RFC 1323 deals with long fat pipes, which very few of us have, it > would make sense to turn the extensions off in the shipped /etc/sysconfig. > Those people who are communicating with TCP between the two ends of a 1.5 > Mbps satellite link, or an intercontinental 45 Mbps link, probably know > who they are and can turn the extensions on. I know that some people in > the continental USA can claim a 45 Mbps path to their favourite ftp site 4 > states away, but surely those paths are used by others, reducing the > 'fatness' of the pipe for RFC 1323 purposes. Local area ATM might be > 'fat' but generally is not 'long' enough to cause the problems with RFC > 1323 addresses. As a data point - running a local-area ATM with "out of the box" parameters (for 2.2 this looks to be 16K windows with no-scaling), I get 60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really bad discrepancy] via ftp. With larger windows (60KB), I can get in the range of 3.5-4.0 MB/s [either 'put xxx /dev/null' or 'get xxx /dev/null' so local disk access is somewhat unrelated. That is, the numbers don't vary much if I'm sending from local disk or receiving to /dev/null.] Using ttcp (tcp user application, memory to memory), I've transmitted close to 70 Mb/s, in the "local-area". I'm not sure that getting twice the throughput counts as being 'not long enough'. [I'm simply providing this as a data point for the discussion, not attempting or interested in arguing for or against either side.] > > Leaving the extensions on by default causes much grief for people with old > Annexes, prevents people whose ISPs use Annexes from reading FreeBSD box > web pages or sending mail to FreeBSD boxes, and generates enormous amounts > of traffic on the FreeBSD mailing lists. > > regards, > > Danny > -- Joseph Thomas E/Mail: jpt@msc.edu Minnesota Supercomputer Center, Inc. jpt@magic.net 1200 Washington Ave So. Tel: +1 612 337 3558 Minneapolis, MN 55415-1227 FAX: +1 612 337 3400 You cannot see what I see because you see what you see. You cannot know what I know because you know what you know. "Mostly Harmless" - Douglas Adams From owner-freebsd-hackers Tue Jan 28 15:50:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19818 for hackers-outgoing; Tue, 28 Jan 1997 15:50:38 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19806; Tue, 28 Jan 1997 15:50:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id PAA17739; Tue, 28 Jan 1997 15:48:18 -0800 (PST) Message-Id: <199701282348.PAA17739@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: shovey@buffnet.net (Steve), terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-reply-to: Your message of "Wed, 29 Jan 1997 09:13:31 +1030." <199701282243.JAA13081@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 15:48:18 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Steve stands accused of saying: >> > >> > 1) Contact the vendor for a fix; one probably exists. >> > >> > 2) If no fix is available, turn extension off on the FreeBSD >> > system, and submit a bug report to the vendor so that a >> > fix will happen. >> >> Turning extensions off does not stop the problem. > >Ah, but it does. It's just that other FreeBSD systems (like Yahoo) still >have them turned on, so the Annex is dropping its guts regardless. > >As has been mentioned, the _correct_ response is to tell your provider >that their Annex is _BROKEN_, and that they need to upgrade its >software (which I believe is a free exercise, but you can ransack >Xylogics' website for details there) preferably before you take your >business elsewhere. The traces that have been posted don't show that as being the problem. TCP extensions cause problems at connection startup and the traces are showing that a regular data packet is being dropped. One possible reason that this problem is being noticed when FreeBSD machines are involved might be due to FreeBSD's Path MTU Discovery causing the packets to be large. It seems likely to me that the Annex can't deal with large packets some or all of the time and drops the packet rather than fragmenting and/or without sending the proper ICMP message (which would break MTU discovery). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 15:58:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA20588 for hackers-outgoing; Tue, 28 Jan 1997 15:58:28 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA20573; Tue, 28 Jan 1997 15:58:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id PAA17781; Tue, 28 Jan 1997 15:54:34 -0800 (PST) Message-Id: <199701282354.PAA17781@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: shovey@buffnet.net (Steve), terry@lambert.org, robert@nanguo.chalmers.com.au, freebsd-questions@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: progress report on connection problems In-reply-to: Your message of "Wed, 29 Jan 1997 09:13:31 +1030." <199701282243.JAA13081@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 15:54:34 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Steve stands accused of saying: >> > >> > 1) Contact the vendor for a fix; one probably exists. >> > >> > 2) If no fix is available, turn extension off on the FreeBSD >> > system, and submit a bug report to the vendor so that a >> > fix will happen. >> >> Turning extensions off does not stop the problem. > >Ah, but it does. It's just that other FreeBSD systems (like Yahoo) still >have them turned on, so the Annex is dropping its guts regardless. Oh, and BTW, only one side needs to have them disabled for them to be disabled. I highly doubt that Yahoo has the extensions enabled, anyway. I certainly don't on wcarchive.cdrom.com. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 16:01:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA20980 for hackers-outgoing; Tue, 28 Jan 1997 16:01:00 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20970; Tue, 28 Jan 1997 16:00:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id QAA17825; Tue, 28 Jan 1997 16:00:13 -0800 (PST) Message-Id: <199701290000.QAA17825@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Daniel O'Callaghan" cc: Steve , Robert Chalmers , FreeBSD ISP , hackers@freebsd.org Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) In-reply-to: Your message of "Wed, 29 Jan 1997 09:40:21 +1100." From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 16:00:13 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Since RFC 1323 deals with long fat pipes, which very few of us have, it >would make sense to turn the extensions off in the shipped /etc/sysconfig. Actually, the main reason it is on is for the other half of RFC 1323 which specifies the "time stamp" extensions for better round-trip time estimates. Unfortunately, I agree with you, however, that RFC 1323 extensions should be disabled by default. The RFC 1644 extensions (T/TCP), however, should remain enabled by default. This will only break "finger", and is useful for keeping vendors TCP stacks compliant. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 16:24:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA23569 for hackers-outgoing; Tue, 28 Jan 1997 16:24:54 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA23564 for ; Tue, 28 Jan 1997 16:24:48 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id AAA23335 for ; Wed, 29 Jan 1997 00:24:45 GMT Message-Id: <199701290024.AAA23335@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: PR2347 - recursive malloc() in ppp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 00:24:45 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone interested in running the "fixed" version? It seems ok on my machine. All I've done is made the "work" happen in a call from the top level read-a-packet loop, and triggered it via a variable that's set when an alarm happens. If anyone's interested, there's a compiled copy on freefall in ~brian/src/usr.sbin/ppp Cheers -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Jan 28 16:31:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA23829 for hackers-outgoing; Tue, 28 Jan 1997 16:31:07 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA23822; Tue, 28 Jan 1997 16:31:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id QAA17983; Tue, 28 Jan 1997 16:30:11 -0800 (PST) Message-Id: <199701290030.QAA17983@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: jpt@msc.edu (Joseph Thomas) cc: danny@panda.hilink.com.au (Daniel O'Callaghan), shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) In-reply-to: Your message of "Tue, 28 Jan 1997 17:40:18 CST." <199701282340.RAA10860@ww.msc.edu> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 16:30:11 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As a data point - running a local-area ATM with "out of the box" >parameters (for 2.2 this looks to be 16K windows with no-scaling), I get >60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really Yikes, that's really awful. What kind of round-trip times are you seeing? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 16:32:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA24300 for hackers-outgoing; Tue, 28 Jan 1997 16:32:53 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA24275; Tue, 28 Jan 1997 16:32:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA09502; Tue, 28 Jan 1997 17:13:27 -0700 From: Terry Lambert Message-Id: <199701290013.RAA09502@phaeton.artisoft.com> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 28 Jan 1997 17:13:27 -0700 (MST) Cc: shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: from "Daniel O'Callaghan" at Jan 29, 97 09:40:21 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Leaving the extensions on by default causes much grief for people with old > Annexes, prevents people whose ISPs use Annexes from reading FreeBSD box > web pages or sending mail to FreeBSD boxes, and generates enormous amounts > of traffic on the FreeBSD mailing lists. You forgot "and gets Annex box owners to take advantage of the free upgrade so the problem goes away". 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 Jan 28 16:35:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA24839 for hackers-outgoing; Tue, 28 Jan 1997 16:35:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA24834; Tue, 28 Jan 1997 16:35:28 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA09514; Tue, 28 Jan 1997 17:16:05 -0700 From: Terry Lambert Message-Id: <199701290016.RAA09514@phaeton.artisoft.com> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: jpt@msc.edu (Joseph Thomas) Date: Tue, 28 Jan 1997 17:16:05 -0700 (MST) Cc: danny@panda.hilink.com.au, shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: <199701282340.RAA10860@ww.msc.edu> from "Joseph Thomas" at Jan 28, 97 05:40:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As a data point - running a local-area ATM with "out of the box" > parameters (for 2.2 this looks to be 16K windows with no-scaling), I get > 60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really > bad discrepancy] via ftp. With larger windows (60KB), I can get in the > range of 3.5-4.0 MB/s [either 'put xxx /dev/null' or 'get xxx /dev/null' > so local disk access is somewhat unrelated. That is, the numbers don't > vary much if I'm sending from local disk or receiving to /dev/null.] > > Using ttcp (tcp user application, memory to memory), I've transmitted > close to 70 Mb/s, in the "local-area". I'm not sure that getting twice > the throughput counts as being 'not long enough'. > > [I'm simply providing this as a data point for the discussion, not attempting > or interested in arguing for or against either side.] Uh, isn't 70/3.5 20 times, not 2 times? 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 Jan 28 16:46:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA25532 for hackers-outgoing; Tue, 28 Jan 1997 16:46:57 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA25522 for ; Tue, 28 Jan 1997 16:46:51 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id AAA00558 for ; Wed, 29 Jan 1997 00:46:48 GMT Message-Id: <199701290046.AAA00558@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: PR2347 - Oops - signals don't seem to interrupt the select()..... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 00:46:47 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Scrap that last message.... :( -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Jan 28 17:23:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA28108 for hackers-outgoing; Tue, 28 Jan 1997 17:23:00 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA28093 for ; Tue, 28 Jan 1997 17:22:54 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id BAA01460 for ; Wed, 29 Jan 1997 01:07:39 GMT Message-Id: <199701290107.BAA01460@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 cc: hackers@freebsd.org Subject: Re: PR2347 - Oops - signals don't seem to interrupt the select()..... In-reply-to: Your message of "Wed, 29 Jan 1997 00:46:47 GMT." <199701290046.AAA00558@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 01:07:39 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Scrap that last message.... :( > Rubbish - yes they do ! The new code in ~brian/src/usr.sbin/ppp seems to be ok now. Anyone care to test ? Thanks. I'll run it for a few days at home and see if it holds up. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Jan 28 17:35:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA29330 for hackers-outgoing; Tue, 28 Jan 1997 17:35:01 -0800 (PST) Received: from packfish.gateway.net.hk (john@packfish.gateway.net.hk [202.76.19.16]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA29270; Tue, 28 Jan 1997 17:34:45 -0800 (PST) Received: (from john@localhost) by packfish.gateway.net.hk (8.8.3/8.7.3) id JAA16436; Wed, 29 Jan 1997 09:32:36 +0800 (HKT) Date: Wed, 29 Jan 1997 09:32:36 +0800 (HKT) From: John Beukema To: Steve cc: Terry Lambert , robert@nanguo.chalmers.com.au, freebsd-questions@freebsd.org, freebsd-isp@freebsd.org, hackers@freebsd.org Subject: Re: progress report on connection problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Steve wrote: > On Tue, 28 Jan 1997, Terry Lambert wrote: > > > > > 1) Contact the vendor for a fix; one probably exists. > > > > > > > > 2) If no fix is available, turn extension off on the FreeBSD > > > > system, and submit a bug report to the vendor so that a > > > > fix will happen. > > > > > > Turning extensions off does not stop the problem. > > > > Does the remote system triggering the problem have extensions enabled? > > Nope. > > > > > Are extensions off on *both* ends? If so, *exactly* what do you > > see happening, and for what programs? > > Yup - It was with users - only some - same problem as the other guy has.. > They would connect to the news server, and not be able to pull headers - > or to the web server, and get the text but not the graphics. It would ^^^^^^ sounds like software handshaking enabled jbeukema > stall. > > The bandaide I put on it was to number all freebsd boxes on class C's > other than those of my annexes, forcing the packets thru my cisco. > Everything cleared. > > From owner-freebsd-hackers Tue Jan 28 18:20:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA01144 for hackers-outgoing; Tue, 28 Jan 1997 18:20:49 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA01139 for ; Tue, 28 Jan 1997 18:20:45 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA11106; Tue, 28 Jan 1997 18:18:47 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma011104; Tue Jan 28 18:18:24 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id SAA21188; Tue, 28 Jan 1997 18:18:24 -0800 (PST) From: Archie Cobbs Message-Id: <199701290218.SAA21188@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701251842.SAA11494@awfulhak.demon.co.uk> from Brian Somers at "Jan 25, 97 06:42:20 pm" To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Tue, 28 Jan 1997 18:18:24 -0800 (PST) Cc: hackers@freebsd.org, ari.suutari@ps.carel.fi, cmott@srv.net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Can I take it from you recent email to the hackers list that > > you solved the problem? > > Nope - as Ari Suutari wrote to me and said: > Hi, > > About two sockets - you might also need them. > My first version used also only one socket, but there > were some cases where kernel packet filtering loop > avoidance code was confused when incoming and outgoing > packets were put into same socket. The result was that > some packets were not diverted which in turn resulted > in connection failures. With separate sockets for > incoming and outgoing packets everything works fine. > > The idea in natd is that user makes modifications in > /etc/rc.firewall to set it up. The test script is only > for testing - you are not expected to use it for anything else. > (perhaps I should mention this in README file). > > Both these main programs are very much alike for obvious > reasons: all the brains is in the code written by Charles. > > Ari S. > > On investigation, he's correct. Tcp & udp return setup packets coming into > the machine with masqd running seem to disappear - masqd sees them, but when > it injects them back into the divert socket they disappear (the app never > sees them). > > This shows itself when you try to initiate a tcp/udp connection through the > divert sockets from the machine running masqd.... a timeout occurs. However, > machines that are having packets forwarded through the masqd machine are fine. > I'll have a look at the divert code and see if I can come up with anything > interresting. Under which version(s) of FreeBSD are you guys having this problem ? I'm trying to track it down... Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Tue Jan 28 18:49:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA02264 for hackers-outgoing; Tue, 28 Jan 1997 18:49:12 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA02259 for ; Tue, 28 Jan 1997 18:49:07 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id VAA04040 for ; Tue, 28 Jan 1997 21:49:02 -0500 (EST) Message-Id: <199701290249.VAA04040@spoon.beta.com> To: hackers@freebsd.org Subject: Constructive criticism (was: bashing everyone for fun and profit) Date: Tue, 28 Jan 1997 21:49:02 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry about the title. I figured it would catch some attention, although the prior part is truely what I hope this will be... constructive criticism. Its roughly 9:30pm, and I'll be heading off to bed soon, as I have to get up at 5am tomorrow, so if this sounds half witted, blame the brain thats half asleep. Now the criticism.... I've been noticing, more an more, that FreeBSD has been/is being divided in to two camps. Basically, the "has", and the "has not". What I mean by this, is that there appears to be the core team, who kick butt making this stuff all work, then the people like me, who'd like to help out where they can, but seem to have an incredible time getting started. Lets take, for instance, the case of ports. I currently have a port of an older version of xtrek running on my box here at home, albiet you can't beam armies up to your ship, but I digress... I'd like to submit it in to the "games" section of the ports. However, I notice this great little file structure that allows you to type "make install clean", and bam! the application is made, installed, and the working space is cleaned up. Pretty slick. However, the bulk of the people I've dealt with using FreeBSD (most of them newbies, albiet, but...) just don't get it. I still have a hard time (which is why I haven't bothered doing it with xtrek) finding a "cookbook" way to set these up. I suspect that if I had a more straight forward way to do one, I'd probably pump about one out per week, and would be willing to take ports on request, and see if I could hack one in to shape (allowing a relative newbie to have his widget X that hasn't already been done). The second major area of concern in my eyes is device drivers. Someone pointed me to a section of handbook that dealt with doing it (supposedly), but it was terribly out of date. Back to ground zero. I hate to say it, but I'll never write the great american device driver, because I can't get the one that returns "A quick brown fox..." when you read from it installed and working. Not because the device driver wouldn't work. Its just that, in my limited experience, it'll take me hours to figure it out - hours that I could be spending writing the great american device driver. To make matters worse, the next version might have a completely different interface. Net result? I do nothing, because I feel my efforts will be obsoleted before I stand a chance in hell of finishing. I guess what I'm driving at is that although the documentation has been getting much better lately, several critical areas are lacking (mostly the technical-weenie stuff). Now, I also realize that the people best suited to writing these documents are the ones that are hard at work actually doing the work. However, on the flip side of the coin, if one were to take a modest 25% of their development time to write this documentation, and then a person (or group of people) could then work a project, being capable of no more than 25% of the work the original person would have done, you still haven't lost anything. If you could make this person or group 50% as efficient, you're now gaining 50% development for a 25% investment in cost (net gain, 25%). I guess what I'm getting at is this: There are a lot of us out here who would write man pages if we knew how to typeset them, those who would write neat utilities if we knew how to poll the information from the kernel (hell, I know about zillion people who'd love to know how to pull IO/up-down, config statistics from their Ethernet interfaces, for instance), those who would write drivers for widget X if they knew how to get them in to the kernel (there are a million books on writing drivers, but none that I know of that speak especially about FreeBSD)... Is it possible to get a commit from the right people to do this, so I can get rid of the conversation flow that looks like: Me: I have X, and would like to do Y. Where can I find docs on it? Them: Look at handbook section X.Y.Z. Me: It doesn't work. Them: Oh, yeah. Its out of date. Me: Then where can I get recent documentation. Them: There isn't any. Try looking at . Me: From owner-freebsd-hackers Tue Jan 28 18:56:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA02464 for hackers-outgoing; Tue, 28 Jan 1997 18:56:23 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA02459; Tue, 28 Jan 1997 18:56:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id SAA18540; Tue, 28 Jan 1997 18:53:34 -0800 (PST) Message-Id: <199701290253.SAA18540@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: jpt@msc.edu (Joseph Thomas), danny@panda.hilink.com.au, shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) In-reply-to: Your message of "Tue, 28 Jan 1997 17:16:05 MST." <199701290016.RAA09514@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 18:53:34 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> As a data point - running a local-area ATM with "out of the box" >> parameters (for 2.2 this looks to be 16K windows with no-scaling), I get >> 60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really >> bad discrepancy] via ftp. With larger windows (60KB), I can get in the >> range of 3.5-4.0 MB/s [either 'put xxx /dev/null' or 'get xxx /dev/null' >> so local disk access is somewhat unrelated. That is, the numbers don't >> vary much if I'm sending from local disk or receiving to /dev/null.] >> >> Using ttcp (tcp user application, memory to memory), I've transmitted >> close to 70 Mb/s, in the "local-area". I'm not sure that getting twice >> the throughput counts as being 'not long enough'. >> >> [I'm simply providing this as a data point for the discussion, not attempting >> or interested in arguing for or against either side.] > >Uh, isn't 70/3.5 20 times, not 2 times? He's mixing bits and bytes. Pay attention to the case of the "b". -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 19:03:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA02748 for hackers-outgoing; Tue, 28 Jan 1997 19:03:04 -0800 (PST) Received: from goof.com (root@goof.com [128.173.246.47]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA02737 for ; Tue, 28 Jan 1997 19:02:57 -0800 (PST) Received: (from mmead@localhost) by goof.com (8.7.5/8.7.3) id WAA18981; Tue, 28 Jan 1997 22:02:06 -0500 (EST) From: "matthew c. mead" Message-Id: <199701290302.WAA18981@goof.com> Subject: Re: Driver for New SMC 10/100's To: jc@irbs.com (John Capo) Date: Tue, 28 Jan 1997 22:02:06 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: from "John Capo" at Jan 22, 97 09:37:26 am 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Capo writes: > Quoting matthew c. mead (mmead@goof.com): > > I saw a thread with a patch and a couple of source code > > suggestions to make the new revision of the SMC 10/100 Mbit > > ethernet cards work properly, however, I couldn't get them to > > work. Is there a known fix for 2.1.6? Thanks! > > > > ftp://ftp.irbs.com/FreeBSD/pci/if_de.c adds support for the SMC9332BDT > using a 21140A. I have not used this on a 100Mbs network. Works > fine at 10Mbs. > > John Capo > I've actually placed this in the kernel and replaced the ethernet card in the system with the SMC9332BDT I was trying to use before. It works great. Thanks again for the help! -matt -- Matthew C. Mead mmead@goof.com http://www.goof.com/~mmead/ From owner-freebsd-hackers Tue Jan 28 19:39:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA05021 for hackers-outgoing; Tue, 28 Jan 1997 19:39:40 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA05015 for ; Tue, 28 Jan 1997 19:39:34 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.3/8.7.3) with SMTP id WAA00536; Tue, 28 Jan 1997 22:39:08 -0500 (EST) Message-Id: <199701290339.WAA00536@whizzo.transsys.com> X-Mailer: exmh version 2.0alpha 12/3/96 To: dg@root.com cc: Petri Helenius , hal@vailsys.com, hackers@freebsd.org From: "Louis A. Mamakos" Subject: Re: best mtu for lo0? References: <199701281936.LAA16507@root.com> In-reply-to: Your message of "Tue, 28 Jan 1997 11:36:05 PST." <199701281936.LAA16507@root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 1997 22:39:08 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Petri Helenius wrote: > > > > > > > What's your lo0 MTU? If it's the 16384 that some > > > > non-tcp-knowledgeable person put in sometime in the past > > > > I think what you are seeing is called "TCP deadlock" which appears when > > > > window size is equal or smaller than the MTU. This makes TCP to be > ... > > > Is this correct? I notice 2.1.6-R sets MTU for lo0 to 16384. Should > > > this be reduced to 1500? Will it affect performance of aliased IP > > > addresses, for which a static route through lo0 is usually specified? > > > >Want me to comment on this (I'm not on the hackers list any longer > >though)? > > > >The above still stands true that if you set your TCPWIN < MTU you'll > >experience TCP 'deadlock' which ends up being of horrible performance. > > Pete is likely correct that window < MTU is a problem (that's obvious, > right?), but he's wrong that this is occuring in recent versions of FreeBSD. > The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. Even on other systems which don't have this optimization, what's the big harm in running stop-and-wait on the loopback interface? It's not as if there are queues in the networks which you can fill and signficant propagation delays. I don't recall exactly how the queuing is done these days and how ipintr() is invoked, but I'll bet that before the loopback output function returns, there's a software interrupt invoked to process the packet just queued up for ip_input()... louie From owner-freebsd-hackers Tue Jan 28 19:47:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA05308 for hackers-outgoing; Tue, 28 Jan 1997 19:47:41 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA05303 for ; Tue, 28 Jan 1997 19:47:38 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.8.3/8.7.3) id FAA26989; Wed, 29 Jan 1997 05:47:24 +0200 (EET) Date: Wed, 29 Jan 1997 05:47:24 +0200 (EET) Message-Id: <199701290347.FAA26989@silver.sms.fi> From: Petri Helenius To: dg@root.com Cc: hal@vailsys.com, hackers@freebsd.org Subject: Re: best mtu for lo0? In-Reply-To: <199701281936.LAA16507@root.com> References: <199701281745.TAA25913@silver.sms.fi> <199701281936.LAA16507@root.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman writes: > >Want me to comment on this (I'm not on the hackers list any longer > >though)? > > > >The above still stands true that if you set your TCPWIN < MTU you'll > >experience TCP 'deadlock' which ends up being of horrible performance. > > Pete is likely correct that window < MTU is a problem (that's obvious, > right?), but he's wrong that this is occuring in recent versions of FreeBSD. > The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. > When did this change? And doesn't the net.inet.tcp.recvspace and net.inet.tcp.sendspace variables have some doing in this anyway? Pete From owner-freebsd-hackers Tue Jan 28 20:13:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA06642 for hackers-outgoing; Tue, 28 Jan 1997 20:13:58 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA06637 for ; Tue, 28 Jan 1997 20:13:54 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.8.3/8.7.3) id GAA27096; Wed, 29 Jan 1997 06:13:49 +0200 (EET) Date: Wed, 29 Jan 1997 06:13:49 +0200 (EET) Message-Id: <199701290413.GAA27096@silver.sms.fi> From: Petri Helenius To: "Louis A. Mamakos" Cc: dg@root.com, hal@vailsys.com, hackers@freebsd.org Subject: Re: best mtu for lo0? In-Reply-To: <199701290339.WAA00536@whizzo.transsys.com> References: <199701281936.LAA16507@root.com> <199701290339.WAA00536@whizzo.transsys.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Louis A. Mamakos writes: > > > > Pete is likely correct that window < MTU is a problem (that's obvious, > > right?), but he's wrong that this is occuring in recent versions of FreeBSD. > > The send/receive windows are set to 3*MTU, and for lo0 this is 49152 bytes. > > Even on other systems which don't have this optimization, what's the big > harm in running stop-and-wait on the loopback interface? It's not as if > there are queues in the networks which you can fill and signficant > propagation delays. I don't recall exactly how the queuing is done > these days and how ipintr() is invoked, but I'll bet that before the > loopback output function returns, there's a software interrupt invoked to > process the packet just queued up for ip_input()... > You'll switch your process context between the receiving and sending process once every window. If you would be windowing, you'll doing that less often. Additionally, that gives usually better performance since you have processes to schedule if you for example have to page something in. Pete From owner-freebsd-hackers Tue Jan 28 20:16:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA06781 for hackers-outgoing; Tue, 28 Jan 1997 20:16:11 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA06716 for ; Tue, 28 Jan 1997 20:15:58 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.4/8.8.5) id PAA00739; Wed, 29 Jan 1997 15:15:34 +1100 (EST) Message-ID: <19970129151534.YC06799@usn.blaze.net.au> Date: Wed, 29 Jan 1997 15:15:34 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: Shimon@i-Connect.Net (Simon Shapiro), hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: <199701280316.NAA06348@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 In-Reply-To: <199701280316.NAA06348@genesis.atrad.adelaide.edu.au>; from Michael Smith on Jan 28, 1997 13:46:23 +1030 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith writes: > > 2. Assunming #1 is true, listen to this (Network Failure System; AKA NFS) > > scenario: > > > > * Linux NFS server, Debian 1.2, Kernel 2.0.27, etc. (nomis) with this > > in /etc/exports: > > > > /usr/src/FreeBSD sendero.i-connect.net(rw,no_root_squash) > > > > * FreeBSD 2.2-BETA client doing: > > > > # mkdir /NewStuff > > # mount -t nfs -o ro nomis;/usr/src/FreeBSD /NewStuff > > # ls -al /NewStuff > > ls: /NewStuff: Permission denied > > What are the permissions on "NewStuff" on the server? Try "ls" without > any other flags first. > > > Dunno about you but smells like a bug to me... > > It looks to me like the server is being _very_ weird. Someone else > (Doug R.?) might have a better idea about that. FWIW, I've seen this too. It occurs only when mounting a Linux ext2 filesystem on a FreeBSD system, and then only sometimes. Unfortunately that "sometimes" is *always* repeatable between any two boxes on which it occurs and there doesn't seem to be any other way around it. When I struck this, I ended up mounting the other way and doing what I had to do (backing up the Linux system prior upgrading to FreeBSD, as it turns out :-)). Two other Linux boxes (all three were running Redhat 3.0 and some 2.0.x version of the kernel) mounted just fine. The "disappearing" mount point was quite alarming at first, and I was sure I was losing my mind. I did check permissions, but it did not seem to be related at all. In all other respects, networking in general was working fine. > > 3. Made a kernel with sound, etc... Worked fine until some days ago. > > Now, all of the sudden, without me doing anything (really :-): > > > > # xmcd -debug > > .... > > Lock file: /tmp/.cdaudio/lock.f02 > > Cannot open /dev/rcd0c: errno=6 > > Is there a CD in the drive? 6 is "not configured", which xmcd should be > telling you. A list of the boot-time probe messages (output of 'dmesg') > would be handy here, as I suspect that your CD wasn't found. Or perhaps there was no CD in the drive on bootup? Just a guess. I've never seen this with my atapi nor had the described problem in switching between audio and data cds. > > 8. Education Question: What is the logic in assigning slice ID's? > > I understand c to be the entire disk > > (why `c'? Why not?) > > Why does sysinstall assign 'e', 'f', > > but (almost) never 'd'? This question is indicative of the biggest transition problems in coming from any other PC operating system to BSD. Terminology: 'slice' is the same as a "partition" in DOS/OS2 terms. 'partition' is the internal scheme BSD uses for paritioning disks. > You mean partition names. Tradition, mostly. 'a' is traditionally > used for a root filesystem, 'b' for swap, 'c' for the whole disk, and > d-h for 'other' partitions. For a while, 'd' was used by various > 386 BSD's to deal with the disparity between "the whole disk" and > "the whole part of the disk that BSD uses"; this is obsoleted by > the 'slice' paradigm. 'd' is usable as a standard partition these days. > > 9. Some safety checks in disklabel and newfs and/or kernel slice- > > partition handling could be nice. If you create an 'a' partition > > which is exactly an overlap of a 'c' in a slice that dominates > > the disk, newfs will FREEZE the system. > > Novel. I've never seen that, and I've done it many times. Nor have I. All my partitions are exactly as described - I don't use anything BUT "dd" mode partitioning since I don't run anything other than FreeBSD... It may be a problem with partioning per se, though. I've had some share of fun in getting new disks partitioned. :-) Once I realised that fdisk was unnecessary for DD disks and skipped that part, life was much easier. The core dumps when using /stand/sysinstall after the installation are definitely there though - have been for some years and I keep trying it in the vain hope that it would work. It would be nice if this could be fixed so that sysinstall could be used for partitioning and creating filesystems at any time. I'm sure it would solve many user problems as it is much easier to do it this way than have to fiddle with fdisk/disklabel no matter how educational this might be. :-) Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Tue Jan 28 20:21:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA07378 for hackers-outgoing; Tue, 28 Jan 1997 20:21:41 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA07367 for ; Tue, 28 Jan 1997 20:21:36 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.4/8.8.5) id PAA00750; Wed, 29 Jan 1997 15:21:17 +1100 (EST) Message-ID: <19970129152117.AA45867@usn.blaze.net.au> Date: Wed, 29 Jan 1997 15:21:17 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: Shimon@i-Connect.Net (Simon Shapiro), hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: <7489.854444803@time.cdrom.com> X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 In-Reply-To: <7489.854444803@time.cdrom.com>; from Jordan K. Hubbard on Jan 28, 1997 01:46:43 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > > 7. trying /stand/sysinstall from a live system dumps core either on > > (the equivalent of) fdisk or disklabel. > > Fixed in later versions. Great, at last! (fx: runs off to /usr/src/release and builds sysinstall for next time... :-)). FWIW, last time I tried (installing 2.2-BETA), fdisk did work fine, but it dumped core when writing the disklabel. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Tue Jan 28 21:32:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA10157 for hackers-outgoing; Tue, 28 Jan 1997 21:32:49 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA10140 for ; Tue, 28 Jan 1997 21:32:44 -0800 (PST) Received: (qmail 9334 invoked by uid 1000); 29 Jan 1997 01:05:19 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 28 Jan 1997 15:34:33 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: (Joerg Wunsch) Subject: Re: 2.2-BETA Questions Cc: hackers@freebsd.org, (J Wunsch) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi J Wunsch; On 28-Jan-97 you wrote: ... > 2.1.6 is the latest release. > 2.2 is the next release, currently in post-BETA. > 3.0 is the head of the development (``3.0-current'') Thanx. Iam now doubly aware of these intricacies. I am also of the understanding that all three are actively maintained. How do bug fixes cross the lines? Ah. something to learn... ... [ Linux NFS Server mess ] > That's funny. Never seen this, but i never had an occasion to test > against a Linux NFS server. The solution is to mount with the resvport option. Go figure :-) Thanx to all... ... > ENXIO. You `cd' driver seems confused. I know it is ENXIO. I know the CD driver is confused. I am too new to FreeBSD to maintain this code (which I assume has a maintainer...) > You could hook a few printf's into /sys/scsi/cd.c (inside cd_open()) > to see which of the ENXIO's hits. Either the drive claims there's no > medium inside, or it fails a READ CAPACITY command. This sounds like debugging to me... ;-) Who is the maintainer? Maybe {s{he can help? > What drive is it? wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, intr, dma, iordis The drive wooked correctly for a few days, but will refuse to mount iso9660 disks after playing music ones. Now the roles reveresed. > Of course, all this doesn't matter. ENXIO must not be confused with > any part on the device node itself. It's a plain driver message. I also understand that. It was posted in case minor/major error. > > > 4. Shutdown questions: > > > > a. When init goes to single user, prompts, asking for a shell. > > You press ENTER and it sits on ``(.???msg - Cannot exactly > > remember) not found'' > > ^C will get you a prompt, most of the time. Sometimes you get > > a fast roll talking about some malloc() failure. Sometimes a > > ^C will stop it, sometimes it will not. > > David Greenman has been the only one by now who also reported such a > behaviour. So now there is a confirmation... ... > Well, that's what the `-a' means: umount everything in fstab. Ah. BSD vs. SYSV. Sorry. But ``wolud be nice'' if shutdown would really shut down the system, and correctly too. Even Linux (Debian) now knows to do that, finally. > Btw., try `cdcontrol' to play your audio CD, and see if it does make a > difference. xmcd is a little too funny to trust it as a generic > debugging tool. They have a tendency to hack on the SCSI bus, so i > wouldn't be surprised if this leaves the driver confused if something > behaves different on your drive. Tried that. No change. Also tried cd[0-2]*. Just in case. Same thing. ... > This seems to happen only on your system, for whatever reason. I know > of several people who are running a partition that is full-size the > slice (or entire disk). As I posted before, this happens unless I use disklabel with /etc/disktab. The system will crash, but AFTER reboot the very same partition is OK. I suspect something fishy... ... > If it's assigned using the config stuff, the ISA bus driver code will > assure this. Some drivers (like syscons) don't fit right; they > use too many ports to describe in config's syntax. > > The number of ports used by this driver is returned from the driver > attach routine. Ah. But I need to write one. I just need to ``know'' that. Easy. The question was relating to a PCI controller's driver which wants to know if an IDE card is in that slot already (The card in question is a SCSI card that can ``play IDE'' if setup correctly. Thanx for your support. Simon From owner-freebsd-hackers Tue Jan 28 21:56:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA11286 for hackers-outgoing; Tue, 28 Jan 1997 21:56:57 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA11281 for ; Tue, 28 Jan 1997 21:56:55 -0800 (PST) Received: (qmail 10659 invoked by uid 1000); 29 Jan 1997 06:56:10 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701280843.JAA03366@ghpc6.ihf.rwth-aachen.de> Date: Tue, 28 Jan 1997 21:55:09 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Thomas Gellekum Subject: WAS: 2.2-BETA Questions IS: Stupidity w/o End Cc: hackers@FreeBSD.ORG, msmith@atrad.adelaide.edu.au Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Thomas Gellekum; On 28-Jan-97 you wrote: ... [ Lots of complaining about CD not playing my music as comanded deleted ] > There's nothing special. Could you post the lines from the probe > messages (see dmesg(8))? xmcd works fine with a Hitachi drive I have > here (CDR-7930, ATAPI, in case someone's interested; xmcd linked with > lesstif-0.75a). The problem was solved by `cat /etc/fstab` and actually LOOKING at what it said. /dev/wcd0c, not /dev/cd0c. My red face says it all... However, I have a host of other problems. Real, I hope... Simon From owner-freebsd-hackers Tue Jan 28 22:39:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA13382 for hackers-outgoing; Tue, 28 Jan 1997 22:39:42 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA13374 for ; Tue, 28 Jan 1997 22:39:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id WAA19406; Tue, 28 Jan 1997 22:39:10 -0800 (PST) Message-Id: <199701290639.WAA19406@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Simon Shapiro cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), hackers@freebsd.org Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Tue, 28 Jan 1997 15:34:33 PST." From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Jan 1997 22:39:10 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > 4. Shutdown questions: >> > >> > a. When init goes to single user, prompts, asking for a shell. >> > You press ENTER and it sits on ``(.???msg - Cannot exactly >> > remember) not found'' >> > ^C will get you a prompt, most of the time. Sometimes you get >> > a fast roll talking about some malloc() failure. Sometimes a >> > ^C will stop it, sometimes it will not. >> >> David Greenman has been the only one by now who also reported such a >> behaviour. > >So now there is a confirmation... Actually, no, the problem I had was when rebooting, and the symptom there is an apparantly messed up baud rate for a short while (I'm using a serial console). The problem above sounds like something more serious...and not one that I've seen. It might be an indication of a hardware problem. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jan 28 22:54:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA14407 for hackers-outgoing; Tue, 28 Jan 1997 22:54:06 -0800 (PST) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA14401 for ; Tue, 28 Jan 1997 22:54:04 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (wck-ca16-15.ix.netcom.com [207.94.231.79]) by dfw-ix8.ix.netcom.com (8.6.13/8.6.12) with ESMTP id WAA25606; Tue, 28 Jan 1997 22:53:27 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.5/8.6.9) id WAA00830; Tue, 28 Jan 1997 22:46:13 -0800 (PST) Date: Tue, 28 Jan 1997 22:46:13 -0800 (PST) Message-Id: <199701290646.WAA00830@silvia.HIP.Berkeley.EDU> To: mcgovern@spoon.beta.com CC: hackers@freebsd.org In-reply-to: <199701290249.VAA04040@spoon.beta.com> (mcgovern@spoon.beta.com) Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * Me: I have X, and would like to do Y. Where can I find docs on it? * * Them: Look at handbook section X.Y.Z. The porting section of the handbook is kept quite up-to-date. Section 18.2.5. Satoshi From owner-freebsd-hackers Tue Jan 28 23:23:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA15513 for hackers-outgoing; Tue, 28 Jan 1997 23:23:07 -0800 (PST) Received: from lassie.eunet.fi (lassie.eunet.fi [192.26.119.7]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA15500 for ; Tue, 28 Jan 1997 23:22:58 -0800 (PST) Received: from tahko.lpr.carel.fi ([192.46.69.100]) by lassie.eunet.fi with SMTP id AA09497 (5.67a/IDA-1.5 for ); Wed, 29 Jan 1997 09:22:31 +0200 Received: from mercury.ps.carel.fi by tahko.lpr.carel.fi with ESMTP (8.7.5/1.1) id JAA20105; Wed, 29 Jan 1997 09:14:20 +0200 (EET) Received: from sodium.ps.carel.fi (sodium.ps.carel.fi [194.137.216.111]) by mercury.ps.carel.fi (8.8.2/8.8.2) with SMTP id KAA11177; Wed, 29 Jan 1997 10:10:06 +0200 (EET) Received: by sodium.ps.carel.fi with Microsoft Mail id <01BC0DC7.5A8AF380@sodium.ps.carel.fi>; Wed, 29 Jan 1997 09:32:32 +0200 Message-Id: <01BC0DC7.5A8AF380@sodium.ps.carel.fi> From: Ari Suutari To: "'Archie Cobbs'" , Brian Somers Cc: "hackers@freebsd.org" , "cmott@srv.net" Subject: RE: ipdivert & masqd Date: Wed, 29 Jan 1997 09:32:31 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi everyone, I had these problems with latest 2.2-SNAP release and maybe, just maybe with 2.2-ALPHA. It was quite simple to reproduce the problem - it occurred every time I opened a TCP connection from the same machine that natd was running on. Everything works well if packets come from different interface and are routed to another. I did some investigations in the kernel land (not being any expert on that), but it seemed like the ip_divert_ignore flag was still set (from processing a outgoing packet) when an incoming packet arrived. I used tcpdump and natd (in verbose mode) at the same time initially to figure out that the problem exists. To set up a testing environment with natd, one could say something like: ipfw flush ipfw add divert 32000 ip from any to any via your-if-name ipfw add pass ip from any to any natd -i 32000 -o 32001 -a your-if-address -v The port 32001 here is a dummy - it is required by the current code in natd. However, it is quite harmess, since no packets are diverted to that port with this setup. Hope this helps, Ari S. -----Original Message----- From: Archie Cobbs [SMTP:archie@whistle.com] Sent: 29. tammikuuta 1997 4:18 To: Brian Somers Cc: hackers@freebsd.org; ari.suutari@ps.carel.fi; cmott@srv.net Subject: Re: ipdivert & masqd > On investigation, he's correct. Tcp & udp return setup packets coming into > the machine with masqd running seem to disappear - masqd sees them, but when > it injects them back into the divert socket they disappear (the app never > sees them). > > This shows itself when you try to initiate a tcp/udp connection through the > divert sockets from the machine running masqd.... a timeout occurs. However, > machines that are having packets forwarded through the masqd machine are fine. > I'll have a look at the divert code and see if I can come up with anything > interresting. Under which version(s) of FreeBSD are you guys having this problem ? I'm trying to track it down... Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 00:18:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA18413 for hackers-outgoing; Wed, 29 Jan 1997 00:18:32 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18404 for ; Wed, 29 Jan 1997 00:18:28 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id AAA13315; Wed, 29 Jan 1997 00:17:55 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma013311; Wed Jan 29 00:17:37 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id AAA22387; Wed, 29 Jan 1997 00:17:37 -0800 (PST) From: Archie Cobbs Message-Id: <199701290817.AAA22387@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <01BC0DC7.5A8AF380@sodium.ps.carel.fi> from Ari Suutari at "Jan 29, 97 09:32:31 am" To: ari.suutari@ps.carel.fi (Ari Suutari) Date: Wed, 29 Jan 1997 00:17:37 -0800 (PST) Cc: archie@whistle.com, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I had these problems with latest 2.2-SNAP release and > maybe, just maybe with 2.2-ALPHA. It was quite simple > to reproduce the problem - it occurred every time I opened > a TCP connection from the same machine that natd was > running on. Everything works well if packets come > from different interface and are routed to another. > > I did some investigations in the kernel land (not being > any expert on that), but it seemed like the ip_divert_ignore > flag was still set (from processing a outgoing packet) when > an incoming packet arrived. Can I get a quick sanity check on something... the divert code is programmed under the assumption that ip_input() and ip_output() can never sleep (ie., no other packet can be treated before the function returns). This is true, right? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 00:19:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA18483 for hackers-outgoing; Wed, 29 Jan 1997 00:19:42 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18478 for ; Wed, 29 Jan 1997 00:19:38 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id AAA11920; Wed, 29 Jan 1997 00:11:54 -0800 (PST) Message-ID: <32EF05E4.59E2B600@whistle.com> Date: Wed, 29 Jan 1997 00:10:12 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Ari Suutari CC: "'Archie Cobbs'" , Brian Somers , "hackers@freebsd.org" , "cmott@srv.net" Subject: Re: ipdivert & masqd References: <01BC0DC7.5A8AF380@sodium.ps.carel.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ari Suutari wrote: Ah a little light shines..... I wonder if it's possible that the ip_output routine might pick up an incoming packet "While it's out there"..? I'll have to think about that.. alternatively, maybe splnet's are nesting with splimp's incorrectly? unlikely.... the whole "global flag" of ip_divert_ignore is a bad idea.. it's not re-entrant at all, but unfortunatly I can't think of a way of fixing that other than adding another argument to ip_input() which I'm sure would go down like a lead balloon. > > Hi everyone, > > I had these problems with latest 2.2-SNAP release and > maybe, just maybe with 2.2-ALPHA. It was quite simple > to reproduce the problem - it occurred every time I opened > a TCP connection from the same machine that natd was > running on. Everything works well if packets come > from different interface and are routed to another. > > I did some investigations in the kernel land (not being > any expert on that), but it seemed like the ip_divert_ignore > flag was still set (from processing a outgoing packet) when > an incoming packet arrived. > > I used tcpdump and natd (in verbose mode) at the > same time initially to figure out that the problem exists. > > To set up a testing environment with natd, one could say > something like: > > ipfw flush > ipfw add divert 32000 ip from any to any via your-if-name > ipfw add pass ip from any to any > > natd -i 32000 -o 32001 -a your-if-address -v > > The port 32001 here is a dummy - it is required by the > current code in natd. However, it is quite harmess, since > no packets are diverted to that port with this setup. > > Hope this helps, > > Ari S. > > -----Original Message----- > From: Archie Cobbs [SMTP:archie@whistle.com] > Sent: 29. tammikuuta 1997 4:18 > To: Brian Somers > Cc: hackers@freebsd.org; ari.suutari@ps.carel.fi; cmott@srv.net > Subject: Re: ipdivert & masqd > > > On investigation, he's correct. Tcp & udp return setup packets coming into > > the machine with masqd running seem to disappear - masqd sees them, but when > > it injects them back into the divert socket they disappear (the app never > > sees them). > > > > This shows itself when you try to initiate a tcp/udp connection through the > > divert sockets from the machine running masqd.... a timeout occurs. However, > > machines that are having packets forwarded through the masqd machine are fine. > > I'll have a look at the divert code and see if I can come up with anything > > interresting. > > Under which version(s) of FreeBSD are you guys having this problem ? > I'm trying to track it down... > > Thanks, > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 00:35:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA19347 for hackers-outgoing; Wed, 29 Jan 1997 00:35:37 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA19341 for ; Wed, 29 Jan 1997 00:35:29 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id IAA03145; Wed, 29 Jan 1997 08:13:21 GMT Message-Id: <199701290813.IAA03145@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: hackers@freebsd.org, ari.suutari@ps.carel.fi, cmott@srv.net Subject: Re: ipdivert & masqd In-reply-to: Your message of "Tue, 28 Jan 1997 18:18:24 PST." <199701290218.SAA21188@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 08:13:20 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [.....] > > Under which version(s) of FreeBSD are you guys having this problem ? > I'm trying to track it down... > > Thanks, > -Archie I'm running 3.0-current and will test it on 2.2-961014-SNAP today. I believe Ari is running 2.2(-BETA?) and suspect that Charles is running much the same or maybe 2.1.6.... -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 00:39:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA19517 for hackers-outgoing; Wed, 29 Jan 1997 00:39:04 -0800 (PST) Received: from quasi.bis.co.il (quasi.bis.co.il [192.115.114.40]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA19511 for ; Wed, 29 Jan 1997 00:38:55 -0800 (PST) Received: from quasi.bis.co.il (localhost [127.0.0.1]) by quasi.bis.co.il (8.8.3/8.8.3) with SMTP id KAA04336; Wed, 29 Jan 1997 10:41:23 GMT Message-ID: <32EF2952.41C67EA6@bis.co.il> Date: Wed, 29 Jan 1997 10:41:22 +0000 From: Meir Dukhan Organization: Bis Software Systems Ltd X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: hackers@freebsd.org CC: mdukhan@quasi.bis.co.il Subject: Sys V IPC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Ok, I know BSD ppl may not like it, but anyway I have few questions I think some of you know the answers. Sys V ipc (at least the calls related to shared mem and messages queues) seems to _not_ be implemented as system calls. Indeed, ktrace/kdump wont records them as system calls (even if the manpage for shmat is in section 2 ;=) I experienced the following: - msgrcv() with IPC_NOWAIT return EWOULDBLOCK instead of ENOMSG (Linux and Sys V) - a process can have no more than 8 shared mem segments (how can I change this ?) Is the above the expected behaviors ? Can one confirm/infirm ? Tia Meir ps: cc to mdukhan@bis.co.il, I'm not on hackers@freebsd.org, Thanks to all in advance. From owner-freebsd-hackers Wed Jan 29 00:53:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA20060 for hackers-outgoing; Wed, 29 Jan 1997 00:53:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA20054 for ; Wed, 29 Jan 1997 00:53:08 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA21762; Wed, 29 Jan 1997 09:52:59 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA19852; Wed, 29 Jan 1997 09:46:58 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 09:46:58 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: beckmann@mail.nacamar.de (Michael Beckmann) Cc: hackers@freebsd.org Subject: Re: 2.2 sources ? References: <2.2.32.19970128143327.00b74300@mail.nacamar.de> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <2.2.32.19970128143327.00b74300@mail.nacamar.de>; from Michael Beckmann on Jan 28, 1997 15:33:27 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Michael Beckmann wrote: > I wonder where one can get the current FreeBSD 2.2 source tree. It seems > that the -current tree is FreeBSD 3.0 now. > > The reason why I ask is that I want to build a kernel from newer sources > than 2.2-BETA. I'm not familiar with cvsup's feature to get a particular CVS branch, but i think you should be able to fetch a tree from the RELENG_2_2 tag (that's the name of the beast). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Jan 29 01:21:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA21180 for hackers-outgoing; Wed, 29 Jan 1997 01:21:01 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA21175 for ; Wed, 29 Jan 1997 01:20:57 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA22267; Wed, 29 Jan 1997 10:20:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA19946; Wed, 29 Jan 1997 09:52:15 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 09:52:15 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Shimon@i-Connect.Net (Simon Shapiro) Cc: hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Jan 28, 1997 15:34:33 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > > 2.1.6 is the latest release. > > 2.2 is the next release, currently in post-BETA. > > 3.0 is the head of the development (``3.0-current'') > > Thanx. Iam now doubly aware of these intricacies. I am also of > the understanding that all three are actively maintained. How do No, 2.1.6 is a release (so it's a fixed mark, vs. a branch that is ongoing work), and the 2.1.x branch is considered dead. We had to concentrate on something. > bug fixes cross the lines? Ah. something to learn... Bug fixes are being merged from -current into the 2.2 branch. > > You could hook a few printf's into /sys/scsi/cd.c (inside cd_open()) > > to see which of the ENXIO's hits. Either the drive claims there's no > > medium inside, or it fails a READ CAPACITY command. > > This sounds like debugging to me... ;-) Who is the maintainer? I think Søren Schmidt. However, there are too many weird ATAPI drives around, so you're the best person to help here. > > > a. When init goes to single user, prompts, asking for a shell. > > > You press ENTER and it sits on ``(.???msg - Cannot exactly > > > remember) not found'' > > David Greenman has been the only one by now who also reported such a > > behaviour. > > So now there is a confirmation... The confirmation isn't the biggest problem, but rather _finding_ it. :) > > Well, that's what the `-a' means: umount everything in fstab. > > Ah. BSD vs. SYSV. Sorry. But ``wolud be nice'' if shutdown would > really shut down the system, and correctly too. Even Linux > (Debian) now knows to do that, finally. shutdown -h now -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Jan 29 01:42:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA22025 for hackers-outgoing; Wed, 29 Jan 1997 01:42:59 -0800 (PST) Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.oz.au [130.102.221.173]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA22018 for ; Wed, 29 Jan 1997 01:42:56 -0800 (PST) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.5/8.6.12) with ESMTP id TAA01388 for ; Wed, 29 Jan 1997 19:35:36 +1000 (EST) Message-Id: <199701290935.TAA01388@mailbox.uq.edu.au> X-Mailer: exmh version 2.0beta 12/23/96 To: hackers@freebsd.org Subject: Setting MTU from userland ppp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 19:35:34 +1000 From: Stephen Hocking Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How does one do this? If I try fiddling tun0 (ifconfig tun0 mtu 256) the userland ppp get quite cranky and ppp net connections hang. Stephen From owner-freebsd-hackers Wed Jan 29 03:56:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA25886 for hackers-outgoing; Wed, 29 Jan 1997 03:56:45 -0800 (PST) Received: from freenet.hamilton.on.ca (0@main.freenet.hamilton.on.ca [199.212.94.65]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA25881 for ; Wed, 29 Jan 1997 03:56:42 -0800 (PST) Received: from james.freenet.hamilton.on.ca (james.freenet.hamilton.on.ca [199.212.94.66]) by freenet.hamilton.on.ca (8.7.5/8.7.3) with ESMTP id GAA14150; Wed, 29 Jan 1997 06:57:00 -0500 (EST) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.7.5/8.7.3) with SMTP id GAA25609; Wed, 29 Jan 1997 06:58:58 -0500 (EST) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Wed, 29 Jan 1997 06:58:58 -0500 (EST) From: Tim Vanderhoek To: "Brian J. McGovern" cc: hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701290249.VAA04040@spoon.beta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997, Brian J. McGovern wrote: > I guess what I'm getting at is this: There are a lot of us out here who would > write man pages if we knew how to typeset them, those who would write neat Well, for manpages there's `man 7 mdoc' and `man 7 mdoc.samples', but personally, the next time I have to write a large manpage (ie. not very soon I plan) I'm going to try writing it in docbook and auto-converting that to manpage format. http://www.ora.com/davenport/index.html, if you're interested. -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk From owner-freebsd-hackers Wed Jan 29 04:37:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA27813 for hackers-outgoing; Wed, 29 Jan 1997 04:37:47 -0800 (PST) Received: from hda.hda.com (ip65-max1-fitch.ziplink.net [199.232.245.65]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA27792 for ; Wed, 29 Jan 1997 04:37:40 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id HAA08800 for hackers@freebsd.org; Wed, 29 Jan 1997 07:32:45 -0500 From: Peter Dufault Message-Id: <199701291232.HAA08800@hda.hda.com> Subject: PC/104 network computer To: hackers@freebsd.org Date: Wed, 29 Jan 1997 07:32:45 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (I tried hardware. Anyone on -hackers using a PC/104 single board computer?) I'm looking for a single board PC/104 computer with ethernet, flash memory, memory, serial ports, and parallel port on a single card. For ease in bootstrapping it should also have a keyboard and floppy interface. I also need a good looking small enclosure with power supply and external connectors. I'm not concerned with screaming performance or more than 16MB memory. The kind of board I have in mind is similar to the Megatel PC/II+i: http://www.emji.net:80/megatel/pc2ispec.html Can anyone recommend others? Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-hackers Wed Jan 29 06:16:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA01831 for hackers-outgoing; Wed, 29 Jan 1997 06:16:30 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA01825 for ; Wed, 29 Jan 1997 06:16:24 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id GAA01336; Wed, 29 Jan 1997 06:15:52 -0800 (PST) To: davidn@unique.usn.blaze.net.au (David Nugent) cc: msmith@atrad.adelaide.edu.au (Michael Smith), Shimon@i-Connect.Net (Simon Shapiro), hackers@freebsd.org Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Wed, 29 Jan 1997 15:15:34 +1100." <19970129151534.YC06799@usn.blaze.net.au> Date: Wed, 29 Jan 1997 06:15:51 -0800 Message-ID: <1332.854547351@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The core dumps when using /stand/sysinstall after the > installation are definitely there though - have been for some > years and I keep trying it in the vain hope that it would > work. It would be nice if this could be fixed so that Have you reproduced this in the latest SNAP? I finally got purchase authority to build the ultimate spam box from hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all in the same box. I'm going to load DOS and Win95 on different drives and try to force FreeBSD to share different combinations as well as set up the "additional" drives after installation over the next couple of days, all of which (I'm sure) will prove instructive. I've never had a system like this to test with before since I've known better than to deliberately build such a horrible combination up to now. :-) Jordan From owner-freebsd-hackers Wed Jan 29 06:58:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA03599 for hackers-outgoing; Wed, 29 Jan 1997 06:58:34 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA03594 for ; Wed, 29 Jan 1997 06:58:24 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id PAA11776; Wed, 29 Jan 1997 15:56:59 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id PAA02810; Wed, 29 Jan 1997 15:53:06 +0100 (MET) Message-Id: <3.0.32.19970129155305.00ab11a0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Jan 1997 15:53:06 +0100 To: Brian Somers From: Eivind Eklund Subject: Re: ipdivert & masqd Cc: Archie Cobbs , hackers@freebsd.org, ari.suutari@ps.carel.fi, cmott@srv.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:13 AM 1/29/97 +0000, Brian Somers wrote: >[.....] >> >> Under which version(s) of FreeBSD are you guys having this problem ? >> I'm trying to track it down... >> > >I'm running 3.0-current and will test it on 2.2-961014-SNAP today. I believe >Ari is running 2.2(-BETA?) and suspect that Charles is running much the same >or maybe 2.1.6.... Charles is running 2.1.0 (or at least he was running 2.1.0 a week ago.), and is (in his own words) "too backwards to test [natd]" BTW: Both masqd and natd need to allocate a large enough buffer to handle PORT-commands being extended. This is done without a buffer check in alias_ftp.c; the maximum size it can be extended to is "PORT 123,123,123,123,123,123\r\n" - 32 characters (including termination) - an extension of 8 characters. The packet payload area _has_ to be large enough handle this. For the IRC DCC case (which I'll hopefully bring to testing point tomorrow - any volunteers?) the expansion can be by 11 characters for each DCC hook in a PRIVMSG, totalling max (payload size)*(4/3), ie expanding to 7/3 the original size for a constructed nasty case. This has bounds-checking, though, and will not do overwrites. Still, extra buffer-space do make it work more reliably. Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Wed Jan 29 06:58:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA03629 for hackers-outgoing; Wed, 29 Jan 1997 06:58:48 -0800 (PST) Received: from quasi.bis.co.il (quasi.bis.co.il [192.115.114.40]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA03621 for ; Wed, 29 Jan 1997 06:58:42 -0800 (PST) Received: from quasi.bis.co.il (localhost [127.0.0.1]) by quasi.bis.co.il (8.8.3/8.8.3) with SMTP id RAA05762; Wed, 29 Jan 1997 17:01:00 GMT Message-ID: <32EF824C.167EB0E7@bis.co.il> Date: Wed, 29 Jan 1997 17:01:00 +0000 From: Meir Dukhan Organization: Bis Software Systems Ltd X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: Julian Elischer CC: hackers@freebsd.org, mdukhan@quasi.bis.co.il Subject: Re: Sys V IPC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks for your answer Julian, and let me ask/precise a little bit, Julian Elischer wrote: > > Meir Dukhan wrote: > > > > Hi > >` > > Ok, I know BSD ppl may not like it, but anyway I have few questions I > > think some of you know the answers. > > > > Sys V ipc (at least the calls related to shared mem and messages queues) > > seems to _not_ be implemented as system calls. > > > > Indeed, ktrace/kdump wont records them as system calls (even if the > > manpage for shmat is in section 2 ;=) > they are system calls > you need to enable them in your kernel config. > they are not compiled in to GENERIC. That's was not what I wanted to say. First my GENERIC file has the SYSVSHM, SYSVSEM, SYSVMSG options. and second I work with a kernel that has, too, these options enabled. By saying that they are not sys call, I mean that maybe they are not implemented as system calls, because ktrace doesn't record them . Another possibility is that ktrace is not aware that msgrcv/msgsnd, shmget/shmat and freinds _are_ system calls. I don't know how ktrace works, maybe it make its jobs by looking at a table of existing system calls, instead of checking if a call is actually a system call or a mere function. > > > > - a process can have no more than 8 shared mem segments > > (how can I change this ?) > > compile in a bigger number? Where can I specify this number ? Can one confirm/infirm ? Tia -- Meir ps: cc to mdukhan@bis.co.il, I'm not on hackers@freebsd.org, Thanks to all in advance. From owner-freebsd-hackers Wed Jan 29 07:11:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA04910 for hackers-outgoing; Wed, 29 Jan 1997 07:11:30 -0800 (PST) Received: from sumatra.americantv.com (sumatra.americantv.com [199.184.181.250]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA04905 for ; Wed, 29 Jan 1997 07:11:23 -0800 (PST) Received: from right.PCS (right.pcs. [148.105.10.31]) by sumatra.americantv.com (8.7.6/8.7.3) with ESMTP id JAA07636; Wed, 29 Jan 1997 09:22:22 -0600 (CST) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id PAA20519; Wed, 29 Jan 1997 15:13:50 GMT Message-ID: Date: Wed, 29 Jan 1997 09:13:50 -0600 From: jlemon@americantv.com (Jonathan Lemon) To: jkh@time.cdrom.com ("Jordan K. Hubbard") Cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions References: <19970129151534.YC06799@usn.blaze.net.au> <1332.854547351@time.cdrom.com> X-Mailer: Mutt 0.56e Mime-Version: 1.0 In-Reply-To: <1332.854547351@time.cdrom.com>; from "Jordan K. Hubbard" on Jan 29, 1997 06:15:51 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" writes: > I finally got purchase authority to build the ultimate spam box from > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > in the same box. I'm going to load DOS and Win95 on different drives Build? Just go and buy a Packard Bell computer. That should give you a pretty good start. :-) -- Jonathan From owner-freebsd-hackers Wed Jan 29 07:14:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA05109 for hackers-outgoing; Wed, 29 Jan 1997 07:14:53 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA05104 for ; Wed, 29 Jan 1997 07:14:49 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id HAA01871; Wed, 29 Jan 1997 07:14:41 -0800 (PST) To: jlemon@americantv.com (Jonathan Lemon) cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Wed, 29 Jan 1997 09:13:50 CST." Date: Wed, 29 Jan 1997 07:14:41 -0800 Message-ID: <1867.854550881@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > "Jordan K. Hubbard" writes: > > I finally got purchase authority to build the ultimate spam box from > > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > > in the same box. I'm going to load DOS and Win95 on different drives > > Build? Just go and buy a Packard Bell computer. That should give you a > pretty good start. :-) I thought of that, but I wanted something even funkier. Something which personified the very worst of every box I've seen paraded through this group. Packard Bell comes amazingly close to this in an out-of-box configuration, I'll agree, but in the end they just weren't quite Funky Enough. :-) Jordan From owner-freebsd-hackers Wed Jan 29 07:31:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA05732 for hackers-outgoing; Wed, 29 Jan 1997 07:31:59 -0800 (PST) Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA05712; Wed, 29 Jan 1997 07:31:54 -0800 (PST) Received: from ww.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA09486; Wed, 29 Jan 97 09:31:50 -0600 From: jpt@msc.edu (Joseph Thomas) Received: (jpt@localhost) by ww.msc.edu (8.7.1/8.6.6) id JAA11228; Wed, 29 Jan 1997 09:31:50 -0600 (CST) Message-Id: <199701291531.JAA11228@ww.msc.edu> Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) To: dg@root.com Date: Wed, 29 Jan 1997 09:31:49 -0600 (CST) Cc: jpt@msc.edu, danny@panda.hilink.com.au, shovey@buffnet.net, robert@nanguo.chalmers.com.au, freebsd-isp@freebsd.org, hackers@freebsd.org In-Reply-To: <199701290030.QAA17983@root.com> from "David Greenman" at Jan 28, 97 04:30:11 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > As a data point - running a local-area ATM with "out of the box" > >parameters (for 2.2 this looks to be 16K windows with no-scaling), I get > >60 KB/s out of the box vs 3.0-3.5 MB/s into the box, [notice the really > > Yikes, that's really awful. What kind of round-trip times are you seeing? > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > Transmitter: - 133 MHz Pentium, 32 MB RAM - FreeBSD 2.2-960801-SNAP - FORE PCA200E OC3c adapter - HARP ATM software (http://www.msci.magic.net) - <3C507 R1> ethernet Receiver: - SGI Challenge XL - IRIX64 6.2 03131016 - 2 150 MHZ IP19 Processors - 128 MB RAM, 2-way interleaved - FORE VMA200E OC3c adapter - FORE Systems Release: irix62_A_ForeThought_4.0.2 (1.13) - Integral Ethernet controller: et0 (IO4 card) - Initial packet (Max.) includes ARP time and call setup for ATM ATM: - both parties connected to FORE ASX-200BX - UNI 3.0 - AAL5 - LLC SNAP encapsulation - MSS 9140 (9180 MTU) With ARP and call setup: --- 198.207.143.4 ping statistics --- 101 packets transmitted, 101 packets received, 0% packet loss round-trip min/avg/max = 0.782/1.041/16.027 ms Without ARP and call setup: --- 198.207.143.4 ping statistics --- 101 packets transmitted, 101 packets received, 0% packet loss round-trip min/avg/max = 0.801/0.898/1.349 ms ETHERNET: - parties connected to different 10BaseT hubs - same subnet, no routing - MSS 1460 (1500 MTU) --- 137.66.176.4 ping statistics --- 101 packets transmitted, 101 packets received, 0% packet loss round-trip min/avg/max = 0.939/0.972/2.041 ms Now, that being said, I'm not ready to start pointing fingers at anything yet. It should be noted that using TTCP with window scaling and going to large socket buffers, I've seen 68.58 Mbits out of the machine, and 96.97 Mbits into the machine. I have not run the simple ftp test over ethernet, nor have I looked into why the ATM transmit is so slow. [We're gennerally pretty good at figuring this stuff out, we do it alot over wide-area ATM, including links with satellites.] I really need to do some more investigation of the ATM software, as well as repeat the tests using ethernet. [I should be receiving another pentium machine in the near future. I'm trying to arrange for a second ATM card, as well as some 100Mbit ethernet cards.] My point in the post was only to provide a data point that perhaps we (being the FreeBSD community) ought to think and ask more questions before taking the easy road of "turn it off." [Not that this might not be the correct answer.] It would be more work to go back later and say "opps, we solved the wrong problem and need to turn extensions back on as the default." Anyways... like I said, just a data point for consideration... -- Joseph Thomas E/Mail: jpt@msc.edu Minnesota Supercomputer Center, Inc. jpt@magic.net 1200 Washington Ave So. Tel: +1 612 337 3558 Minneapolis, MN 55415-1227 FAX: +1 612 337 3400 You cannot see what I see because you see what you see. You cannot know what I know because you know what you know. "Mostly Harmless" - Douglas Adams From owner-freebsd-hackers Wed Jan 29 07:54:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA06931 for hackers-outgoing; Wed, 29 Jan 1997 07:54:04 -0800 (PST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA06886 for ; Wed, 29 Jan 1997 07:53:58 -0800 (PST) Received: from sol1.gud.siemens.co.at (root@[10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id QAA16577 for ; Wed, 29 Jan 1997 16:54:37 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0vpcK1-000216C; Wed, 29 Jan 97 16:53 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA211803031; Wed, 29 Jan 1997 16:50:31 +0100 From: "Hr.Ladavac" Message-Id: <199701291550.AA211803031@ws2301.gud.siemens.co.at> Subject: Re: 2.2-BETA Questions To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 16:50:30 +0100 (MEZ) Cc: jlemon@americantv.com, hackers@FreeBSD.ORG In-Reply-To: <1867.854550881@time.cdrom.com> from "Jordan K. Hubbard" at Jan 29, 97 07:14:41 am 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk E-mail message from Jordan K. Hubbard contained: > > > "Jordan K. Hubbard" writes: > > > I finally got purchase authority to build the ultimate spam box from > > > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > > > in the same box. I'm going to load DOS and Win95 on different drives > > > > Build? Just go and buy a Packard Bell computer. That should give you a > > pretty good start. :-) > > I thought of that, but I wanted something even funkier. Something > which personified the very worst of every box I've seen paraded > through this group. Packard Bell comes amazingly close to this in an > out-of-box configuration, I'll agree, but in the end they just weren't > quite Funky Enough. :-) You have forgotten a floppy tape and a parallel port Zip drive. And, instead of ATAPI CD-ROM, be a sport and use an ATAPI CD Changer :) /Marino > > Jordan > From owner-freebsd-hackers Wed Jan 29 08:12:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA07847 for hackers-outgoing; Wed, 29 Jan 1997 08:12:17 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA07839 for ; Wed, 29 Jan 1997 08:12:03 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id KAA00280; Wed, 29 Jan 1997 10:10:58 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma000272; Wed Jan 29 10:10:55 1997 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id KAA22045; Wed, 29 Jan 1997 10:10:21 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.4/8.6.12) with ESMTP id KAA19636; Wed, 29 Jan 1997 10:11:21 -0600 (CST) Message-Id: <199701291611.KAA19636@jake.lodgenet.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Meir Dukhan cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: Sys V IPC In-reply-to: Your message of "Wed, 29 Jan 1997 17:01:00 GMT." <32EF824C.167EB0E7@bis.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 10:11:20 -0600 From: "Eric L. Hernes" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Meir Dukhan writes: > >That's was not what I wanted to say. First my GENERIC file has the >SYSVSHM, SYSVSEM, SYSVMSG options. and second I work with a kernel that >has, too, these options enabled. > >By saying that they are not sys call, I mean that maybe they are not >implemented as system calls, because ktrace doesn't record them . The system call is shmsys(); shmget and friends are wrapped up into this. It looks like the real syscalls are there too, but aren't used for whatever reason, binary compats maybe, just left undone maybe. at any rate look for shmsys in kdump's output. > >I don't know how ktrace works, maybe it make its jobs by looking at a >table of existing system calls, instead of checking if a call is >actually a system call or a mere function. ktrace uses the syscall slot number. kdump gets the syscall names from /usr/src/sys/kern/syscalls.c, same as the kernel. > >> > >> > - a process can have no more than 8 shared mem segments >> > (how can I change this ?) >> >> compile in a bigger number? > >Where can I specify this number ? options SHMMAXPGS=4096 options "SHMSEG=128" Although as dyson and others have noted, this is mostly an administrative limit. If you're feeling ambitious, you could probably turn them into a sysctl. >Tia > >-- Meir > >ps: cc to mdukhan@bis.co.il, I'm not on hackers@freebsd.org, Thanks to >all in advance. > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Wed Jan 29 08:44:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA08996 for hackers-outgoing; Wed, 29 Jan 1997 08:44:24 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA08984 for ; Wed, 29 Jan 1997 08:44:10 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id SAA11928; Wed, 29 Jan 1997 18:40:18 +0200 (EET) Date: Wed, 29 Jan 1997 18:40:18 +0200 (EET) From: Narvi To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-Reply-To: <1332.854547351@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Jordan K. Hubbard wrote: > > The core dumps when using /stand/sysinstall after the > > installation are definitely there though - have been for some > > years and I keep trying it in the vain hope that it would > > work. It would be nice if this could be fixed so that > > Have you reproduced this in the latest SNAP? > > I finally got purchase authority to build the ultimate spam box from > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > in the same box. I'm going to load DOS and Win95 on different drives I hope you are getting a CDROM that does not on say the package in bold print taht it works together with Win*, OS/2, Linux & Solaris. I have one and it works together in any position and combination I have tried :-) Sander > and try to force FreeBSD to share different combinations as well as > set up the "additional" drives after installation over the next couple > of days, all of which (I'm sure) will prove instructive. I've never > had a system like this to test with before since I've known better > than to deliberately build such a horrible combination up to now. :-) > > Jordan > From owner-freebsd-hackers Wed Jan 29 08:57:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA09511 for hackers-outgoing; Wed, 29 Jan 1997 08:57:17 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA09504 for ; Wed, 29 Jan 1997 08:57:12 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id RAA13513; Wed, 29 Jan 1997 17:55:52 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id RAA03315; Wed, 29 Jan 1997 17:56:37 +0100 (MET) Message-Id: <3.0.32.19970129175636.00ae0c10@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Jan 1997 17:56:37 +0100 To: Brian Somers From: Eivind Eklund Subject: Re: PR2347 - recursive malloc() in ppp Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:24 AM 1/29/97 +0000, Brian Somers wrote: >Anyone interested in running the "fixed" version? It seems ok on my machine. >All I've done is made the "work" happen in a call from the top level >read-a-packet loop, and triggered it via a variable that's set when an >alarm happens. > >If anyone's interested, there's a compiled copy on freefall in > ~brian/src/usr.sbin/ppp I was interested, and thus tried to get it from here. That seemed awfully hard without having an account on freefall - or am I being stupid here? Anonymous FTP didn't work, nor did http://freefall.freebsd.org/~brian/ A search for freefall at www.freebsd.org didn't turn up anything of interest. Is there something obvious I'm missing, or is this impossible to get at for most of us? (I'm trying to do active maintenance for PPP+pktAlias, and would really like to test/inspect this.) Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Wed Jan 29 09:11:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA09941 for hackers-outgoing; Wed, 29 Jan 1997 09:11:09 -0800 (PST) Received: from beauty.nacamar.de (petzi@beauty.nacamar.de [194.112.16.36]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA09935 for ; Wed, 29 Jan 1997 09:11:06 -0800 (PST) Received: from localhost (petzi@localhost) by beauty.nacamar.de (8.8.4/8.7.3) with SMTP id SAA04923 for ; Wed, 29 Jan 1997 18:11:02 +0100 Date: Wed, 29 Jan 1997 18:11:01 +0100 (MET) From: Michael Beckmann To: hackers@freebsd.org Subject: 2.2-BETA: options MAXMEM not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I finally singled out what the problem with my 2.2-BETA installation was. I was able to build a kernel successfully, but the kernel never booted. It panicked during the boot with the message: kmem_suballoc: bad status return of 3 I found out that it was the options "MAXMEM=(256*1024)" in the kernel config file. When I comment it out, the kernel boots fine (but only uses 64 MB RAM). The MAXMEM option used to work fine in previous kernel versions. The syntax is according to the LINT configuration. Oh well... I need that RAM. Cheers, Michael From owner-freebsd-hackers Wed Jan 29 09:19:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA10434 for hackers-outgoing; Wed, 29 Jan 1997 09:19:30 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA10427 for ; Wed, 29 Jan 1997 09:19:27 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id JAA25943; Wed, 29 Jan 1997 09:18:39 -0800 (PST) Message-Id: <199701291718.JAA25943@austin.polstra.com> To: joerg_wunsch@uriah.heep.sax.de Subject: Re: 2.2 sources ? Newsgroups: polstra.freebsd.hackers In-Reply-To: References: <2.2.32.19970128143327.00b74300@mail.nacamar.de> Organization: Polstra & Co., Seattle, WA Cc: beckmann@mail.nacamar.de (Michael Beckmann), hackers@freebsd.org Date: Wed, 29 Jan 1997 09:18:39 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I wonder where one can get the current FreeBSD 2.2 source tree. It seems > > that the -current tree is FreeBSD 3.0 now. > > > > The reason why I ask is that I want to build a kernel from newer sources > > than 2.2-BETA. > > I'm not familiar with cvsup's feature to get a particular CVS branch, > but i think you should be able to fetch a tree from the RELENG_2_2 tag > (that's the name of the beast). Yes, that will work. There's a tutorial on how to do it in the FreeBSD handbook, section 17.2, at: http://www.freebsd.org/handbook/handbook.html See especially section 17.2.3. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Wed Jan 29 09:23:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA10701 for hackers-outgoing; Wed, 29 Jan 1997 09:23:22 -0800 (PST) Received: from gateway.skipstone.com (root@GATEWAY.SKIPSTONE.COM [198.214.10.129]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA10695 for ; Wed, 29 Jan 1997 09:23:19 -0800 (PST) Received: from [204.69.236.50] (hotapplepie.skipstone.com [204.69.236.50]) by gateway.skipstone.com (8.7.4/8.6.9) with SMTP id LAA26467; Wed, 29 Jan 1997 11:20:42 -0600 Date: 29 Jan 97 11:21:25 -0600 Subject: Re: 2.2-BETA Questions From: "Richard Wackerbarth" To: "Joerg Wunsch" Cc: hackers@freebsd.org, "Simon Shapiro" X-Mailer: Cyberdog/2.0a2 MIME-Version: 1.0 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Jan 29, 1997 2:52 AM, J Wunsch wrote: >As Simon Shapiro wrote: > >> > 2.1.6 is the latest release. >> > 2.2 is the next release, currently in post-BETA. >> > 3.0 is the head of the development (``3.0-current'') >> >> Thanx. Iam now doubly aware of these intricacies. I am also of >> the understanding that all three are actively maintained. How do > >No, 2.1.6 is a release (so it's a fixed mark, vs. a branch that is >ongoing work), and the 2.1.x branch is considered dead. We had to >concentrate on something. > >> bug fixes cross the lines? Ah. something to learn... > >Bug fixes are being merged from -current into the 2.2 branch. This is not quite accurate. The 2.1 branch still exists and is not quite dead. However, the only "fixes" that get there are the most serious security fixes and an occasional correction to the install procedure that Jordan might throw in. From owner-freebsd-hackers Wed Jan 29 09:29:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA11122 for hackers-outgoing; Wed, 29 Jan 1997 09:29:23 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA11112 for ; Wed, 29 Jan 1997 09:29:20 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id JAA26014; Wed, 29 Jan 1997 09:29:16 -0800 (PST) Message-Id: <199701291729.JAA26014@austin.polstra.com> To: dg@root.com Subject: Re: RFC 1323 default settings (was Re: progress report on connection problems) Newsgroups: polstra.freebsd.hackers In-Reply-To: <199701290000.QAA17825@root.com> References: <199701290000.QAA17825@root.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Wed, 29 Jan 1997 09:29:16 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Actually, the main reason it is on is for the other half of RFC 1323 which > specifies the "time stamp" extensions for better round-trip time estimates. > Unfortunately, I agree with you, however, that RFC 1323 extensions should be > disabled by default. The RFC 1644 extensions (T/TCP), however, should remain > enabled by default. This will only break "finger", and is useful for keeping > vendors TCP stacks compliant. Are you saying that the RFC 1644 extensions have no effect unless the application explicitly elects to use them? I was hoping that would be the case, but it doesn't seem to be. I have an old Lexmark printer hanging off my ethernet. If I turn on RFC 1644 (leaving RFC 1323 turned off), the first communication to the printer kills it so dead that I have to power cycle it to bring it back to life. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Wed Jan 29 09:53:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12464 for hackers-outgoing; Wed, 29 Jan 1997 09:53:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12459 for ; Wed, 29 Jan 1997 09:53:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA12218; Wed, 29 Jan 1997 10:33:36 -0700 From: Terry Lambert Message-Id: <199701291733.KAA12218@phaeton.artisoft.com> Subject: Re: ipdivert & masqd To: archie@whistle.com (Archie Cobbs) Date: Wed, 29 Jan 1997 10:33:35 -0700 (MST) Cc: ari.suutari@ps.carel.fi, archie@whistle.com, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net In-Reply-To: <199701290817.AAA22387@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 00:17:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I did some investigations in the kernel land (not being > > any expert on that), but it seemed like the ip_divert_ignore > > flag was still set (from processing a outgoing packet) when > > an incoming packet arrived. > > Can I get a quick sanity check on something... the divert code is > programmed under the assumption that ip_input() and ip_output() > can never sleep (ie., no other packet can be treated before the > function returns). This is true, right? For the divert handler, you mean? Yes. You can build a state automaton that collects state and generates outbound data at intervals different than the inbound data, though, so long as you return immediately rather than blocking after each inbound-to-the-divert-handler data item has been processed. 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 Jan 29 10:19:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13417 for hackers-outgoing; Wed, 29 Jan 1997 10:19:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA13411 for ; Wed, 29 Jan 1997 10:19:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA12267; Wed, 29 Jan 1997 11:00:00 -0700 From: Terry Lambert Message-Id: <199701291800.LAA12267@phaeton.artisoft.com> Subject: Re: 2.2-BETA Questions To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 11:00:00 -0700 (MST) Cc: jlemon@americantv.com, hackers@FreeBSD.ORG In-Reply-To: <1867.854550881@time.cdrom.com> from "Jordan K. Hubbard" at Jan 29, 97 07:14:41 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I finally got purchase authority to build the ultimate spam box from > > > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > > > in the same box. I'm going to load DOS and Win95 on different drives > > > > Build? Just go and buy a Packard Bell computer. That should give you a > > pretty good start. :-) > > I thought of that, but I wanted something even funkier. Something > which personified the very worst of every box I've seen paraded > through this group. Packard Bell comes amazingly close to this in an > out-of-box configuration, I'll agree, but in the end they just weren't > quite Funky Enough. :-) Make sure the IDE controller does not support LBA, get a bigger than 512M IDE drive anyway, and install the OnTrack 7.x stuff to load BIOS-based translation and LBA support onto the thing. Oh yeah: get an IDE controller without the shift registers between the slot and the IDE bus, and make sure it uses a CMD640b chip. That way it can be both electrically unreliable, and lock up when you sneeze at it because of the channel interleave bugs on the CMD. Also, your master drive should be non-WD, and your slave should be WD (so that it won't even work under Win95, because WD can't make drives that will slave for other manufacturers because the IDE spec isn't strict enough). Make sure you load the "standard" ATAPI drivers from one vendor, but install the CDROM drive from another... preferrably something you buy for $17 at www.onsale.com because the drive is one of the first 1x IDE CDROMs ever manufactured. Make sure that, internally, it's wired like a Micron Home MPC (ie: the sound output from the CDROM goes through an interrupt hungry sound card that is not quite SB compatible). Definitely install a floppy tape drive, and if you can get one, use the IOMega parallel to SCSI converter as your SCSI interface. Finally, make sure you install PnP ISA cards, but that machine doesn't have a PnP BIOS, so that the OS has to make the PnP I/O calls to get them configured. Be sure the thing has an onboard bus mouse port that uses IRQ 12, and the video card outputs vertical retrace on IRQ2 so the PnP operations will stomp on these interrupts without seeing them... PS: Saturn I/Neptune I/Mercury I chipset for PCI, if possible, so that you don't get PCI DMA cache invalidation signals; too bad you can have an EISA/PCI with both a bogus Intel chipset and the HiNT chipset -- cut the traces for memory bus to slot connections for data lines 25-32, if you have to, to get the same effect. PPS: Don't forget: The Pentium you install should have the FPU bug. PPPS: If you are running an Intel motheboard, get SIMMs with gold contacts; if not, get them with lead. PPPPS: Too bad you can't install VLB bus mastering controllers in a system with PCI slots... then you could really go to hell in a handbasket, since only one of them would require the driver to invalidate the DMA target cache for it because it wasn't in a "master" slot. Actually, if you could get one of the original Gateway or Dell P60 boxes with the 1G IDE drives, you'd almost have all this. As a bonus, you'll have some nice cooling problems with the CPU. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Jan 29 10:19:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13427 for hackers-outgoing; Wed, 29 Jan 1997 10:19:37 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA13410 for ; Wed, 29 Jan 1997 10:19:32 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.4/8.7.3) id TAA21125; Wed, 29 Jan 1997 19:17:36 +0100 (MET) From: Søren Schmidt Message-Id: <199701291817.TAA21125@ravenock.cybercity.dk> Subject: Re: 2.2-BETA Questions In-Reply-To: <1867.854550881@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 29, 97 07:14:41 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 19:17:27 +0100 (MET) Cc: jlemon@americantv.com, hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who wrote: > > "Jordan K. Hubbard" writes: > > > I finally got purchase authority to build the ultimate spam box from > > > hell - two IDE HDs, an IDE CDROM drive, a SCSI HD and CDROM drive, all > > > in the same box. I'm going to load DOS and Win95 on different drives > > > > Build? Just go and buy a Packard Bell computer. That should give you a > > pretty good start. :-) > > I thought of that, but I wanted something even funkier. Something > which personified the very worst of every box I've seen paraded > through this group. Packard Bell comes amazingly close to this in an > out-of-box configuration, I'll agree, but in the end they just weren't > quite Funky Enough. :-) A couple of ideas: First see to it that the two IDE HD's are of different make, that should get you a good deal of exitement. Eg Quantum & WD or WD & Maxtor or WD & Seagate could give you some interesting funkiness, If you can get hold of a Conner drive, the make of the other doesn't matter, you'll have all the fun anyways), get a Promise or better a HongKong clone of a IDE cache controller, and then a Sanyo 3 disk ATAPI cdrom. Then a Elcheapo MAD or OPTI based soundcard, and a LPT port that only can be set at the lpt3 (0x3bc) address, together with an early Matrox MGA videocard. This should supply you all the fun you can bare for the foreseeable future... Im not to be held responsible for any harm done by you when trying to get this BOFH to work..,.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Jan 29 10:31:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13978 for hackers-outgoing; Wed, 29 Jan 1997 10:31:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA13973 for ; Wed, 29 Jan 1997 10:31:40 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA12299; Wed, 29 Jan 1997 11:12:57 -0700 From: Terry Lambert Message-Id: <199701291812.LAA12299@phaeton.artisoft.com> Subject: Re: 2.2 sources ? To: jdp@polstra.com (John Polstra) Date: Wed, 29 Jan 1997 11:12:57 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, beckmann@mail.nacamar.de, hackers@FreeBSD.ORG In-Reply-To: <199701291718.JAA25943@austin.polstra.com> from "John Polstra" at Jan 29, 97 09:18:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm not familiar with cvsup's feature to get a particular CVS branch, > > but i think you should be able to fetch a tree from the RELENG_2_2 tag > > (that's the name of the beast). > > Yes, that will work. There's a tutorial on how to do it in the FreeBSD > handbook, section 17.2, at: > > http://www.freebsd.org/handbook/handbook.html > > See especially section 17.2.3. I went through these docs the other day... I believe the WWW server is *seriously* underutilized. 1) An HTML page with a CGI-based script generator would be a big win, since the options are not really self-documenting very well. For instance, knowing where things go, and what distributions to get. 2) Another suggestion: a single DOS executable that, when run, will ask for a blank disk, format it, and copy the boot disk out of its internal data area, ask for another, and format it, and write out the second disk. This would let you click a "make BSD install disks" button in any browser that allowed ".exe" file types (ie: MS Internet Explorer 3.x) and end up with disks, without dicking around with rawrite or the other tons of excerment you have to play with now. 3) How about definining a ".sh" file type in the default mailcap for the FreeBSD install for NetScape or whatever, and setting up each port as a button which generates a .sh for the port using a CGI script... "click here to install this, click here to install that" buttons for all ports and packages. Use a CGI script to rotor, and/or have the user select, a mirror site to get packages from. etc. (other things along these lines should be obvious). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Jan 29 10:37:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA14126 for hackers-outgoing; Wed, 29 Jan 1997 10:37:06 -0800 (PST) Received: from beauty.nacamar.de (petzi@beauty.nacamar.de [194.112.16.36]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA14116 for ; Wed, 29 Jan 1997 10:37:03 -0800 (PST) Received: from localhost (petzi@localhost) by beauty.nacamar.de (8.8.4/8.7.3) with SMTP id TAA06574 for ; Wed, 29 Jan 1997 19:36:59 +0100 Date: Wed, 29 Jan 1997 19:36:58 +0100 (MET) From: Michael Beckmann To: hackers@freebsd.org Subject: 2.2-BETA: options MAXMEM not working (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk OK, after having built a couple more kernels, I found out that the MAXMEM option does not work for me when set to over 128 MB. I now run a kernel that uses only 128 MB, though my machine has 192 MB and will have 256 at the end of the week. Has this problem been fixed in kernels subsequent to 2.2-BETA ? I was using 160 MB just fine with FreeBSD 2.1.5. Cheers, Michael From owner-freebsd-hackers Wed Jan 29 11:10:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA15725 for hackers-outgoing; Wed, 29 Jan 1997 11:10:46 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA15720 for ; Wed, 29 Jan 1997 11:10:41 -0800 (PST) Received: (qmail 3901 invoked by uid 1000); 29 Jan 1997 20:09:59 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 29 Jan 1997 11:13:14 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: hackers@freebsd.org Subject: More 2.2-BETA goodies... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ I am cross-posting this to scsi as well, as some of the issues here are SCSI related and I am not sure that readership is overlapping... ] Hi Y'all, Since we are all bored with nothing better to do I decided to burden this nice quorum with some more good ways to use 2.2-BETA. Maybe you can clarify some of them for me: 1. An easy way to panic the system: * Put ``devfs /devs devfs rw 0 0'' in /etc/fstab * Do ``mount -a'' * Do ``mount -a'' (again) * Do ``df'' - You will see /devs mounted twice. Actually you will see /kern and /dev twice if you setup kernfs and/or fdesc. * do ``umount /devs'' You will get a nice little panic with a complaint about dangling inodes. 2. Not a show stopper. More of a question. Under HEAVY disk I/O, with an AHA-2940W, you see all keyboard, mouse, modem activity freeze for few seconds and then resume. I suspected SCSI timeouts, but saw no kernel or driver complaints. It appears as if the system stops processing interrupts for a while. Quiet SCSI timeout (no error messages)? 3. Back to the Iomega Jaz: If it spins down (it likes to do that), and then you try to access it (say mount a file system), you get dropped the kernel debugger (``db>''), with ``.. sd... no slices...'' error message. Now, if you are lucky, you were not in X11, and can see the ``db>'' on the screen. All you need to do is type ``c'' once and all will be well. If you do it too quickly, you will repeat the event. Is this problem: a. The aic7xxx driver timing out too soon b. The SCSI code above the driver deciding to timeout too soon c. Iomega not building hardware to FreeBSD specs :-) If, on the other hand, you were in an X11 session, you are hosed. I think the kernel debugger stops interrupts at this point. What is the way to get at the debugger at this point. Aside from doing the proper thing, which is to configure a serial console, etc. 4. Pppd drops the connection, without warning, under very heavy load. 5. Question: Using xperfmon++ (cool), one observes that a system equipped with AHA2940W enjoys about 3-15 times as many interrupts/sec as disk transfers/sec. The system, does nothing but SCSI right now (cvs checkout in parallel with a tape backup (cpio, I know...). Nothing else. Assumin the #9 S3 card generates no interrupts, keeping my hands off the keyboard and mouse, no Ethernet traffic, no PPP traffic; The system does a peak of 246 disk T/s and about 625 interrupts/sec. Discounting 100 interrupts for the heartbeat, We still have two interrupts per sec charged to the disk I/O. Under HEAVY load, the numbers climb logarithmically; Up to 300 T/s with over 2,500 I/s. Heavy disk load in this note means 8``st'' threads in parallel. So that xperfmon++ will say 300+ T/s, which seems to be the maximum the AHA2940 can sustain. Ts is a Seek Test program we use to excite disks and stress them at the same time. It generates a random (or sequential) stream of I/O requests to a file/device and then measures how it does. It can either read or write, or read-modify-write and do a whole set of nifty things. If there is interest, I can post it. It runs on Slowlaris 2.5.1, linux 2.x and FreeBSD 9of courcse). We prefer it to others because it does true random seeks, very accurate and I wrote it, so it must be good :-). It is also short! Simon From owner-freebsd-hackers Wed Jan 29 11:13:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA15937 for hackers-outgoing; Wed, 29 Jan 1997 11:13:24 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA15929 for ; Wed, 29 Jan 1997 11:13:22 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id LAA00697; Wed, 29 Jan 1997 11:12:20 -0800 (PST) To: Narvi cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Wed, 29 Jan 1997 18:40:18 +0200." Date: Wed, 29 Jan 1997 11:12:20 -0800 Message-ID: <693.854565140@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I hope you are getting a CDROM that does not on say the package in bold > print taht it works together with Win*, OS/2, Linux & Solaris. I have one > and it works together in any position and combination I have tried :-) I got the evil "Sound blaster discovery pack" bundle that you see so many Earnest Young Couples stuffing in their minivans over at costco. I figure it's a pretty safe bet that it will: a) Not work. b) Be a frequently reported Not-working-item. :-) From owner-freebsd-hackers Wed Jan 29 11:25:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA16690 for hackers-outgoing; Wed, 29 Jan 1997 11:25:15 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA16683 for ; Wed, 29 Jan 1997 11:25:13 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA17413; Wed, 29 Jan 1997 11:24:39 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma017409; Wed Jan 29 11:24:32 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id LAA24150; Wed, 29 Jan 1997 11:24:32 -0800 (PST) From: Archie Cobbs Message-Id: <199701291924.LAA24150@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701291733.KAA12218@phaeton.artisoft.com> from Terry Lambert at "Jan 29, 97 10:33:35 am" To: terry@lambert.org (Terry Lambert) Date: Wed, 29 Jan 1997 11:24:32 -0800 (PST) Cc: archie@whistle.com, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I did some investigations in the kernel land (not being > > > any expert on that), but it seemed like the ip_divert_ignore > > > flag was still set (from processing a outgoing packet) when > > > an incoming packet arrived. > > > > Can I get a quick sanity check on something... the divert code is > > programmed under the assumption that ip_input() and ip_output() > > can never sleep (ie., no other packet can be treated before the > > function returns). This is true, right? > > For the divert handler, you mean? Yes. Then I don't understand how ip_divert_ignore can ever be incorrectly set (ie., non-zero)... if you look at ip_divert.c, you see the only place that it is ever set to a non-zero value is before the outgoing packet is delivered, via a call to ether ip_input() or ip_output() (in the function div_output()). Then it gets reset to zero after either of these functions returns. Am I missing some subtlety in there? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 12:06:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18309 for hackers-outgoing; Wed, 29 Jan 1997 12:06:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA18302 for ; Wed, 29 Jan 1997 12:06:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA12629; Wed, 29 Jan 1997 12:47:25 -0700 From: Terry Lambert Message-Id: <199701291947.MAA12629@phaeton.artisoft.com> Subject: Re: ipdivert & masqd To: archie@whistle.com (Archie Cobbs) Date: Wed, 29 Jan 1997 12:47:25 -0700 (MST) Cc: terry@lambert.org, archie@whistle.com, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net In-Reply-To: <199701291924.LAA24150@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 11:24:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Can I get a quick sanity check on something... the divert code is > > > programmed under the assumption that ip_input() and ip_output() > > > can never sleep (ie., no other packet can be treated before the > > > function returns). This is true, right? > > > > For the divert handler, you mean? Yes. > > Then I don't understand how ip_divert_ignore can ever be incorrectly > set (ie., non-zero)... if you look at ip_divert.c, you see the only > place that it is ever set to a non-zero value is before the outgoing > packet is delivered, via a call to ether ip_input() or ip_output() > (in the function div_output()). Then it gets reset to zero after > either of these functions returns. > > Am I missing some subtlety in there? ...I ....I ...I don't know *that*! *sproing* Yeeeeeaaaaarrrrrrggggggghhhhhhhhh! Actually, I think it's so the outbound packet doesn't get redivirted by that particular handler, but you *can* chain handlers. For instance, say I wanted to chain a cleanwall, a firewall, and a IP proxy server and they were all in seperate divert modules. 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 Jan 29 12:11:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18534 for hackers-outgoing; Wed, 29 Jan 1997 12:11:34 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA18524 for ; Wed, 29 Jan 1997 12:11:29 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vpYbr-0004t7-00; Wed, 29 Jan 1997 03:55:23 -0800 Date: Wed, 29 Jan 1997 03:55:23 -0800 (PST) From: Tom Samplonius To: Simon Shapiro cc: hackers@freebsd.org Subject: Re: More 2.2-BETA goodies... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Simon Shapiro wrote: ... > If there is interest, I can post it. It runs on Slowlaris 2.5.1, linux 2.x > and FreeBSD 9of courcse). We prefer it to others because it does true ... I'm interested. I've been looking for something to test transactional limits of SCSI controllers and drives. Problems with tagged command queuing, etc don't show up until you have a very high number of transactions per second. On an other note, have you tried turning AHC_TAGENABLE and/or AHC_SCBPAGING_ENABLE on? AHC_TAGENABLE is pretty reliable if your drives support it. SCSPAGING needs some work yet, I think. Tom From owner-freebsd-hackers Wed Jan 29 12:17:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18935 for hackers-outgoing; Wed, 29 Jan 1997 12:17:51 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA18926 for ; Wed, 29 Jan 1997 12:17:47 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA17869; Wed, 29 Jan 1997 12:17:10 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma017867; Wed Jan 29 12:16:42 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id MAA24360; Wed, 29 Jan 1997 12:16:42 -0800 (PST) From: Archie Cobbs Message-Id: <199701292016.MAA24360@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701291947.MAA12629@phaeton.artisoft.com> from Terry Lambert at "Jan 29, 97 12:47:25 pm" To: terry@lambert.org (Terry Lambert) Date: Wed, 29 Jan 1997 12:16:41 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > Can I get a quick sanity check on something... the divert code is > > > > programmed under the assumption that ip_input() and ip_output() > > > > can never sleep (ie., no other packet can be treated before the > > > > function returns). This is true, right? > > > > > > For the divert handler, you mean? Yes. > > > > Then I don't understand how ip_divert_ignore can ever be incorrectly > > set (ie., non-zero)... if you look at ip_divert.c, you see the only > > place that it is ever set to a non-zero value is before the outgoing > > packet is delivered, via a call to ether ip_input() or ip_output() > > (in the function div_output()). Then it gets reset to zero after > > either of these functions returns. > > > > Am I missing some subtlety in there? > > [ ... ] > > Actually, I think it's so the outbound packet doesn't get redivirted > by that particular handler, but you *can* chain handlers. For instance, > say I wanted to chain a cleanwall, a firewall, and a IP proxy server > and they were all in seperate divert modules. Right! That is the purpose of this ip_divert_ignore hack -- for loop avoidance. It allows you to send a packet back out via the divert socket and simultaneously say "Don't divert *this* packet back into *this* socket". The theory was that this loop avoidance was working too well, and seemed to be applying to packets other than the one that it was supposed to. What I'm trying to prove to myself is that this can't be happening. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 12:38:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA19791 for hackers-outgoing; Wed, 29 Jan 1997 12:38:49 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA19786 for ; Wed, 29 Jan 1997 12:38:44 -0800 (PST) Message-Id: <199701292038.MAA19786@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA210270266; Thu, 30 Jan 1997 07:37:46 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: eivind@dimaga.com (Eivind Eklund) Date: Thu, 30 Jan 1997 07:37:46 +1100 (EDT) Cc: brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi, cmott@srv.net In-Reply-To: <3.0.32.19970129155305.00ab11a0@dimaga.com> from "Eivind Eklund" at Jan 29, 97 03:53:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Eivind Eklund, sie said: > > For the IRC DCC case (which I'll hopefully bring to testing point tomorrow > - any volunteers?) the expansion can be by 11 characters for each DCC hook > in a PRIVMSG, totalling max (payload size)*(4/3), ie expanding to 7/3 the > original size for a constructed nasty case. This has bounds-checking, > though, and will not do overwrites. Still, extra buffer-space do make it > work more reliably. But anything after the 512th data byte in the TCP payload will be ignored, so if your message is 512 bytes long, contains a DCC request in it, information will be lost that the sender is not aware about (this assumes the packet is just one IRC message) if the payload size must increase as a result. It is a *much* better idea to redirect IRC to a local TCP port and process it using a proxy agent. Same could also be said for FTP. Darren From owner-freebsd-hackers Wed Jan 29 12:46:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20184 for hackers-outgoing; Wed, 29 Jan 1997 12:46:57 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA20166 for ; Wed, 29 Jan 1997 12:46:54 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id VAA16478; Wed, 29 Jan 1997 21:39:44 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id UAA04642; Wed, 29 Jan 1997 20:47:09 +0100 (MET) Message-Id: <3.0.32.19970129204709.00afdec0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Jan 1997 20:47:10 +0100 To: Terry Lambert From: Eivind Eklund Subject: Re: 2.2 sources ? Cc: jdp@polstra.com (John Polstra), joerg_wunsch@uriah.heep.sax.de, beckmann@mail.nacamar.de, hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 11:12 AM 1/29/97 -0700, Terry Lambert wrote: >2) >Another suggestion: a single DOS executable that, when run, will ask >for a blank disk, format it, and copy the boot disk out of its internal >data area, ask for another, and format it, and write out the second disk. > >This would let you click a "make BSD install disks" button in any >browser that allowed ".exe" file types (ie: MS Internet Explorer 3.x) >and end up with disks, without dicking around with rawrite or the >other tons of excerment you have to play with now. I don't believe it is possible to do access the raw disks from Win95 or WinNT; at least, it is not possible from a DOS executable. It *might* be possible from a WinNT executable (which will also run under Win95). However, my resident Win95/NT expert didn't know how. >3) >How about definining a ".sh" file type in the default mailcap for >the FreeBSD install for NetScape or whatever, and setting up each >port as a button which generates a .sh for the port using a CGI >script... "click here to install this, click here to install that" >buttons for all ports and packages. Use a CGI script to rotor, and/or >have the user select, a mirror site to get packages from. I still don't like the concept of having the user *automatically* run anything downloaded. I don't think setting ut the mailcap to do so is a good idea, to put it mildly. (It almost give me enough paranoia to make me want to switch to another OS; it is a large part of the reason I don't run IE, _ever_.) Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Wed Jan 29 12:52:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20501 for hackers-outgoing; Wed, 29 Jan 1997 12:52:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA20494 for ; Wed, 29 Jan 1997 12:52:03 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA03897; Wed, 29 Jan 1997 21:51:17 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id UAA21205; Wed, 29 Jan 1997 20:51:37 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 20:51:37 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: eivind@dimaga.com (Eivind Eklund) Cc: brian@awfulhak.demon.co.uk (Brian Somers), hackers@freebsd.org Subject: Re: PR2347 - recursive malloc() in ppp References: <3.0.32.19970129175636.00ae0c10@dimaga.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <3.0.32.19970129175636.00ae0c10@dimaga.com>; from Eivind Eklund on Jan 29, 1997 17:56:37 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Eivind Eklund wrote: > >If anyone's interested, there's a compiled copy on freefall in > > ~brian/src/usr.sbin/ppp > > I was interested, and thus tried to get it from here. That seemed awfully > hard without having an account on freefall - or am I being stupid here? Well, Brian, i think as a freefall user you could put it into frefall's incoming. (Uploads from outside have been disabled.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Jan 29 12:58:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20842 for hackers-outgoing; Wed, 29 Jan 1997 12:58:58 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA20834 for ; Wed, 29 Jan 1997 12:58:51 -0800 (PST) Received: (qmail 8847 invoked by uid 5); 29 Jan 1997 20:58:49 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Thu Jan 30 07:24:26 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id HAA04929; Thu, 30 Jan 1997 07:24:26 +1100 (EST) From: John Birrell Message-Id: <199701292024.HAA04929@freebsd1.cimlogic.com.au> Subject: Re: PC/104 network computer To: dufault@hda.com (Peter Dufault) Date: Thu, 30 Jan 1997 07:24:25 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199701291232.HAA08800@hda.hda.com> from Peter Dufault at "Jan 29, 97 07:32:45 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Dufault wrote: > (I tried hardware. Anyone on -hackers using a PC/104 single board > computer?) > > I'm looking for a single board PC/104 computer with ethernet, flash > memory, memory, serial ports, and parallel port on a single card. > For ease in bootstrapping it should also have a keyboard and floppy > interface. I also need a good looking small enclosure with power > supply and external connectors. I'm not concerned with screaming > performance or more than 16MB memory. > > The kind of board I have in mind is similar to the Megatel PC/II+i: > > http://www.emji.net:80/megatel/pc2ispec.html > > Can anyone recommend others? We've just installed two Teknor Viper 806 boards running FreeBSD and using a digital I/O board plugged into the PC104 connector. We sourced the boards from a local distributor, but the brochures refer to: http://www.teknor.com/ > > Peter > > -- > Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation > HD Associates, Inc. Voice: 508 433 6936 > Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au; jb@netbsd.org 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Wed Jan 29 13:00:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA21047 for hackers-outgoing; Wed, 29 Jan 1997 13:00:43 -0800 (PST) Received: from darkstar (ras527.srv.net [205.180.127.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA21042 for ; Wed, 29 Jan 1997 13:00:38 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id NAA01064; Wed, 29 Jan 1997 13:58:29 -0700 Date: Wed, 29 Jan 1997 13:58:28 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Darren Reed cc: Eivind Eklund , brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi Subject: Re: ipdivert & masqd In-Reply-To: <9701292040.AA22766@snake.srv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But anything after the 512th data byte in the TCP payload will be ignored, > so if your message is 512 bytes long, contains a DCC request in it, > information will be lost that the sender is not aware about (this assumes > the packet is just one IRC message) if the payload size must increase as > a result. > > It is a *much* better idea to redirect IRC to a local TCP port and process > it using a proxy agent. Same could also be said for FTP. > > Darren Darren, In theory, one can construct cases where the FTP logic in the packet aliasing software won't work (IP fragmenting a PORT command, or where the PORT command is split between TCP packets with different sequence numbers, or where the PORT command is in the middle of a packet, and so forth). In practice, these situations are not seen, and the packet aliasing software works for FTP. The system loading is very low, and the software easily scales to situations where there are large numbers of users. I don't know about IRC, but my guess is that the real situation is simpler than the theoretical. Whatever Linux does to handle IRC, I am told that it looks fairly similar to what one does for FTP. Charles Mott From owner-freebsd-hackers Wed Jan 29 13:19:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA21972 for hackers-outgoing; Wed, 29 Jan 1997 13:19:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA21965 for ; Wed, 29 Jan 1997 13:19:41 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA17113; Wed, 29 Jan 1997 13:57:56 -0700 From: Terry Lambert Message-Id: <199701292057.NAA17113@phaeton.artisoft.com> Subject: Re: 2.2 sources ? To: eivind@dimaga.com (Eivind Eklund) Date: Wed, 29 Jan 1997 13:57:56 -0700 (MST) Cc: terry@lambert.org, jdp@polstra.com, joerg_wunsch@uriah.heep.sax.de, beckmann@mail.nacamar.de, hackers@FreeBSD.ORG In-Reply-To: <3.0.32.19970129204709.00afdec0@dimaga.com> from "Eivind Eklund" at Jan 29, 97 08:47:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >This would let you click a "make BSD install disks" button in any > >browser that allowed ".exe" file types (ie: MS Internet Explorer 3.x) > >and end up with disks, without dicking around with rawrite or the > >other tons of excerment you have to play with now. > > I don't believe it is possible to do access the raw disks from Win95 or > WinNT; at least, it is not possible from a DOS executable. It *might* be > possible from a WinNT executable (which will also run under Win95). > However, my resident Win95/NT expert didn't know how. You must assert volume locks. These are documented in the Win95 SDK. You can open a channel to the ring 0 stub driver to get at the driver level code. This can all be done from a Windows95 executable which is a "console" application (or you can make it a Windows app). A CGI script can tell a Win95 IE3.x from a WinNT IE3.x, and provide the right executable. > >3) > >How about definining a ".sh" file type in the default mailcap for > >the FreeBSD install for NetScape or whatever, and setting up each > >port as a button which generates a .sh for the port using a CGI > >script... "click here to install this, click here to install that" > >buttons for all ports and packages. Use a CGI script to rotor, and/or > >have the user select, a mirror site to get packages from. > > I still don't like the concept of having the user *automatically* run > anything downloaded. I don't think setting ut the mailcap to do so is a > good idea, to put it mildly. (It almost give me enough paranoia to make me > want to switch to another OS; it is a large part of the reason I don't run > IE, _ever_.) IE has settings which, by default, will offer to download rather than run an executable grabbed this way. You have to override them if you want them to run. But it's one click away. If NetScape doesn't have the same "override" feature in its mailcap definition for external file type handlers, you could build a small X app to pipeline the sh handler, and provide the same feature there (but I'm pretty sure NetScape can do anything IE can do). The point is to make it *much* easier to obtain access to the programs and data on the WW server. For instance, it would have been seriously handy for setting up cvsup to not have to dick with all of the usses, and deal with a forms/checkbox/button interface instead. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Jan 29 13:20:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22121 for hackers-outgoing; Wed, 29 Jan 1997 13:20:59 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA22111 for ; Wed, 29 Jan 1997 13:20:53 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA04513; Wed, 29 Jan 1997 22:20:44 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA21423; Wed, 29 Jan 1997 22:03:51 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 22:03:50 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Shimon@i-Connect.Net (Simon Shapiro) Cc: hackers@FreeBSD.ORG Subject: Re: More 2.2-BETA goodies... References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Jan 29, 1997 11:13:14 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > 1. An easy way to panic the system: > > * Put ``devfs /devs devfs rw 0 0'' > in /etc/fstab > * Do ``mount -a'' Shortcut: umount /devs Known sucker. DEVFS is really not yet ready for the masses. (Alas.) > 5. Question: Using xperfmon++ (cool), one observes that a system equipped > with AHA2940W enjoys about 3-15 times as many interrupts/sec as disk > transfers/sec. The system, does nothing but SCSI right now (cvs > checkout in parallel with a tape backup (cpio, I know...). > Nothing else. > > Discounting > 100 interrupts for the heartbeat, ... You have to discount 100 + 128 interrupts per second, there are two clocks. If you're using pcaudio, this increases to 100 + 1024 while pcaudio is running. xperfmon++ has a tendency to not become adapted to more recent changes very quickly (guess whom you should blame for this :-). systat -vmstat might be more authoritative in its data (and also gives you a split view for the various interrupt sources). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Jan 29 13:25:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22307 for hackers-outgoing; Wed, 29 Jan 1997 13:25:51 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA22302 for ; Wed, 29 Jan 1997 13:25:49 -0800 (PST) Message-Id: <199701292125.NAA22302@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA221113143; Thu, 30 Jan 1997 08:25:43 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net (Charles Mott) Date: Thu, 30 Jan 1997 08:25:43 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Charles Mott" at Jan 29, 97 01:58:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Charles Mott, sie said: > > > But anything after the 512th data byte in the TCP payload will be ignored, > > so if your message is 512 bytes long, contains a DCC request in it, > > information will be lost that the sender is not aware about (this assumes > > the packet is just one IRC message) if the payload size must increase as > > a result. > > > > It is a *much* better idea to redirect IRC to a local TCP port and process > > it using a proxy agent. Same could also be said for FTP. > > > > Darren > > Darren, > > In theory, one can construct cases where the FTP logic in the packet > aliasing software won't work (IP fragmenting a PORT command, or where the > PORT command is split between TCP packets with different sequence numbers, > or where the PORT command is in the middle of a packet, and so forth). > > In practice, these situations are not seen, and the packet aliasing > software works for FTP. The system loading is very low, and the software > easily scales to situations where there are large numbers of users. > > I don't know about IRC, but my guess is that the real situation is simpler > than the theoretical. Whatever Linux does to handle IRC, I am told that > it looks fairly similar to what one does for FTP. Well, in practice, the TIS FWTK/Gauntlet was sending the FTP PORT command in two packets, so that Linux would break and so too did Firewall-1. Darren From owner-freebsd-hackers Wed Jan 29 13:31:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22667 for hackers-outgoing; Wed, 29 Jan 1997 13:31:22 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA22651 for ; Wed, 29 Jan 1997 13:31:15 -0800 (PST) Message-Id: <199701292131.NAA22651@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA221713349; Thu, 30 Jan 1997 08:29:09 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: archie@whistle.com (Archie Cobbs) Date: Thu, 30 Jan 1997 08:29:09 +1100 (EDT) Cc: terry@lambert.org, archie@whistle.com, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net In-Reply-To: <199701292016.MAA24360@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 12:16:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Archie Cobbs, sie said: > > The theory was that this loop avoidance was working too well, and > seemed to be applying to packets other than the one that it was > supposed to. What I'm trying to prove to myself is that this can't > be happening. Does ip_divert_flag get set/reset inside or outside the loop in ip_input() which dequeues packets ? (src isn't handy) Darren From owner-freebsd-hackers Wed Jan 29 13:32:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22856 for hackers-outgoing; Wed, 29 Jan 1997 13:32:21 -0800 (PST) Received: from darkstar (ras527.srv.net [205.180.127.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA22827 for ; Wed, 29 Jan 1997 13:32:13 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id OAA01100; Wed, 29 Jan 1997 14:31:48 -0700 Date: Wed, 29 Jan 1997 14:31:47 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Darren Reed cc: hackers@freebsd.org Subject: Re: ipdivert & masqd In-Reply-To: <9701292125.AA24747@snake.srv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Darren Reed wrote: > In some mail from Charles Mott, sie said: > > > > > But anything after the 512th data byte in the TCP payload will be ignored, > > > so if your message is 512 bytes long, contains a DCC request in it, > > > information will be lost that the sender is not aware about (this assumes > > > the packet is just one IRC message) if the payload size must increase as > > > a result. > > > > > > It is a *much* better idea to redirect IRC to a local TCP port and process > > > it using a proxy agent. Same could also be said for FTP. > > > > > > Darren > > > > Darren, > > > > In theory, one can construct cases where the FTP logic in the packet > > aliasing software won't work (IP fragmenting a PORT command, or where the > > PORT command is split between TCP packets with different sequence numbers, > > or where the PORT command is in the middle of a packet, and so forth). > > > > In practice, these situations are not seen, and the packet aliasing > > software works for FTP. The system loading is very low, and the software > > easily scales to situations where there are large numbers of users. > > > > I don't know about IRC, but my guess is that the real situation is simpler > > than the theoretical. Whatever Linux does to handle IRC, I am told that > > it looks fairly similar to what one does for FTP. > > Well, in practice, the TIS FWTK/Gauntlet was sending the FTP PORT command > in two packets, so that Linux would break and so too did Firewall-1. > > Darren > That is curious. What does TIS FWTK/Gauntlet do? Charles Mott From owner-freebsd-hackers Wed Jan 29 13:39:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA23304 for hackers-outgoing; Wed, 29 Jan 1997 13:39:24 -0800 (PST) Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA23299 for ; Wed, 29 Jan 1997 13:39:21 -0800 (PST) Received: from idt.unit.no (tegge@ikke.idt.unit.no [129.241.111.65]) by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id WAA21498; Wed, 29 Jan 1997 22:32:21 +0100 (MET) Message-Id: <199701292132.WAA21498@pat.idt.unit.no> To: petzi@mail.nacamar.de Cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA: options MAXMEM not working (fwd) In-Reply-To: Your message of "Wed, 29 Jan 1997 19:36:58 +0100 (MET)" References: X-Mailer: Mew version 1.06 on Emacs 19.33.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 29 Jan 1997 22:32:21 +0100 From: Tor Egge Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > OK, after having built a couple more kernels, I found out that the MAXMEM > option does not work for me when set to over 128 MB. I now run a kernel > that uses only 128 MB, though my machine has 192 MB and will have 256 at > the end of the week. Has this problem been fixed in kernels subsequent to > 2.2-BETA ? I was using 160 MB just fine with FreeBSD 2.1.5. > > Cheers, > > Michael Is bounce buffer support disabled ? It uses some kernel virtual address space. If that does not help, you may want to look at PR kern/1880. - Tor Egge From owner-freebsd-hackers Wed Jan 29 13:42:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA23518 for hackers-outgoing; Wed, 29 Jan 1997 13:42:26 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA23513 for ; Wed, 29 Jan 1997 13:42:23 -0800 (PST) Message-Id: <199701292142.NAA23513@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA227324136; Thu, 30 Jan 1997 08:42:16 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net (Charles Mott) Date: Thu, 30 Jan 1997 08:42:16 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, hackers@freebsd.org In-Reply-To: from "Charles Mott" at Jan 29, 97 02:31:47 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Charles Mott, sie said: > > > Well, in practice, the TIS FWTK/Gauntlet was sending the FTP PORT command > > in two packets, so that Linux would break and so too did Firewall-1. > > > > Darren > > > > That is curious. What does TIS FWTK/Gauntlet do? does a send/write call for "PORT " and another for the address/port info. Darren From owner-freebsd-hackers Wed Jan 29 14:07:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA24902 for hackers-outgoing; Wed, 29 Jan 1997 14:07:14 -0800 (PST) Received: from darkstar (ras527.srv.net [205.180.127.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA24866 for ; Wed, 29 Jan 1997 14:05:51 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id PAA01136; Wed, 29 Jan 1997 15:05:35 -0700 Date: Wed, 29 Jan 1997 15:05:34 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Darren Reed cc: avalon@coombs.anu.edu.au, hackers@freebsd.org Subject: Re: ipdivert & masqd In-Reply-To: <9701292142.AA19231@snake.srv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > That is curious. What does TIS FWTK/Gauntlet do? > > does a send/write call for "PORT " and another for the address/port > info. > > Darren My syntax may have been a little unclear. It is just that I had never heard of the TIS ... Gauntlet program. Is it just an FTP client, or something more advanced? If source code is available, I think that some may wish to update the code. Charles Mott From owner-freebsd-hackers Wed Jan 29 14:33:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA26251 for hackers-outgoing; Wed, 29 Jan 1997 14:33:51 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA26240 for ; Wed, 29 Jan 1997 14:33:45 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id WAA13475; Wed, 29 Jan 1997 22:03:39 GMT Message-Id: <199701292203.WAA13475@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Eivind Eklund cc: hackers@freebsd.org Subject: Re: PR2347 - recursive malloc() in ppp In-reply-to: Your message of "Wed, 29 Jan 1997 17:56:37 +0100." <3.0.32.19970129175636.00ae0c10@dimaga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 22:03:38 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > At 12:24 AM 1/29/97 +0000, Brian Somers wrote: > >Anyone interested in running the "fixed" version? It seems ok on my machine. > >All I've done is made the "work" happen in a call from the top level > >read-a-packet loop, and triggered it via a variable that's set when an > >alarm happens. > > > >If anyone's interested, there's a compiled copy on freefall in > > ~brian/src/usr.sbin/ppp > > I was interested, and thus tried to get it from here. That seemed awfully > hard without having an account on freefall - or am I being stupid here? [.....] No - I am, or at least I'm being inconsiderate. The code has been commited now, so it's available via cvsup. Drop me a line if you want me to send you a patch (if you don't sup). My appologies. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 14:34:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA26286 for hackers-outgoing; Wed, 29 Jan 1997 14:34:06 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA26273 for ; Wed, 29 Jan 1997 14:34:01 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id VAA13426 for ; Wed, 29 Jan 1997 21:46:13 GMT Message-Id: <199701292146.VAA13426@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: lpd - remote printing with an output filter Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 21:46:13 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone got any problems with me making this work ? It's always irritated me ! It consists of two one-liners to printjob.c. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 14:43:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27025 for hackers-outgoing; Wed, 29 Jan 1997 14:43:09 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27016 for ; Wed, 29 Jan 1997 14:43:05 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA19113; Wed, 29 Jan 1997 14:41:13 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma019111; Wed Jan 29 14:40:44 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id OAA24821; Wed, 29 Jan 1997 14:40:44 -0800 (PST) From: Archie Cobbs Message-Id: <199701292240.OAA24821@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: from Charles Mott at "Jan 29, 97 01:58:28 pm" To: cmott@srv.net (Charles Mott) Date: Wed, 29 Jan 1997 14:40:44 -0800 (PST) Cc: avalon@coombs.anu.edu.au, eivind@dimaga.com, brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > But anything after the 512th data byte in the TCP payload will be ignored, > > so if your message is 512 bytes long, contains a DCC request in it, > > information will be lost that the sender is not aware about (this assumes > > the packet is just one IRC message) if the payload size must increase as > > a result. > > > > It is a *much* better idea to redirect IRC to a local TCP port and process > > it using a proxy agent. Same could also be said for FTP. > > > > Darren > > Darren, > > In theory, one can construct cases where the FTP logic in the packet > aliasing software won't work (IP fragmenting a PORT command, or where the > PORT command is split between TCP packets with different sequence numbers, > or where the PORT command is in the middle of a packet, and so forth). > > In practice, these situations are not seen, and the packet aliasing > software works for FTP. The system loading is very low, and the software > easily scales to situations where there are large numbers of users. My observations are consistent with Charles' .. I've only ever seen the FTP port command alone in it's own packet. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 14:46:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27201 for hackers-outgoing; Wed, 29 Jan 1997 14:46:33 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27188 for ; Wed, 29 Jan 1997 14:45:54 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA16901; Thu, 30 Jan 1997 09:45:39 +1100 (EST) Date: Thu, 30 Jan 1997 09:45:38 +1100 (EST) From: "Daniel O'Callaghan" To: Charles Mott cc: Darren Reed , Eivind Eklund , brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@freebsd.org, ari.suutari@ps.carel.fi Subject: Re: ipdivert & masqd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Charles Mott wrote: > In theory, one can construct cases where the FTP logic in the packet > aliasing software won't work (IP fragmenting a PORT command, or where the > PORT command is split between TCP packets with different sequence numbers, > or where the PORT command is in the middle of a packet, and so forth). > > In practice, these situations are not seen, and the packet aliasing > software works for FTP. The system loading is very low, and the software > easily scales to situations where there are large numbers of users. > > I don't know about IRC, but my guess is that the real situation is simpler > than the theoretical. Whatever Linux does to handle IRC, I am told that > it looks fairly similar to what one does for FTP. People coding these in-stream proxies might also like to look at the slirp code There are quite a few transparent proxies in there. Danny From owner-freebsd-hackers Wed Jan 29 14:47:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27254 for hackers-outgoing; Wed, 29 Jan 1997 14:47:28 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27246 for ; Wed, 29 Jan 1997 14:47:26 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA19160; Wed, 29 Jan 1997 14:46:43 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma019158; Wed Jan 29 14:46:19 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id OAA24842; Wed, 29 Jan 1997 14:46:19 -0800 (PST) From: Archie Cobbs Message-Id: <199701292246.OAA24842@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701292130.NAA19395@gatekeeper> from Darren Reed at "Jan 30, 97 08:29:09 am" To: avalon@coombs.anu.edu.au (Darren Reed) Date: Wed, 29 Jan 1997 14:46:19 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@freebsd.org, cmott@srv.net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The theory was that this loop avoidance was working too well, and > > seemed to be applying to packets other than the one that it was > > supposed to. What I'm trying to prove to myself is that this can't > > be happening. > > Does ip_divert_flag get set/reset inside or outside the loop in > ip_input() which dequeues packets ? (src isn't handy) Ah.. well, it doesn't get reset until ip_input() returns. Perhaps this is the problem... certainly if calling ip_input() with one packet can trigger the ipfw processing of other packets, that would be bad. [ checking source .. ] >From my reading it doesn't seem like this can happen. Packet fragments are queued up and then merged when the last packet arrives, but sending ip_input() a whole separate packet shouldn't trigger this. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 14:47:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27266 for hackers-outgoing; Wed, 29 Jan 1997 14:47:30 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27251 for ; Wed, 29 Jan 1997 14:47:27 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id OAA25606 for ; Wed, 29 Jan 1997 14:46:26 -0800 (PST) Message-ID: <32EFD2E2.167EB0E7@whistle.com> Date: Wed, 29 Jan 1997 14:44:50 -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: [Fwd: freebsd performance.] Content-Type: multipart/mixed; boundary="------------794BDF32446B9B3D2781E494" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------794BDF32446B9B3D2781E494 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A commnet from someone using FreeBSD in a production project.. I know nothing about the regex stuff... anyone have comments? people who have committed their proffesional name on using freeBSD deserve sume special support. julian --------------794BDF32446B9B3D2781E494 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from whistle.com (whistle.whistle.com [207.76.205.131]) by alpo.whistle.com (8.8.4/8.8.4) with ESMTP id JAA18431 for ; Wed, 29 Jan 1997 09:42:39 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id JAA16637 for ; Wed, 29 Jan 1997 09:42:37 -0800 (PST) Received: from gatekeeper.whistle.com(207.76.204.2) by whistle.com via smap (V1.3) id sma016635; Wed Jan 29 09:42:31 1997 Received: (from smap@localhost) by gatekeeper (8.7.5/8.6.12) id JAA15158 for ; Wed, 29 Jan 1997 09:42:31 -0800 (PST) Received: from idiom.com(140.174.82.4) by gatekeeper via smap (V1.3) id sma015156; Wed Jan 29 09:41:12 1997 Received: from localhost (jason@localhost [127.0.0.1]) by idiom.com (8.8.5/8.8.3) with SMTP id JAA10621 for ; Wed, 29 Jan 1997 09:41:11 -0800 (PST) Message-Id: <199701291741.JAA10621@idiom.com> X-Authentication-Warning: idiom.com: jason@localhost [127.0.0.1] didn't use HELO protocol To: julian@whistle.com Subject: freebsd performance. Date: Wed, 29 Jan 1997 09:41:11 -0800 From: Jason Venner The posix regex library is VERY VERY slow. I have a program that uses a large regex to parse some input. I have a version in perl and a version in C++ using the freebsd posix regex library. The perl version is 100X faster that the C++ version. gprof on the C++ version shows 99% of the spend in: 91.53 46.17 46.17 1152366 0.04 0.04 lstep 6.52 49.46 3.29 98497 0.03 0.47 lslow --------------794BDF32446B9B3D2781E494-- From owner-freebsd-hackers Wed Jan 29 14:47:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27305 for hackers-outgoing; Wed, 29 Jan 1997 14:47:40 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA27295 for ; Wed, 29 Jan 1997 14:47:37 -0800 (PST) Received: from becker2.u.washington.edu by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vpims-000907C; Wed, 29 Jan 97 14:47 PST Received: from localhost (spaz@localhost) by becker2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with SMTP id OAA26572; Wed, 29 Jan 1997 14:45:42 -0800 (PST) Date: Wed, 29 Jan 1997 14:45:40 -0800 (PST) From: John Utz To: Michael Beckmann cc: hackers@FreeBSD.ORG Subject: Re: 2.2-BETA: options MAXMEM not working (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi; This sounds like a variable length problem, such as a variable that is declared as an int but actually needs to be a long int...., thus you might be getting a wrap-around modulo the largest value that the variable can actually hold... just my 0.02.... On Wed, 29 Jan 1997, Michael Beckmann wrote: > OK, after having built a couple more kernels, I found out that the MAXMEM > option does not work for me when set to over 128 MB. I now run a kernel > that uses only 128 MB, though my machine has 192 MB and will have 256 at > the end of the week. Has this problem been fixed in kernels subsequent to > 2.2-BETA ? I was using 160 MB just fine with FreeBSD 2.1.5. > > Cheers, > > Michael > > ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-hackers Wed Jan 29 15:06:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA28261 for hackers-outgoing; Wed, 29 Jan 1997 15:06:05 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA28255 for ; Wed, 29 Jan 1997 15:06:01 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id KAA17182; Thu, 30 Jan 1997 10:02:03 +1100 Date: Thu, 30 Jan 1997 10:02:03 +1100 From: Bruce Evans Message-Id: <199701292302.KAA17182@godzilla.zeta.org.au> To: j@uriah.heep.sax.de, Shimon@i-Connect.Net Subject: Re: More 2.2-BETA goodies... Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Discounting >> 100 interrupts for the heartbeat, ... > >You have to discount 100 + 128 interrupts per second, there are two >clocks. If you're using pcaudio, this increases to 100 + 1024 while >pcaudio is running. 16000 + 128 when pcaudio is running. 100 + 1024 when profiling is running. I use pcaudio to stress the system. Bruce From owner-freebsd-hackers Wed Jan 29 15:35:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA29745 for hackers-outgoing; Wed, 29 Jan 1997 15:35:11 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA29721 for ; Wed, 29 Jan 1997 15:34:55 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id XAA14485; Wed, 29 Jan 1997 23:30:52 GMT Message-Id: <199701292330.XAA14485@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: terry@lambert.org (Terry Lambert), ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net Subject: Re: ipdivert & masqd In-reply-to: Your message of "Wed, 29 Jan 1997 12:16:41 PST." <199701292016.MAA24360@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 23:30:52 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [.....] > > Actually, I think it's so the outbound packet doesn't get redivirted > > by that particular handler, but you *can* chain handlers. For instance, > > say I wanted to chain a cleanwall, a firewall, and a IP proxy server > > and they were all in seperate divert modules. > > Right! That is the purpose of this ip_divert_ignore hack -- for loop > avoidance. It allows you to send a packet back out via the divert socket > and simultaneously say "Don't divert *this* packet back into *this* socket". > > The theory was that this loop avoidance was working too well, and > seemed to be applying to packets other than the one that it was > supposed to. What I'm trying to prove to myself is that this can't > be happening. > > -Archie Not exactly - on my machine, there are two problems (3.0-current). The machine that's doing the masquerading is 10.0.1.254. 1. When I do a tcp setup from 10.0.1.254 to 10.0.1.1, the packet goes out ok, 10.0.1.1 receives it and replies (netstat shows ESTABLISHED). Masqd/natd receives the packet, fixes it and re-injects it.... then, all of a sudden, nothing happens. After a long wait, nothing continues to happen :( It's as if the ip_sum is wrong, but I don't believe that yet as it works ok when there are two divert sockets involved. 2. When a ping is sent from 10.0.1.1 to 10.0.1.254, the incoming icmp packet is picked up by masqd/natd, fondled and re-injected. That's *all* that masqd/natd sees. However, 10.0.1.1 gets an ICMP reply. Everything else works. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 15:48:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00434 for hackers-outgoing; Wed, 29 Jan 1997 15:48:27 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00429 for ; Wed, 29 Jan 1997 15:48:23 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA19873; Wed, 29 Jan 1997 15:47:45 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma019871; Wed Jan 29 15:47:15 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id PAA25117; Wed, 29 Jan 1997 15:47:14 -0800 (PST) From: Archie Cobbs Message-Id: <199701292347.PAA25117@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701292330.XAA14485@awfulhak.demon.co.uk> from Brian Somers at "Jan 29, 97 11:30:52 pm" To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Wed, 29 Jan 1997 15:47:14 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Not exactly - on my machine, there are two problems (3.0-current). The > machine that's doing the masquerading is 10.0.1.254. > > 1. When I do a tcp setup from 10.0.1.254 to 10.0.1.1, the packet goes out > ok, 10.0.1.1 receives it and replies (netstat shows ESTABLISHED). > Masqd/natd receives the packet, fixes it and re-injects it.... then, > all of a sudden, nothing happens. After a long wait, nothing continues > to happen :( It's as if the ip_sum is wrong, but I don't believe that > yet as it works ok when there are two divert sockets involved. > > 2. When a ping is sent from 10.0.1.1 to 10.0.1.254, the incoming icmp > packet is picked up by masqd/natd, fondled and re-injected. That's > *all* that masqd/natd sees. However, 10.0.1.1 gets an ICMP reply. Hmmm.. a couple of questions, trying to understand the setup. Sorry if this is starting to get tiring... :-) - What is your network topology (ASCII art if possible)? That is, what IP interfaces are on what networks with what addresses assigned? - What are the ipfw rules that are installed on the diverting machine? - Why are any packets having their IP addresses remapped if the two machines (at 10.0.1.254 and 10.0.1.1) are on the same subnet? Also, if netstat shows ESTABLISHED (on either end), then at least one packet must have successfully made it across in both directions, due to the TCP handshaking involved in getting to that state. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Jan 29 15:56:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00809 for hackers-outgoing; Wed, 29 Jan 1997 15:56:07 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00800 for ; Wed, 29 Jan 1997 15:56:05 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id PAA09608; Wed, 29 Jan 1997 15:55:41 -0800 (PST) To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: [Fwd: freebsd performance.] In-reply-to: Your message of "Wed, 29 Jan 1997 14:44:50 PST." <32EFD2E2.167EB0E7@whistle.com> Date: Wed, 29 Jan 1997 15:55:40 -0800 Message-ID: <9604.854582140@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I know nothing about the regex stuff... > anyone have comments? We know. Keith Bostic was grousing about it at USENIX, and apparently Henry Spencer was supposed to do more stuff with the regexp code but never did, so it's sort of up for grabs. Jordan From owner-freebsd-hackers Wed Jan 29 15:59:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00931 for hackers-outgoing; Wed, 29 Jan 1997 15:59:03 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00926 for ; Wed, 29 Jan 1997 15:59:00 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id PAA27625; Wed, 29 Jan 1997 15:56:10 -0800 (PST) Message-ID: <32EFE339.31DFF4F5@whistle.com> Date: Wed, 29 Jan 1997 15:54:33 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Joerg Wunsch CC: Simon Shapiro , hackers@freebsd.org Subject: Re: More 2.2-BETA goodies... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Simon Shapiro wrote: > > > Shortcut: umount /devs > > Known sucker. DEVFS is really not yet ready for the masses. (Alas.) damm! I tought I fixed that! oh well hpefully I'll get back to it again.. > > > 5. Question: Using xperfmon++ (cool), one observes that a system equipped > > with AHA2940W enjoys about 3-15 times as many interrupts/sec as disk > > transfers/sec. The system, does nothing but SCSI right now (cvs > > checkout in parallel with a tape backup (cpio, I know...). > > Nothing else. > > > > Discounting > > 100 interrupts for the heartbeat, ... > > You have to discount 100 + 128 interrupts per second, there are two > clocks. If you're using pcaudio, this increases to 100 + 1024 while > pcaudio is running. actually thats 16000 for pcaudio it interrupts twice per audio sample :) > > xperfmon++ has a tendency to not become adapted to more recent changes > very quickly (guess whom you should blame for this :-). systat > -vmstat might be more authoritative in its data (and also gives you a > split view for the various interrupt sources). julian From owner-freebsd-hackers Wed Jan 29 16:21:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA02282 for hackers-outgoing; Wed, 29 Jan 1997 16:21:19 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA02277 for ; Wed, 29 Jan 1997 16:21:08 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id AAA15020; Thu, 30 Jan 1997 00:11:56 GMT Message-Id: <199701300011.AAA15020@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net Subject: Re: ipdivert & masqd In-reply-to: Your message of "Wed, 29 Jan 1997 15:47:14 PST." <199701292347.PAA25117@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 00:11:56 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Not exactly - on my machine, there are two problems (3.0-current). The > > machine that's doing the masquerading is 10.0.1.254. > > > > 1. When I do a tcp setup from 10.0.1.254 to 10.0.1.1, the packet goes out > > ok, 10.0.1.1 receives it and replies (netstat shows ESTABLISHED). > > Masqd/natd receives the packet, fixes it and re-injects it.... then, > > all of a sudden, nothing happens. After a long wait, nothing continues > > to happen :( It's as if the ip_sum is wrong, but I don't believe that > > yet as it works ok when there are two divert sockets involved. > > > > 2. When a ping is sent from 10.0.1.1 to 10.0.1.254, the incoming icmp > > packet is picked up by masqd/natd, fondled and re-injected. That's > > *all* that masqd/natd sees. However, 10.0.1.1 gets an ICMP reply. > > Hmmm.. a couple of questions, trying to understand the setup. Sorry if > this is starting to get tiring... :-) > > - What is your network topology (ASCII art if possible)? That is, > what IP interfaces are on what networks with what addresses assigned? > > - What are the ipfw rules that are installed on the diverting machine? > > - Why are any packets having their IP addresses remapped if the two > machines (at 10.0.1.254 and 10.0.1.1) are on the same subnet? > > Also, if netstat shows ESTABLISHED (on either end), then at least > one packet must have successfully made it across in both directions, > due to the TCP handshaking involved in getting to that state. > > Thanks, > -Archie I've essentially got the following: ---------------- ---------------------- | 10.0.10.2 |------------------| 10.0.10.1 | ---------------- | | | 10.0.1.254 (ed0) | ---------------------- | | ----------------- | | 10.0.1.1 |--------------------------- ----------------- with a mask of ffffff00 everywhere and the machine in the middle using the following: ipfw add 100 divert 6668 all from any to any via ed0 The masqd/natd programs then pick up all packets and call the packet aliasing code. *All* packets get mangled so that there are no real/alias port conflicts - that is, an outgoing packet to 10.0.1.1:21 from 10.0.1.254:1025 cannot keep the 1025 port because it may conflict with an already existing "alias" port - making it impossible to figure out what to do with the returning 10.0.1.254:1025 packet. Instead, all packets have their source port changed to an alias port on the way out, and changed back to what it should be on the way back in. A table is maintained, mapping alias ports to real IP/port pairs. Needless to say, the "point" behind this is to have the 10.0.10.0/24 network connected to the 10.0.1.1/24 network through the 10.0.1.254 IP. The problems with the 10.0.1.254 machine itself are a bit of a shame because that's the machine that didn't need to do anything special in the first place :) -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 16:28:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA02705 for hackers-outgoing; Wed, 29 Jan 1997 16:28:27 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA02697 for ; Wed, 29 Jan 1997 16:28:24 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA20289; Wed, 29 Jan 1997 16:27:45 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma020287; Wed Jan 29 16:27:22 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id QAA25259; Wed, 29 Jan 1997 16:27:21 -0800 (PST) From: Archie Cobbs Message-Id: <199701300027.QAA25259@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701300011.AAA15020@awfulhak.demon.co.uk> from Brian Somers at "Jan 30, 97 00:11:56 am" To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Wed, 29 Jan 1997 16:27:21 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've essentially got the following: > > ---------------- ---------------------- > | 10.0.10.2 |------------------| 10.0.10.1 | > ---------------- | | > | 10.0.1.254 (ed0) | > ---------------------- > | > | > ----------------- | > | 10.0.1.1 |--------------------------- > ----------------- > > with a mask of ffffff00 everywhere and the machine in the middle using > the following: > > ipfw add 100 divert 6668 all from any to any via ed0 A-HAH! :-) Could you try the following patch? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Index: ip_input.c =================================================================== RCS file: /cvs/freebsd/src/sys/netinet/ip_input.c,v retrieving revision 1.50.2.1 diff -c -r1.50.2.1 ip_input.c *** 1.50.2.1 1996/11/11 23:40:45 --- ip_input.c 1997/01/30 00:26:55 *************** *** 431,436 **** --- 431,438 ---- return; ours: + ip_divert_ignore = 0; /* This packet is being consumed locally, + so we can turn off loop avoidance. */ /* * If offset or IP_MF are set, must reassemble. From owner-freebsd-hackers Wed Jan 29 16:29:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA02886 for hackers-outgoing; Wed, 29 Jan 1997 16:29:59 -0800 (PST) Received: from fog.xinside.com (fog.xinside.com [199.164.187.39]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA02877 for ; Wed, 29 Jan 1997 16:29:55 -0800 (PST) Received: (from smap@localhost) by fog.xinside.com (8.8.3/8.7.3) id RAA13970 for ; Wed, 29 Jan 1997 17:29:54 -0700 (MST) X-Authentication-Warning: fog.xinside.com: smap set sender to using -f Received: from chon.xinside.com(199.164.187.134) by fog.xinside.com via smap (V1.3) id sma013968; Wed Jan 29 17:29:38 1997 Received: (from patrick@localhost) by chon.xinside.com (8.7.5/8.6.12) id RAA02431; Wed, 29 Jan 1997 17:29:19 -0700 (MST) Date: Wed, 29 Jan 1997 17:29:19 -0700 (MST) Message-Id: <199701300029.RAA02431@chon.xinside.com> From: Patrick Giagnocavo To: hackers@freebsd.org Subject: [Fwd: freebsd performance.] In-Reply-To: <32EFD2E2.167EB0E7@whistle.com> References: <32EFD2E2.167EB0E7@whistle.com> Reply-To: patrick@xinside.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Elischer writes: > The posix regex library is VERY VERY slow. > > I have a program that uses a large regex to parse some input. > > I have a version in perl and a version in C++ using the freebsd posix > regex library. > > The perl version is 100X faster that the C++ version. > > gprof on the C++ version shows 99% of the spend in: > > 91.53 46.17 46.17 1152366 0.04 0.04 lstep > 6.52 49.46 3.29 98497 0.03 0.47 lslow I am surprised that some of our more erudite members on the list have not jumped on this. So, a definitely non-erudite person will. The best book to get on the subject is the newly released 'Mastering Regular Expressions' by Jeffrey Freidl; it is published by O'Reilly and Associates. Posix regex is explained in the book; as well, there are a number of tests, gambits, and special cases that can be used to substantially speed up searches. There are two different 'engines' - NFA (nondeterministic finite automaton) and DFA (deterministic finite automaton). Perl is 'traditional NFA' according to Mr. Friedl, while POSIX leans towards DFA-like behavior in all cases (always returns 'leftmost-longest' that matches - perl returns I believe the first part that matches). Also, Perl does not 'do' POSIX IIRC; so the results can actually be different when using the same regex string. Perl does however have some very powerful features for its regex - covered in the book. Anyways, get the book - it is well written and very informative. Another book that covers this is the 'Red Dragon' compiler book by Aho Sethi and Ullman. Page 113 and following in the version I have. Maybe this fellow should post all or part of his regex strings - there may well be a way to optimize them. I am sure that there is a way to speed it up to get it faster. 100X difference is just too great to say that it is the library, IMHO. Cordially Patrick Giagnocavo patrick@xinside.com -Opinions expressed are not even mine, let alone my employers'!- From owner-freebsd-hackers Wed Jan 29 16:48:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA04792 for hackers-outgoing; Wed, 29 Jan 1997 16:48:17 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA04783 for ; Wed, 29 Jan 1997 16:48:14 -0800 (PST) Received: from awfulhak.demon.co.uk by mail.crl.com with SMTP id AA02871 (5.65c/IDA-1.5 for ); Wed, 29 Jan 1997 16:47:36 -0800 Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id AAA15572 for ; Thu, 30 Jan 1997 00:43:57 GMT Message-Id: <199701300043.AAA15572@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: Source code commits Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 00:43:57 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is it possible to commit source code locally, and get cvsup to send the udpates back to freefall ? If not, would there be a lot of work involved ? -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Jan 29 16:59:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA05821 for hackers-outgoing; Wed, 29 Jan 1997 16:59:34 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA05813 for ; Wed, 29 Jan 1997 16:59:31 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA23779; Thu, 30 Jan 1997 11:29:18 +1030 (CST) From: Michael Smith Message-Id: <199701300059.LAA23779@genesis.atrad.adelaide.edu.au> Subject: Kernel extensions, &c. &c. In-Reply-To: <1.5.4.32.19970122145501.00691f78@jump.net> from Lee Crites at "Jan 22, 97 08:55:01 am" To: adonai@jump.net (Lee Crites) Date: Thu, 30 Jan 1997 11:29:17 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Mailbox overload!) Lee Crites stands accused of saying: > >>> Having been on the kernel extension writing end of things, I can appreciate >>> how complex it would be to configure a live, running kernel that can accept > >> aribrary extensions on the fly. However, making something that can > >> link/re-link on reboot wouldn't be as difficult. > > > >Are you admitting some experience and maybe offering to help? Wonderful! > > Well, I've tried to 'admit[] some experience and maybe offer[] to help' > twice before. This is the first time I have received a positive response to it. That's unhappy 8( > The first time (about sockets and such) seemed to have actually garnered > some quasi-offense. I was, in fact, somewhat surprised. After two decades > in the computer industry, including working as a consultant in many > different fields, this was the first time I felt snubbed at the offer of > free help. (While it is true that loading the os on a machine and joining > some lists doesn't make me a 'part' of FreeBSD, I did have some hopes at > kind of wedging my foot in the door, so to speak, by trying to help out in > areas I understood fairly well.) TBH, I don't recall this at all. I certainly don't think that it could be described as the "normal" state of affairs. > I wish you guys luck in trying to come to a good conclusion in this (and the > few other) debate going on. A 'good' conclusion, imo, is one where all > parties can come away feeling good with what is happening and where it is > going, and are happily working together towards the same goals. Thanks! Hopefully your mail problems have been resolved and you can share in the process; I for one would be happy to have your experience and perspective around, and I'm certain I wouldn't be alone. > Lee -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 17:20:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA07683 for hackers-outgoing; Wed, 29 Jan 1997 17:20:36 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA07674 for ; Wed, 29 Jan 1997 17:20:31 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA24028; Thu, 30 Jan 1997 11:50:11 +1030 (CST) From: Michael Smith Message-Id: <199701300120.LAA24028@genesis.atrad.adelaide.edu.au> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701290249.VAA04040@spoon.beta.com> from "Brian J. McGovern" at "Jan 28, 97 09:49:02 pm" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 11:50:10 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern stands accused of saying: > I've been noticing, more an more, that FreeBSD has been/is being > divided in to two camps. Basically, the "has", and the "has > not". What I mean by this, is that there appears to be the core > team, who kick butt making this stuff all work, then the people like > me, who'd like to help out where they can, but seem to have an > incredible time getting started. This is called the "learning curve". There are two ways to climb it, for climb it you must if you want to do anything. 1) Spend lots of time trying, asking questions, exercising your intelligence and patience. 2) Give lots of money to someone else to have them force you through 1). The "have/have not" stance, in this case, is sour grapes because you haven't made it up yet. There isn't some cabal trying to keep you ignorant and frustrated - developers are desperately desired! Case 2) really only manifests when there are lots of people desperate to climb and stupid enough to part with the sort of money involved, which isn't the case with FreeBSD. > you can't beam armies up to your ship, but I digress... I'd like to > submit it in to the "games" section of the ports. However, I notice > this great little file structure that allows you to type "make > install clean", and bam! the application is made, installed, and the > working space is cleaned up. It's in the handbook, in the section on ports. It looks like a cookbook to me. Or perhaps you could look at a few other ones that might be similar to yours - learn by example? > The second major area of concern in my eyes is device > drivers. Someone pointed me to a section of handbook that dealt with > doing it (supposedly), but it was terribly out of date. Back to If you can't work out how device drivers are integrated, I seriously doubt that you're up to writing one in the first place. 8( However, I'll note that I've been helping people learning DD writing for a while now (not that I'm any expert at it either), and I've never seen your name attached to a question going past. How are you supposed to learn if you never _ask_? > I guess what I'm getting at is this: There are a lot of us out here > who would write man pages if we knew how to typeset them, those who > would write neat utilities if we knew how to poll the information > from the kernel (hell, I know about zillion people who'd love to > know how to pull IO/up-down, config statistics from their Ethernet > interfaces, for instance), those who would write drivers for widget > X if they knew how to get them in to the kernel (there are a million > books on writing drivers, but none that I know of that speak > especially about FreeBSD)... I hate to say it, but I think that the right line for you is "there are a lot of us out here that like to whine about doing stuff because it requires some effort, and we're socialised to expect everything handed to us on a platter covered with disclaimers". _prove_me_wrong_ : I (and plenty of others) are willing to help you achieve your goals. It's why we're here. > Them: There isn't any. Try looking at out of date code here>. > > Me: Looks like I'm right so far. Go for it. Please? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 17:26:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA07868 for hackers-outgoing; Wed, 29 Jan 1997 17:26:51 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA07861 for ; Wed, 29 Jan 1997 17:26:47 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA11495; Wed, 29 Jan 1997 17:25:20 -0800 (PST) To: Terry Lambert cc: jlemon@americantv.com, hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-reply-to: Your message of "Wed, 29 Jan 1997 11:00:00 MST." <199701291800.LAA12267@phaeton.artisoft.com> Date: Wed, 29 Jan 1997 17:25:20 -0800 Message-ID: <11491.854587520@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Make sure the IDE controller does not support LBA, get a bigger than > 512M IDE drive anyway, and install the OnTrack 7.x stuff to load > .. a whole bunch of similar instructions deleted .. Why do I get the feeling that Terry is enjoying this? Terry, you sadist! :-) Jordan From owner-freebsd-hackers Wed Jan 29 17:44:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA08896 for hackers-outgoing; Wed, 29 Jan 1997 17:44:15 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA08891 for ; Wed, 29 Jan 1997 17:44:13 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA11626; Wed, 29 Jan 1997 17:44:08 -0800 (PST) To: Brian Somers cc: hackers@freebsd.org Subject: Re: Source code commits In-reply-to: Your message of "Thu, 30 Jan 1997 00:43:57 GMT." <199701300043.AAA15572@awfulhak.demon.co.uk> Date: Wed, 29 Jan 1997 17:44:07 -0800 Message-ID: <11622.854588647@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is it possible to commit source code locally, and get cvsup to send the > udpates back to freefall ? If not, would there be a lot of work involved ? This isn't cvsup's domain, actually, but it is something CVS can handle itself. You simply set CVS_RSH to ``ssh' and CVSROOT to ``freefall.freebsd.org:/home/ncvs'', then you do your CVS operations as normal. I have some shell functions which I use so that I can keep things checked out relative to my local CVS repository (and obviously many times faster than using freefall's) up until the point where I want to commit the changes, then it fools CVS into thinking that the sources were originally checked out from freefall too: function do-local-cvs { setenv CVSROOT /home/ncvs [ -f CVS/Root ] && echo $CVSROOT > CVS/Root } function do-remote-cvs { setenv CVSROOT freefall.freebsd.org:/home/ncvs [ -f CVS/Root ] && echo $CVSROOT > CVS/Root } function cvscommit { do-remote-cvs cvs commit $* do-local-cvs } From owner-freebsd-hackers Wed Jan 29 17:59:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA09819 for hackers-outgoing; Wed, 29 Jan 1997 17:59:52 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09802 for ; Wed, 29 Jan 1997 17:59:49 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id RAA00697; Wed, 29 Jan 1997 17:56:17 -0800 (PST) Message-ID: <32EFFF5F.794BDF32@whistle.com> Date: Wed, 29 Jan 1997 17:54:40 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Michael Smith CC: Lee Crites , hackers@freebsd.org Subject: Re: Kernel extensions, &c. &c. References: <199701300059.LAA23779@genesis.atrad.adelaide.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith wrote: > > (Mailbox overload!) > > Lee Crites stands accused of saying: > > > >>> Having been on the kernel extension writing end of things, I can appreciate > >>> how complex it would be to configure a live, running kernel that can accept > > >> aribrary extensions on the fly. However, making something that can > > >> link/re-link on reboot wouldn't be as difficult. > > > > > >Are you admitting some experience and maybe offering to help? Wonderful! > > > > Well, I've tried to 'admit[] some experience and maybe offer[] to help' > > twice before. This is the first time I have received a positive response to it. The trouble seems to be that there is no single "task master" who can tell you what you should be doing. So if peple are hacking away on their own code they usually feel that they haven't really got the time to explain every thing to some-one new , or that they are not happy with others seeing their code in that state, etc. you need to find something you are interested in and just start on it yourself.. other people will very quickly notice you and include you in the relevant conversations. > > That's unhappy 8( > > > The first time (about sockets and such) seemed to have actually garnered > > some quasi-offense. I was, in fact, somewhat surprised. After two decades > > in the computer industry, including working as a consultant in many > > different fields, this was the first time I felt snubbed at the offer of > > free help. (While it is true that loading the os on a machine and joining > > some lists doesn't make me a 'part' of FreeBSD, I did have some hopes at > > kind of wedging my foot in the door, so to speak, by trying to help out in > > areas I understood fairly well.) What did you offer? there must have been a miscommunication somewhere.. > > TBH, I don't recall this at all. I certainly don't think that it could be > described as the "normal" state of affairs. > > > I wish you guys luck in trying to come to a good conclusion in this (and the > > few other) debate going on. A 'good' conclusion, imo, is one where all > > parties can come away feeling good with what is happening and where it is > > going, and are happily working together towards the same goals. > > Thanks! Hopefully your mail problems have been resolved and you can > share in the process; I for one would be happy to have your experience > and perspective around, and I'm certain I wouldn't be alone. me too > > > Lee > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 18:01:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10037 for hackers-outgoing; Wed, 29 Jan 1997 18:01:02 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA10010 for ; Wed, 29 Jan 1997 18:00:54 -0800 (PST) Message-Id: <199701300200.SAA10010@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA019119490; Thu, 30 Jan 1997 12:58:10 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: archie@whistle.com (Archie Cobbs) Date: Thu, 30 Jan 1997 12:58:10 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, brian@awfulhak.demon.co.uk, hackers@FreeBSD.ORG, cmott@srv.net In-Reply-To: <199701292246.OAA24842@bubba.whistle.com> from "Archie Cobbs" at Jan 29, 97 02:46:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Archie Cobbs, sie said: > > > > > The theory was that this loop avoidance was working too well, and > > > seemed to be applying to packets other than the one that it was > > > supposed to. What I'm trying to prove to myself is that this can't > > > be happening. > > > > Does ip_divert_flag get set/reset inside or outside the loop in > > ip_input() which dequeues packets ? (src isn't handy) > > Ah.. well, it doesn't get reset until ip_input() returns. Perhaps > this is the problem... certainly if calling ip_input() with one > packet can trigger the ipfw processing of other packets, that would > be bad. > > [ checking source .. ] > > >From my reading it doesn't seem like this can happen. Packet fragments > are queued up and then merged when the last packet arrives, but sending > ip_input() a whole separate packet shouldn't trigger this. Not what I meant...the ethernet drivers queue up packets using IF_ENQUEUE() (right ?) and ip_input() picks them off using IF_DEQUEUE()...or is there an external loop calling ip_input() now that does the IF_DEQUEUE() ? Darren From owner-freebsd-hackers Wed Jan 29 18:02:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10162 for hackers-outgoing; Wed, 29 Jan 1997 18:02:37 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA10143 for ; Wed, 29 Jan 1997 18:02:31 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id TAA01256; Wed, 29 Jan 1997 19:02:25 -0700 (MST) Date: Wed, 29 Jan 1997 19:02:25 -0700 (MST) Message-Id: <199701300202.TAA01256@rocky.mt.sri.com> From: Nate Williams To: Brian Somers Cc: hackers@freebsd.org Subject: Re: Source code commits In-Reply-To: <199701300043.AAA15572@awfulhak.demon.co.uk> References: <199701300043.AAA15572@awfulhak.demon.co.uk> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is it possible to commit source code locally, and get cvsup to send the > udpates back to freefall ? If not, would there be a lot of work involved ? Nope. The possibility of someone else modifying the source is too great. There has to be a 'central' database, and that database is freefall. Nate From owner-freebsd-hackers Wed Jan 29 18:03:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10266 for hackers-outgoing; Wed, 29 Jan 1997 18:03:15 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA10250 for ; Wed, 29 Jan 1997 18:03:11 -0800 (PST) Message-Id: <199701300203.SAA10250@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA021069778; Thu, 30 Jan 1997 13:02:58 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net (Charles Mott) Date: Thu, 30 Jan 1997 13:02:58 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Charles Mott" at Jan 29, 97 03:05:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Charles Mott, sie said: > > > > That is curious. What does TIS FWTK/Gauntlet do? > > > > does a send/write call for "PORT " and another for the address/port > > info. > > > > Darren > > My syntax may have been a little unclear. It is just that I had never > heard of the TIS ... Gauntlet program. Is it just an FTP client, or > something more advanced? If source code is available, I think that some > may wish to update the code. Firewall product. The point is, it isn't Gauntlet or the Firewall Toolkit which is doing anything wrong, it is the "transparent proxy" which makes bad assumptions (although 99% of the time it gets away with them). Darren From owner-freebsd-hackers Wed Jan 29 18:13:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10733 for hackers-outgoing; Wed, 29 Jan 1997 18:13:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA10725 for ; Wed, 29 Jan 1997 18:13:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA20752; Wed, 29 Jan 1997 18:54:44 -0700 From: Terry Lambert Message-Id: <199701300154.SAA20752@phaeton.artisoft.com> Subject: Re: 2.2-BETA Questions To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 18:54:44 -0700 (MST) Cc: terry@lambert.org, jlemon@americantv.com, hackers@FreeBSD.ORG In-Reply-To: <11491.854587520@time.cdrom.com> from "Jordan K. Hubbard" at Jan 29, 97 05:25:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Make sure the IDE controller does not support LBA, get a bigger than > > 512M IDE drive anyway, and install the OnTrack 7.x stuff to load > > .. a whole bunch of similar instructions deleted .. > > Why do I get the feeling that Terry is enjoying this? Terry, you > sadist! :-) Because if you personally have to put up with the crap, you're going to gain a whole lot of sympathy for the poor schmucks who bought machines with the crap preinstalled, and now want to unistall a small amount of the crap (namely, whatever MS OS they are replacing with BSD). 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Jan 29 18:18:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11057 for hackers-outgoing; Wed, 29 Jan 1997 18:18:31 -0800 (PST) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA11051 for ; Wed, 29 Jan 1997 18:18:24 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.8.3/8.8.3) with SMTP id UAA20887; Wed, 29 Jan 1997 20:17:34 -0600 (CST) Received: from localhost by solaria.sol.net (8.5/8.5) id TAA29530; Wed, 29 Jan 1997 19:56:56 -0600 From: Joe Greco Message-Id: <199701300156.TAA29530@solaria.sol.net> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 29 Jan 97 19:56:55 CST Cc: mcgovern@spoon.beta.com, hackers@FreeBSD.ORG In-Reply-To: <199701300120.LAA24028@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 30, 97 11:50:10 am X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This is called the "learning curve". There are two ways to climb it, for > climb it you must if you want to do anything. > > 1) Spend lots of time trying, asking questions, exercising your intelligence > and patience. > 2) Give lots of money to someone else to have them force you through 1). 3) Spend lots of time trying and bludgeon your way mostly through it, then read the documentation (even if its out of date), and it will probably make a lot more sense. > It's in the handbook, in the section on ports. It looks like a cookbook > to me. Or perhaps you could look at a few other ones that might be > similar to yours - learn by example? That worked for me... I wanted a port for "tripwire" and I bludgeoned my way through, just fine. Mind you, I don't necessarily consider it unreasonable to climb a 150' "learning curve" by wearing my magnetic boots... I spent the better part of a day building a minimal FreeBSD floppy that could NFS mount /usr/X11R6 off of a read only NFS server and act as a diskless Xterminal. That was fun :-) > I hate to say it, but I think that the right line for you is "there > are a lot of us out here that like to whine about doing stuff because > it requires some effort, and we're socialised to expect everything > handed to us on a platter covered with disclaimers". Hmmm, I don't know if that's fair... but then again, maybe it is. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Wed Jan 29 18:24:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11266 for hackers-outgoing; Wed, 29 Jan 1997 18:24:38 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11235; Wed, 29 Jan 1997 18:22:05 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199701300222.SAA11235@freefall.freebsd.org> Subject: Re: Worst Marketing Strategies To: cbt@mcia.com Date: Wed, 29 Jan 1997 18:22:05 -0800 (PST) Cc: webmaster@owlsnest.com, hackers In-Reply-To: <32EFCEFD.2849@mcia.com> from "CBTravenss" at Jan 29, 97 02:28:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The FreeBSD Project Inc. is in no way affliated with owlsnet.com. it seems that owlsnet.com uses FreeBSD to run their website www.owlsnet.com. The FreeBSD Project Inc, is not responsible for the actions of others that use FreeBSD, just as Scott Paper Company is not responsible for the actions of juveniles that use Scott Paper Company products to "paper" someone else's property. jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB CBTravenss wrote: > > Receiving unsolicited email from owlsnest.com was annoying enough but > stating that by replying and returning a copy of your email, I am > therein giving owlsnet.com personnel authorization > to do something and then bill me is totally outrageous. I'm contributing > to an article on Internet marketing techniques and will use your > technique as an example of the worst of them. > > Your affiliation with the FreeBSD organization (your one-page Web > presence: > www.owlsnest.com > offers only one link and the link is to the FreeBSD site), prompts me to > send copies of this message to them so that they can rethink their > affiliation with you, or if your organization and theirs is one and the > same, the marketing strategy you have devised can be more thoughtfully > planned. > > CBT > From owner-freebsd-hackers Wed Jan 29 18:28:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11388 for hackers-outgoing; Wed, 29 Jan 1997 18:28:01 -0800 (PST) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA11365 for ; Wed, 29 Jan 1997 18:27:58 -0800 (PST) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.7.5/8.7.3) with ESMTP id VAA00299 for ; Wed, 29 Jan 1997 21:27:50 -0500 (EST) Message-Id: <199701300227.VAA00299@spooky.rwwa.com> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-hackers@freebsd.org Subject: biosboot config? Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 29 Jan 1997 21:27:49 -0500 From: Robert Withrow Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Attempting to actually solve the ``I wanna automatically boot off my dang scsi drive even though I have two IDE drives in my stupid system'', I think I have a glimmer... I am able to boot my system with ``3:sd(0,a)/kernel'', which seems strange since I have only three drives and the 3: would seem to refer to the fourth drive, no? Any idea why this is? Is this because a ATAPI cdrom gets inserted in the table? Another mystery is this: Booteasy comes up on the first IDE drive (where I installed it), but F5 goes directly to the first SCSI drive. Why is that? Anyway, how's this: 1) I need to CD to /usr/src/sys/i386/boot/biosboot/ 2) I need to rebuild with BOOT_HD_BIAS=3 3) I need to install it onto the disk. HOWZATDONE? Any chance of this working? Will this automatically make ``3:sd(0,a)/kernel'' the default boot? ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM From owner-freebsd-hackers Wed Jan 29 18:30:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11551 for hackers-outgoing; Wed, 29 Jan 1997 18:30:46 -0800 (PST) Received: from darkstar (ras540.srv.net [205.180.127.40]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA11546 for ; Wed, 29 Jan 1997 18:30:42 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id TAA01376; Wed, 29 Jan 1997 19:30:08 -0700 Date: Wed, 29 Jan 1997 19:30:06 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Darren Reed cc: hackers@freebsd.org Subject: Re: ipdivert & masqd In-Reply-To: <9701300203.AA10014@snake.srv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > My syntax may have been a little unclear. It is just that I had never > > heard of the TIS ... Gauntlet program. Is it just an FTP client, or > > something more advanced? If source code is available, I think that some > > may wish to update the code. > > Firewall product. > > The point is, it isn't Gauntlet or the Firewall Toolkit which is doing > anything wrong, it is the "transparent proxy" which makes bad assumptions > (although 99% of the time it gets away with them). > > Darren > I've seen quite a bit of feedback from several continents on the software I have written. In particular, any time I have made a mistake, I have been *very* quickly informed by users. I have yet to see any complaints from users about ftp handling. In any event, it would be unusual to have such a firewall behind the packet aliasing software I have written. It would be interesting to see whether the authors of the firewall product you mention were being deliberately "difficult". Standards are flexible. Most well-intentioned authors of free software want to see their products be as compatible as possible with outside solutions. Having software work with transparent proxies is something that many people are aware of. Of course, people writing commercial products often have very different motives. Your comments are interesting, but your attitude is not constructive in my view. Charles Mott From owner-freebsd-hackers Wed Jan 29 18:34:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11679 for hackers-outgoing; Wed, 29 Jan 1997 18:34:40 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA11674 for ; Wed, 29 Jan 1997 18:34:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA20836; Wed, 29 Jan 1997 19:16:02 -0700 From: Terry Lambert Message-Id: <199701300216.TAA20836@phaeton.artisoft.com> Subject: Re: Source code commits To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Jan 1997 19:16:01 -0700 (MST) Cc: brian@awfulhak.demon.co.uk, hackers@freebsd.org In-Reply-To: <11622.854588647@time.cdrom.com> from "Jordan K. Hubbard" at Jan 29, 97 05:44:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Is it possible to commit source code locally, and get cvsup to send the > > udpates back to freefall ? If not, would there be a lot of work involved ? > > This isn't cvsup's domain, actually, but it is something CVS can > handle itself. You simply set CVS_RSH to ``ssh' and CVSROOT to > ``freefall.freebsd.org:/home/ncvs'', then you do your CVS operations > as normal. > > I have some shell functions which I use so that I can keep things > checked out relative to my local CVS repository (and obviously many > times faster than using freefall's) up until the point where I want to > commit the changes, then it fools CVS into thinking that the sources > were originally checked out from freefall too: [ ... ] Not too useful to those of us who checkin to our local repository because we can't checkin to Freefall... It would be nice if I could: cvsup <-- tree without my tag cvs co src [ set local tag ] [ edit file locally ] [ check in under tag ] cvsup <-- tree without my tag [ edit file more locally ] cvsup <-- tree without my tag [ check in again under tag ] cvsup <-- tree without my tag [ create diff locally ] [ send diff to Julian (or whever has commit privs ] [ set new local tag ] cvsup <-- tree without my tag cvsup <-- tree without my tag [ edit file more locally ] cvsup <-- tree without my tag [ check in again under tag ] cvsup <-- tree without my tag [ Julian commits changes ] cvsup <-- tree without my tag, but with commits from "local tag" to to "new local tag" ] *** Here's the bugger: *** [ I merge local tag, so deltas after "new local tag" are applied relative to post-merge code ] cvsup <-- tree without my tag [ I repeat "send diff..." ] ... Right now, I have to wait for the checkin, and can do no new work until it has occurred (making it against my best interests to check in). Plus, I can't "rebranch" my local tag, or run several concurrent derivative branches (also making it a bad idea to send diffs). Plus you guys lose my edit history, which is what cuts the code up into small enough change domains for you guys to digest (ie: tag1, code, tag2, code, tag3, code, tag4, submit 1-2, submit 2-3, submit 3-4). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Jan 29 18:43:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12136 for hackers-outgoing; Wed, 29 Jan 1997 18:43:59 -0800 (PST) Received: from narcissus.ml.org (root@brosenga.Pitzer.edu [134.173.120.201]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA12131 for ; Wed, 29 Jan 1997 18:43:54 -0800 (PST) Received: (from ben@localhost) by narcissus.ml.org (8.7.5/8.7.3) id SAA06295; Wed, 29 Jan 1997 18:43:52 -0800 (PST) Date: Wed, 29 Jan 1997 18:43:52 -0800 (PST) From: Snob Art Genre To: "Jordan K. Hubbard" cc: Terry Lambert , jlemon@americantv.com, hackers@FreeBSD.ORG Subject: Re: 2.2-BETA Questions In-Reply-To: <11491.854587520@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997, Jordan K. Hubbard wrote: > > Make sure the IDE controller does not support LBA, get a bigger than > > 512M IDE drive anyway, and install the OnTrack 7.x stuff to load > > .. a whole bunch of similar instructions deleted .. > > Why do I get the feeling that Terry is enjoying this? Terry, you > sadist! :-) Everybody's enjoying this -- I forwarded a copy to a Linux-using friend of mine and even he enjoyed it. > > Jordan > Ben The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-hackers Wed Jan 29 18:50:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12515 for hackers-outgoing; Wed, 29 Jan 1997 18:50:16 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA12509 for ; Wed, 29 Jan 1997 18:50:14 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA20882; Wed, 29 Jan 1997 19:30:15 -0700 From: Terry Lambert Message-Id: <199701300230.TAA20882@phaeton.artisoft.com> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 29 Jan 1997 19:30:15 -0700 (MST) Cc: mcgovern@spoon.beta.com, hackers@FreeBSD.ORG In-Reply-To: <199701300120.LAA24028@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 30, 97 11:50:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I've been noticing, more an more, that FreeBSD has been/is being > > divided in to two camps. Basically, the "has", and the "has > > not". What I mean by this, is that there appears to be the core > > team, who kick butt making this stuff all work, then the people like > > me, who'd like to help out where they can, but seem to have an > > incredible time getting started. > > This is called the "learning curve". There are two ways to climb it, for > climb it you must if you want to do anything. [ ... ] How about flattening the curve, instead? It's not an inherent property. [ ... ] > If you can't work out how device drivers are integrated, I seriously > doubt that you're up to writing one in the first place. 8( This is wrong... I don't have to understand linker sets to be a good driver writer, but if I don't, how the driver gets integrated is a bit of FreeBSD-specific mystery, totally abstract from the concept of writing drivers themselves. [ ... wishful thinking on a document describing the existing DKI ... ] > I hate to say it, but I think that the right line for you is "there > are a lot of us out here that like to whine about doing stuff because > it requires some effort, and we're socialised to expect everything > handed to us on a platter covered with disclaimers". Or "we're interested in solving the problems themselves using a defined methodology, than in examining code to determine, each on our own, what a successful methodology might look like; if everyone has to reinvent the wheel, then no one will have time left to work on the wagon". Point of view, really... he did say he was willing to figuratively "reinvent the wheel and document it so other won't have to", only he had the problem with "reinventing how to document". Can't have a wheel until someone documents "how to make a circle"... 8-). Note: I betting that you realize that if you are arguing against documentation, you can't win. 8-) 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Jan 29 18:53:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12783 for hackers-outgoing; Wed, 29 Jan 1997 18:53:56 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA12768 for ; Wed, 29 Jan 1997 18:53:53 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA20892; Wed, 29 Jan 1997 19:32:47 -0700 From: Terry Lambert Message-Id: <199701300232.TAA20892@phaeton.artisoft.com> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: jgreco@solaria.sol.net (Joe Greco) Date: Wed, 29 Jan 1997 19:32:47 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@freebsd.org In-Reply-To: <199701300156.TAA29530@solaria.sol.net> from "Joe Greco" at Jan 29, 97 07:56:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Mind you, I don't necessarily consider it > unreasonable to climb a 150' "learning curve" by wearing my magnetic > boots... Which reminds me... how did Picard and Worf's magnetic boots stick to the Entrprise's Titanium hull? PS: Magnetic boots are only a help if your learning curve is ferromagnetic... 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 Jan 29 19:01:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13697 for hackers-outgoing; Wed, 29 Jan 1997 19:01:50 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13682 for ; Wed, 29 Jan 1997 19:01:46 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA25266; Thu, 30 Jan 1997 13:29:33 +1030 (CST) From: Michael Smith Message-Id: <199701300259.NAA25266@genesis.atrad.adelaide.edu.au> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701300230.TAA20882@phaeton.artisoft.com> from Terry Lambert at "Jan 29, 97 07:30:15 pm" To: terry@lambert.org (Terry Lambert) Date: Thu, 30 Jan 1997 13:29:31 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > > > This is called the "learning curve". There are two ways to climb it, for > > climb it you must if you want to do anything. > > [ ... ] > > How about flattening the curve, instead? It's not an inherent property. Flattening the curve requires reducing the amount of knowledge required for a given task. Reducing the amount of knowledge required in the current context is not a simple or useful task in any other than the longest, most divorced-from-reality view. > > If you can't work out how device drivers are integrated, I seriously > > doubt that you're up to writing one in the first place. 8( > > This is wrong... I don't have to understand linker sets to be a good > driver writer, but if I don't, how the driver gets integrated is a > bit of FreeBSD-specific mystery, totally abstract from the concept > of writing drivers themselves. You're (deliberately?) misreading me. Try the alternative interpretation of what I said. > Note: I betting that you realize that if you are arguing against > documentation, you can't win. 8-) 8-). I'm arguing against someone saying "You're making it too hard" with the response "I'm no bloody genius, and if I can do it, you can too". This makes the generous assumption that the other party is as capable as I am, which is IMHO fairly realistic. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 19:02:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13757 for hackers-outgoing; Wed, 29 Jan 1997 19:02:09 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13725 for ; Wed, 29 Jan 1997 19:01:59 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id WAA09208; Wed, 29 Jan 1997 22:01:40 -0500 (EST) Message-Id: <199701300301.WAA09208@spoon.beta.com> To: msmith@atrad.adelaide.edu.au cc: hackers@freebsd.org Subject: Cases (was: Constructive Criticism) Date: Wed, 29 Jan 1997 22:01:40 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I've been noticing, more an more, that FreeBSD has been/is being >> divided in to two camps. Basically, the "has", and the "has >> not". What I mean by this, is that there appears to be the core >> team, who kick butt making this stuff all work, then the people like >> me, who'd like to help out where they can, but seem to have an >> incredible time getting started. > >This is called the "learning curve". There are two ways to climb it, for >climb it you must if you want to do anything. > >1) Spend lots of time trying, asking questions, exercising your intelligence > and patience. >2) Give lots of money to someone else to have them force you through 1). I disagree with your two cases. As with any development decision, if I can't justify the cost of undertaking the certain project, I won't even begin it. In the case of #1, its a time/learning curve that is out of reach. By the time I figure it out for release x.y.z, its usually changed. Even so, digesting x amount of data in reasonable size time chunks (I usually get 20 minutes a couple of time a day here or there to work on these types of projects, maybe totalling an hour or so a day). In your second case, the dollar cost would also be out of reach. > >The "have/have not" stance, in this case, is sour grapes because you >haven't made it up yet. There isn't some cabal trying to keep you >ignorant and frustrated - developers are desperately desired! > >Case 2) really only manifests when there are lots of people desperate >to climb and stupid enough to part with the sort of money involved, >which isn't the case with FreeBSD. > >> you can't beam armies up to your ship, but I digress... I'd like to >> submit it in to the "games" section of the ports. However, I notice >> this great little file structure that allows you to type "make >> install clean", and bam! the application is made, installed, and the >> working space is cleaned up. > >It's in the handbook, in the section on ports. It looks like a cookbook >to me. Or perhaps you could look at a few other ones that might be >similar to yours - learn by example? Ok, so one bad example ;p But, still, I've noted a good chunk of the technical docs in the handbook always seems to be a release out of date. Again, perhaps its something that can be undertaken. > >> The second major area of concern in my eyes is device >> drivers. Someone pointed me to a section of handbook that dealt with >> doing it (supposedly), but it was terribly out of date. Back to > >If you can't work out how device drivers are integrated, I seriously >doubt that you're up to writing one in the first place. 8( > Ah, again, a circle effect. You'll never get good till you've chewed on a handful of them. And you'll never start on your first till you think you can do it. A lack of documentation makes it infinately more difficult. Again, being under time limitations to "play" with this type of material in _ORDER_ to get good at it, it will take some spoon feeding. But, like my original message said, if I _am_ able to learn something useful, and return an equal amount, or more time on development than what you took to teach me, its a win all around. >However, I'll note that I've been helping people learning DD writing for >a while now (not that I'm any expert at it either), and I've never >seen your name attached to a question going past. How are you supposed >to learn if you never _ask_? > Thats easy. Its something I have a passing interest in undertaking. Unfortunately, my time to tinker with such things is limited. I've banged out some test code in the past (simple device reads, writes, etc), but don't have a weekend to figure out how to stick it in the kernel. And until I know I have a weekend to make a concerted effort, I won't bother anyone with the newbie question. Why ask the question if the answer would be useless? When the time comes, I'll ask. However, I'd also like to keep the number of questions I have to ask to a bare minimum. I'd rather have it be "I'm doing XYZPDQ, and it blows up in such and such a way. Can any one see any obvious problem", than "What do I do now?". It needs to be something I can digest in 20 minute chunks of time, over a long period of time. >> I guess what I'm getting at is this: There are a lot of us out here >> who would write man pages if we knew how to typeset them, those who >> would write neat utilities if we knew how to poll the information >> from the kernel (hell, I know about zillion people who'd love to >> know how to pull IO/up-down, config statistics from their Ethernet >> interfaces, for instance), those who would write drivers for widget >> X if they knew how to get them in to the kernel (there are a million >> books on writing drivers, but none that I know of that speak >> especially about FreeBSD)... > >I hate to say it, but I think that the right line for you is "there >are a lot of us out here that like to whine about doing stuff because >it requires some effort, and we're socialised to expect everything >handed to us on a platter covered with disclaimers". > >_prove_me_wrong_ : I (and plenty of others) are willing to help you >achieve your goals. It's why we're here. 0 I tend to disagree with this sentiment (the silver platter comment) , as well. I agree that a lot of people are like this. But, there are also different levels of interest, and different timeframes. I spend 8 hours plus a day writing code for Cisco. Coming home and spending four hours reviewing device drivers to figure out how to put one together is crazy. However, if there was sufficient documentation on the structures and routines that need to be called to get things set up, I can save the four hours and go straight to putting my effort in to writing the driver. I also realize that some of the kernel routines are being documented in the 3.0 code. I applaud the person (people) doing the work. Also, there are people that learn poorly from example. I'm one of them. That includes everything from programming to learning to fly helicopters (which I now do well, BTW). For me, example goes as far as "Thats neat". For me to grow beyond copying an example in the book, I really need to understand _why_ I'm doing what i'm doing. Reading someone else's chunk of code doesn't tell you WHY they implemented something a certain way... Good commenting would, but if all the code in the world had sufficient commenting, we wouldn't be having this discussion :) But, because I don't like arguing for the sake of arguing, here's a plan. Tomorrow, whilest I'm at work, I will write some code for a pseudo-device driver I wish to call foo. I will write routines for fooinit, fooread, and foowrite. According to the documentation I've read, I should be able to leave the open and close routines set to (I guess NULL ?) nothing. fooinit will also exist, but will just contain a printf to announce the presence of the pseudo-driver. The driver will be a character driver, with major number of 20. Minor number will represent buffer numbers, each buffer will be 1K in length. Writes to a buffer will set the string. Reads will return it (if the full length is specified). Optionally, I'll use the offset attributes to allow multiple reads and writes. Lastly, all of these routines will be in a file called foodev.c. Now, based on my reading, and what I've seen in some of the drivers I _have_ looked at, I believe that I'll have to set a cdevsw structure up, and it looks like a struct isa_driver. I also see probe() and attach() routines that I have not seen documentation on before in the books I have read. I see devfs support thrown in... Looks kinky. Probably will need help there eventually... Anyhow, want to lecture me on what some of these things are, whats required, whats optional, and how my stuff will fit in the cosmic scheme of things? And no, I don't randomly shoot my mouth off about how miserable something is unless I think its worth salvaging, and I'm willing to pitch in _where I can_. If I really just wanted to gripe, I'd keep my mouth shut... Saves on calories. -Brian From owner-freebsd-hackers Wed Jan 29 19:06:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA14099 for hackers-outgoing; Wed, 29 Jan 1997 19:06:55 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA14094 for ; Wed, 29 Jan 1997 19:06:52 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id WAA02410; Wed, 29 Jan 1997 22:05:29 -0500 (EST) Date: Wed, 29 Jan 1997 22:05:29 -0500 (EST) From: Mark Mayo To: Michael Smith cc: "Brian J. McGovern" , hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701300120.LAA24028@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Michael Smith wrote: > Brian J. McGovern stands accused of saying: > > > I've been noticing, more an more, that FreeBSD has been/is being > > divided in to two camps. Basically, the "has", and the "has [big SNIP] > > > The second major area of concern in my eyes is device > > drivers. Someone pointed me to a section of handbook that dealt with > > doing it (supposedly), but it was terribly out of date. Back to > > If you can't work out how device drivers are integrated, I seriously > doubt that you're up to writing one in the first place. 8( > > However, I'll note that I've been helping people learning DD writing for > a while now (not that I'm any expert at it either), and I've never > seen your name attached to a question going past. How are you supposed > to learn if you never _ask_? > I'm a beginning Unix programmer also, and when I looked at the device driver section of the handbook, it was very uncomplete. I understand, however, that writing device drivers in Unix is quite similar across most unix platforms.. Can you recomend a good book on device driver writing for Unix, that would minimize my headaches when I try to make mine work with FreeBSD? TIA. -Mark ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ > From owner-freebsd-hackers Wed Jan 29 19:31:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA15662 for hackers-outgoing; Wed, 29 Jan 1997 19:31:51 -0800 (PST) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA15657 for ; Wed, 29 Jan 1997 19:31:43 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.8.3/8.8.3) with SMTP id VAA21382; Wed, 29 Jan 1997 21:31:31 -0600 (CST) Received: from localhost by solaria.sol.net (8.5/8.5) id VAA00309; Wed, 29 Jan 1997 21:10:53 -0600 From: Joe Greco Message-Id: <199701300310.VAA00309@solaria.sol.net> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: terry@lambert.org (Terry Lambert) Date: Wed, 29 Jan 97 21:10:50 CST Cc: msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@freebsd.org In-Reply-To: <199701300232.TAA20892@phaeton.artisoft.com> from "Terry Lambert" at Jan 29, 97 07:32:47 pm X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Mind you, I don't necessarily consider it > > unreasonable to climb a 150' "learning curve" by wearing my magnetic > > boots... > > Which reminds me... how did Picard and Worf's magnetic boots stick to > the Entrprise's Titanium hull? Maybe a side effect of the Structural Integrity Field? :-) When you're dumping boatloads of energy into the hull, after all... it doesn't seem to be hard to generate gravity, given energy. A minor amount of magnetism should be easier. The hull isn't just tritanium, incidentally, unless things simplified considerably since the time of the Enterprise-D. (ST:TNG Tech Manual, standard issue office literature, and there is no "titanium" at all in the Enterprise's hull, TYVM ;-) - but there are several layers of tritanium). > PS: Magnetic boots are only a help if your learning curve is > ferromagnetic... I make you a deal, Terry... you _show_ me a learning curve, and we will see if it is ferromagnetic. :-) Grin, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Wed Jan 29 19:34:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA15832 for hackers-outgoing; Wed, 29 Jan 1997 19:34:32 -0800 (PST) Received: from limbic.gc2.kloepfer.org (limbic.gc2.kloepfer.org [206.225.39.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA15826 for ; Wed, 29 Jan 1997 19:34:28 -0800 (PST) Received: (from gil@localhost) by limbic.gc2.kloepfer.org (8.8.5/8.8.5) id VAA07917 for freebsd-hackers@freebsd.org; Wed, 29 Jan 1997 21:34:26 -0600 (CST) Message-Id: <199701300334.VAA07917@limbic.gc2.kloepfer.org> Subject: Submitted UPS monitor software to PR system To: freebsd-hackers@freebsd.org Date: Wed, 29 Jan 1997 21:34:26 -0600 (CST) From: "Gil Kloepfer Jr." X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At Jordan's suggestion, I submitted my contribution (?) to the FreeBSD project of a Tripp Lite UPS monitor daemon to the PR system. The ID number is misc/2617 and contains a shar of the C code, Makefile, and manual page. This is really a first shot at a means of managing a UPS under FreeBSD (at least for me it is anyhow). I realize ideally it should be able to handle other UPS monitoring port specs, and be configurable as to its action. I'm more than willing to take on the responsibility for some of this. Unfortunately I don't have a lot of UPS monitoring port specs to work with. I developed this from scratch, even though I was aware of some linux work going on in this regard. It didn't appear from my reading that it did exactly what I wanted, and I didn't want to be discouraged from getting this done (I had a set of batteries melt along with frying my UPS not long ago). Basically I tested all the functions I could on the UPS itself, and created a simulator to test the those that would take too long (low battery). I can probably do the same for UPSs that use opto-isolators, relays, and LEDs for control...so to add new UPSs, I may be able to develop from the spec and have some nice soul test it. The shutdown mechanism is not as elegant as one may desire, but I felt that a "graceful" UPS shutdown was an alternative to pulling the plug while everything was running. Creating elaborate kernel code to perform this function may have been the literally "correct" way to do it, but it would have been highly hardware-dependent and horrible to maintain (as well as overkill under the circumstances). The cable involves some strange (ab)uses of the modem control signals and TxD from a serial port. It needs one resistor for pull-up wired between two pins. The cable is trivially made. Constructive feedback is welcome, of course. Hopefully this will be useful for someone. --- Gil Kloepfer gil@gc2.kloepfer.org http://www.gc2.kloepfer.org/ From owner-freebsd-hackers Wed Jan 29 19:53:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA16689 for hackers-outgoing; Wed, 29 Jan 1997 19:53:33 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA16684 for ; Wed, 29 Jan 1997 19:53:30 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id OAA26563; Thu, 30 Jan 1997 14:22:45 +1030 (CST) From: Michael Smith Message-Id: <199701300352.OAA26563@genesis.atrad.adelaide.edu.au> Subject: Re: Cases (was: Constructive Criticism) In-Reply-To: <199701300301.WAA09208@spoon.beta.com> from "Brian J. McGovern" at "Jan 29, 97 10:01:40 pm" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 14:22:44 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern stands accused of saying: > > > >This is called the "learning curve". There are two ways to climb it, for > >climb it you must if you want to do anything. > > > >1) Spend lots of time trying, asking questions, exercising your intelligence > > and patience. > >2) Give lots of money to someone else to have them force you through 1). > > I disagree with your two cases. As with any development decision, if > I can't justify the cost of undertaking the certain project, I won't > even begin it. Do you read Dilbert? If it weren't for your other comments, I would have to say that you were trained management. You need to lift your eyes a little and look at the longer-term benefits of a given exercise. > In the case of #1, its a time/learning curve that is > out of reach. By the time I figure it out for release x.y.z, its > usually changed. You're joking, right? The driver integration model has changed _once_ in something like ten years, and that change is simple, straightforward, and if you asked could be explained in less than a screenfull of words. > Ok, so one bad example ;p But, still, I've noted a good chunk of the > technical docs in the handbook always seems to be a release out of > date. Again, perhaps its something that can be undertaken. Writing documentation is lots of work. Tina and her ilk are a rare resource. > >If you can't work out how device drivers are integrated, I seriously > >doubt that you're up to writing one in the first place. 8( > > > > Ah, again, a circle effect. You'll never get good till you've chewed on a > handful of them. Correct. > And you'll never start on your first till you think you > can do it. *This* is your failing point, and it is annoyingly common. Given "you can never know until you try", your attitude means that you will _never_learn_ because without an ironclad guarantee of success, you'll never make the effort. An attitude like that is a guarantee of failure. > A lack of documentation makes it infinately more difficult. I would assert that the mailing lists are a form of interactive documentation that transcends anything that can be statically committed to any media. > But, like my original > message said, if I _am_ able to learn something useful, and return an equal > amount, or more time on development than what you took to teach me, its a > win all around. Your offerings would be gratefully accepted, believe you me 8) > Unfortunately, my time to tinker with such things is limited. I've > banged out some test code in the past (simple device reads, writes, > etc), but don't have a weekend to figure out how to stick it in the > kernel. And until I know I have a weekend to make a concerted > effort, I won't bother anyone with the newbie question. Why ask the > question if the answer would be useless? How can you make an assessment like that when you claim ignorance? Perhaps integrating your driver is a 5-minute task? Will you let your timidity hold you back? > When the time comes, I'll ask. However, I'd also like to keep the > number of questions I have to ask to a bare minimum. I'd rather have > it be "I'm doing XYZPDQ, and it blows up in such and such a way. Can > any one see any obvious problem", than "What do I do now?". I think "I have some device driver routines, how do I glue them together so that the kernel can use them" is a pretty straightforward question. I could (and would happily) answer that in a fashion that you should be able to do something with directly. > For me to grow beyond copying an example in the book, I really need > to understand _why_ I'm doing what i'm doing. Why not ask them then? The authors of the code you're fretting about (or at the very least people that understand it) are all around, and most are easily approachable. > Reading someone else's chunk of code doesn't tell you WHY they > implemented something a certain way... Good commenting would, but if > all the code in the world had sufficient commenting, we wouldn't be > having this discussion :) Reading the code in its larger context will often make obvious why something was implemented in a particular fashion. Often "expediency" is the only succinct answer 8) > Tomorrow, whilest I'm at work, I will write some code for a pseudo-device > driver I wish to call foo. I will write routines for fooinit, fooread, > and foowrite. According to the documentation I've read, I should be able to > leave the open and close routines set to (I guess NULL ?) nothing. fooinit > will also exist, but will just contain a printf to announce the presence of > the pseudo-driver. The driver will be a character driver, with major number > of 20. Minor number will represent buffer numbers, each buffer will be 1K > in length. Writes to a buffer will set the string. Reads will return it (if > the full length is specified). Optionally, I'll use the offset attributes > to allow multiple reads and writes. Lastly, all of these routines will > be in a file called foodev.c. Ok, sounds like a plan. > Now, based on my reading, and what I've seen in some of the drivers > I _have_ looked at, I believe that I'll have to set a cdevsw structure up, > and it looks like a struct isa_driver. I also see probe() and attach() > routines that I have not seen documentation on before in the books I have > read. I see devfs support thrown in... Looks kinky. Probably will need help > there eventually... Ok. > Anyhow, want to lecture me on what some of these things are, whats required, > whats optional, and how my stuff will fit in the cosmic scheme of things? Sure; I'll keep it cc'd to -hackers so that others can snipe at my ignorance, and if you save all of these messages, you should have an excellent reference on which to base your documentation. I'll restrict myself to ISA drivers, as these are where I'm most familiar. PCI drivers are generally similar, but have an easier time in some regards. I'll use your 'foo' driver as an example. ==== Driver initialisation is seperated into two parts, known as 'probe' and 'attach'. The purpose of the 'probe' routine is to ascertain whether the hardware is present, and optionally determine its configuration. Probe/attach for ISA device drivers is triggered by the presence of a non-static isa_driver structure in the driver; at least the first three fields should be initialised, with the probe and attach routines and the name of the driver : struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; The 'fooprobe' function is called during startup to determine whether the device is present or not. It should return zero if the probe for the hardware failed, or the size of the I/O space occupied by the device if the probe succeeded. static int fooprobe(struct isa_device *dev) It is legitimate to alter the contents of the fields in the isa_device structure, if new values are determined by probing for the hardware. Note that the id_irq field is a bitmask, not a numeric value. The probe routine should not emit any text unless it comes up against something particularly alarming. The probe routine is called once per instance of the driver in the configuration file. Attach is called, again once per instance of the driver in the config, when the device has been successfully probed and does not conflict. static int fooattach(struct isa_device *dev) The attach routine should build any local data structures required for management of the device. It is traditional for the attach routine to emit a line like : foo0: Snarklewacker 200, rotating Floib, no BoBoBoBoB. The startup code will have already emitted a line like : foo0 at 0x10-20 irq 1 iomem 0x12345 on isa Once internal state for the driver has been established, you add an entry to the device switch for the driver. In the case of a character device, the following fragment is normally used : dev = makedev(CDEV_MAJOR,0); cdevsw_add(&dev,&foo_cdevsw,NULL); Where CDEV_MAJOR is the major device number assigned to the driver (normally #defined somewhere obvious). A typical cdevsw initialisation might look like : static d_open_t fooopen; static d_close_t fooclose; static d_read_t fooread; static d_write_t foowrite; static d_ioctl_t fooioctl; static d_select_t fooselect; #define CDEV_MAJOR 20 static struct cdevsw foo_cdevsw = { fooopen, fooclose, fooread, foowrite, fooioctl, nullstop, nullreset, nodevtotty, fooselect, nommap, NULL, driver_name, NULL, -1 }; Note that some of the placeholders are "no*" and some are "null*" - I think that this is laziness on someone's part 8( To create a devfs device node : sc->devfs_token = devfs_add_devsw(&foo_cdevsw, unit, DEV_CHR, UID_ROOT, GID_WHEEL, 0660, "foo%d", unit); This returns a token which is saved (here) in the devfs_token field in the device's softc structure (the per-device state structure). The cdevsw structure defines the driver's entrypoints, unit is the unit number associated with the device node (you can encode major/minor data here if you wish), DEV_CHR indicates a character device node, the UID_ROOT, GID_WHEEL and 0660 entries set the ownership/permissions on the new device node, and the remaining arguments are printf-style, with a format string and parameters for the format string which yield the name of the device node. You can call this several times to create multiple nodes for a single instance of the driver. ==== That should get you probing and attached; keep us in touch! > -Brian -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 19:54:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA16765 for hackers-outgoing; Wed, 29 Jan 1997 19:54:38 -0800 (PST) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA16759 for ; Wed, 29 Jan 1997 19:54:35 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.8.3/8.8.3) with SMTP id VAA21433; Wed, 29 Jan 1997 21:54:27 -0600 (CST) Received: from localhost by solaria.sol.net (8.5/8.5) id VAA00595; Wed, 29 Jan 1997 21:33:48 -0600 From: Joe Greco Message-Id: <199701300333.VAA00595@solaria.sol.net> Subject: Re: Network interfaces: removal of. To: louie@TransSys.COM (Louis A. Mamakos) Date: Wed, 29 Jan 97 21:33:45 CST Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199701280402.XAA03991@whizzo.transsys.com> from "Louis A. Mamakos" at Jan 27, 97 11:02:20 pm X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > does anyone have any ideas on this? > > One idea: add a new message for the routing socket which can notify > routing daemons that you want to delete an interface (or, like it or not, > it's gone now). Hopefully they can then arrange to have active references > to the interface be removed. > > I recall another system which had a the ability to "delete" a network > interface. What it really did was cheat: it essentially overwrote the > interface name, and shoved the data structure off into a corner. It was > still around, though, so that if there was some errant reference to it, > nothing "bad" would happen. > > Clearly, this is just a hack. However, it seems to work "well enough", > so from a pragmatic perspective, you can't dismiss it completely. > > While I'm sure that the modules that reference interfaces are finite, > there's nothing to allocate references to them. This would require a > level of discipline unknown to the BSD net code. Hell, you might just > as well wish for locks on the data structures to make the code SMP safe :-) It's (definitely!) not BSD, but Solaris has some support for this. Their interfaces are done on the fly.. # ifconfig le1 ifconfig: SIOCGIFFLAGS: le1: no such interface # ifconfig le1 plumb # ifconfig le1 10.1.1.1 # ifconfig le1 le1: flags=842 mtu 1500 inet 10.1.1.1 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:1a:f5:1e # ifconfig le1 up # route add net 192.168.0.0 10.1.2.3 1 add net 192.168.0.0: gateway 10.1.2.3 # ifconfig le1 le1: flags=843 mtu 1500 inet 10.1.1.1 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:1a:f5:1e # netstat -rn|grep 192.168 192.168.0.0 10.1.2.3 UG 0 0 # ifconfig le1 down # netstat -rn|grep 192.168 192.168.0.0 10.1.2.3 UG 0 0 # ifconfig le1 unplumb # ifconfig le1 ifconfig: SIOCGIFFLAGS: le1: no such interface # netstat -rn|grep 192.168 192.168.0.0 10.1.2.3 UG 0 0 # Not ideal... but something. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Wed Jan 29 20:00:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17107 for hackers-outgoing; Wed, 29 Jan 1997 20:00:11 -0800 (PST) Received: from weenix.guru.org (unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17057 for ; Wed, 29 Jan 1997 20:00:06 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id WAA25499 for hackers@freebsd.org; Wed, 29 Jan 1997 22:59:33 -0500 (EST) Date: Wed, 29 Jan 1997 22:59:33 -0500 (EST) From: Keith Mitchell Message-Id: <199701300359.WAA25499@weenix.guru.org> To: hackers@freebsd.org Subject: Re: lpd - remote printing with an output filter X-Newsreader: TIN [UNIX 1.3 unoff BETA release 970124] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Has anyone got any problems with me making this work ? It's always > irritated me ! It consists of two one-liners to printjob.c. No, but I would like to see it happen. I have several printers hanging off a HP JetDirect EX print server and there is no way to run an output filter on them. Consequently, the user must KNOW not to just blindly print to it. (sigh). From owner-freebsd-hackers Wed Jan 29 20:13:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17724 for hackers-outgoing; Wed, 29 Jan 1997 20:13:26 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA17718 for ; Wed, 29 Jan 1997 20:13:23 -0800 (PST) Received: from spoon.beta.com ([199.165.180.33]) by mail.crl.com with SMTP id AA21297 (5.65c/IDA-1.5 for ); Wed, 29 Jan 1997 20:12:50 -0800 Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id XAA09417; Wed, 29 Jan 1997 23:08:34 -0500 (EST) Message-Id: <199701300408.XAA09417@spoon.beta.com> To: Mark Mayo Cc: Michael Smith , "Brian J. McGovern" , hackers@freebsd.org, mcgovern@spoon.beta.com Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: Your message of "Wed, 29 Jan 1997 22:05:29 EST." Date: Wed, 29 Jan 1997 23:08:33 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark, I've seen at LEAST two titles called "Writing a Unix device driver". One is good, as it tends to take things piece by piece, rather than dumping the whole picture on you. The other was cryptic, and just difficult to read. IF you'd like I'd beam you the author's name of the one I particularly liked. Unfortunately, I've yet to find a good one that really has to do with 4.4ish stuff. Most deal with SCO. But... -Brian From owner-freebsd-hackers Wed Jan 29 21:06:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA19846 for hackers-outgoing; Wed, 29 Jan 1997 21:06:16 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA19832 for ; Wed, 29 Jan 1997 21:06:08 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id AAA09649; Thu, 30 Jan 1997 00:05:43 -0500 (EST) Message-Id: <199701300505.AAA09649@spoon.beta.com> To: msmith@atrad.adelaide.edu.au cc: hackers@freebsd.org Subject: The continuting email... Date: Thu, 30 Jan 1997 00:05:43 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Do you read Dilbert? If it weren't for your other comments, I would have >to say that you were trained management. You need to lift your eyes a >little and look at the longer-term benefits of a given exercise. There are long term benefits, and there are short term realities. The long term benefits is that I may get good at this. The short term reality is that I have a certain length of time to aquire the information to do this. If the time required is excessive, or unrealistic, it makes a better choice to either hire someone to do it, or wait for someone else to do it, and put my energies where not only will I have efficiency, but I'll have success. Perhaps it is being "trained management", but you'll notice that the number of learned people working with FreeBSD that could develop a userful driver is nearly nil compared to the number of people running FreeBSD. Why is that? They all put their resources where it will gain them the most. Many people, like myself, have limited time, and a lot to do. >> Ok, so one bad example ;p But, still, I've noted a good chunk of the >> technical docs in the handbook always seems to be a release out of >> date. Again, perhaps its something that can be undertaken. >Writing documentation is lots of work. Tina and her ilk are a rare >resource. I'd be more than happy to hammer out documentation. I do it quite frequently. However, doing documentation requires a.) Coordination with the group as a whole, b.) A _serious_ understanding of what you're writing about (unless you opt to sound like you're clueless, or be wrong, etc), and c.) understanding of the mechanism to write the documentation. Right now, I would say that I fail in all cases. a.) is covered by the fact I don't deal with the developers regularly. I should, and I try, but it doesn't happen. b.) This is optional, based on what I'd try to document. Workings of a service, like tftpd? Sure, no problem. Give me two hours on a Saturday... Working of a device driver interface? Yeah, right... Give me a year. c.) Some one was nice enough to point out the appropriate man pages for writing man pages. Given a weekend of tinkering with it, I'm sure I could figure it out. But, theres 8-10 hours right there. Is documentation what I'd be _most_ useful at? >> And you'll never start on your first till you think you >> can do it. >*This* is your failing point, and it is annoyingly common. Given "you can >never know until you try", your attitude means that you will _never_learn_ >because without an ironclad guarantee of success, you'll never make the >effort. An attitude like that is a guarantee of failure. It depends on your definition of ironclad guarantee of success. When I start any project at work, I have a fairly good idea of what I'm going to do, and how to get there. So long as I maintain at least one path to reach my goal, I will continue to plug away at it. If I don't have one, and a reasonable amount of investigation doesn't give me a new path. The project goes on "hold" indefinately until I can find a new path to pursue. Also, in lieu of another comment earlier that I wanted to drop over the sake of arguement (but it applies here, so I'll bring it back up), I did once (about 2 weeks ago) post about getting my ficticious 'foo' driver installed in the kernel to the hackers list. I got one (1) reply from someone with a handbook section to check out. I downloaded it, printed it, and followed the steps. Didn't work. Queried hackers as to why it didn't work. I think it was Jordan who replied that the section in question (excuse my fuzziness on the _exact_ answer, but its been awhile, and I didn't pay much attention beyond the basic meaning of the message) was for FreeBSD versions through 2.1.5 or 2.1.6. As I was running 2.2-BETA on all my machines (trying, in my minimalist way to find any bugs for the pending release - of which I've submitted 3-4 minor ones to date [so I don't bang on the machines as hard as some..]), the handbook section became useless. As no one else answered that and future messages on the subject, and the docs were out of date, I no longer had a path. Hence, it went on hold till I saw enough people mentioning the things I saw, and I summarized it in an opinion message.... >> A lack of documentation makes it infinately more difficult. >I would assert that the mailing lists are a form of interactive >documentation that transcends anything that can be statically >committed to any media. As per the message above, it doesn't always work. Timing becomes critical. People become critical. If your timing is off (someone takes a day off, or mail is lost, etc), or the one person who has a good answer isn't available, it doesn't work. However, if that person was to do a brain-dump on to a white paper. Not even documentation per say, but their thoughts on the hows, whys, and wheres, it would at least provide a static source for some place to start. >> But, like my original >> message said, if I _am_ able to learn something useful, and return an equal >> amount, or more time on development than what you took to teach me, its a >> win all around. >Your offerings would be gratefully accepted, believe you me 8) As I would like to offer. Again, I really don't want to argue with anyone. My merest dialog (originally) was to stress that static, written, up to date documentation would allow people (such as myself) to learn these things at their own pace, in their own time. Then, once their ready, their newly found skill sets would be available to assist the development goals. However, I see it taking an initial capital of properly trained people to provide static documentation for this purpose. >> Unfortunately, my time to tinker with such things is limited. I've >> banged out some test code in the past (simple device reads, writes, >> etc), but don't have a weekend to figure out how to stick it in the >> kernel. And until I know I have a weekend to make a concerted >> effort, I won't bother anyone with the newbie question. Why ask the >> question if the answer would be useless? >How can you make an assessment like that when you claim ignorance? >Perhaps integrating your driver is a 5-minute task? Will you let your >timidity hold you back? Because I have already sunk over a week (80 hours) in to just reading up on how to properly write a driver. I have looked at other drivers, and I can usually anticipate my learning curve. If it were a five minute task, please, surprise me. However, I think 10 hours over a weekend that I can dedicate to it would really be a more realistic number. I'll probably need more in the long run. And no, its not timidity thats holding me back. Its my desire to bring completion to the things I start. I despise not finishing things on schedule (management again?) >> When the time comes, I'll ask. However, I'd also like to keep the >> number of questions I have to ask to a bare minimum. I'd rather have >> it be "I'm doing XYZPDQ, and it blows up in such and such a way. Can >> any one see any obvious problem", than "What do I do now?". >I think "I have some device driver routines, how do I glue them together >so that the kernel can use them" is a pretty straightforward question. >I could (and would happily) answer that in a fashion that you should be >able to do something with directly. But, you're also making two assumptions. One, that I am in fact ready, and two, that I would like the answer. That was not the point of my original posting. The point of my original posting was that via good docs, a.) The question would (should?) never have to be asked in the first place (siting driver writing as an example), b.) the system, overall, would be better documented, and c.) It provides 'newbies' with a unified set of documentation for how to go about a task, so that the learning curve will be as greatly reduced as possible (read: dump the tinkering and show me how to do something useful). >> For me to grow beyond copying an example in the book, I really need >> to understand _why_ I'm doing what i'm doing. >Why not ask them then? The authors of the code you're fretting about >(or at the very least people that understand it) are all around, and most >are easily approachable. I don't disagree with this. However, it comes back to time, timing, effort, and energy. Time, as in I only have limited time, and if I spend the time I have trying to find the right person to talk to, wait for replies, etc, the time I have to actually WORK on something is gone, and we all have to wait till the next cycle (which, by then, would cause me to forget the answer anyways :) ). Timing, as in if the "right" person isn't available, whether you even get an answer becomes shaky at best. Effort, as in which is easier? Asking all the right questions, or reading up to get a base understanding, and THEN asking about what you don't get. Energy, as in see "Time". Also, I oft feel (as others do), that if I were high guru on a mountain, and someone came to me and asked "How do I program in C?", the answer would not be a 30 hour class. It would be "Why not get a book on it". Likewise, a simple question stands a far better chance of being answered (correctly), than a "I don't have a clue, save me" question. That is the type of question that people who expect answers on silver platters will ask. It is the type of question that, personally, I don't think should ever need to be asked _provided there is an alternate source for the information_. >> Reading someone else's chunk of code doesn't tell you WHY they >> implemented something a certain way... Good commenting would, but if >> all the code in the world had sufficient commenting, we wouldn't be > having this discussion :) >Reading the code in its larger context will often make obvious why something >was implemented in a particular fashion. Often "expediency" is the only >succinct answer 8) See "time" (above) >> Tomorrow, whilest I'm at work, I will write some code for a pseudo-device >> driver I wish to call foo. I will write routines for fooinit, fooread, >> and foowrite. According to the documentation I've read, I should be able to >> leave the open and close routines set to (I guess NULL ?) nothing. fooinit >> will also exist, but will just contain a printf to announce the presence of >> the pseudo-driver. The driver will be a character driver, with major number >> of 20. Minor number will represent buffer numbers, each buffer will be 1K >> in length. Writes to a buffer will set the string. Reads will return it (if >> the full length is specified). Optionally, I'll use the offset attributes >> to allow multiple reads and writes. Lastly, all of these routines will >> be in a file called foodev.c. >Ok, sounds like a plan. >> Now, based on my reading, and what I've seen in some of the drivers >> I _have_ looked at, I believe that I'll have to set a cdevsw structure up, >> and it looks like a struct isa_driver. I also see probe() and attach() >> routines that I have not seen documentation on before in the books I have >> read. I see devfs support thrown in... Looks kinky. Probably will need help >> there eventually... >Ok. >> Anyhow, want to lecture me on what some of these things are, whats required, >> whats optional, and how my stuff will fit in the cosmic scheme of things? >Sure; I'll keep it cc'd to -hackers so that others can snipe at my ignorance, >and if you save all of these messages, you should have an excellent reference >on which to base your documentation. >I'll restrict myself to ISA drivers, as these are where I'm most familiar. >PCI drivers are generally similar, but have an easier time in some >regards. >I'll use your 'foo' driver as an example. ==== >Driver initialisation is seperated into two parts, known as 'probe' and >'attach'. The purpose of the 'probe' routine is to ascertain whether >the hardware is present, and optionally determine its configuration. >Probe/attach for ISA device drivers is triggered by the presence of a >non-static isa_driver structure in the driver; at least the first three >fields should be initialised, with the probe and attach routines and the >name of the driver : Ok. I know the what. Any particular reason it has to be non-static? I assume to cause it to blow up if there is another driver with the same name, but, am I correct? Secondly, what are the fields after the first 3? Also, I did a grep for "isa_driver" in /usr/include via a find (ie - grep "isa_driver" `find .` to no avail. Which header should I include? (BTW: I noted to jordan that the ssys.* set in -BETA had trailing garbage at the end. I don't know if it means the set is corrupt and I'm missing something) >struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; >The 'fooprobe' function is called during startup to determine whether >the device is present or not. It should return zero if the probe >for the hardware failed, or the size of the I/O space occupied by >the device if the probe succeeded. Please define "size of the I/O space". To me, this can mean many things, probably all of which are wrong. Is it the number of ports a device uses? Amount of memory (shared or otherwise)? And how about our simulated pseudo device, which won't control hardware, but might have a few K in buffers? >static int >fooprobe(struct isa_device *dev) >It is legitimate to alter the contents of the fields in the isa_device >structure, if new values are determined by probing for the hardware. >Note that the id_irq field is a bitmask, not a numeric value. The >probe routine should not emit any text unless it comes up against >something particularly alarming. Ok. id_irq is a bitmask. I'll have to save my other questions once I can find struct isa_device. I am currently assuming that this contains the info in the kernel config file when called. Same for a pseudo-device? > >The probe routine is called once per instance of the driver in the >configuration file. > >Attach is called, again once per instance of the driver in the config, >when the device has been successfully probed and does not conflict. Does the driver make the call as to the conflict? Or does the system look at the struct isa_device, and if a conflict occurs, not call the probe and attach routines? > >static int >fooattach(struct isa_device *dev) > >The attach routine should build any local data structures required for >management of the device. It is traditional for the attach routine to >emit a line like : > >foo0: Snarklewacker 200, rotating Floib, no BoBoBoBoB. > >The startup code will have already emitted a line like : > >foo0 at 0x10-20 irq 1 iomem 0x12345 on isa > Ok. This smells like the init routines I'm used to seeing. >Once internal state for the driver has been established, you add an entry >to the device switch for the driver. In the case of a character device, >the following fragment is normally used : > > dev = makedev(CDEV_MAJOR,0); > cdevsw_add(&dev,&foo_cdevsw,NULL); > Ok. Looks clear enough. I'm assuming we're still in attach here... I'm also assuming that block devices would call bdevsw_add (wrong name i think, but I think I get the idea). How about STREAMS types or tty type devices that are linked off through a line protocol? Once I'm done with driver foo, I'd like to start work on an ISA multi-modem card thats being prepped by Cisco for inclusion in to their routers (the modem modules, not the ISA cards). I'll need to run SLIP and PPP across the link. the _documentation I have_ says I'll have to make it a little more special than a "normal" character device... >Where CDEV_MAJOR is the major device number assigned to the driver >(normally #defined somewhere obvious). > >A typical cdevsw initialisation might look like : > >static d_open_t fooopen; >static d_close_t fooclose; >static d_read_t fooread; >static d_write_t foowrite; >static d_ioctl_t fooioctl; >static d_select_t fooselect; > >#define CDEV_MAJOR 20 >static struct cdevsw foo_cdevsw = >{ > fooopen, fooclose, fooread, foowrite, > fooioctl, nullstop, nullreset, nodevtotty, > fooselect, nommap, NULL, driver_name, > NULL, -1 >}; > Ok. Some of it makes sense. Is there a blank generic one that gives the appropriate order? For instance, I see nullstop and nullreset. There should also be a poll routine in there some where? Is it a NULL? a no? a -1? >Note that some of the placeholders are "no*" and some are "null*" - I >think that this is laziness on someone's part 8( Again, see the note above. Docs on what they "should be" could help fix this :) > >To create a devfs device node : > > sc->devfs_token = devfs_add_devsw(&foo_cdevsw, unit, > DEV_CHR, UID_ROOT, GID_WHEEL, > 0660, "foo%d", unit); > >This returns a token which is saved (here) in the devfs_token field in >the device's softc structure (the per-device state structure). The >cdevsw structure defines the driver's entrypoints, unit is the unit >number associated with the device node (you can encode major/minor >data here if you wish), DEV_CHR indicates a character device node, the >UID_ROOT, GID_WHEEL and 0660 entries set the ownership/permissions on >the new device node, and the remaining arguments are printf-style, >with a format string and parameters for the format string which yield >the name of the device node. > Ok. Is creating a devfs node mandatory? I know people would like to move to it, but when/is it required? What makes the decision if it is optional? >You can call this several times to create multiple nodes for a single >instance of the driver. Ok. I assume this means that it'll generate the same major numbers with appropriate minor numbers? > > > ==== > >That should get you probing and attached; keep us in touch! > >> -Brian > I appreciate the help to date. Again, my goal is not to argue, but to assist. Can't assist without knowledge, can't gain knowledge without documentation (I despise cultural learning. Too much pure data gets damaged in the retelling...) >- -- >]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ >]] Genesis Software genesis@gsoft.com.au [[ >]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ >]] realtime instrument control. (ph) +61-8-8267-3493 [[ >]] Unix hardware collector. "Where are your PEZ?" The Tick [[ > >------- End of Forwarded Message > > From owner-freebsd-hackers Wed Jan 29 21:17:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA20228 for hackers-outgoing; Wed, 29 Jan 1997 21:17:36 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA20223 for ; Wed, 29 Jan 1997 21:17:33 -0800 (PST) Received: (from jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) id VAA01442; Wed, 29 Jan 1997 21:17:32 -0800 (PST) To: freebsd-hackers@freebsd.org Path: not-for-mail From: jdp@polstra.com (John Polstra) Newsgroups: polstra.freebsd.hackers Subject: Re: Source code commits Date: 29 Jan 1997 21:17:31 -0800 Organization: Polstra & Co., Seattle, WA Lines: 8 Distribution: local Message-ID: <5cpatb$1cv@austin.polstra.com> References: <199701300043.AAA15572@awfulhak.demon.co.uk> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is it possible to commit source code locally, and get cvsup to send the > udpates back to freefall ? If not, would there be a lot of work involved ? No and yes, respectively. :-) -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Wed Jan 29 21:24:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA20518 for hackers-outgoing; Wed, 29 Jan 1997 21:24:53 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA20513 for ; Wed, 29 Jan 1997 21:24:49 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id PAA27382; Thu, 30 Jan 1997 15:54:35 +1030 (CST) From: Michael Smith Message-Id: <199701300524.PAA27382@genesis.atrad.adelaide.edu.au> Subject: Re: The continuting email... In-Reply-To: <199701300505.AAA09649@spoon.beta.com> from "Brian J. McGovern" at "Jan 30, 97 00:05:43 am" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 15:54:34 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (I'm splitting the thread here. This half really needs to die, the other half should survive) Brian J. McGovern stands accused of saying: > > where not only will I have efficiency, but I'll have > success. Perhaps it is being "trained management", but you'll notice > that the number of learned people working with FreeBSD that could > develop a userful driver is nearly nil compared to the number of > people running FreeBSD. Why is that? They all put their resources > where it will gain them the most. Many people, like myself, have > limited time, and a lot to do. I beg to differ on your demographic, but I take your point. > Also, in lieu of another comment earlier that I wanted to drop over > the sake of arguement (but it applies here, so I'll bring it back > up), I did once (about 2 weeks ago) post about getting my ficticious > 'foo' driver installed in the kernel to the hackers list. MHA; I honestly do not recall this, sorry. 8( > available to assist the development goals. However, I see it taking > an initial capital of properly trained people to provide static > documentation for this purpose. Ok; so I prod you to start doing, which will result in you asking questions, and causing people on this list to start producing the information that you require. Hopefully the net result is worthwhile. > bring completion to the things I start. I despise not finishing things on > schedule (management again?) Yes, but Ray Dolby would sympathise 8) (And I envy you; I'm a chronic non-finisher in my personal projects, as I always take on too much at once 8( ) > I appreciate the help to date. Again, my goal is not to argue, but to > assist. Can't assist without knowledge, can't gain knowledge without > documentation (I despise cultural learning. Too much pure data > gets damaged in the retelling...) Understood, and I appreciate your points. Let's drive. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 21:26:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA20612 for hackers-outgoing; Wed, 29 Jan 1997 21:26:42 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA20592 for ; Wed, 29 Jan 1997 21:26:37 -0800 (PST) Message-Id: <199701300526.VAA20592@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA090311978; Thu, 30 Jan 1997 16:26:18 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net (Charles Mott) Date: Thu, 30 Jan 1997 16:26:18 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Charles Mott" at Jan 29, 97 07:30:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Charles Mott, sie said: > > > > My syntax may have been a little unclear. It is just that I had never > > > heard of the TIS ... Gauntlet program. Is it just an FTP client, or > > > something more advanced? If source code is available, I think that some > > > may wish to update the code. > > > > Firewall product. > > > > The point is, it isn't Gauntlet or the Firewall Toolkit which is doing > > anything wrong, it is the "transparent proxy" which makes bad assumptions > > (although 99% of the time it gets away with them). > > > > Darren > > > > I've seen quite a bit of feedback from several continents on the software I > have written. In particular, any time I have made a mistake, I have > been *very* quickly informed by users. I have yet to see any complaints > from users about ftp handling. > > In any event, it would be unusual to have such a firewall behind the > packet aliasing software I have written. It would be interesting to see > whether the authors of the firewall product you mention were being > deliberately "difficult". Nobody was, just the Firewall-1/Linux implementations are imperfect. > Your comments are interesting, but your attitude is not constructive in > my view. This probably reflects my frustration of how difficult it is to implement properly. Darren From owner-freebsd-hackers Wed Jan 29 21:37:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA21231 for hackers-outgoing; Wed, 29 Jan 1997 21:37:57 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA21224 for ; Wed, 29 Jan 1997 21:37:54 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id VAA25715; Wed, 29 Jan 1997 21:35:49 -0800 (PST) Date: Wed, 29 Jan 1997 21:35:49 -0800 (PST) From: Chris Coleman To: "Brian J. McGovern" cc: Mark Mayo , Michael Smith , hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701300408.XAA09417@spoon.beta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alright, I have had enough. I work at Big Bend Community College. I have talked them into using FreeBSD as our campus Standard for Internet Resources. Mainly because of its reliability and availability. They also were very pleased with the tight-nit core team that puts out a reliable release every six months. Now it time for me to lend a hand. Im not that great a programmer, but I teach, and i like to write. So I am embarking on a project. I am taking this chatter about lack of documentation very seriously. Im Going to Write a Book. I am in the middle of setting up two FreeBSD machines and am documenting the things that i do as i go. I want to write a basic book that is from a user point of view. I spent six months struggling through the download and setup of my first FreeBSD box. I knew nothing about computers three years ago. I want to add to the project. This is a User Run Project. So I the User am going to do Somthing about it. Therefore, If you don't like the documentation, Write something. Even if it is just a well documented complaint. I will be accepting contributions, and criticizm and whatever helpful things you have to offer. So stop complaining about What doesn't work and What isnt documented, And do something. If anyone else is working on a title, or has anything partially started I would like to hear form them, so we can get organized and not duplicate each other work. I have put together a home page, and all my work will be open for review as I get it put together. Many thanks for all the Advice that you have given me. This list has been a livesaver many times. Chris Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html Death is life's way of telling you you're fired. From owner-freebsd-hackers Wed Jan 29 21:53:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA21740 for hackers-outgoing; Wed, 29 Jan 1997 21:53:21 -0800 (PST) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA21735 for ; Wed, 29 Jan 1997 21:53:18 -0800 (PST) Received: (from dec@localhost) by phoenix.its.rpi.edu (8.8.4/8.8.3) id AAA00562 for hackers@freebsd.org; Thu, 30 Jan 1997 00:53:35 -0500 (EST) Date: Thu, 30 Jan 1997 00:53:35 -0500 (EST) From: "David E. Cross" Message-Id: <199701300553.AAA00562@phoenix.its.rpi.edu> To: hackers@freebsd.org Subject: Motif 2.0.1 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have access to the sources to Motif 2.0.1 (under my university's site license)... However I have yet to successfully compile motif 2.0.1 on 2.1.6-RELEASE (or any version)... Is there anyone out there who has gotten it working, and could give me a few pointers? -- David Cross ACS Help Desk From owner-freebsd-hackers Wed Jan 29 21:54:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA21782 for hackers-outgoing; Wed, 29 Jan 1997 21:54:14 -0800 (PST) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA21777 for ; Wed, 29 Jan 1997 21:54:08 -0800 (PST) Received: (from dec@localhost) by phoenix.its.rpi.edu (8.8.4/8.8.3) id AAA00738 for hackers@freebsd.org; Thu, 30 Jan 1997 00:54:35 -0500 (EST) Date: Thu, 30 Jan 1997 00:54:35 -0500 (EST) From: "David E. Cross" Message-Id: <199701300554.AAA00738@phoenix.its.rpi.edu> To: hackers@freebsd.org Subject: Ensoniq SoundScape Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone gotten this card to work under FreeBSD? If so, could you give me a hand (I think I am close, just missing that one last step) -- David Cross ACS Help Desk From owner-freebsd-hackers Wed Jan 29 22:02:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA22121 for hackers-outgoing; Wed, 29 Jan 1997 22:02:01 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22113 for ; Wed, 29 Jan 1997 22:01:55 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id QAA27658; Thu, 30 Jan 1997 16:31:39 +1030 (CST) From: Michael Smith Message-Id: <199701300601.QAA27658@genesis.atrad.adelaide.edu.au> Subject: Device Drivers 101 In-Reply-To: <199701300505.AAA09649@spoon.beta.com> from "Brian J. McGovern" at "Jan 30, 97 00:05:43 am" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 16:31:38 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern stands accused of saying: > > >Driver initialisation is seperated into two parts, known as 'probe' and > >'attach'. The purpose of the 'probe' routine is to ascertain whether > >the hardware is present, and optionally determine its configuration. > > >Probe/attach for ISA device drivers is triggered by the presence of a > >non-static isa_driver structure in the driver; at least the first three > >fields should be initialised, with the probe and attach routines and the > >name of the driver : > > Ok. I know the what. Any particular reason it has to be non-static? I assume > to cause it to blow up if there is another driver with the same name, but, > am I correct? The structures are collated at link time into what is known as a 'linker set'. This results in a statically-initialised array of all of the isa_device structures which can be processed by the startup code. The structure has to be non-static so that it is visible to the linker. > Secondly, what are the fields after the first 3? There is only one other field at the moment : struct isa_driver { int (*probe) __P((struct isa_device *idp)); /* test whether device is present */ int (*attach) __P((struct isa_device *idp)); /* setup driver for a device */ char *name; /* device name */ int sensitive_hw; /* true if other probes confuse us */ } Drivers with sensitive_hw set to true are probed before others to avoid being confused by other probes to the same space. > Also, I did a grep for "isa_driver" in /usr/include via a find (ie - > grep "isa_driver" `find .` to no avail. Which header should I include? #include , found in /sys/i386/isa/. As a kernel-only header, it't not found under /usr/include. > >struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; > > >The 'fooprobe' function is called during startup to determine whether > >the device is present or not. It should return zero if the probe > >for the hardware failed, or the size of the I/O space occupied by > >the device if the probe succeeded. > > Please define "size of the I/O space". To me, this can mean many > things, probably all of which are wrong. Is it the number of ports a > device uses? Amount of memory (shared or otherwise)? And how about > our simulated pseudo device, which won't control hardware, but might > have a few K in buffers? The size of the range of I/O ports that the device occupies. This is, as has been observed elsewhere, a poor choice, as there are devices that occupy no I/O ports, and others that occupy several disjoint ranges. Pseudo-devices are handled differently. The 'vn' driver is a good place to look for a readable example (/sys/dev/vn/vn.c), but the basic strategy involves using the SYSINIT macro to register a startup function which calls the pseudo-device's init function, which in turn uses [cb]devsw_add and optionally devfs_add* to register the driver's existence. (For "normal" devices, the bus probe code for the bus to which the device belongs processes the linker set described above and calls the probe/attach pairs.) > >It is legitimate to alter the contents of the fields in the isa_device > >structure, if new values are determined by probing for the hardware. > >Note that the id_irq field is a bitmask, not a numeric value. The > >probe routine should not emit any text unless it comes up against > >something particularly alarming. > > Ok. id_irq is a bitmask. I'll have to save my other questions once I can > find struct isa_device. I am currently assuming that this contains the > info in the kernel config file when called. Same for a pseudo-device? Pseudo-devices don't get any config information. The isa_device structure is initialised by the config file data, yes. > >Attach is called, again once per instance of the driver in the config, > >when the device has been successfully probed and does not conflict. > Does the driver make the call as to the conflict? Or does the system look > at the struct isa_device, and if a conflict occurs, not call the probe > and attach routines? The bus code is responsible for deciding whether a driver is in conflict; drivers should ideally know nothing about the bus or other drivers. > >Once internal state for the driver has been established, you add an entry > >to the device switch for the driver. In the case of a character device, > >the following fragment is normally used : > > > > dev = makedev(CDEV_MAJOR,0); > > cdevsw_add(&dev,&foo_cdevsw,NULL); > > > > Ok. Looks clear enough. I'm assuming we're still in attach here... I'm > also assuming that block devices would call bdevsw_add (wrong name i think, > but I think I get the idea). The name is correct too 8) > How about STREAMS types or tty type devices that are linked off > through a line protocol? No STREAMS in the BSD kernel 8). Tty devices are character devices; there's extra state involved in interacting with the tty stack, which is logically layered on top of the character driver. This is a topic on which Bruce is best qualified to comment; I'm just going to refer to sio.c and translate what I read into English 8) > >Where CDEV_MAJOR is the major device number assigned to the driver > >(normally #defined somewhere obvious). > > > >A typical cdevsw initialisation might look like : > > > >static d_open_t fooopen; > >static d_close_t fooclose; > >static d_read_t fooread; > >static d_write_t foowrite; > >static d_ioctl_t fooioctl; > >static d_select_t fooselect; > > > >#define CDEV_MAJOR 20 > >static struct cdevsw foo_cdevsw = > >{ > > fooopen, fooclose, fooread, foowrite, > > fooioctl, nullstop, nullreset, nodevtotty, > > fooselect, nommap, NULL, driver_name, > > NULL, -1 > >}; > > > > Ok. Some of it makes sense. Is there a blank generic one that gives the > appropriate order? For instance, I see nullstop and nullreset. There should > also be a poll routine in there some where? Is it a NULL? a no? a -1? I don't believe that there's a blank. The structure and the blanks are listed in /sys/sys/conf.h. I should have been a little more thoughtful about the no vs. null comment : The no* versions return ENODEV, the null* versions always succeed but do nothing, the nx* versions return ENXIO (but are a bad idea according to the comment in sys/kern/subr_xxx.c where they are defined). BSD doesn't have a poll syscall; 'similar' functionality is afforded by select(2). > Ok. Is creating a devfs node mandatory? I know people would like to move to > it, but when/is it required? What makes the decision if it is optional? It's not mandatory, but if you don't put a call in to create it, someone else will 8) Normally devfs node creation is conditionalised on DEVFS. > >You can call this several times to create multiple nodes for a single > >instance of the driver. > > Ok. I assume this means that it'll generate the same major numbers with > appropriate minor numbers? Devfs doesn't really 'do' major and minor numbers; there's a logically direct translation from the named node to your switch entry and the unit number you supply when you create the node. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jan 29 22:13:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA22614 for hackers-outgoing; Wed, 29 Jan 1997 22:13:35 -0800 (PST) Received: from clipper.cs.kiev.ua (root@cs-demon.ua.net [193.124.48.251]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA22608 for ; Wed, 29 Jan 1997 22:13:28 -0800 (PST) Received: from dog.farm.org by clipper.cs.kiev.ua with uucp id m0vppdO-000t47C; Thu, 30 Jan 97 08:06 WET Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id VAA03336; Wed, 29 Jan 1997 21:59:48 -0800 (PST) Date: Wed, 29 Jan 1997 21:59:48 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199701300559.VAA03336@dog.farm.org> To: shocking@mailbox.uq.edu.au (Stephen Hocking) Cc: freebsd-hackers@freebsd.org Subject: Re: Setting MTU from userland ppp Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701290935.TAA01388@mailbox.uq.edu.au> you wrote: > How does one do this? If I try fiddling tun0 (ifconfig tun0 mtu 256) the > userland ppp get quite cranky and ppp net connections hang. set mtu 576 in /etc/ppp/ppp.conf works for me. This would specify your _tranimission_ size. To change it on the other side, change the other end's setup. Don't use 256 as your MTU. (violates the RFC) From owner-freebsd-hackers Wed Jan 29 22:14:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA22655 for hackers-outgoing; Wed, 29 Jan 1997 22:14:13 -0800 (PST) Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22648 for ; Wed, 29 Jan 1997 22:14:08 -0800 (PST) Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.8.4/8.7.3) id WAA01444 for hackers@freebsd.org; Wed, 29 Jan 1997 22:14:06 -0800 (PST) Date: Wed, 29 Jan 1997 22:14:06 -0800 (PST) From: Jaye Mathisen Message-Id: <199701300614.WAA01444@schizo.cdsnet.net> To: hackers@freebsd.org Subject: Bind 4.9.5-P1 on FreeBSD going bonkers... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm having an intermittent problem on my main nameserver for my ISP site. I'm using FreeBSD -current as of about August on a P5-90, 64MB's RAM. Basically the following tells the whole story. It works fine for a while, and then every request comes back as non-authoritative. They're not even always right. Restarting the nameserver fixes the problem for the short term. Note that this is not for my own domain, nor hosts that we serve, but just random places out there on the net. # nslookup www.stroud.com Server: ns.cdsnet.net Address: 204.118.244.2 Non-authoritative answer: Name: www.stroud.com Address: 204.107.221.239 # named.restart Jan 29 22:09:59 ns named[28248]: starting. named 4.9.5-P1 Tue Jan 21 16:09:56 PST 1997 root@ns.cdsnet.net:/usr/local/src/bind-4.9.5-P1/named Jan 29 22:10:00 ns named[28249]: Ready to answer queries. nslookup www.stroud.com Name Server Restarted # # Server: ns.cdsnet.net Address: 204.118.244.2 Name: www.stroud.com Addresses: 204.107.221.239, 199.35.192.140 This is a serious problem, since my squid server won't use any non-authoritative answers from the DNS, and so several thousand customers can't access the web. Restarting named *always* fixes it. Any ideas appreciated. From owner-freebsd-hackers Wed Jan 29 22:50:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA24136 for hackers-outgoing; Wed, 29 Jan 1997 22:50:43 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24127 for ; Wed, 29 Jan 1997 22:50:40 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id WAA12336; Wed, 29 Jan 1997 22:49:09 -0800 (PST) To: Terry Lambert cc: brian@awfulhak.demon.co.uk, hackers@freebsd.org Subject: Re: Source code commits In-reply-to: Your message of "Wed, 29 Jan 1997 19:16:01 MST." <199701300216.TAA20836@phaeton.artisoft.com> Date: Wed, 29 Jan 1997 22:49:09 -0800 Message-ID: <12332.854606949@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I suggested a sort of "write-through" validation/submission system for the CVS tree a year ago, where anyone could "commit" to the source tree but for those people who weren't actually authorized to commit directly, what would happen instead is that the diffs would be automagically sent to the person or persons actually responsible for the code in question, and they would review and optionally commit it. Unfortunately, someone still needs to add the feature and that someone is not me. :-) Jordan From owner-freebsd-hackers Thu Jan 30 00:08:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA27292 for hackers-outgoing; Thu, 30 Jan 1997 00:08:06 -0800 (PST) Received: from emout06.mail.aol.com (emout06.mx.aol.com [198.81.11.97]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27286 for ; Thu, 30 Jan 1997 00:08:01 -0800 (PST) From: StevenR362@aol.com Received: (from root@localhost) by emout06.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id DAA08082; Thu, 30 Jan 1997 03:07:30 -0500 (EST) Date: Thu, 30 Jan 1997 03:07:30 -0500 (EST) Message-ID: <970130001449_1313001207@emout06.mail.aol.com> To: sos@ravenock.cybercity.dk, jkh@time.cdrom.com cc: hackers@freebsd.org Subject: Re: 2.2-BETA Questions MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In a message dated 97-01-29 13:53:12 EST, sos@ravenock.cybercity.dk (Søren Schmidt) writes: > A couple of ideas: > > First see to it that the two IDE HD's are of different make, that should > get you a good deal of exitement. Eg Quantum & WD or WD & Maxtor or > WD & Seagate could give you some interesting funkiness, If you can get > hold of a Conner drive, the make of the other doesn't matter, you'll > have all the fun anyways), get a Promise or better a HongKong clone > of a IDE cache controller, and then a Sanyo 3 disk ATAPI cdrom. > Then a Elcheapo MAD or OPTI based soundcard, and a LPT port that > only can be set at the lpt3 (0x3bc) address, together with an early > Matrox MGA videocard. > > This should supply you all the fun you can bare for the foreseeable > future... Hmmm, parts of the above listing sound suspiciously like the hardware I sent you. :) Glad to see that you are having fun with it! Steve From owner-freebsd-hackers Thu Jan 30 00:26:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA27873 for hackers-outgoing; Thu, 30 Jan 1997 00:26:13 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27865 for ; Thu, 30 Jan 1997 00:26:11 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id BAA02591; Thu, 30 Jan 1997 01:26:03 -0700 (MST) Date: Thu, 30 Jan 1997 01:26:03 -0700 (MST) Message-Id: <199701300826.BAA02591@rocky.mt.sri.com> From: Nate Williams To: "Jordan K. Hubbard" Cc: Terry Lambert , brian@awfulhak.demon.co.uk, hackers@freebsd.org Subject: Re: Source code commits In-Reply-To: <12332.854606949@time.cdrom.com> References: <199701300216.TAA20836@phaeton.artisoft.com> <12332.854606949@time.cdrom.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I suggested a sort of "write-through" validation/submission system for > the CVS tree a year ago, where anyone could "commit" to the source > tree but for those people who weren't actually authorized to commit > directly, what would happen instead is that the diffs would be > automagically sent to the person or persons actually responsible for > the code in question, and they would review and optionally commit it. Aieee, why go for trivial solutions when we can do something much more useful (and difficult). I think it would be easier to rewrite CVS from scratch. :) Nate From owner-freebsd-hackers Thu Jan 30 00:48:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA28792 for hackers-outgoing; Thu, 30 Jan 1997 00:48:53 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA28785 for ; Thu, 30 Jan 1997 00:48:48 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id AAA06603; Thu, 30 Jan 1997 00:44:53 -0800 (PST) Date: Thu, 30 Jan 1997 00:43:08 -0800 (PST) From: Julian Elischer To: "Brian J. McGovern" cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: The continuting email... In-Reply-To: <199701300505.AAA09649@spoon.beta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Brian J. McGovern wrote: > >I'll restrict myself to ISA drivers, as these are where I'm most familiar. > >PCI drivers are generally similar, but have an easier time in some > >regards. PCI drivers register themselves differently, and the PCI code recognises the harware and calls the 'attach' routine directly.. the probe() routine is redunant (yay!) > > >I'll use your 'foo' driver as an example. > > ==== > > >Probe/attach for ISA device drivers is triggered by the presence of a > >non-static isa_driver structure in the driver; at least the first three > >fields should be initialised, with the probe and attach routines and the > >name of the driver : > > Ok. I know the what. Any particular reason it has to be non-static? I assume > to cause it to blow up if there is another driver with the same name, but, > am I correct? It has to be non static because the presence of the device in teh kernel configuration file will cause a reference to this structure to be made in a generated .c file which will be linked into the kernel. look in a kernel build directory (e.g. /sys/compile/GENERIC) for the file ioconf.c . This file is generated from the kernel config file. > > Secondly, what are the fields after the first 3? nope, that's all. In other BSD systems there are sometimes more > > Also, I did a grep for "isa_driver" in /usr/include via a find (ie - > grep "isa_driver" `find .` to no avail. Which header should I include? in /sys/i386/isa/isa_device.h > > >struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; > > >The 'fooprobe' function is called during startup to determine whether > >the device is present or not. It should return zero if the probe > >for the hardware failed, or the size of the I/O space occupied by > >the device if the probe succeeded. > > Please define "size of the I/O space". To me, this can mean many > things, probably all of which are wrong. Is it the number of ports a > device uses? Amount of memory (shared or otherwise)? And how about > our simulated pseudo device, which won't control hardware, but might > have a few K in buffers? The number of IO ports. you may fill in the size of the shared memory buffer in the isa_device structure (and other fields) as well > > >static int > >fooprobe(struct isa_device *dev) > > >It is legitimate to alter the contents of the fields in the isa_device > >structure, if new values are determined by probing for the hardware. > >Note that the id_irq field is a bitmask, not a numeric value. The > >probe routine should not emit any text unless it comes up against > >something particularly alarming. > > Ok. id_irq is a bitmask. I'll have to save my other questions once I can > find struct isa_device. I am currently assuming that this contains the > info in the kernel config file when called. Same for a pseudo-device? > > > > >The probe routine is called once per instance of the driver in the > >configuration file. > > > >Attach is called, again once per instance of the driver in the config, > >when the device has been successfully probed and does not conflict. > Does the driver make the call as to the conflict? Or does the system look > at the struct isa_device, and if a conflict occurs, not call the probe > and attach routines? The kernel makes the call after the probe has checked the values it was given and changed anything.. there is also (I seem to remember) a check BEFORE that as well > > > > >static int > >fooattach(struct isa_device *dev) > > > >The attach routine should build any local data structures required for > >management of the device. It is traditional for the attach routine to > >emit a line like : > > > >foo0: Snarklewacker 200, rotating Floib, no BoBoBoBoB. > > > >The startup code will have already emitted a line like : > > > >foo0 at 0x10-20 irq 1 iomem 0x12345 on isa > > > Ok. This smells like the init routines I'm used to seeing. > > > >Once internal state for the driver has been established, you add an entry > >to the device switch for the driver. In the case of a character device, > >the following fragment is normally used : > > > > dev = makedev(CDEV_MAJOR,0); > > cdevsw_add(&dev,&foo_cdevsw,NULL); > > > > Ok. Looks clear enough. I'm assuming we're still in attach here... Well, no..well, maybe.. this must be called exactly ONCE for each driver. It is possible that the attach code is called more than that so the code needs to have "have I been here before" protection.. In many drivers there is no hardware so no attach function os called. for an example look at mem.c This driver uses a facility in the kernel called SYSINIT. the SYSINIT facility allows an arbitrary function to specify where it is to be called in the boot sequence. Most drivers have a SYSINIT entry in addition to the attach/probe stuff. and pseudo-device driver MUST have one.. The SYSINIT entry usually specifies an 'init' routine that is run ONCE and ONLY ONCE (unless you have two SYSINIT entries). This is the IDEAL place to put the cdevs_add() calls as it will ensure that it happens once, before it's needed. Note also that in some ways the 'init' code is exactly what would need to be called to link in the driver had it been an LKM. when all drivers use SYSINIT and all cdevsw/bdevsw entries are dynamic and all interrupts are hooked in dynamically, then in effect you will be able to load device drivers as LKMs with no extra work. DEVFS gives you a view into this dynamic world. > I'm > also assuming that block devices would call bdevsw_add (wrong name i think, > but I think I get the idea). no, it IS bdevsw_add. notice that the bdevsw and cdevsw entries in your driver are THE ACTUAL ENTRIES. In FreeBSD the cdevsw and bdevsw tables are an array of POINTERS, and not an array of actual structs. The cdevsw_add() can be asked to CHOOSE a major number for you if you don't have one in mind. The number used is STORED IN THE cdevsw/bdevsw table entry, so examine it afterwards to discover what you got. They also have crosspointers, so given a cdev you can quickly find the related bdev and visa versa. (and also the driver 'name' for use in error messages etc. (e.g. 'foo') > How about STREAMS typesi BSD doesn't have streams, but if they did they would be initialised through the same SYSINIT method (see /sys/kernel.h) (SI_SUB_DRIVERS) as we don't have them I have no idea how you'd access them :) > or tty type devices that tty devices are just normal devices.. pty devices are pseudo devices and thus have a SYSINIT entry. > are linked off through a line protocol? Once I'm done with driver foo, > I'd like to start work on an ISA multi-modem card thats being prepped > by Cisco for inclusion in to their routers (the modem modules, not the ISA > cards). I'll need to run SLIP and PPP across the link. the _documentation I > have_ says I'll have to make it a little more special than a "normal" character > device... why? > > >Where CDEV_MAJOR is the major device number assigned to the driver > >(normally #defined somewhere obvious). Well Majors are assigned in /sys/i386/conf/majors (or something) but that file isn't actually used..it's just for reference. > > > >A typical cdevsw initialisation might look like : > > > >static d_open_t fooopen; > >static d_close_t fooclose; > >static d_read_t fooread; > >static d_write_t foowrite; > >static d_ioctl_t fooioctl; > >static d_select_t fooselect; > > > >#define CDEV_MAJOR 20 > >static struct cdevsw foo_cdevsw = > >{ > > fooopen, fooclose, fooread, foowrite, > > fooioctl, nullstop, nullreset, nodevtotty, > > fooselect, nommap, NULL, driver_name, > > NULL, -1 > >}; > > > > Ok. Some of it makes sense. Is there a blank generic one that gives the > appropriate order? For instance, I see nullstop and nullreset. There should > also be a poll routine in there some where? Is it a NULL? a no? a -1? Poll is sysV there is no poll in BSD.. the similar entry is the 'select' entry. > >Note that some of the placeholders are "no*" and some are "null*" - I > >think that this is laziness on someone's part 8( > Again, see the note above. Docs on what they "should be" could help fix this :) agreed.. it MIGHT be in conf.h > > > > >To create a devfs device node : > > > > sc->devfs_token = devfs_add_devsw(&foo_cdevsw, unit, > > DEV_CHR, UID_ROOT, GID_WHEEL, > > 0660, "foo%d", unit); > > > >This returns a token which is saved (here) in the devfs_token field in > >the device's softc structure (the per-device state structure). The reason for keeping the token is in case you want to removethe device. you do so by supplying the token you were given to the devfs_??? function (it's in the chapter 9 man page I believe) > >The > >cdevsw structure defines the driver's entrypoints, unit is the unit > >number associated with the device node (you can encode major/minor > >data here if you wish), DEV_CHR indicates a character device node, the > >UID_ROOT, GID_WHEEL and 0660 entries set the ownership/permissions on > >the new device node, and the remaining arguments are printf-style, > >with a format string and parameters for the format string which yield > >the name of the device node. > > > Ok. Is creating a devfs node mandatory? I know people would like to move to > it, but when/is it required? What makes the decision if it is optional? Well If I can get the bugs shaken out we should move to it asap :) > > >You can call this several times to create multiple nodes for a single > >instance of the driver. > > Ok. I assume this means that it'll generate the same major numbers with > appropriate minor numbers? no, YOU supply a differnt minor number and name each time.. this is effectively making entries in /dev for your driver. you can also make links for devices that want different names. how you interpret teh minor number is up to the driver so only the driver can decide how to allocate them.. > > I appreciate the help to date. Again, my goal is not to argue, but to > assist. Can't assist without knowledge, can't gain knowledge without > documentation (I despise cultural learning. Too much pure data > gets damaged in the retelling...) > julian (let me know more about this device and PPP I may have some info for you on that too) > From owner-freebsd-hackers Thu Jan 30 01:49:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA01670 for hackers-outgoing; Thu, 30 Jan 1997 01:49:02 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA01664 for ; Thu, 30 Jan 1997 01:48:59 -0800 (PST) Message-Id: <199701300948.BAA01664@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA152817733; Thu, 30 Jan 1997 20:48:53 +1100 From: Darren Reed Subject: Re: ipdivert & masqd To: cmott@srv.net Date: Thu, 30 Jan 1997 20:48:53 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: <199701300526.VAA20592@freefall.freebsd.org> from "Darren Reed" at Jan 30, 97 04:26:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Darren Reed, sie said: > > > > The point is, it isn't Gauntlet or the Firewall Toolkit which is doing > > > anything wrong, it is the "transparent proxy" which makes bad assumptions > > > (although 99% of the time it gets away with them). > > Your comments are interesting, but your attitude is not constructive in > > my view. > > This probably reflects my frustration of how difficult it is to > implement properly. And more to the point, ipmasqd/ipdivertd are in a good position to do it properly so some effort should be made to see what can be done to create a solution that overcomes deficincies in other existing systems. Wasting this oppotunity doesn't seem very sensible (to me). IMHO, some effort should be made to attempt to "do it properly". Maybe the "simpler" solutions could be imlpemented but they should be done so only with a clear understanding that its a temporary solution and work is being done on fixing it. (Is that a bit more constructive ?) Darren From owner-freebsd-hackers Thu Jan 30 02:07:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA02207 for hackers-outgoing; Thu, 30 Jan 1997 02:07:49 -0800 (PST) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA02202 for ; Thu, 30 Jan 1997 02:07:40 -0800 (PST) Received: from dibble.utell.net (dibble.utell.net [97.3.0.10]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id KAA29835; Thu, 30 Jan 1997 10:07:30 GMT Message-Id: <199701301007.KAA29835@ui-gate.utell.co.uk> From: "Brian Somers" To: Cc: Subject: Re: PR2347 - recursive malloc() in ppp Date: Thu, 30 Jan 1997 10:02:46 -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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Brian, > > I didn't mean to jump into the middle of your mail conversion > related to this recursive malloc. Forgive me if I do cause > any problems here. > > I modified the original 2.0.5 code for a local ISP who > used FreeBSD as their main engines and made it work reliably. > . But after the ISP upgraded the code to 2.1.5 and I still noticed > that there are a few problems that were not fixed properly. One of > the problems that I noticed was relatively new to the ppp code. > > Sometimes when the line is dropped, ppp just locks up > and the tail -f /var/log/ppp.log stops to show any more traces. > netstat -m shows that the mbuf usage is relatively reasonable. > There is no way that I can get out of it. I put a data scope on > the line and noticed that ppp did not respond to any ppp command > from the peer side. This system is fully loaded with ip-filter running > NAT and RDR, caching proxy, sockd, netcat, etc. We have ruled out > everything except ppp because when we changed to sppp, the problem > went away. The only way to get out of it is to kill -9. It works > fine after it is restarted it again. > > Allow me to ask you if your patch related to the problem > mentioned above. If it does, would you please send me the patch > . > > Many thanks. > > Fran I'm not sure what your problem might have been, but lots of changes have been done to ppp since then. You can pick up the current sources from ftp://ftp.freebsd.org:/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ppp if you want to have a look at the "current" version, but I don't think it'll compile on 2.1*. If you're interested in *just* the patches, have a look on http://www.freebsd.org/~brian. -- Brian Don't _EVER_ lose your sense of humour From owner-freebsd-hackers Thu Jan 30 03:04:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA04669 for hackers-outgoing; Thu, 30 Jan 1997 03:04:47 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA04663 for ; Thu, 30 Jan 1997 03:04:41 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Thu, 30 Jan 97 12:04 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for Freebsd-hackers@freebsd.org id ; Thu, 30 Jan 97 12:04 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA20685; Thu, 30 Jan 97 11:10:09 +0100 Date: Thu, 30 Jan 97 11:10:09 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9701301010.AA20685@wavehh.hanse.de> To: julian@whistle.COM Cc: Freebsd-hackers@freebsd.org, jason@idiom.com Subject: Re: [Fwd: freebsd performance.] Newsgroups: hanse-ml.freebsd.hackers References: <32EFD2E2.167EB0E7@whistle.com> Reply-To: cracauer@wavehh.hanse.de Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From: Jason Venner >The posix regex library is VERY VERY slow. >I have a program that uses a large regex to parse some input. >I have a version in perl and a version in C++ using the freebsd posix >regex library. >The perl version is 100X faster that the C++ version. >gprof on the C++ version shows 99% of the spend in: > 91.53 46.17 46.17 1152366 0.04 0.04 lstep > 6.52 49.46 3.29 98497 0.03 0.47 lslow Adding to the explanations about different kinds of regular expressions by Patrick Giagnocavo, I'd like to note that I found *BSD's regex support to be quite fast. I benchmarked Spencers code against various versions of GNU regex stuff and found Spencers library to be about 30% faster than the GNU stuff from GNU-sed-2.x and that the GNU sed-3.00/regex-1.0 stuff didn't even pass my benchmarks without coredumping. I didn't take perl's library into account because I found no easy way to use it from C. I'd say it is a valid goal to make perl's regex library availiable as a C library (maybe someone already did). For different regex syntax anyway and maybe for performance also. I'd like to second the request for a simplified test case that shows the difference so we can investigate the problem. Jason, do you copy, can you provide a regex and a testfile? I tend to say some easy-to-solve thing must have been triggered. After all, perl's regex code is derived from Spencer's, too. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin_Cracauer@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin From owner-freebsd-hackers Thu Jan 30 03:05:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA04720 for hackers-outgoing; Thu, 30 Jan 1997 03:05:10 -0800 (PST) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04713 for ; Thu, 30 Jan 1997 03:05:04 -0800 (PST) Received: from dibble.utell.net (dibble.utell.net [97.3.0.10]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id KAA00746; Thu, 30 Jan 1997 10:57:47 GMT Message-Id: <199701301057.KAA00746@ui-gate.utell.co.uk> From: "Brian Somers" To: Cc: , , , , Subject: Re: ipdivert & masqd Date: Thu, 30 Jan 1997 10:53:04 -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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've essentially got the following: > > > > ---------------- ---------------------- > > | 10.0.10.2 |------------------| 10.0.10.1 | > > ---------------- | | > > | 10.0.1.254 (ed0) | > > ---------------------- > > | > > | > > ----------------- | > > | 10.0.1.1 |--------------------------- > > ----------------- > > > > with a mask of ffffff00 everywhere and the machine in the middle using > > the following: > > > > ipfw add 100 divert 6668 all from any to any via ed0 > > A-HAH! :-) > > Could you try the following patch? > > Thanks, > - -Archie > > [.....] I tried it, and I'm a bit confused about the results ! It allows connections in both directions between 10.0.1.1 and 10.0.1.254, but sending a packet from 10.0.10.2 to 10.0.1.1 goes to 10.0.10.1, gets aliased as 10.0.1.254->10.0.1.1, gets accepted and replied to by 10.0.1.1 and gets changed from 10.0.1.1->10.0.1.254 to 10.0.1.1->10.0.10.3 by the PacketAlias stuff and then disappears. Maybe the problem is with the forwarding code - where ip_input() calls ip_output(). I didn't realize this happened ! Surely, we should be remembering and zero'ing ip_divert_ignore before calling ip_output here, and restoring it afterwards. I'll check this when I get home this evening ! Brian Don't _EVER_ lose your sense of humour From owner-freebsd-hackers Thu Jan 30 03:19:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA05490 for hackers-outgoing; Thu, 30 Jan 1997 03:19:44 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA05483 for ; Thu, 30 Jan 1997 03:19:42 -0800 (PST) Received: from fakir.india.hp.com (fakir.india.hp.com [15.10.40.3]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id DAA02756; Thu, 30 Jan 1997 03:19:33 -0800 (PST) Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.20/15.5+ECS 3.3) id AA268284982; Thu, 30 Jan 1997 16:49:42 +0500 Message-Id: <199701301149.AA268284982@fakir.india.hp.com> To: rminnich@sarnoff.com Cc: freebsd-hackers@freebsd.org Subject: Using rfork() / threads Date: Thu, 30 Jan 1997 16:49:41 +0500 From: A JOSEPH KOSHY Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm looking at porting a linux program that uses `clone()' and was considering the BSD `rfork()' as an equivalent. My questions are: Do we have an equivalent for Linux `sched_yield()'? How light weight is the process created by `rfork()' (assuming that we share everything possible to be shared)? I'm not really looking at a complete emulation of `clone()'; just enough to get equivalent functionality. The other approach I am looking at is to use a user space threads library to get the required multi-threading. Which brings me to my next question: Whats the current state of the Posix threads library on FreeBSD? Thanks, Koshy My Personal Opinions Only. From owner-freebsd-hackers Thu Jan 30 03:34:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA06235 for hackers-outgoing; Thu, 30 Jan 1997 03:34:53 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA06230 for ; Thu, 30 Jan 1997 03:34:50 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id DAA13141; Thu, 30 Jan 1997 03:32:36 -0800 (PST) To: Nate Williams cc: Terry Lambert , brian@awfulhak.demon.co.uk, hackers@freebsd.org Subject: Re: Source code commits In-reply-to: Your message of "Thu, 30 Jan 1997 01:26:03 MST." <199701300826.BAA02591@rocky.mt.sri.com> Date: Thu, 30 Jan 1997 03:32:36 -0800 Message-ID: <13137.854623956@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Aieee, why go for trivial solutions when we can do something much more > useful (and difficult). Naw, you could do it all with a simple before-commit script. :-) Jordan From owner-freebsd-hackers Thu Jan 30 04:25:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA08098 for hackers-outgoing; Thu, 30 Jan 1997 04:25:54 -0800 (PST) Received: from vanuata (vanuata.dcs.gla.ac.uk [130.209.240.50]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA08093 for ; Thu, 30 Jan 1997 04:25:51 -0800 (PST) Received: from solander.dcs.gla.ac.uk (actually host solander) by vanuata with SMTP (MMTA) with ESMTP; Thu, 30 Jan 1997 12:25:41 +0000 Received: (from simonm@localhost) by solander.dcs.gla.ac.uk (8.8.4/8.7.3) id MAA22552; Thu, 30 Jan 1997 12:25:36 GMT To: freebsd-hackers@freebsd.org Subject: Re: Ensoniq SoundScape References: <199701300554.AAA00738@phoenix.its.rpi.edu> From: Simon Marlow Date: 30 Jan 1997 12:25:35 +0000 In-Reply-To: "David E. Cross"'s message of Thu, 30 Jan 1997 00:54:35 -0500 (EST) Message-ID: Lines: 25 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "David E. Cross" writes: > > Has anyone gotten this card to work under FreeBSD? If so, could you give me > a hand (I think I am close, just missing that one last step) You can get it to work as a soundblaster - this is the best I've managed. The trick is to get the PnP parameters set up right. I did this by booting Win95 and then booting FreeBSD using the fbsdboot program, but you could probably use the PnP code that's floating around somewhere (I forget where, search the mail archives). There is a soundscape driver in the kernel, but it seems to be experimental/out-of-date. When I finally got it to compile, it failed to recognise the card. Cheers, Simon -- Simon Marlow simonm@dcs.gla.ac.uk Research Assistant http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key From owner-freebsd-hackers Thu Jan 30 05:04:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09827 for hackers-outgoing; Thu, 30 Jan 1997 05:04:08 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09813; Thu, 30 Jan 1997 05:04:01 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199701301304.FAA09813@freefall.freebsd.org> Subject: Re: Cases (was: Constructive Criticism) To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 05:04:00 -0800 (PST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org In-Reply-To: <199701300301.WAA09208@spoon.beta.com> from "Brian J. McGovern" at Jan 29, 97 10:01:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern wrote: > > >> I've been noticing, more an more, that FreeBSD has been/is being > >> divided in to two camps. Basically, the "has", and the "has > >> not". What I mean by this, is that there appears to be the core > >> team, who kick butt making this stuff all work, then the people like > >> me, who'd like to help out where they can, but seem to have an > >> incredible time getting started. > > > >This is called the "learning curve". There are two ways to climb it, for > >climb it you must if you want to do anything. > > > >1) Spend lots of time trying, asking questions, exercising your intelligence > > and patience. > >2) Give lots of money to someone else to have them force you through 1). > > I disagree with your two cases. As with any development decision, if I can't > justify the cost of undertaking the certain project, I won't even begin it. In > the case of #1, its a time/learning curve that is out of reach. By the time > I figure it out for release x.y.z, its usually changed. Even so, digesting > x amount of data in reasonable size time chunks (I usually get 20 minutes > a couple of time a day here or there to work on these types of projects, maybe > totalling an hour or so a day). 20 minutes a day is exactly the situation that i face. sometimes i am able to devote an entire weekend day to the project but that is very rare (wife, 4 kids, house, 2 cars, job all of these demand maintainence ;) this is one reason that i took on the job of postmaster. find something that you need to do, then apply the extra effort to document that part of the system, or develope a program that you need and submit that to the project. everyone can contribute ;) jmb From owner-freebsd-hackers Thu Jan 30 05:25:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA10519 for hackers-outgoing; Thu, 30 Jan 1997 05:25:11 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA10514 for ; Thu, 30 Jan 1997 05:25:08 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id XAA00207 for hackers@freebsd.org; Thu, 30 Jan 1997 23:55:05 +1030 (CST) From: Michael Smith Message-Id: <199701301325.XAA00207@genesis.atrad.adelaide.edu.au> Subject: Mail digestion To: hackers@freebsd.org Date: Thu, 30 Jan 1997 23:55:04 +1030 (CST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Elm appears to have just eaten all my outstanding mail (some 200+ items). If you were expecting a response from me on something, you'll need to send it again. 8( -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Jan 30 05:29:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA10636 for hackers-outgoing; Thu, 30 Jan 1997 05:29:33 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA10630 for ; Thu, 30 Jan 1997 05:29:31 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id IAA09489; Thu, 30 Jan 1997 08:26:28 -0500 Date: Thu, 30 Jan 1997 08:26:28 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: A JOSEPH KOSHY cc: freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads In-Reply-To: <199701301149.AA268284982@fakir.india.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, A JOSEPH KOSHY wrote: > I'm looking at porting a linux program that uses `clone()' and was > considering the BSD `rfork()' as an equivalent. My questions are: > Do we have an equivalent for Linux `sched_yield()'? well, i wrote one a few years back for freebsd but it never got put in. It's a trivial call. They used to look like this (Wally Kimura, then of IBM, was the originator of this as far as I know) yield() { runrun++; } Looking at my current kernel source it seems you need to: yield() { want_resched++; } Corrections appreciated. > How light weight is the process created by `rfork()' (assuming > that we share everything possible to be shared)? Not light at all. It shares things with the other process, but it is a full process in its own right. You really ought to check out the latest context switch times for freebsd before assuming that is bad. As Rob Pike once said, and I quote semi-accurately, threads are needed for systems that have poor context switch performance. Translation: that doesn't mean they're needed. If you request file descriptor sharing, then the fd tables are shared between processes: if one opens a file, the other will see it. VM space handling is a little different. If you request VM space sharing, you don't exactly get Vm address space sharing: what you get is instead shared data areas where in normal fork they are copied. More details on request. The effect is what you want, though: shared data areas. > I'm not really looking at a complete emulation of `clone()'; just enough > to get equivalent functionality. Going by my reading of my linux kernel source, rfork gives more than enough. ron From owner-freebsd-hackers Thu Jan 30 05:38:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA11046 for hackers-outgoing; Thu, 30 Jan 1997 05:38:37 -0800 (PST) Received: from nimbus.superior.net (root@nimbus.superior.net [206.153.96.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA11038 for ; Thu, 30 Jan 1997 05:38:24 -0800 (PST) Received: (from exidor@localhost) by nimbus.superior.net (8.8.5/8.8.4) id IAA19867; Thu, 30 Jan 1997 08:38:21 -0500 (EST) Message-ID: <19970130083821.IC11373@@> Date: Thu, 30 Jan 1997 08:38:21 -0500 From: exidor@superior.net (Christopher Masto) To: kmitch@weenix.guru.org (Keith Mitchell) Cc: hackers@freebsd.org Subject: Re: lpd - remote printing with an output filter References: <199701300359.WAA25499@weenix.guru.org> X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 In-Reply-To: <199701300359.WAA25499@weenix.guru.org>; from Keith Mitchell on Jan 29, 1997 22:59:33 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Keith Mitchell writes: > > Has anyone got any problems with me making this work ? It's always > > irritated me ! It consists of two one-liners to printjob.c. > > No, but I would like to see it happen. I have several printers hanging off > a HP JetDirect EX print server and there is no way to run an output filter > on them. Consequently, the user must KNOW not to just blindly print to it. > (sigh). I simply installed LPRng, which is a whole lot better and includes support for "bounce queues" (job is filtered and then sent somewhere else). -- Christopher Masto . . . . Superior Net Support: support@superior.net chris@masto.com . . . . . Masto Consulting: info@masto.com On Agreement: If I had entered into an agreement with that man, I would be sticking my head in a moose - attributed to movie mogul Samuel Goldwyn From owner-freebsd-hackers Thu Jan 30 06:03:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA11797 for hackers-outgoing; Thu, 30 Jan 1997 06:03:54 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA11789 for ; Thu, 30 Jan 1997 06:03:47 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA09649; Thu, 30 Jan 1997 09:03:16 -0500 Date: Thu, 30 Jan 1997 09:03:15 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: A JOSEPH KOSHY , freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ron Minnich |"Failure is not an option" -- Gene Kranz rminnich@sarnoff.com | -- except, of course, on Microsoft products (609)-734-3120 | ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html On Thu, 30 Jan 1997, Ron G. Minnich wrote: > They used to look like this (Wally Kimura, then of IBM, was the originator ^^^^^^ OOOOPS. Imura. Wally, if you're out there, sorry. ron From owner-freebsd-hackers Thu Jan 30 06:17:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA12354 for hackers-outgoing; Thu, 30 Jan 1997 06:17:58 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA12349 for ; Thu, 30 Jan 1997 06:17:54 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id IAA21428; Thu, 30 Jan 1997 08:17:02 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma021420; Thu Jan 30 08:16:43 1997 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id IAA09745; Thu, 30 Jan 1997 08:16:01 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.4/8.6.12) with ESMTP id IAA29041; Thu, 30 Jan 1997 08:17:07 -0600 (CST) Message-Id: <199701301417.IAA29041@jake.lodgenet.com> X-Mailer: exmh version 2.0beta 12/23/96 To: "Brian J. McGovern" cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Cases (was: Constructive Criticism) In-reply-to: Your message of "Wed, 29 Jan 1997 22:01:40 EST." <199701300301.WAA09208@spoon.beta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 08:17:06 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Brian J. McGovern" writes: >> >>> The second major area of concern in my eyes is device >>> drivers. Someone pointed me to a section of handbook that dealt with >>> doing it (supposedly), but it was terribly out of date. Back to >> >>If you can't work out how device drivers are integrated, I seriously >>doubt that you're up to writing one in the first place. 8( >> > >Ah, again, a circle effect. You'll never get good till you've chewed on a >handful of them. And you'll never start on your first till you think you >can do it. Everyone I've ever talked to about device drivers says something to the effect of "its not rocket science". Its just one of those things that you need to go through a few times. I often look back on drivers I did even two months ago and see lots of things I could do better. The nice thing about drivers is that they're usually small enough that it only takes a week or so to totally rip one apart and start over with the good parts. Of course there's always exceptions, but you shouldn't be starting with that complex a project. > >But, because I don't like arguing for the sake of arguing, here's a plan. >Tomorrow, whilest I'm at work, I will write some code for a pseudo-device >driver I wish to call foo. I will write routines for fooinit, fooread, >and foowrite. Just from this sentence, its obvious that you haven't read even sparse documentation that your picking at ;-) *BSD doesn't have a fooinit, SysV does. BSD uses fooprobe() and fooattach(). If your device is connected to a bus of any kind (or wants to pretend it is) you have a probe() to do a quick presence test. If the probe returns anything other than zero, your attach routine will be called to do further config. If you have a true pseudo-device (like if_tun, vnode, etc) you'll have just an attach(). > According to the documentation I've read, I should be able to >leave the open and close routines set to (I guess NULL ?) nothing. Just to understand where you're coming from, what documentation is this? > fooinit >will also exist, but will just contain a printf to announce the presence of >the pseudo-driver. The driver will be a character driver, with major number >of 20. Minor number will represent buffer numbers, each buffer will be 1K >in length. Writes to a buffer will set the string. Reads will return it (if >the full length is specified). Optionally, I'll use the offset attributes >to allow multiple reads and writes. Lastly, all of these routines will >be in a file called foodev.c. > That all looks OK. >Now, based on my reading, and what I've seen in some of the drivers >I _have_ looked at, I believe that I'll have to set a cdevsw structure up, Yes, in 2.2 and later, the driver is responsible for it's own [cb]devsw structure. >and it looks like a struct isa_driver. only if your device wants to pretend its an isa device. It could also want to be a pc-card, scsi, pci, eisa, or real pseudo device. All of these busses are slightly different. > I also see probe() and attach() >routines that I have not seen documentation on before in the books I have >read. The 4.4 Daemon book mentions them. I think the 4.3 and possibly Vahalia do too. Check out as many of these as you can get your hands on: Writing Device Drivers: Tutorial and Reference; Tim Burke, Mark A. Parenti, Al, Wojtas; Digital Press, ISBN 1-55558-141-2. Pretty good all around device driver book, geared toward Digital Unix, but it's probably closer to *BSD than any other book I've seen. Writing A Unix Device Driver; Janet I. Egan, Thomas J. Teixeira; John Wiley & Sons, ISBN 0-471-62859-X. System V oriented. The best section is the appendix that explains differences between BSD and SysV Writing Device Drivers for SCO Unix; Peter Kettle, Steve Statler; Addison-Wesley, ISBN 0-201-54425-3 A good introduction to device drivers, SCO oriented (obviously). But covers a lot of the basics of unix drivers. These are more on the kernel in general, but theres lots of good stuff here: The Design and Implementation of the 4.3BSD Unix Operating System; Leffler, McKusick, Karels, and Quarterman; Addison-Wesley, ISBN 0-201-06196-1 The Design and Implementation of the 4.4BSD Unix Operating System; McKusick, Bostic, Karels, and Quarterman; Addison-Wesley, ISBN 0-201-54979-4 Unix Internals the New Frontiers; Uresh Vahalia; Prentice Hall, ISBN 0-13-101908-2 anyone more? > > -Brian > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Thu Jan 30 06:30:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA12933 for hackers-outgoing; Thu, 30 Jan 1997 06:30:23 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA12923 for ; Thu, 30 Jan 1997 06:30:19 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id IAA21805; Thu, 30 Jan 1997 08:29:10 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma021784; Thu Jan 30 08:28:46 1997 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id IAA10106; Thu, 30 Jan 1997 08:28:04 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.4/8.6.12) with ESMTP id IAA29130; Thu, 30 Jan 1997 08:29:10 -0600 (CST) Message-Id: <199701301429.IAA29130@jake.lodgenet.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Michael Smith cc: mcgovern@spoon.beta.com (Brian J. McGovern), hackers@freebsd.org Subject: Re: Cases (was: Constructive Criticism) In-reply-to: Your message of "Thu, 30 Jan 1997 14:22:44 +1030." <199701300352.OAA26563@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 08:29:10 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith writes: >#define CDEV_MAJOR 20 >static struct cdevsw foo_cdevsw = >{ > fooopen, fooclose, fooread, foowrite, > fooioctl, nullstop, nullreset, nodevtotty, > fooselect, nommap, NULL, driver_name, > NULL, -1 >}; > >Note that some of the placeholders are "no*" and some are "null*" - I >think that this is laziness on someone's part 8( I think that the `no' routines return ENODEV as an error, and the `null' routines silently do nothing. Probably only for the ones that make sense though. If you set d_open to be nullopen, your device will work. If you set it to noopen, open("/dev/mydev") will always fail. Some of them are just #defined to be the other though, like d_reset and d_stop. glance through sys/kern/subr_xxx.c and sys/sys/conf.h if you care. ;-) > >-- >]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ >]] Genesis Software genesis@gsoft.com.au [[ >]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ >]] realtime instrument control. (ph) +61-8-8267-3493 [[ >]] Unix hardware collector. "Where are your PEZ?" The Tick [[ > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Thu Jan 30 07:04:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA14199 for hackers-outgoing; Thu, 30 Jan 1997 07:04:44 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA14192 for ; Thu, 30 Jan 1997 07:04:39 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vpy2N-0007OS-00; Thu, 30 Jan 1997 08:04:27 -0700 To: Darren Reed Subject: Re: ipdivert & masqd Cc: hackers@freebsd.org In-reply-to: Your message of "Thu, 30 Jan 1997 07:37:46 +1100." <199701292038.MAA19786@freefall.freebsd.org> References: <199701292038.MAA19786@freefall.freebsd.org> Date: Thu, 30 Jan 1997 08:04:26 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199701292038.MAA19786@freefall.freebsd.org> Darren Reed writes: : It is a *much* better idea to redirect IRC to a local TCP port and process : it using a proxy agent. Same could also be said for FTP. Yes. It is. However, you also have to do the same for Talk, Real Audio and at least one other protocol that encodes either the IP address or ports of the system. Warner From owner-freebsd-hackers Thu Jan 30 07:08:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA14405 for hackers-outgoing; Thu, 30 Jan 1997 07:08:22 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA14394 for ; Thu, 30 Jan 1997 07:08:13 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vpy4d-0007Oo-00; Thu, 30 Jan 1997 08:06:47 -0700 To: Charles Mott Subject: Re: ipdivert & masqd Cc: Darren Reed , Eivind Eklund , brian@awfulhak.demon.co.uk, archie@whistle.com, hackers@freebsd.org, ari.suutari@ps.carel.fi In-reply-to: Your message of "Wed, 29 Jan 1997 13:58:28 MST." References: Date: Thu, 30 Jan 1997 08:06:47 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Charles Mott writes: : In practice, these situations are not seen, and the packet aliasing : software works for FTP. The system loading is very low, and the software : easily scales to situations where there are large numbers of users. True. : I don't know about IRC, but my guess is that the real situation is simpler : than the theoretical. Whatever Linux does to handle IRC, I am told that : it looks fairly similar to what one does for FTP. Yes. You could also go out and get SLiRP, which would show you all kinds of neat tricks for all the pathological protocols out there. It has to do exactly the same thing. You could look at the TIA sources, if you have them too, but few people do :-) Warner From owner-freebsd-hackers Thu Jan 30 07:16:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA14783 for hackers-outgoing; Thu, 30 Jan 1997 07:16:51 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA14778 for ; Thu, 30 Jan 1997 07:16:48 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id JAA26684; Thu, 30 Jan 1997 09:13:34 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma026682; Thu Jan 30 09:13:30 1997 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id JAA11206; Thu, 30 Jan 1997 09:12:49 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.4/8.6.12) with ESMTP id JAA29351; Thu, 30 Jan 1997 09:13:54 -0600 (CST) Message-Id: <199701301513.JAA29351@jake.lodgenet.com> X-Mailer: exmh version 2.0beta 12/23/96 To: "Brian J. McGovern" cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: The continuting email... In-reply-to: Your message of "Thu, 30 Jan 1997 00:05:43 EST." <199701300505.AAA09649@spoon.beta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 09:13:54 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Brian J. McGovern" writes: > >I'd be more than happy to hammer out documentation. I do it quite frequently. >However, doing documentation requires a.) Coordination with the group as a If you're serious about writing some of this down. I'd let you have the driver writer's guide as a starting point. Its the out-of-date doc we've all been refering to ;-) When I first started learning drivers, I wanted the same doc you're looking for. I even scribbled down a few notes. The thing that I've found out about documenting is that as you get further up the curve, different things are important. I lose sight of what might be a big stumbling block for a beginner. Then as you get higher and higher, free time gets harder and harder to come by (or maybe its just my attention defecit syndrome ;-)). And you're sitting there trying to make sense out of your notes and then you finally say, screw it, I'm going to walk the dog, or go to the bar, or go hunging, or ..., I'll just answer a few questions on -hackers ;-) > >>Driver initialisation is seperated into two parts, known as 'probe' and >>'attach'. The purpose of the 'probe' routine is to ascertain whether >>the hardware is present, and optionally determine its configuration. > >>Probe/attach for ISA device drivers is triggered by the presence of a >>non-static isa_driver structure in the driver; at least the first three >>fields should be initialised, with the probe and attach routines and the >>name of the driver : > >Ok. I know the what. Any particular reason it has to be non-static? I assume >to cause it to blow up if there is another driver with the same name, but, >am I correct? because that's the one piece of information used to bolt your driver into the kernel. well, that and the interrupt handler, if any. have a look at ioconf.c in the kernel compile directory sometime. (yet another obscure source reference ;-)) > >Secondly, what are the fields after the first 3? > >Also, I did a grep for "isa_driver" in /usr/include via a find (ie - >grep "isa_driver" `find .` to no avail. Which header should I include? The kernel is mostly a self-contained critter that can be placed *anywhere* no /usr/include is usually necessary. In fact /usr/include/{sys,machine,net,netinet} are symlinks into the kernel tree, if it exists. Most if not all ISA stuff is in sys/i386/isa/*** including all device drivers, header files, and bus driver sources proper. `struct isa_driver' is in sys/i386/isa/isa_device.h > >>struct isa_driver foodriver = { fooprobe, fooattach, "foo"}; > >>The 'fooprobe' function is called during startup to determine whether >>the device is present or not. It should return zero if the probe >>for the hardware failed, or the size of the I/O space occupied by >>the device if the probe succeeded. > >Please define "size of the I/O space". To me, this can mean many >things, probably all of which are wrong. Is it the number of ports a >device uses? Amount of memory (shared or otherwise)? And how about >our simulated pseudo device, which won't control hardware, but might >have a few K in buffers? In the i386 architecture, there are really four different ways to get data to/from a device: 1) I/O space, or I/O mapped IO, 2) shared memory segment, or memory mapped IO, 3) DMA, 4) interrupts. I/O mapped IO is accomplished via the inb/outb family of instructions. These are conveniently wrapped up in machine/cpu_func.h so that in your code you can just outb(someaddr, someval). NOTE that if you're porting some code from linux, they have the args reversed! If our device has the config line: `device ep0 at isa? port 0x300 net irq 10 vector epintr' `port 0x300' is the address in the IO space. Memory mapped IO is a region usually in the 640K-1M range that the device shares with the OS. In the config line `device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr' `iomem 0xd0000' sets the memory mapped IO address. You can set pointers to this physical addr, and do bcopy's bzero's etc. You will have to make sure that you are accessing the memory via a `kernel virtual address', or you'll panic. The isa_device pointer handed to probe() and attach are a KVA. If you want to see the physical addr, use kvtop(). DMA (on the isa bus) is accomplished by isa_dma* family of functions. There is no docs on this, so you'll have to grep in sys/i386/isa for their use :( Or use the source in sys/i386/isa/isa.c The line: `device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr' shows that this device uses DMA channel 7. There's a pretty good section in the handbook on DMA. Interrupts are just a signaling mechanism, similar to signals in user processes. But they add a lot of concurrency issues to a driver. The line `device fea0 at isa? net irq ? vector feaintr' shows that the driver can figure out the IRQ from the card, and the interrupt handler is `feaintr', which must be non-static. > >Ok. Looks clear enough. I'm assuming we're still in attach here... I'm >also assuming that block devices would call bdevsw_add (wrong name i think, >but I think I get the idea). How about STREAMS types or tty type devices that >are linked off through a line protocol? There are no STREAMS. Network drivers are quite different from standard character drivers, but they are also documented better in the 4.4BSD book. Most of the multi-line serial drivers are derrived from sio. There is a slight bit of glue required to get the driver to work with line disciplines, but thats covered in the 4.4 book too (I think) Other than that its just a character driver. In fact for the first phase of development, I'd be inclined to get it working as a standard char device, then when that's working, go for the line discipline stuff. But then I've never written one either. > >Ok. Some of it makes sense. Is there a blank generic one that gives the >appropriate order? For instance, I see nullstop and nullreset. There should >also be a poll routine in there some where? Is it a NULL? a no? a -1? Poll is SysV, BSD uses select for similar operations. For a ttydriver, I think you can safely set this to the generic `ttselect' and have it work. >> >Ok. Is creating a devfs node mandatory? I know people would like to move to >it, but when/is it required? What makes the decision if it is optional? Not mandatory, you should respect the `DEVFS' pre-processor macro. like: #ifdef DEVFS #endif eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Thu Jan 30 08:09:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA16730 for hackers-outgoing; Thu, 30 Jan 1997 08:09:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA16724 for ; Thu, 30 Jan 1997 08:09:40 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id IAA22016; Thu, 30 Jan 1997 08:50:15 -0700 From: Terry Lambert Message-Id: <199701301550.IAA22016@phaeton.artisoft.com> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 30 Jan 1997 08:50:15 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@FreeBSD.ORG In-Reply-To: <199701300259.NAA25266@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 30, 97 01:29:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > This is called the "learning curve". There are two ways to climb it, for > > > climb it you must if you want to do anything. > > > > How about flattening the curve, instead? It's not an inherent property. > > Flattening the curve requires reducing the amount of knowledge required > for a given task. Yes. Exactly why it should be done. > Reducing the amount of knowledge required in the current context is > not a simple or useful task in any other than the longest, most > divorced-from-reality view. Useful to whom? Existing contributors, or contributors that it would be in the projects best interests to bring on line? Taking the long view is not the same as being unrealistic. If it is, then you should flatten that curve, too, and then it won't be. 8-). > > > If you can't work out how device drivers are integrated, I seriously > > > doubt that you're up to writing one in the first place. 8( > > > > This is wrong... I don't have to understand linker sets to be a good > > driver writer, but if I don't, how the driver gets integrated is a > > bit of FreeBSD-specific mystery, totally abstract from the concept > > of writing drivers themselves. > > You're (deliberately?) misreading me. Try the alternative interpretation > of what I said. Uh... "If you don't know how the undocumented current implementation of device numbering relates to the undocumented devfs method of registration, then you're not up to writing a driver"? Actually, a driver writer should only have to care about DDI/DKI, and not care about configuration: that should still be inherent in the interface. I don't grok that interpretation, either. > > Note: I betting that you realize that if you are arguing against > > documentation, you can't win. 8-) 8-). > > I'm arguing against someone saying "You're making it too hard" with the > response "I'm no bloody genius, and if I can do it, you can too". > > This makes the generous assumption that the other party is as capable as > I am, which is IMHO fairly realistic. Ah... but what if you *are* a bllody genius, only you aren't aware of it? 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Jan 30 08:25:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA17269 for hackers-outgoing; Thu, 30 Jan 1997 08:25:09 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA17264 for ; Thu, 30 Jan 1997 08:25:07 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.4/8.7.3) with SMTP id IAA03591; Thu, 30 Jan 1997 08:24:41 -0800 (PST) Date: Thu, 30 Jan 1997 08:24:40 -0800 (PST) From: Jaye Mathisen To: Tor Egge cc: petzi@mail.nacamar.de, hackers@freebsd.org Subject: Re: 2.2-BETA: options MAXMEM not working (fwd) In-Reply-To: <199701292132.WAA21498@pat.idt.unit.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmmm, I have a 2.2 box with 256MB RAM, and it sees it all just fine using the kernel option. On Wed, 29 Jan 1997, Tor Egge wrote: > > OK, after having built a couple more kernels, I found out that the MAXMEM > > option does not work for me when set to over 128 MB. I now run a kernel > > that uses only 128 MB, though my machine has 192 MB and will have 256 at > > the end of the week. Has this problem been fixed in kernels subsequent to > > 2.2-BETA ? I was using 160 MB just fine with FreeBSD 2.1.5. > > > > Cheers, > > > > Michael > > Is bounce buffer support disabled ? It uses some kernel virtual address space. > > If that does not help, you may want to look at PR kern/1880. > > - Tor Egge > From owner-freebsd-hackers Thu Jan 30 08:46:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA18250 for hackers-outgoing; Thu, 30 Jan 1997 08:46:26 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA18245 for ; Thu, 30 Jan 1997 08:46:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA22068; Thu, 30 Jan 1997 09:25:02 -0700 From: Terry Lambert Message-Id: <199701301625.JAA22068@phaeton.artisoft.com> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: jgreco@solaria.sol.net (Joe Greco) Date: Thu, 30 Jan 1997 09:25:02 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@freebsd.org In-Reply-To: <199701300310.VAA00309@solaria.sol.net> from "Joe Greco" at Jan 29, 97 09:10:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I make you a deal, Terry... you _show_ me a learning curve, and we will > see if it is ferromagnetic. :-) Hmmmm... OK. Transparent Aluminum Learning Curve #1: Describe the current overall DDI/DKI interface (including VM system API's). Describe how to write a device for it, such that the device sources will require no (or minimal) revision for use with the overall DDI/DKI interface which will be in use following the switch to devfs. Transparent Aluminum Learning Curve #2: Describe the current overall VFS module interface, starting with the VFS consumer interface at the top, and ending with the VM system API-based device interaction layer on the bottom, such that someone can write VFS modules with nearly no knowledge of FreeBSD internals, but moderate to high knowledge of FS design. Describe the theoretical basis for modules using both the VFS consumer and provider interface, instead of a system specific VM API, such that the module created will be stackable, once the layer abstraction issues that keep stacking from working above the level of agregation (as in the FFS/UFS stack) have been resolved. Transparent Aluminum Learning Curve #3: Describe the current overall support for ENPIC-type PCMCIA to ISA bridge chipsets for supplying card services. Describe the restrictions on implementation implied by the use of card services, such that a device driver can be written to operate with both PCMCIA and ISA devices, with no regard as to whether the device is a bridged PCMCIA device or a vanilla ISA device. Bonus question: describe the relationship of the current card services to the bus attach and planned PnP code changes, and its effect on the logical seperation of the functions in the device probe and attach routines. Transparent Aluminum Learning Curve #4: Describe the relationship between the kernel and utility programs such as "ps", "w", "vmstat", and so on. Place particular emphasis on providing a list of utilities which need to be rebuilt as a result of what structures changing. Describe *why* the utilities are dependent on promiscuous knowledge of kernel memory structures, and how a utility contributor can establish a similar list for a utility they plan to contribute. Bonus: describe implementation of this class of utilities with any long range plans for divorcing structure from presentation, so that the utility can be coded in such a way as to require minimal modification as these long term plans become reality. Transparent Aluminum Learning Curve #5: Describe the relationship between crt.0, ld.so, and the dlopen() family of routines. Describe the impact of this relationship on the use of library-level agregated (linker set) based constructors for pure virtual base classes (interfaces) in C++. Describe the correct way to code for maximum interoperability with the current a.out implementation, and the apparent future implementation direction, as embodied in John Polstra's "Elfkit". Transparent Aluminum Learning Curve #6: Describe why there are different tools for establishing the data structures used by the diskslice code vs. DOS partitioning, when conceptually, the only difference is the data being written. In the process, explain the utility of "/etc/disktab". Describe the interaction of these tools for adding a new disk to an existing FreeBSD system. Provide this data independent of drive controller type, drive size, physical drive geometry, or any other information which considers a drive as anything other than a linear array of sectors. Bonus: describe the operation of Bad144. Had enough? 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Jan 30 08:57:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA18917 for hackers-outgoing; Thu, 30 Jan 1997 08:57:32 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA18911 for ; Thu, 30 Jan 1997 08:57:29 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id LAA12254 for ; Thu, 30 Jan 1997 11:57:26 -0500 (EST) Message-Id: <199701301657.LAA12254@spoon.beta.com> To: hackers@freebsd.org Subject: Followup to criticism (was: Constructive criticism) Date: Thu, 30 Jan 1997 11:57:26 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmm. Talk about dropping a rock on a wasps nest :) I don't think I've gotten more email on any subject I've ever written about. At least its good to know that its a passionate subject. However, I started to get nervous when Terry backed me up (Sorry, Terry ;p ). I never meant to it be negative (more of an impassioned plea for attention was my goal), and I apologize to anyone wo got irritated. However, this seemingly negative instance has caused several positive things to happen. Firstly, I received an incredible inflow of technical information. It beat the hell out of "Read the manual section..." that I've seen before. I learned more in the past 24 hours about some of the more techie aspects than I have in two weeks of reading, and another of poking around with existing code. I'd like to say that this is the best format for _me_ to learn something, but too many have called me the _abnormal_ case in the past. Anyhow, my goals with this information. I'm going to sit down this weekend and try to hammer out my first pseudo-device. Once its working, I will cut a cookbook white paper, including ALL the steps I went through, the sample code, and as much informative documentation as I can provide on each of the steps. Then, I will release it for the wizards to comment on. A final version will probably be revamped in to HTML for inclusion in whatever document is chosen. As hardware permits, I'll also try doing a character device driver, and possibly a block driver (although I doubt I'll ever have anything useful to do one with, although some samples might make sense). Appropriate documentation on those will be released as they're completed. My next (non question) post should be Saturday some time. -Brian From owner-freebsd-hackers Thu Jan 30 09:07:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA19531 for hackers-outgoing; Thu, 30 Jan 1997 09:07:58 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA19523 for ; Thu, 30 Jan 1997 09:07:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA22108; Thu, 30 Jan 1997 09:48:30 -0700 From: Terry Lambert Message-Id: <199701301648.JAA22108@phaeton.artisoft.com> Subject: Re: The continuting email... To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 09:48:30 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org In-Reply-To: <199701300505.AAA09649@spoon.beta.com> from "Brian J. McGovern" at Jan 30, 97 00:05:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Do you read Dilbert? If it weren't for your other comments, I would have > >to say that you were trained management. You need to lift your eyes a > >little and look at the longer-term benefits of a given exercise. > > There are long term benefits, and there are short term realities. The long > term benefits is that I may get good at this. The short term reality is > that I have a certain length of time to aquire the information to do this. > If the time required is excessive, or unrealistic, it makes a better > choice to either hire someone to do it, or wait for someone else to do > it, and put my energies where not only will I have efficiency, but I'll > have success. I want to add a note here: the place he will probably put his energies is Linux, which has a well documented DDI/DKI. The assumption here is that he is the pet device driver writer for a given hardware vendor, not a FreeBSD fanatic who has decided to dive into writing devices. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Jan 30 09:14:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA19839 for hackers-outgoing; Thu, 30 Jan 1997 09:14:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA19834 for ; Thu, 30 Jan 1997 09:14:11 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA22139; Thu, 30 Jan 1997 09:55:15 -0700 From: Terry Lambert Message-Id: <199701301655.JAA22139@phaeton.artisoft.com> Subject: Re: Setting MTU from userland ppp To: dk+@ua.net Date: Thu, 30 Jan 1997 09:55:15 -0700 (MST) Cc: shocking@mailbox.uq.edu.au, freebsd-hackers@freebsd.org In-Reply-To: <199701300559.VAA03336@dog.farm.org> from "Dmitry Kohmanyuk" at Jan 29, 97 09:59:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > set mtu 576 > > in /etc/ppp/ppp.conf > > works for me. > > This would specify your _tranimission_ size. To change it on the other > side, change the other end's setup. > > Don't use 256 as your MTU. (violates the RFC) Any chance of having the software *enforce* the RFC, then? 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 Jan 30 09:14:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA19869 for hackers-outgoing; Thu, 30 Jan 1997 09:14:42 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA19861 for ; Thu, 30 Jan 1997 09:14:39 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA22125; Thu, 30 Jan 1997 09:54:02 -0700 From: Terry Lambert Message-Id: <199701301654.JAA22125@phaeton.artisoft.com> Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) To: chris@bb.cc.wa.us (Chris Coleman) Date: Thu, 30 Jan 1997 09:54:02 -0700 (MST) Cc: mcgovern@spoon.beta.com, mark@quickweb.com, msmith@atrad.adelaide.edu.au, hackers@freebsd.org In-Reply-To: from "Chris Coleman" at Jan 29, 97 09:35:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Therefore, If you don't like the documentation, Write something. Even if > it is just a well documented complaint. I will be accepting > contributions, and criticizm and whatever helpful things you have to > offer. So stop complaining about What doesn't work and What isnt > documented, And do something. > > If anyone else is working on a title, or has anything partially started I > would like to hear form them, so we can get organized and not duplicate > each other work. What is the intent of your book? What specific areas will it cover? What kind of existing material are you looking for? 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 Jan 30 09:23:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA20378 for hackers-outgoing; Thu, 30 Jan 1997 09:23:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA20367 for ; Thu, 30 Jan 1997 09:23:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA22180; Thu, 30 Jan 1997 10:04:42 -0700 From: Terry Lambert Message-Id: <199701301704.KAA22180@phaeton.artisoft.com> Subject: Re: Mail digestion To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 30 Jan 1997 10:04:42 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199701301325.XAA00207@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 30, 97 11:55:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Elm appears to have just eaten all my outstanding mail (some 200+ items). > > If you were expecting a response from me on something, you'll need to > send it again. 8( Describe the event. It may be in your "received" folder (to access, "elm -f =received"). It may be that your tmp got full on the save, or some other event occured, where it ran out of space and bailed. Typically, this will leave a file in /tmp or /usr/tmp, etc., which you can recover by catting it onto your mail file. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Jan 30 09:45:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA21711 for hackers-outgoing; Thu, 30 Jan 1997 09:45:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA21699 for ; Thu, 30 Jan 1997 09:45:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA22242; Thu, 30 Jan 1997 10:25:58 -0700 From: Terry Lambert Message-Id: <199701301725.KAA22242@phaeton.artisoft.com> Subject: Re: Followup to criticism (was: Constructive criticism) To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 10:25:58 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199701301657.LAA12254@spoon.beta.com> from "Brian J. McGovern" at Jan 30, 97 11:57:26 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hmm. Talk about dropping a rock on a wasps nest :) I don't think I've > gotten more email on any subject I've ever written about. At least its > good to know that its a passionate subject. However, I started > to get nervous when Terry backed me up (Sorry, Terry ;p ). I never meant > to it be negative (more of an impassioned plea for attention was my goal), > and I apologize to anyone wo got irritated. You say that like it's a bad thing... Just because I back something up doesn't mean it's negative. Though I will admit, I'll get down there in the muddy rut with my riding crop and whack and scream and foam at the mouth... "Get the wagon out of the rut! Quit pushing forward, you are trying to move seven tons of mud that are in front of the wheels! Get the wagon out of the rut! I don't care if all you see is the back of a wagon, the sen tons of mud are there! Get the wagon out of the rut! When you push wheels into mud, the mud bunches up in front of the wheels and makes it much harder to push next time! Get the wagon out of the rut! If you just use these four ugly boards for a short time, you can be out of the rut! Get the wagon out of the rut!" ...or I'll sit back where it's dry... "Pave the road! Ruts are stupid! Pave the road! If you'd only pave your roads, you wouldn't *get* ruts in the first place! Pave the road! Look, you're going to be driving back and forth over this thing for the next ten years! Pave the road! The time spent paving will be paid for in decreased travel time! Pave the road! How can you justify the travel time you spend in ruts? Pave the road! What, are you an idiot who *likes* ruts for some damn reason? Pave the road!" ...when I think it's appropriate. Doesn't make me a bad person. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Jan 30 10:14:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA23145 for hackers-outgoing; Thu, 30 Jan 1997 10:14:56 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23135 for ; Thu, 30 Jan 1997 10:14:51 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id TAA01757; Thu, 30 Jan 1997 19:13:09 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id TAA13677; Thu, 30 Jan 1997 19:02:13 +0100 (MET) Message-Id: <3.0.32.19970130190212.00b22780@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Jan 1997 19:02:14 +0100 To: Warner Losh From: Eivind Eklund Subject: Re: ipdivert & masqd Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:04 AM 1/30/97 -0700, you wrote: >In message <199701292038.MAA19786@freefall.freebsd.org> Darren Reed writes: >> It is a *much* better idea to redirect IRC to a local TCP port and process >> it using a proxy agent. Same could also be said for FTP. > >Yes. It is. However, you also have to do the same for Talk, Real >Audio and at least one other protocol that encodes either the IP >address or ports of the system. I'm thinking about doing transparent proxying for the protocols, but I want to see how well the packet-patching version run first. As it is, it is (hopefully) right in 99% of the cases, and it scales well. If I get reports of real-life problems I'll make it a priority to make proxies, but not before. (And the packet-patchers will still be an option - for most people, they probably are a better or as good solution.) Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Thu Jan 30 11:01:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA25032 for hackers-outgoing; Thu, 30 Jan 1997 11:01:06 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA25027 for ; Thu, 30 Jan 1997 11:01:01 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id LAA14124 for ; Thu, 30 Jan 1997 11:00:59 -0800 (PST) To: hackers@freebsd.org Subject: Jukka Ukkonen: POSIX.4 - scheduler once more (as you requested) Date: Thu, 30 Jan 1997 11:00:59 -0800 Message-ID: <14120.854650859@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Any interest in this? I'd like a few more reviewers, if possible. ------- Forwarded Message From: jau@iki.fi (Jukka Ukkonen) Latin-Date: Miercuri XXIX Ianuarie a.d. MCMXCVII Organization: Private person Phone: +358-9-6215280 (home) Reply-To: jau@iki.fi (Jukka Ukkonen) Content-Conversion: prohibited X-Mailer: ELM [version 2.4 PL25+pgp] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Greetings from Helsinki, You said earlier that you did not dare to publish my POSIX sched-package before I send you the correct version once more, because previously I had sent you an old version. So, I tried to do exactly that by replying to the address in the From header of your message, and the message bounced back due to some error the reason of which I have already forgotten. This time the attached version of my POSIX-sched package is the most recent version. (I have removed the earlier test versions from my hard disk to avoid any more surprises with them.) The manual pages are still missing though as they were about a month ago when we last discussed this extension. Cheers, // jau - ------ / Jukka A. Ukkonen, Internet and New Media / Finnish Telecom Ltd. /__ M.Sc. (sw-eng & cs) (Phone) +358-2040-4025 / Internet: Jukka.Ukkonen@tele.fi (Fax) +358-2040-2712 / Internet: jau@iki.fi (Mobile) +358-400-606671 v Internet: ukkonen@nic.funet.fi (Home&Fax) +358-9-6215280 o \ / - - X ------------------------- clip clip ------------------------------ / \ O # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # sched/sched.h # sched/sched_getparam.c # sched/sched_getscheduler.c # sched/sched_get_priority_max.c # sched/sched_get_priority_min.c # sched/sched_rr_get_interval.c # sched/sched_setparam.c # sched/sched_setscheduler.c # sched/Makefile # sched/Kernel-Sched.Diffs # sched/sched_yield.Diffs # sched/RTprio.diffs # echo x - sched/sched.h sed 's/^X//' >sched/sched.h << 'END-of-sched/sched.h' X/* X * Copyright (c) 1995,1996 Jukka Ukkonen X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Jukka Antero Ukkonen. X * 4. Neither the names of the authors nor the names of contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * 5. The source code must be available for anyone who wishes to have it. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * %W% (Jukka Ukkonen) %E% X */ X X X#ifndef _SCHED_H X#define _SCHED_H X X#include X#include X#include /* For struct timespec */ X X#ifndef _POSIX_PRIORITY_SCHEDULING X# define _POSIX_PRIORITY_SCHEDULING X#endif X X/* X * FIFO and Round-Robin must really be separate, but maybe X * it could be possible and worthwhile to try approximate FIFO X * using RR with higher priorities. X * X * RTP_PRIO_REALTIME with round-robin among equal priority X * processes at every time-quantum (= currently HZ/10) would X * still be only a poor substitute for fifo scheduling on X * systems that don't have a real fifo policy. X * X * Otherwise FIFO and RR are equivalent in all respects, but X * RR comes with involuntary release of CPU after the time X * quantum has passed. X * FIFO knows only about voluntary release of the CPU while X * the process can run as long as it wishes. So, you really X * can hang your machine, if there is no other process with X * higher RT-priority (FIFO or RR) ready to kill a infinitely X * looping FIFO process. X */ X X#ifdef RTP_PRIO_FIFO X# define SCHED_FIFO RTP_PRIO_FIFO X#else X# define SCHED_FIFO RTP_PRIO_REALTIME X#endif X X#define SCHED_RR RTP_PRIO_REALTIME X#define SCHED_TIMESHARE RTP_PRIO_NORMAL X#define SCHED_IDLE RTP_PRIO_IDLE X#define SCHED_OTHER SCHED_TIMESHARE X X/* X * Hopefully someone is interested enough to add X * the necessary deadline logic to the kernel. X */ X X#ifdef RTP_PRIO_DEADLINE X# define SCHED_DEADLINE RTP_PRIO_DEADLINE X#endif X Xstruct sched_param { X int sched_type; /* scheduling policy */ X int sched_priority; /* nice for time-share, else true prio */ X int sched_pgprio; /* pg-nice for TS, else unused */ X int sched_userprio; /* user-nice for TS, else unused */ X struct timespec sched_deadline; /* reserved for deadline scheduling */ X struct timespec sched_timereq; /* reserved for deadline scheduling */ X}; X X#endif END-of-sched/sched.h echo x - sched/sched_getparam.c sed 's/^X//' >sched/sched_getparam.c << 'END-of-sched/sched_getparam.c' X/* X * Copyright (c) 1995,1996 Jukka Ukkonen X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Jukka Antero Ukkonen. X * 4. Neither the names of the authors nor the names of contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * 5. The source code must be available for anyone who wishes to have it. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * %W% (Jukka Ukkonen) %E% X */ X X#ifndef lint Xstatic const char sccsid[] = "%W%\t(Jukka Ukkonen)\t%E%"; X#endif X X X#include X#include X#include X#include X#include X#include X Xint Xsched_getparam (pid, param) X pid_t pid; X struct sched_param *param; X{ X struct rtprio rtp; X X if (! param) { X errno = EINVAL; X return (-1); X } X X if (rtprio (RTP_LOOKUP, pid, &rtp) < 0) X return (-1); X X param->sched_type = rtp.type; X X if (rtp.type == RTP_PRIO_NORMAL) { X errno = 0; X X param->sched_priority = getpriority (PRIO_PROCESS, pid); X X if ((param->sched_priority == -1) && errno) X return (-1); X X param->sched_priority = -param->sched_priority; X X errno = 0; X X param->sched_pgprio = getpriority (PRIO_PGRP, pid); X X if ((param->sched_pgprio == -1) && errno) X return (-1); X X param->sched_pgprio = -param->sched_pgprio; X X errno = 0; X X param->sched_userprio = getpriority (PRIO_USER, pid); X X if ((param->sched_userprio == -1) && errno) X return (-1); X X param->sched_userprio = -param->sched_userprio; X } X else X param->sched_priority = RTP_PRIO_MAX - rtp.prio; X X return (0); X} END-of-sched/sched_getparam.c echo x - sched/sched_getscheduler.c sed 's/^X//' >sched/sched_getscheduler.c << 'END-of-sched/sched_getscheduler.c' X/* X * Copyright (c) 1995,1996 Jukka Ukkonen X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Jukka Antero Ukkonen. X * 4. Neither the names of the authors nor the names of contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * 5. The source code must be available for anyone who wishes to have it. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * %W% (Jukka Ukkonen) %E% X */ X X#ifndef lint Xstatic const char sccsid[] = "%W%\t(Jukka Ukkonen)\t%E%"; X#endif X X X#include X#include X#include X#include X Xint Xsched_getscheduler (pid) X pid_t pid; X{ X struct rtprio rtp; X X if (rtprio (RTP_LOOKUP, pid, &rtp) < 0) X return (-1); X X return ((int) rtp.type); X} END-of-sched/sched_getscheduler.c echo x - sched/sched_get_priority_max.c sed 's/^X//' >sched/sched_get_priority_max.c << 'END-of-sched/sched_get_priority_max.c' X/* X * Copyright (c) 1995,1996 Jukka Ukkonen X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Jukka Antero Ukkonen. X * 4. Neither the names of the authors nor the names of contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * 5. The source code must be available for anyone who wishes to have it. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * %W% (Jukka Ukkonen) %E% X */ X X#ifndef lint Xstatic const char sccsid[] = "%W%\t(Jukka Ukkonen)\t%E%"; X#endif X X X#include X#include X#include X#include X#include X Xint Xsched_get_priority_max (policy) X int policy; X{ X errno = 0; X X switch (policy) { X X case SCHED_FIFO: X case SCHED_RR: X case SCHED_IDLE: X return (RTP_PRIO_MAX); X X case SCHED_TIMESHARE: X return (PRIO_MAX); X X default: X errno = EINVAL; /* Here is a gotcha! Always check errno! */ X return (-1); /* Whether negatives are valid is unspecified. */ X } X} X END-of-sched/sched_get_priority_max.c echo x - sched/sched_get_priority_min.c sed 's/^X//' >sched/sched_get_priority_min.c << 'END-of-sched/sched_get_priority_min.c' X/* X * Copyright (c) 1995,1996 Jukka Ukkonen X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Jukka Antero Ukkonen. X * 4. Neither the names of the authors nor the names of contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * 5. The source code must be available for anyone who wishes to have it. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * %W% (Jukka Ukkonen) %E% X */ X X#ifndef lint Xstatic const char sccsid[] = "%W%\t(Jukka Ukkonen)\t%E%"; X#endif X X X#include X#include X#include X#include X#include X Xint Xsched_get_priority_max (policy) X int policy; X{ X errno = 0; X X switch (policy) { X X case SCHED_FIFO: X case SCHED_RR: X case SCHED_IDLE: X return (RTP_PRIO_MIN); X X case SCHED_TIMESHARE: X return (PRIO_MIN); X X default: X errno = EINVAL; /* Here is a gotcha! Always check errno! */ X return (-1); /* Whether negatives are valid is unspecified. */ X } X} X END-of-sched/sched_get_priority_min.c echo x - sched/sched_rr_get_interval.c sed 's/^X//' >sched/sched_rr_get_interval.c << 'END-of-sched/sched_rr_get_interval.c' X/* X * Copyright (c) 1995,1996 Jukka Ukkonen X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Jukka Antero Ukkonen. X * 4. Neither the names of the authors nor the names of contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * 5. The source code must be available for anyone who wishes to have it. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * %W% (Jukka Ukkonen) %E% X */ X X#ifndef lint Xstatic const char sccsid[] = "%W%\t(Jukka Ukkonen)\t%E%"; X#endif X X X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X Xint Xsched_rr_get_interval (pid, ts) X pid_t pid; X struct timespec *ts; X{ X struct clockinfo cinfo; X struct rtprio rtp; X int sysmib[2]; X size_t cinfosize; X X if (! ts) { X errno = EFAULT; X X return (-1); X } X X if (rtprio (RTP_LOOKUP, pid, &rtp) < 0) X return (-1); X X if (rtp.type != SCHED_RR) { X errno = EINVAL; X X return (-1); X } X X cinfosize = sizeof (cinfo); X X sysmib[0] = CTL_KERN; X sysmib[1] = KERN_CLOCKRATE; X X if (sysctl (sysmib, 2, &cinfo, &cinfosize, NULL, 0) < 0) X return (-1); X X ts->ts_sec = 0; X ts->ts_nsec = cinfo.tick * 10 * 1000; /* really (hz / 10) */ X X return (0); X} X X#ifdef DEBUG_SCHED_RR_GET_INTERVAL X Xint Xmain () X{ X struct timespec ts; X X if (sched_rr_get_interval (getpid (), &ts) < 0) { X perror ("sched_rr_get_interval ()"); X exit (-1); X } X X printf ("ts.ts_sec = %d, ts.ts_nsec = %d\n", ts.ts_sec, ts.ts_nsec); X X return (0); X} X X#endif X END-of-sched/sched_rr_get_interval.c echo x - sched/sched_setparam.c sed 's/^X//' >sched/sched_setparam.c << 'END-of-sched/sched_setparam.c' X/* X * Copyright (c) 1995,1996 Jukka Ukkonen X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Jukka Antero Ukkonen. X * 4. Neither the names of the authors nor the names of contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * 5. The source code must be available for anyone who wishes to have it. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * %W% (Jukka Ukkonen) %E% X */ X X#ifndef lint Xstatic const char sccsid[] = "%W%\t(Jukka Ukkonen)\t%E%"; X#endif X X X#include X#include X#include X#include X#include X#include X Xint Xsched_setparam (pid, param) X pid_t pid; X struct sched_param *param; X{ X struct rtprio rtp; X X if (! param) { X errno = EINVAL; X return (-1); X } X X if (rtprio (RTP_LOOKUP, pid, &rtp) < 0) X return (-1); X X if (rtp.type == RTP_PRIO_NORMAL) { X if (setpriority (PRIO_PROCESS, pid, -param->sched_priority) < 0) X return (-1); X X if (setpriority (PRIO_PGRP, pid, -param->sched_pgprio) < 0) X return (-1); X X if (setpriority (PRIO_USER, pid, -param->sched_userprio) < 0) X return (-1); X X rtp.prio = 0; X } X else X rtp.prio = RTP_PRIO_MAX - param->sched_priority; X X if (rtprio (RTP_SET, pid, &rtp) < 0) X return (-1); X X return (0); X} END-of-sched/sched_setparam.c echo x - sched/sched_setscheduler.c sed 's/^X//' >sched/sched_setscheduler.c << 'END-of-sched/sched_setscheduler.c' X/* X * Copyright (c) 1995,1996 Jukka Ukkonen X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Jukka Antero Ukkonen. X * 4. Neither the names of the authors nor the names of contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * 5. The source code must be available for anyone who wishes to have it. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * %W% (Jukka Ukkonen) %E% X */ X X#ifndef lint Xstatic const char sccsid[] = "%W%\t(Jukka Ukkonen)\t%E%"; X#endif X X X#include X#include X#include X#include X#include X#include X Xint Xsched_setscheduler (pid, policy, param) X pid_t pid; X int policy; X struct sched_param *param; X{ X struct rtprio rtp; X X if (! param) { X errno = EINVAL; X return (-1); X } X X rtp.type = policy; X X if (policy == RTP_PRIO_NORMAL) { X if (setpriority (PRIO_PROCESS, pid, -param->sched_priority) < 0) X return (-1); X X if (setpriority (PRIO_PGRP, pid, -param->sched_pgprio) < 0) X return (-1); X X if (setpriority (PRIO_USER, pid, -param->sched_userprio) < 0) X return (-1); X X rtp.prio = 0; X } X else X rtp.prio = RTP_PRIO_MAX - param->sched_priority; X X if (rtprio (RTP_SET, pid, &rtp) < 0) X return (-1); X X return (0); X} END-of-sched/sched_setscheduler.c echo x - sched/Makefile sed 's/^X//' >sched/Makefile << 'END-of-sched/Makefile' X XCC = gcc X X.c.o: X $(CC) $(CFLAGS) -c $< X ld -r -x $@ X mv a.out $@ X chmod a-x $@ X XCINCL = -I../include -I../ctype X XCFLAGS = -O4 -fexpensive-optimizations -fpcc-struct-return -funsigned-char \ X -D_NO_POSIX_OPAQUE_TYPES $(CDEBUG) $(CINCL) X#CFLAGS = $(CDEBUG) $(CINCL) X XSRCS = \ X sched_get_priority_max.c sched_setparam.c \ X sched_get_priority_min.c sched_setscheduler.c \ X sched_getparam.c sched_getscheduler.c \ X sched_rr_get_interval.c X XOBJS = \ X sched_get_priority_max.o sched_setparam.o \ X sched_get_priority_min.o sched_setscheduler.o \ X sched_getparam.o sched_getscheduler.o \ X sched_rr_get_interval.o X Xlibsched.a: $(OBJS) X rm -f $@ X ar rv $@ $(OBJS) X ranlib $@ X END-of-sched/Makefile echo x - sched/Kernel-Sched.Diffs sed 's/^X//' >sched/Kernel-Sched.Diffs << 'END-of-sched/Kernel-Sched.Diffs' X--- /sys/kern/kern_resource.c.orig Tue May 30 11:05:39 1995 X+++ /sys/kern/kern_resource.c Mon Dec 25 20:52:30 1995 X@@ -247,8 +247,11 @@ X /* can't set realtime priority */ X if (rtp.type == RTP_PRIO_REALTIME) X return (EPERM); X+ if (rtp.type == RTP_PRIO_FIFO) X+ return (EPERM); X } X switch (rtp.type) { X+ case RTP_PRIO_FIFO: X case RTP_PRIO_REALTIME: X case RTP_PRIO_NORMAL: X case RTP_PRIO_IDLE: X--- /sys/kern/kern_synch.c.orig Tue May 30 11:05:44 1995 X+++ /sys/kern/kern_synch.c Tue Dec 26 16:23:20 1995 X@@ -67,8 +67,10 @@ X roundrobin(arg) X void *arg; X { X+ if (! curproc || curproc->p_rtprio.type != RTP_PRIO_FIFO) { X+ need_resched(); X+ } X X- need_resched(); X timeout(roundrobin, NULL, hz / 10); X } X X@@ -670,7 +672,11 @@ X p->p_usrpri = newpriority; X if (newpriority < curpriority) X need_resched(); X- } else { X+ } else if (! curproc || X+ (curproc->p_rtprio.type != RTP_PRIO_FIFO) || X+ (((p->p_rtprio.type == RTP_PRIO_FIFO) || X+ (p->p_rtprio.type == RTP_PRIO_REALTIME)) && X+ (p->p_rtprio.prio < curproc->p_rtprio.prio))) { X need_resched(); X } X } X--- /sys/sys/rtprio.h.orig Sun Oct 2 06:45:59 1994 X+++ /sys/sys/rtprio.h Mon Dec 25 20:48:18 1995 X@@ -42,7 +42,26 @@ X #define RTP_PRIO_REALTIME 0 X #define RTP_PRIO_NORMAL 1 X #define RTP_PRIO_IDLE 2 X+#define RTP_PRIO_FIFO 3 X X+/* X+ * RTP_PRIO_QUANTUM -- not implemented yet! X+ * Actually this is intended as another type X+ * of round-robin policy with the ability to X+ * allow processes request a non-default X+ * time-slice or time-quantum. X+ */ X+/* #define RTP_PRIO_QUANTUM 4 */ X+ X+/* X+ * RTP_PRIO_DEADLINE -- not implemented yet! X+ */ X+/* #define RTP_PRIO_DEADLINE 5 */ X+ X+/* X+ * Actual priority ranges should be changed X+ * to cover at least some 128 to 256 steps! X+ */ X /* priority range */ X #define RTP_PRIO_MIN 0 /* Highest priority */ X #define RTP_PRIO_MAX 31 /* Lowest priority */ X@@ -57,6 +76,10 @@ X struct rtprio { X u_short type; X u_short prio; X+#if defined(RTP_PRIO_DEADLINE) || defined(RTP_PRIO_QUANTUM) X+ struct timeval deadline; /* Fail if not ready to repeat. */ X+ struct timeval quantum; /* Min./required time slice. */ X+#endif X }; X #endif X X--- /sys/i386/i386/swtch.s.orig Tue Dec 26 14:19:25 1995 X+++ /sys/i386/i386/swtch.s Tue Dec 26 14:20:58 1995 X@@ -90,6 +90,9 @@ X X movzwl P_RTPRIO_PRIO(%eax),%edx X X+ cmpw $RTP_PRIO_FIFO,P_RTPRIO_TYPE(%eax) /* fifo rt priority? */ X+ je set_rt X+ X cmpw $RTP_PRIO_REALTIME,P_RTPRIO_TYPE(%eax) /* realtime priority? */ X jne set_id /* must be idle priority */ X X--- /sys/vm/vm_glue.c.orig Mon Oct 16 22:43:05 1995 X+++ /sys/vm/vm_glue.c Mon Dec 25 20:52:32 1995 X@@ -430,6 +430,9 @@ X /* X * do not swapout a realtime process X */ X+ if (p->p_rtprio.type == RTP_PRIO_FIFO) X+ continue; X+ X if (p->p_rtprio.type == RTP_PRIO_REALTIME) X continue; X X--- /usr/include/sys/rtprio.h.orig Sun Oct 2 06:45:59 1994 X+++ /usr/include/sys/rtprio.h Mon Dec 25 20:48:18 1995 X@@ -42,7 +42,26 @@ X #define RTP_PRIO_REALTIME 0 X #define RTP_PRIO_NORMAL 1 X #define RTP_PRIO_IDLE 2 X+#define RTP_PRIO_FIFO 3 X X+/* X+ * RTP_PRIO_QUANTUM -- not implemented yet! X+ * Actually this is intended as another type X+ * of round-robin policy with the ability to X+ * allow processes request a non-default X+ * time-slice or time-quantum. X+ */ X+/* #define RTP_PRIO_QUANTUM 4 */ X+ X+/* X+ * RTP_PRIO_DEADLINE -- not implemented yet! X+ */ X+/* #define RTP_PRIO_DEADLINE 5 */ X+ X+/* X+ * Actual priority ranges should be changed X+ * to cover at least some 128 to 256 steps! X+ */ X /* priority range */ X #define RTP_PRIO_MIN 0 /* Highest priority */ X #define RTP_PRIO_MAX 31 /* Lowest priority */ X@@ -57,6 +76,10 @@ X struct rtprio { X u_short type; X u_short prio; X+#if defined(RTP_PRIO_DEADLINE) || defined(RTP_PRIO_QUANTUM) X+ struct timeval deadline; /* Fail if not ready to repeat. */ X+ struct timeval quantum; /* Min./required time slice. */ X+#endif X }; X #endif X END-of-sched/Kernel-Sched.Diffs echo x - sched/sched_yield.Diffs sed 's/^X//' >sched/sched_yield.Diffs << 'END-of-sched/sched_yield.Diffs' X--- /sys/kern/init_sysent.c.no_sched_yield Wed Dec 4 23:41:55 1996 X+++ /sys/kern/init_sysent.c Wed Dec 4 23:49:14 1996 X@@ -179,6 +179,7 @@ X int mlock(); X int munlock(); X int getsid(); X+int sched_yield(); X int lkmnosys(); X X #ifdef COMPAT_43 X@@ -489,7 +490,8 @@ X { 2, munlock }, /* 204 = munlock */ X /* { 0, nosys }, 205 = nosys */ X { 1, getsid }, /* 205 = getsid */ X- { 0, nosys }, /* 206 = nosys */ X+ /* { 0, nosys }, 206 = nosys */ X+ { 0, sched_yield }, /* 206 = sched_yield */ X { 0, nosys }, /* 207 = nosys */ X { 0, nosys }, /* 208 = nosys */ X { 0, nosys }, /* 209 = nosys */ X--- /sys/kern/syscalls.c.no_sched_yield Wed Dec 4 23:42:24 1996 X+++ /sys/kern/syscalls.c Wed Dec 4 23:46:07 1996 X@@ -249,7 +249,8 @@ X "munlock", /* 204 = munlock */ X /* "#205", 205 = nosys */ X "getsid", /* 205 = getsid */ X- "#206", /* 206 = nosys */ X+ /* "#206", 206 = nosys */ X+ "sched_yield", /* 206 = sched_yield */ X "#207", /* 207 = nosys */ X "#208", /* 208 = nosys */ X "#209", /* 209 = nosys */ X--- /sys/kern/syscalls.master.no_sched_yield Wed Dec 4 23:42:43 1996 X+++ /sys/kern/syscalls.master Wed Dec 4 23:44:28 1996 X@@ -280,7 +280,8 @@ X 204 STD 2 BSD munlock X ; 205 UNIMPL 0 NOHIDE nosys X 205 STD 1 BSD getsid X-206 UNIMPL 0 NOHIDE nosys X+; 206 UNIMPL 0 NOHIDE nosys X+206 STD 0 POSIX sched_yield X 207 UNIMPL 0 NOHIDE nosys X 208 UNIMPL 0 NOHIDE nosys X 209 UNIMPL 0 NOHIDE nosys X--- /sys/kern/kern_synch.c.no_sched_yield Tue Dec 24 13:12:02 1996 X+++ /sys/kern/kern_synch.c Tue Dec 24 11:25:33 1996 X@@ -681,3 +681,20 @@ X } X } X X+struct sched_yield_args { X+ void *arg; X+}; X+/* ARGSUSED */ X+int X+sched_yield (p, uap, retval) X+ struct proc *p; X+ struct sched_yield_args *uap; X+ int *retval; X+{ X+ need_resched (); /* Wild, isn't it? */ X+ X+ *retval = 0; X+ X+ return (0); X+} X+ X--- /usr/include/sys/syscall.h.no_sched_yield Tue Dec 24 13:19:56 1996 X+++ /usr/include/sys/syscall.h Tue Dec 24 12:23:18 1996 X@@ -193,3 +193,4 @@ X #define SYS_mlock 203 X #define SYS_munlock 204 X #define SYS_getsid 205 X+#define SYS_sched_yield 206 X--- /usr/include/unistd.h.no_sched_yield Tue Dec 24 13:18:59 1996 X+++ /usr/include/unistd.h Tue Dec 24 12:39:59 1996 X@@ -174,6 +174,7 @@ X int vhangup __P((void)); X void *valloc __P((size_t)); /* obsoleted by malloc() */ X pid_t vfork __P((void)); X+int sched_yield __P((void)); X #endif /* !_POSIX_SOURCE */ X __END_DECLS X X--- /sys/sys/syscall.h.no_sched_yield Tue Dec 24 13:22:52 1996 X+++ /sys/sys/syscall.h Tue Dec 24 12:23:56 1996 X@@ -193,3 +193,4 @@ X #define SYS_mlock 203 X #define SYS_munlock 204 X #define SYS_getsid 205 X+#define SYS_sched_yield 206 END-of-sched/sched_yield.Diffs echo x - sched/RTprio.diffs sed 's/^X//' >sched/RTprio.diffs << 'END-of-sched/RTprio.diffs' X--- /usr/src/usr.sbin/rtprio/rtprio.c.orig Sun Oct 2 06:48:21 1994 X+++ /usr/src/usr.sbin/rtprio/rtprio.c Tue Dec 26 11:18:20 1995 X@@ -63,6 +63,10 @@ X X if (!strcmp(p, "rtprio")) X rtp.type = RTP_PRIO_REALTIME; X+#ifdef RTP_PRIO_FIFO X+ else if (!strcmp(p, "rtfifoprio")) X+ rtp.type = RTP_PRIO_FIFO; X+#endif X else if (!strcmp(p, "idprio")) X rtp.type = RTP_PRIO_IDLE; X X@@ -76,8 +80,13 @@ X perror(argv[0]); X exit (1); X } X+ X printf("%s: ", p); X+ X switch (rtp.type) { X+ case RTP_PRIO_FIFO: X+ printf("hard realtime fifo priority %d\n", rtp.prio); X+ break; X case RTP_PRIO_REALTIME: X printf("realtime priority %d\n", rtp.prio); X break; END-of-sched/RTprio.diffs exit ------- End of Forwarded Message From owner-freebsd-hackers Thu Jan 30 11:09:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA25308 for hackers-outgoing; Thu, 30 Jan 1997 11:09:55 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA25303 for ; Thu, 30 Jan 1997 11:09:46 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id LAA24545 for ; Thu, 30 Jan 1997 11:10:47 -0800 (PST) Received: (qmail 23343 invoked by uid 110); 30 Jan 1997 19:09:15 -0000 MBOX-Line: From richard@deep-thought.org Thu Jan 30 16:04:40 1997 remote from suburbia.net Delivered-To: proff@suburbia.net Received: (qmail 20421 invoked from network); 30 Jan 1997 16:04:30 -0000 Received: from a42.deep-thought.org (203.4.184.227) by suburbia.net with SMTP; 30 Jan 1997 16:04:30 -0000 Received: by a42.deep-thought.org id m0vpyyg-0024vyC (Debian Smail-3.2 1996-Jul-4 #2); Fri, 31 Jan 1997 03:04:42 +1100 (EST) Message-Id: Date: Fri, 31 Jan 1997 03:04:42 +1100 (EST) X-Newsreader: knews 0.9.8 From: richard@deep-thought.org (Richard Jones) Subject: glibc-2.0 (aka libc-6) - new, experimental version of C library (fwd) To: proff@suburbia.net MIME-Version: 1.0 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Path: news.aus.world.net!nsw1.news.telstra.net!news.telstra.net!psgrain!iafrica.com!uct.uni.net.za!ru.uni.net.za!wits.uni.net.za!howland.erols.net!newsfeed.internetmci.com!nic.win.hookup.net!vertex.tor.hookup.net!nic.wat.hookup.net!omega.metrics.com!liw.clinet.fi!not-for-mail From: drepper@i44d2.ipd.info.uni-karlsruhe.de (Ulrich Drepper) Newsgroups: comp.os.linux.announce Subject: glibc-2.0 (aka libc-6) - new, experimental version of C library Followup-To: comp.os.linux.development.system Date: Wed, 29 Jan 1997 14:20:31 GMT Organization: University of Karlsruhe, Germany Lines: 866 Approved: linux-announce@news.ornl.gov (Lars Wirzenius) Message-ID: NNTP-Posting-Host: localhost X-Server-Date: 29 Jan 1997 14:20:39 GMT X-Original-Date: 27 Jan 1997 15:45:08 GMT X-Auth: PGPMoose V1.1 PGP comp.os.linux.announce iQBVAwUBMu9ctDiesvPHtqnBAQFSfQH+NCqxDJE8e6DAhOkbk8cfggTAozHxEG6K iENCdjdrwv739blp5QS6eZqflHSC0894S1NJyMPN+NfJcnSQSuRgSA== =6w4R X-Cache: nntpcache 1.0.1 (cf. ftp://nntpcache.org/nntpcache) -----BEGIN PGP SIGNED MESSAGE----- [ Moderator's note: This is about 36 kilobytes, but because it is of fundamental importance to the Linux community, I still approve it. --liw ] GNU libc 2.0 (aka libc-6) is available -------------------------------------- !!! BEFORE DOING *ANY* WORK WITH GNU LIBC READ THIS FILE ENTIRELY !!! The first release of the GNU libc for more than two years has the version number 2.0 and it is a big step to the complete GNU system. I've announced this package on the usual GNU announcement list using the text you find below. Here I only want to add some more points which are critical for all users of Linux: - - GNU libc 2.0 is the next major version of the libc, interface number 6. This means binaries compiled with the old libc will never use the new libc-6. But it is of course possible to run old and new binaries at the same time. - - This step in the interface number will hopefully be the last *forced* one. We think we now have ways to guarantee that we never have to create a new incompatible interface for the libc if we don't want to do so. I.e., this interface will be stable. Don't ask for details now. - - GNU libc 2.0 is titled "experimental". We are not yet ready for the general use. This will take some more weeks. But we are ready for a much wider audience. The code in the libc should be pretty stable. Due to some recent big changes the compilation environment might not yet be bug free, though. But this shouldn't be critical since the errors are obvious. - - Installing GNU libc 2.0 for the first time isn't trivial. I first thought I could provide a save installation procedure but due to the variety of systems out there this is no easy to solve problem. I don't take any responsibility on me if you mess up your system by installing glibc. If you are using a distribution you should probably wait until an upgrading package is available. If you set up your system yourself the following explanation should be enough: * for using libc-5 the next release of gcc will probably have a new target name: *-pc-linuxlibc5. So first create a directory /usr/i586-linuxlibc5 (use your architecture instead of i586 if necessary) * the old headers must be evacuated. Move /usr/include mv /usr/include /usr/i586-linuxlibc5/include * create a new directory mkdir /usr/include and create the necessary links for the kernel headers ln -s /usr/src/linux/include/linux /usr/include ln -s /usr/src/linux/include/asm /usr/include * create a directory for the libc-5 libraries mkdir /usr/i586-linuxlibc5/lib * add this directory *at the top* of your /etc/ld.so.conf file (you should also have ld.so-1.8.8 installed; otherwise you get strange messages once glibc is installed) * move all the libraries (*.a files, *.so files and the files the links point to) into the new directory. Once this is done you might have to rerun `ldconfig'. * Remove all files or links names *.so from /lib. I.e., remove all the files the linker will use. But do *not* remove the shared libraries itself! * you might want to save the files /etc/rpc /etc/localtime /usr/share/zoneinfo/* if available. But it is not critical and the files which come with GNU libc should be compatible with the old files. - - If your system still runs at this point you are almost set. You have possibilities: * use the binary release we provide. Binaries will be available for ix86 m68k alpha The alpha and m68k binaries may show up later since nobody gave me machines to do the work myself. * use the source and build the libc yourself The decision is also made by your machine and disk space. Compiling a complete GNU libc binary with shared, static and profiling libraries takes on my i586@133+64MB about 3 hours. If you do this you need disk space for 23 MB sources 100 MB object files 42 MB installation If you go with the binaries you only need the 42 MB. These number are for ix86 (I use debugging info which makes the sizes explode). The m68k you'll probably get comparable numbers and for alpha they will probably even higher. - - If you decide to compile glibc yourself you need beside the disk space * the three add-ons crypt linuxthreads localedata (optional) Please note the export restriction for the crypt add-on. Non-US users should get it from the European site at ftp://ftp.ifi.uio.no/pub/gnu * GNU make 3.75 * gcc >= 2.7.2 (better 2.7.2.1) * binutils 2.7 (for alpha you even need a snapshot) * if something you changed something in the configure files you need autoconf-2.12. You should have: * bash-2.0 - - to start the compilation you need to install the add-ons tar xf glibc-2.0.tar cd glibc-2.0 tar xf ../glibc-linuxthreads-2.0.tar tar xf ../glibc-crypt-2.0.tar tar xf ../glibc-localedata-2.0.tar and start the configure script using the extra argument ../configure --enable-add-ons=linuxthreads,crypt,localedata ... (Here I already imply that you should create a subdirectory in the glibc source directory. Since we have not yet paid much attention to the `make clean' goal this is probably the only way to get the source tree clean again.) - - compile, check, and install the library (after you've saved the old environment as described above) make make check make install Use the CFLAGS make variable to decide about optimization. - - in any case you now have to prepare the gcc for the new library. Even if you used the binary distribution you have to do this step. The section from the FAQ file in the glibc distribution explaining what is to do follows. Before you change anything copy the files below /usr/lib/gcc-lib/i586-linux to /usr/lib/gcc-lib/i586-linuxlibc5 (please note that this name is the same as used above!) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [Q16] ``When I use GNU libc on my Linux system by linking against to libc.so which comes with glibc all I get is a core dump.'' [A16] {UD} It is not enough to simply link against the GNU libc library itself. The GNU C library comes with its own dynamic linker which really conforms to the ELF API standard. This dynamic linker must be used. Normally this is done by the compiler. The gcc will use -dynamic-linker /lib/ld-linux.so.1 unless the user specifies her/himself a -dynamic-linker argument. But this is not the correct name for the GNU dynamic linker. The correct name is /lib/ld.so.1 which is the name specified in the SVr4 ABi. To change your environment to use GNU libc for compiling you need to change the `specs' file of your gcc. This file is normally found at /usr/lib/gcc-lib///specs In this file you have to change a few things: - - change `ld-linux.so.1' to `ld.so.1' (or to ld-linux.so.2, see below) - - remove all expression `%{...:-lgmon}'; there is no libgmon in glibc Things are getting a bit more complicated if you have GNU libc installed in some other place than /usr, i.e., if you do not want to use it instead of the old libc. In this case the needed startup files and libraries are not found in the regular places. So the specs file must tell the compiler and linker exactly what to use. Here is for example the gcc-2.7.2 specs file when GNU libc is installed at /usr: - ----------------------------------------------------------------------- *asm: %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} *asm_final: %{pipe:-} *cpp: %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} *cc1: %{profile:-p} *cc1plus: *endfile: %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s *link: - -m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}} *lib: %{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}} *libgcc: - -lgcc *startfile: %{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s} *switches_need_spaces: *signed_char: %{funsigned-char:-D__CHAR_UNSIGNED__} *predefines: - -D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) *cross_compile: 0 *multilib: ; - ----------------------------------------------------------------------- The above is currently correct for ix86/Linux. Because of compatibility issues on this platform the dynamic linker must have a different name: ld-linux.so.2. So you have to replace %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld-linux.so.2} by %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld.so.1} in the above example specs file to make it work for other systems. Future versions of GCC will automatically provide the correct specs. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now you should be ready for using GNU libc. Please take the system as what it is currently: experimental. There are a lot of machines out there which only use GNU libc but this does not mean everything works now. You should start compiling some programs and try to run them. Always remember that you should be able to compile binaries for libc-5 using the -b i586-linuxlibc5 option to gcc. Now some more comments to news for glibc on Linux. The whole library is not a "port" of the Linux libc back into GNU libc. Instead almost all things are written for GNU libc and some are also used in the Linux libc (e.g., the whole internationalization subsystem). So you should not expect the new libc to behave exactly like libc-5. We corrected some functions and made others more compliant with the general rules of GNU. Please consult the FAQ file in the distribution for some examples. One of the biggest changes was that the interface to the kernel is abstracted. I.e., where libc-5 simply used system calls and uses the kernel headers this does not happen anymore for libc-6. In fact almost no kernel header file is used anymore! I know several people had problems with this decision but - Linus is happy since he does not has to pay attention to the users of the libc when changing headers - distribution builders are happy since their distributions do not depend on a special kernel version and may become obsolete when something changed in the kernel (note that Debian already uses this method) - the libc maintainer is happy since he also has not change the library and headers to follow a moving target - we were able to implement changes in the libc which are not yet available in the kernel (e.g., using larger types for central types like uid_t and gid_t and, most important, sigset_t). If you ask me what the most noticeable change from libc-5 to libc-6 is I would answer: multi-threading. GNU libc uses one thread implementation (Xavier Leroy's LinuxThreads, a special version) and it fully exploits it. The whole libc is thread safe, functions with non-reentrant interface have a reentrant counterpart. The stdio implementation is really thread safe and not partly as done in libc-5 with all the hacks. The second big advantage has the name NSS. This is a scheme for handling name databases. This scheme originally comes from Solaris and it provides a clean and extendable way to handle the different lookup schemes. Currently we support: plain file, database file, DNS, NIS and a compatibility mode for NIS. Future releases will support NIS+ and hesiod and perhaps some more. The interface for these modules, which are implemented in shared libs, is documented in the GNU libc manual and so everybody can write a new model her/himself. Side note: Sun has a similar implementation for Solaris where all the modules are shared objects. The difference is that you cannot generate a static application using any lookup function on Solaris. The GNU dynamic loader does not have this limitation.) The math library should be much more correct and often also faster. The GNU libc also has several new functions from POSIX and XPG4.2 and is overall very much closer to comply with all the standards out there. I can run the POSIX test suite without many problems. Finally a word to the complains I heard in the past. Some people love to speak about the "bureaucrats at the FSF" and the slow development. I don't think this deserves a reply but the feeling I mean to recognize here is: The FSF is not able to keep the pace with the fast development in the Linux community. I want to add several comments here: 1. Before starting to work entirely on the GNU libc I help HJ a lot in writing the Linux libc and even after that point many (most?) of the new code in the Linux libc came from the GNU libc and was written by me. So I very well know the speed of the development on Linux since I was responsible for it sometimes. 2. When people complain about "bureaucrats" this mainly means that we always require assignments. It is true that this is sometimes problematic. But let's take the following example: ``GNU and the whole free software slowly has more influence on the software market than many of the companies want. Somebody the leader of one of the evil companies, let's call it `Hellsware', decides to corrupt the FSF. They let one of their employers offer some new and interesting code to the FSF but refuse to send an assignment. Now they wait until the FSF heavily uses the code and suddenly they claim that the code is their own property and that is is patented. They fire the employer (after giving her/him lots of money to not tell the story) and sue the FSF. Given the American justice system and the amount of money available for the defense the result is foreseeable.'' With an assignment the FSF would be in a much stronger situation. The employer would have declared that the code is usable without restriction (e.g., patents) and so the FSF can always declare they never knew about the misuse. You can decide: live with free software or with only one evil company left? 3. Many (especially commercial) users of Linux in fact *do* want to see a slower change of the code. We try to fit there needs with our release scheme. 4. For a few GNU packages (including GNU libc) we now use GNATS for handling bug reports. The `glibcbug' script which comes with the GNU libc should be used to report bugs. An WWW interface to GNATS will hopefully soon be available so that you should be able to follow the status of your bug report and also examine old problem reports. A plea: please do *not* (exclusively) end bug reports to the Linux mailing lists. I don't read them regularly since there is far too much noise. Use the `glibcbug' script. 5. We will use a release scheme for glibc which is now also in use for gcc. I.e., 2.0.x will go on until we reached a stable version. In the meantime we will start working on glibc-2.1. One final word: *please* read all the available documentation before reporting a bug (perhaps excluding the manual though this would be good as well). I cannot and will not answer questions answered in these docs. Please with high email traffic will agree that there must be a cutoff. I don't speak about 50 mails a day. Please also consult the WWW pages for the GNU libc at http://www.gnu.org/software/libc/libc.html I'll hopefully update and extend these pages so keep looking. Thanks for reading through all this and I hope we all work good together in making the GNU libc the best libc available in the universe. At this point I want to thank again my fellow workers in the very busy last months. Roland McGrath, former glibc maintainer Andreas Schwab, for the m68k port and constantly repairing what I break. Richard Henderson, David Mosberger-Tang for the DEC Alpha port Hongjiu Lu, for lots of the underlying code for ix86 and constant real-life checks Ralf Baechle, for the MIPS port Miguel de Icaza, for the Sparc port Xavier Leroy, for the LinuxThreads package Wolfram Gloger & Doug Lea for the new malloc Thorsten Kukuk, for the NIS implementation Many of bugs were found due to the constant nit picking by Andreas Jaeger a sun Thanks to all of them! - -- Uli - ---------------. drepper@cygnus.com ,-. Rubensstrasse 5 Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany Cygnus Solutions `--' drepper@gnu.ai.mit.edu `------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Version 2.0 of the GNU C library is now available for anonymous FTP from prep.ai.mit.edu in the file glibc-2.0.tar.gz (about 3.8 megabytes gzip'd). No diffs are available to the 1.09.1 release since the diffs would be much larger than the sources itself. The `crypt' DES encryption code is in glibc-crypt-2.0.tar.gz (about 30k gzip'd). Please note that it is illegal under US federal law to export this software outside the United States. Those outside the USA can get the file from ftp://ftp.ifi.uio.no/pub/gnu [129.240.64.21] instead. You do NOT need the crypt package to build the rest of the C library. The C library contains sources for a MD5 based "encryption" so that the crypt functions are available. If the machine works in a networked environment it is useful to use the crypt package, though. Beside the crypt package there are two more "add-ons" available for use in the GNU C library. They are available at the same places like the glibc-2.0.tar.gz file itself: * glibc-linuxthreads-2.0.tar.gz is a clone(2) based POSIX thread implementation for Linux. * glibc-localedate-2.0.tar.gz are the POSIX locale specification and character set definition which are used in the `localedef' tool to produce locale information files which are used the C library functions. This is a major new release. It is not possible to list all the changes which happened in the last two years. At the bottom of this mail you find a list of the most important changes, taken from the `NEWS' file in the distribution. The GNU C library is a complete drop-in replacement for libc.a on Unix. On systems which support shared libraries the GNU C library will also be installed as a shared library. It conforms to the ANSI C standard (including amendment 1), POSIX.1:1996, and XPG4.2, has most of the functions specified by POSIX.2, and is intended to be upward compatible with 4.3 and 4.4 BSD. It also has several functions from System V and other systems, plus GNU extensions. The current version of the GNU C library is ported to only a few systems: *-*-gnu GNU Hurd i386-*-linux-gnu Linux/GNU on Intel ix87 m68k-*-linux-gnu Linux/GNU on Motorola m680x0 alpha-*-linux-gnu Linux/GNU on DEC Alpha The ports to sparc-*-linux-gnu and mips-*-linux-gnu are nearly finished. On these platforms the GNU C library is intended to be the standard C library. On Linux the 2.0 version of the GNU libc will be used as the libc-6, superceding the Linux based GNU C library version 5. Former versions of this library ran on a wide variety of systems. Currently there are efforts to port GNU libc again to sparc-*-sysv, sparc-sun-solaris2, mips-sgi-irix5, and mips-sgi-irix6. Porting the GNU C library to modern systems is not hard. People interested in porting the library should read the WWW page on porting http://www.gnu.org/software/libc/porting.html and get on the mailing (see below). The INSTALL file now includes some porting instructions which should help people get started. If you have questions, or are doing a port, tell the mailing list about it. All bug reports for the GNU C library should be sent using the `glibcbug' shell script which comes with the GNU libc to mailto://bugs@gnu.ai.mit.edu Suggestions and questions should be send to to the mailing list mailto://bug-glibc@prep.ai.mit.edu If you don't read the gnewsgroup gnu.bug.glibc, you can subscribe to the list by asking: mailto://bug-glibc-request@prep.ai.mit.edu Please DO NOT send bug report for the GNU C library to . That list is for bug reports for GNU CC. GNU CC and the GNU C library are separate entities maintained by separate people. If you send patches, please also report what the bugs you think you are fixing are! Fill in all fields in the form presented to you by the `glibcbug' script. Large mounds of patches with comments like "foobar was broken", or "foobar didn't handle frobnication right" are very difficult to deal with. Unless you tell me, I have no way of knowing how to reproduce the bugs you found and figure out the right solution, and I cannot assume that your solution is correct. The Texinfo source for the GNU C Library Reference Manual comes along with the C library. This manual documents all the library facilities, both what Unix terms ``system calls'' (section 2) and ``library functions'' (section 3). Before printing the manual, beware that it is more than 700 pages long, so you may well be better off ordering a printed copy from the FSF than trying to print it yourself. Unfortunately, we have not had the time to update the manual recently. At this point I would like to thank all the people who made this software possible by providing code or by testing and debugging. The ChangeLog file gives you an impression of the amount of work which was done. - -- Uli - ---------------. drepper@cygnus.com ,-. Rubensstrasse 5 Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany Cygnus Solutions `--' drepper@gnu.ai.mit.edu `------------------------ Version 2.0 * GNU extensions are no longer declared by default. To enable them you must define the macro `_GNU_SOURCE' in your program or compile with `-D_GNU_SOURCE'. * The library has changed from using GNU ld symbol aliases to using weak symbols where available. The ELF object file format supports weak symbols; GNU ld also supports weak symbols in the a.out format. (There is also now support for other GNU ld extensions in ELF. Use the `--with-elf' option to configure to indicate you have ELF, and `--with-gnu-ld' if using GNU ld.) This change resulted in the deletion of many files which contained only symbol aliases, reducing the size of the source and the compiled library; many other files were renamed to less cryptic names previously occupied by the symbol alias files. There is a new header file for programs which operate on files in the ELF format. * Converted to Autoconf version 2, so `configure' has more options. Run `configure --help' to see the details. * The library can now be configured to build profiling, highly-optimized (but undebuggable), and/or shared libraries (ELF with GNU ld only). The `--enable-profile', `--enable-omitfp', and `--enable-shared' options to `configure' enable building these extra libraries. The shared library is built by default when using both ELF and GNU ld. When shared libraries are enabled, the new library `-ldl' is available for arbitrary run-time loading of shared objects; its interface is defined in . The new header file gives access to the internals of the run-time dynamic linker, `ld.so'. The shell script `ldd' is similar to the application of same name on other systems and it provides information about dynamically linked binaries. * The C library now provides the run-time support code for profiling executables compiled with `-pg'. Programs can control the profiling code through the interface in . The `gmon.out' files written by the GNU C library can be read only by GNU `gprof' (from GNU binutils); the support for this file format was contributed by David Mosberger-Tang. * The math code has been replaced with a math library based on fdlibm from Sun, and modified by JT Conklin and Ulrich Drepper with i387 support, by Ian Taylor with `float' functions and by Ulrich Drepper with `long double' functions. The math functions now reside in a separate library, so programs using them will need to use `-lm' their linking commands. * John C. Bowman contributed optimized ix87 assembler inline functions. * Ulrich Drepper has contributed support for an `/etc/nsswitch.conf' mechanism similar to that found in Solaris 2. This is now used for the group, passwd, hosts, networks, services, protocols, rpc, ethers, shadow, netgroup, publickey, and alias databases. The `nsswitch.conf' file controls what services are used for each individual database. This works by loading shared libraries with names specified in `nsswitch.conf', so service modules can be changed or added at any time without even relinking any program. Currently there are the file, db, and NIS based NSS services available. * The new functions `strtoq' and `strtouq' parse integer values from strings, like `strtol' and `strtoul', but they return `long long int' and `unsigned long long int' values, respectively (64-bit quantities). * The new functions `strtof' and `strtold' parse floating-point values from strings, like `strtod', but they return `float' and `long double' values, respectively (on some machines `double' and `long double' are the same). * Ulrich Drepper has contributed new implementations of the floating-point printing and reading code used in the `printf' family of functions and `strtod', `strtof', and `strtold'. These new functions are perfectly accurate, and much faster than the old ones. * The implementation of the POSIX locale model was completely rewritten by Ulrich Drepper. This includes the new programs `localedef' and `locale' to compile the POSIX locale definition. * The former dummy implementations of the strcoll and strxfrm function are now replaced by fully functional code contributed by Ulrich Drepper. The collation information comes from the POSIX locale definitions. * The new header defines an interface for accessing various locale-dependent data (using the locale chosen with `setlocale'). * Ulrich Drepper has contributed a new suite of functions for operation on wide-character and multibyte-character strings, in ; and classification and case conversion of wide characters, in . These new functions are conforming to the ISO C, Amendement 1 specification. * There is now a second implementation of the standard I/O library available. It comes from GNU libg++ as was written by Per Bothner, heavily modified by Hongjiu Lu and made thread safe by Ulrich Drepper. * You can now use positional parameter specifications in format strings for the `printf' and `scanf' families of functions. For example, `printf ("Number %2$d, Mr %1$s\n", "Jones", 6);'' prints ``Number 6, Mr Jones''. This is mainly useful when providing different format strings for different languages, whose grammars may dictate different orderings of the values being printed. To support this feature, the interface for `register_printf_handler' has changed; see the header file for details. * The `printf' and `scanf' families of functions now understand a new formatting flag for numeric conversions: the ' flag (e.g. %'d or %'f) says to group numbers as indicated by the locale; for `scanf' and friends, this says to accept as valid only a number with all the proper grouping separators in the right places. In the default "C" locale, numbers are not grouped; but locales for specific countries will define the usual conventions (i.e. separate thousands with `,' in the US locale). * The pgrp functions have been regularized, slightly incompatibly but much less confusingly. The core functions are now `getpgid' and `setpgid', which take arguments for the PID to operate on; the POSIX.1 `getpgrp' (no argument) and BSD `setpgrp' (identical to `setpgid') functions are provided for compatibility. There is no longer an incompatible `getpgrp' with an argument declared under _BSD_SOURCE; no BSD code uses it. * The new header file and suite of functions simplify programs that operate on directory trees. This code comes from 4.4 BSD. * The resolver code has been updated from the BIND 4.9.5-P1 release. Parts of the code were heavily modified by Ulrich Drepper to fit in the NSS scheme used in glibc. * The new function `malloc_find_object_address' finds the starting address of a malloc'd block, given any address within the block; `malloc_object_allocated_size' returns the size of an allocated block; and `malloc_walk' lets you walk through all allocated blocks. These can be useful for debugging; see for the interfaces. * There is a new malloc debugging hook `__memalign_hook'. * There are new typedefs `ushort' for `unsigned short int' and `uint' for `unsigned int' in . These are for compatibility only and their use is discouraged. * The `-lmcheck' library to enable standard malloc debugging hooks is now done differently, so that it works even without GNU ld. * New function `euidaccess' checks allowed access to a file like `access', but using the effective IDs instead of the real IDs. * The time zone data files have been updated for the latest and greatest local time conventions of the countries of the world. * The new function `dirfd' extracts the file descriptor used by a DIR stream; see . * The new functions `ecvt', `fcvt', and `gcvt' provide an obsolete interface for formatting floating-point numbers. They are provided only for compatibility; new programs should use `sprintf' instead. There are also equivalent function for the `long double' floating-point type and all functions also exist in a reentrant form. * The new auxiliary library `-lutil' from 4.4 BSD contains various functions for maintaining the login-record files (primarily of use to system programs such as `login'), and convenient functions for allocating and initializing a pseudo-terminal (pty) device. * Ulrich Drepper has contributed new support for System V style shared memory and IPC on systems that support it. * Ulrich Drepper has contributed several miscellaneous new functions found in System V: The `hsearch' family of functions provide an effective implementation of hash tables; `a64l' and `l64a' provide a very simple binary to ASCII mapping; `drand48' and friends provide a 48-bit random number generator. * Ulrich Drepper has contributed new reentrant counterparts for the `random' and `hsearch' families of functions; `random_r', `hsearch_r', etc. * Ulrich Drepper has contributed new, highly-optimized versions of several string functions for the i486/Pentium family of processors. * Ulrich Drepper has updated the Linux-specific code, based largely on work done in Hongjiu Lu's version of GNU libc for Linux. The GNU library now supports Linux versions 2.0.10 and later, using the ELF object file format (i[3456]86-*-linux). * Andreas Schwab has ported the C library to Linux/m68k (m68k-*-linux). * David Mosberger-Tang and Richard Henderson have ported the C library to Linux/Alpha (alpha-*-linux). Richard Henderson contributed the dynamic linking support for ELF/Alpha. * Richard Henderson contributed several Alpha optimized assembler function for arithmetic and string handling. * Ulrich Drepper has contributed a new set of message catalog functions to support multiple languages using the interface, for use with his new package GNU gettext. Translation volunteers have contributed catalogs of the library's messages in Spanish, German, and Korean. * For compatibility with XPG4, Ulrich Drepper has contributed the `gencat' program and the `catgets' function for reading the catalog files it creates. (The interface is preferred; we include the interface using `catgets' only for source compatibility with programs already written to use it.) * New header file gives SVID-compatible names for constants. * Various new macros, declarations, and small header files for compatibility with 4.4 BSD. * New function `group_member' is a convenient way to check if a process has a given effective group ID. * When using GCC 2.7 and later, the socket functions are now declared in a special way so that passing an argument of type `struct sockaddr_in *', `struct sockaddr_ns *', or `struct sockaddr_un *' instead of the generic `struct sockaddr *' type, does not generate a type-clash warning. * New function `error' declared in header file is a convenient function for printing error messages and optionally exiting; this is the canonical function used in GNU programs. The new functions `err', `warn', and friends in header file are the canonical 4.4 BSD interface for doing the same thing. * The interface has several new flags from 4.4 BSD that extend the POSIX.2 `glob' function to do ~ and {...} expansion. * New function `unsetenv' complements `setenv' for compatibility with 4.4 BSD. `clearenv' which is used in POSIX.9 is also available. * New function `getsid' returns session ID number on systems that support it. * We have incorporated the 4.4 BSD `db' library (version 1.85). New header files and provide a rich set of functions for several types of simple databases stored in memory and in files, and is an old `ndbm'-compatible interface using the `db' functions. Link with `-ldb' to get these functions. * New macro `strdupa' copies a string like `strdup', but uses local stack space from `alloca' instead of dynamic heap space from `malloc'. * New function `strnlen' is like `strlen' but searches only a given maximum number of characters for the null terminator. `stpncpy', `strndup' and `strndupa' are similar variants for the `stpcpy', `strdup' and `strdupa' function. * New function `statfs' in header . * The new and interfaces contributed by Miles Bader provide convenient functions for operating on blocks of null-terminated strings. * A new suite of functions in handle all the details of reading and writing the utmp file. * An implementation of the NIS/YP(tm) based NSS service was contributed by Thorsten Kukuk. * Paul Eggert and Ulrich Drepper modified the `strftime' function to be completely POSIX compliant and also implemented the extended functionality to handle alternate digit representation and alternate era date formats. * Ulrich Drepper provided an implementation of the `strptime' function defined in XPG4.2 which transforms a string into a `struct tm' value. * Paul Eggert provided the tzselect shell script as part of the timezone code. The shell script makes it easy to select the correct timezone specification. * The implementation of the malloc family of functions is completely replaced by a new implementation by Doug Lea with many improvements by Wolfram Gloger. The implementation uses the mmap function (if available) and it is optimized for the use in multi threaded programs. * Ulrich Drepper contributed a MD5 "encryption" for the crypt family of functions. This new functionality is usable by specifying a special salt string and it is compatible with implementation on *BSD systems. * Lots of functions from the XPG4.2 standard were added by Ulrich Drepper: `getsubopt' to handle second level command line options, `bsd_signal' to access BSD style `signal' functionality, the obsolete `regexp' style expression matcher. * the `lchown' function is available on system which support this functionality. * The implementation of the shadow password handling function was contributed by Ulrich Drepper. * David Mosberger-Tang changed the SunRPC implementation to be 64bit safe. * POSIX.1g support was added. The header is available, `isfdtype' and `pselect' are implemented. Craig Metz contributed an implementation of `getaddrinfo'. - -- - -- Uli - ---------------. drepper@cygnus.com ,-. Rubensstrasse 5 Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany Cygnus Solutions `--' drepper@gnu.ai.mit.edu `------------------------ -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMu9cT4QRll5MupLRAQHMlwQAmunhPDH5G8GS9fXdRsJ9rkJAYntSLnqU +2e5HP3xwXM4+klnYEuhGIMRHCu14gWDnlrapYOBQZHPMd7hJsTOwUinDjyMVxnv eM4DexYtx15GlITvkKlhEIgt0iuMDjZvFC3yeQCFmJ+VynL2sTbahuGz2PP58Prs 03BJUe5Cr5o= =zMug -----END PGP SIGNATURE----- -- This article has been digitally signed by the moderator, using PGP. http://www.iki.fi/liw/lars-public-key.asc has PGP key for validating signature. Send submissions for comp.os.linux.announce to: linux-announce@news.ornl.gov PLEASE remember a short description of the software and the LOCATION. This group is archived at http://www.iki.fi/liw/linux/cola.html From owner-freebsd-hackers Thu Jan 30 11:13:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA25477 for hackers-outgoing; Thu, 30 Jan 1997 11:13:26 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA25466 for ; Thu, 30 Jan 1997 11:13:09 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id UAA29216; Thu, 30 Jan 1997 20:14:25 +0100 (MET) From: Søren Schmidt Message-Id: <199701301914.UAA29216@ravenock.cybercity.dk> Subject: Re: ipdivert & masqd In-Reply-To: <3.0.32.19970130190212.00b22780@dimaga.com> from Eivind Eklund at "Jan 30, 97 07:02:14 pm" To: eivind@dimaga.com (Eivind Eklund) Date: Thu, 30 Jan 1997 20:14:15 +0100 (MET) Cc: imp@village.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Eivind Eklund who wrote: > At 08:04 AM 1/30/97 -0700, you wrote: > >In message <199701292038.MAA19786@freefall.freebsd.org> Darren Reed writes: > >> It is a *much* better idea to redirect IRC to a local TCP port and process > >> it using a proxy agent. Same could also be said for FTP. > > > >Yes. It is. However, you also have to do the same for Talk, Real > >Audio and at least one other protocol that encodes either the IP > >address or ports of the system. > > I'm thinking about doing transparent proxying for the protocols, but I want > to see how well the packet-patching version run first. As it is, it is > (hopefully) right in 99% of the cases, and it scales well. If I get > reports of real-life problems I'll make it a priority to make proxies, but > not before. > (And the packet-patchers will still be an option - for most people, they > probably are a better or as good solution.) Hmm, I've done a NAT implementation, and my experience tells me that doing ftp, irc, realaudio etc in the NAT itself, (I like the name packet-patchers :) ) is the most efficient way of doing things, and it saves the user for all that proxy fiddleing, they see the world as if they where on the net directly... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Jan 30 11:15:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA25575 for hackers-outgoing; Thu, 30 Jan 1997 11:15:01 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA25555 for ; Thu, 30 Jan 1997 11:14:56 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id LAA28704; Thu, 30 Jan 1997 11:11:50 -0800 (PST) Date: Thu, 30 Jan 1997 11:11:49 -0800 (PST) From: Chris Coleman To: Terry Lambert cc: mcgovern@spoon.beta.com, mark@quickweb.com, msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <199701301654.JAA22125@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Terry Lambert wrote: > > > > If anyone else is working on a title, or has anything partially started I > > would like to hear form them, so we can get organized and not duplicate > > each other work. > > What is the intent of your book? What specific areas will it cover? > I want to aim my book at the first time FreeBSD Users. I will cover Installation and setup. Basically I want a to cover all the questions that I had when i First got started. I am open to ideas about what else could be included. I have put up a tenative Table of Contents on My Web page. > What kind of existing material are you looking for? If anyone has somthing that they think needs to appear in a book about FreeBSD, I think that is what im looking for. For example, i hear alot about device drivers, I wouldn't be able to write much of a chapter on that, but if someone wanted to contribute. I would be happy to include it. Also, I am going to try and include alot of Warnings and Cautions and Notes to the reader about common mistakes. I know i made alot of them. I am going to work on it as though I was the only one Working on it, but I think this will end up a collective effort. I definately need to keep in touch with the developers to make sure I am correct in my advice to the readers. Basically i Am hoping that there is enough people putting together piece-meal documentation, that it might fill in the areas of the book that my knowledge lacks. Thanks Christopher J. Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html Death is life's way of telling you you're fired. From owner-freebsd-hackers Thu Jan 30 11:45:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA27231 for hackers-outgoing; Thu, 30 Jan 1997 11:45:53 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA27226 for ; Thu, 30 Jan 1997 11:45:51 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Thu, 30 Jan 97 20:45 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for rminnich@Sarnoff.COM id ; Thu, 30 Jan 97 20:45 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA23376; Thu, 30 Jan 97 18:53:18 +0100 Date: Thu, 30 Jan 97 18:53:18 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9701301753.AA23376@wavehh.hanse.de> To: rminnich@Sarnoff.COM Cc: freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads Newsgroups: hanse-ml.freebsd.hackers References: <199701301149.AA268284982@fakir.india.hp.com> Reply-To: cracauer@wavehh.hanse.de Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk rminnich@Sarnoff.COM (Ron G. Minnich) wrote: [rfork] >VM space handling is a little different. If you request VM space sharing, >you don't exactly get Vm address space sharing: what you get is instead >shared data areas where in normal fork they are copied. More details on >request. The effect is what you want, though: shared data areas. Could you explain a bit more. What exactly is the difference between VM space sharing and shared data areas from the process' and the kernel perspective? Thanks Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin_Cracauer@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin From owner-freebsd-hackers Thu Jan 30 12:03:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA28111 for hackers-outgoing; Thu, 30 Jan 1997 12:03:46 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA28102 for ; Thu, 30 Jan 1997 12:03:43 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA28257; Thu, 30 Jan 1997 12:02:45 -0800 (PST) Received: from alpo.whistle.com(207.76.205.1) by whistle.com via smap (V1.3) id sma028241; Thu Jan 30 12:02:17 1997 Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id LAA06035; Thu, 30 Jan 1997 11:58:46 -0800 (PST) Message-ID: <32F0FD13.41C67EA6@whistle.com> Date: Thu, 30 Jan 1997 11:57:07 -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: Chris Coleman , mcgovern@spoon.beta.com, mark@quickweb.com, msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) References: <199701301654.JAA22125@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > Therefore, If you don't like the documentation, Write something. Even if > > it is just a well documented complaint. I will be accepting > > contributions, and criticizm and whatever helpful things you have to > > offer. So stop complaining about What doesn't work and What isnt > > documented, And do something. > > > > If anyone else is working on a title, or has anything partially started I > > would like to hear form them, so we can get organized and not duplicate > > each other work. > > What is the intent of your book? What specific areas will it cover? > What kind of existing material are you looking for? how will it differ from the "FreeBSD book" that Walnut Creek CDROM sell? > > 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 Jan 30 12:07:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA28336 for hackers-outgoing; Thu, 30 Jan 1997 12:07:59 -0800 (PST) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA28328 for ; Thu, 30 Jan 1997 12:07:48 -0800 (PST) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.5/8.8.5) with SMTP id PAA06463; Thu, 30 Jan 1997 15:07:05 -0500 (EST) Date: Thu, 30 Jan 1997 15:07:05 -0500 (EST) From: John Fieber To: "David E. Cross" cc: hackers@freebsd.org Subject: Re: Motif 2.0.1 In-Reply-To: <199701300553.AAA00562@phoenix.its.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, David E. Cross wrote: > I have access to the sources to Motif 2.0.1 (under my university's site > license)... However I have yet to successfully compile motif 2.0.1 on > 2.1.6-RELEASE (or any version)... Is there anyone out there who has gotten > it working, and could give me a few pointers? No, but issues such as these are addressed http://www.primate.wisc.edu/software/imake-stuff/. I had read somewhere that one of the "fixes" in 2.0.1 was to make it work with X11R6. It could be an urban legend though. Are you encountering makefile problems or actual code compiling problems? In the 2.0 release, quite a bit of Imakefile tweaking was necessary before it would work. The only code bogons were in the demos. Indiana University didn't renew the source license so we get no 2.0.1 update. :( -john From owner-freebsd-hackers Thu Jan 30 12:27:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA29197 for hackers-outgoing; Thu, 30 Jan 1997 12:27:56 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA29187 for ; Thu, 30 Jan 1997 12:27:39 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id VAA07518 for ; Thu, 30 Jan 1997 21:26:51 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id VAA29858 for hackers@freebsd.org; Thu, 30 Jan 1997 21:26:27 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id VAA16132; Thu, 30 Jan 1997 21:17:42 +0100 (CET) Message-ID: <19970130211742.TN38393@keltia.freenix.fr> Date: Thu, 30 Jan 1997 21:17:42 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: ipdivert & masqd References: <3.0.32.19970130190212.00b22780@dimaga.com> <199701301914.UAA29216@ravenock.cybercity.dk> X-Mailer: Mutt 0.59/1-2,4,7-8,10-14 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 3.0-CURRENT ctm#2975 In-Reply-To: =?iso-8859-1?Q?=3C199701301914=2EUAA29216=40ravenock=2Ecybercity=2Edk=3E?= =?iso-8859-1?Q?=3B_from_S=F8ren_Schmidt_on_Jan_30=2C_1997_20=3A14=3A15_+?= =?iso-8859-1?Q?0100?= Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Søren Schmidt: > and it saves the user for all that proxy fiddleing, they see the > world as if they where on the net directly... ...but make user authentication a nightmare (if it can't be done at all). In my former job as a security consultant, user identification & authentication was a big plus of our product. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #37: Mon Jan 27 23:21:10 CET 1997 From owner-freebsd-hackers Thu Jan 30 12:43:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA29951 for hackers-outgoing; Thu, 30 Jan 1997 12:43:48 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA29945 for ; Thu, 30 Jan 1997 12:43:44 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id PAA05114; Thu, 30 Jan 1997 15:42:28 -0500 (EST) Date: Thu, 30 Jan 1997 15:42:28 -0500 (EST) From: Mark Mayo To: Terry Lambert cc: "Brian J. McGovern" , hackers@freebsd.org Subject: Re: Followup to criticism (was: Constructive criticism) In-Reply-To: <199701301725.KAA22242@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Terry Lambert wrote: > > Hmm. Talk about dropping a rock on a wasps nest :) I don't think I've > > gotten more email on any subject I've ever written about. At least its > > good to know that its a passionate subject. However, I started > > to get nervous when Terry backed me up (Sorry, Terry ;p ). I never meant > > to it be negative (more of an impassioned plea for attention was my goal), > > and I apologize to anyone wo got irritated. > > You say that like it's a bad thing... > > Just because I back something up doesn't mean it's negative. > > Though I will admit, I'll get down there in the muddy rut with my > riding crop and whack and scream and foam at the mouth... [SNIP] Now this is truly funny :-) Great stuff Terry - I knew you had a sense of humour lying behind that foaming mouth ;-) And no, it doesn't make you a bad person IMHO - I quite enjoy your posts, and greatly appreciate your willingness to disclose your knowledge to the masses (no matter how it is accepted..) -Mark ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) > > "Get the wagon out of the rut! Quit pushing forward, you > are trying to move seven tons of mud that are in front > of the wheels! Get the wagon out of the rut! I don't > care if all you see is the back of a wagon, the sen tons > of mud are there! Get the wagon out of the rut! When you > push wheels into mud, the mud bunches up in front of the > wheels and makes it much harder to push next time! Get > the wagon out of the rut! If you just use these four > ugly boards for a short time, you can be out of the rut! > Get the wagon out of the rut!" > > ...or I'll sit back where it's dry... > > "Pave the road! Ruts are stupid! Pave the road! If > you'd only pave your roads, you wouldn't *get* ruts in > the first place! Pave the road! Look, you're going to > be driving back and forth over this thing for the next > ten years! Pave the road! The time spent paving will > be paid for in decreased travel time! Pave the road! > How can you justify the travel time you spend in ruts? > Pave the road! What, are you an idiot who *likes* > ruts for some damn reason? Pave the road!" > > ...when I think it's appropriate. > > Doesn't make me a bad person. > > 8-). > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Thu Jan 30 12:46:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA00272 for hackers-outgoing; Thu, 30 Jan 1997 12:46:13 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA00265 for ; Thu, 30 Jan 1997 12:46:10 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id MAA29121; Thu, 30 Jan 1997 12:42:59 -0800 (PST) Date: Thu, 30 Jan 1997 12:42:59 -0800 (PST) From: Chris Coleman To: Julian Elischer cc: Terry Lambert , mcgovern@spoon.beta.com, mark@quickweb.com, msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <32F0FD13.41C67EA6@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Julian Elischer wrote: > > > > What is the intent of your book? What specific areas will it cover? > > What kind of existing material are you looking for? > > how will it differ from the "FreeBSD book" that Walnut Creek CDROM sell? I have to document the 5 existing FreeBSD Machines that I set up for the College. I am required to produce enough documentation so that the Student interns that work in the computer science area can administrate the system after I leave. These Student Interns are trained only in Novell. Therefore I need to produce a document that will show them the basics of FreeBSD Unix. Basically this will be a newbie book. Christopher J. Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html Death is life's way of telling you you're fired. From owner-freebsd-hackers Thu Jan 30 12:55:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA00630 for hackers-outgoing; Thu, 30 Jan 1997 12:55:18 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA00625 for ; Thu, 30 Jan 1997 12:55:16 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id VAA03910; Thu, 30 Jan 1997 21:52:37 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id VAA15668; Thu, 30 Jan 1997 21:50:29 +0100 (MET) Message-Id: <3.0.32.19970130215029.00b2eba0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Jan 1997 21:50:30 +0100 To: =?iso-8859-1?Q?S=F8ren_?= Schmidt From: Eivind Eklund Subject: Re: ipdivert & masqd Cc: imp@village.org, hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by freefall.freebsd.org id MAA00626 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:14 PM 1/30/97 +0100, Søren Schmidt wrote: >In reply to Eivind Eklund who wrote: >> I'm thinking about doing transparent proxying for the protocols, but I want >> to see how well the packet-patching version run first. As it is, it is >> (hopefully) right in 99% of the cases, and it scales well. If I get >> reports of real-life problems I'll make it a priority to make proxies, but >> not before. >> (And the packet-patchers will still be an option - for most people, they >> probably are a better or as good solution.) > >Hmm, I've done a NAT implementation, and my experience tells me that >doing ftp, irc, realaudio etc in the NAT itself, (I like the name >packet-patchers :) ) is the most efficient way of doing things, >and it saves the user for all that proxy fiddleing, they see the >world as if they where on the net directly... I was still thinking of doing 100% transparent proxies. This would involve snapping up all connection to proxied services, either re-assembling them or throwing them at a local socket. For this stream I would fork out and run a proxy, which could interpret the data as a stream instead of a set of disconnected packets. It is a little less efficient than packet-patching, but works 100% and still saves the user for 'all the proxy fiddleing'. Working with normal proxies (SOCKS, proxy-FTP) is a pain, and I will not write anything that encourage admins to use them. Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Thu Jan 30 13:08:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA01345 for hackers-outgoing; Thu, 30 Jan 1997 13:08:10 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01323 for ; Thu, 30 Jan 1997 13:08:04 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id WAA29422; Thu, 30 Jan 1997 22:09:34 +0100 (MET) From: Søren Schmidt Message-Id: <199701302109.WAA29422@ravenock.cybercity.dk> Subject: Re: ipdivert & masqd In-Reply-To: <19970130211742.TN38393@keltia.freenix.fr> from Ollivier Robert at "Jan 30, 97 09:17:42 pm" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Thu, 30 Jan 1997 22:09:25 +0100 (MET) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Ollivier Robert who wrote: > According to Søren Schmidt: > > and it saves the user for all that proxy fiddleing, they see the > > world as if they where on the net directly... > > ...but make user authentication a nightmare (if it can't be done at all). > In my former job as a security consultant, user identification & > authentication was a big plus of our product. User authentication ?? at the IP level ?? you lost me there :( -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Jan 30 13:10:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA01539 for hackers-outgoing; Thu, 30 Jan 1997 13:10:05 -0800 (PST) Received: from ns.newreach.net (root@ns.newreach.net [206.25.170.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01510 for ; Thu, 30 Jan 1997 13:10:00 -0800 (PST) Received: from phoenix.aristar.com (ip68.akron.newreach.net [206.25.171.68]) by ns.newreach.net (8.8.4/8.6.9) with SMTP id QAA25772 for ; Thu, 30 Jan 1997 16:09:52 -0500 (EST) Message-ID: <32F10E32.167EB0E7@aristar.com> Date: Thu, 30 Jan 1997 16:10:10 -0500 From: "Matthew A. Gessner" Organization: Aristar, Inc. X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: hackers Subject: dialup iijppp not letting line go? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, all, First, thanks for those who've helped me with setting up ppp and ppp+pktAlias (esp EE). My current task is to allow outside access from the world to a specific machine that is on my LAN through another machine connected via a modem using the ppp+pktAlias software. The specifics are: 1) Our ISP has dedicated 2 IP addresses for us: 206.25.171.180 inetgw running ppp+pktAlias 206.25.171.181 phoenix machine I want to be able to allow packets for phoenix coming in from the outside into inetgw to get to phoenix. So far, I haven't been able to make this happen. 2) I have assigned an alias to ed0: it has 2 addresses: 10.0.0.1 (local) 206.25.171.181 (alias) 3) phoenix's usual default gateway is inetgw, except when I want to connect directly through my modem (which I do sometimes). 4) I have a static route on phoenix: route add 206.25.171.181 localhost It gives an error when I start it but it does go through: it gives me this: (/etc/ppp.orig)# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 206.25.171.40 UGc 4 0 tun0 10 link#1 UC 1 0 10.0.0.4 0:40:5:1b:dc:44 UHLW 0 1587 ed0 530 10.0.0.16 0:40:5:37:7b:4b UHLW 0 132 ed0 127.0.0.1 127.0.0.1 UH 1 0 lo0 206.25.171 link#1 UC 1 0 206.25.171.40 206.25.171.68 UH 5 0 tun0 206.25.171.181 127.0.0.1 UGHS 1 0 lo0 I think I'm missing something somewhere. Can someone fill in the missing pieces? Do I need to be running ipfw? Do I need to put something else in my routing tables? My apologies for not being able to figure out what's going on here. My ISP does have his routing tables set up properly, AFAIK. He's routing all packets for the 181 address to the 180 address. If this isn't clear, write me and I'll elucidate. My other problem is that when I do a direct serial port linkup, even if I disconnect the cable, the ppp session stays active. Now I'm definitely doing something non-standard with this: I'm plugging in an Apple MessagePad and talking PPP. I've set the serial ports as 'modem' in rc.serial. Is there something else I need to be doing? Set a timeout in the dialup part of ppp.conf? TIA -- Matthew Gessner, Computer Scientist, Aristar, Inc. 302 N. Cleveland-Massillon Rd. Akron, OH 44333 Voice (330) 668-2267, Fax (330) 668-2961 From owner-freebsd-hackers Thu Jan 30 13:13:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA01698 for hackers-outgoing; Thu, 30 Jan 1997 13:13:30 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01692 for ; Thu, 30 Jan 1997 13:13:23 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id WAA29443; Thu, 30 Jan 1997 22:14:39 +0100 (MET) From: Søren Schmidt Message-Id: <199701302114.WAA29443@ravenock.cybercity.dk> Subject: Re: ipdivert & masqd In-Reply-To: <3.0.32.19970130215029.00b2eba0@dimaga.com> from Eivind Eklund at "Jan 30, 97 09:50:30 pm" To: eivind@dimaga.com (Eivind Eklund) Date: Thu, 30 Jan 1997 22:14:30 +0100 (MET) Cc: imp@village.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Eivind Eklund who wrote: > >and it saves the user for all that proxy fiddleing, they see the > >world as if they where on the net directly... > > I was still thinking of doing 100% transparent proxies. This would involve > snapping up all connection to proxied services, either re-assembling them > or throwing them at a local socket. For this stream I would fork out and > run a proxy, which could interpret the data as a stream instead of a set of > disconnected packets. > > It is a little less efficient than packet-patching, but works 100% and > still saves the user for 'all the proxy fiddleing'. Working with normal > proxies (SOCKS, proxy-FTP) is a pain, and I will not write anything that > encourage admins to use them. Well having the kernel reassemble fragments (or pieces "known" to belonging together) is one thing, but sending it out a socket to userland and then back again costs. I played with the divert hack to begin with, but it gave up on "true" ethernet speed, even on fast machines (100Mhz 486's). Thats why I'm so focused on staying in the kernel... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Jan 30 13:13:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA01742 for hackers-outgoing; Thu, 30 Jan 1997 13:13:55 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01727 for ; Thu, 30 Jan 1997 13:13:48 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id WAA04102 for hackers@freebsd.org; Thu, 30 Jan 1997 22:12:21 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id WAA15796 for ; Thu, 30 Jan 1997 22:06:18 +0100 (MET) Message-Id: <3.0.32.19970130220618.00aea190@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Jan 1997 22:06:20 +0100 To: hackers@freebsd.org From: Eivind Eklund Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When was this introduced, and is there any way for me to check if it is present? (BSD > xxxx, for instance?) I have some code from -current I am thinking of doing development on, and I run 2.1.6. Just deleting all #include will make the code compile and run under 2.1.6, but I assume it is needed under current. If there is any place I should have found this information beyond asking the list, please enlighten me. Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Thu Jan 30 13:21:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA02149 for hackers-outgoing; Thu, 30 Jan 1997 13:21:01 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA02142 for ; Thu, 30 Jan 1997 13:20:58 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA01947 for freebsd-hackers@freebsd.org; Thu, 30 Jan 1997 22:20:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA28661; Thu, 30 Jan 1997 22:14:37 +0100 (MET) Message-ID: Date: Thu, 30 Jan 1997 22:14:36 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: biosboot config? References: <199701300227.VAA00299@spooky.rwwa.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701300227.VAA00299@spooky.rwwa.com>; from Robert Withrow on Jan 29, 1997 21:27:49 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Robert Withrow wrote: > Attempting to actually solve the ``I wanna automatically > boot off my dang scsi drive even though I have two > IDE drives in my stupid system'', I think I have a glimmer... Btw, give `nextboot' a try. > 1) I need to CD to /usr/src/sys/i386/boot/biosboot/ > 2) I need to rebuild with BOOT_HD_BIAS=3 > 3) I need to install it onto the disk. HOWZATDONE? make all install disklabel -B sd0 -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Jan 30 13:25:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA02465 for hackers-outgoing; Thu, 30 Jan 1997 13:25:38 -0800 (PST) Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA02449 for ; Thu, 30 Jan 1997 13:25:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by chrome.jdl.com (8.6.12/8.6.12) with SMTP id PAA28195 for ; Thu, 30 Jan 1997 15:24:55 -0600 Message-Id: <199701302124.PAA28195@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost didn't use HELO protocol To: hackers@freebsd.org Subject: 2.2-BETA Install Feedback Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Compiler-Motto: Wintermute is dead. Long live Wintermute. Date: Thu, 30 Jan 1997 15:24:55 -0600 From: Jon Loeliger Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Freebies, OK, I *finally* got around to installing 2.2-BETA on a new disk. Once FTP silliness was eliminated during the install process, all went fairly smoothly with only minor glitches. One of the items I was most interested in seeing with this release was the ATAPI CD ROM code. So I beat on it some with mixed results. In particular, I was able to attach, mount and unmount a CD file system, multiple times and occasionally read from it. It would happily read files for a while, but then it would arbitrarily decide to quit. A umount/mount cycle would clear it up for a while, and the offending file could be read again, only to wedge elsewhere. Then, after, oh, a dozen mount/umount cycles, it finally decided there was: # mount /cdrom cd9660: /dev/wcd0c: Input/output error and would no longer work at all. I suspect that a system reboot would gain me more workable mount/umount cycles again. Here's what the /var/log/messages looks like, in almost all it's wonderous glory (I hacked out the X installation messings and security comments). Please feel free to contact me, but keep me on the CC: list as I'm currently NOT subscribed to hackers. Thanks, jdl ---------------------------------------------------------------- Jan 29 13:01:44 zinc /kernel: Copyright (c) 1992-1996 FreeBSD Inc. Jan 29 13:01:44 zinc /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 Jan 29 13:01:44 zinc /kernel: The Regents of the University of California. All rights reserved. Jan 29 13:01:44 zinc /kernel: Jan 29 13:01:44 zinc /kernel: FreeBSD 2.2-BETA_A #0: Tue Dec 24 03:41:49 1996 Jan 29 13:01:44 zinc /kernel: jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC Jan 29 13:01:44 zinc /kernel: Calibrating clock(s) relative to mc146818A clock ... i586 clock: 90211771 Hz, i8254 clock: 1193279 Hz Jan 29 13:01:44 zinc /kernel: CPU: Pentium (90.20-MHz 586-class CPU) Jan 29 13:01:44 zinc /kernel: Origin = "GenuineIntel" Id = 0x524 Stepping=4 Jan 29 13:01:44 zinc /kernel: Features=0x1bf Jan 29 13:01:44 zinc /kernel: real memory = 16777216 (16384K bytes) Jan 29 13:01:44 zinc /kernel: avail memory = 14499840 (14160K bytes) Jan 29 13:01:44 zinc /kernel: Probing for devices on PCI bus 0: Jan 29 13:01:44 zinc /kernel: chip0 rev 17 on pci0:0 Jan 29 13:01:45 zinc /kernel: chip1 rev 67 on pci0:2 Jan 29 13:01:45 zinc /kernel: vga0 rev 0 on pci0:6 Jan 29 13:01:45 zinc /kernel: Probing for devices on the ISA bus: Jan 29 13:01:45 zinc /kernel: sc0 at 0x60-0x6f irq 1 on motherboard Jan 29 13:01:45 zinc /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> Jan 29 13:01:45 zinc /kernel: ed0 at 0x320-0x33f irq 9 msize 8192 on isa Jan 29 13:01:45 zinc /kernel: ed0: address 00:c0:a8:36:0c:dd, type NE2000 (16 bit) Jan 29 13:01:45 zinc /kernel: ed1 not found at 0x300 Jan 29 13:01:45 zinc /kernel: fe0 not found at 0x300 Jan 29 13:01:45 zinc /kernel: sio0 not found at 0x3f8 Jan 29 13:01:45 zinc /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Jan 29 13:01:45 zinc /kernel: sio1: type 16550A Jan 29 13:01:45 zinc /kernel: sio2: disabled, not probed. Jan 29 13:01:45 zinc /kernel: sio3: disabled, not probed. Jan 29 13:01:45 zinc /kernel: lpt0 at 0x378-0x37f irq 7 on isa Jan 29 13:01:45 zinc /kernel: lpt0: Interrupt-driven port Jan 29 13:01:45 zinc /kernel: lp0: TCP/IP capable interface Jan 29 13:01:45 zinc /kernel: lpt1 at 0x378-0x37f on isa Jan 29 13:01:45 zinc /kernel: lpt1 not probed due to I/O address conflict with lpt0 at 0x378 Jan 29 13:01:45 zinc /kernel: mse0 not found at 0x23c Jan 29 13:01:45 zinc /kernel: psm0: disabled, not probed. Jan 29 13:01:45 zinc /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Jan 29 13:01:45 zinc /kernel: fdc0: NEC 72065B Jan 29 13:01:45 zinc /kernel: fd0: 1.44MB 3.5in Jan 29 13:01:45 zinc /kernel: fd1: 1.2MB 5.25in Jan 29 13:01:45 zinc /kernel: wdc0 at 0x1f0-0x1f7 irq 14 on isa Jan 29 13:01:45 zinc /kernel: wdc0: unit 0 (wd0): Jan 29 13:01:46 zinc /kernel: wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S Jan 29 13:01:46 zinc /kernel: wdc0: unit 1 (wd1): Jan 29 13:01:46 zinc /kernel: wd1: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S Jan 29 13:01:46 zinc /kernel: wdc1 at 0x170-0x177 irq 15 on isa Jan 29 13:01:46 zinc /kernel: wdc1: unit 0 (atapi): , removable, cmd16 Jan 29 13:01:46 zinc /kernel: atapi1.0: invalid command phase, ireason=0x3, status=40, error=0 Jan 29 13:01:46 zinc /kernel: bt0 not probed due to I/O address conflict with ed0 at 0x330 Jan 29 13:01:46 zinc /kernel: uha0 not probed due to I/O address conflict with ed0 at 0x330 Jan 29 13:01:46 zinc /kernel: aha0 not probed due to I/O address conflict with ed0 at 0x330 Jan 29 13:01:46 zinc /kernel: aic0 not found at 0x340 Jan 29 13:01:46 zinc /kernel: nca0 not found at 0x1f88 Jan 29 13:01:46 zinc /kernel: nca1 not found at 0x350 Jan 29 13:01:46 zinc /kernel: sea0 not found Jan 29 13:01:46 zinc /kernel: wt0 not found at 0x300 Jan 29 13:01:46 zinc /kernel: mcd0 not found at 0x300 Jan 29 13:01:46 zinc /kernel: matcdc0 not found at 0x230 Jan 29 13:01:46 zinc /kernel: scd0 not found at 0x230 Jan 29 13:01:46 zinc /kernel: ie0 not found at 0x360 Jan 29 13:01:46 zinc /kernel: ep0 not found at 0x300 Jan 29 13:01:46 zinc /kernel: ix0 not found at 0x300 Jan 29 13:01:46 zinc /kernel: le0 not found at 0x300 Jan 29 13:01:46 zinc /kernel: lnc0 not found at 0x280 Jan 29 13:01:46 zinc /kernel: ze0 not found at 0x300 Jan 29 13:01:46 zinc /kernel: zp0 not found at 0x300 Jan 29 13:01:46 zinc /kernel: npx0 on motherboard Jan 29 13:01:46 zinc /kernel: npx0: INT 16 interface Jan 29 13:01:46 zinc /kernel: apm0: disabled, not probed. Jan 29 13:01:48 zinc lpd[108]: restarted Jan 29 13:03:12 zinc /kernel: cmd XF86_S3 pid 157 tried to use non-present SYSVSHM Jan 30 02:15:03 zinc su: jdl to root on /dev/ttyp0 Jan 30 02:25:48 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc0, status=c0, error=c0 Jan 30 02:25:48 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc8, status=c8, error=c8 Jan 30 02:25:59 zinc /kernel: atapi1.0: controller not ready for cmd Jan 30 02:26:10 zinc last message repeated 4 times Jan 30 02:26:24 zinc /kernel: wcd0: media changed Jan 30 02:53:27 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc0, status=c0, error=c0 Jan 30 02:53:27 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc8, status=c8, error=c8 Jan 30 02:53:38 zinc /kernel: atapi1.0: controller not ready for cmd Jan 30 02:53:50 zinc last message repeated 4 times Jan 30 02:54:16 zinc /kernel: wcd0: media changed Jan 30 03:32:40 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc0, status=c0, error=c0 Jan 30 03:32:41 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc8, status=c8, error=c8 Jan 30 03:32:52 zinc /kernel: atapi1.0: controller not ready for cmd Jan 30 03:33:03 zinc last message repeated 4 times Jan 30 03:33:25 zinc /kernel: wcd0: media changed Jan 30 03:36:28 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc0, status=c0, error=c0 Jan 30 03:36:36 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc8, status=c8, error=c8 Jan 30 03:36:36 zinc /kernel: atapi1.0: controller not ready for cmd Jan 30 03:36:55 zinc last message repeated 3 times Jan 30 03:36:55 zinc /kernel: wcd0: media changed Jan 30 03:36:55 zinc /kernel: wcd0: cannot read audio disc Jan 30 03:43:24 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc0, status=c0, error=c0 Jan 30 03:43:24 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc8, status=c8, error=c8 Jan 30 03:43:35 zinc /kernel: atapi1.0: controller not ready for cmd Jan 30 03:43:47 zinc last message repeated 4 times Jan 30 03:44:17 zinc /kernel: wcd0: media changed Jan 30 03:51:00 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc0, status=c0, error=c0 Jan 30 03:51:08 zinc /kernel: atapi1.0: invalid command phase, ireason=0xc8, status=c8, error=c8 Jan 30 03:51:08 zinc /kernel: atapi1.0: controller not ready for cmd Jan 30 03:51:25 zinc last message repeated 4 times Jan 30 03:51:27 zinc /kernel: wcd0: media changed From owner-freebsd-hackers Thu Jan 30 13:35:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA03143 for hackers-outgoing; Thu, 30 Jan 1997 13:35:13 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA03137 for ; Thu, 30 Jan 1997 13:35:10 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id QAA05306; Thu, 30 Jan 1997 16:33:31 -0500 (EST) Date: Thu, 30 Jan 1997 16:33:31 -0500 (EST) From: Mark Mayo To: Chris Coleman cc: Julian Elischer , Terry Lambert , mcgovern@spoon.beta.com, msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Chris Coleman wrote: > > On Thu, 30 Jan 1997, Julian Elischer wrote: > > > > > > > What is the intent of your book? What specific areas will it cover? > > > What kind of existing material are you looking for? > > > > how will it differ from the "FreeBSD book" that Walnut Creek CDROM sell? > > I have to document the 5 existing FreeBSD Machines that I set up for the > College. I am required to produce enough documentation so that the > Student interns that work in the computer science area can administrate > the system after I leave. These Student Interns are trained only in > Novell. Therefore I need to produce a document that will show them the > basics of FreeBSD Unix. Basically this will be a newbie book. I noticed that you called your book "A USERS GUIDE TO INSTALLING AND RUNNING FREEBSD". Perhaps you should contact Greg Lehey, he wrote a book called: "Installing and Running FreeBSD", published by Walnut Creek. The book is 3 hundered pages long, and came with my 2.1R CD-ROM. If you check out http://www.cdrom.com/os/bsdbook.htm you'll notice that it's now called: "The Complete FreeBSD". I'm assuming this is an updated version of the book I have. Greg's book is fairly good, dealing mostly with the Installation. He doesn't really get into network setups, ppp, etc.. in great detail. It was excellent for me, as it introduced me to the whole kernel build procedure, installation concepts, and hardware setup. He also gets into XFree86 configuration details, although I would have like a slightly more expanded chapter on X11R6 - maybe with a little less focus on XFree86 and on X11 in general (config file locations, better explanations of xdm, etc..) I think maybe some of the things you could cover would include an explantion of some of the BSD traditions (slice a is for / filesystem, b for swap, c for entire disk, etc..) and maybe even a step-by-step approach to "Setting Up a High-Performance Internet Server with FreeBSD". Ever see those SAMS books around that explain how to setup a Linux Internet server? I don't know the quality of them, but my friend at a local book store tells me they sell like hotcakes! Whatever you decide, contact Greg Lehey and see what he has done, and I'm certainly willing to help out considerably with stuff as well (I suspect I'm at a similar technical level as yourself - relatively new to freeBSD, but after having to learn everything from scratch to make real FreeBSD servers, I'm feeling more comfortable with the OS. At least from an administration standpoint). FreeBSD is a great OS suited for a wide variety of tasks - I would like to see sort of a "Do it Yourself Server, with FreeBSD" book. Almost a motivational book of sorts to show a new admin (who's undoubtably been asked to perform network magic with low funding) the types of things that FreeBSD excels at: - You don't need to by NT Server, use Samba as a SMB server for small to medium sized Windows LANS - You don't need to buy NT server, use FreeBSD for Dial-up WAN access - You don't need to buy NT server, use FreeBSD to connect your LAN to the Internet - with on demand dialing, and a firewall - You don't need to buy NT server, use FreeBSD and Apache to create a high perforance, stable web server. - DNS? Email? You don't need NT or a commercial Unix, use FreeBSD and named/sendmail - You don't need to buy a Cisco router, use FreeBSD and Gated with a cheap PC card! (Emerging Technologies, for ex.) - Etc.. If only I were finished school - so many things to do, so little time :( Good luck, -Mark ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) > > > Christopher J. Coleman (chris@aries.bb.cc.wa.us) > Computer Support Technician I (509)-766-8873 > Big Bend Community College Internet Instructor > FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html > Death is life's way of telling you you're fired. > > From owner-freebsd-hackers Thu Jan 30 13:56:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA04328 for hackers-outgoing; Thu, 30 Jan 1997 13:56:02 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA04296 for ; Thu, 30 Jan 1997 13:55:57 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id IAA05419; Fri, 31 Jan 1997 08:55:36 +1100 (EST) Date: Fri, 31 Jan 1997 08:55:35 +1100 (EST) From: "Daniel O'Callaghan" To: Eivind Eklund cc: Warner Losh , hackers@FreeBSD.ORG Subject: Transparent proxies (was Re: ipdivert & masqd) In-Reply-To: <3.0.32.19970130190212.00b22780@dimaga.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Eivind Eklund wrote: > At 08:04 AM 1/30/97 -0700, you wrote: > I'm thinking about doing transparent proxying for the protocols, but I want > to see how well the packet-patching version run first. As it is, it is > (hopefully) right in 99% of the cases, and it scales well. If I get > reports of real-life problems I'll make it a priority to make proxies, but > not before. Here's a problem which requires transparent proxies for a data stream, not packet-patching: Transparent capture of all HTTP requests on port 80 and diversion to a www-proxy server. e.g. Client Sends "NAT" WWW-Proxy receives 10.2.3.4 10.2.3.1 10.2.3.55 10.2.3.4-> 5.6.7.8:80 ================> 10.2.3.1->10.2.3.55 GET / HTTP/1.0 GET http://5.6.7.8:80/ HTTP/1.0 Darren Reed's ipfilter does this with the 'redirect' keyword and some trickery in the receiving process. The example given is for the ftwk's ftp-gw program (from ftp.tis.com). The userland process finds its true destination by calling an IOCTL for the kernel NAT code. regards, Danny From owner-freebsd-hackers Thu Jan 30 14:41:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA06512 for hackers-outgoing; Thu, 30 Jan 1997 14:41:11 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA06507 for ; Thu, 30 Jan 1997 14:41:04 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id XAA00539; Thu, 30 Jan 1997 23:42:42 +0100 (MET) From: Søren Schmidt Message-Id: <199701302242.XAA00539@ravenock.cybercity.dk> Subject: Re: 2.2-BETA Install Feedback In-Reply-To: <199701302124.PAA28195@chrome.jdl.com> from Jon Loeliger at "Jan 30, 97 03:24:55 pm" To: jdl@jdl.com (Jon Loeliger) Date: Thu, 30 Jan 1997 23:42:32 +0100 (MET) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jon Loeliger who wrote: > > In particular, I was able to attach, mount and unmount a CD > file system, multiple times and occasionally read from it. > It would happily read files for a while, but then it would > arbitrarily decide to quit. A umount/mount cycle would clear > it up for a while, and the offending file could be read again, > only to wedge elsewhere. Then, after, oh, a dozen mount/umount > cycles, it finally decided there was: > > # mount /cdrom > cd9660: /dev/wcd0c: Input/output error > > and would no longer work at all. I suspect that a system > reboot would gain me more workable mount/umount cycles again. Ahh, I see its the NEC 260 drive, thats a known rougue, and I have gotten my hands on one, just havnøt had enough time to get it to play proberly yet, it fails more seldom on my setup than yours, making bug hunting more difficult.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Jan 30 14:47:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07001 for hackers-outgoing; Thu, 30 Jan 1997 14:47:01 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA06946 for ; Thu, 30 Jan 1997 14:46:47 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id PAA09362; Thu, 30 Jan 1997 15:45:50 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.1-alpha.p0.FreeBSD:970130150229:7353=_" In-Reply-To: Date: Thu, 30 Jan 1997 14:49:56 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Tom Samplonius Subject: Re: More 2.2-BETA goodies... Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This message is in MIME format --_=XFMail.1.1-alpha.p0.FreeBSD:970130150229:7353=_ Content-Type: text/plain; charset=iso-8859-8 Hi Tom Samplonius; On 29-Jan-97 you wrote: > > On Wed, 29 Jan 1997, Simon Shapiro wrote: > > ... > > If there is interest, I can post it. It runs on Slowlaris 2.5.1, linux 2.x > > and FreeBSD 9of courcse). We prefer it to others because it does true > ... > > I'm interested. I've been looking for something to test transactional > limits of SCSI controllers and drives. Problems with tagged command > queuing, etc don't show up until you have a very high number of > transactions per second. > > On an other note, have you tried turning AHC_TAGENABLE and/or > AHC_SCBPAGING_ENABLE on? AHC_TAGENABLE is pretty reliable if your drives > support it. SCSPAGING needs some work yet, I think. Thanx. I am sure many will be interested. I am saving this note myself. We are working, as many of you have learned by now :-) on writing a FreeBSD driver for the DPT controllers as we need some unique features in these (expensive) controllers. I say ``expensive'' as our initial work will only apply to the high-end adapters. Here is st.c, AKA rs.c. (st was known as rs for many, many years. I found /usr/local/bin/rs upon installing FreeBSD. It does something totally different. If this program has any apeal, I can contribute it to the FreeBSD project. How? I know to change the copyright message... Anyway, no man page for now, but basically, you give it a filename to work on, a size is optional. and what kind of a mess you want it to create. A cute addision is that it finds the size of raw partitions very quickly (stat(2) does not) and -S will tell you what it found. It does reads by default, but can do read-modify-write or write-only. Random seek is the default behavior, but you can cause it to seek sequentially. It tries to report ``net'' times. I found that different Unixes report times(2) very differently. Slowlaris, for example, appears to discount (part of?) ``blocked-on-i/o'' time. It misses calendar ``wall clock'' time but ``date;st -....;date'' does the same. There is a million options. see the source and the -h option. It needs no makefile. Just compile it. Simon --_=XFMail.1.1-alpha.p0.FreeBSD:970130150229:7353=_ Content-Disposition: attachment; filename="st.c" Content-Transfer-Encoding: base64 Content-Type: application/octet-stream; name=st.c; SizeOnDisk=25120 LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKgogKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqCiAqICAgICAgIENv cHlyaWdodCAoYykgMTk5MC0xOTk1IGJ5IFNpbW9uIHNoYXBpcm8gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICoKICogICAgICAgQWxsIFJpZ2h0cyBSZXNlcnZlZCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAq CiAqICAgICAgIFRISVMgSVMgVU5QVUJMSVNIRUQgUFJPUFJJRVRBUlkgU09VUkNFIENPREUgT0Yg ICAgICAgICAgICAgICAgICAgICAgICoKICogICAgICAgICAgICAgICAgICAgICAgICBTaW1vbiBz aGFwaXJvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgogKiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAqCiAqICAgICAgIFRoZSBjb3B5cmlnaHQgbm90aWNlIGFib3ZlIGRvZXMgbm90 IGV2aWRlbmNlIGFueSAgICAgICAgICAgICAgICAgICAgICoKICogICAgICAgYWN0dWFsIG9yIGlu dGVuZGVkIHB1YmxpY2F0aW9uIG9mIHN1Y2ggc291cmNlIGNvZGUuICAgICAgICAgICAgICAgICAg KgogKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAqCiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCgovKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqCiAqICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoKICogIHJzOiAgICAgICAgUmFu ZG9tIGFuZCBTZXF1ZW50aWFsIFNlZWsgcmVhZCB0ZXN0IHByb2dyYW0gICAgICAgICAgICAgICAg ICAgKgogKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAqCiAqICBhcmd1bWVudHM6IC1mIGZpbGVfbmFtZSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoKICogICAg ICAgICAgICAgLXAgbm9fb2ZfcGFzc2VzIChkZWZhdWx0ID0gMCkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICAtciByZWNvcmRfc2l6ZSAoZGVmYXVsdCA9 IDQwOTYpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqCiAqICAgICAgICAgICAgIC1z IGZpbGVfc2l6ZSAoZGVmYXVsdCA9IDAgJiBtZWFucyBhdXRvLWRldGVjdCkgICAgICAgICAgICAg ICAgICoKICogICAgICAgICAgICAgLVIgbm9fcmVjb3JkcyAoZGVmYXVsdCA9IGZpbGVfc2l6ZSAv IHJlY29yZF9zaXplKSAgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICAtdiBGaWxlIHN5c3Rl bSBpcyB2ZXJ5LCB2ZXJ5IGZhc3QgKFJBTSBkaXNrKSAgICAgICAgICAgICAgICAgICAqCiAqICAg ICAgICAgICAgIC1sIFVzZSBsb2NrZigyKSB0byBsb2NrIHRoZSByZWNvcmRzLiAgRG8gTk9UIHNs ZWVwIG9uIGJ1c3kgICAgICoKICogICAgICAgICAgICAgLUwgVXNlIGxvY2tmIGJ1dCBzbGVlcCBp ZiBidXN5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICAt byBVc2UgT19TWU5DL2ZzeW5jIHRvIGd1YXJhbnRlZSBzeW5jaHJvbm91cyB3cml0ZXMgICAgICAg ICAgICAqCiAqICAgICAgICAgICAgIC1PIHJlY29yZHMgdG8gc3luY2hyb25pemUgcmVjb3JkcyBl dmVyeSBzbyBvZnRlbiAoZnN5bmMgb25seSkgICoKICogICAgICAgICAgICAgLXEgRG8gc2VxdWVu dGlhbCBhY2Nlc3MgaW5zdGVhZCBvZiByYW5kb20gICAgICAgICAgICAgICAgICAgICAgKgogKiAg ICAgICAgICAgICAtUSBEbyBub3QgZXhwbGljaXRseSBsc2VlayBpbiBzZXF1ZW50aWFsIG1vZGUg ICAgICAgICAgICAgICAgICAqCiAqICAgICAgICAgICAgIC1XIEVuYWJsZSB3cml0ZXMgKC13IHdp bGwgbm90IG9wZXJhdGUgd2l0aG91dCB0aGlzIGBgc2FmZXR5JycgICoKICogICAgICAgICAgICAg LXcgUnxXOnBhdHRlcm4gV3JpdGUgb3B0aW9uczogIHIgbWVhbnMgcmVhZCB0aGVuIHdyaXRlLCAg ICAgICAgKgogKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdzpw YXR0ZXJuIG1lYW5zIGZpbGwgdGhlIGJ1ZmZlciAqCiAqICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2l0aCBwYXR0ZXJuIChoZXggbm8uKSoKICog ICAgICAgICAgICAgLXggZGVidWcgbW9kZSBvbiAoZGVmYXVsdCA9IG9mZikgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICAtUyBSZXBvcnQgZmlsZSBzaXplICho YW5keSBmb3IgcmF3IGRldmljZXMpICAgICAgICAgICAgICAgICAgICAqCiAqICAgICAgICAgICAg IC1tIFJlcG9ydCB0aW1lICBpbiBtaWxsaXNlY29uZHMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICoKICogICAgICAgICAgICAgLU0gUmVwb3J0IHJlc3VsdCBpbiBtZWdhYnl0ZXMvc2Vj b25kIE11dGV4IHdpdGggLUkgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICAtSSBSZXBvcnQg bnVtYmVyIG9mIEkvTyBvcGVyYXRpb25zIHBlciBzZWNvbmQgICAgICAgICAgICAgICAgICAqCiAq ICAgICAgICAgICAgIC1WIEdpdmUgdmlzdWFsIHByb2dyZXNzIGluZGljYXRpb24gKGRvdCBwZXIg cmVjb3JkKSAgICAgICAgICAgICoKICogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgogKiAgcmV0dXJuczog ICAwIGFuZCBubyBvZiBjbG9jayB0aWNrcyBwYXNzZWQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAqCiAqICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoKICogIGNhdmVhdHM6ICAgT25lIHBhc3Mg cGVyIGNhbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgog KiAgICAgICAgICAgICBXaWVyZCByZWNvcmQgc2l6ZXMgd2lsbCByZXN1bHQgaW4gc3ViLW9wdGlt YWwgcmVzdWx0cyBvbiBtb3N0ICAqCiAqICAgICAgICAgICAgIHN5c3RlbXMgKHdpZXJkIGlzIHdo ZXJlIHJlY29yZF9zaXplICUgTkJQU0MgKDUxMikgIT0gMCkgICAgICAgICoKICogICAgICAgICAg ICAgSWYgZmlsZV9zaXplICUgcmVjb3JkX3NpemUgIT0gMCB3ZSBtYWtlIGl0IHNvICh0cnVuY2F0 ZSkgICAgICAgKgogKiAgICAgICAgICAgICBJZiB0aGUgZmlsZSBkb2VzIG5vdCBleGlzdCwgb3Ig dG9vIHNob3J0IHdlIGZhaWwhICAgICAgICAgICAgICAqCiAqICAgICAgICAgICAgIFdlIGRvIG5v dCBjaGVjayBmb3IgaG9sZXMgaW4gZmlsZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoK ICogICAgICAgICAgICAgV2UgcGFzcyB0aHJvdWdoIChpZ25vcmUpIHN5bWJvbGljIGxpbmtzICAg ICAgICAgICAgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICBSdW5uaW5nIG9uIG5vbi1yYW5k b20tc2Vla2luZyBjaGFyYWN0ZXIgc3BlY2lhbCBjYW4gbWFrZSBsaWZlICAqCiAqICAgICAgICAg ICAgIGV4Y2l0aW5nIDotKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICoKICogICAgICAgICAgICAgTWFrZXMgZmlsZV9zaXplL3JlY29yZF9zaXplIHJl YWRzIHBlciBwYXNzICAgICAgICAgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICBpZiB2ZXJ5 X2Zhc3QgKC12KSBpcyBvbiwgd2UgdGltZSB0aGUgd2hvbGUgaXR0ZXJhdGlvbiwgbm90ICAgICAq CiAqICAgICAgICAgICAgIGp1c3QgdGhlIHJlYWQgcG9ydGlvbiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICoKICogICAgICAgICAgICAgSW4gY2hvb3NpbmcgZm9ybWF0 LCBNYi9zZWMgaGFzIGhpZ2hlciBwcmlvcml0eSB0aGFuIG1zYyAgICAgICAgKgogKiAgICAgICAg ICAgICBJZiBtYl9wZXJfc2VjLCB0aGVuIHJlY29yZCBzaXplIG11c3QgYmUgYSBmcmFjdGlvbiBv ZiAxTWIgICAgICAqCiAqICAgICAgICAgICAgIElmIE1iL1NlYywgZG8gbm90IGxldCBmaWxlX3Np emUgKiBwYXNzZXMgKHRvdGFsIGJ5dGVzIHJlYWQpICAgICoKICogICAgICAgICAgICAgZXhjY2Vl ZCAyR0IgKDB4N2ZmZmZmZmYpIG9yIHJlcG9ydGVkIHJlc3VsdHMgd2lsbCBiZSBmdW5ueSAgICAg KgogKiAgICAgICAgICAgICBCb3RoIGEgdmFsaWQgLXcgKHNlZSBiZWxvdykgYW5kIC1XIG11c3Qg ZXhpc3QgdG8gZW5hYmxlIHdyaXRlcy4qCiAqICAgICAgICAgICAgIC13IHc6cGF0dGVybiBhc3N1 bWVzIHRoYXQgcGF0dGVybiBpcyBhIHVsb25nLiAgICAgICAgICAgICAgICAgICoKICogICAgICAg ICAgICAgV3JpdGUgb3B0aW9ucyBkbyBOT1Qgd29yayB3aXRoIC1RIChza2lwIHNlZWtpbmcpLiAg ICAgICAgICAgICAgKgogKiAgICAgICAgICAgICBSYW5kb20gc2VlayBtb2RlIChkZWZhdWx0KSBk b2VzIG5vdCBndWFyYW50ZWUgdGhhdCBhbGwgcmVjb3JkcyAqCiAqICAgICAgICAgICAgIHdpbGwg YmUgYWNjZXNzZWQuICBUaGVyZSB3aWxsIGJlIGFzIG1hbnkgYWNjZXNzZXMgYXMgdGhlcmUgYXJl ICoKICogICAgICAgICAgICAgYmxvY2tzIGluIHRoZSBmaWxlLiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKgogKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqCiAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKiovCgojaWRlbnQgIiRIZWFkZXI6IC91c3Ivc3JjL2xvY2FsL3JzL1JDUy9z dC5jLHYgMS41IDE5OTcvMDEvMTQgMDA6NTQ6MjUgU2hpbW9uUiBFeHAgU2hpbW9uUiAkIgoKI2lu Y2x1ZGUgPHN5cy90eXBlcy5oPgojaWZkZWYgX19GcmVlQlNEX18KI2luY2x1ZGUgPGxpbWl0cy5o PgojZW5kaWYKI2luY2x1ZGUgPHZhbHVlcy5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CiNpbmNsdWRl IDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CiNpbmNsdWRlIDxzeXMvdGltZXMuaD4K I2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDx0aW1lLmg+CiNpbmNsdWRlIDxsaW1pdHMuaD4K I2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3RyaW5nLmg+ CgojaWZkZWYgX19GcmVlQlNEX18KdHlwZWRlZiB1bnNpZ25lZCBsb25nIHVsb25nOwojZGVmaW5l IEZfTE9DSyAgICAgICAgICAgIExPQ0tfU0gKI2RlZmluZSBGX1RMT0NLICAgICAgICAgICBMT0NL X05CCiNkZWZpbmUgRl9VTE9DSyAgICAgICAgICAgTE9DS19VTgojZGVmaW5lIE9fU1lOQyAgICAg ICAgICAgIDAKI2luY2x1ZGUgPHN5cy9maWxlLmg+CiNlbmRpZgoKI2lmbmRlZiBPRkZfTUFYCiNk ZWZpbmUgT0ZGX01BWCAgICAgICAgICAgTE9OR19NQVgKI2VuZGlmCgojZGVmaW5lICBET19XUklU RVMgICAgICAgIDB4MTEKCiNkZWZpbmUgIFZFUlNJT04gICAgICAgICAgIlJhbmRvbSBTZWVrZXIg VmVyc2lvbiAkUmV2aXNpb246IDEuNSAkXG4iCiNkZWZpbmUgIFZBTElEX09QVElPTlMgICAgIk86 UjpvUXFWU01tdnhmOnI6czpwOld3OklsTCIKCiNkZWZpbmUgIFVTQUdFICAgICAgICAgICAgIlwK VXNhZ2U6IHJzIC1mIGZpbGVfbmFtZSBbb3B0aW9ucy4uLl1cblwKT3B0aW9uczogIC1wIG5vX29m X3Bhc3NlcyAoZGVmYXVsdCA9IDEpXG5cCiAgICAgICAgICAtciByZWNvcmRfc2l6ZSAgKGRlZmF1 bHQgPSA0MDk2KVxuXAogICAgICAgICAgLXMgZmlsZV9zaXplICAgIChkZWZhdWx0ID0gMCAmIG1l YW5zIGF1dG8tZGV0ZWN0KVxuXAogICAgICAgICAgLVIgbm9fcmVjb3JkcyAgIChkZWZhdWx0ID0g ZmlsZV9zaXplIC8gcmVjb3JkX3NpemUpXG5cCiAgICAgICAgICAtcSAgICAgICAgICAgICAgUGVy Zm9ybSBzZVFlbnRpYWwgYWNjZXNzLCBpbnN0ZWFkIG9mIHJhbmRvbVxuXAogICAgICAgICAgLVEg ICAgICAgICAgICAgIERvIG5vdCBleHBsaWNpdGx5IHNlZWsgaW4gc2VxdWVudGlhbCBtb2RlXG5c CiAgICAgICAgICAtdiAgICAgICAgICAgICAgRmlsZSBzeXN0ZW0gaXMgdmVyeSwgdmVyeSBmYXN0 IChSQU0gZGlzaylcblwKICAgICAgICAgIC1sICAgICAgICAgICAgICBVc2Ugbm9uLWJsb2NraW5n IGxvY2tmKDIpL2Zsb2NrKDIpXG5cCiAgICAgICAgICAtTCAgICAgICAgICAgICAgVXNlIGJsb2Nr aW5nIGxvY2tmKDIpL2Zsb2NrKClcblwKICAgICAgICAgIC1vICAgICAgICAgICAgICBGb3JjZSBz eW5jaHJvbml6ZWQgd3JpdGVzIChMaW51eCBvbmx5PylcblwKICAgICAgICAgIC1XICAgICAgICAg ICAgICBFbmFibGUgd3JpdGVzXG5cCiAgICAgICAgICAtdyBSfFc6cGF0dGVybiAgRG8gcmVhZC10 aGVuLXdyaXRlIG9yIHdyaXRlLCBoZXggcGF0dGVyblxuXAogICAgICAgICAgLVMgICAgICAgICAg ICAgIFJlcG9ydCBmaWxlIHNpemUgKGhhbmR5IGZvciByYXcgZGV2aWNlcylcblwKICAgICAgICAg IC1tICAgICAgICAgICAgICBSZXBvcnQgdGltZSAgaW4gbWlsbGlzZWNvbmRzXG5cCiAgICAgICAg ICAtTXxJICAgICAgICAgICAgUmVwb3J0IHJlc3VsdCBpbiBtZWdhYnl0ZXMgb3IgSS9PLW9wcyBz cGVyIC9zZWNvbmRcblwKICAgICAgICAgIC14ICAgICAgICAgICAgICBkZWJ1ZyBtb2RlIG9uIChk ZWZhdWx0ID0gb2ZmKVxuXAogICAgICAgICAgLVYgICAgICAgICAgICAgIEdpdmUgdmlzdWFsIGlu ZGljYXRpb24gb2YgcHJvZ3Jlc1xuIgojZGVmaW5lICBTVEFUX0ZBSUxFRF9NU0cgInJzOiBGYWls ZWQgdG8gb2J0YWluIHN0YXR1cyBvZiAlcyIKI2RlZmluZSAgTk9UX1ZBTElEICAgICAgICJOViIK I2RlZmluZSAgQ0FOTk9UX09QRU5fREVWICAicnM6IENhbm5vdCBPUEVOICVzIChSL08pIGZvciBz aXppbmciCiNkZWZpbmUgIENBTk5PVF9TRUVLX0RFViAgInJzOiBDYW5ub3QgU0VFSyAlcyBmb3Ig c2l6aW5nIgoKI2RlZmluZSAgUkVDT1JEX1NJWkUgICAgICA0MDk2CiNkZWZpbmUgIFBBU1NFUyAg ICAgICAgICAgMQoKLyogRXhpdCBzdGF0dXMgdmFsdWVzICovCgojaWZuZGVmIEJBRF9PUFRJT04K I2RlZmluZSAgQkFEX09QVElPTiAgICAgICAxCiNlbmRpZgoKI2RlZmluZSAgU1RBVF9GQUlMRUQg ICAgICAyCiNkZWZpbmUgIEJBRF9GSUxFX1RZUEUgICAgMwojZGVmaW5lICBNQUxMT0NfRkFJTEVE ICAgIDQKI2RlZmluZSAgT1BFTl9GQUlMRUQgICAgICA1CiNkZWZpbmUgIExTRUVLX0ZBSUxFRCAg ICAgNgojZGVmaW5lICBSRUFEX0ZBSUxFRCAgICAgIDcKI2RlZmluZSAgQ0xPU0VfRkFJTEVEICAg ICA4CgojZGVmaW5lICBNRUdBQllURSAgICAgICAgICgxMDI0ICogMTAyNCkKCnN0YXRpYyBpbnQg aXNfZGlzayhtb2RlX3QgbW9kZV93b3JkKQp7CiAgc3dpdGNoICggbW9kZV93b3JkICYgU19JRk1U ICkKICB7CiAgICBjYXNlIFNfSUZDSFI6CiAgICBjYXNlIFNfSUZCTEs6CiAgICAgIHJldHVybigx KTsKICAgIGRlZmF1bHQ6CiAgICAgIHJldHVybigwKTsKICB9Cn0KCnN0YXRpYyBpbnQgaW52YWxp ZF9maWxlKG1vZGVfdCBtb2RlX3dvcmQpCnsKICBzd2l0Y2ggKCBtb2RlX3dvcmQgJiBTX0lGTVQg KQogIHsKICAgIGNhc2UgU19JRklGTzoKICAgIC8qIGNhc2UgU19JRkNIUjogKi8KICAgIGNhc2Ug U19JRkRJUjoKICAgICAgcmV0dXJuKDEpOwogICAgZGVmYXVsdDoKICAgICAgcmV0dXJuKDApOwog IH0KfQoKc3RhdGljIGludCBzZWVrX2VuZHBvaW50KGludCBmZCwgc2l6ZV90IG9mZnNldCkKewog IGNoYXIgIHJlc3VsdFsxXTsKCiAgaW50ICAgcmVhZF9yZXN1bHQ7CgogIGlmICggbHNlZWsoZmQs IG9mZnNldCwgU0VFS19TRVQpID09IC0xICkKICAgIHJldHVybigtMSk7CgogIHJlYWRfcmVzdWx0 ID0gcmVhZChmZCwgKHZvaWQgKilyZXN1bHQsIDEpOwoKICBzd2l0Y2ggKCByZWFkX3Jlc3VsdCAp CiAgewogICAgY2FzZSAtMToKICAgICAgcmV0dXJuKC0yKTsKICAgIGNhc2UgMToKICAgICAgcmV0 dXJuKDApOwogICAgZGVmYXVsdDoKICAgICAgcmV0dXJuKDEpOwogIH0KfQoKaW50Cm1haW4oYXJn YywgYXJndikKICBpbnQgICAgICBhcmdjOwogIGNoYXIgICAqKmFyZ3Y7CnsKICAvKiBFeHRlcm5h bCBmdW5jdGlvbnMgKi8KCiAgZXh0ZXJuICBjaGFyICAgICAqb3B0YXJnOwoKICAvKiBMb2NhbCBW YXJpYWJsZXMgKi8KCiAgICAgICAgICBpbnQgICAgICAgYmFkX29wdGlvbiAgICAgICAgPSAwLAog ICAgICAgICAgICAgICAgICAgIG5keCwKICAgICAgICAgICAgICAgICAgICBwYXNzZXMgICAgICAg ICAgICA9IFBBU1NFUywKICAgICAgICAgICAgICAgICAgICBkZXZpY2VfZmQgICAgICAgICA9IC0x LAogICAgICAgICAgICAgICAgICAgIGRlYnVnX29uICAgICAgICAgID0gMCwKICAgICAgICAgICAg ICAgICAgICB2ZXJ5X2Zhc3QgICAgICAgICA9IDAsCiAgICAgICAgICAgICAgICAgICAgbWlsbGlz ZWNvbmRzICAgICAgPSAwLAogICAgICAgICAgICAgICAgICAgIG1iX3Blcl9zZWMgICAgICAgID0g MCwKICAgICAgICAgICAgICAgICAgICBpb19wZXJfc2VjICAgICAgICA9IDAsCiAgICAgICAgICAg ICAgICAgICAgdGVsbF9maWxlX3NpemUgICAgPSAwLAogICAgICAgICAgICAgICAgICAgIHZpc3Vh bF9wcm9ncmVzcyAgID0gMCwKICAgICAgICAgICAgICAgICAgICBzZXF1ZW50aWFsX2FjY2VzcyA9 IDAsCiAgICAgICAgICAgICAgICAgICAgZG9fbHNlZWsgICAgICAgICAgPSAxLAogICAgICAgICAg ICAgICAgICAgIGRvX2xvY2tmICAgICAgICAgID0gMCwKICAgICAgICAgICAgICAgICAgICBibG9j a2luZ19sb2NrICAgICA9IDAsCiAgICAgICAgICAgICAgICAgICAgZG9fd3JpdGVzICAgICAgICAg PSAwLAogICAgICAgICAgICAgICAgICAgIHJlYWRfdGhlbl93cml0ZSAgID0gMCwKICAgICAgICAg ICAgICAgICAgICBlbmFibGVfd3JpdGVzICAgICA9IDAsCiAgICAgICAgICAgICAgICAgICAgZG9f b19zeW5jICAgICAgICAgPSAwLAogICAgICAgICAgICAgICAgICAgIHJlY3NfcGVyX2ZzeW5jICAg ID0gMDsKCiAgICAgICAgICAgdWxvbmcgICAgd3JpdGVfcGF0dGVybiAgICAgPSAwOwoKCiAgICAg ICAgICAgc2l6ZV90ICAgcmVjb3JkX3NpemUgICAgICAgPSBSRUNPUkRfU0laRSwKICAgICAgICAg ICAgICAgICAgICBmaWxlX3NpemUgICAgICAgICA9IDAsCiAgICAgICAgICAgICAgICAgICAgcmVj b3JkcywKICAgICAgICAgICAgICAgICAgICBub19vZl9yZWFkcyAgICAgICA9IDA7CgogICAgICAg ICAgY2hhciAgICAgKmZpbGVfbmFtZSAgICAgICAgID0gTlVMTCwKICAgICAgICAgICAgICAgICAg ICpidWZmZXI7CgogIHN0cnVjdCAgdG1zICAgICAgIHRpbWVzX3N0cnVjdDsKCiAgY2xvY2tfdCAg ICAgICAgICAgc3RhcnRfdGltZSAgICAgICA9IDAsCiAgICAgICAgICAgICAgICAgICAgZmluaXNo X3RpbWUgICAgICA9IDAsCiAgICAgICAgICAgICAgICAgICAgYWNjdW11bGF0ZWRfdGltZSA9IDA7 CgogIHN0cnVjdCAgc3RhdCAgICAgIHN0YXR1c19idWZmZXI7CgogIC8qIFBhcnNlIGNvbW1hbmQg bGluZSAqLwogIGlmICggYXJnYyA9PSAxICkKICAgICsrYmFkX29wdGlvbjsKICBlbHNlCiAgewog ICAgd2hpbGUgKCAobmR4ID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsIFZBTElEX09QVElPTlMpKSAhPSAt MSkKICAgIHsKICAgICAgc3dpdGNoIChuZHgpCiAgICAgIHsKICAgICAgICBjYXNlICdvJzoKICAg ICAgICAgICsrZG9fb19zeW5jOwogICAgICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSAnTyc6CiAg ICAgICAgICByZWNzX3Blcl9mc3luYyA9IGF0b2kob3B0YXJnKTsKICAgICAgICAgIGJyZWFrOwog ICAgICAgIGNhc2UgJ1cnOgogICAgICAgICAgZW5hYmxlX3dyaXRlcyA9IDB4MDE7CiAgICAgICAg ICBicmVhazsKICAgICAgICBjYXNlICd3JzoKICAgICAgICAgIHN3aXRjaCAoIG9wdGFyZ1swXSAp CiAgICAgICAgICB7CiAgICAgICAgICAgIGNhc2UgJ1InOgogICAgICAgICAgICAgICsrcmVhZF90 aGVuX3dyaXRlOwogICAgICAgICAgICAgIGRvX3dyaXRlcyAgICAgICA9IDE7CiAgICAgICAgICAg ICAgYnJlYWs7CiAgICAgICAgICAgIGNhc2UgJ1cnOgogICAgICAgICAgICAgIGlmICggb3B0YXJn WzFdID09ICc6JyApCiAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgd3JpdGVfcGF0dGVy biAgID0gb3B0YXJnWzJdOwogICAgICAgICAgICAgICAgZG9fd3JpdGVzICAgICAgID0gMHgxMDsK ICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgZWxzZQogICAgICAgICAgICAgIHsKICAgICAg ICAgICAgICAgIGRvX3dyaXRlcyA9IDA7CiAgICAgICAgICAgICAgICArK2JhZF9vcHRpb247CiAg ICAgICAgICAgICAgfQogICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICBkZWZhdWx0Ogog ICAgICAgICAgICAgICsrYmFkX29wdGlvbjsKICAgICAgICAgICAgICBicmVhazsKICAgICAgICAg IH0KCiAgICAgICAgICBicmVhazsKICAgICAgICBjYXNlICdRJzoKICAgICAgICAgIGRvX2xzZWVr ID0gMDsKICAgICAgICAgIGJyZWFrOwogICAgICAgIGNhc2UgJ3EnOgogICAgICAgICAgKytzZXF1 ZW50aWFsX2FjY2VzczsKICAgICAgICAgIGJyZWFrOwogICAgICAgIGNhc2UgJ1YnOgogICAgICAg ICAgKyt2aXN1YWxfcHJvZ3Jlc3M7CiAgICAgICAgICBicmVhazsKICAgICAgICBjYXNlICdTJzoK ICAgICAgICAgICsrdGVsbF9maWxlX3NpemU7CiAgICAgICAgICBicmVhazsKICAgICAgICBjYXNl ICdNJzoKICAgICAgICAgICsrbWJfcGVyX3NlYzsKICAgICAgICAgIGlvX3Blcl9zZWMgPSAwOwog ICAgICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSAnbCc6CiAgICAgICAgICArK2RvX2xvY2tmOwog ICAgICAgICAgYmxvY2tpbmdfbG9jayA9IDA7CiAgICAgICAgICBicmVhazsKICAgICAgICBjYXNl ICdMJzoKICAgICAgICAgICsrZG9fbG9ja2Y7CiAgICAgICAgICArK2Jsb2NraW5nX2xvY2s7CiAg ICAgICAgICBicmVhazsKICAgICAgICBjYXNlICdJJzoKICAgICAgICAgICsraW9fcGVyX3NlYzsK ICAgICAgICAgIG1iX3Blcl9zZWMgPSAwOwogICAgICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSAn bSc6CiAgICAgICAgICArK21pbGxpc2Vjb25kczsKICAgICAgICAgIGJyZWFrOwogICAgICAgIGNh c2UgJ3YnOgogICAgICAgICAgKyt2ZXJ5X2Zhc3Q7CiAgICAgICAgICBicmVhazsKICAgICAgICBj YXNlICd4JzoKICAgICAgICAgICsrZGVidWdfb247CiAgICAgICAgICBicmVhazsKICAgICAgICBj YXNlICdmJzoKICAgICAgICAgIGZpbGVfbmFtZSA9IG9wdGFyZzsKICAgICAgICAgIGlmICggKGZp bGVfbmFtZSA9PSBOVUxMKSB8fCAhZmlsZV9uYW1lICkKICAgICAgICAgICAgKytiYWRfb3B0aW9u OwogICAgICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSAnUic6CiAgICAgICAgICBub19vZl9yZWFk cyA9IChpbnQpIHN0cnRvdWwob3B0YXJnLCAoY2hhciAqKilOVUxMLCAwKTsKICAgICAgICAgIGlm ICggIW5vX29mX3JlYWRzICkKICAgICAgICAgICAgKytiYWRfb3B0aW9uOwogICAgICAgICAgYnJl YWs7CiAgICAgICAgY2FzZSAncyc6CiAgICAgICAgICBmaWxlX3NpemUgPSAoaW50KSBzdHJ0b3Vs KG9wdGFyZywgKGNoYXIgKiopTlVMTCwgMCk7CiAgICAgICAgICBpZiAoICFmaWxlX3NpemUgKQog ICAgICAgICAgICArK2JhZF9vcHRpb247CiAgICAgICAgICBicmVhazsKICAgICAgICBjYXNlICdy JzoKICAgICAgICAgIHJlY29yZF9zaXplID0gKGludCkgc3RydG91bChvcHRhcmcsIChjaGFyICoq KU5VTEwsIDApOwogICAgICAgICAgaWYgKCAhcmVjb3JkX3NpemUgKQogICAgICAgICAgICArK2Jh ZF9vcHRpb247CiAgICAgICAgICBicmVhazsKICAgICAgICBjYXNlICdwJzoKICAgICAgICAgIHBh c3NlcyA9IChpbnQpIHN0cnRvdWwob3B0YXJnLCAoY2hhciAqKilOVUxMLCAwKTsKICAgICAgICAg IGlmICggIHBhc3NlcyA8IDEgKQogICAgICAgICAgICArK2JhZF9vcHRpb247CiAgICAgICAgICBi cmVhazsKICAgICAgICBjYXNlICc/JzoKICAgICAgICAgICsrYmFkX29wdGlvbjsKICAgICAgICAg IGJyZWFrOwogICAgICB9CiAgICAgIGlmICggYmFkX29wdGlvbiApCiAgICAgICAgYnJlYWs7CiAg ICB9CiAgIH0KCiAgaWYgKCByZWNzX3Blcl9mc3luYyAmJiAhIGRvX29fc3luYyApCiAgewogICAg KHZvaWQpZnByaW50ZihzdGRlcnIsCiAgICAgICAgICAgICAgICAgICIlcyBPb29wczogIEZvciBz eW5jcm9ub3VzIFdSSVRFIG9wZXJhdGlvbnMsIHNwZWNpZnkgYm90aCAtbyBhbmQgLU8hXG4iLAog ICAgICAgICAgICAgICAgICBhcmd2WzBdKTsKICAgIGV4aXQoQkFEX09QVElPTik7CiAgfQoKICAv KiBWZXJpZnkgKGNhcmVmdWxseSEpIHRoYXQgd2UgcmVsbHkgd2FudCB0byB3cml0ZSBhbnl0aGlu ZyAqLwogIGlmICggKGRvX3dyaXRlcyAmJiAhIGVuYWJsZV93cml0ZXMpIHx8IChlbmFibGVfd3Jp dGVzICYmICFkb193cml0ZXMpICkKICB7CiAgICAodm9pZClmcHJpbnRmKHN0ZGVyciwKICAgICAg ICAgICAgICAgICAgIiVzIE9vb3BzOiAgRm9yIFdSSVRFIG9wZXJhdGlvbnMsIHNwZWNpZnkgYm90 aCAtVyBhbmQgLXchXG4iLAogICAgICAgICAgICAgICAgICBhcmd2WzBdKTsKICAgIGV4aXQoQkFE X09QVElPTik7CiAgfQogIGVsc2UKICAgIGRvX3dyaXRlcyB8PSBlbmFibGVfd3JpdGVzOwoKICBp ZiAoICFlbmFibGVfd3JpdGVzICkKICAgIHJlYWRfdGhlbl93cml0ZSA9IDA7CgogIC8qIGxzZWVr IGNhbiBiZSBkaXNhYmxlZCBvbmx5IGluIHNlcXVlbnRpYWwgUkVBRC1vbmx5IG1vZGUgKi8KICBp ZiAoICFzZXF1ZW50aWFsX2FjY2VzcyApCiAgICArK2RvX2xzZWVrOwoKICBpZiAoIGVuYWJsZV93 cml0ZXMgJiYgIWRvX2xzZWVrICkKICB7CiAgICAodm9pZCkgZnByaW50ZihzdGRlcnIsICIlcyBj YW5ub3QgYWNjZXB0IC1XIGFuZCAtUSB0b2dldGhlciFcbiIsIGFyZ3ZbMF0pOwogICAgZXhpdChC QURfT1BUSU9OKTsKICB9CgogIGlmICggZGVidWdfb24gKQogICAgKHZvaWQpIGZwcmludGYoc3Rk ZXJyLCBWRVJTSU9OKTsKICBpZiAoIGJhZF9vcHRpb24gfHwKICAgICAgICFmaWxlX25hbWUgIHx8 CiAgICAgICAhcmVjb3JkX3NpemUgfHwKICAgICAgICggKGZpbGVfc2l6ZSE9IDApICYmICggZmls ZV9zaXplIDwgcmVjb3JkX3NpemUpKQogICAgICkKICB7CiAgICAodm9pZCkgZnByaW50ZihzdGRv dXQsIFVTQUdFKTsKICAgIGV4aXQoQkFEX09QVElPTik7CiAgfQoKICBpZiAoIHN0YXQoZmlsZV9u YW1lLCAmc3RhdHVzX2J1ZmZlcikgKQogIHsKICAgIHBlcnJvcigiRmFpbGVkIHRvIG9idGFpbiBz dGF0dXMgb2YgcmVxdWVzdGVkIGZpbGUhIik7CiAgICBleGl0ICggU1RBVF9GQUlMRUQgKTsKICB9 CgogIGlmICggaW52YWxpZF9maWxlKHN0YXR1c19idWZmZXIuc3RfbW9kZSkgKQogIHsKICAgIHBl cnJvcigiQ2Fubm90IHBlcmZvcm0gcmFuZG9tIHNlZWtzIG9uIHRoaXMgdHlwZSBvZiBhIGZpbGUh Iik7CiAgICBleGl0ICggQkFEX0ZJTEVfVFlQRSApOwogIH0KCiAgLyogaWYgZmlsZSBzaXplIGlz IG5vdCBrbm93biB5ZXQsIGZpbmQgaXQgb3V0ICovCiAgaWYgKCAhZmlsZV9zaXplICkKICB7CiAg ICBpZiAoIGRlYnVnX29uICkKICAgICAgKHZvaWQpZnByaW50ZihzdGRlcnIsICJbJXM6JWRdOiBG aWxlX3NpemUgaXMgdW5rbm93bi4uLlxuIiwKICAgICAgICAgICAgICAgICAgICBfX0ZJTEVfXywg X19MSU5FX18pOwoKICAgIGlmICggaXNfZGlzayhzdGF0dXNfYnVmZmVyLnN0X21vZGUpICkKICAg IHsKICAgICAgaWYgKCBkZWJ1Z19vbiApCiAgICAgICAgKHZvaWQpZnByaW50ZihzdGRlcnIsICJb JXM6JWRdOiBBcHBlYXJzIHRvIGJlIGEgZGlzay4uLlxuIiwKICAgICAgICAgICAgICAgICAgICAg IF9fRklMRV9fLCBfX0xJTkVfXyk7CgogICAgICAvKiB0aGVyZSBpcyBubyBrbm93biBVbml4IHN5 c3RlbSBjYWxsIHRvIHJlcG9ydCBzaXplIG9mIGEgZGV2aWNlLi4uCiAgICAgICAqIFNvIHdlIHdp bGwgb3BlbiBpdCBhbmQgZmluZCAodGhlIGhhcmQgd2F5ICkgaXRzIHNpemUKICAgICAgICovCiAg ICAgIGlmICggKGRldmljZV9mZCA9IG9wZW4oZmlsZV9uYW1lLCBPX1JET05MWSkpID09IC0xICkK ICAgICAgewogICAgICAgIHBlcnJvcigiRmFpbGVkIHRvIG9wZW4gcmVxdWVzdGVkIGZpbGUiKTsK ICAgICAgICBleGl0KCBPUEVOX0ZBSUxFRCApOwogICAgICB9CiAgICAgIGVsc2UKICAgICAgewog ICAgICAgIC8qIEZvciBsYWNrIG9mIGJldHRlciB3YXkgb2YgZmluZGluZyBhIGRldmljZSBzaXpl LAogICAgICAgICAqIGRvIGEgYmluYXJ5IHNlYXJjaC4uLgoKICAgICAgICAgKiBzZXQgdG9wIG1h cmsKICAgICAgICAgKiBzZXQgYm90dG9tIG1hcmsKCiAgICAgICAgICogdHJ5IGhhbGYgd2F5Lgog ICAgICAgICAqIGlmIGZhaWxlZCB0b3AgbWFyayA9IGhhbGYgd2F5CiAgICAgICAgICogZWxzZSBi b3R0b20gPSBoYWxmIHdheS4KCiAgICAgICAgICogcmVwZWF0IHVudGlsIHRvcCAtIGJvdHRvbSA8 PSAxCiAgICAgICAgICovCgogICAgICAgIHJlZ2lzdGVyIHNpemVfdCB0b3Bfc2l6ZSAgICA9IExP TkdfTUFYLAogICAgICAgICAgICAgICAgICAgICAgICBib3R0b21fc2l6ZSA9IDAsCiAgICAgICAg ICAgICAgICAgICAgICAgIGhhbGZfc2l6ZSAgID0gMDsKCiAgICAgICAgbmR4ICAgICAgICAgPSAw OwoKICAgICAgICBkbwogICAgICAgIHsKICAgICAgICAgIGhhbGZfc2l6ZSA9IGJvdHRvbV9zaXpl ICsgKHRvcF9zaXplIC0gYm90dG9tX3NpemUpIC8gMjsKICAgICAgICAgIHN3aXRjaCAoIHNlZWtf ZW5kcG9pbnQoZGV2aWNlX2ZkLCBoYWxmX3NpemUpICkKICAgICAgICAgIHsKICAgICAgICAgICAg Y2FzZSAtMToKICAgICAgICAgICAgICBwZXJyb3IoImxzZWVrKDIpIGZhaWxlZCB3aGlsZSBzZWFy Y2hpbmcgZmlsZSBzaXplISIpOwogICAgICAgICAgICAgIHJldHVybiggTFNFRUtfRkFJTEVEICk7 CiAgICAgICAgICAgIGNhc2UgLTI6CiAgICAgICAgICAgIGNhc2UgMToKICAgICAgICAgICAgICB0 b3Bfc2l6ZSA9IGhhbGZfc2l6ZTsKICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgY2Fz ZSAwOgogICAgICAgICAgICAgIGJvdHRvbV9zaXplID0gaGFsZl9zaXplOwogICAgICAgICAgICAg IGJyZWFrOwogICAgICAgICAgfQoKICAgICAgICAgICsrbmR4OwogICAgICAgIH0KICAgICAgICB3 aGlsZSAoICh0b3Bfc2l6ZSAtIGJvdHRvbV9zaXplKSA+IDEgKTsKCiAgICAgICAgZmlsZV9zaXpl ID0gKHNpemVfdCl0b3Bfc2l6ZTsKCiAgICAgICAgaWYgKCBkZWJ1Z19vbiApCiAgICAgICAgICAo dm9pZClmcHJpbnRmKHN0ZGVyciwKICAgICAgICAgICAgICAgICAgICAgICAgIlslczolZF06IERp c2sgc2l6ZSBvZiAldWwgZGV0ZXJtaW5lZCBpbiAlZCBwYXNzZXNcbiIsCiAgICAgICAgICAgICAg ICAgICAgICAgIF9fRklMRV9fLCBfX0xJTkVfXywgZmlsZV9zaXplLCBuZHgpOwogICAgICB9Cgog ICAgICAodm9pZCkgY2xvc2UoZGV2aWNlX2ZkKTsKICAgICAgZGV2aWNlX2ZkID0gLTE7CgogICAg fQogICAgZWxzZQogICAgewogICAgICBmaWxlX3NpemUgPSAoc2l6ZV90KXN0YXR1c19idWZmZXIu c3Rfc2l6ZTsKCiAgICAgIGlmICggZGVidWdfb24gKQogICAgICAgICh2b2lkKWZwcmludGYoc3Rk ZXJyLAogICAgICAgICAgICAgICAgICAgICAgIlslczolZF06IE8vUyByZXBvcnRlZCBkaXNrIHNp emUgb2YgJXVcbiIsCiAgICAgICAgICAgICAgICAgICAgICBfX0ZJTEVfXywgX19MSU5FX18sIGZp bGVfc2l6ZSk7CiAgICB9CiAgfQoKICBpZiAoIHRlbGxfZmlsZV9zaXplICkKICB7CiAgICBpZiAo IG1iX3Blcl9zZWMgKQogICAgewogICAgICAodm9pZCkgZnByaW50ZihzdGRvdXQsICJBY3R1YWwg U2l6ZSA9ICV1LiUwMnVNQiwgIiwKICAgICAgICAgICAgICAgICAgICAgZmlsZV9zaXplIC8gKDEw MjQgKiAxMDI0KSwKICAgICAgICAgICAgICAgICAgICAgKGZpbGVfc2l6ZSAlICgxMDI0ICogMTAy NCkgLyAxMDAwMCkpOwogICAgfQogICAgZWxzZQogICAgICAodm9pZCkgZnByaW50ZihzdGRvdXQs ICJBY3R1YWwgU2l6ZSA9ICV1LCAiLCBmaWxlX3NpemUpOwogIH0KCiAgLyogUm91bmQgZmlsZSBz aXplIGRvd24gdG8gY29tcGxldGUgbnVtYmVyIG9mIHJlY29yZHMgKi8KICBmaWxlX3NpemUgPSBy ZWNvcmRfc2l6ZSAqICggZmlsZV9zaXplIC8gcmVjb3JkX3NpemUpOwoKICBpZiAoIHRlbGxfZmls ZV9zaXplICkKICB7CiAgICBpZiAoIG1iX3Blcl9zZWMgKQogICAgICAodm9pZCkgZnByaW50Zihz dGRvdXQsICJVc2VkIFNpemUgPSAldS4lMDJ1TUJcbiIsCiAgICAgICAgICAgICAgICAgICAgIGZp bGVfc2l6ZSAvIE1FR0FCWVRFLAogICAgICAgICAgICAgICAgICAgICAoZmlsZV9zaXplICUgTUVH QUJZVEUgLyAxMDAwMCkpOwogICAgZWxzZQogICAgICAodm9pZCkgZnByaW50ZihzdGRvdXQsICJV c2VkIFNpemUgPSAldVxuIiwgZmlsZV9zaXplKTsKICB9CgogIGlmICggZGVidWdfb24gKQogICAg KHZvaWQpZnByaW50ZihzdGRlcnIsICJbJXM6JWRdOiBGaWxlX3NpemUgaXMgJXVcbiIsCiAgICAg ICAgICAgICAgICAgIF9fRklMRV9fLCBfX0xJTkVfXywgZmlsZV9zaXplKTsKCiAgLyogQWxsb2Nh dGUgbWVtb3J5IGZvciB0aGUgaW5wdXQgYnVmZmVyICovCiAgaWYgKCAoYnVmZmVyID0gbWFsbG9j KHJlY29yZF9zaXplKSkgPT0gTlVMTCApCiAgewogICAgcGVycm9yKCJDYW5ub3QgYWxsb2NhdGUg YnVmZmVyIGZvciByZWFkIG9wZXJhdGlvbnMiKTsKICAgIGV4aXQgKCBNQUxMT0NfRkFJTEVEICk7 CiAgfQoKICBpZiAoIGRlYnVnX29uICkKICAgICh2b2lkKWZwcmludGYoc3RkZXJyLAogICAgICAg ICAgICAgICAgICAiWyVzOiVkXTogQWxsb2NhdGVkICVkIGJ5dGVzIG9mIGJ1ZmZlciBzcGFjZVxu IiwKICAgICAgICAgICAgICAgICAgX19GSUxFX18sIF9fTElORV9fLCByZWNvcmRfc2l6ZSk7Cgog IC8qIHRoZXJlIGlzIGEgbGliYyB0aGluZyB0aGF0IGRvZXMgdGhhdC4gIFdoYXQncyBpdHMgbmFt ZT8gKi8KICBpZiAoIGRvX3dyaXRlcyA9PSBET19XUklURVMgKQogIHsKICAgICh2b2lkKW1lbXNl dCgodm9pZCAqKWJ1ZmZlciwgd3JpdGVfcGF0dGVybiwgcmVjb3JkX3NpemUpOwogIH0KCiAgLyog SWYgbmVjZXNzYXJ5LCBvcGVuIHRoZSBmaWxlICovCiAgaWYgKCBkZXZpY2VfZmQgPT0gLTEgKQog IHsKICAgIGludCBtb2RlOwoKICAgIGlmICggZW5hYmxlX3dyaXRlcyApCiAgICB7CiAgICAgIG1v ZGUgPSBPX1JEV1I7CiAgICAgIGlmICggZG9fb19zeW5jICkKICAgICAgewogICAgICAgIG1vZGUg fD0gT19TWU5DOwogICAgICB9CiAgICB9CiAgICBlbHNlCiAgICB7CiAgICAgIG1vZGUgPSBPX1JE T05MWTsKICAgIH0KCiAgICBpZiAoIChkZXZpY2VfZmQgPSBvcGVuKGZpbGVfbmFtZSwgbW9kZSkp ID09IC0xICkKICAgIHsKICAgICAgcGVycm9yKCJGYWlsZWQgdG8gb3BlbiByZXF1ZXN0ZWQgZmls ZSIpOwogICAgICByZXR1cm4oIE9QRU5fRkFJTEVEICk7CiAgICB9CgogICAgaWYgKCBkZWJ1Z19v biApCiAgICAgICh2b2lkKWZwcmludGYoc3RkZXJyLAogICAgICAgICAgICAgICAgICAgICJbJXM6 JWRdOiBPcGVuZWQgJXNcbiIsCiAgICAgICAgICAgICAgICAgICAgX19GSUxFX18sIF9fTElORV9f LCBmaWxlX25hbWUpOwoKICB9CgogIC8qIFdlIHNldCB0aGlzIG9uZSBsYXRlLCB0byBsZXQgYWxs IG90aGVyIGNvbXB1dGF0aW9uIGJlIGRvbmUgZmlyc3QgKi8KICByZWNvcmRzID0gZmlsZV9zaXpl IC8gcmVjb3JkX3NpemU7CiAgaWYgKCAhbm9fb2ZfcmVhZHMgKQogIHsKICAgIG5vX29mX3JlYWRz ID0gcmVjb3JkczsKICB9CgogIC8qIGxvb3AgYXMgbXVjaCBhcyBuZWNlc3NhcnkgKi8KICBmb3Ig KG5keCA9IDA7IG5keCA8IHBhc3NlczsgbmR4KysgKQogIHsKICAgIHJlZ2lzdGVyIGludCByZWFk X25vICA9IDAsCiAgICAgICAgICAgICAgICAgZnN5bmNfbm8gPSAwOwoKICAgIC8qIEluaXRpYWxp emUgdGhlIHJhbmRvbSBudW1iZXIgZ2VuZXJhdG9yLCBvbmNlIHBlciBpdGVyYXRpb24gKi8KICAg IGlmICggIXNlcXVlbnRpYWxfYWNjZXNzICkKICAgICAgc3JhbmQoKGxvbmcpdGltZSgodGltZV90 ICopMCkpOwoKICAgIGlmICggZGVidWdfb24gKQogICAgICAodm9pZClmcHJpbnRmKHN0ZGVyciwK ICAgICAgICAgICAgICAgICAgICAiWyVzOiVkXTogUGFzcyAlZFxuIiwKICAgICAgICAgICAgICAg ICAgICBfX0ZJTEVfXywgX19MSU5FX18sIG5keCk7CgogICAgaWYgKCB2aXN1YWxfcHJvZ3Jlc3Mg KQogICAgICAodm9pZCkgZnByaW50ZihzdGRvdXQsICJcbiVkOiAiLCBuZHgpOwoKICAgIGlmICgg dmVyeV9mYXN0ICkKICAgICAgc3RhcnRfdGltZSAgPSB0aW1lcygmdGltZXNfc3RydWN0KTsKCiAg ICAvKiBMc2VlayBpbml0aWFsbHkgaWYgbm8gc2Vla3Mgd2FudGVkICovCiAgICBpZiAoICFkb19s c2VlayApCiAgICB7CiAgICAgIGlmICggbHNlZWsoZGV2aWNlX2ZkLCAwLCBTRUVLX1NFVCkgPT0g LTEgKQogICAgICAgIHBlcnJvcigiRmFpbGVkIHRvIHByZS1zZWVrIik7CgogICAgICBpZiAoIGRl YnVnX29uICkKICAgICAgICAodm9pZClmcHJpbnRmKHN0ZGVyciwgIlslczolZF06IFByZS1zZWVr ZWQgdG8gcmVjb3JkIDBcbiIsCiAgICAgICAgICAgICAgICAgICAgICBfX0ZJTEVfXywgX19MSU5F X18pOwogICAgfQoKICAgIGZvciAoIHJlYWRfbm8gPSAwOyByZWFkX25vIDwgbm9fb2ZfcmVhZHM7 IHJlYWRfbm8rKyApCiAgICB7CiAgICAgIHJlZ2lzdGVyICBzaXplX3QgICByZWNvcmRfbm8gICAg PSAwOwogICAgICByZWdpc3RlciAgc2l6ZV90ICAgb2Zmc2V0ICAgICAgID0gMDsKICAgICAgcmVn aXN0ZXIgIHNzaXplX3QgIHJlYWRfcmVzdWx0ICA9IDAsCiAgICAgICAgICAgICAgICAgICAgICAg ICB3cml0ZV9yZXN1bHQgPSAwOwoKICAgICAgaWYgKCBzZXF1ZW50aWFsX2FjY2VzcyApCiAgICAg IHsKICAgICAgICBpZiAoIGRvX2xzZWVrICkKICAgICAgICAgIHJlY29yZF9ubyA9IHJlYWRfbm87 CiAgICAgIH0KICAgICAgZWxzZQogICAgICB7CiAgICAgICAgc3NpemVfdCByYW5kb20gPSBscmFu ZDQ4KCk7CgogICAgICAgIHJlY29yZF9ubyA9IHJhbmRvbSAlIHJlY29yZHM7CgogICAgICAgIGlm ICggZGVidWdfb24gKQogICAgICAgICAgKHZvaWQpZnByaW50ZihzdGRlcnIsCiAgICAgICAgICAg ICAgICAgICAgICAgICJbJXMuJWRdOiByYW5kb20gPSAldSwgcmVhZHMgPSAldSwgcmVjb3JkX25v ID0gJXVcbiIsCiAgICAgICAgICAgICAgICAgICAgICAgIF9fRklMRV9fLCBfX0xJTkVfXywgcmFu ZG9tLCByZWNvcmRzLCByZWNvcmRfbm8pOwogICAgICB9CgogICAgICBpZiAoIGRvX2xzZWVrICkK ICAgICAgewogICAgICAgIG9mZnNldCA9IHJlY29yZF9ubyAqIHJlY29yZF9zaXplOwoKICAgICAg ICBpZiAoIGxzZWVrKGRldmljZV9mZCwgb2Zmc2V0LCBTRUVLX1NFVCkgPT0gLTEgKQogICAgICAg IHsKICAgICAgICAgICAgcGVycm9yKHNlcXVlbnRpYWxfYWNjZXNzID8gIkZhaWxlZCB0byBzZWVr IGluIFNlcXVlbnRpYWwgbW9kZSIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDogIkZhaWxlZCB0byBzZWVrIGluIFJhbmRvbSBtb2RlIik7CiAgICAgICAgICAgIGV4aXQgKExT RUVLX0ZBSUxFRCApOwogICAgICAgIH0KCiAgICAgICAgaWYgKCBkZWJ1Z19vbiApCiAgICAgICAg ICAodm9pZClmcHJpbnRmKHN0ZGVyciwKICAgICAgICAgICAgICAgICAgICAgICAgIlslczolZF06 IEFjY2VzcyAlZCBzZWVrZWQgdG8gcmVjb3JkICV1IG9mICV1XG4iLAogICAgICAgICAgICAgICAg ICAgICAgICBfX0ZJTEVfXywgX19MSU5FX18sIHJlYWRfbm8sIHJlY29yZF9ubywgbm9fb2ZfcmVh ZHMpOwogICAgICAgIGVsc2UKICAgICAgICAgIGlmICggdmlzdWFsX3Byb2dyZXNzICkKICAgICAg ICAgICAgKHZvaWQpIGZwdXRjKCcuJywgc3Rkb3V0KTsKICAgICAgfQoKICAgICAgaWYgKCBkb19s b2NrZiApCiAgICAgIHsKICAgICAgICBpbnQgbG9ja19tb2RlOwoKICAgICAgICBpZiAoIGJsb2Nr aW5nX2xvY2sgKQogICAgICAgICAgbG9ja19tb2RlID0gRl9MT0NLOwogICAgICAgIGVsc2UKICAg ICAgICAgIGxvY2tfbW9kZSA9IEZfVExPQ0s7CgojaWZkZWYgX19GcmVlQlNEX18KICAgICAgICBp ZiAoIGZsb2NrKGRldmljZV9mZCwgbG9ja19tb2RlKSA9PSAtMSApCiNlbHNlCiAgICAgICAgaWYg KCBsb2NrZihkZXZpY2VfZmQsIGxvY2tfbW9kZSwgcmVjb3JkX3NpemUpID09IC0xICkKI2VuZGlm CiAgICAgICAgewojaWZkZWYgX19GcmVlQlNEX18KICAgICAgICAgIGlmICggKGVycm5vID09IEVX T1VMREJMT0NLKSAmJiAobG9ja19tb2RlID09IEZfVExPQ0spICkKI2Vsc2UKICAgICAgICAgIGlm ICggKGVycm5vID09IEVBR0FJTikgJiYgKGxvY2tfbW9kZSA9PSBGX1RMT0NLKSApCiNlbmRpZgog ICAgICAgICAgewogICAgICAgICAgICBpZiAoIGRlYnVnX29uICkKICAgICAgICAgICAgewogICAg ICAgICAgICAgICh2b2lkKWZwcmludGYoc3RkZXJyLAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgIlslczolZF06IFJlY29yZCAlZCBpcyBhbHJlYWR5IGxvY2tlZFxuIiwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgIF9fRklMRV9fLCBfX0xJTkVfXywgcmVjb3JkX25vKTsKICAgICAgICAg ICAgfQogICAgICAgICAgICBlbHNlCiAgICAgICAgICAgIHsKICAgICAgICAgICAgICBpZiAoIHZp c3VhbF9wcm9ncmVzcyApCiAgICAgICAgICAgICAgICAodm9pZCkgZnB1dGMoJ0wnLCBzdGRvdXQp OwogICAgICAgICAgICAgIGVsc2UKICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAodm9p ZCkgZnByaW50ZihzdGRlcnIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiJXMgRVJS T1I6ICBGYWlsZWQgdG8gbG9jayByZWNvcmQgJWQgKCVkKVxuIiwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFyZ3ZbMF0sIHJlY29yZF9ubywgZXJybm8pOwogICAgICAgICAgICAgICAg ZXhpdCgxKTsKICAgICAgICAgICAgICB9CiAgICAgICAgICAgIH0KICAgICAgICAgIH0KICAgICAg ICB9CiAgICAgIH0KCiAgICAgIGlmICggdmlzdWFsX3Byb2dyZXNzICkKICAgICAgICAodm9pZCkg ZnB1dGMoJy4nLCBzdGRvdXQpOwoKICAgICAgLyogVGFrZSBhIHRpbWUgc3RhbXAuCiAgICAgICAq IFdlIGRvIG5vdCBjaGVjayByZXR1cm4gdmFsdWUgYXMgaXQgY2FuIG9ubHkgZmFpbCBpZiB0aGUK ICAgICAgICogcG9pbnRlciBpcyBpbnZhbGlkLi4uCiAgICAgICAqLwoKICAgICAgaWYgKCAhdmVy eV9mYXN0ICkKICAgICAgICBzdGFydF90aW1lICA9IHRpbWVzKCZ0aW1lc19zdHJ1Y3QpOwoKICAg ICAgaWYgKCBkb193cml0ZXMgPT0gRE9fV1JJVEVTICkKICAgICAgewogICAgICAgIHdyaXRlX3Jl c3VsdCA9IHdyaXRlKGRldmljZV9mZCwgKHZvaWQgKilidWZmZXIsIHJlY29yZF9zaXplKTsKICAg ICAgICBpZiAoIHdyaXRlX3Jlc3VsdCAhPSByZWNvcmRfc2l6ZSkKICAgICAgICB7CiAgICAgICAg ICAod3JpdGVfcmVzdWx0ID09IChNQVhJTlQpKQogICAgICAgICAgICA/IHBlcnJvcigiV3JpdGUg b3BlcmF0aW9uIGZhaWxlZDogIikKICAgICAgICAgICAgOiAodm9pZClmcHJpbnRmKHN0ZGVyciwg IiVzIFNob3J0IFdyaXRlIVxuIiwgYXJndlswXSk7CgogICAgICAgICAgaWYgKCBkb19sb2NrZiAp CiNpZmRlZiBfX0ZyZWVCU0RfXwogICAgICAgICAgICAodm9pZCkgZmxvY2soZGV2aWNlX2ZkLCBG X1VMT0NLKTsKI2Vsc2UKICAgICAgICAgICAgKHZvaWQpIGxvY2tmKGRldmljZV9mZCwgRl9VTE9D SywgcmVjb3JkX3NpemUpOwojZW5kaWYKCiAgICAgICAgICBnb3RvIGFicnVwdF9lbmQ7CiAgICAg ICAgfQogICAgICAgIGVsc2UKICAgICAgICB7CiAgICAgICAgICBpZiAoIHJlY3NfcGVyX2ZzeW5j ICkKICAgICAgICAgIHsKICAgICAgICAgICAgaWYgKCArK2ZzeW5jX25vID09IHJlY3NfcGVyX2Zz eW5jICkKICAgICAgICAgICAgewogICAgICAgICAgICAgIGZzeW5jX25vID0gMDsKICAgICAgICAg ICAgICBpZiAoIGZzeW5jKGRldmljZV9mZCkgKQogICAgICAgICAgICAgIHsKICAgICAgICAgICAg ICAgIHBlcnJvcigiRmFpbGVkIHRvIHN5bmNocm9uaXplIHdyaXRlcyIpOwogICAgICAgICAgICAg ICAgZ290byBhYnJ1cHRfZW5kOwogICAgICAgICAgICAgIH0KICAgICAgICAgICAgfQogICAgICAg ICAgfQogICAgICAgIH0KICAgICAgfQogICAgICBlbHNlCiAgICAgIHsKICAgICAgICByZWFkX3Jl c3VsdCA9IChzc2l6ZV90KXJlYWQoZGV2aWNlX2ZkLCAodm9pZCAqKWJ1ZmZlciwgcmVjb3JkX3Np emUpOwogICAgICAgIGlmICggcmVhZF9yZXN1bHQgIT0gcmVjb3JkX3NpemUpCiAgICAgICAgewog ICAgICAgICAgICBpZiAocmVhZF9yZXN1bHQgPT0gLTEpCiAgICAgICAgICAgICAgcGVycm9yKCJS ZWFkIG9wZXJhdGlvbiBmYWlsZWQ6ICIpOwogICAgICAgICAgICBlbHNlICh2b2lkKWZwcmludGYo c3RkZXJyLCAiJXMgU2hvcnQgUmVhZCAoJWQpIVxuIiwgYXJndlswXSwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHJlYWRfcmVzdWx0KTsKICAgICAgICAgICAgZ290byBhYnJ1cHRfZW5k OwogICAgICAgIH0KCiAgICAgICAgaWYgKCByZWFkX3RoZW5fd3JpdGUgKQogICAgICAgIHsKICAg ICAgICAgIGlmICggbHNlZWsoZGV2aWNlX2ZkLCBvZmZzZXQsIFNFRUtfU0VUKSA9PSAtMSApCiAg ICAgICAgICB7CiAgICAgICAgICAgIHBlcnJvcihzZXF1ZW50aWFsX2FjY2VzcyA/ICJGYWlsZWQg dG8gcmUtc2VlayBpbiBTZXF1ZW50aWFsIG1vZGUiCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA6ICJGYWlsZWQgdG8gcmUtc2VlayBpbiBSYW5kb20gbW9kZSIpOwogICAgICAg ICAgICBleGl0IChMU0VFS19GQUlMRUQgKTsKICAgICAgICAgIH0KICAgICAgICAgIHdyaXRlX3Jl c3VsdCA9IHdyaXRlKGRldmljZV9mZCwgKHZvaWQgKilidWZmZXIsIHJlY29yZF9zaXplKTsKICAg ICAgICAgIGlmICggd3JpdGVfcmVzdWx0ICE9IHJlY29yZF9zaXplKQogICAgICAgICAgewogICAg ICAgICAgICAod3JpdGVfcmVzdWx0ID09IC0xKQogICAgICAgICAgICAgID8gcGVycm9yKCJSZS1X cml0ZSBvcGVyYXRpb24gZmFpbGVkOiAiKQogICAgICAgICAgICAgIDogKHZvaWQpZnByaW50Zihz dGRlcnIsICIlcyBTaG9ydCBSZS1Xcml0ZSAoJWQpIVxuIiwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgYXJndlswXSwgd3JpdGVfcmVzdWx0KTsKICAgICAgICAgICAgZ290byBhYnJ1cHRf ZW5kOwogICAgICAgICAgfQogICAgICAgIH0KICAgICAgfQoKI2lmZGVmIF9fRnJlZUJTRF9fCiAg ICAgICh2b2lkKWZsb2NrKGRldmljZV9mZCwgRl9VTE9DSyk7CiNlbHNlCiAgICAgICh2b2lkKWxv Y2tmKGRldmljZV9mZCwgRl9VTE9DSywgcmVjb3JkX3NpemUpOwojZW5kaWYKCiAgICAgIGlmICgg IXZlcnlfZmFzdCApCiAgICAgICAgZmluaXNoX3RpbWUgPSB0aW1lcygmdGltZXNfc3RydWN0KTsK ICAgICAgCiAgICAgIGlmICggIXZlcnlfZmFzdCApCiAgICAgICAgYWNjdW11bGF0ZWRfdGltZSAr PSAoZmluaXNoX3RpbWUgLSBzdGFydF90aW1lKTsKCiAgICAgIGlmICggIXZlcnlfZmFzdCAmJiBk ZWJ1Z19vbiApCiAgICAgICAgKHZvaWQpZnByaW50ZihzdGRlcnIsCiAgICAgICAgICAgICAgICAg ICAgICAiWyVzOiVkXTogRG9uZSBpbiAlbHUgdGlja3MsIHRvdGFsIGlzICVsdSB0aWNrc1xuIiwK ICAgICAgICAgICAgICAgICAgICAgIF9fRklMRV9fLCBfX0xJTkVfXywKICAgICAgICAgICAgICAg ICAgICAgIGZpbmlzaF90aW1lIC0gc3RhcnRfdGltZSwgYWNjdW11bGF0ZWRfdGltZSk7CgoKICAg IH0KCiAgICBpZiAoIHZlcnlfZmFzdCApCiAgICB7CiAgICAgIGZpbmlzaF90aW1lID0gdGltZXMo JnRpbWVzX3N0cnVjdCk7CiAgICAgIGFjY3VtdWxhdGVkX3RpbWUgKz0gKGZpbmlzaF90aW1lIC0g c3RhcnRfdGltZSk7CiAgICB9CiAgfQoKYWJydXB0X2VuZDoKCiAgaWYgKCBhY2N1bXVsYXRlZF90 aW1lID09IDAgKQogICAgZXhpdCgxKTsKCiAgaWYgKHZpc3VhbF9wcm9ncmVzcyApCiAgICAodm9p ZCkgZnB1dGMoJ1xuJywgc3Rkb3V0KTsKCiAgaWYgKCBtYl9wZXJfc2VjICkKICB7CiAgICBkb3Vi bGUgYnl0ZXNfcGVyX3RpYyA9IChkb3VibGUpZmlsZV9zaXplICogKGRvdWJsZSlwYXNzZXMgLyAo ZG91YmxlKWFjY3VtdWxhdGVkX3RpbWU7CgogICAgKHZvaWQpIGZwcmludGYoc3Rkb3V0LCAiJS4y ZlxuIiwgYnl0ZXNfcGVyX3RpYyk7CiAgfQogIGVsc2UgaWYgKCBpb19wZXJfc2VjICkKICB7CiAg ICBkb3VibGUgcmVzdWx0ID0gKGRvdWJsZSlDTEtfVENLICogKGRvdWJsZSlmaWxlX3NpemUgKiAo ZG91YmxlKXBhc3NlcyBcCiAgICAgICAgICAgICAgICAgICAgLyAoZG91YmxlKXJlY29yZF9zaXpl IC8gKGRvdWJsZSlhY2N1bXVsYXRlZF90aW1lOwogICAgKHZvaWQpIGZwcmludGYoc3Rkb3V0LCAi JS4yZlxuIixyZXN1bHQpOwoKICB9CiAgZWxzZSBpZiAoIG1pbGxpc2Vjb25kcyApCiAgewogICAg ZG91YmxlIHJlc3VsdCA9IChkb3VibGUpYWNjdW11bGF0ZWRfdGltZSAqIChkb3VibGUpMTAwMCAv IChkb3VibGUpQ0xLX1RDSzsKICAgICh2b2lkKSBmcHJpbnRmKHN0ZG91dCwgIiUuMmZcbiIsIHJl c3VsdCk7CiAgfQogIGVsc2UKICB7CiAgICAodm9pZCkgZnByaW50ZihzdGRvdXQsICIlbHVcbiIs IGFjY3VtdWxhdGVkX3RpbWUpOwogIH0KICByZXR1cm4oMCk7Cn0KCg== --_=XFMail.1.1-alpha.p0.FreeBSD:970130150229:7353=_-- End of MIME message From owner-freebsd-hackers Thu Jan 30 14:47:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07077 for hackers-outgoing; Thu, 30 Jan 1997 14:47:30 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07058 for ; Thu, 30 Jan 1997 14:47:25 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id PAA09348; Thu, 30 Jan 1997 15:45:49 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970129151534.YC06799@usn.blaze.net.au> Date: Thu, 30 Jan 1997 12:21:39 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: (David Nugent) Subject: Re: 2.2-BETA Questions Cc: hackers@FreeBSD.org, (Michael Smith) Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi David Nugent; On 29-Jan-97 you wrote: ... > FWIW, I've seen this too. It occurs only when mounting a Linux ext2 > filesystem on a FreeBSD system, and then only sometimes. Unfortunately > that "sometimes" is *always* repeatable between any two boxes on which > it occurs and there doesn't seem to be any other way around it. the fix for that was posted already. Add -o resvport to the NFS mount options. ... The non-music CD is actually a ``Simon's Blind Special''. The CD is, on my system wcd0, not cd0. The /etc/fstab entry for /cdrom survived. The entries in /dev/ did not (after an upgrade). ... > This question is indicative of the biggest transition problems > in coming from any other PC operating system to BSD. Terminology: > > 'slice' is the same as a "partition" in DOS/OS2 terms. > 'partition' is the internal scheme BSD uses for paritioning > disks. Yup. Just like SVR4 :-) Thanx for the help... Simon From owner-freebsd-hackers Thu Jan 30 14:47:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07081 for hackers-outgoing; Thu, 30 Jan 1997 14:47:31 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07063 for ; Thu, 30 Jan 1997 14:47:27 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id PAA09351; Thu, 30 Jan 1997 15:45:49 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970129152117.AA45867@usn.blaze.net.au> Date: Thu, 30 Jan 1997 12:39:25 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: (David Nugent) Subject: Re: 2.2-BETA Questions Cc: hackers@freebsd.org, (Jordan K. Hubbard) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi David Nugent; On 29-Jan-97 you wrote: > Jordan K. Hubbard writes: > > > 7. trying /stand/sysinstall from a live system dumps core either on > > > (the equivalent of) fdisk or disklabel. > > > > Fixed in later versions. > > Great, at last! > > (fx: runs off to /usr/src/release and builds sysinstall for next > time... :-)). > > FWIW, last time I tried (installing 2.2-BETA), fdisk did work fine, > but it dumped core when writing the disklabel. Yup. Exactly so. Simon From owner-freebsd-hackers Thu Jan 30 14:50:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07488 for hackers-outgoing; Thu, 30 Jan 1997 14:50:14 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07477 for freebsd-hackers; Thu, 30 Jan 1997 14:50:11 -0800 (PST) From: Mike Pritchard Message-Id: <199701302250.OAA07477@freefall.freebsd.org> Subject: grp.h To: freebsd-hackers Date: Thu, 30 Jan 1997 14:50:10 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Shouldn't the declaration in grp.h read: gid_t gr_gid; instead of: int gr_gid; like it currently does? It also looks like pwd.h also declares the uid and gid as ints instead of using the typedefs. -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-hackers Thu Jan 30 14:54:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07802 for hackers-outgoing; Thu, 30 Jan 1997 14:54:30 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07791 for ; Thu, 30 Jan 1997 14:54:25 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.4/8.7.3) with SMTP id OAA26629 for ; Thu, 30 Jan 1997 14:54:24 -0800 (PST) Date: Thu, 30 Jan 1997 14:54:24 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org Subject: $confusion == CVSUP + Jaye_Mathisen Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm sorry, I'm really trying... I installed a 2.2-BETA SNAP on a box. I take the standard-supfile, set the tage to RELENG_2_2, and fire up CVSUP 14.1. It merrily cranks along, and retrieves numerous files and diffs from src-all So then I go to /usr/src, kick out a make world, and come back in a couple hours. Reboot, and voila', I still have old gook there. Like sendmail 8.8.4, which I could've sworn was updated to 8.8.5 in 2.2 several days ago. I regularly have an unbuildable /usr/src, and just renaming /usr/src to /usr/src.bak and re-cvsupping gets me a usable tree. Is it just me? Is there something obviously wrong with my procedure here? It also seems odd to me that there's a -stable branch which matches up with 2.1??? A standard branch which seems to generate a 3.0-current, and nothing in the examples that deliberately points to 2.2-nearly-released. Yet if you installed 2.2-nearly-released, you should get a cvsup file that lets you work with what you got... From owner-freebsd-hackers Thu Jan 30 15:01:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA08134 for hackers-outgoing; Thu, 30 Jan 1997 15:01:20 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA08107 for ; Thu, 30 Jan 1997 15:01:17 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA07037; Fri, 31 Jan 1997 00:01:14 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA28752; Thu, 30 Jan 1997 22:28:07 +0100 (MET) Message-ID: Date: Thu, 30 Jan 1997 22:28:07 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: mcgovern@spoon.beta.com (Brian J. McGovern) Subject: Re: Device Drivers 101 References: <199701300505.AAA09649@spoon.beta.com> <199701300601.QAA27658@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701300601.QAA27658@genesis.atrad.adelaide.edu.au>; from Michael Smith on Jan 30, 1997 16:31:38 +1030 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Michael Smith wrote: > Devfs doesn't really 'do' major and minor numbers; there's a logically > direct translation from the named node to your switch entry and the > unit number you supply when you create the node. Though, it's a very good idea to leave the major number assignment to devfs. The existing drivers don't do this yet, but i think once devfs is really up for the masses, we should walk through the tree and avoid hard allocations wherever possible. (I.e., almost everything except those devices the bootstrap code has builtin knowlege about.) I think you can achieve automatic major number assignment by passing -1 down to devfs. Julian might comment on this. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Jan 30 15:01:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA08198 for hackers-outgoing; Thu, 30 Jan 1997 15:01:50 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA08179 for ; Thu, 30 Jan 1997 15:01:46 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA07056; Fri, 31 Jan 1997 00:01:38 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA28769; Thu, 30 Jan 1997 22:39:11 +0100 (MET) Message-ID: Date: Thu, 30 Jan 1997 22:39:11 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: mrcpu@schizo.cdsnet.net (Jaye Mathisen) Cc: hackers@freebsd.org Subject: Re: Bind 4.9.5-P1 on FreeBSD going bonkers... References: <199701300614.WAA01444@schizo.cdsnet.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701300614.WAA01444@schizo.cdsnet.net>; from Jaye Mathisen on Jan 29, 1997 22:14:06 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Jaye Mathisen wrote: > This is a serious problem, since my squid server won't use any > non-authoritative answers from the DNS, and so several thousand > customers can't access the web. I would consider this behaviour broken. It defeats the idea of the DNS cache. I haven't observed it on our version of squid. > Restarting named *always* fixes it. Of course, since it always blows the DNS cache. Basically, a non- authoritative answer means nothing more than it's an answer not from a primary or secondary server, but out of the DNS cache of some other server (your own one, or a DNS server upstream if you're using the `forwarders' feature). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Jan 30 15:23:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA09422 for hackers-outgoing; Thu, 30 Jan 1997 15:23:38 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA09417 for ; Thu, 30 Jan 1997 15:23:35 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA07621; Fri, 31 Jan 1997 00:23:27 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id AAA29229; Fri, 31 Jan 1997 00:11:13 +0100 (MET) Message-ID: Date: Fri, 31 Jan 1997 00:11:13 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: eivind@dimaga.com (Eivind Eklund) Cc: hackers@freebsd.org Subject: Re: References: <3.0.32.19970130220618.00aea190@dimaga.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <3.0.32.19970130220618.00aea190@dimaga.com>; from Eivind Eklund on Jan 30, 1997 22:06:20 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Eivind Eklund wrote: > When was this introduced, and is there any way for me to check if it is > present? (BSD > xxxx, for instance?) #include #if __FreeBSD_version >= 199702 # define NEED_NET_IF_VAR_H #endif That catches some -current systems before the change, but that shouldn't matter. It doesn't hit 2.2 machines, since they are frozen to 199701 (even though it's obvious that we won't ship 2.2R by January). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Jan 30 15:32:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10102 for hackers-outgoing; Thu, 30 Jan 1997 15:32:42 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10094 for ; Thu, 30 Jan 1997 15:32:37 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id TAA19616; Thu, 30 Jan 1997 19:16:58 GMT Message-Id: <199701301916.TAA19616@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Harlan Stenn Subject: Re: PR2347 - recursive malloc() in ppp Cc: hackers@freebsd.org In-reply-to: Your message of "Thu, 30 Jan 1997 05:09:13 EST." <24845.854618953@mumps.pfcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 19:16:58 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Are you maintining ppp these days? > > If so, did you get my email about needed to rotate the log file upon > receipt of, say, SIGUSR1? > > H I recall the email. In theory, as ppp uses syslog(), newsyslog & syslog should co-operate to make this possible and it should be outside of ppp's control. Having said that, I'm not sure that things are working correctly. I'll look into it and get back. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Jan 30 15:33:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10159 for hackers-outgoing; Thu, 30 Jan 1997 15:33:03 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10145 for ; Thu, 30 Jan 1997 15:32:59 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id TAA19712; Thu, 30 Jan 1997 19:39:13 GMT Message-Id: <199701301939.TAA19712@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: jgreco@solaria.sol.net (Joe Greco), msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-reply-to: Your message of "Wed, 29 Jan 1997 19:32:47 MST." <199701300232.TAA20892@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 19:39:13 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Which reminds me... how did Picard and Worf's magnetic boots stick to > the Entrprise's Titanium hull? Presumably in the same way that their knees stuck to it when they were pressing the buttons ! -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Jan 30 15:40:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10796 for hackers-outgoing; Thu, 30 Jan 1997 15:40:26 -0800 (PST) Received: from smtp.connectnet.com (smtp.connectnet.com [207.110.0.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10761; Thu, 30 Jan 1997 15:40:16 -0800 (PST) Received: from wink.connectnet.com (wink.connectnet.com [206.251.156.23]) by smtp.connectnet.com (8.8.4/Connectnet-2.2) with SMTP id PAA18857; Thu, 30 Jan 1997 15:41:00 -0800 (PST) Message-Id: <199701302341.PAA18857@smtp.connectnet.com> From: "That Doug Guy" To: "freebsd-hackers@freebsd.org" Cc: "freebsd-isp@freebsd.org" Date: Thu, 30 Jan 97 15:40:11 -0800 Reply-To: "That Doug Guy" Priority: Normal X-Mailer: That Doug Guy's Registered PMMail 1.53 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: 2.2+ and sequence number guessing Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Cross-posted to security and questions twice over a period of 4 days, but never got a response. Please accept my apologies in advance if you feel that either of *these* lists is inappropriate for these questions, but I do need answers. Feel free to trim responses to the most appropriate group, I am subscribed to both.] Howdy, :) I have been doing some research on the security of various *nix's, and found some very interesting discussion in the mail archives regarding the security of freebsd vs. a sequence number guessing IP spoof attack. Without rehashing what seemed to be a rather heated discussion last spring, I am wondering if someone could fill me in on any changes, improvements, etc. that have been made in 2.2 regarding this problem. Also, if someone could highlight the changes regarding security against syn flooding promised in 2.2, it would help. Of course, if this information is already available on line, a pointer to it would be appreciated. And speaking of security, I am looking for information on the relative usefulness and efficiency of tcp wrappers vs. Darren Reed's IP filtering. I've read all I can find on both (including downloading the IP filter package), and I'm still a bit confused about how much overhead either will add to my system. It looks like I'll be going with Darren's stuff because I need to filter access to ircd, and as far as I can tell the wrappers won't hook it. Any information or pointers to more detailed documentation would be appreciated. Thank you, Doug From owner-freebsd-hackers Thu Jan 30 15:46:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA11160 for hackers-outgoing; Thu, 30 Jan 1997 15:46:15 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA11152 for ; Thu, 30 Jan 1997 15:46:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA00636; Thu, 30 Jan 1997 16:45:10 -0700 From: Terry Lambert Message-Id: <199701302345.QAA00636@phaeton.artisoft.com> Subject: Re: Using rfork() / threads To: cracauer@wavehh.hanse.de Date: Thu, 30 Jan 1997 16:45:10 -0700 (MST) Cc: rminnich@Sarnoff.COM, freebsd-hackers@FreeBSD.ORG In-Reply-To: <9701301753.AA23376@wavehh.hanse.de> from "Martin Cracauer" at Jan 30, 97 06:53:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >VM space handling is a little different. If you request VM space sharing, > >you don't exactly get Vm address space sharing: what you get is instead > >shared data areas where in normal fork they are copied. More details on > >request. The effect is what you want, though: shared data areas. > > Could you explain a bit more. What exactly is the difference between > VM space sharing and shared data areas from the process' and the > kernel perspective? The per process open file table points to the same location, for one (that's actually a biggie). If I open a file in one process, it is open for both processes. If I close it, it's closed. There is one fd offset associated with the object -- if one process writes it, the offset is advanced, and if the other writes it, it's advanced again. There is a potential race as to who gets to do the write. Etc. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Jan 30 15:53:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA12115 for hackers-outgoing; Thu, 30 Jan 1997 15:53:55 -0800 (PST) Received: from freenet.hamilton.on.ca (0@main.freenet.hamilton.on.ca [199.212.94.65]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA12107 for ; Thu, 30 Jan 1997 15:53:52 -0800 (PST) From: hoek@freenet.hamilton.on.ca Received: from james.freenet.hamilton.on.ca (james.freenet.hamilton.on.ca [199.212.94.66]) by freenet.hamilton.on.ca (8.7.5/8.7.3) with ESMTP id SAA01474; Thu, 30 Jan 1997 18:54:08 -0500 (EST) Received: (from ac199@localhost) by james.freenet.hamilton.on.ca (8.7.5/8.7.3) id SAA27772; Thu, 30 Jan 1997 18:56:04 -0500 (EST) Date: Thu, 30 Jan 1997 18:56:04 -0500 (EST) Message-Id: <199701302356.SAA27772@james.freenet.hamilton.on.ca> X-Mailer: slnr v.2.13 as ported to FreeBSD To: terry@lambert.org cc: hackers@freebsd.org, mcgovern@spoon.beta.com (Brian J. McGovern) Subject: Re: Followup to criticism (was: Constructive criticism) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In Email, Terry Lambert wrote: > > Just because I back something up doesn't mean it's negative. > > Though I will admit, I'll get down there in the muddy rut with my > riding crop and whack and scream and foam at the mouth... [...] > > Doesn't make me a bad person. Being a good person doesn't make you good company! It merely means that the rest of the world is going to be against you... :-) -- From owner-freebsd-hackers Thu Jan 30 15:54:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA12174 for hackers-outgoing; Thu, 30 Jan 1997 15:54:26 -0800 (PST) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA12165 for ; Thu, 30 Jan 1997 15:54:23 -0800 (PST) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.4/8.7.3) id PAA05111; Thu, 30 Jan 1997 15:53:34 -0800 (PST) Date: Thu, 30 Jan 1997 15:53:34 -0800 (PST) Message-Id: <199701302353.PAA05111@vader.cs.berkeley.edu> To: joerg_wunsch@uriah.heep.sax.de CC: eivind@dimaga.com, hackers@FreeBSD.ORG In-reply-to: Subject: Re: From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * > When was this introduced, and is there any way for me to check if it is * > present? (BSD > xxxx, for instance?) * * #include * * #if __FreeBSD_version >= 199702 * # define NEED_NET_IF_VAR_H * #endif * * That catches some -current systems before the change, but that * shouldn't matter. It doesn't hit 2.2 machines, since they are frozen * to 199701 (even though it's obvious that we won't ship 2.2R by * January). Except this will break when 2.2.5 is released (unless if_var.h is merged into the -2.2 branch, but you get the point). :( Satoshi "did I already tell you I hate parallel development?" Asami From owner-freebsd-hackers Thu Jan 30 16:21:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA15113 for hackers-outgoing; Thu, 30 Jan 1997 16:21:04 -0800 (PST) Received: from skylark.hilink.com.au (skylark.hilink.com.au [203.29.224.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA15093 for ; Thu, 30 Jan 1997 16:20:56 -0800 (PST) Received: from localhost (danny@localhost) by skylark.hilink.com.au (8.8.5/8.6.10) with SMTP id LAA21373; Fri, 31 Jan 1997 11:20:12 +1100 (EST) Date: Fri, 31 Jan 1997 11:20:11 +1100 (EST) From: "Daniel O'Callaghan" To: tiller@connectnet.com cc: hackers@freebsd.org Subject: TCP sequence numbers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The code below is taken from sys/netinet/tcp_seq.h in 2.2-ALPHA. It is not present in 2.1.5. That should indicate that TCP sequence number guessing attacks have been significantly stomped on. More knowledgeable people please correct me. /* * Increment for tcp_iss each second. * This is designed to increment at the standard 250 KB/s, * but with a random component averaging 128 KB. * We also increment tcp_iss by a quarter of this amount * each time we use the value for a new connection. * If defined, the tcp_random18() macro should produce a * number in the range [0-0x3ffff] that is hard to predict. */ #ifndef tcp_random18 #define tcp_random18() ((random() >> 14) & 0x3ffff) #endif #define TCP_ISSINCR (122*1024 + tcp_random18()) extern tcp_seq tcp_iss; /* tcp initial send seq # */ #else #define TCP_ISSINCR (250*1024) /* increment for tcp_iss each second */ #endif /* KERNEL */ #endif /* _NETINET_TCP_SEQ_H_ */ From owner-freebsd-hackers Thu Jan 30 16:57:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA17551 for hackers-outgoing; Thu, 30 Jan 1997 16:57:48 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA17546 for ; Thu, 30 Jan 1997 16:57:45 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id BAA06430; Fri, 31 Jan 1997 01:56:10 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id BAA17861; Fri, 31 Jan 1997 01:57:42 +0100 (MET) Message-Id: <3.0.32.19970131015742.00b1ccf0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 31 Jan 1997 01:57:43 +0100 To: asami@vader.cs.berkeley.edu (Satoshi Asami) From: Eivind Eklund Subject: Re: Cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 03:53 PM 1/30/97 -0800, Satoshi Asami wrote: >>> When was this introduced, and is there any way for me to check if it is >>> present? (BSD > xxxx, for instance?) >> >> #include >> >> #if __FreeBSD_version >= 199702 >> # define NEED_NET_IF_VAR_H >> #endif >> >> That catches some -current systems before the change, but that >> shouldn't matter. It doesn't hit 2.2 machines, since they are frozen >> to 199701 (even though it's obvious that we won't ship 2.2R by >> January). > >Except this will break when 2.2.5 is released (unless if_var.h is >merged into the -2.2 branch, but you get the point). :( Should I add something like .if exists(/usr/bin/net/if_var.h) CFLAGS+= HAS_NET_IF_VAR_H .endif to the Makefile in addition, perhaps? As long as I haven't got a "proper" solution this is the best I can see. (This could be a loop over the include-path instead of a direct test, but I cannot see this gaining much on anything but very obscure systems.) Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Thu Jan 30 17:29:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA19275 for hackers-outgoing; Thu, 30 Jan 1997 17:29:20 -0800 (PST) Received: from nexgen.ampr.org (max2-190.HiWAAY.net [208.147.145.190]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19270 for ; Thu, 30 Jan 1997 17:29:14 -0800 (PST) Received: from nexgen.ampr.org (localhost [127.0.0.1]) by nexgen.ampr.org (8.8.4/8.8.4) with ESMTP id TAA21295; Thu, 30 Jan 1997 19:27:50 -0600 (CST) Message-Id: <199701310127.TAA21295@nexgen.ampr.org> X-Mailer: exmh version 1.6.9 8/22/96 To: Keith Mitchell cc: hackers@freebsd.org From: dkelly@hiwaay.net Subject: Re: lpd - remote printing with an output filter In-reply-to: Message from Keith Mitchell of "Wed, 29 Jan 1997 22:59:33 EST." <199701300359.WAA25499@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 19:25:44 -0600 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Keith Mitchell writes: > > > Has anyone got any problems with me making this work ? It's always > > irritated me ! It consists of two one-liners to printjob.c. > > No, but I would like to see it happen. I have several printers hanging off > a HP JetDirect EX print server and there is no way to run an output filter > on them. Consequently, the user must KNOW not to just blindly print to it. > (sigh). I was looking thru the handbook the other night while setting up my printer. Saw a comment that one way to implement a filter on a remote printer was to make a "virtual" local printer with an "if" or "of" filter of your choice which ultimately pipes the output right back into "lpr -Preal_printer". Doesn't seem so hard? I must be missing something. OTOH, I don't have my Apple LaserWriter NTR working to my satisfaction either. Used the parallel printer port. Job prints perfectly but the printer doesn't know its finished so the lights are still flashing and the Mac can't get in via the LocalTalk port. I'm using a mix of a2ps and lprps. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Thu Jan 30 17:33:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA19486 for hackers-outgoing; Thu, 30 Jan 1997 17:33:17 -0800 (PST) Received: from Clifford.LiveNet.Net (root@Clifford.LiveNet.Net [206.156.5.13]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19481 for ; Thu, 30 Jan 1997 17:33:14 -0800 (PST) Received: from bigdaddy (Tsunami.Stormer.LiveNet.Net [206.156.5.133]) by Clifford.LiveNet.Net (8.7.6/8.6.9) with ESMTP id UAA13811 for ; Thu, 30 Jan 1997 20:38:51 -0500 (EST) Message-Id: <199701310138.UAA13811@Clifford.LiveNet.Net> From: "Joseph" To: Subject: Error Message Date: Thu, 30 Jan 1997 20:31:49 -0500 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-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi I downloaded all of release 2.1.6 into my DOS disk e:\freebsd and I tried to do the DOS partition install but it keeps giving me this error: Error mounting /dev/wd1s2 on /DOS invalid argument 22 I have 3 hard drives and have given one to Freebsd to use excessive c:\ = 1 gig d:\ = 1.35 e:\ = 1.35 where freebds is stored ?:\ = 2.1 gigs I gave to UNIX d: & e: is a 2.7 split down the middle I have all the 2.1.6 files on e: it. looks like it isn't finding the files, I have done the partitions without installing any files and it has worked but told me it wouldn't be able boot on account of no file transferred to the UNIX Drive. I have made the directories 50 megs / 100megs swap 200megs /var 1600 give or take /usr please I need help :-( Thanks Joe From owner-freebsd-hackers Thu Jan 30 17:36:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA19847 for hackers-outgoing; Thu, 30 Jan 1997 17:36:55 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19840 for ; Thu, 30 Jan 1997 17:36:52 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id SAA07253; Thu, 30 Jan 1997 18:36:44 -0700 (MST) Date: Thu, 30 Jan 1997 18:36:44 -0700 (MST) Message-Id: <199701310136.SAA07253@rocky.mt.sri.com> From: Nate Williams To: Jaye Mathisen Cc: hackers@freebsd.org Subject: Re: $confusion == CVSUP + Jaye_Mathisen In-Reply-To: References: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Reboot, and voila', I still have old gook there. Like sendmail 8.8.4, > which I could've sworn was updated to 8.8.5 in 2.2 several days ago. Nope, it hasn't been tagged into 2.2 > I regularly have an unbuildable /usr/src, and just renaming /usr/src to > /usr/src.bak and re-cvsupping gets me a usable tree. > > Is it just me? Is there something obviously wrong with my procedure here? Are you sure the build completely successfully? Sometimes it blows off in the middle of building/installing something, and anything in the build tree after that point isn't built/installed. Nate From owner-freebsd-hackers Thu Jan 30 17:44:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA20277 for hackers-outgoing; Thu, 30 Jan 1997 17:44:02 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA20257 for ; Thu, 30 Jan 1997 17:43:56 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id RAA06454; Thu, 30 Jan 1997 17:40:21 -0800 (PST) Message-ID: <32F14D23.1CFBAE39@whistle.com> Date: Thu, 30 Jan 1997 17:38:43 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Joerg Wunsch CC: FreeBSD hackers , "Brian J. McGovern" Subject: Re: Device Drivers 101 References: <199701300505.AAA09649@spoon.beta.com> <199701300601.QAA27658@genesis.atrad.adelaide.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Michael Smith wrote: > > > Devfs doesn't really 'do' major and minor numbers; there's a logically > > direct translation from the named node to your switch entry and the > > unit number you supply when you create the node. > > Though, it's a very good idea to leave the major number assignment to > devfs. The existing drivers don't do this yet, but i think once devfs > is really up for the masses, we should walk through the tree and avoid > hard allocations wherever possible. (I.e., almost everything except > those devices the bootstrap code has builtin knowlege about.) > > I think you can achieve automatic major number assignment by passing > -1 down to devfs. Julian might comment on this. No you pass -1 to cdevsw_add amd bdevsw_add then see what they allocated you and pass that to devfs when you set up the devices in devfs. > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Jan 30 17:45:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA20377 for hackers-outgoing; Thu, 30 Jan 1997 17:45:07 -0800 (PST) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA20369 for ; Thu, 30 Jan 1997 17:45:02 -0800 (PST) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.7.5/8.7.3) with ESMTP id UAA04356 for ; Thu, 30 Jan 1997 20:44:28 -0500 (EST) Message-Id: <199701310144.UAA04356@spooky.rwwa.com> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-hackers@freebsd.org Subject: Re: glibc-2.0 (aka libc-6) - new, experimental version of C library (fwd) In-reply-to: Your message of "Fri, 31 Jan 1997 03:04:42 +1100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 20:44:28 -0500 From: Robert Withrow Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk richard@deep-thought.org said: > * The new auxiliary library `-lutil' from 4.4 BSD contains various > functions for maintaining the login-record files (primarily of use to > system programs such as `login'), and convenient functions for > allocating and initializing a pseudo-terminal (pty) device. Out of curiosity, does this library now have a more restrictive copyright (i.e. gpv) than it did when it came from 4.4 BSD? ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM From owner-freebsd-hackers Thu Jan 30 17:46:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA20487 for hackers-outgoing; Thu, 30 Jan 1997 17:46:51 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA20471 for ; Thu, 30 Jan 1997 17:46:47 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id CAA06962; Fri, 31 Jan 1997 02:45:22 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id CAA18583; Fri, 31 Jan 1997 02:46:54 +0100 (MET) Message-Id: <3.0.32.19970131024654.00942e70@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 31 Jan 1997 02:46:56 +0100 To: "Brian Somers" From: Eivind Eklund Subject: Re: PR2347 - recursive malloc() in ppp Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 10:02 AM 1/30/97 -0000, Brian Somers wrote: >I'm not sure what your problem might have been, but lots of changes have >been done to ppp since then. You can pick up the current sources from >ftp://ftp.freebsd.org:/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ppp if you >want to have a look at the "current" version, but I don't think it'll >compile on 2.1*. With minor patches, it will. Replace the #include with +#include +#if ___FreeBSD_version >= 199702 #include +#endif this might break under 2.2.5R, though. (Will work under 2.1.6, 2.2 and -current as of today) BTW: Who is the right person to submit patches for PPP to? Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-hackers Thu Jan 30 17:54:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA20916 for hackers-outgoing; Thu, 30 Jan 1997 17:54:59 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA20910 for ; Thu, 30 Jan 1997 17:54:56 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA04589; Fri, 31 Jan 1997 12:24:02 +1030 (CST) From: Michael Smith Message-Id: <199701310154.MAA04589@genesis.atrad.adelaide.edu.au> Subject: Re: Mail digestion In-Reply-To: <199701301704.KAA22180@phaeton.artisoft.com> from Terry Lambert at "Jan 30, 97 10:04:42 am" To: terry@lambert.org (Terry Lambert) Date: Fri, 31 Jan 1997 12:24:00 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > Elm appears to have just eaten all my outstanding mail (some 200+ items). > > > > If you were expecting a response from me on something, you'll need to > > send it again. 8( > > Describe the event. It may be in your "received" folder (to access, > "elm -f =received"). It may be that your tmp got full on the save, > or some other event occured, where it ran out of space and bailed. > Typically, this will leave a file in /tmp or /usr/tmp, etc., which > you can recover by catting it onto your mail file. I've been using elm for probably close to a decade now, so I think I have a reasonable idea of its failure modes 8) The 'event' was the key sequence 'd$' : delete message, update folder, swap virtual (fvwm) screen. When I returned to the screen with elm (running in an xterm over a slow ssh session), I had no messages in my inbox. /var/mail/msmith and /tmp/mbox.msmith were both size zero. The last message in my received folder is dated november. There's no NFS in the picture anywhere; all I can think of is a race between elm and mail.local in locking the mailbox. 8( > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Jan 30 17:57:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA21059 for hackers-outgoing; Thu, 30 Jan 1997 17:57:55 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA21054 for ; Thu, 30 Jan 1997 17:57:53 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id RAA02652; Thu, 30 Jan 1997 17:57:16 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma002650; Thu Jan 30 17:56:50 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id RAA00251; Thu, 30 Jan 1997 17:56:49 -0800 (PST) From: Archie Cobbs Message-Id: <199701310156.RAA00251@bubba.whistle.com> Subject: Re: ipdivert & masqd In-Reply-To: <199701301057.KAA00746@ui-gate.utell.co.uk> from Brian Somers at "Jan 30, 97 10:53:04 am" To: brian@utell.co.uk (Brian Somers) Date: Thu, 30 Jan 1997 17:56:49 -0800 (PST) Cc: archie@whistle.com, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@FreeBSD.org, cmott@srv.net, brian@awfulhak.demon.co.uk X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > I've essentially got the following: > > > > > > ---------------- ---------------------- > > > | 10.0.10.2 |------------------| 10.0.10.1 | > > > ---------------- | | > > > | 10.0.1.254 (ed0) | > > > ---------------------- > > > | > > > | > > > ----------------- | > > > | 10.0.1.1 |--------------------------- > > > ----------------- > > > > > > with a mask of ffffff00 everywhere and the machine in the middle using > > > the following: > > > > > > ipfw add 100 divert 6668 all from any to any via ed0 > > > > A-HAH! :-) > > > > Could you try the following patch? > > > > Thanks, > > - -Archie > > > > [.....] > > I tried it, and I'm a bit confused about the results ! It > allows connections in both directions between 10.0.1.1 and > 10.0.1.254, but sending a packet from 10.0.10.2 to 10.0.1.1 > goes to 10.0.10.1, gets aliased as 10.0.1.254->10.0.1.1, > gets accepted and replied to by 10.0.1.1 and gets changed > from 10.0.1.1->10.0.1.254 to 10.0.1.1->10.0.10.3 by the > PacketAlias stuff and then disappears. I the 10.0.10.3 is a typo.. > Maybe the problem is with the forwarding code - where ip_input() > calls ip_output(). I didn't realize this happened ! Surely, we > should be remembering and zero'ing ip_divert_ignore before > calling ip_output here, and restoring it afterwards. I'll check this > when I get home this evening ! Yes, ip_input() calls ip_output() indirectly when forwarding packets. You actually want to *not* zero ip_divert_ignore in this case in order to realize the intended semantics of the socket -- the loop avoidance is supposed to avoid all diversion back to the port, even if the packet passes through ipfw twice, on the way "in" and on the way "out". -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Jan 30 18:01:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA21226 for hackers-outgoing; Thu, 30 Jan 1997 18:01:03 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA21213 for ; Thu, 30 Jan 1997 18:00:59 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id UAA00273; Thu, 30 Jan 1997 20:59:30 -0500 (EST) Message-Id: <199701310159.UAA00273@spoon.beta.com> To: hoek@freenet.hamilton.on.ca cc: terry@lambert.org, hackers@freebsd.org, mcgovern@spoon.beta.com (Brian J. McGovern), mcgovern@spoon.beta.com Subject: Re: Followup to criticism (was: Constructive criticism) In-reply-to: Your message of "Thu, 30 Jan 1997 18:56:04 EST." <199701302356.SAA27772@james.freenet.hamilton.on.ca> Date: Thu, 30 Jan 1997 20:59:30 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry, I don't want you to think that I was trying to be mean with that comment :) Just that in the past, I think I've seen myself on the other side of a number of issues in the past, and our thought-alignment caused me to do a parity check on the grey matter :) -Brian From owner-freebsd-hackers Thu Jan 30 18:02:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA21277 for hackers-outgoing; Thu, 30 Jan 1997 18:02:20 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA21272 for ; Thu, 30 Jan 1997 18:02:17 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA02696; Thu, 30 Jan 1997 18:01:46 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma002692; Thu Jan 30 18:01:25 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id SAA00278; Thu, 30 Jan 1997 18:01:25 -0800 (PST) From: Archie Cobbs Message-Id: <199701310201.SAA00278@bubba.whistle.com> Subject: Re: Using rfork() / threads In-Reply-To: <199701302345.QAA00636@phaeton.artisoft.com> from Terry Lambert at "Jan 30, 97 04:45:10 pm" To: terry@lambert.org (Terry Lambert) Date: Thu, 30 Jan 1997 18:01:25 -0800 (PST) Cc: cracauer@wavehh.hanse.de, rminnich@Sarnoff.COM, freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >VM space handling is a little different. If you request VM space sharing, > > >you don't exactly get Vm address space sharing: what you get is instead > > >shared data areas where in normal fork they are copied. More details on > > >request. The effect is what you want, though: shared data areas. > > > > Could you explain a bit more. What exactly is the difference between > > VM space sharing and shared data areas from the process' and the > > kernel perspective? > > The per process open file table points to the same location, for one > (that's actually a biggie). If I open a file in one process, it is > open for both processes. If I close it, it's closed. There is one > fd offset associated with the object -- if one process writes it, > the offset is advanced, and if the other writes it, it's advanced > again. There is a potential race as to who gets to do the write. What about the heap... is it shared? What about shared libraries? I assume stack regions are not shared... -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Jan 30 18:33:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA23686 for hackers-outgoing; Thu, 30 Jan 1997 18:33:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA23678 for ; Thu, 30 Jan 1997 18:33:02 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA01148; Thu, 30 Jan 1997 19:30:42 -0700 From: Terry Lambert Message-Id: <199701310230.TAA01148@phaeton.artisoft.com> Subject: Re: Followup to criticism (was: Constructive criticism) To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Thu, 30 Jan 1997 19:30:42 -0700 (MST) Cc: hoek@freenet.hamilton.on.ca, terry@lambert.org, hackers@freebsd.org, mcgovern@spoon.beta.com In-Reply-To: <199701310159.UAA00273@spoon.beta.com> from "Brian J. McGovern" at Jan 30, 97 08:59:30 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I don't want you to think that I was trying to be mean with that > comment :) Just that in the past, I think I've seen myself on the other > side of a number of issues in the past, and our thought-alignment caused > me to do a parity check on the grey matter :) Heh. Glad you passed. But it still means I fail your parity check on occasion. 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 Jan 30 18:34:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA23852 for hackers-outgoing; Thu, 30 Jan 1997 18:34:13 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA23840 for ; Thu, 30 Jan 1997 18:34:10 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id CAA03194; Fri, 31 Jan 1997 02:33:22 GMT Date: Fri, 31 Jan 1997 11:33:22 +0900 (JST) From: Michael Hancock To: Martin Cracauer cc: rminnich@Sarnoff.COM, freebsd-hackers@FreeBSD.ORG Subject: Re: Using rfork() / threads In-Reply-To: <9701301753.AA23376@wavehh.hanse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Martin Cracauer wrote: > rminnich@Sarnoff.COM (Ron G. Minnich) wrote: > > [rfork] > > >VM space handling is a little different. If you request VM space sharing, > >you don't exactly get Vm address space sharing: what you get is instead > >shared data areas where in normal fork they are copied. More details on > >request. The effect is what you want, though: shared data areas. > > Could you explain a bit more. What exactly is the difference between > VM space sharing and shared data areas from the process' and the > kernel perspective? In fork the mappings are copied and the data is marked copied on write. In the original vfork you just inherited the mappings (Vm address space sharing). In rfork the mappings are copied but the data is not marked copy on write. I haven't analyzed rfork so someone might correct me but this makes sense to me. Regards, Mike From owner-freebsd-hackers Thu Jan 30 18:51:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25079 for hackers-outgoing; Thu, 30 Jan 1997 18:51:52 -0800 (PST) Received: from localhost (ppp2218.on.sympatico.ca [206.172.244.106]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA25070 for ; Thu, 30 Jan 1997 18:51:47 -0800 (PST) Received: (from gardner@localhost) by localhost (8.6.12/8.6.12) id VAA00282; Thu, 30 Jan 1997 21:50:51 -0500 Date: Thu, 30 Jan 1997 21:50:51 -0500 From: Gardner Buchanan Message-Id: <199701310250.VAA00282@localhost> To: dufault@hda.com, hackers@freebsd.org Subject: Re: PC/104 network computer Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: Peter Dufault > Date: Wed, 29 Jan 1997 07:32:45 -0500 (EST) > Subject: PC/104 network computer > > (I tried hardware. Anyone on -hackers using a PC/104 single board > computer?) > > I'm looking for a single board PC/104 computer with ethernet, flash > memory, memory, serial ports, and parallel port on a single card. > For ease in bootstrapping it should also have a keyboard and floppy > interface. I also need a good looking small enclosure with power > supply and external connectors. I'm not concerned with screaming > performance or more than 16MB memory. > > The kind of board I have in mind is similar to the Megatel PC/II+i: > > http://www.emji.net:80/megatel/pc2ispec.html > > Can anyone recommend others? > I ran FreeBSD 2.0.5 and 2.1 on an Ampro Littleboard. I had to write my own Ethernet driver for the SMC 91C92 chip. The Datalux "databrick" systems (sorry, you'll have to use Yahoo or whatever) look quite nice. They aren't PC/104 though. They do also use the SMC 91C92. My driver for it is on www.smc.com. ============================================ Gardner Buchanan Ottawa, ON From owner-freebsd-hackers Thu Jan 30 19:00:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA25638 for hackers-outgoing; Thu, 30 Jan 1997 19:00:49 -0800 (PST) Received: from marvin (root@marvin.mmedia.com [199.240.226.118]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA25623 for ; Thu, 30 Jan 1997 19:00:44 -0800 (PST) Received: (from joed@localhost) by marvin (8.8.4/8.8.2) id VAA01115; Thu, 30 Jan 1997 21:00:22 -0600 (CST) Message-ID: Date: Thu, 30 Jan 1997 20:59:20 -0600 From: joed@ksu.edu (Joe Diehl) To: thomas@ghpc8.ihf.rwth-aachen.de (Thomas Gellekum) Cc: freebsd-hackers@freebsd.org Subject: Re: 2.2-BETA Questions References: <199701280843.JAA03366@ghpc6.ihf.rwth-aachen.de> X-Mailer: Mutt 0.55 Mime-Version: 1.0 In-Reply-To: <199701280843.JAA03366@ghpc6.ihf.rwth-aachen.de>; from Thomas Gellekum on Jan 28, 1997 09:43:39 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thomas Gellekum writes: > Simon Shapiro wrote: > [Charset iso-8859-8 unsupported, filtering to ASCII...] > > What is the kernel config option for CD audio support? > > There's nothing special. Could you post the lines from the probe > messages (see dmesg(8))? xmcd works fine with a Hitachi drive I have > here (CDR-7930, ATAPI, in case someone's interested; xmcd linked with > lesstif-0.75a). > As a note, not all ATAPI drives have functioning audio. The NEC CDR260 (2x ide toy that gateway was shipping with their p5-60s) works most of the time in data (locks the machine on occasion) but audio flat out fails. joed@marvin:~% cdcontrol -f /dev/wcd0c Compact Disc Control utility, version 2.0 Type `?' for command list cdcontrol> play cdcontrol: Input/output error cdcontrol> info Starting track = 1, ending track = 14, TOC size = 122 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 4:13.25 0 18850 audio 170 72:12.74 - 324824 - - I can eject and the whole bit.. just can't play.. *shrug* --- Joe Diehl PGP Key: finger joed@unix.ksu.edu From owner-freebsd-hackers Thu Jan 30 19:02:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA25772 for hackers-outgoing; Thu, 30 Jan 1997 19:02:17 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA25762 for ; Thu, 30 Jan 1997 19:02:06 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id XAA20718; Thu, 30 Jan 1997 23:42:32 GMT Message-Id: <199701302342.XAA20718@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: dk+@ua.net, shocking@mailbox.uq.edu.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Setting MTU from userland ppp In-reply-to: Your message of "Thu, 30 Jan 1997 09:55:15 MST." <199701301655.JAA22139@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 23:42:32 +0000 From: Brian Somers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > set mtu 576 > > > > in /etc/ppp/ppp.conf > > > > works for me. > > > > This would specify your _tranimission_ size. To change it on the other > > side, change the other end's setup. > > > > Don't use 256 as your MTU. (violates the RFC) > > Any chance of having the software *enforce* the RFC, then? I'll have a look at the RFC. It currently checks that 100 <= M[TR]U <= 2000. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Jan 30 19:05:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA25965 for hackers-outgoing; Thu, 30 Jan 1997 19:05:47 -0800 (PST) Received: from eldorado.net-tel.co.uk ([193.122.171.253]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA25957 for ; Thu, 30 Jan 1997 19:05:40 -0800 (PST) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id DAA19743; Fri, 31 Jan 1997 03:04:29 GMT Received: from "/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/" by net-tel.co.uk (Route400-RFCGate); Fri, 31 Jan 97 3:01:20 +0000 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 31 Jan 97 3:01:20 +0000 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 31 Jan 97 3:01:18 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Fri, 31 Jan 97 3:01:17 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:8035-970131030117-6E3C] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Fri, 31 Jan 97 3:01:17 +0000 X400-Content-Identifier: Re(2): Using rfo Message-Id: <"40b1-970131030103-8AD9*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: rminnich@Sarnoff.COM Cc: freebsd-hackers@freebsd.org In-Reply-To: Subject: Re(2): Using rfork() / threads Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > VM space handling is a little different. If you request VM space sharing, > you don't exactly get Vm address space sharing: what you get is instead > shared data areas where in normal fork they are copied. More details on > request. The effect is what you want, though: shared data areas. What synchronization primitives are you supposed to use between two rfork()ed processes? Using SysV sepmaphores seems a bit perverse (and would they even work in the environment after a rfork() ?), but talking through pairs of sockets to lock small datastructures seems a bit heavyweight. From owner-freebsd-hackers Thu Jan 30 19:06:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA26031 for hackers-outgoing; Thu, 30 Jan 1997 19:06:35 -0800 (PST) Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA26000 for ; Thu, 30 Jan 1997 19:06:24 -0800 (PST) Received: from bogus.mindspring.com (borg.mindspring.com [204.180.128.14]) by mule0.mindspring.com (8.8.4/8.8.4) with SMTP id WAA56368 for ; Thu, 30 Jan 1997 22:06:21 -0500 Message-Id: <1.5.4.32.19970131030617.00922bc8@mindspring.com> X-Sender: kpneal@mindspring.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Jan 1997 22:06:17 -0500 To: hackers@freebsd.org From: "Kevin P. Neal" Subject: Re: Source code commits Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 01:26 AM 1/30/97 -0700, Nate Williams wrote: >> I suggested a sort of "write-through" validation/submission system for >> the CVS tree a year ago, where anyone could "commit" to the source >> tree but for those people who weren't actually authorized to commit >> directly, what would happen instead is that the diffs would be >> automagically sent to the person or persons actually responsible for >> the code in question, and they would review and optionally commit it. > >Aieee, why go for trivial solutions when we can do something much more >useful (and difficult). > >I think it would be easier to rewrite CVS from scratch. :) Starting with RCS. A nice library with a well defined interface. Then CVS can be put on top of that. This is actually on my todo list. Above it, however, is getting a stable machine to do the coding on. -- XCOMM Kevin P. Neal, Junior, Comp. Sci. - kpneal@pobox.com XCOMM House of Retrocomputing: - kpneal@eos.ncsu.edu XCOMM http://www.pobox.com/~kpn/ - kevinneal@bix.com XCOMM "Rebooting with command:" -- SPARCstation 10 boot prom From owner-freebsd-hackers Thu Jan 30 19:35:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27087 for hackers-outgoing; Thu, 30 Jan 1997 19:35:18 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA27081 for ; Thu, 30 Jan 1997 19:35:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA01399; Thu, 30 Jan 1997 20:34:09 -0700 From: Terry Lambert Message-Id: <199701310334.UAA01399@phaeton.artisoft.com> Subject: Re: Using rfork() / threads To: archie@whistle.com (Archie Cobbs) Date: Thu, 30 Jan 1997 20:34:09 -0700 (MST) Cc: terry@lambert.org, cracauer@wavehh.hanse.de, rminnich@Sarnoff.COM, freebsd-hackers@freebsd.org In-Reply-To: <199701310201.SAA00278@bubba.whistle.com> from "Archie Cobbs" at Jan 30, 97 06:01:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The per process open file table points to the same location, for one > > (that's actually a biggie). If I open a file in one process, it is > > open for both processes. If I close it, it's closed. There is one > > fd offset associated with the object -- if one process writes it, > > the offset is advanced, and if the other writes it, it's advanced > > again. There is a potential race as to who gets to do the write. > > What about the heap... is it shared? What about shared libraries? > I assume stack regions are not shared... Stack is not shared. I believe mmap'ed memory regions remain shared. I believe heap data is shared, including libs... if this isn't true, then we don't need libc_r for a kernel threads environment. But it would also mean that context sharing needs to use data in shared memory (making heap process ["thread"] local to each process). If this is true, then sfork() is like Sequent's vfork(). I thought that it wasn't true, though, and that's why the call name was changed. I really haven't played with sfork() much, recently... you should contact the author. 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 Jan 30 19:39:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27494 for hackers-outgoing; Thu, 30 Jan 1997 19:39:13 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA27489 for ; Thu, 30 Jan 1997 19:39:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA01418; Thu, 30 Jan 1997 20:37:34 -0700 From: Terry Lambert Message-Id: <199701310337.UAA01418@phaeton.artisoft.com> Subject: Re: Re(2): Using rfork() / threads To: Andrew.Gordon@net-tel.co.uk Date: Thu, 30 Jan 1997 20:37:34 -0700 (MST) Cc: rminnich@Sarnoff.COM, freebsd-hackers@FreeBSD.org In-Reply-To: <"40b1-970131030103-8AD9*/G=Andrew/S=Gordon/O=NET-TEL Computer from "Andrew.Gordon@net-tel.co.uk" at Jan 31, 97 03:01:17 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > VM space handling is a little different. If you request VM space sharing, > > you don't exactly get Vm address space sharing: what you get is instead > > shared data areas where in normal fork they are copied. More details on > > request. The effect is what you want, though: shared data areas. > > What synchronization primitives are you supposed to use between two > rfork()ed processes? Using SysV sepmaphores seems a bit perverse > (and would they even work in the environment after a rfork() ?), > but talking through pairs of sockets to lock small datastructures > seems a bit heavyweight. You use processor test-and-set (CMPTST) on a shared region. If you want SMP cache coherency for the same situation, you write a kernel module that uses IPI invalidation queueing. Time for a set of mutex libraries that are SMP aware? It would be easier in elf so you could constructorize the mutex initialization to decide whether or not to make kernel or non-kernel calls at load 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 Thu Jan 30 19:47:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27949 for hackers-outgoing; Thu, 30 Jan 1997 19:47:20 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA27930; Thu, 30 Jan 1997 19:47:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id TAA27603; Thu, 30 Jan 1997 19:46:37 -0800 (PST) Message-Id: <199701310346.TAA27603@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "That Doug Guy" cc: "freebsd-hackers@freebsd.org" , "freebsd-isp@freebsd.org" Subject: Re: 2.2+ and sequence number guessing In-reply-to: Your message of "Thu, 30 Jan 1997 15:40:11 PST." <199701302341.PAA18857@smtp.connectnet.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 30 Jan 1997 19:46:37 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I have been doing some research on the security of various *nix's, >and found some very interesting discussion in the mail archives regarding >the security of freebsd vs. a sequence number guessing IP spoof attack. >Without rehashing what seemed to be a rather heated discussion last spring, >I am wondering if someone could fill me in on any changes, improvements, >etc. that have been made in 2.2 regarding this problem. Also, if someone >could highlight the changes regarding security against syn flooding >promised in 2.2, it would help. Of course, if this information is already >available on line, a pointer to it would be appreciated. There were changes made that made the initial sequence number more random. See rev 1.29 of tcp_input.c. The random drop syn-flood protection was implemented. See rev 1.52 of tcp_input.c. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Jan 30 20:38:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA00539 for hackers-outgoing; Thu, 30 Jan 1997 20:38:04 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA00532 for ; Thu, 30 Jan 1997 20:37:59 -0800 (PST) Message-Id: <199701310437.UAA00532@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA131285434; Fri, 31 Jan 1997 15:37:14 +1100 From: Darren Reed Subject: Re: Transparent proxies (was Re: ipdivert & masqd) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Fri, 31 Jan 1997 15:37:14 +1100 (EDT) Cc: eivind@dimaga.com, imp@village.org, hackers@FreeBSD.ORG In-Reply-To: from "Daniel O'Callaghan" at Jan 31, 97 08:55:35 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Daniel O'Callaghan, sie said: > On Thu, 30 Jan 1997, Eivind Eklund wrote: > > At 08:04 AM 1/30/97 -0700, you wrote: > > I'm thinking about doing transparent proxying for the protocols, but I want > > to see how well the packet-patching version run first. As it is, it is > > (hopefully) right in 99% of the cases, and it scales well. If I get > > reports of real-life problems I'll make it a priority to make proxies, but > > not before. > > Here's a problem which requires transparent proxies for a data stream, > not packet-patching: Transparent capture of all HTTP requests on port 80 > and diversion to a www-proxy server. > > e.g. > > Client Sends "NAT" WWW-Proxy receives > 10.2.3.4 10.2.3.1 10.2.3.55 > > 10.2.3.4-> 5.6.7.8:80 ================> 10.2.3.1->10.2.3.55 > GET / HTTP/1.0 GET http://5.6.7.8:80/ HTTP/1.0 > > Darren Reed's ipfilter does this with the 'redirect' keyword and some > trickery in the receiving process. The example given is for the ftwk's > ftp-gw program (from ftp.tis.com). The userland process finds its true > destination by calling an IOCTL for the kernel NAT code. To give you some idea of "what happens": rule example: rdr ed0 any port ftp -> localhost port ftp (redirect all incoming packets going to port ftp, even if they're not for this host, to 127.0.0.1, port ftp) in inetd.conf of your freebsd gateway, you'd have: ftp stream nowait root ... /usr/local/bin/tpftpd tpftpd (tpftpd is a transparent proxy enabled ftpd). On a user's workstation, the route to X points through the freebsd gateway so they enter: % ftp X IPFilter sees the ftp packet, maps its destination to the localhost, thus inetd detects a connection, fires off tpftpd. The user doing "ftp X" sees "Connection Established". tpftpd starts up, does a lookup on the source of the connection, gets the real remote destination, initiates a connection to X. When the connection is established, it then acts like a tcp-relay, forwarding data backward and forward between the endpoints, having no trouble handling the "PORT" commands. The user doing "ftp X" has no idea of the "middle man" unless tpftpd sends its own messages when the connection is initiated. There are patches available for all the Firewall Toolkit proxies to enable this behaviour. ftp is usually the best example, using it with HTTP so that users don't need to manually configure web browsers for proxies is another. Darren From owner-freebsd-hackers Thu Jan 30 20:46:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA01004 for hackers-outgoing; Thu, 30 Jan 1997 20:46:17 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA00999 for ; Thu, 30 Jan 1997 20:46:13 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id EAA04600; Fri, 31 Jan 1997 04:45:57 GMT Date: Fri, 31 Jan 1997 13:45:57 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Archie Cobbs , cracauer@wavehh.hanse.de, freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads In-Reply-To: <199701310334.UAA01399@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Terry Lambert wrote: > > > The per process open file table points to the same location, for one > > > (that's actually a biggie). If I open a file in one process, it is > > > open for both processes. If I close it, it's closed. There is one > > > fd offset associated with the object -- if one process writes it, > > > the offset is advanced, and if the other writes it, it's advanced > > > again. There is a potential race as to who gets to do the write. > > > > What about the heap... is it shared? What about shared libraries? > > I assume stack regions are not shared... > > Stack is not shared. I believe mmap'ed memory regions remain shared. > I believe heap data is shared, including libs... if this isn't true, > then we don't need libc_r for a kernel threads environment. But it > would also mean that context sharing needs to use data in shared > memory (making heap process ["thread"] local to each process). If > this is true, then sfork() is like Sequent's vfork(). I thought > that it wasn't true, though, and that's why the call name was changed. > > I really haven't played with sfork() much, recently... you should > contact the author. Or look at the man pages and source. man rfork See /usr/src/sys/kern/kern_fork.c and /usr/include/sys/unistd.h. Regards, Mike Hancock From owner-freebsd-hackers Thu Jan 30 21:38:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA03111 for hackers-outgoing; Thu, 30 Jan 1997 21:38:46 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA03105 for ; Thu, 30 Jan 1997 21:38:42 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id QAA06964; Fri, 31 Jan 1997 16:08:32 +1030 (CST) From: Michael Smith Message-Id: <199701310538.QAA06964@genesis.atrad.adelaide.edu.au> Subject: Re: Jukka Ukkonen: POSIX.4 - scheduler once more (as you requested) In-Reply-To: <14120.854650859@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 30, 97 11:00:59 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 31 Jan 1997 16:08:31 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > Any interest in this? I'd like a few more reviewers, if possible. It looks pretty good; perhaps a hair light on design detail. I need to grab my POSIX.4 book again. We could really use this stuff, but I can hardly commit to a date 8( I'll certainly wring its neck once I get a chance... > This time the attached version of my POSIX-sched package is > the most recent version. (I have removed the earlier test > versions from my hard disk to avoid any more surprises with > them.) The manual pages are still missing though as they were > about a month ago when we last discussed this extension. Manpages would be very nice, yes 8) > / Jukka A. Ukkonen, Internet and New Media / Finnish Telecom Ltd. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Jan 30 21:41:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA03407 for hackers-outgoing; Thu, 30 Jan 1997 21:41:53 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA03399 for ; Thu, 30 Jan 1997 21:41:47 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id VAA03447 for ; Thu, 30 Jan 1997 21:43:02 -0800 (PST) Received: (qmail 15308 invoked by uid 110); 31 Jan 1997 05:41:20 -0000 MBOX-Line: From best-of-security-request@suburbia.net Fri Jan 31 13:05:37 1997 remote from suburbia.net Received: (from list@localhost) by suburbia.net (8.8.4/8.8.4) id NAA12392 for proff@suburbia.net; Fri, 31 Jan 1997 13:05:37 +1100 (EST) Received: (qmail 11856 invoked from network); 31 Jan 1997 01:53:46 -0000 Received: from midway.evtech.com (204.96.163.2) by suburbia.net with SMTP; 31 Jan 1997 01:53:46 -0000 Received: from tahiti.evtech.com (tahiti.evtech.com [192.35.179.19]) by midway.evtech.com (8.7.3/8.6.9) with ESMTP id TAA28451; Thu, 30 Jan 1997 19:52:48 -0600 (CST) Received: from borneo (borneo.evtech.com [192.35.179.29]) by tahiti.evtech.com (8.6.12/8.6.12) with SMTP id TAA07088; Thu, 30 Jan 1997 19:52:46 -0600 Received: from borneo.evtech.com (localhost) by borneo (5.x) id AA07829; Thu, 30 Jan 1997 19:06:04 -0600 Message-Id: <9701310106.AA07829@borneo> To: Terrell Thacker Cc: best-of-security@suburbia.net, travis@evtech.com, bugtraq@fc.net Subject: Re: BoS: Re: Smashing the stack In-Reply-To: Your message of "Wed, 22 Jan 1997 14:12:42 EST." <9701221912.AA23790@mtc.iitri.com> Date: Thu, 30 Jan 1997 19:06:04 -0600 From: Travis Hassloch x231 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <9701221912.AA23790@mtc.iitri.com> you write: > My main question is if all > of these protection modes are available, why are they not being used > effectively in the OSs that exist for the X86 line? Well, I wondered this exact thing, and the reasons I got back usually were: 1) It doesn't fit the memory mapping model. Virtual memory handling is VERY difficult to do right under Unix, and it's very hard to know when you've broken something. Ask the FreeBSD people, they just redesigned theirs not long ago. I looked briefly at the description of the cmap (core map) in a book a while back and I bet most BSD Unixes haven't changed their memory model much from the original Vax-specific stuff. 2) It's SLOW. Reloading a segment register on a 486 in protected mode took a VERY long time. It's probably a lot faster on newer models. (Sorry, don't remember the exact number; I want to say it was 100 cycles). Most Unices on the PC simply set the segment registers to base 0, size 4GB, r/w, and leave it at that the whole time, never incurring the overhead of reloading them. In fact, for all of Intel's fancy x86 call-gate stuff, I believe the Linux people ran some benchmarks and determined the old-fashioned software interrupt (trap) was faster and so nobody even bothers with it. 3) Not many people are qualified to make that kind of a change. Many of the ones who are are too busy :) > If so, what are those OSs? I believe OS/2 uses segment-based protection, but don't quote me on it. > Wouldn't it be nice if you could write off stack smashing > on certain X86 platforms because the OS/processor combination wouldn't > allow it to occur? Yes. It would also be nice if they took advantage of better memory-mapping techniques (like using a single 4MB page to map the non-swappable monolithic kernel image instead of multiple 4K pages) to improve performance by having a smaller TLB footprint, too. It's on my todo list. ;) -- Travis Hassloch | Beware of False Profits | P=NP if (P=0 or N=1) Fools are often sure of themselves, but wise men are full of doubt. From owner-freebsd-hackers Thu Jan 30 21:52:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA03939 for hackers-outgoing; Thu, 30 Jan 1997 21:52:41 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA03934 for ; Thu, 30 Jan 1997 21:52:39 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Fri, 31 Jan 97 06:52 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for freebsd-hackers@FreeBSD.ORG id ; Fri, 31 Jan 97 06:52 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA28758; Fri, 31 Jan 97 03:38:07 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9701310238.AA28758@wavehh.hanse.de> Subject: Re: Using rfork() / threads To: terry@lambert.org (Terry Lambert) Date: Fri, 31 Jan 1997 03:38:06 +0100 (MET) Cc: cracauer@wavehh.hanse.de, rminnich@Sarnoff.COM, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199701302345.QAA00636@phaeton.artisoft.com> from "Terry Lambert" at Jan 30, 97 04:45:10 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > >VM space handling is a little different. If you request VM space sharing, > > >you don't exactly get Vm address space sharing: what you get is instead > > >shared data areas where in normal fork they are copied. More details on > > >request. The effect is what you want, though: shared data areas. > > > > Could you explain a bit more. What exactly is the difference between > > VM space sharing and shared data areas from the process' and the > > kernel perspective? > > The per process open file table points to the same location, for one > (that's actually a biggie). If I open a file in one process, it is > open for both processes. If I close it, it's closed. There is one > fd offset associated with the object -- if one process writes it, > the offset is advanced, and if the other writes it, it's advanced > again. There is a potential race as to who gets to do the write. Sure, so much is clear. But the original comment quoted topmost sounded like there are two sperate concepts called "VM address speace sharing" and "shared data areas", which is the same thing for me. Maybe one the these terms implies that one of them has resources like the descriptor table on board and the other not, but then I never heard of this term usage. Hence my question. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://cracauer.cons.org Fax +49 40 522 85 36 From owner-freebsd-hackers Thu Jan 30 22:02:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA04339 for hackers-outgoing; Thu, 30 Jan 1997 22:02:41 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA04334 for ; Thu, 30 Jan 1997 22:02:38 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id WAA03774 for ; Thu, 30 Jan 1997 22:03:50 -0800 (PST) Received: (qmail 15591 invoked by uid 110); 31 Jan 1997 06:02:07 -0000 Message-ID: <19970131060207.15590.qmail@suburbia.net> Subject: Re: TCP sequence numbers In-Reply-To: from Daniel O'Callaghan at "Jan 31, 97 11:20:11 am" To: danny@hilink.com.au (Daniel O'Callaghan) Date: Fri, 31 Jan 1997 17:02:06 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The code below is taken from sys/netinet/tcp_seq.h in 2.2-ALPHA. It is > not present in 2.1.5. > > That should indicate that TCP sequence number guessing attacks have been > significantly stomped on. More knowledgeable people please correct me. > > /* > * Increment for tcp_iss each second. > * This is designed to increment at the standard 250 KB/s, > * but with a random component averaging 128 KB. > * We also increment tcp_iss by a quarter of this amount > * each time we use the value for a new connection. > * If defined, the tcp_random18() macro should produce a > * number in the range [0-0x3ffff] that is hard to predict. > */ > #ifndef tcp_random18 > #define tcp_random18() ((random() >> 14) & 0x3ffff) > #endif > #define TCP_ISSINCR (122*1024 + tcp_random18()) > > extern tcp_seq tcp_iss; /* tcp initial send seq # */ > #else > #define TCP_ISSINCR (250*1024) /* increment for tcp_iss each second */ > #endif /* KERNEL */ > #endif /* _NETINET_TCP_SEQ_H_ */ This is insecure against more sophisticated attacks. Linear congruential generators leak internal state, and this one does so badly. See my patch. Cheers, Julian From owner-freebsd-hackers Thu Jan 30 22:20:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA05313 for hackers-outgoing; Thu, 30 Jan 1997 22:20:34 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA05303 for ; Thu, 30 Jan 1997 22:20:28 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id HAA08839 for ; Fri, 31 Jan 1997 07:20:18 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id HAA16025 for hackers@freebsd.org; Fri, 31 Jan 1997 07:19:57 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id GAA18557; Fri, 31 Jan 1997 06:53:22 +0100 (CET) Message-ID: <19970131065322.GI11386@keltia.freenix.fr> Date: Fri, 31 Jan 1997 06:53:22 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: ipdivert & masqd References: <19970130211742.TN38393@keltia.freenix.fr> <199701302109.WAA29422@ravenock.cybercity.dk> X-Mailer: Mutt 0.59/1-2,4,7-8,10-14 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 3.0-CURRENT ctm#2975 In-Reply-To: =?iso-8859-1?Q?=3C199701302109=2EWAA29422=40ravenock=2Ecybercity=2Edk=3E?= =?iso-8859-1?Q?=3B_from_S=F8ren_Schmidt_on_Jan_30=2C_1997_22=3A09=3A25_+?= =?iso-8859-1?Q?0100?= Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Søren Schmidt: > User authentication ?? at the IP level ?? you lost me there :( There is no user authentication and that is the problem. Some corporations like to have more control and that's where regular proxies are more appreciated than transparent ones. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #37: Mon Jan 27 23:21:10 CET 1997 From owner-freebsd-hackers Thu Jan 30 23:06:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA08329 for hackers-outgoing; Thu, 30 Jan 1997 23:06:35 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA08310 for ; Thu, 30 Jan 1997 23:06:22 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id RAA07585; Fri, 31 Jan 1997 17:34:46 +1030 (CST) From: Michael Smith Message-Id: <199701310704.RAA07585@genesis.atrad.adelaide.edu.au> Subject: Re: The continuting email... In-Reply-To: <199701301648.JAA22108@phaeton.artisoft.com> from Terry Lambert at "Jan 30, 97 09:48:30 am" To: terry@lambert.org (Terry Lambert) Date: Fri, 31 Jan 1997 17:34:45 +1030 (CST) Cc: mcgovern@spoon.beta.com, msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > I want to add a note here: the place he will probably put his energies > is Linux, which has a well documented DDI/DKI. The assumption here is > that he is the pet device driver writer for a given hardware vendor, > not a FreeBSD fanatic who has decided to dive into writing devices. You should perhaps read these threads before delivering your pronouncements; the net result would be less cream in your whiskers. (Brian has already indicated his plans, and I think he'd take offense at being called a 'pet' 8) > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Jan 30 23:48:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA10416 for hackers-outgoing; Thu, 30 Jan 1997 23:48:51 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA10409 for ; Thu, 30 Jan 1997 23:48:47 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id XAA12016; Thu, 30 Jan 1997 23:39:08 -0800 (PST) Date: Thu, 30 Jan 1997 23:37:26 -0800 (PST) From: Julian Elischer To: Martin Cracauer cc: Terry Lambert , rminnich@Sarnoff.COM, freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads In-Reply-To: <9701310238.AA28758@wavehh.hanse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 31 Jan 1997, Martin Cracauer wrote: > > > > > >VM space handling is a little different. If you request VM space sharing, > > > >you don't exactly get Vm address space sharing: what you get is instead > > > >shared data areas where in normal fork they are copied. More details on > > > >request. The effect is what you want, though: shared data areas. > > > > > > Could you explain a bit more. What exactly is the difference between > > > VM space sharing and shared data areas from the process' and the > > > kernel perspective? > > > > The per process open file table points to the same location, for one > > (that's actually a biggie). If I open a file in one process, it is > > open for both processes. If I close it, it's closed. There is one > > fd offset associated with the object -- if one process writes it, > > the offset is advanced, and if the other writes it, it's advanced > > again. There is a potential race as to who gets to do the write. > > Sure, so much is clear. > > But the original comment quoted topmost sounded like there are two > sperate concepts called "VM address speace sharing" and "shared data > areas", which is the same thing for me. Maybe one the these terms > implies that one of them has resources like the descriptor table on > board and the other not, but then I never heard of this term usage. There is VM space sharing, and then there is what rfork CURRENTLY does, which is VM object sharing.. in teh first one, the 'vmspace' structure normally associated with a process simply has it's reference cont incremented.. in the second, each object in teh space has it's reference count incremented.. The differnece is that in teh first, any NEW REGIONS mapped by one process are seen by the other where in the second, only regions that already existed at teh time of the rfork() are shared and new regions are private.. the reason that (1) is not yet implimented is that the kernel stack is in that VM at the same address for each process, and this MUST be unique per process.. The SMP code must have solved this some how, so if they finally check in that code we should be able to switch to (1). > > Hence my question. > > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer > http://cracauer.cons.org > Fax +49 40 522 85 36 > From owner-freebsd-hackers Fri Jan 31 01:30:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA14209 for hackers-outgoing; Fri, 31 Jan 1997 01:30:33 -0800 (PST) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA14184 for ; Fri, 31 Jan 1997 01:30:14 -0800 (PST) Received: from dibble.utell.net (dibble.utell.net [97.3.0.10]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id JAA28459; Fri, 31 Jan 1997 09:29:55 GMT Message-Id: <199701310929.JAA28459@ui-gate.utell.co.uk> From: "Brian Somers" To: "Eivind Eklund" Cc: , Subject: Re: PR2347 - recursive malloc() in ppp Date: Fri, 31 Jan 1997 09:25:11 -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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- > From: Eivind Eklund > To: Brian Somers > Cc: fyeung@fyeung8.netific.com; hackers@freebsd.org > Subject: Re: PR2347 - recursive malloc() in ppp > Date: 31 January 1997 01:46 > > At 10:02 AM 1/30/97 -0000, Brian Somers wrote: > >I'm not sure what your problem might have been, but lots of changes have > >been done to ppp since then. You can pick up the current sources from > >ftp://ftp.freebsd.org:/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ppp if you > >want to have a look at the "current" version, but I don't think it'll > >compile on 2.1*. > > With minor patches, it will. Replace the > > #include > > with > > +#include > +#if ___FreeBSD_version >= 199702 > #include > +#endif > > this might break under 2.2.5R, though. (Will work under 2.1.6, 2.2 and > -current as of today) > > BTW: Who is the right person to submit patches for PPP to? > > > > Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ Brian Don't _EVER_ lose your sense of humour From owner-freebsd-hackers Fri Jan 31 02:21:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA16057 for hackers-outgoing; Fri, 31 Jan 1997 02:21:24 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA16046 for ; Fri, 31 Jan 1997 02:21:20 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id LAA26256; Fri, 31 Jan 1997 11:20:48 +0100 (MET) From: Mikael Karpberg Message-Id: <199701311020.LAA26256@ocean.campus.luth.se> Subject: Re: Source code commits To: kpneal@pobox.com (Kevin P. Neal) Date: Fri, 31 Jan 1997 11:20:48 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <1.5.4.32.19970131030617.00922bc8@mindspring.com> from "Kevin P. Neal" at "Jan 30, 97 10:06:17 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Kevin P. Neal: > At 01:26 AM 1/30/97 -0700, Nate Williams wrote: > >> I suggested a sort of "write-through" validation/submission system for > >> the CVS tree a year ago, where anyone could "commit" to the source > >> tree but for those people who weren't actually authorized to commit > >> directly, what would happen instead is that the diffs would be > >> automagically sent to the person or persons actually responsible for > >> the code in question, and they would review and optionally commit it. > > > >Aieee, why go for trivial solutions when we can do something much more > >useful (and difficult). > > > >I think it would be easier to rewrite CVS from scratch. :) > > Starting with RCS. A nice library with a well defined interface. > Then CVS can be put on top of that. > > This is actually on my todo list. Above it, however, is getting a stable > machine to do the coding on. That sounds great! If you do, however, PLEASE fix the fundamental flaw in cvs: It treats projects, not files. *sigh* This is VERY annoying when using C++, wher eyou have one class per file, and you try to do code reuse. It would be SO nice if you just checked all the files in a "global heap", (unless you specifically said it was to be a project specific file) and what the "project" normally was was just a file looking something like the current ".../CVS/Entries" files. Then you could start building a project, using old classes that had some nice basic functionality you need, like a mutex wrapper, or so. Imagine if you could do something like this to create a new project: me@my> cvs new MyNewProject me@my> cd MyNewProject me@my> mkdir thread_sync me@my> cd thread_sync me@my> cvs include mutexwrapper.cc me@my> emacs semaphorewrapper.cc me@my> cvs add semaphorewrapper.cc me@my> ls mutexwrapper.cc semaphorewrapper.cc me@my> cd .. me@my> vi Makfile me@my> cvs add -private Makefile me@my> ls $CVSROOT/PUBLIC/ mutexwrapper.cc semaphorewrapper.cc me@my> ls $CVSROOT/MyNewProject PUBLIC_INCLUDES Makefile me@my> echo "YES! HURRAY!" etc... Then, if I made a bugfix in my mutexwrapper, it would automatically spread to all my other projects using it, and they could in turn include the semaphore wrapper from this project and start using that. Maybe my example above is wrong. Maybe it should be default private, and have a -public switch. Or maybe have both switches and a .cvsrc option to set the default. It would greatly simplyfy code reuse, and would be very useful, at least for me, trying to track bugfixes across projects at work, and at home. Maybe you should also be able to include a project specific file in another project, if two of your projects need an extra funktion in the mutexwrapper that you don't want to add for all other projects. I just had to get that out of my system :-) It's THE greatest flaw with CVS as it is today, IMHO. /Mikael From owner-freebsd-hackers Fri Jan 31 02:24:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA16205 for hackers-outgoing; Fri, 31 Jan 1997 02:24:22 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA16199 for ; Fri, 31 Jan 1997 02:24:15 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA16798 for hackers@freebsd.org; Fri, 31 Jan 1997 11:24:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id LAA02512; Fri, 31 Jan 1997 11:06:20 +0100 (MET) Message-ID: Date: Fri, 31 Jan 1997 11:06:20 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: lpd - remote printing with an output filter References: <199701310127.TAA21295@nexgen.ampr.org> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701310127.TAA21295@nexgen.ampr.org>; from dkelly@hiwaay.net on Jan 30, 1997 19:25:44 -0600 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As dkelly@hiwaay.net wrote: > I was looking thru the handbook the other night while setting up my > printer. Saw a comment that one way to implement a filter on a remote > printer was to make a "virtual" local printer with an "if" or "of" filter > of your choice which ultimately pipes the output right back into "lpr > -Preal_printer". Doesn't seem so hard? I must be missing something. It's not too hard. However, you lose the ability to kill the job once it went into the final queue, since it's owned by `daemon' then. We use this method extensively at work (mainly for filtering PostScript), and i wrote a setuid perl wrapper that re-owns the job if it originated from a local user. (If the job has been remote, all bets are off anyway, and it will still be owned by daemon.) I can contribute that perl wrapper if people are interested. -- 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 Jan 31 02:26:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA16299 for hackers-outgoing; Fri, 31 Jan 1997 02:26:46 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA16290 for ; Fri, 31 Jan 1997 02:26:43 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id CAA05754 for ; Fri, 31 Jan 1997 02:26:39 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA16800; Fri, 31 Jan 1997 11:24:35 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id LAA02521; Fri, 31 Jan 1997 11:07:52 +0100 (MET) Message-ID: Date: Fri, 31 Jan 1997 11:07:52 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: bigdaddy@livenet.net (Joseph) Cc: hackers@FreeBSD.ORG Subject: Re: Error Message References: <199701310138.UAA13811@Clifford.LiveNet.Net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701310138.UAA13811@Clifford.LiveNet.Net>; from Joseph on Jan 30, 1997 20:31:49 -0500 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Joseph wrote: > Hi I downloaded all of release 2.1.6 into my DOS disk e:\freebsd and I > tried to do the DOS partition install but it keeps giving me this error: > > Error mounting /dev/wd1s2 on /DOS invalid argument 22 What kind of DOS filesystem is it? The DOS filesystem code of FreeBSD (which is known to be a little rusty) doesn't seem to recognize it as a valid DOS filesystem. That's what the `invalid argument' stands for. -- 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 Jan 31 03:08:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA17394 for hackers-outgoing; Fri, 31 Jan 1997 03:08:02 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA17373 for ; Fri, 31 Jan 1997 03:07:59 -0800 (PST) Received: from paris.CS.Berkeley.EDU (paris.CS.Berkeley.EDU [128.32.34.47]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id DAA05809 for ; Fri, 31 Jan 1997 03:07:58 -0800 (PST) Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id DAA01324; Fri, 31 Jan 1997 03:04:56 -0800 (PST) From: Josh MacDonald Message-Id: <199701311104.DAA01324@paris.CS.Berkeley.EDU> To: Terry Lambert cc: brian@awfulhak.demon.co.uk, hackers@freebsd.org Subject: Re: Source code commits In-reply-to: Your message of "Wed, 29 Jan 1997 19:16:01 MST." <199701300216.TAA20836@phaeton.artisoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1317.854708675.1@paris.CS.Berkeley.EDU> Date: Fri, 31 Jan 1997 03:04:37 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Not only does CVS need a rewrite from scratch, it needs a (re?)design from scratch. For those of you aspiring to do so, please note that I've got a pretty big head start and you can all wait for me to finish PRCS 2.0, I'm working on it as I write this. I would like to address Terry's problem here, and have had private discussion's with John Polstra about doing so. Anyone's welcome to make suggestions. -josh > > > Is it possible to commit source code locally, and get cvsup to send the > > > udpates back to freefall ? If not, would there be a lot of work involved > ? > > > > This isn't cvsup's domain, actually, but it is something CVS can > > handle itself. You simply set CVS_RSH to ``ssh' and CVSROOT to > > ``freefall.freebsd.org:/home/ncvs'', then you do your CVS operations > > as normal. > > > > I have some shell functions which I use so that I can keep things > > checked out relative to my local CVS repository (and obviously many > > times faster than using freefall's) up until the point where I want to > > commit the changes, then it fools CVS into thinking that the sources > > were originally checked out from freefall too: > > [ ... ] > > Not too useful to those of us who checkin to our local repository > because we can't checkin to Freefall... > > It would be nice if I could: > > cvsup <-- tree without my tag > cvs co src > [ set local tag ] > [ edit file locally ] > [ check in under tag ] > cvsup <-- tree without my tag > [ edit file more locally ] cvsup <-- tree without my tag > [ check in again under tag ] > cvsup <-- tree without my tag > [ create diff locally ] > [ send diff to Julian (or whever has commit privs ] > [ set new local tag ] > cvsup <-- tree without my tag > cvsup <-- tree without my tag > [ edit file more locally ] > cvsup <-- tree without my tag > [ check in again under tag ] > cvsup <-- tree without my tag > [ Julian commits changes ] > cvsup <-- tree without my tag, but with commits from "local tag" to > to "new local tag" ] > *** Here's the bugger: *** > [ I merge local tag, so deltas after "new local tag" are applied > relative to post-merge code ] > cvsup <-- tree without my tag > [ I repeat "send diff..." ] > ... > > Right now, I have to wait for the checkin, and can do no new work until > it has occurred (making it against my best interests to check in). Plus, > I can't "rebranch" my local tag, or run several concurrent derivative > branches (also making it a bad idea to send diffs). > > Plus you guys lose my edit history, which is what cuts the code up > into small enough change domains for you guys to digest (ie: tag1, code, > tag2, code, tag3, code, tag4, submit 1-2, submit 2-3, submit 3-4). > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Fri Jan 31 03:08:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA17425 for hackers-outgoing; Fri, 31 Jan 1997 03:08:23 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA17420 for ; Fri, 31 Jan 1997 03:08:21 -0800 (PST) Received: from pcpsj.pfcs.com (harlan.fred.net [205.252.219.31]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id DAA05813 for ; Fri, 31 Jan 1997 03:08:14 -0800 (PST) Received: from mumps.pfcs.com (mumps.pfcs.com [192.52.69.11]) by pcpsj.pfcs.com (8.6.12/8.6.9) with SMTP id GAA09971; Fri, 31 Jan 1997 06:06:22 -0500 Received: from localhost by mumps.pfcs.com with SMTP id AA29080 (5.67b/IDA-1.5); Fri, 31 Jan 1997 06:06:19 -0500 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: bigdaddy@livenet.net (Joseph), hackers@FreeBSD.ORG Subject: Re: Error Message In-Reply-To: Your message of "Fri, 31 Jan 1997 11:07:52 +0100." Date: Fri, 31 Jan 1997 06:06:17 -0500 Message-Id: <29078.854708777@mumps.pfcs.com> From: Harlan Stenn Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I just installed a 2.1.6 system tonight. I unpacked the mtools package so I could copy pfdisk.exe from the tools/ subdir to a bootable floppy, and "mdir" failed saying the floppy had a FAT problems (mdir tried the secondary without success). I put the floppy in another (non-FreeBSD) Unix box with mtools on it, copied pfdisk.exe to the floppy without problems, and then booted the floppy on the aforementioned 2.1.6 box without any trouble. H From owner-freebsd-hackers Fri Jan 31 03:13:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA17680 for hackers-outgoing; Fri, 31 Jan 1997 03:13:39 -0800 (PST) Received: from paris.CS.Berkeley.EDU (paris.CS.Berkeley.EDU [128.32.34.47]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA17675 for ; Fri, 31 Jan 1997 03:13:37 -0800 (PST) Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id DAA01372; Fri, 31 Jan 1997 03:13:16 -0800 (PST) From: Josh MacDonald Message-Id: <199701311113.DAA01372@paris.CS.Berkeley.EDU> To: Mikael Karpberg cc: hackers@freebsd.org Subject: Re: Source code commits In-reply-to: Your message of "Fri, 31 Jan 1997 11:20:48 +0100." <199701311020.LAA26256@ocean.campus.luth.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1365.854709176.1@paris.CS.Berkeley.EDU> Date: Fri, 31 Jan 1997 03:12:59 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The problem with your idea is you're trying to fix a problem that wouldn't exist if CVS operated *better* on projects, not on individual files. Its a limitation imposed by the CVS repository format. I think you're approach takes the wrong direction. If CVS didn't have such a hard-coded notion of the directory, you could just have each project have a list of files, some of which could be other projects, then you could share code by including the same subproject in two higher level projects. You could implement this by wrapping CVS in a layer of scripts, even, but I tend to dislike such solutions. -josh > > That sounds great! If you do, however, PLEASE fix the fundamental flaw in > cvs: It treats projects, not files. *sigh* > > This is VERY annoying when using C++, wher eyou have one class per file, > and you try to do code reuse. > > It would be SO nice if you just checked all the files in a "global heap", > (unless you specifically said it was to be a project specific file) and > what the "project" normally was was just a file looking something like > the current ".../CVS/Entries" files. > > Then you could start building a project, using old classes that had some > nice basic functionality you need, like a mutex wrapper, or so. > Imagine if you could do something like this to create a new project: > > me@my> cvs new MyNewProject > me@my> cd MyNewProject > me@my> mkdir thread_sync > me@my> cd thread_sync > me@my> cvs include mutexwrapper.cc > me@my> emacs semaphorewrapper.cc > me@my> cvs add semaphorewrapper.cc > me@my> ls > mutexwrapper.cc semaphorewrapper.cc > me@my> cd .. > me@my> vi Makfile > me@my> cvs add -private Makefile > me@my> ls $CVSROOT/PUBLIC/ > mutexwrapper.cc semaphorewrapper.cc > me@my> ls $CVSROOT/MyNewProject > PUBLIC_INCLUDES Makefile > me@my> echo "YES! HURRAY!" > etc... > > Then, if I made a bugfix in my mutexwrapper, it would automatically spread > to all my other projects using it, and they could in turn include the > semaphore wrapper from this project and start using that. Maybe my example > above is wrong. Maybe it should be default private, and have a -public > switch. Or maybe have both switches and a .cvsrc option to set the default. > It would greatly simplyfy code reuse, and would be very useful, at least > for me, trying to track bugfixes across projects at work, and at home. > Maybe you should also be able to include a project specific file in another > project, if two of your projects need an extra funktion in the mutexwrapper > that you don't want to add for all other projects. > > I just had to get that out of my system :-) > It's THE greatest flaw with CVS as it is today, IMHO. > > /Mikael > > From owner-freebsd-hackers Fri Jan 31 04:36:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA21001 for hackers-outgoing; Fri, 31 Jan 1997 04:36:09 -0800 (PST) Received: from hda.hda.com (ip87-max1-fitch.ziplink.net [199.232.245.87]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA20990 for ; Fri, 31 Jan 1997 04:36:05 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id HAA12655; Fri, 31 Jan 1997 07:30:50 -0500 From: Peter Dufault Message-Id: <199701311230.HAA12655@hda.hda.com> Subject: Re: Jukka Ukkonen: POSIX.4 - scheduler once more (as you requested) In-Reply-To: <14120.854650859@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 30, 97 11:00:59 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 31 Jan 1997 07:30:49 -0500 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk One quick observation: > X * 5. The source code must be available for anyone who wishes to have it. Jukka has already heard this part: What do people think of packaging this up as a user library against an LKM'd pseudo /dev/realtime driver? I have the skeleton to do that. My reasoning is I'd like to be able to have different realtime facilities, for example, process migration to an attached embedded processor that would "fault" back as soon as you tried to do something in that environment. It also gives you a way to have realtime user or group protection. I realise that Jukka's work could always be the default soft-realtime behavior, but if done differently a single binary wouldn't run in both places. The hooks into the default kernel have to be kept well defined with that approach. A downside to this approach is that these won't be system calls. Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-hackers Fri Jan 31 05:51:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA23279 for hackers-outgoing; Fri, 31 Jan 1997 05:51:07 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA23274 for ; Fri, 31 Jan 1997 05:51:03 -0800 (PST) Received: from truk.brandinnovators.com (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 22910 on Fri, 31 Jan 1997 14:21:26 +0100; id OAA22910 efrom: hans@truk.brandinnovators.com; eto: hackers@freebsd.org Received: by truk.brandinnovators.com (8.7.5/BI96070101) for id OAA01068; Fri, 31 Jan 1997 14:15:02 +0100 (MET) Message-Id: <199701311315.OAA01068@truk.brandinnovators.com> From: hans@brandinnovators.com (Hans Zuidam) Subject: tunnel device and SIGIO weirdness To: hackers@freebsd.org Date: Fri, 31 Jan 1997 14:15:02 +0100 (MET) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I've been trying to use the tunnel device for debugging a proprietary TCP/IP stack. In order to simulate interrupts I use the async notification (i.e. SIGIOs) on the fd for the TCP/IP stack. As I ran into something that looks like missing or late arrival of SIGIOs I decided to take a closer look at how SIGIOs are delivered: [net/if_tun.c] if (tp->tun_flags & TUN_ASYNC && tp->tun_pgrp) { if (tp->tun_pgrp > 0) gsignal(tp->tun_pgrp, SIGIO); else if (p = pfind(-tp->tun_pgrp)) psignal(p, SIGIO); } while SIGIOs on sockets are delivered as [kern/uipc_socket2.c] if (so->so_state & SS_ASYNC) { if (so->so_pgid < 0) gsignal(-so->so_pgid, SIGIO); else if (so->so_pgid > 0 && (p = pfind(so->so_pgid)) != 0) psignal(p, SIGIO); } As far as I can see is the delivery of SIGIOs in the tunnel driver wrong. The `... && tp->tun_pgrp) { if (tp->tun_pgrp > 0) ...' looks redundant or in error. Can someone enlighten me? Thanks in advance, Hans -- H. Zuidam E-Mail: hans@brandinnovators.com Brand Innovators B.V. P-Mail: P.O. Box 1377 de Pinckart 54 5602 BJ Eindhoven, The Netherlands 5674 CC Nuenen Tel. +31 40 2631134, Fax. +31 40 2831138 From owner-freebsd-hackers Fri Jan 31 05:55:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA23359 for hackers-outgoing; Fri, 31 Jan 1997 05:55:25 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA23352 for ; Fri, 31 Jan 1997 05:55:22 -0800 (PST) Received: from oskar.nanoteq.co.za ([163.195.219.2]) by mail.crl.com with SMTP id AA22197 (5.65c/IDA-1.5 for ); Fri, 31 Jan 1997 05:54:44 -0800 Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.6.12/8.6.12) id OAA17276; Fri, 31 Jan 1997 14:12:57 +0200 From: Reinier Bezuidenhout Message-Id: <199701311212.OAA17276@oskar.nanoteq.co.za> Subject: Re: ZNYX346 and FreeBSD 2.1.5 In-Reply-To: <199611060525.VAA24242@Gatekeeper.Lamb.net> from Ulf Zimmermann at "Nov 5, 96 09:25:40 pm" To: ulf@lamb.net (Ulf Zimmermann) Date: Fri, 31 Jan 1997 14:12:57 +0200 (SAT) Cc: danny@panda.hilink.com.au, robin@intercore.com, fenner@parc.xerox.com, gavin@ormond.unimelb.edu.au, freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi .... I got a Znyx 4 port PCI card working in FreeBSD 2.1.5 ... but what I now actually would like is to get two of these cards working ... I've tried compiling a kernel that supports 8 de devices but because each port uses an interrupt I seem to be running out of interrupts on the PCI bus ... :( I've tried to set one slot to INT A and the other to INT B, but it doesn't seem to work, when both are on INT A then FreeBSD probes both the cards on the same IRQ's Is it at all possible to have (hardware wize) two of these 4 PORT cards in one machine ?? Thanx Reinier From owner-freebsd-hackers Fri Jan 31 06:16:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA24037 for hackers-outgoing; Fri, 31 Jan 1997 06:16:49 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA24031; Fri, 31 Jan 1997 06:16:41 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id BAA19407; Sat, 1 Feb 1997 01:11:34 +1100 Date: Sat, 1 Feb 1997 01:11:34 +1100 From: Bruce Evans Message-Id: <199701311411.BAA19407@godzilla.zeta.org.au> To: freebsd-hackers@freefall.freebsd.org, mpp@freefall.freebsd.org Subject: Re: grp.h Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Shouldn't the declaration in grp.h read: > > gid_t gr_gid; > >instead of: > > int gr_gid; > >like it currently does? It should at least have the same type. Avoiding grp_t has the advantage that need not depend on . However, already uses gid_t elsewhere. This has been on my list of things to fix for several years. I haven't had time to check for dependenices on sign extension bugs. >It also looks like pwd.h also declares the uid and gid as ints >instead of using the typedefs. Similarly, except already pollutes the namespace by including . Bruce From owner-freebsd-hackers Fri Jan 31 06:38:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA24908 for hackers-outgoing; Fri, 31 Jan 1997 06:38:05 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA24895 for ; Fri, 31 Jan 1997 06:37:52 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA16415; Fri, 31 Jan 1997 09:37:19 -0500 Date: Fri, 31 Jan 1997 09:37:18 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads In-Reply-To: <199701310201.SAA00278@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 30 Jan 1997, Archie Cobbs wrote: > > > Could you explain a bit more. What exactly is the difference between > > > VM space sharing and shared data areas from the process' and the > > > kernel perspective? > What about the heap... is it shared? What about shared libraries? > I assume stack regions are not shared... well let's talk about fork, the vm part anyway. These comments apply to freebsd only -- systems such as irix are a bit different, esp. if you use sproc(). When you fork, there is a vm space that needs to be copied so that the new process has its own distinct address space. So a new vm space is created and populated with new objects. Each object has a set of flags that indicates what should happen when the vmspace_fork is done. These are: #define VM_INHERIT_SHARE ((vm_inherit_t) 0) /* share with child */ #define VM_INHERIT_COPY ((vm_inherit_t) 1) /* copy into child */ #define VM_INHERIT_NONE ((vm_inherit_t) 2) /* absent from child */ #define VM_INHERIT_DONATE_COPY ((vm_inherit_t) 3) /* copy and delete */ Segments for shared library code, text (code), shared mapped files, and read-only segments are typically VM_INHERIT_SHARE. Segments which are data (bss, stack, your initial data area, etc). are typically VM_INHERIT_COPY, which means that they get copy-on-write semantics. [[ for an interesting discussion on the (de-)merits of copy-on-write, look in the usenix archives for the keyword "bovaphobic".]] So what I did for rfork, v1: 1) modified /proc so that any process could read the file /seglist and determine what segments were part of its address space, and what the inherit attributes of those segments were. As an aside, the number of one and two-page length objects is interesting and at times depressing. (this (trivial) set of changes was offered to freebsd many times, but never picked up. Memo to ron: could openbsd use it? ) seglist was read-write: you could modify your segments attributes by writing to it. Of course normal file permissions apply: you can't sabotage other people's segment attributes! 2) Added a system call (minherit) that let users modify the segment inheritance more efficiently. Offered to freebsd, results as above. 3) added rfork, which had user-mode work and kernel-mode work. rfork user-mode simply set the inherit attributes of everything past _end up to the end of bss (break(0)) to VM_INHERIT_SHARE. so your data areas, but not your stack, ended up shared. rfork kernel simply forked, but also allowed fd table sharing. so to sum up: 1) data areas end up shared 2) stack is not shared 3) in my original version you had a great deal of flexibility as to what is shared. What's not shared is the address space itself, unlike e.g. Irix. So if the processes make mods to the address space after the rfork, they are not visible to each other. Why's this matter? well, if you're doing a user-mode distributed shared memory it matters in some cases, but I've written enough here ... See openbsd for a different and in many ways better, but less flexible, version of rfork. in particular, the flexibility of inheritance is not as good, but at least you don't have to figure out in user mode what inheritance to set. As i understand TDRs implementation of rfork was the one that finally made it (albeit with modifications) into freebsd. ron From owner-freebsd-hackers Fri Jan 31 06:45:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA25305 for hackers-outgoing; Fri, 31 Jan 1997 06:45:28 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA25300 for ; Fri, 31 Jan 1997 06:45:25 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA16465; Fri, 31 Jan 1997 09:43:52 -0500 Date: Fri, 31 Jan 1997 09:43:51 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Andrew.Gordon@net-tel.co.uk cc: freebsd-hackers@freebsd.org Subject: Re: Re(2): Using rfork() / threads In-Reply-To: <"40b1-970131030103-8AD9*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well, i have another thing that was (ah well) offered to freebsd called fastlock(). Fastlock was two things: 1) test and set, which ran at memory bandwidth 2) a system call to be called only if the lock failed, which ran at system call speeds. Fastlock is called with a pointer to shared data. In the general case locks do not collide. So the cost of fastlock is the cost of a tset. In the case of collision, the high-order bit was set (tset(mem, 0x80000000) and the fastlock system call was called. The process waiting on the lock then slept. The owner of the lock can do one of two things when it frees the lock: 1) if no collide (mem&0x80000000 == 0), just clear the lock 2) otherwise, clear the lock and call a system call which wakes up the first sleeper on the lock. End result: very very fast locks, quite a bit faster than anything else. ron Ron Minnich |"Failure is not an option" -- Gene Kranz rminnich@sarnoff.com | -- except, of course, on Microsoft products (609)-734-3120 | ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html From owner-freebsd-hackers Fri Jan 31 06:46:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA25355 for hackers-outgoing; Fri, 31 Jan 1997 06:46:35 -0800 (PST) Received: from students.itb.ac.id (students.ITB.ac.id [167.205.22.114]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA25346 for ; Fri, 31 Jan 1997 06:46:28 -0800 (PST) Received: (from iman@localhost) by students.itb.ac.id (8.8.4/8.7.3) id VAA13227; Fri, 31 Jan 1997 21:45:58 +0700 (JVT) Date: Fri, 31 Jan 1997 21:45:58 +0700 (JVT) From: iman triwahyudi To: hackers@FreeBSD.ORG Subject: packet driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Anyone know how to get radio packet driver for FreeBSD ? Cheers Iman From owner-freebsd-hackers Fri Jan 31 07:17:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26596 for hackers-outgoing; Fri, 31 Jan 1997 07:17:04 -0800 (PST) Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA26590 for ; Fri, 31 Jan 1997 07:16:58 -0800 (PST) Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id KAA16900 for ; Fri, 31 Jan 1997 10:16:57 -0500 Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma016775; Fri Jan 31 10:15:40 1997 Received: from dur-mail.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA27364; Fri, 31 Jan 97 10:21:36 EST Received: from thoth.ctron (thoth.ctron.com [134.141.65.91]) by dur-mail.ctron.com (8.6.12/8.6.9) with ESMTP id KAA04390 for ; Fri, 31 Jan 1997 10:18:49 -0500 Received: from thoth by thoth.ctron (SMI-8.6/SMI-SVR4) id KAA20051; Fri, 31 Jan 1997 10:17:31 -0500 Message-Id: <32F20D0B.6385@ctron.com> Date: Fri, 31 Jan 1997 10:17:31 -0500 From: Alexander Seth Jones Organization: Cabletron Systems, Inc. X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: hackers@freefall.freebsd.org Subject: performance puzzler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've just run into a puzzling situation: The code consists of protocol messages being encoded into a byte stream, and then decoded back into a C++ object. One of the messages is 200 bytes in length, and I successfully decode it, do all error checking, etc., in about 0.5 milliseconds. This is without -O, and with -m486 and -ggdb. The hardware is an Intel 486-66, running 2.1.5-RELEASE. The puzzling thing comes when I try to run the test at home on my AMD 486-120, running 2.1.0-RELEASE. It runs the test in 0.6 milliseconds!! I decided to do some investigation. I ran the lmbenchmark memory read and write tests on both machines, and the 120 beat the 66 convincingly on every test. I then ran a simple test that incremented an integer 100 million times. It took the 120 between 17 and 18 seconds, and the 66 between 26 and 27 seconds, which is close to the 120/66 ratio I would expect. Why, then, does the 120 run my code slower than the 66? I've double checked and re-double checked the test, had other people look at it, and it is a valid test. Is there an instruction that I'm using a lot that Intel can do that much faster than AMD? Help... -- Alex Jones | ajones@ctron.com Cabletron Systems, Inc. Durham, NH USA 03824 From owner-freebsd-hackers Fri Jan 31 07:34:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA27409 for hackers-outgoing; Fri, 31 Jan 1997 07:34:23 -0800 (PST) Received: from eldorado.net-tel.co.uk ([193.122.171.253]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA27330 for ; Fri, 31 Jan 1997 07:34:03 -0800 (PST) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id PAA20686; Fri, 31 Jan 1997 15:31:11 GMT Received: from "/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/" by net-tel.co.uk (Route400-RFCGate); Fri, 31 Jan 97 15:27:15 +0000 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 31 Jan 97 15:27:15 +0000 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 31 Jan 97 15:27:13 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Fri, 31 Jan 97 15:27:13 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:8655-970131152713-4AEF] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Fri, 31 Jan 97 15:27:13 +0000 X400-Content-Identifier: Re(2): Re(2): Us Message-Id: <"5fb2-970131152702-FFD1*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: "Ron G. Minnich" Cc: freebsd-hackers@freebsd.org In-Reply-To: Subject: Re(2): Re(2): Using rfork() / threads Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > well, i have another thing that was (ah well) offered to freebsd called > fastlock(). Fastlock was two things: > 1) test and set, which ran at memory bandwidth > 2) a system call to be called only if the lock failed, > which ran at system call speeds. Sounds just the ticket for what I need. I am quite often writing servers for one network protocol or another, where the the server holds per-user state for a large number of users, but the users typically spend much of their time asleep at the keyboard and hence a process-per-user design is wasteful, but in the absence of async I/O, a one-process design has insufficient parallelism. The ideal compromise is a small number of processes picking work off a queue - but this needs the per-user state to be shared between the processes and a means of sharing out the requests. You can do some of this with SysV SHM and semaphores, but it gets inefficient when one of the pieces of per-user state you would like to share is an open fd. rfork() and fastlock() seems a much more efficient combination, though there is a potential problem with running out of fds in a large system. From owner-freebsd-hackers Fri Jan 31 07:56:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA28244 for hackers-outgoing; Fri, 31 Jan 1997 07:56:44 -0800 (PST) Received: from canario.fiscodata (root@[200.255.244.56]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA28239 for ; Fri, 31 Jan 1997 07:56:38 -0800 (PST) Received: from paulo (paulo.fiscodata [192.168.0.18]) by canario.fiscodata (8.7.5/8.7.3) with SMTP id NAA22512; Fri, 31 Jan 1997 13:58:36 GMT Message-ID: <32F1F954.794BDF32@sul.com.br> Date: Fri, 31 Jan 1997 13:53:24 +0000 From: Paulo Cesar Pereira de Andrade Organization: FiscoData X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: Joerg Wunsch CC: FreeBSD Hackers Subject: Re: Error Message References: <199701310138.UAA13811@Clifford.LiveNet.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Joseph wrote: > > > Hi I downloaded all of release 2.1.6 into my DOS disk e:\freebsd and I > > tried to do the DOS partition install but it keeps giving me this error: > > > > Error mounting /dev/wd1s2 on /DOS invalid argument 22 > > What kind of DOS filesystem is it? The DOS filesystem code of FreeBSD > (which is known to be a little rusty) doesn't seem to recognize it as > a valid DOS filesystem. That's what the `invalid argument' stands > for. > > -- > 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. ;-) Should be: FreeBSD - DOG /dev/wd1s5 - D: /dev/wd1s6 - E: With FreeBSD 2.1.0 I cant see a way to select these devices, as a DOS partition install. I remember, when I was so new to Unix, and installed FreeBSD 2.0, I had the option to choose a device, but looks like now you must use your imagination :(. -- **** Paulo Cesar Pereira de Andrade - fisco.dev@sul.com.br **** --------------------------------------------------------------- **** The daemon is Free **** From owner-freebsd-hackers Fri Jan 31 08:38:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA29711 for hackers-outgoing; Fri, 31 Jan 1997 08:38:13 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA29706 for ; Fri, 31 Jan 1997 08:38:11 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA09671; Fri, 31 Jan 1997 09:38:05 -0700 (MST) Date: Fri, 31 Jan 1997 09:38:05 -0700 (MST) Message-Id: <199701311638.JAA09671@rocky.mt.sri.com> From: Nate Williams To: Josh MacDonald Cc: hackers@freebsd.org Subject: Re: Source code commits In-Reply-To: <199701311104.DAA01324@paris.CS.Berkeley.EDU> References: <199701300216.TAA20836@phaeton.artisoft.com> <199701311104.DAA01324@paris.CS.Berkeley.EDU> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Josh MacDonald writes: > Not only does CVS need a rewrite from scratch, it needs a > (re?)design from scratch. For those of you aspiring to > do so, please note that I've got a pretty big head start and > you can all wait for me to finish PRCS 2.0, I'm working on > it as I write this. You already know what I'd like (CVS mailing lists *grin*), but let me state publically (outside of Greg's ear) that I think client/server is a bigger issue than atomic locking and 'commit' locking. But, feel free to address any of them you feel. (If you feel like talking about it, I have some ideas you might be interested in offline). Nate From owner-freebsd-hackers Fri Jan 31 08:40:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA29893 for hackers-outgoing; Fri, 31 Jan 1997 08:40:51 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA29886 for ; Fri, 31 Jan 1997 08:40:49 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id IAA12413 for ; Fri, 31 Jan 1997 08:42:02 -0800 (PST) Received: (qmail 6453 invoked by uid 110); 31 Jan 1997 16:40:19 -0000 Message-ID: <19970131164019.6452.qmail@suburbia.net> Subject: Re: grp.h In-Reply-To: <199701311411.BAA19407@godzilla.zeta.org.au> from Bruce Evans at "Feb 1, 97 01:11:34 am" To: bde@zeta.org.au (Bruce Evans) Date: Sat, 1 Feb 1997 03:40:19 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >It also looks like pwd.h also declares the uid and gid as ints > >instead of using the typedefs. > > Similarly, except already pollutes the namespace by including > . > > Bruce > See my pr for a numner of include fixes, this being one of them. ------------------------------------------------------------------------------ Prof. Julian Assange |If you want to build a ship, don't drum up people proff@iq.org |together to collect wood and don't assign them tasks proff@suburbia.net |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-hackers Fri Jan 31 08:55:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA00776 for hackers-outgoing; Fri, 31 Jan 1997 08:55:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA00771 for ; Fri, 31 Jan 1997 08:55:47 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA02872; Fri, 31 Jan 1997 09:54:22 -0700 From: Terry Lambert Message-Id: <199701311654.JAA02872@phaeton.artisoft.com> Subject: Re: Using rfork() / threads To: julian@current1.whistle.com (Julian Elischer) Date: Fri, 31 Jan 1997 09:54:22 -0700 (MST) Cc: cracauer@wavehh.hanse.de, terry@lambert.org, rminnich@Sarnoff.COM, freebsd-hackers@freebsd.org In-Reply-To: from "Julian Elischer" at Jan 30, 97 11:37:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > the reason that (1) is not yet implimented is that the kernel > stack is in that VM at the same address for each process, > and this MUST be unique per process.. > The SMP code must have solved this some how, > so if they finally check in that code we should be able > to switch to (1). Stack per processor. Really, there needs to be the concept of a kernel execution context, for a *lot* of reasons. Foremost would be the implementation of an async call gate. 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 Jan 31 09:17:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA01821 for hackers-outgoing; Fri, 31 Jan 1997 09:17:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01816 for ; Fri, 31 Jan 1997 09:17:09 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA02956; Fri, 31 Jan 1997 10:15:10 -0700 From: Terry Lambert Message-Id: <199701311715.KAA02956@phaeton.artisoft.com> Subject: Re: The continuting email... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Fri, 31 Jan 1997 10:15:10 -0700 (MST) Cc: terry@lambert.org, mcgovern@spoon.beta.com, msmith@atrad.adelaide.edu.au, hackers@freebsd.org In-Reply-To: <199701310704.RAA07585@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 31, 97 05:34:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I want to add a note here: the place he will probably put his energies > > is Linux, which has a well documented DDI/DKI. The assumption here is > > that he is the pet device driver writer for a given hardware vendor, > > not a FreeBSD fanatic who has decided to dive into writing devices. > > You should perhaps read these threads before delivering your > pronouncements; the net result would be less cream in your whiskers. > > (Brian has already indicated his plans, and I think he'd take offense at > being called a 'pet' 8) Whether you call it "pet" or "employee", you are talking the same net effect: he will have a small amount of discretionary time, if any, and any project undertaken for a free UNIX clone on his bosses say-so will be done in the context of a cost/benefit analysis, and not because he likes FreeBSD. I understand where you are coming from, but playing the hardline is only a valid strategy when you and the person you are playing with are operating from the same philosophical basis. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Jan 31 09:28:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02340 for hackers-outgoing; Fri, 31 Jan 1997 09:28:31 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA02334 for ; Fri, 31 Jan 1997 09:28:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA02984; Fri, 31 Jan 1997 10:25:38 -0700 From: Terry Lambert Message-Id: <199701311725.KAA02984@phaeton.artisoft.com> Subject: Re: Source code commits To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Fri, 31 Jan 1997 10:25:38 -0700 (MST) Cc: kpneal@pobox.com, hackers@FreeBSD.ORG In-Reply-To: <199701311020.LAA26256@ocean.campus.luth.se> from "Mikael Karpberg" at Jan 31, 97 11:20:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >I think it would be easier to rewrite CVS from scratch. :) > > > > Starting with RCS. A nice library with a well defined interface. > > Then CVS can be put on top of that. > > > > This is actually on my todo list. Above it, however, is getting a stable > > machine to do the coding on. > > That sounds great! If you do, however, PLEASE fix the fundamental flaw in > cvs: It treats projects, not files. *sigh* > > This is VERY annoying when using C++, wher eyou have one class per file, > and you try to do code reuse. > > It would be SO nice if you just checked all the files in a "global heap", > (unless you specifically said it was to be a project specific file) and > what the "project" normally was was just a file looking something like > the current ".../CVS/Entries" files. Ugh. The "global heap" idea in PVCS and in DEC's VCS both suffer from not letting you have duplicate file names in code branches. This is very bad if you want to provide an encapsulated inplementation class for an interface class for something like, oh, say, y.tab.c, y.code.c, y.tab.h, and lex.yy.c. For instance, if you have an interface class "automaton" or "character parser" that encapsulated the lex/yacc relationship and you had multiple implementation classed for that interface. > Then, if I made a bugfix in my mutexwrapper, it would automatically spread > to all my other projects using it, and they could in turn include the > semaphore wrapper from this project and start using that. Maybe my example > above is wrong. Maybe it should be default private, and have a -public > switch. Or maybe have both switches and a .cvsrc option to set the default. > It would greatly simplyfy code reuse, and would be very useful, at least > for me, trying to track bugfixes across projects at work, and at home. > Maybe you should also be able to include a project specific file in another > project, if two of your projects need an extra funktion in the mutexwrapper > that you don't want to add for all other projects. Hmm... Almost, for C++, you want to implement at the interface level and include the interface definitions in your consumer code, but leave the implementation class as common code associated through the abstract virtual base class... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Jan 31 09:40:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA03084 for hackers-outgoing; Fri, 31 Jan 1997 09:40:30 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA03073 for ; Fri, 31 Jan 1997 09:40:18 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA03009; Fri, 31 Jan 1997 10:38:37 -0700 From: Terry Lambert Message-Id: <199701311738.KAA03009@phaeton.artisoft.com> Subject: Re: performance puzzler To: ajones@ctron.com (Alexander Seth Jones) Date: Fri, 31 Jan 1997 10:38:37 -0700 (MST) Cc: hackers@freefall.freebsd.org In-Reply-To: <32F20D0B.6385@ctron.com> from "Alexander Seth Jones" at Jan 31, 97 10:17:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The code consists of protocol messages being encoded into a byte > stream, and then decoded back into a C++ object. One of the messages is > 200 bytes in length, and I successfully decode it, do all error > checking, etc., in about 0.5 milliseconds. This is without -O, and with > -m486 and -ggdb. The hardware is an Intel 486-66, running > 2.1.5-RELEASE. > > The puzzling thing comes when I try to run the test at home on my AMD > 486-120, running 2.1.0-RELEASE. It runs the test in 0.6 milliseconds!! Divide each clock speed by increasing integer values starting with 1 until the result is less than or equal to 33. This is your max bus speed possible for the system. An easy way to do this is magnitude based arithmatic (yes, I own a slide-rule): exp(log(120)%log(33)) = 30 exp(log(66)%log(33)) = 33 Your bus on the 120 is 3MHz slower than the bus on the 66. What you are doing is not I/O bound, it is CPU bound. It is a common mistake to believe that a clock multiplied CPU will make everything faster, and frequently people trade down bus speed to trade up CPU speed. In point of fact, access to everything but L1 is done at bus speed, not CPU speed, and access to non-L1, non-L2 potentially causes I/O wait states. These are the results you should expect on I/O bound operations, even on CPU's from the same chipmask. There may be AMD-specific instruction speed difference on top of this. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Jan 31 09:47:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA03401 for hackers-outgoing; Fri, 31 Jan 1997 09:47:58 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA03392 for ; Fri, 31 Jan 1997 09:47:53 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-10.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA05341 (5.67b/IDA-1.5 for ); Fri, 31 Jan 1997 18:46:31 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id SAA02964; Fri, 31 Jan 1997 18:46:40 +0100 (CET) Message-Id: <19970131184640.QA11059@x14.mi.uni-koeln.de> Date: Fri, 31 Jan 1997 18:46:40 +0100 From: se@freebsd.org (Stefan Esser) To: rbezuide@oskar.nanoteq.co.za (Reinier Bezuidenhout) Cc: ulf@lamb.net (Ulf Zimmermann), danny@panda.hilink.com.au, robin@intercore.com, fenner@parc.xerox.com, gavin@ormond.unimelb.edu.au, freebsd-hackers@freebsd.org Subject: Re: ZNYX346 and FreeBSD 2.1.5 References: <199611060525.VAA24242@Gatekeeper.Lamb.net> <199701311212.OAA17276@oskar.nanoteq.co.za> X-Mailer: Mutt 0.59-PL19 Mime-Version: 1.0 In-Reply-To: <199701311212.OAA17276@oskar.nanoteq.co.za>; from Reinier Bezuidenhout on Jan 31, 1997 14:12:57 +0200 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 31, rbezuide@oskar.nanoteq.co.za (Reinier Bezuidenhout) wrote: > Hi .... > > I got a Znyx 4 port PCI card working in FreeBSD 2.1.5 ... but what > I now actually would like is to get two of these cards working ... Doesn't sound too hard ... > I've tried compiling a kernel that supports 8 de devices but because > each port uses an interrupt I seem to be running out of interrupts on > the PCI bus ... :( You can't run out of interrupts on the PCI bus (by definition :) > I've tried to set one slot to INT A and the other to INT B, but > it doesn't seem to work, when both are on INT A then FreeBSD > probes both the cards on the same IRQ's Well, what's bad about this ? On most PCI motherboards, there are only 4 distinct interrupt lines available on the PCI *bus*. This is not a limitation of PCI, which only defines, that there are 4 interrupt PINs per PCI *slot*, but not whether each is individually connected to some kind of interrupt controller, or as the other extreme all interrupt pins of all slots are just wired together in some way ... PCI drivers must support interrupt sharing, and FreeBSD does, for quite some time now. If you can't get your cards to work, then I need a VERBOSE boot message log. But I assume, that everything works just fine, with always two Ethernet chips from either card sharing one IRQ. > Is it at all possible to have (hardware wize) two of these > 4 PORT cards in one machine ?? I think so. Please boot with "-v" and send me the log, and I will check, whether there is anything to worry about. Regards, STefan From owner-freebsd-hackers Fri Jan 31 10:07:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA04103 for hackers-outgoing; Fri, 31 Jan 1997 10:07:26 -0800 (PST) Received: from chai.plexuscom.com (chai.plexuscom.com [207.87.46.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA04093 for ; Fri, 31 Jan 1997 10:07:23 -0800 (PST) Received: from chai.plexuscom.com (localhost [127.0.0.1]) by chai.plexuscom.com (8.8.4/8.6.12) with ESMTP id NAA14384 for ; Fri, 31 Jan 1997 13:08:01 -0500 (EST) Message-Id: <199701311808.NAA14384@chai.plexuscom.com> To: hackers@freebsd.org Subject: g++, STL and -frepo on FreeBSD-2.2-Beta Date: Fri, 31 Jan 1997 13:08:01 -0500 From: Bakul Shah Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'd appreciate some help from g++/STL experts on this list to solve a problem with the above combination. If this problem can be solved, a copylefted Verilog behavioral simuluator just may show up in the ports collection! Assuming it works. For the uninitiated, the -frepo patch from cygnus to the stock gcc-2.7.2 is essential for a hassle free use of the standard template library (STL). As I understand it, somehow the linker calls the compiler as many times as needed to instantiate specific classes built from templates and used in the program being linked. The trouble is, this doesn't work for me. This is what I did: tar -zxf gcc-2.7.2.tar.gz cd gcc-2.7.2 gzcat ../gcc-2.7.2-2.7.2.1.diff.gz | patch -p1 -s gzcat ../gcc-2.7.2-repo.gz | patch -s ./configure make bootstrap make install # this step as root rm /usr/local/lib/gcc-lib/i386-unknown-freebsd2.2/2.7.2.1/include/stdarg.h # gcc installed stdarg.h clashes with the standard freebsd includes. Next I built and installed libg++-2.7.1 because that is what the program I am trying to compile wants. Then I tried the following test program: cat >x.cc < // include everything for simplicity. #include #include int main(int, char*[]) { list list1; for(int i = 0; i < 10; ++i) { list1.push_back(rand()); } return 0; } EOF g++ -frepo -c x.cc g++ -o x x.o The last step above should call the compiler to instantiate the list class and everything should just work. No such luck. I get: x.o: Undefined symbol `list::list(void)' referenced from text segment x.o: Undefined symbol `list::push_back(int const &)' referenced from text segment x.o: Undefined symbol `list::~list(void)' referenced from text segment collect2: ld returned 1 exit status g++ -v -o x x.o reveals /usr/local/lib/gcc-lib/i386-unknown-freebsd2.2/2.7.2.1/ld -e start -dc -dp -o x /usr/lib/crt0.o -L/usr/local/lib/gcc-lib/i386-unknown-freebsd2.2/2.7.2.1 -L/usr/local/lib x.o -lg++ -lstdc++ -lm -lgcc -lc -lgcc Which seems right to me. Any ideas for figuring this out will be gratefully accepted. -- bakul From owner-freebsd-hackers Fri Jan 31 10:11:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA04432 for hackers-outgoing; Fri, 31 Jan 1997 10:11:37 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA04409 for ; Fri, 31 Jan 1997 10:11:30 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id FAA27476; Sat, 1 Feb 1997 05:07:11 +1100 Date: Sat, 1 Feb 1997 05:07:11 +1100 From: Bruce Evans Message-Id: <199701311807.FAA27476@godzilla.zeta.org.au> To: bde@zeta.org.au, proff@suburbia.net Subject: Re: grp.h Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >It also looks like pwd.h also declares the uid and gid as ints >> >instead of using the typedefs. >> >> Similarly, except already pollutes the namespace by including >> . >See my pr for a numner of include fixes, this being one of them. They pollute the namespace unacceptably (to me). Otherwise I would have made some of them years ago. Has anyone (except the authors :-) looked closely at glibc-2.0? Old versions were careful to a fault about namespaces (IIRC they did things like including features.h multiple times to get one name each time). Old Linux headers have an ugly combination of carefulness for gnu features and sloppiness for Linux features. Bruce From owner-freebsd-hackers Fri Jan 31 12:26:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10249 for hackers-outgoing; Fri, 31 Jan 1997 12:26:12 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10244 for ; Fri, 31 Jan 1997 12:26:09 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id HAA30173; Sat, 1 Feb 1997 07:21:35 +1100 Date: Sat, 1 Feb 1997 07:21:35 +1100 From: Bruce Evans Message-Id: <199701312021.HAA30173@godzilla.zeta.org.au> To: hackers@freebsd.org, hans@brandinnovators.com Subject: Re: tunnel device and SIGIO weirdness Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >As I ran into something that looks like missing or late arrival of >SIGIOs I decided to take a closer look at how SIGIOs are delivered: > > [net/if_tun.c] > if (tp->tun_flags & TUN_ASYNC && tp->tun_pgrp) { > if (tp->tun_pgrp > 0) > gsignal(tp->tun_pgrp, SIGIO); > else if (p = pfind(-tp->tun_pgrp)) > psignal(p, SIGIO); > } >As far as I can see is the delivery of SIGIOs in the tunnel driver >wrong. The `... && tp->tun_pgrp) { if (tp->tun_pgrp > 0) ...' looks >redundant or in error. Can someone enlighten me? Thanks in advance, I think it just uses a different sign convention. The bugs are probably in the initialization of tp->tun_pgrp. The FSETOWN ioctl has many bugs. It is documented to apply to files, but it actually applies to the underlying sockets or devices. It works better for sockets because fcntl() knows too much about sockets and initializes the socket directly without checking anything. This makes it easy to initialize the pgid to any process id or any process group id (including ones that don't exist and ones that you don't have permission to send signals to :-(). For non-sockets, it converts positive pgid's to the process group id, so it is impossible to send SIGIO to single processes and the (tp->tun_pgrp < 0) code is unreachable. It is more broken for ttys. For ttys, the ASYNC pgrp must match the POSIX pgrp it it's often inconvenient to set up a POSIX pgrp. Bruce From owner-freebsd-hackers Fri Jan 31 12:33:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10504 for hackers-outgoing; Fri, 31 Jan 1997 12:33:03 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10499 for ; Fri, 31 Jan 1997 12:32:59 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA15001; Fri, 31 Jan 1997 13:32:14 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <9701301753.AA23376@wavehh.hanse.de> Date: Thu, 30 Jan 1997 23:38:31 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: cracauer@wavehh.hanse.de Subject: Re: Using rfork() / threads Cc: freebsd-hackers@freebsd.org, rminnich@Sarnoff.COM, (Martin Cracauer) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Martin Cracauer; On 30-Jan-97 you wrote: > rminnich@Sarnoff.COM (Ron G. Minnich) wrote: > > [rfork] > > >VM space handling is a little different. If you request VM space sharing, > >you don't exactly get Vm address space sharing: what you get is instead > >shared data areas where in normal fork they are copied. More details on > >request. The effect is what you want, though: shared data areas. > > Could you explain a bit more. What exactly is the difference between > VM space sharing and shared data areas from the process' and the > kernel perspective? Yes please, in perspective of the Linux clone(2) and the new libc 2.0 threads, etc. Thanx, Simon From owner-freebsd-hackers Fri Jan 31 12:33:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10593 for hackers-outgoing; Fri, 31 Jan 1997 12:33:39 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10575 for ; Fri, 31 Jan 1997 12:33:34 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA15046; Fri, 31 Jan 1997 13:32:17 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 31 Jan 1997 13:27:44 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: "Ron G. Minnich" Subject: Re: Re(2): Using rfork() / threads Cc: freebsd-hackers@FreeBSD.ORG, Andrew.Gordon@net-tel.co.uk Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk So where is this fantastic code? Simon Hi Ron G. Minnich; On 31-Jan-97 you wrote: > well, i have another thing that was (ah well) offered to freebsd called > fastlock(). Fastlock was two things: > 1) test and set, which ran at memory bandwidth > 2) a system call to be called only if the lock failed, > which ran at system call speeds. > > Fastlock is called with a pointer to shared data. In the general case > locks do not collide. So the cost of fastlock is the cost of a tset. In > the case of collision, the high-order bit was set (tset(mem, 0x80000000) > and the fastlock system call was called. The process waiting on the lock then > slept. > > The owner of the lock can do one of two things when it frees the lock: > 1) if no collide (mem&0x80000000 == 0), just clear the lock > 2) otherwise, clear the lock and call a system call which wakes up the first > sleeper on the lock. > > End result: very very fast locks, quite a bit faster than anything else. > > ron > > Ron Minnich |"Failure is not an option" -- Gene Kranz > rminnich@sarnoff.com | -- except, of course, on Microsoft products > (609)-734-3120 | > ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html > > From owner-freebsd-hackers Fri Jan 31 12:36:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10849 for hackers-outgoing; Fri, 31 Jan 1997 12:36:14 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10839 for ; Fri, 31 Jan 1997 12:36:09 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA15000; Fri, 31 Jan 1997 13:32:13 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701310144.UAA04356@spooky.rwwa.com> Date: Thu, 30 Jan 1997 23:36:43 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Robert Withrow Subject: Re: glibc-2.0 (aka libc-6) - new, experimental version of C libr Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Robert Withrow; On 31-Jan-97 you wrote: > > richard@deep-thought.org said: > > * The new auxiliary library `-lutil' from 4.4 BSD contains various > > functions for maintaining the login-record files (primarily of use to > > system programs such as `login'), and convenient functions for > > allocating and initializing a pseudo-terminal (pty) device. > > Out of curiosity, does this library now have a more restrictive > copyright (i.e. gpv) than it did when it came from 4.4 BSD? But, of course my dear. It is a FSF product. Freedom is a ratchet, you can tighen but not loosen. Simon From owner-freebsd-hackers Fri Jan 31 12:36:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10884 for hackers-outgoing; Fri, 31 Jan 1997 12:36:21 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA10855 for ; Fri, 31 Jan 1997 12:36:14 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA07342 (5.67b/IDA-1.5 for ); Fri, 31 Jan 1997 21:36:10 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id VAA04082; Fri, 31 Jan 1997 21:36:22 +0100 (CET) Message-Id: <19970131213621.EQ13588@x14.mi.uni-koeln.de> Date: Fri, 31 Jan 1997 21:36:21 +0100 From: se@freebsd.org (Stefan Esser) To: hackers@freebsd.org Subject: PCI LKM: How to find object file from PCI ID ... X-Mailer: Mutt 0.59-PL19 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all! I've been thinking about the best way to have a user-land program determine, whether any of the object files in the /lkm directory might be appropriate for some PCI device, for which no driver exists in the kernel. I test-implemented all of them, and found that all approaches that relie on some text being present in the object file as a string or as part of a symbol require this information to be inlined verbatim (i.e. you can't just reference a macro like NCR_810_ID, since it is only defined regarding its numeric contents). Possibilities: 1) Have a config file that contains PCI ID to LKM mappings. 2) Put the PCI IDs as character strings into the LKM binary. 3) Create symbols with names that allow to derive PCI IDs supported. 4) Put an array of PCI IDs into the LKM under a well known name. Examples: 1) File containing lines like: D 00011000 ncr.o D 000f1000 ncr.o D 802910ec if_ed.o [ The "D" denotes a PCI Device ID, while "C" would match a PCI Class, and "S" a Subvendor ID. ] 2) Create (symbolic) links that contain the PCI ID and point to the LKM file: /dev/pci/d_00011000 -> ../ncr.o /dev/pci/d_000f1000 -> ../ncr.o /dev/pci/d_802910ec -> ../if_ed.o 3) Include a string into the binary, for example: static const char pciids [] = "\nPCI_D 00011000 000f1000\n"; 4) Define a character variable, of which only the name is significant: static char pci_d_00011000; static char pci_d_000f1000; 5) Build an array of integers under a known name: static const int pci_d_ids [] = { 0x00011000, 0x000f1000 }; Advantages: 1) Trivial implementation, no driver changes required. Fast lookup from a script possible, for highest flexibility. 2) Trivial implementation, extremely fast lookup, high flexibility. Similar to 1), but uses file names as keys to directly access the LKM required. 3) Easy to implement and to use (just a "strings | grep"). 4) Easy to implement and to use, but requires system command "nm" instead of "strings". 5) The only one not worried about the details of the representation of the number (i.e. operating on a number instead of a string). 3+4+5) do not require any steps beyond copying the LKM into the target directory for making it available to the PCI LKM loader. Disadvantages: 1) File must be maintained on driver updates (but this could be automated to happen in the install target of the LKM's Makefile or the package "description" of a LKM distributed as binary). 2) Lots of file names are to be created, since a single driver may support devices with up to 10 distinct PCI IDs. Inconsistencies are possible, if a LKM is replaced by one for a different (set of) PCI device(s), but the old PCI IDs still point to the LKM name (this could be avoided by using hard links). 3) Requires an action to be performed on each file in the LKM directory, which is significantly slower than a grep on a file. False hits are possible, but can be minimized by choosing a good lead in string for each line. The character array increases the kernel space requirement of the driver. 4) Same as 3), with "nm" being slower and possibly not available on a system (if it is not at all used for software development). 5) Can't be done in a simple shell script. (Ok, you could make this a shell script calling the debugger to extract symbol information :) A C program is required to extract the symbol table with reasonable performance. 3+4+5) Could take advantage of cacheing information retrieved on boot time in file, and then the advantages of 1) could be provided :) Conclusions: I'm not going to choose either of these for the time being, but would like to receive some feedback from interested parties. Since USB uses very similar device IDs and will require loading and unloading of LKMs whenever a device is connected or deconnected (USB supports hot-pluggable devices !), I would like to find a solution that applies to USB, too. It is for that reason, that I consider the real and CPU times required to identify the LKM ... My prefered solution would be 1), currently, since only a low number of PCI drivers exist. The file of PCI IDs could be automatically maintained by each drivers install target in the Makefile. Solution 2) also has its advantages. But it requires the creation of a new directory (under /lkm to allow for hard links to point there). It does not differ from 1) that much, actually ... 3+4+5) put all the information into the LKM binary, and need no further steps to be performed, besides moving the LKM in an agreed-upon directory. I do not like the overhead of looking into some 30 files, which easily might become 3 times as many, if more drivers are made available as LKM. If a file is created from the Any further ideas ? Regards, STefan From owner-freebsd-hackers Fri Jan 31 12:37:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10960 for hackers-outgoing; Fri, 31 Jan 1997 12:37:07 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10937; Fri, 31 Jan 1997 12:36:46 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id HAA30414; Sat, 1 Feb 1997 07:33:17 +1100 Date: Sat, 1 Feb 1997 07:33:17 +1100 From: Bruce Evans Message-Id: <199701312033.HAA30414@godzilla.zeta.org.au> To: asami@vader.cs.berkeley.edu, eivind@dimaga.com Subject: Re: Cc: hackers@freebsd.org, wollman@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Should I add something like > >.if exists(/usr/bin/net/if_var.h) >CFLAGS+= HAS_NET_IF_VAR_H >.endif > >to the Makefile in addition, perhaps? As long as I haven't got a "proper" >solution this is the best I can see. (This could be a loop over the >include-path instead of a direct test, but I cannot see this gaining much >on anything but very obscure systems.) Since the exposed user interface still contains kernel-internal data- structures and applications didn't need to know about this before, the correct solution is to merge back into , perhaps using a nested include. Ugh. Bruce From owner-freebsd-hackers Fri Jan 31 13:03:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA12258 for hackers-outgoing; Fri, 31 Jan 1997 13:03:49 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12245 for ; Fri, 31 Jan 1997 13:03:38 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id VAA23940; Fri, 31 Jan 1997 21:01:53 GMT Message-Id: <199701312101.VAA23940@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "Matthew A. Gessner" cc: hackers Subject: Re: dialup iijppp not letting line go? In-reply-to: Your message of "Thu, 30 Jan 1997 16:10:10 EST." <32F10E32.167EB0E7@aristar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Jan 1997 21:01:52 +0000 From: Brian Somers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [.....] > 1) Our ISP has dedicated 2 IP addresses for us: > 206.25.171.180 inetgw running ppp+pktAlias > 206.25.171.181 phoenix machine > > I want to be able to allow packets for phoenix coming in from the > outside into inetgw to get to phoenix. So far, I haven't been able to > make this happen. > > 2) I have assigned an alias to ed0: it has 2 addresses: > > 10.0.0.1 (local) > 206.25.171.181 (alias) With a netmask of 0xfffffffe I take it. > 3) phoenix's usual default gateway is inetgw, except when I want to > connect directly through my modem (which I do sometimes). > > > 4) I have a static route on phoenix: > route add 206.25.171.181 localhost > It gives an error when I start it but it does go through: it gives > me this: > > (/etc/ppp.orig)# netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 206.25.171.40 UGc 4 0 tun0 > 10 link#1 UC 1 0 > 10.0.0.4 0:40:5:1b:dc:44 UHLW 0 1587 ed0 > 530 > 10.0.0.16 0:40:5:37:7b:4b UHLW 0 132 ed0 > 127.0.0.1 127.0.0.1 UH 1 0 lo0 > 206.25.171 link#1 UC 1 0 > 206.25.171.40 206.25.171.68 UH 5 0 tun0 > 206.25.171.181 127.0.0.1 UGHS 1 0 lo0 > > I think I'm missing something somewhere. Can someone fill in the > missing pieces? Do I need to be running ipfw? Do I need to put > something else in my routing tables? So how does phoenix get to 206.25.171.68 ? What you want on phoenix is ifconfig ed0 inet 206.25.171.181 netmask 0xfffffffe alias route add 206.25.171.181 localhost route add default 206.25.171.180 and on inetgw ifconfig ed0 inet 206.25.171.180 netmask 0xfffffffe alias route add 206.25.181.180 localhost Assuming you've got forwarding turned on on inetgw and that your ISP is routing packets for both machines, things should be ok. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Fri Jan 31 13:04:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA12336 for hackers-outgoing; Fri, 31 Jan 1997 13:04:12 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12272 for ; Fri, 31 Jan 1997 13:03:52 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id UAA23897; Fri, 31 Jan 1997 20:40:20 GMT Message-Id: <199701312040.UAA23897@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: dkelly@hiwaay.net cc: Keith Mitchell , hackers@freebsd.org Subject: Re: lpd - remote printing with an output filter In-reply-to: Your message of "Thu, 30 Jan 1997 19:25:44 CST." <199701310127.TAA21295@nexgen.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Jan 1997 20:40:20 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Keith Mitchell writes: > > > > > Has anyone got any problems with me making this work ? It's always > > > irritated me ! It consists of two one-liners to printjob.c. > > > > No, but I would like to see it happen. I have several printers hanging off > > a HP JetDirect EX print server and there is no way to run an output filter > > on them. Consequently, the user must KNOW not to just blindly print to it. > > (sigh). > > I was looking thru the handbook the other night while setting up my > printer. Saw a comment that one way to implement a filter on a remote > printer was to make a "virtual" local printer with an "if" or "of" filter > of your choice which ultimately pipes the output right back into "lpr > -Preal_printer". Doesn't seem so hard? I must be missing something. This works - it's what I eventually did under Sequent-PTX. Never the less, it's a workaround for a deficiency that shouldn't really be there. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Fri Jan 31 14:34:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16317 for hackers-outgoing; Fri, 31 Jan 1997 14:34:34 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16309 for ; Fri, 31 Jan 1997 14:34:30 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id OAA26719 for ; Fri, 31 Jan 1997 14:20:09 -0800 (PST) Message-ID: <32F26FB5.167EB0E7@whistle.com> Date: Fri, 31 Jan 1997 14:18:29 -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: Suggested ehternet chips/cards? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We are looking at making or OEMing a dual ethernet card for some applications. This should be an ISA card for now.. is there a dual enet ISA card that people have had good experience with. Bare in mind that PIO as used in the NE2000 device can saturate an ISA bus with 2 cards leaving Nothing left over for the CPU or other devices.. (basically the CPU stalls for such a long time per inw() that two full ethernets ensures that there are about 0 cycles of CPU left for any other task. for this reason I'm especially interested in a card/chipset that would support DMA (even cheasy PC DMA), or at LEAST use a shared memeory pool (ISA memory ops are faster than PIO). This app is unfortunatly STUCK with ISA. (things will change however :) Suggestions? julian From owner-freebsd-hackers Fri Jan 31 14:41:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16636 for hackers-outgoing; Fri, 31 Jan 1997 14:41:19 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16631 for ; Fri, 31 Jan 1997 14:41:16 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id OAA19066; Fri, 31 Jan 1997 14:38:57 -0800 (PST) To: Mark Mayo cc: Chris Coleman , Julian Elischer , Terry Lambert , mcgovern@spoon.beta.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-reply-to: Your message of "Thu, 30 Jan 1997 16:33:31 EST." Date: Fri, 31 Jan 1997 14:38:56 -0800 Message-ID: <19062.854750336@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Perhaps you should contact Greg Lehey, he wrote a book called: > "Installing and Running FreeBSD", published by Walnut Creek. The book is 3 > hundered pages long, and came with my 2.1R CD-ROM. If you check out > http://www.cdrom.com/os/bsdbook.htm you'll notice that it's now called: > "The Complete FreeBSD". I'm assuming this is an updated version of the > book I have. Well, don't forget several things here. First off, while Greg'd work relies heavily on the Handbook and FAQ documents, it's still (C) Greg Lehey. You can't just take sections of his stuff and put it into a free, online version of the book unless you're sure it came from some other (C) FreeBSD, Inc. source or you have Greg's explicit permission. The Handbook and FAQ documents are copyrighted by FreeBSD, Inc. and freely redistributable on the same terms as the source code - you can use it for free or commercial purposes. Also, "The Complete FreeBSD" == "Installing and Running FreeBSD" with printed man pages, that's all. :-) Would this book be written in SGML and back-portable to the FreeBSD web page distribution, or what exactly? If the author finds SGML too constraining and retreats to HTML or some other format then I certainly understand and won't gritch about it, I'm just wondering. Jordan From owner-freebsd-hackers Fri Jan 31 14:45:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16766 for hackers-outgoing; Fri, 31 Jan 1997 14:45:01 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16751 for ; Fri, 31 Jan 1997 14:44:55 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id OAA27206 for ; Fri, 31 Jan 1997 14:37:23 -0800 (PST) Message-ID: <32F273BE.446B9B3D@whistle.com> Date: Fri, 31 Jan 1997 14:35: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: hackers@freebsd.org Subject: Gardner Buchanan where are you? Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Return-Path: Received: from localhost (localhost) by alpo.whistle.com (8.8.5/8.8.4) with internal id OAA27008; Fri, 31 Jan 1997 14:34:34 -0800 (PST) Date: Fri, 31 Jan 1997 14:34:34 -0800 (PST) From: Mail Delivery Subsystem Message-Id: <199701312234.OAA27008@alpo.whistle.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="OAA27008.854750074/alpo.whistle.com" Subject: Returned mail: User unknown Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --OAA27008.854750074/alpo.whistle.com The original message was received at Fri, 31 Jan 1997 14:12:03 -0800 (PST) from current1.whistle.com [207.76.205.22] ----- Mail could not be delivered due to errors for the following email addresses ----- ----- Transcript of session follows ----- ... while talking to freefall.freebsd.org.: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown --OAA27008.854750074/alpo.whistle.com Content-Type: message/delivery-status Reporting-MTA: dns; alpo.whistle.com Arrival-Date: Fri, 31 Jan 1997 14:12:03 -0800 (PST) Final-Recipient: rfc822; gardner@freefall.freebsd.org Action: failed Status: 2.0.0 Remote-MTA: DNS; freefall.freebsd.org Diagnostic-Code: SMTP; 250 OAA16309 Message accepted for delivery Last-Attempt-Date: Fri, 31 Jan 1997 14:34:34 -0800 (PST) --OAA27008.854750074/alpo.whistle.com Content-Type: message/rfc822 Return-Path: Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id OAA26541 for ; Fri, 31 Jan 1997 14:12:03 -0800 (PST) Sender: julian Message-ID: <32F26DD0.41C67EA6@whistle.com> Date: Fri, 31 Jan 1997 14:10:24 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Gardner Buchanan Subject: Re: PC/104 network computer References: <199701310250.VAA00282@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gardner Buchanan wrote: > > I ran FreeBSD 2.0.5 and 2.1 on an Ampro Littleboard. I had to > write my own Ethernet driver for the SMC 91C92 chip. The Datalux > "databrick" systems (sorry, you'll have to use Yahoo or whatever) > look quite nice. They aren't PC/104 though. They do also use the > SMC 91C92. My driver for it is on www.smc.com. We're looking at a 2nd generation ethernet card for our product. this chipis one we have breiefly considered.. Is you rdriver available for looking at (as part of our selection process) what do you think about that chip? the 4K of ram is a problem for me.. (UDP requests are 8K in NFS and result in back-to-back packets from fast machines..) comments? Thanks! julian --OAA27008.854750074/alpo.whistle.com-- From owner-freebsd-hackers Fri Jan 31 15:19:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA18349 for hackers-outgoing; Fri, 31 Jan 1997 15:19:26 -0800 (PST) Received: from eldorado.net-tel.co.uk ([193.122.171.253]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA18344; Fri, 31 Jan 1997 15:19:17 -0800 (PST) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id XAA21559; Fri, 31 Jan 1997 23:18:42 GMT Received: from "/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/" by net-tel.co.uk (Route400-RFCGate); Fri, 31 Jan 97 23:14:24 +0000 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 31 Jan 97 23:14:24 +0000 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 31 Jan 97 23:14:22 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Fri, 31 Jan 97 23:14:22 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:8655-970131231422-4E17] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Fri, 31 Jan 97 23:14:22 +0000 X400-Content-Identifier: Re: PCI LKM: How Message-Id: <"271-970131231413-CE37*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: se@freebsd.org Cc: hackers@freebsd.org In-Reply-To: <19970131213621.EQ13588@x14.mi.uni-koeln.de> Subject: Re: PCI LKM: How to find object file from PCI ID ... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Since USB uses very similar device IDs and will require loading and > unloading of LKMs whenever a device is connected or deconnected (USB > supports hot-pluggable devices !), I would like to find a solution > that applies to USB, too. It is for that reason, that I consider the > real and CPU times required to identify the LKM ... Note that CardBus is essentially PCI squeezed into a PCMCIA card shape, so this stuff will also affect pccardd in due course. As people have been posting in the past few days about re-writing pccardd and its config file format, perhaps this aspect needs considering sooner rather than later? From owner-freebsd-hackers Fri Jan 31 16:02:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA20846 for hackers-outgoing; Fri, 31 Jan 1997 16:02:17 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20833 for ; Fri, 31 Jan 1997 16:02:15 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.4/8.7.3) with SMTP id QAA04243 for ; Fri, 31 Jan 1997 16:02:13 -0800 (PST) Date: Fri, 31 Jan 1997 16:02:13 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org Subject: Nice sysctl variables to have... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 1 version number at the top of /usr/src that is updated with every CVS update. 1 kernel version number that is updated after every update in /usr/src/sys. From owner-freebsd-hackers Fri Jan 31 16:39:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA24770 for hackers-outgoing; Fri, 31 Jan 1997 16:39:33 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA24762 for ; Fri, 31 Jan 1997 16:39:30 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id TAA09632; Fri, 31 Jan 1997 19:37:31 -0500 (EST) Date: Fri, 31 Jan 1997 19:37:31 -0500 (EST) From: Mark Mayo To: "Jordan K. Hubbard" cc: Chris Coleman , Julian Elischer , Terry Lambert , mcgovern@spoon.beta.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: <19062.854750336@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 31 Jan 1997, Jordan K. Hubbard wrote: > > Perhaps you should contact Greg Lehey, he wrote a book called: > > "Installing and Running FreeBSD", published by Walnut Creek. The book is 3 > > hundered pages long, and came with my 2.1R CD-ROM. If you check out > > http://www.cdrom.com/os/bsdbook.htm you'll notice that it's now called: > > "The Complete FreeBSD". I'm assuming this is an updated version of the > > book I have. > > Well, don't forget several things here. > > First off, while Greg'd work relies heavily on the Handbook and FAQ > documents, it's still (C) Greg Lehey. You can't just take sections of > his stuff and put it into a free, online version of the book unless > you're sure it came from some other (C) FreeBSD, Inc. source or you > have Greg's explicit permission. The Handbook and FAQ documents are > copyrighted by FreeBSD, Inc. and freely redistributable on the same > terms as the source code - you can use it for free or commercial > purposes. Also, "The Complete FreeBSD" == "Installing and Running FreeBSD" > with printed man pages, that's all. :-) > That's sort of what I meant - sorry if it sounded like I was suggesting to just take Greg's work. I just thought that it wouldn't be too productive to produce "another" version of Greg's book - which is excellent, BTW - but to create a book on something else! Essentially, focus more on what you can do with FreeBSD after the installation. Check out http://www.bb.cc.wa.us/~chris/book.html for the preliminary Table of Contents > Would this book be written in SGML and back-portable to the FreeBSD > web page distribution, or what exactly? If the author finds SGML too > constraining and retreats to HTML or some other format then I > certainly understand and won't gritch about it, I'm just wondering. > I guess it's undecided so far - Chris is putting it together, and it's his idea. It's an open effort, with a consideration of possibly publishing a book -- we both noticed that the Sams.Net "How to make a Linux Internet Server" books are insanely popular.. We're planning on describing our own trials and tribulations of starting from scratch with FreeBSD and ending up with the amazing things you can accomplish with the OS. All ideas are welcome of course - take a look at the TOC and give Chris (or me) feedback! -mark ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) > Jordan > From owner-freebsd-hackers Fri Jan 31 16:40:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA24912 for hackers-outgoing; Fri, 31 Jan 1997 16:40:50 -0800 (PST) Received: from localhost (ppp2172.on.sympatico.ca [206.172.244.60]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA24904 for ; Fri, 31 Jan 1997 16:40:47 -0800 (PST) Received: (from gardner@localhost) by localhost (8.6.12/8.6.12) id TAA00174 for freebsd-hackers@FreeBSD.org; Fri, 31 Jan 1997 19:40:03 -0500 Date: Fri, 31 Jan 1997 19:40:03 -0500 Message-ID: X-Mailer: XFMail 0.3-beta [p0] on FreeBSD Reply-To: gbuchanan@sympatico.ca From: Gardner To: Subject: mset(), mclear(), msleep() and mwakeup(): Where? Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk 4.4BSD mmap(MAP_HASSEMAPHORE) supposedly gives the ability to use shared memory semaphores via mset(), mclear(), msleep() and mwakeup(). On page 491 and 492 Uresh Vahalia says that I can do these things. Marshall McKusick and friends are silent on the subject. So are the man pages, and find /usr/src/sys -name \*.\[ch] -exec grep msleep {} \; -print says nothing either. Is Vahalia lying to me? ============================================ Gardner Buchanan Ottawa, On From owner-freebsd-hackers Fri Jan 31 17:12:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA26306 for hackers-outgoing; Fri, 31 Jan 1997 17:12:01 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA26293 for ; Fri, 31 Jan 1997 17:11:58 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA03661; Fri, 31 Jan 1997 18:08:18 -0700 From: Terry Lambert Message-Id: <199702010108.SAA03661@phaeton.artisoft.com> Subject: Re: grp.h To: bde@zeta.org.au (Bruce Evans) Date: Fri, 31 Jan 1997 18:08:17 +73700 (MST) Cc: bde@zeta.org.au, proff@suburbia.net, hackers@freebsd.org In-Reply-To: <199701311807.FAA27476@godzilla.zeta.org.au> from "Bruce Evans" at Feb 1, 97 05:07:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> >It also looks like pwd.h also declares the uid and gid as ints > >> >instead of using the typedefs. > >> > >> Similarly, except already pollutes the namespace by including > >> . > > >See my pr for a numner of include fixes, this being one of them. > > They pollute the namespace unacceptably (to me). Otherwise I would > have made some of them years ago. Doesn't POSIX actually mandate "int" in some of the prototypes? 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 Jan 31 17:14:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA26415 for hackers-outgoing; Fri, 31 Jan 1997 17:14:13 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26405 for ; Fri, 31 Jan 1997 17:14:09 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA11999; Sat, 1 Feb 1997 11:43:55 +1030 (CST) From: Michael Smith Message-Id: <199702010113.LAA11999@genesis.atrad.adelaide.edu.au> Subject: Re: Suggested ehternet chips/cards? In-Reply-To: <32F26FB5.167EB0E7@whistle.com> from Julian Elischer at "Jan 31, 97 02:18:29 pm" To: julian@whistle.com (Julian Elischer) Date: Sat, 1 Feb 1997 11:43:54 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Elischer stands accused of saying: > We are looking at making or OEMing a dual ethernet card for some > applications. This should be an ISA card for now.. > is there a dual enet ISA card that people have had good experience with. I've actually never met a dual-ethernet ISA card. 'm presuming that space is the primary reason behind your wanting a dual-ISA card. Have you looked at using a couple of PC-104 ehthernets on a PC-104 piggyback board? (I realise that this may be prohibitively expensive). > for this reason I'm especially interested in a card/chipset that > would support DMA (even cheasy PC DMA), or at LEAST use a shared > memeory pool (ISA memory ops are faster than PIO). If you're going to DIY, I would recommend using one of the 8390 derivatives; these support lots of shared memory (up to 64K, although the 'ed' driver only currently supports 16K), and as anyone who has beaten on the 'ed' driver knows, they work rather well. NatSemi have a whole family of these parts; at least some of them have integrated line drivers as well (8390x family). Winbond (89C90x) and UMC also do similar parts. Terry might be able to find out whoever did the Artisoft AE-2 cards; they're a fairly legendary piece of hardware based on the 83902. Neither the SMC nor the similar Crystal parts have impressed me at all; they all have really small (~2K) buffers, possibly because they try to put the buffer RAM on-chip. > julian -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Fri Jan 31 17:16:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA26500 for hackers-outgoing; Fri, 31 Jan 1997 17:16:02 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA26473 for ; Fri, 31 Jan 1997 17:15:59 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA03677; Fri, 31 Jan 1997 18:14:33 -0700 From: Terry Lambert Message-Id: <199702010114.SAA03677@phaeton.artisoft.com> Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta To: bakul@torrentnet.com (Bakul Shah) Date: Fri, 31 Jan 1997 18:14:33 +73700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199701311808.NAA14384@chai.plexuscom.com> from "Bakul Shah" at Jan 31, 97 01:08:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > cat >x.cc < #include // include everything for simplicity. > #include > #include > > int main(int, char*[]) { > list list1; > for(int i = 0; i < 10; ++i) { > list1.push_back(rand()); > } > return 0; > } > EOF > > g++ -frepo -c x.cc > g++ -o x x.o > > The last step above should call the compiler to instantiate the > list class and everything should just work. No such luck. I > get: > > x.o: Undefined symbol `list::list(void)' referenced from text segment ********************* constructor > x.o: Undefined symbol `list::push_back(int const &)' referenced from text segment ********************************* type member > x.o: Undefined symbol `list::~list(void)' referenced from text segment ********************** destructor It can't call the constructor, used implicitly in the list1 auto declarator. It can't call the destructor, called implicily when the list1 auto storage goes out of scope of main(). It can't call the push_back member function, which is explicitly called. Clearly, the template class definition template class list ... { ... }; is not in scope. The header files you have included are apparently not sufficient. Perhaps you meant "List" instead of "list"??? 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 Jan 31 17:23:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA26773 for hackers-outgoing; Fri, 31 Jan 1997 17:23:29 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26766 for ; Fri, 31 Jan 1997 17:23:27 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id RAA10511; Fri, 31 Jan 1997 17:20:41 -0800 (PST) Date: Fri, 31 Jan 1997 17:20:41 -0800 (PST) From: Chris Coleman Reply-To: Chris Coleman To: Mark Mayo cc: "Jordan K. Hubbard" , Julian Elischer , Terry Lambert , mcgovern@spoon.beta.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 31 Jan 1997, Mark Mayo wrote: > On Fri, 31 Jan 1997, Jordan K. Hubbard wrote: SNIP > > purposes. Also, "The Complete FreeBSD" == "Installing and Running FreeBSD" > > with printed man pages, that's all. :-) I wrote an email to Greg, and mentioned what I was trying to do. He said he left alot of system administration stuff out of his latest book. So I thought I'd include some of that. Mostly I think I am aiming at the First time System administrators. Having access to Free Unix lands alot more of us in the position of System Administrator than any Commercial Unix Server ever could. I was one of them. SNIP > > > but to create a book on something else! Essentially, focus more on what > you can do with FreeBSD after the installation. > > Check out http://www.bb.cc.wa.us/~chris/book.html for the preliminary > Table of Contents I try to post something new each day, even if it is small. > > > > Would this book be written in SGML and back-portable to the FreeBSD > > web page distribution, or what exactly? If the author finds SGML too > > constraining and retreats to HTML or some other format then I > > certainly understand and won't gritch about it, I'm just wondering. > > I just got my first SGML book, "The Concise Companion". So I don't know much about SGML. I was going to worry about content first. But I am becoming fond of the Idea that this is an On-line Book. So I am open to suggestions. > I guess it's undecided so far - Chris is putting it together, and it's his > idea. It's an open effort, with a consideration of possibly publishing a > book -- we both noticed that the Sams.Net "How to make a Linux Internet > Server" books are insanely popular.. We're planning on describing our own > trials and tribulations of starting from scratch with FreeBSD and ending > up with the amazing things you can accomplish with the OS. All ideas are > welcome of course - take a look at the TOC and give Chris (or me) > feedback! > > -mark Linux has too many books. I would like to see a few other titles for FreeBSD generated in concert to this one. > > ---------------------------------------------------------------------------- > Mark Mayo mark@quickweb.com > RingZero Comp. http://vinyl.quickweb.com/mark > ---------------------------------------------------------------------------- > "I prefer tongue-tied knowledge to ignorant loquacity." > Cicero (106-43 B.C.) > > > > > > Jordan > > > > Christopher J. Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html Death is life's way of telling you you're fired. From owner-freebsd-hackers Fri Jan 31 17:38:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA27443 for hackers-outgoing; Fri, 31 Jan 1997 17:38:24 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA27438 for ; Fri, 31 Jan 1997 17:38:20 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA12981; Sat, 1 Feb 1997 01:38:03 GMT Date: Sat, 1 Feb 1997 10:38:03 +0900 (JST) From: Michael Hancock To: "Ron G. Minnich" cc: Andrew.Gordon@net-tel.co.uk, freebsd-hackers@FreeBSD.ORG Subject: Re: Re(2): Using rfork() / threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The Vahalia book mentions shared memory locks for 4.4BSD that worked essentially the same way. They were named mset, mwait, or something like that. Fastlock sounds cool, but shared memory locks are supposed to be fast. Instead of naming things like FastLock or TurboLock we should name them according to their function. i.e. synchronization primitives to use in shared memory. I prefer the mxxx conventions to categorize it with the mmap calls. On the otherhand, since rlock came from Plan 9 maybe we should look at Plan 9 synchronization. Regards, Mike Hancock On Fri, 31 Jan 1997, Ron G. Minnich wrote: > well, i have another thing that was (ah well) offered to freebsd called > fastlock(). Fastlock was two things: > 1) test and set, which ran at memory bandwidth > 2) a system call to be called only if the lock failed, > which ran at system call speeds. > > Fastlock is called with a pointer to shared data. In the general case > locks do not collide. So the cost of fastlock is the cost of a tset. In > the case of collision, the high-order bit was set (tset(mem, 0x80000000) > and the fastlock system call was called. The process waiting on the lock then > slept. > > The owner of the lock can do one of two things when it frees the lock: > 1) if no collide (mem&0x80000000 == 0), just clear the lock > 2) otherwise, clear the lock and call a system call which wakes up the first > sleeper on the lock. > > End result: very very fast locks, quite a bit faster than anything else. > > ron > > Ron Minnich |"Failure is not an option" -- Gene Kranz > rminnich@sarnoff.com | -- except, of course, on Microsoft products > (609)-734-3120 | > ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html > > -- 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 Jan 31 18:33:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA29393 for hackers-outgoing; Fri, 31 Jan 1997 18:33:34 -0800 (PST) Received: from bsd.fs.bauing.th-darmstadt.de (bsd.fs.bauing.th-darmstadt.de [130.83.63.241]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA29382 for ; Fri, 31 Jan 1997 18:33:30 -0800 (PST) Received: from [195.52.251.6] (apfel.nacamar.de [195.52.251.6]) by bsd.fs.bauing.th-darmstadt.de (8.8.2/8.8.2) with ESMTP id DAA13725; Sat, 1 Feb 1997 03:32:55 +0100 (MET) X-Sender: freebsd@mail.nacamar.de Message-Id: In-Reply-To: References: <199701292132.WAA21498@pat.idt.unit.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 1 Feb 1997 03:32:14 +0100 To: Jaye Mathisen From: Michael Beckmann Subject: Re: 2.2-BETA: options MAXMEM not working (fwd) Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hmmm, I have a 2.2 box with 256MB RAM, and it sees it all just fine using >the kernel option. My kernel has the ccd enabled. I think there was another problem report about an interference with ccd... Cheers, Michael From owner-freebsd-hackers Fri Jan 31 18:33:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA29412 for hackers-outgoing; Fri, 31 Jan 1997 18:33:39 -0800 (PST) Received: from bsd.fs.bauing.th-darmstadt.de (bsd.fs.bauing.th-darmstadt.de [130.83.63.241]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA29392 for ; Fri, 31 Jan 1997 18:33:33 -0800 (PST) Received: from [195.52.251.6] (apfel.nacamar.de [195.52.251.6]) by bsd.fs.bauing.th-darmstadt.de (8.8.2/8.8.2) with ESMTP id DAA13722; Sat, 1 Feb 1997 03:32:51 +0100 (MET) X-Sender: freebsd@mail.nacamar.de Message-Id: In-Reply-To: <199701292132.WAA21498@pat.idt.unit.no> References: Your message of "Wed, 29 Jan 1997 19:36:58 +0100 (MET)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 1 Feb 1997 03:29:57 +0100 To: Tor Egge , petzi@mail.nacamar.de From: Michael Beckmann Subject: Re: 2.2-BETA: options MAXMEM not working (fwd) Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 22:32 Uhr +0100 29.1.1997, Tor Egge wrote: >> OK, after having built a couple more kernels, I found out that the MAXMEM >> option does not work for me when set to over 128 MB. I now run a kernel >> that uses only 128 MB, though my machine has 192 MB and will have 256 at >> the end of the week. Has this problem been fixed in kernels subsequent to >> 2.2-BETA ? I was using 160 MB just fine with FreeBSD 2.1.5. >> >> Cheers, >> >> Michael > >Is bounce buffer support disabled ? It uses some kernel virtual address space. It was enabled, I disabled it now. >If that does not help, you may want to look at PR kern/1880. I applied your patches. The kernel now recognises all the RAM. I cannot say which of the two changes helped, however, as I made the changes at once :-) Cheers, Michael From owner-freebsd-hackers Fri Jan 31 19:24:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA01357 for hackers-outgoing; Fri, 31 Jan 1997 19:24:33 -0800 (PST) Received: from Clifford.LiveNet.Net (root@Clifford.LiveNet.Net [206.156.5.13]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA01351 for ; Fri, 31 Jan 1997 19:24:28 -0800 (PST) Received: from samantha (Ice.Stormer.LiveNet.Net [206.156.5.140]) by Clifford.LiveNet.Net (8.7.6/8.6.9) with ESMTP id WAA08803 for ; Fri, 31 Jan 1997 22:30:24 -0500 (EST) Message-Id: <199702010330.WAA08803@Clifford.LiveNet.Net> From: "Joseph I. Arias" To: Date: Fri, 31 Jan 1997 22:26:41 -0800 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have Win95 installed in my computer, but I'm booting the system from the boot disk that I made with rawrite boot4.flp and I also tried boot.flp. I formated the drive and just installed dos 6.22 on it and still getting this same message. Thanks Joe ---------- : From: J Wunsch : To: Joseph : Cc: hackers@FreeBSD.ORG : Subject: Re: Error Message : Date: Friday, January 31, 1997 5:07 AM : : As Joseph wrote: : : > Hi I downloaded all of release 2.1.6 into my DOS disk e:\freebsd and I : > tried to do the DOS partition install but it keeps giving me this error: : > : > Error mounting /dev/wd1s2 on /DOS invalid argument 22 : : What kind of DOS filesystem is it? The DOS filesystem code of FreeBSD : (which is known to be a little rusty) doesn't seem to recognize it as : a valid DOS filesystem. That's what the `invalid argument' stands : for. : : -- : 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 Jan 31 19:46:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA02076 for hackers-outgoing; Fri, 31 Jan 1997 19:46:54 -0800 (PST) Received: from siesta.cs.wustl.edu (nw1@siesta.cs.wustl.edu [128.252.165.3]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA02071 for ; Fri, 31 Jan 1997 19:46:51 -0800 (PST) Received: from localhost by siesta.cs.wustl.edu (SMI-8.6/ECL-J1.00) id VAA26518; Fri, 31 Jan 1997 21:46:42 -0600 Message-Id: <199702010346.VAA26518@siesta.cs.wustl.edu> To: hackers@freebsd.org cc: John Birrell From: Nanbor Wang Subject: pthread library on FreeBSD Date: Fri, 31 Jan 1997 21:46:41 -0600 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, Thanks for your help I had made some progress on porting ACE to FreeBSD. However, I encountered another obstacle. There seems to be some pthread functions unimplemented. After looking to its source code, here is a list of functions that are missing and will be nice if ACE can make use of them. pthread_mutexattr_destroy: pthread_condattr_init: pthread_condattr_destroy: pthread_attr_setstackaddr: pthread_attr_setdetachstate: These are nowhere to be found. pthread_cleanup_push: pthread_cleanup_pop: Have underlying functions _thread_cleanup_push and _thread_cleanup_pop but there is no API functions. (Possibly implemented?) Does anyone know this is because that pthread lib (for BSD) itself is still ongoing or just because the pthread lib source files in FreeBSD are simply outdated? I am running -current as of 1/26. Under either circumstance, is there anyway to get around this? TIA. Later, _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Nanbor Wang http://www.cs.wustl.edu/~nw1/ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ From owner-freebsd-hackers Fri Jan 31 19:47:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA02102 for hackers-outgoing; Fri, 31 Jan 1997 19:47:01 -0800 (PST) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA02094 for ; Fri, 31 Jan 1997 19:46:59 -0800 (PST) Received: (from tony@localhost) by nlanr.net (8.7.3/8.7.3) id TAA01593 for hackers@freebsd.org; Fri, 31 Jan 1997 19:46:59 -0800 (PST) From: Tony Sterrett Message-Id: <199702010346.TAA01593@nlanr.net> Subject: MAXMEM question To: hackers@freebsd.org Date: Fri, 31 Jan 1997 19:46:59 +73600 (PST) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all: I am trying to allocate 1Mb bytes of memory for a special custom device. I will need to allocate about 16Mb and they must occurs in 1Mb contigous blocks. I have three approaches and I'd like know your (all of you) opinon(s): 1. I reduce that amount of memory bsd thinks I have by changing the value in vm_init.c vm_set_page_size(); virtual_avail = vm_page_startup(avail_start, avail_end, virtual_avail); and reducing the avail_end and then somehow mapping this space into user space. 2. using vm_page_alloc_contig(size, low, high, alignment) to get the memory. I've been trying to use this function to get the memory but I've had no luck doing it, maybe I'm parameters I'm addr = (void *) vm_page_alloc_contig (1048576,25165872, 0x1fffffe, 4096) ; is how I did it. 3. Some change change to locore.s to set aside. So what do you dudes Cheers, Tony From owner-freebsd-hackers Fri Jan 31 20:14:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA02899 for hackers-outgoing; Fri, 31 Jan 1997 20:14:28 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA02890 for ; Fri, 31 Jan 1997 20:14:21 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id BAA29834; Sat, 1 Feb 1997 01:34:22 GMT Message-Id: <199702010134.BAA29834@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: iman triwahyudi cc: hackers@FreeBSD.ORG Subject: Re: packet driver In-reply-to: Your message of "Fri, 31 Jan 1997 21:45:58 +0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Feb 1997 01:34:22 +0000 From: Brian Somers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Anyone know how to get radio packet driver for FreeBSD ? > > > Cheers > Iman Sorry, but there's no such thing as a "packet driver" for FreeBSD. A packet driver is a piece of DOS TSR software that sits on a software interrupt, providing an API to a piece of hardware. Perhaps you mean "Is there a radio driver for FreeBSD" ? Hmm, dunno ! Sorry ! -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Fri Jan 31 20:15:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA02976 for hackers-outgoing; Fri, 31 Jan 1997 20:15:55 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA02971 for ; Fri, 31 Jan 1997 20:15:50 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id EAA04555; Sat, 1 Feb 1997 04:09:48 GMT Message-Id: <199702010409.EAA04555@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: brian@utell.co.uk (Brian Somers), terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net Subject: Re: ipdivert & masqd FIXED ! In-reply-to: Your message of "Thu, 30 Jan 1997 17:56:49 PST." <199701310156.RAA00251@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Feb 1997 04:09:47 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > I've essentially got the following: > > > > > > > > ---------------- ---------------------- > > > > | 10.0.10.2 |------------------| 10.0.10.1 | > > > > ---------------- | | > > > > | 10.0.1.254 (ed0) | > > > > ---------------------- > > > > | > > > > | > > > > ----------------- | > > > > | 10.0.1.1 |--------------------------- > > > > ----------------- [.....] > > Maybe the problem is with the forwarding code - where ip_input() > > calls ip_output(). I didn't realize this happened ! Surely, we > > should be remembering and zero'ing ip_divert_ignore before > > calling ip_output here, and restoring it afterwards. I'll check this > > when I get home this evening ! > > Yes, ip_input() calls ip_output() indirectly when forwarding packets. > You actually want to *not* zero ip_divert_ignore in this case in order > to realize the intended semantics of the socket -- the loop avoidance > is supposed to avoid all diversion back to the port, even if the packet > passes through ipfw twice, on the way "in" and on the way "out". > It turns out that this was the problem ! If 10.0.1.1 pings 10.0.1.254, ip_input() is called. This diverts to masqd and then gets re-injected. The second time around, ip_input() ignores the divert (correctly) but calls ip_output(). ip_output() incorrectly ignores the divert socket - so the packet mangling doesn't get done ! I've altered things slightly so that ip_divert_ignore gets zero'd as soon as it's been used in both ip_input() and ip_output(). Patches are available on www.awfulhak.demon.co.uk. Also, ip_divert_ignore is set in ip_divert.c irrespective of whether sin->sin_port is around.... I think this may be wrong, (it works, but for the wrong reasons) - ICMPs break with the check left in ! I'm not sure why, but this has fixed the other problem too - I had a bug in my test program, so maybe your suggested patch from a few days ago worked too - sorry if this is the case. Anyway, can you have a look at things and see if you want them commited - or see if you want me committed ;) There's a version of masqd on www.awfulhak.demon.co.uk too - natd-1.1 is "on the verge" I believe and it's much more functional than masqd, so I suspect natd will live and masqd will die (RIP). Cheers. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Fri Jan 31 20:32:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA03418 for hackers-outgoing; Fri, 31 Jan 1997 20:32:29 -0800 (PST) Received: from ami.tom.computerworks.net (root@AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA03413 for ; Fri, 31 Jan 1997 20:32:27 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #1) id m0vqX7n-0021lDC; Fri, 31 Jan 97 23:32 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id WAA26914; Fri, 31 Jan 1997 22:28:47 -0600 Date: Fri, 31 Jan 1997 22:28:47 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199702010428.WAA26914@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: pib comments. Newsgroups: taronga.freebsd.hackers In-Reply-To: References: <199701040417.OAA22838@genesis.atrad.adelaide.edu.au> Organization: none Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , Jaye Mathisen wrote: >My frustration with TCL/TK was related to performance in general, not your >app. I've tried TKdesk, and it crawls, and zircon runs like a dog as >well. TkDesk is slow, barely usable under Tcl 7.x, but it is usable on my 486/50. Zircon is quite snappy, thank you very much, again on the same 486/50. Under Tcl 8.0a1 WebTk, another program about as slow as TkDesk under 7.x, is pretty damn fast. If your problem is Tcl speed, then try it with the 8.0 alpha. I suspect that you've got a problem with the Tk side, though, since your box SHOULD be fast enough to make my head explode. From owner-freebsd-hackers Fri Jan 31 20:43:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA03685 for hackers-outgoing; Fri, 31 Jan 1997 20:43:59 -0800 (PST) Received: from gargoyle.bazzle.com (gargoyle.bazzle.com [206.103.246.190]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA03680 for ; Fri, 31 Jan 1997 20:43:52 -0800 (PST) Received: from gargoyle.bazzle.com (net2.bazzle.com [206.103.246.189]) by gargoyle.bazzle.com (8.8.4/8.6.12) with SMTP id XAA16136; Fri, 31 Jan 1997 23:42:36 -0500 (EST) Date: Fri, 31 Jan 1997 23:42:36 -0500 (EST) From: "Eric J. Chet" To: Terry Lambert cc: Bakul Shah , hackers@FreeBSD.ORG Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta In-Reply-To: <199702010114.SAA03677@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 31 Jan 1997, Terry Lambert wrote: > > cat >x.cc < > #include // include everything for simplicity. > > #include > > #include > > > > int main(int, char*[]) { > > list list1; > > for(int i = 0; i < 10; ++i) { > > list1.push_back(rand()); > > } > > return 0; > > } > > EOF > > > > g++ -frepo -c x.cc > > g++ -o x x.o > > > > The last step above should call the compiler to instantiate the > > list class and everything should just work. No such luck. I > > get: > > > > x.o: Undefined symbol `list::list(void)' referenced from text segment > ********************* constructor > > x.o: Undefined symbol `list::push_back(int const &)' referenced from text segment > ********************************* type member > > x.o: Undefined symbol `list::~list(void)' referenced from text segment > ********************** destructor > > It can't call the constructor, used implicitly in the list1 auto > declarator. It can't call the destructor, called implicily when the > list1 auto storage goes out of scope of main(). It can't call the > push_back member function, which is explicitly called. > > > Clearly, the template class definition > > template > class list ... { > ... > }; > > is not in scope. The header files you have included are apparently > not sufficient. > > Perhaps you meant "List" instead of "list"??? > Hello The -frepo patches don't work on our version of the g++ and ld. I assume ld is the problem. I haven't had the time to take a look to see what needs to be changed. The -frepo patch from Cygnus when applied, should create a set of *.ii one for each source file complied from g++. The *.ii files specify all templates that need to be instantiated before linking can take place. I believe there is a collect2 module that performs the instantiations task. I do know that if you build g++ with John Polstra's ELF patches and the -frepo patches. Then template repository works as advertised. On the other hand, the only thing you lose by not having the repository with our native compiler is executable size. The compiler will instantiated every template used in a object file and include it in that object file. Meaning, you can have duplicate template instantiations across different object files. Eric J. Chet - ejc@naserver1.cb.lucent.com - ejc@bazzle.com > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Fri Jan 31 20:55:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA03952 for hackers-outgoing; Fri, 31 Jan 1997 20:55:14 -0800 (PST) Received: from hydrogen.nike.efn.org (metriclient-11.uoregon.edu [128.223.172.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA03945 for ; Fri, 31 Jan 1997 20:55:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.4/8.8.4) with SMTP id UAA28220; Fri, 31 Jan 1997 20:53:37 -0800 (PST) Date: Fri, 31 Jan 1997 20:53:37 -0800 (PST) From: John-Mark Gurney Reply-To: John-Mark Gurney To: Terry Lambert cc: hackers@freefall.freebsd.org Subject: Re: performance puzzler In-Reply-To: <199701311738.KAA03009@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 31 Jan 1997, Terry Lambert wrote: > > The puzzling thing comes when I try to run the test at home on my AMD > > 486-120, running 2.1.0-RELEASE. It runs the test in 0.6 milliseconds!! > > Divide each clock speed by increasing integer values starting with 1 > until the result is less than or equal to 33. This is your max bus > speed possible for the system. An easy way to do this is magnitude > based arithmatic (yes, I own a slide-rule): > > exp(log(120)%log(33)) = 30 > exp(log(66)%log(33)) = 33 > > Your bus on the 120 is 3MHz slower than the bus on the 66. What you > are doing is not I/O bound, it is CPU bound. umm... this usually isn't true... most of the non 33mhz bus speeds (for 486 based chips) are actually 40 mhz or 50mhz... the amd-486/120dx4 is actually a 40mhz bus multiplied by 3... it's kinda like the Intel 486/100dx4... the chip is actually 3x bus speed (33mhz)... like AMD makes a 5x86/133... if you get the ADZ version you can usually over clock it to a 160... 40mhz x 4... the reason being is the ADZ's encasing is rated at 85C unlike the ADW that's only 55C... sure it's taking a chance, but it's a nice boost on a vlb based machine :)... John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Fri Jan 31 21:15:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA04457 for hackers-outgoing; Fri, 31 Jan 1997 21:15:09 -0800 (PST) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA04452 for ; Fri, 31 Jan 1997 21:15:05 -0800 (PST) Received: from w2xo.pgh.pa.us (localhost [127.0.0.1]) by w2xo.pgh.pa.us (8.8.4/8.8.4) with SMTP id AAA04859; Sat, 1 Feb 1997 00:14:53 -0500 (EST) Message-ID: <32F2D14D.446B9B3D@w2xo.pgh.pa.us> Date: Sat, 01 Feb 1997 00:14:53 -0500 From: Jim Durham Organization: Dis- X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: Brian Somers CC: iman triwahyudi , hackers@FreeBSD.ORG Subject: Re: packet driver References: <199702010134.BAA29834@awfulhak.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian Somers wrote: > > > > > Anyone know how to get radio packet driver for FreeBSD ? > > > > > > Cheers > > Iman > > Sorry, but there's no such thing as a "packet driver" for FreeBSD. A packet > driver is a piece of DOS TSR software that sits on a software interrupt, > providing an API to a piece of hardware. Perhaps you mean "Is there a > radio driver for FreeBSD" ? > > Hmm, dunno ! Sorry ! > -- There is no "packet driver" per se, but I have a modified version of Phil Karn's "Net" software here that will allow ham AX25 and tcp/ip networking through a serial port and TNC. You can also nail up a slip connection through a PTY to the FreeBSD kernel, which will allow NET to talk to the ethernet interface used by FreeBSD and server as a router from the RF network to internet. There are a couple other packages that will also do this. TNOS and WAMPES, both variations of Phil's code. TNOS has a web page, I believe. -Jim Durham From owner-freebsd-hackers Fri Jan 31 21:46:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA05603 for hackers-outgoing; Fri, 31 Jan 1997 21:46:47 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA05592 for ; Fri, 31 Jan 1997 21:46:40 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id QAA15037; Sat, 1 Feb 1997 16:48:10 +1100 (EST) Date: Sat, 1 Feb 1997 16:48:10 +1100 (EST) From: "Daniel O'Callaghan" To: Brian Somers cc: iman triwahyudi , hackers@FreeBSD.ORG Subject: Re: packet driver In-Reply-To: <199702010134.BAA29834@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 1 Feb 1997, Brian Somers wrote: > > > > Anyone know how to get radio packet driver for FreeBSD ? > > Sorry, but there's no such thing as a "packet driver" for FreeBSD. A packet > driver is a piece of DOS TSR software that sits on a software interrupt, > providing an API to a piece of hardware. Perhaps you mean "Is there a > radio driver for FreeBSD" ? The question is "Is there a packet radio driver?", i.e. a driver for packet radio. There is a driver in Linux, but not for FreeBSD, I believe. Danny From owner-freebsd-hackers Fri Jan 31 22:44:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA07408 for hackers-outgoing; Fri, 31 Jan 1997 22:44:34 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA07403 for ; Fri, 31 Jan 1997 22:44:31 -0800 (PST) Received: from colint.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vqZBR-0008xYC; Fri, 31 Jan 97 22:44 PST X-ROUTED: Sat, 1 Feb 1997 00:45:52 -0600 Received: from default [207.112.160.129] by colint.com with smtp id AACNBMEF ; Sat, 1 Feb 1997 00:45:28 -0600 Message-ID: <32F2E611.7ED3@colint.com> Date: Sat, 01 Feb 1997 00:43:30 -0600 From: Michel Pelletier Reply-To: mike@colint.com Organization: Collective Intelligence, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk subscribe From owner-freebsd-hackers Fri Jan 31 22:47:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA07480 for hackers-outgoing; Fri, 31 Jan 1997 22:47:53 -0800 (PST) Received: from alpha.risc.org (ppp-149.isdn-3.ican.net [206.231.241.149]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA07475 for ; Fri, 31 Jan 1997 22:47:50 -0800 (PST) Received: from localhost (taob@localhost) by alpha.risc.org (8.8.4/8.8.4) with SMTP id BAA05794 for ; Sat, 1 Feb 1997 01:47:47 -0500 (EST) Date: Sat, 1 Feb 1997 01:47:46 -0500 (EST) From: Brian Tao To: FREEBSD-HACKERS-L Subject: Mounting CD-ROM when data not on first track Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On a whim, I bought the "Star Trek: First Contact" soundtrack today on CD. It has a filesystem on track 14 of the disc with Quicktime trailers of the movie. Trying to mount this on FreeBSD 2.2-BETA gives me this error: cd0(ncr0:6:0): BLANK CHECK req sz: 16 (decimal) asc:64,0 Illegal mode for this track cd0(ncr0:6:0): error code 0 I presume this is because mount_cd9660 only looks for data on the first track of the CD? How would I mount the data track from such a CD? This is the toc dump from cdcontrol: Starting track = 1, ending track = 14, TOC size = 122 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 4:21.27 0 19452 audio 2 4:21.27 2:18.40 19452 10240 audio 3 6:37.67 2:12.05 29692 9755 audio 4 8:47.72 2:45.15 39447 12240 audio 5 11:31.12 3:22.72 51687 15072 audio 6 14:52.09 4:02.67 66759 18067 audio 7 18:53.01 2:24.60 84826 10710 audio 8 21:15.61 4:49.50 95536 21575 audio 9 26:03.36 7:10.57 117111 32157 audio 10 33:12.18 5:57.05 149268 26630 audio 11 39:07.23 5:28.32 175898 24482 audio 12 44:33.55 4:27.00 200380 19875 audio 13 48:58.55 4:57.37 220255 22162 audio 14 53:54.17 18:30.36 242417 83136 data 170 72:22.53 - 325553 - - -- Brian Tao (BT300, taob@risc.org) "Though this be madness, yet there is method in't" From owner-freebsd-hackers Fri Jan 31 22:52:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA07601 for hackers-outgoing; Fri, 31 Jan 1997 22:52:40 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA07596 for ; Fri, 31 Jan 1997 22:52:36 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vqZGu-0002bc-00; Fri, 31 Jan 1997 23:49:56 -0700 To: Brian Somers Subject: Re: Setting MTU from userland ppp Cc: Terry Lambert , dk+@ua.net, shocking@mailbox.uq.edu.au, freebsd-hackers@freebsd.org In-reply-to: Your message of "Thu, 30 Jan 1997 23:42:32 GMT." <199701302342.XAA20718@awfulhak.demon.co.uk> References: <199701302342.XAA20718@awfulhak.demon.co.uk> Date: Fri, 31 Jan 1997 23:49:56 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199701302342.XAA20718@awfulhak.demon.co.uk> Brian Somers writes: : > > Don't use 256 as your MTU. (violates the RFC) : > : > Any chance of having the software *enforce* the RFC, then? : : I'll have a look at the RFC. It currently checks that 100 <= M[TR]U <= 2000. Can someone point out where in the RFCs it says that an MTU size of 256 is illegal? The closes that I've seen is a statement in the IP RFC that says that a remote side must be able to asssemble a packet of at least 576 bytes, but does not disallow smaller fragment sizes. Warner From owner-freebsd-hackers Fri Jan 31 23:03:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA07896 for hackers-outgoing; Fri, 31 Jan 1997 23:03:52 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA07891 for ; Fri, 31 Jan 1997 23:03:45 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vqZRe-0002bz-00; Sat, 1 Feb 1997 00:01:02 -0700 To: Brian Somers Subject: Re: packet driver Cc: iman triwahyudi , hackers@freebsd.org In-reply-to: Your message of "Sat, 01 Feb 1997 01:34:22 GMT." <199702010134.BAA29834@awfulhak.demon.co.uk> References: <199702010134.BAA29834@awfulhak.demon.co.uk> Date: Sat, 01 Feb 1997 00:01:02 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702010134.BAA29834@awfulhak.demon.co.uk> Brian Somers writes: : > Anyone know how to get radio packet driver for FreeBSD ? : Sorry, but there's no such thing as a "packet driver" for FreeBSD. I think you parsed this wrong. How do I get a radio-packet driver for FreeBSD? Eg, a driver for one of the many packet-radio cards that are out there... Warner From owner-freebsd-hackers Fri Jan 31 23:12:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA08329 for hackers-outgoing; Fri, 31 Jan 1997 23:12:03 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA08306 for ; Fri, 31 Jan 1997 23:12:00 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id SAA14153; Sat, 1 Feb 1997 18:09:43 +1100 Date: Sat, 1 Feb 1997 18:09:43 +1100 From: Bruce Evans Message-Id: <199702010709.SAA14153@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: grp.h Cc: hackers@freebsd.org, proff@suburbia.net Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Doesn't POSIX actually mandate "int" in some of the prototypes? No. It says that applications may redeclare the standard functions using a declaration that is lexically identically to the one in the standard. This means that either all arg types must be the same as their default promotions, or the compiler must be ANSI. BSD requires the latter. For example, the following strictly POSIX conformant program does not compile if the compiler isn't ANSI: --- #define _POSIX_SOURCE 1 #include #include mode_t umask(mode_t); int main(void) { return 1; } ---- because mode_t is u_int16_t (which promotes to int if ints have 16 bits and to unsigned otherwise) and has declared umask() incompatibly as `mode_t umask();' if the compiler is non-ANSI. This also prevents from declaring umask() as `mode_t umask(promotion_of_u_int16_t);' which may be required for the __P(()) hack to actually work - this would break the above program for ANSI compilers. Bruce From owner-freebsd-hackers Sat Feb 1 00:15:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA10150 for hackers-outgoing; Sat, 1 Feb 1997 00:15:18 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA10132 for ; Sat, 1 Feb 1997 00:14:48 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id TAA06303; Sat, 1 Feb 1997 19:15:33 +1100 (EST) From: Julian Assange Message-Id: <199702010815.TAA06303@profane.iq.org> Subject: #include dependencies In-Reply-To: <199701311937.GAA29276@godzilla.zeta.org.au> from Bruce Evans at "Feb 1, 97 06:37:11 am" To: bde@zeta.org.au (Bruce Evans) Date: Sat, 1 Feb 1997 19:15:32 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Most of the #include changes are wrong. > > Most of the headers are only used in the kernel. Kernel sources > follow the convention of including or > before any other header. > > Bruce I'm aware of this, this is why you see a number of #ifndef KERNEL. I strongly philosophically disagree with the need for this but have done so out of what appears to be (foolish imho) tradition. At first I thought perhaps this step was due to cross-compilation needs requiring different sys/types.h files. This appears not to be the case and many kernel .c files rely on the fact that sys/types.h is included in sys/libkern.h. In terms of name-space pollution, the only difference between polluting the name-space from the .C file compared to polluting it from the included file, is that the name space *continues* to be polluted even when the included file is changed to no longer be dependent on the pollution. Do not be saying that this is a good thing as it provides a continuity of name-space pollution in the .C file. C code should only explicity resolve those include files which *it* needs to define datatypes that it *directly* uses. Anything else is inherently unstable across time and across changing environments. I have only resolved mandatory dependencies; i.e those dependencies required for gcc to parse the include file without error, which any C code that uses the include file MUST have resolved, one way or the other, in order to compile at all. You state "most of the headers are only used in the kernel". While you may be correct statistically, this is not a view I can endorse. /dev/kmem makes a mockery out of these assumptions and a not insignificant number of user level programs can and do parse kernel data structures just this way. As time goes by and boundaries between user-level programs the kernel break down we can only expect the cross-transfer of data-structures to increase. Personally I believe the only #ifdef KERNEL we should be seeing is around externs and function definitions, because that is where the only REAL difference between user-level and kernel-level include code dependencies should be occurring. I did not enforce my philosophy blindly with these patches. You may recall I started a weeks debate on this issue and at the end if it, the concensus appeared to be strongly supportive of the direction I have taken. It wasn't philosophy driving engineering, though it has certainly dictated the path I chose. The simple impetus was that code which works perfectly well on all other major platforms refuses to compile under FreeBSD for the very reason we have been discussing. From very large, well supported and well ported user-level programs like scilab to kernel/lkm code such as ipfilter. I believe the -hackers archive bears me out on this. Comments? Cheers, Julian From owner-freebsd-hackers Sat Feb 1 00:43:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA10965 for hackers-outgoing; Sat, 1 Feb 1997 00:43:59 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA10960 for ; Sat, 1 Feb 1997 00:43:57 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id AAA13973; Sat, 1 Feb 1997 00:43:23 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma013969; Sat Feb 1 00:43:03 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id AAA06137; Sat, 1 Feb 1997 00:43:02 -0800 (PST) From: Archie Cobbs Message-Id: <199702010843.AAA06137@bubba.whistle.com> Subject: Re: ipdivert & masqd FIXED ! In-Reply-To: <199702010409.EAA04555@awfulhak.demon.co.uk> from Brian Somers at "Feb 1, 97 04:09:47 am" To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Sat, 1 Feb 1997 00:43:01 -0800 (PST) Cc: archie@whistle.com, brian@utell.co.uk, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Yes, ip_input() calls ip_output() indirectly when forwarding packets. > > You actually want to *not* zero ip_divert_ignore in this case in order > > to realize the intended semantics of the socket -- the loop avoidance > > is supposed to avoid all diversion back to the port, even if the packet > > passes through ipfw twice, on the way "in" and on the way "out". > > > > It turns out that this was the problem ! > > If 10.0.1.1 pings 10.0.1.254, ip_input() is called. This diverts to masqd > and then gets re-injected. The second time around, ip_input() ignores the > divert (correctly) but calls ip_output(). ip_output() incorrectly ignores > the divert socket - so the packet mangling doesn't get done ! > > I've altered things slightly so that ip_divert_ignore gets zero'd as soon > as it's been used in both ip_input() and ip_output(). Patches are available > on www.awfulhak.demon.co.uk. Also, ip_divert_ignore is set in ip_divert.c > irrespective of whether sin->sin_port is around.... I think this may be wrong, > (it works, but for the wrong reasons) - ICMPs break with the check left in ! This wasn't the original intent, but in retrospect it makes more sense -- your patch that zeros ip_divert_ignore after calling ip_fw_chk() looks good to me... -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Sat Feb 1 01:12:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA11652 for hackers-outgoing; Sat, 1 Feb 1997 01:12:30 -0800 (PST) Received: from lassie.eunet.fi (lassie.eunet.fi [192.26.119.7]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA11646 for ; Sat, 1 Feb 1997 01:12:26 -0800 (PST) Received: from marathon.tekla.fi by lassie.eunet.fi with SMTP id AA16208 (5.67a/IDA-1.5 for ); Sat, 1 Feb 1997 11:12:24 +0200 Received: from poveri.tekla.fi by marathon.tekla.fi (5.65/20-jun-90) id AA09842; Sat, 1 Feb 1997 11:12:23 +0200 From: sja@tekla.fi (Sakari Jalovaara) Received: by poveri.tekla.fi; (5.65v3.2/1.1.8.2/20Aug96-0557PM) id AA26068; Sat, 1 Feb 1997 11:12:22 +0200 Date: Sat, 1 Feb 1997 11:12:22 +0200 Message-Id: <9702010912.AA26068@poveri.tekla.fi> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Error Message (mounting a DOS partition) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Error mounting /dev/wd1s2 on /DOS invalid argument 22 I also have a DOS partition I can't mount (not that I really care...) There seems to be some sort of offset thingie going on that FreeBSD doesn't know about. I have three slices: /dev/wd0s1 is DOS C: and can be mounted from FreeBSD. /dev/wd0s2 is FreeBSD. /dev/wd0s3 is DOS D: and can NOT be mounted from FreeBSD. /dev/wd0s3 (aka D:) has NULs at the beginning where mountmsdosfs() expects a boot sector. However, there seems to be a DOS fs at an offset of 0x7e00 bytes (go figure) from the beginning: hexdump -C /dev/wd0s3 | head -12 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 |................| 000001c0 c1 9a 06 3f ff fd 3f 00 00 00 c1 26 06 00 00 00 |...?..?....&....| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00007e00 eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 08 01 00 |.<.MSDOS5.0.....| 00007e10 02 00 02 00 00 f8 c5 00 3f 00 40 00 3f 00 00 00 |........?.@.?...| 00007e20 c1 26 06 00 80 00 29 cf 1e 40 11 44 20 20 20 20 |.&....)..@.D | Here is fdisk output: ******* Working on device /dev/rwd0 ******* parameters extracted from in-core disklabel are: cylinders=1023 heads=64 sectors/track=63 (4032 blks/cyl) parameters to be used for BIOS calculations are: cylinders=1023 heads=64 sectors/track=63 (4032 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: sysid 6,(Primary 'big' DOS (> 32MB)) start 63, size 104769 (51 Meg), flag 0 beg: cyl 0/ sector 1/ head 1; end: cyl 25/ sector 63/ head 63 The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 104832, size 3612672 (1764 Meg), flag 80 beg: cyl 26/ sector 1/ head 0; end: cyl 921/ sector 63/ head 63 The data for partition 2 is: sysid 5,(Extended DOS) start 3717504, size 403200 (196 Meg), flag 0 beg: cyl 922/ sector 1/ head 0; end: cyl 1021/ sector 63/ head 63 The data for partition 3 is: ++sja From owner-freebsd-hackers Sat Feb 1 01:20:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA11868 for hackers-outgoing; Sat, 1 Feb 1997 01:20:41 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA11860 for ; Sat, 1 Feb 1997 01:20:35 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id UAA15875; Sat, 1 Feb 1997 20:22:16 +1100 (EST) Date: Sat, 1 Feb 1997 20:22:15 +1100 (EST) From: "Daniel O'Callaghan" To: Warner Losh cc: Brian Somers , Terry Lambert , dk+@ua.net, shocking@mailbox.uq.edu.au, freebsd-hackers@freebsd.org Subject: Re: Setting MTU from userland ppp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 31 Jan 1997, Warner Losh wrote: > In message <199701302342.XAA20718@awfulhak.demon.co.uk> Brian Somers writes: > : > > Don't use 256 as your MTU. (violates the RFC) > : > > : > Any chance of having the software *enforce* the RFC, then? > : > : I'll have a look at the RFC. It currently checks that 100 <= M[TR]U <= 2000. > > Can someone point out where in the RFCs it says that an MTU size of > 256 is illegal? > > The closes that I've seen is a statement in the IP RFC that says that > a remote side must be able to asssemble a packet of at least 576 > bytes, but does not disallow smaller fragment sizes. As far as I am aware, the minimum MTU is 68 - a fully optioned IP packet with a single 8 octet chunk of fragment. At least, that is for routers. Danny From owner-freebsd-hackers Sat Feb 1 01:49:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA12543 for hackers-outgoing; Sat, 1 Feb 1997 01:49:54 -0800 (PST) Received: from buffnet4.buffnet.net (root@buffnet4.buffnet.net [205.246.19.13]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA12538; Sat, 1 Feb 1997 01:49:51 -0800 (PST) Received: from buffnet1.buffnet.net (mmdf@buffnet1.buffnet.net [205.246.19.10]) by buffnet4.buffnet.net (8.6.12/8.6.9) with SMTP id EAA31042; Sat, 1 Feb 1997 04:17:48 -0500 Received: from buffnet11.buffnet.net by buffnet1.buffnet.net id aa19012; 1 Feb 97 4:50 EST Date: Sat, 1 Feb 1997 04:50:45 -0500 (EST) From: Steve To: freebsd-questions@freebsd.org, hackers@freebsd.org Subject: slow ypserv problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ive noted that any program that uses setpwent()/getpwent() to riffle thru the password file looking for user, brings the uptime over 2.00 - takes forever - and systat will show ypserv taking up to and over 80% of the cpu. Im not sure who the author/port programmer is - but thought they ought to know. From owner-freebsd-hackers Sat Feb 1 01:51:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA12670 for hackers-outgoing; Sat, 1 Feb 1997 01:51:37 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA12665 for ; Sat, 1 Feb 1997 01:51:34 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA17084; Sat, 1 Feb 1997 20:49:03 +1100 Date: Sat, 1 Feb 1997 20:49:03 +1100 From: Bruce Evans Message-Id: <199702010949.UAA17084@godzilla.zeta.org.au> To: bde@zeta.org.au, proff@iq.org Subject: Re: #include dependencies Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Most of the headers are only used in the kernel. Kernel sources >I'm aware of this, this is why you see a number of #ifndef KERNEL. #ifndef KERNEL in kernel-only headers is nonsense (unless it is used to control a #warning or #error). >needs requiring different sys/types.h files. This appears not >to be the case and many kernel .c files rely on the fact that >sys/types.h is included in sys/libkern.h. sys/libkern.h includes because it is a modern self- sufficient header. Anything that depends on it exporting types is broken. Nothing much can depend on this since sys/libkern.h is only included directly libkern. Everything else in the kernel gets it by including sys/systm.h. sys/systm.h actually relies on sys/types.h being included in machine/cpufunc.h. >In terms of name-space pollution, the only difference between >polluting the name-space from the .C file compared to polluting it >from the included file, is that the name space *continues* to be >polluted even when the included file is changed to no longer be >dependent on the pollution. Do not be saying that this is a good No, the main difference is that applications have control over the amount of pollution. Some headers reserve a huge amount of namespace so they must not be included by other system headers. E.g., if the application includes , it must not define any identifiers start with `E' and followed by a digit or an upper case letter. If an application includes , it must not declare anything starting with `c_' or define anything starting with `B[0-9]', `I', `O', `TC' or `V'. >thing as it provides a continuity of name-space pollution in the >.C file. C code should only explicity resolve those include files >which *it* needs to define datatypes that it *directly* uses. >Anything else is inherently unstable across time and across changing >environments. By including standard headers in other headers, you make it hard for an application to include precisely the headers that it needs. After living for a while in an environment with sloppy headers, programs depend on things like obtaining declarations related to ANSI time functions by including . ( used to expediently include ; still expedniently includes .) This is inherently unstable across time and across changing environments :-). >You state "most of the headers are only used in the kernel". While >you may be correct statistically, this is not a view I can endorse. >/dev/kmem makes a mockery out of these assumptions and a not New interfaces should use sysctl() and be designed better to only pass the parts of the kernel struct of interest to applications across the interface. >I did not enforce my philosophy blindly with these patches. You may >recall I started a weeks debate on this issue and at the >end if it, the concensus appeared to be strongly supportive of >the direction I have taken. The consensus seemed to be for self-sufficient headers. There was no consensus about how to implement this. >It wasn't philosophy driving engineering, though it has certainly >dictated the path I chose. The simple impetus was that code which >works perfectly well on all other major platforms refuses to compile >under FreeBSD for the very reason we have been discussing. From It must not be BSD code. FreeBSD has made very few changes to 4.4Lite's application interface (to a fault). Bruce From owner-freebsd-hackers Sat Feb 1 02:06:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA13041 for hackers-outgoing; Sat, 1 Feb 1997 02:06:22 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA13036 for ; Sat, 1 Feb 1997 02:06:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id CAA03489; Sat, 1 Feb 1997 02:05:25 -0800 (PST) Message-Id: <199702011005.CAA03489@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Tony Sterrett cc: hackers@freebsd.org Subject: Re: MAXMEM question In-reply-to: Your message of "Fri, 31 Jan 1997 19:46:59." <199702010346.TAA01593@nlanr.net> From: David Greenman Reply-To: dg@root.com Date: Sat, 01 Feb 1997 02:05:25 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 2. using vm_page_alloc_contig(size, low, high, alignment) > to get the memory. I've been trying to use this function > to get the memory but I've had no luck doing it, maybe > I'm parameters I'm >addr = (void *) vm_page_alloc_contig (1048576,25165872, 0x1fffffe, 4096) ; should be: addr = (void *) vm_page_alloc_contig (1048576, 0, 0xffffffff, PAGE_SIZE); Assumes: 1) you want 1MB of physically contiguous memory, 2) you don't care what the physical start/end addresses are, 3) you don't need any special alignment. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sat Feb 1 02:32:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA13589 for hackers-outgoing; Sat, 1 Feb 1997 02:32:30 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA13578 for ; Sat, 1 Feb 1997 02:32:22 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id VAA17625; Sat, 1 Feb 1997 21:24:30 +1100 Date: Sat, 1 Feb 1997 21:24:30 +1100 From: Bruce Evans Message-Id: <199702011024.VAA17625@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, sja@tekla.fi Subject: Re: Error Message (mounting a DOS partition) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I also have a DOS partition I can't mount (not that I really care...) >There seems to be some sort of offset thingie going on that FreeBSD >doesn't know about. Actually, FreeBSD knows a lot about it. >I have three slices: >/dev/wd0s1 is DOS C: and can be mounted from FreeBSD. >/dev/wd0s2 is FreeBSD. >/dev/wd0s3 is DOS D: and can NOT be mounted from FreeBSD. > >/dev/wd0s3 (aka D:) has NULs at the beginning where mountmsdosfs() >expects a boot sector. However, there seems to be a DOS fs at an >offset of 0x7e00 bytes (go figure) from the beginning: > >hexdump -C /dev/wd0s3 | head -12 This is a good way to check that the slice contains what you think it does. >00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| >* >000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 |................| >000001c0 c1 9a 06 3f ff fd 3f 00 00 00 c1 26 06 00 00 00 |...?..?....&....| ^^^^^^^^^^^^ ^^^^^^^^^^^ offset of 1st size of slice in 1st slice logical drive (403137 decimal) >000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| >* >00007e00 eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 08 01 00 |.<.MSDOS5.0.....| ^^^^^^^^ (offset 0x3f) * (sector size 0x200) = 0x7e00 >00007e10 02 00 02 00 00 f8 c5 00 3f 00 40 00 3f 00 00 00 |........?.@.?...| >00007e20 c1 26 06 00 80 00 29 cf 1e 40 11 44 20 20 20 20 |.&....)..@.D | >Here is fdisk output: > >******* Working on device /dev/rwd0 ******* >parameters extracted from in-core disklabel are: >cylinders=1023 heads=64 sectors/track=63 (4032 blks/cyl) >... >The data for partition 2 is: >sysid 5,(Extended DOS) > start 3717504, size 403200 (196 Meg), flag 0 ^^^^^^ used up by 1 logical drive of size 403200 containing 1 slice of size 403200-63 at relative offset 63 > beg: cyl 922/ sector 1/ head 0; > end: cyl 1021/ sector 63/ head 63 wd0s3 is an extended partition. It may contain almost any number of logical drives, of which DOS officially supports up to 23 (D:-Z:) provided there is only one DOS drive, and FreeBSD supports 26 (wd0s5-wd0s30) independently of other drives. >dev/wd0s3 is DOS D: and can NOT be mounted from FreeBSD. /dev/wd0s5 is DOS D: and CAN be mounted from FreeBSD. DOS drive numbering is very illogical and isn't understood by FreeBSD. E.g., if you add another drive and put a primary DOS partition partition on it, then IIRC it will become D: and the old D: will become E:. FreeBSD attempts to support multiple extended partitions and multiple logical drives at every level, but you shouldn't use this. It isn't standard and makes the numbering more confusing. Bruce From owner-freebsd-hackers Sat Feb 1 04:52:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA19435 for hackers-outgoing; Sat, 1 Feb 1997 04:52:48 -0800 (PST) Received: from lassie.eunet.fi (lassie.eunet.fi [192.26.119.7]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA19430 for ; Sat, 1 Feb 1997 04:52:45 -0800 (PST) Received: from marathon.tekla.fi by lassie.eunet.fi with SMTP id AA28297 (5.67a/IDA-1.5 for ); Sat, 1 Feb 1997 14:52:43 +0200 Received: from poveri.tekla.fi by marathon.tekla.fi (5.65/20-jun-90) id AA13387; Sat, 1 Feb 1997 14:52:42 +0200 From: sja@tekla.fi (Sakari Jalovaara) Received: by poveri.tekla.fi; (5.65v3.2/1.1.8.2/20Aug96-0557PM) id AA24323; Sat, 1 Feb 1997 14:52:41 +0200 Date: Sat, 1 Feb 1997 14:52:41 +0200 Message-Id: <9702011252.AA24323@poveri.tekla.fi> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Error Message (mounting a DOS partition) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > wd0s3 is an extended partition. It may contain almost any number of > logical drives, of which DOS officially supports up to 23 (D:-Z:) > provided there is only one DOS drive, and FreeBSD supports 26 > (wd0s5-wd0s30) independently of other drives. Ah, so, right, aha, yeah (he said, nodding, pretending to understand DOS partitioning :-) Actually, I think I'm getting some of this. So, DOS disks always have four partitions (some of which can have zero size). Slices 5..32 (NDOSPART+1...MAX_SLICES) are *inside* extended partitions (or recursively inside other slices). wd0s5 doesn't come after wd0s4 (as a UNIX weenie might expect); it is inside the first extended partition (whichever of the four that might be.) s6 would be either after s5 inside the same extended partition, or on the next extended partition, or even inside s5. Trying to mount an extended partition is silly; what I want to mount is one of the logical drives inside it. Hmm, it's too bad extended partitions don't seem to have an obvious magic number so that mount code could notice what is going on and tell the user. > >dev/wd0s3 is DOS D: and can NOT be mounted from FreeBSD. > /dev/wd0s5 is DOS D: and CAN be mounted from FreeBSD. Right you are, wd0s5 works. Thanks! ++sja From owner-freebsd-hackers Sat Feb 1 05:13:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA19992 for hackers-outgoing; Sat, 1 Feb 1997 05:13:46 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA19987 for ; Sat, 1 Feb 1997 05:13:40 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id NAA01092; Sat, 1 Feb 1997 13:12:29 GMT Message-Id: <199702011312.NAA01092@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Warner Losh cc: iman triwahyudi , hackers@FreeBSD.ORG Subject: Re: packet driver In-reply-to: Your message of "Sat, 01 Feb 1997 00:01:02 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Feb 1997 13:12:29 +0000 From: Brian Somers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In message <199702010134.BAA29834@awfulhak.demon.co.uk> Brian Somers writes: > : > Anyone know how to get radio packet driver for FreeBSD ? > : Sorry, but there's no such thing as a "packet driver" for FreeBSD. > > I think you parsed this wrong. How do I get a radio-packet driver for > FreeBSD? Eg, a driver for one of the many packet-radio cards that are > out there... Ah - a packet radio driver ;) Sorry - still don't know :( -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat Feb 1 05:15:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA20072 for hackers-outgoing; Sat, 1 Feb 1997 05:15:48 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA20063 for ; Sat, 1 Feb 1997 05:15:44 -0800 (PST) Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0vqfI5-000Qb5C; Sat, 1 Feb 97 14:15 MET Received: (grog@localhost) by freebie.lemis.de (8.8.4/8.6.12) id OAA19288; Sat, 1 Feb 1997 14:15:06 +0100 (MET) From: grog@lemis.de Message-Id: <199702011315.OAA19288@freebie.lemis.de> Subject: Re: bisdn In-Reply-To: <8720b6wb2e.fsf@localhost.xs4all.nl> from Peter Mutsaers at "Jan 28, 97 07:47:21 am" To: plm@xs4all.nl (Peter Mutsaers) Date: Sat, 1 Feb 1997 14:15:05 +0100 (MET) Cc: hackers@freebsd.org (FreeBSD Hackers) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Reply-to: grog@lemis.de (Greg Lehey) WWW-Home-Page: http://www.FreeBSD.org/~grog X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Mutsaers writes: >> > On Mon, 27 Jan 1997 15:42:04 +0100 (MET), Greg Lehey >> > said: > > GL> Well, to be fair, Gary Jennejohn replied and told me that this > GL> related to ppp, which I don't use. I think the problem there > GL> is that not many people use ppp over here, so it's not > GL> surprising that it's taking a long time. > > Yes, that is the problem for most people. I'm surprised that you don't > use PPP! Here all ISP's offer ISDN access only through syncPPP. I > can't even think of another way. If you don't use PPP, then how do you > get TCP/IP over ISDN? Why should you need ppp to run IP? None of the high-speed lines do. They run a straight layer 2 protocol--HDLC, in the case of ISDN over here. ppp just adds encapsulation overhead. Greg From owner-freebsd-hackers Sat Feb 1 05:20:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA20300 for hackers-outgoing; Sat, 1 Feb 1997 05:20:51 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA20294 for ; Sat, 1 Feb 1997 05:20:48 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA04670 for hackers@freebsd.org; Sat, 1 Feb 1997 14:20:45 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id NAA01440; Sat, 1 Feb 1997 13:58:25 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 13:58:24 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: Suggested ehternet chips/cards? References: <32F26FB5.167EB0E7@whistle.com> <199702010113.LAA11999@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702010113.LAA11999@genesis.atrad.adelaide.edu.au>; from Michael Smith on Feb 1, 1997 11:43:54 +1030 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Michael Smith wrote: > Neither the SMC nor the similar Crystal parts have impressed me at > all; they all have really small (~2K) buffers, possibly because they > try to put the buffer RAM on-chip. What about AMD? The `Lance' (Am7990PC) chip has got good reputation, and has been used in many workstations, i think. I'm not certain about the quality of their newer products (PCnet?). -- 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 Feb 1 05:22:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA20364 for hackers-outgoing; Sat, 1 Feb 1997 05:22:51 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA20353 for ; Sat, 1 Feb 1997 05:22:46 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA04700; Sat, 1 Feb 1997 14:22:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id OAA07639; Sat, 1 Feb 1997 14:15:45 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 14:15:45 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: BigDaddy@LiveNet.Net (Joseph I. Arias) Cc: hackers@freebsd.org Subject: Re: Can't install from DOS partition References: <199702010330.WAA08803@Clifford.LiveNet.Net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702010330.WAA08803@Clifford.LiveNet.Net>; from Joseph I. Arias on Jan 31, 1997 22:26:41 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Joseph I. Arias wrote: > I have Win95 installed in my computer, but I'm booting the system from the > boot disk that I made with rawrite boot4.flp and I also tried boot.flp. I > formated the drive and just installed dos 6.22 on it and still getting this > same message. Hrmpf. Please, don't split your personal and list replies into two separate messages. I've already answered in private mail (and this seems to be a problem with missing VFAT support). Also, please use a Subject line. -- 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 Feb 1 05:22:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA20401 for hackers-outgoing; Sat, 1 Feb 1997 05:22:59 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA20392 for ; Sat, 1 Feb 1997 05:22:56 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA04701; Sat, 1 Feb 1997 14:22:50 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id OAA09621; Sat, 1 Feb 1997 14:18:58 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 14:18:58 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: taob@risc.org (Brian Tao) Cc: freebsd-hackers@freebsd.org (FREEBSD-HACKERS-L) Subject: Re: Mounting CD-ROM when data not on first track References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Brian Tao on Feb 1, 1997 01:47:46 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Brian Tao wrote: > On a whim, I bought the "Star Trek: First Contact" soundtrack > today on CD. It has a filesystem on track 14 of the disc with > Quicktime trailers of the movie. IMHO, this violates the cd9660 specs which apparently assume that at most the very first track of each session is in CD-ROM Data format. (That's why they have a fairly confused terminology about a ``multi- session'' CD.) I've once got a set of patches to enable multi-track support for the `cd' driver, but didn't track this further waiting for Justin's SCSI branch being merged into the main tree first. I could probably dig them up for you if you desire. -- 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 Feb 1 05:27:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA20575 for hackers-outgoing; Sat, 1 Feb 1997 05:27:47 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA20570 for ; Sat, 1 Feb 1997 05:27:44 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id NAA01803; Sat, 1 Feb 1997 13:25:44 GMT Message-Id: <199702011325.NAA01803@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: brian@utell.co.uk, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net, joerg_wunsch@uriah.heep.sax.de Subject: Re: ipdivert & masqd FIXED ! In-reply-to: Your message of "Sat, 01 Feb 1997 00:43:01 PST." <199702010843.AAA06137@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Feb 1997 13:25:44 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > Yes, ip_input() calls ip_output() indirectly when forwarding packets. > > > You actually want to *not* zero ip_divert_ignore in this case in order > > > to realize the intended semantics of the socket -- the loop avoidance > > > is supposed to avoid all diversion back to the port, even if the packet > > > passes through ipfw twice, on the way "in" and on the way "out". > > > > > > > It turns out that this was the problem ! > > > > If 10.0.1.1 pings 10.0.1.254, ip_input() is called. This diverts to masqd > > and then gets re-injected. The second time around, ip_input() ignores the > > divert (correctly) but calls ip_output(). ip_output() incorrectly ignores > > the divert socket - so the packet mangling doesn't get done ! > > > > I've altered things slightly so that ip_divert_ignore gets zero'd as soon > > as it's been used in both ip_input() and ip_output(). Patches are available > > on www.awfulhak.demon.co.uk. Also, ip_divert_ignore is set in ip_divert.c > > irrespective of whether sin->sin_port is around.... I think this may be wrong, > > (it works, but for the wrong reasons) - ICMPs break with the check left in ! > > This wasn't the original intent, but in retrospect it makes more > sense -- your patch that zeros ip_divert_ignore after calling > ip_fw_chk() looks good to me... I'll commit the changes then - anyone have a problem with them going into 2.2 too ? -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat Feb 1 06:22:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA23812 for hackers-outgoing; Sat, 1 Feb 1997 06:22:39 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA23804 for ; Sat, 1 Feb 1997 06:22:36 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id PAA05943 for hackers@FreeBSD.ORG; Sat, 1 Feb 1997 15:22:28 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id PAA25861; Sat, 1 Feb 1997 15:06:47 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 15:06:47 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG (FreeBSD Hackers) Subject: Re: bisdn References: <8720b6wb2e.fsf@localhost.xs4all.nl> <199702011315.OAA19288@freebie.lemis.de> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702011315.OAA19288@freebie.lemis.de>; from grog@lemis.de on Feb 1, 1997 14:15:05 +0100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As grog@lemis.de wrote: > Why should you need ppp to run IP? [over ISDN - J.] Because of the existing, well-defined negotiation protocol. Almost all router manufacturers went away from their home-grown, mutually incompatible ``IP over raw HDLC'' protocols. I don't know of any ISDN router that doesn't support PPP right now, but i know of router manufacturers who dropped (or intend to drop) their legacy ``raw HDLC'' options. They ended up reinwhenting the PPP wheel anyway, regarding IP address negotiation, LQR etc. Let alone compatibility to other peers. It's a often stated but unproven myth that PPP adds _much_ overhead. You end up with the same near 8 KB/s throughput per 64 Kbit/s channel nevertheless. -- 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 Feb 1 06:52:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA24673 for hackers-outgoing; Sat, 1 Feb 1997 06:52:15 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA24668 for ; Sat, 1 Feb 1997 06:52:11 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id BAA24105; Sun, 2 Feb 1997 01:47:20 +1100 Date: Sun, 2 Feb 1997 01:47:20 +1100 From: Bruce Evans Message-Id: <199702011447.BAA24105@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, sja@tekla.fi Subject: Re: Error Message (mounting a DOS partition) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Actually, I think I'm getting some of this. So, DOS disks always >have four partitions (some of which can have zero size). >Slices 5..32 (NDOSPART+1...MAX_SLICES) are *inside* extended >partitions (or recursively inside other slices). Normally, recursively inside one extended partition in the primary partition table. >wd0s5 doesn't come after wd0s4 (as a UNIX weenie might expect); wd0[a-h] and wd0s[1-4] need not be in sector order, so you shouldn't expect much here. >it is inside the first extended partition (whichever of the four >that might be.) s6 would be either after s5 inside the same extended >partition, or on the next extended partition, or even inside s5. Normally, to get s6, s4 would have contain 2 partitions (er slices, I'll call them pslices from now on). s5 and an extended pslice that isn't mapped to a FreeBSD slice. This extended pslice contains s6 and possibly another extended pslice... s5 would never have another pslice in it, but there might be 2 more pslices in the pslice table at the start of slice s4. These are normally not used. Bruce From owner-freebsd-hackers Sat Feb 1 07:22:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26372 for hackers-outgoing; Sat, 1 Feb 1997 07:22:01 -0800 (PST) Received: from magigimmix.xs4all.nl (magigimmix.xs4all.nl [194.109.6.25]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26351 for ; Sat, 1 Feb 1997 07:21:46 -0800 (PST) Received: from asterix.xs4all.nl (asterix.xs4all.nl [194.109.6.11]) by magigimmix.xs4all.nl (8.7.6/XS4ALL) with ESMTP id QAA16494; Sat, 1 Feb 1997 16:21:43 +0100 (MET) Received: from plm.xs4all.nl (uucp@localhost) by asterix.xs4all.nl (8.7.5/8.7.2) with UUCP id QAA01960; Sat, 1 Feb 1997 16:15:32 +0100 (MET) Received: (from plm@localhost) by plm.xs4all.nl (8.8.4/8.7.3) id PAA00225; Sat, 1 Feb 1997 15:24:13 +0100 (MET) Date: Sat, 1 Feb 1997 15:24:13 +0100 (MET) Message-Id: <199702011424.PAA00225@plm.xs4all.nl> From: Peter Mutsaers To: grog@lemis.de (Greg Lehey) Cc: hackers@freebsd.org (FreeBSD Hackers) Subject: Re: bisdn In-Reply-To: <199702011315.OAA19288@freebie.lemis.de> References: <8720b6wb2e.fsf@localhost.xs4all.nl> <199702011315.OAA19288@freebie.lemis.de> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> On Sat, 1 Feb 1997 14:15:05 +0100 (MET), Greg Lehey said: GL> Peter Mutsaers writes: >> > On Mon, 27 Jan 1997 15:42:04 +0100 (MET), Greg Lehey >> > said: >> GL> Well, to be fair, Gary Jennejohn replied and told me that this GL> related to ppp, which I don't use. I think the problem there GL> is that not many people use ppp over here, so it's not GL> surprising that it's taking a long time. >> >> Yes, that is the problem for most people. I'm surprised that you don't >> use PPP! Here all ISP's offer ISDN access only through syncPPP. I >> can't even think of another way. If you don't use PPP, then how do you >> get TCP/IP over ISDN? GL> Why should you need ppp to run IP? None of the high-speed lines do. GL> They run a straight layer 2 protocol--HDLC, in the case of ISDN over GL> here. ppp just adds encapsulation overhead. Indeed, but in practice, every home user who connects to an ISP needs PPP. There aren't many that can afford dedicated links. At least I don't know of any ISP's that offer other ways for TCP/IP connection. From owner-freebsd-hackers Sat Feb 1 07:55:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA27402 for hackers-outgoing; Sat, 1 Feb 1997 07:55:13 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA27397 for ; Sat, 1 Feb 1997 07:55:10 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id HAA19146; Sat, 1 Feb 1997 07:54:59 -0800 (PST) To: sja@tekla.fi (Sakari Jalovaara) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Error Message (mounting a DOS partition) In-reply-to: Your message of "Sat, 01 Feb 1997 11:12:22 +0200." <9702010912.AA26068@poveri.tekla.fi> Date: Sat, 01 Feb 1997 07:54:59 -0800 Message-ID: <19142.854812499@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > /dev/wd0s3 is DOS D: and can NOT be mounted from FreeBSD. No, /dev/wd0s3 is NOT DOS D:. :-) /dev/wd0s4 is DOS D:. Please RTFM the FAQ and Handbook; they discuss DOS extended partition handling, as does INSTALL.TXT. Jordan From owner-freebsd-hackers Sat Feb 1 08:10:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA28073 for hackers-outgoing; Sat, 1 Feb 1997 08:10:12 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28067 for ; Sat, 1 Feb 1997 08:10:08 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id IAA19203; Sat, 1 Feb 1997 08:07:45 -0800 (PST) To: Brian Somers cc: Archie Cobbs , brian@utell.co.uk, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@FreeBSD.ORG, cmott@srv.net, joerg_wunsch@uriah.heep.sax.de Subject: Re: ipdivert & masqd FIXED ! In-reply-to: Your message of "Sat, 01 Feb 1997 13:25:44 GMT." <199702011325.NAA01803@awfulhak.demon.co.uk> Date: Sat, 01 Feb 1997 08:07:45 -0800 Message-ID: <19199.854813265@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'll commit the changes then - anyone have a problem with them going into > 2.2 too ? Since they'll be necessary for adding this support later, if nothing else, I have no objections. Jordan From owner-freebsd-hackers Sat Feb 1 08:12:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA28213 for hackers-outgoing; Sat, 1 Feb 1997 08:12:16 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA28207 for ; Sat, 1 Feb 1997 08:12:12 -0800 (PST) Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0vqi2y-000QbZC; Sat, 1 Feb 97 17:12 MET Received: (grog@localhost) by freebie.lemis.de (8.8.4/8.6.12) id QAA19237; Sat, 1 Feb 1997 16:56:10 +0100 (MET) From: grog@lemis.de Message-Id: <199702011556.QAA19237@freebie.lemis.de> Subject: Re: bisdn In-Reply-To: <199702011424.PAA00225@plm.xs4all.nl> from Peter Mutsaers at "Feb 1, 97 03:24:13 pm" To: plm@xs4all.nl (Peter Mutsaers) Date: Sat, 1 Feb 1997 16:56:10 +0100 (MET) Cc: hackers@freebsd.org (FreeBSD Hackers) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Reply-to: grog@lemis.de (Greg Lehey) WWW-Home-Page: http://www.FreeBSD.org/~grog X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Mutsaers writes: >>> On Sat, 1 Feb 1997 14:15:05 +0100 (MET), Greg Lehey said: > > GL> Peter Mutsaers writes: >>>> On Mon, 27 Jan 1997 15:42:04 +0100 (MET), Greg Lehey >>>> said: >>> > GL> Well, to be fair, Gary Jennejohn replied and told me that this > GL> related to ppp, which I don't use. I think the problem there > GL> is that not many people use ppp over here, so it's not > GL> surprising that it's taking a long time. >>> >>> Yes, that is the problem for most people. I'm surprised that you don't >>> use PPP! Here all ISP's offer ISDN access only through syncPPP. I >>> can't even think of another way. If you don't use PPP, then how do you >>> get TCP/IP over ISDN? > > GL> Why should you need ppp to run IP? None of the high-speed lines do. > GL> They run a straight layer 2 protocol--HDLC, in the case of ISDN over > GL> here. ppp just adds encapsulation overhead. > > Indeed, but in practice, every home user who connects to an ISP needs PPP. > There aren't many that can afford dedicated links. Agreed, but there's no connection between the two matters. > At least I don't know of any ISP's that offer other ways for > TCP/IP connection. There aren't too many in the USA. That doesn't mean that there shouldn't be. I believe most ISDN routers can be set up to run without PPP. Certainly the ISPs over here, nearly all of who offer transparent HDLC, use the same routers as are used in the USA. Greg From owner-freebsd-hackers Sat Feb 1 08:18:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA28377 for hackers-outgoing; Sat, 1 Feb 1997 08:18:50 -0800 (PST) Received: from alpha.risc.org (ppp-155.isdn-3.ican.net [206.231.241.155]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28372 for ; Sat, 1 Feb 1997 08:18:42 -0800 (PST) Received: from localhost (taob@localhost) by alpha.risc.org (8.8.4/8.8.4) with SMTP id LAA08936; Sat, 1 Feb 1997 11:18:18 -0500 (EST) Date: Sat, 1 Feb 1997 11:18:17 -0500 (EST) From: Brian Tao To: Joerg Wunsch cc: FREEBSD-HACKERS-L Subject: Re: Mounting CD-ROM when data not on first track In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 1 Feb 1997, J Wunsch wrote: > > IMHO, this violates the cd9660 specs which apparently assume that at > most the very first track of each session is in CD-ROM Data format. I was under that impression as well. Certainly every other "multimedia" CD I've bought has had the data on track 1. > I've once got a set of patches to enable multi-track support for the > `cd' driver, but didn't track this further waiting for Justin's SCSI > branch being merged into the main tree first. I could probably dig > them up for you if you desire. What source tree are they diffed against? I've got a 2.2-BETA machine at home, and a 3.0-SNAP at work. -- Brian Tao (BT300, taob@risc.org) "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sat Feb 1 08:20:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA28539 for hackers-outgoing; Sat, 1 Feb 1997 08:20:14 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28534 for ; Sat, 1 Feb 1997 08:20:11 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id IAA19282; Sat, 1 Feb 1997 08:20:05 -0800 (PST) cc: sja@tekla.fi (Sakari Jalovaara), freebsd-hackers@FreeBSD.ORG Subject: Re: Error Message (mounting a DOS partition) In-reply-to: Your message of "Sat, 01 Feb 1997 07:54:59 PST." <19142.854812499@time.cdrom.com> Date: Sat, 01 Feb 1997 08:20:04 -0800 Message-ID: <19278.854814004@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > /dev/wd0s3 is DOS D: and can NOT be mounted from FreeBSD. > > No, /dev/wd0s3 is NOT DOS D:. :-) > > /dev/wd0s4 is DOS D:. Please RTFM the FAQ and Handbook; they > discuss DOS extended partition handling, as does INSTALL.TXT. *Ahem*. :-} That is to say, /dev/wd0s5. /dev/wd0s4 is, indeed, the last physical partition and not what I meant to type at all. Damn keybd! :-) Jordan From owner-freebsd-hackers Sat Feb 1 08:34:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA28900 for hackers-outgoing; Sat, 1 Feb 1997 08:34:17 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28889 for ; Sat, 1 Feb 1997 08:34:11 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id LAA10659; Sat, 1 Feb 1997 11:34:03 -0500 (EST) Message-Id: <199702011634.LAA10659@spoon.beta.com> To: hackers@freebsd.org cc: msmith@atrad.adelaide.edu.au Subject: Device driver help... Date: Sat, 01 Feb 1997 11:34:02 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ok. I'm underway writing my pseudo-device driver, as promised. Unfortuately, I think I hit my first snag early on in that the book I'm using for reference was slanted towards SCO. Here's what they recommend: #include #include #include #include #include #include static char message[] = "This is a test message\n"; fooinit() { printf("Test Data Character Device Driver\n"); } void fooread(dev_t dev) { while (u.u_count) { if (copyout(&message[u.u_offset % sizeof(message)], u.u_base, 1) == -1) { u.u_error = EFAULT; return; } u.u_base++; u.u_offset++; u.u_count--; } } At this point, I figured it'd be a good idea to actually try to compile it out of kernel, just to see how close I was to the mark. Lets just say I missed :) I started checking out some of the drivers, such as sio.c, and a few others for "how they did it". I ended up (to date) with something that looks like this: #define KERNEL #include #include #include #include #include #include #include #include #include #include #include #include #ifdef DEVFS #include #endif #include #include #include static char message[] = "This is a test message\n"; fooinit() { printf("Test Character Device Driver\n"); } static int fooread(dev,myuio, flag) dev_t dev; struct uio *myuio; int flag; { while(myuio->u_count) { if (copyout(&message[myuio->u_count % sizeof(message)], myuio->u_base, 1) == -1) { myuio->u_error = EFAULT; return; } myuio->u_base++; myuio->u_offset++; myuio->u_count--; } } Unfortunately, the uio structure doesn't seem to be the same as SCOs (hence, things like uio->u_base don't exist). Could someone please tell me if I'm even on the right path with struct uio, and if so, provide some minimal documentation as to the fields, and how to apply them in this circumstance? Thanks. -Brian PS - I realize this driver is pretty hideous, and a lot could be done to it. Remember, however, its 15 minutes of work :) From owner-freebsd-hackers Sat Feb 1 09:51:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA01770 for hackers-outgoing; Sat, 1 Feb 1997 09:51:30 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01761 for ; Sat, 1 Feb 1997 09:51:26 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA10564; Sat, 1 Feb 1997 18:51:24 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id SAA29332; Sat, 1 Feb 1997 18:38:52 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 18:38:52 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: sja@tekla.fi (Sakari Jalovaara) Subject: Re: Error Message (mounting a DOS partition) References: <9702010912.AA26068@poveri.tekla.fi> <19142.854812499@time.cdrom.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19142.854812499@time.cdrom.com>; from Jordan K. Hubbard on Feb 1, 1997 07:54:59 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > /dev/wd0s3 is DOS D: and can NOT be mounted from FreeBSD. > > No, /dev/wd0s3 is NOT DOS D:. :-) > > /dev/wd0s4 is DOS D:. Only in rare cases. :-) Slice number 0 never appears in a name, since it's an alias for the non-sliced device (or compatibility slice), like in /dev/wd0a. Slices number 1 through 4 are hard-coded for the four standard fdisk table slots, regardless of whether they're actually in use or not. So unless you have created e.g. DOS drive C: in slot #3 and another DOS slice in #4, /dev/wd0s4 is not drive D:. (The DOS tools IMHO don't let you create two DOS slices in the primary fdisk table, although they are able to use them.) ``Extended partitions'' start with slice number 5 in FreeBSD, and their slice entries are only valid if there's indeed something to map. So, DOS drive D: is most likely /dev/[r]wd0s5. -- 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 Feb 1 09:51:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA01796 for hackers-outgoing; Sat, 1 Feb 1997 09:51:42 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01791 for ; Sat, 1 Feb 1997 09:51:39 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA10593 for freebsd-hackers@freebsd.org; Sat, 1 Feb 1997 18:51:37 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id SAA29341; Sat, 1 Feb 1997 18:39:51 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 18:39:51 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FREEBSD-HACKERS-L) Subject: Re: Mounting CD-ROM when data not on first track References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Brian Tao on Feb 1, 1997 11:18:17 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Brian Tao wrote: > > I've once got a set of patches to enable multi-track support for the > > `cd' driver, but didn't track this further waiting for Justin's SCSI > > branch being merged into the main tree first. I could probably dig > > them up for you if you desire. > > What source tree are they diffed against? I've got a 2.2-BETA > machine at home, and a 3.0-SNAP at work. Most likely some very old 2.2, if i could dig them up at all. -- 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 Feb 1 09:52:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA01865 for hackers-outgoing; Sat, 1 Feb 1997 09:52:22 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01856 for ; Sat, 1 Feb 1997 09:52:18 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA10647; Sat, 1 Feb 1997 18:51:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id SAA29372; Sat, 1 Feb 1997 18:48:15 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 18:48:15 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: mcgovern@spoon.beta.com (Brian J. McGovern) Cc: hackers@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: Device driver help... References: <199702011634.LAA10659@spoon.beta.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702011634.LAA10659@spoon.beta.com>; from Brian J. McGovern on Feb 1, 1997 11:34:02 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Brian J. McGovern wrote: > void fooread(dev_t dev) > { > while (u.u_count) Uh. No such thing like u-dot in BSD... :) > I started checking out some of the drivers, such as sio.c, and a few others > for "how they did it". I ended up (to date) with something that looks like > this: tty-style drivers are certainly the worst you could look at. They use clists which greatly obfuscates the matter for you. Better look at a simple driver like the scanner drivers that are around. > Unfortunately, the uio structure doesn't seem to be the same as SCOs (hence, > things like uio->u_base don't exist). First, BSD supports scatter/gather IO, so there's not a single buffer in it, but an IO vector. Second, you ought to have uiomove(9) (man page yet to be written, of course -- but now you're a really good candidate to write it finally! :) do the dirty work for you. -- 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 Feb 1 09:54:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA01958 for hackers-outgoing; Sat, 1 Feb 1997 09:54:13 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA01945 for ; Sat, 1 Feb 1997 09:54:10 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id SAA05874; Sat, 1 Feb 1997 18:55:38 +0100 (MET) From: Søren Schmidt Message-Id: <199702011755.SAA05874@ravenock.cybercity.dk> Subject: Re: bisdn In-Reply-To: <199702011556.QAA19237@freebie.lemis.de> from "grog@lemis.de" at "Feb 1, 97 04:56:10 pm" To: grog@lemis.de Date: Sat, 1 Feb 1997 18:55:30 +0100 (MET) Cc: plm@xs4all.nl, hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to grog@lemis.de who wrote: > >>> Yes, that is the problem for most people. I'm surprised that you don't > >>> use PPP! Here all ISP's offer ISDN access only through syncPPP. I > >>> can't even think of another way. If you don't use PPP, then how do you > >>> get TCP/IP over ISDN? > > > > GL> Why should you need ppp to run IP? None of the high-speed lines do. > > GL> They run a straight layer 2 protocol--HDLC, in the case of ISDN over > > GL> here. ppp just adds encapsulation overhead. > > > > Indeed, but in practice, every home user who connects to an ISP needs PPP. > > There aren't many that can afford dedicated links. > > Agreed, but there's no connection between the two matters. > > > At least I don't know of any ISP's that offer other ways for > > TCP/IP connection. > > There aren't too many in the USA. That doesn't mean that there > shouldn't be. I believe most ISDN routers can be set up to run > without PPP. Certainly the ISPs over here, nearly all of who offer > transparent HDLC, use the same routers as are used in the USA. Here in DK land most (if not all) ISP uses PPP as well, so nearly all is only in DE land (I think).... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Sat Feb 1 10:00:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA02245 for hackers-outgoing; Sat, 1 Feb 1997 10:00:55 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA02225; Sat, 1 Feb 1997 10:00:50 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vqbzu-0002xj-00; Sat, 1 Feb 1997 01:44:35 -0800 Date: Sat, 1 Feb 1997 01:44:34 -0800 (PST) From: Tom Samplonius To: Steve cc: freebsd-questions@freebsd.org, hackers@freebsd.org Subject: Re: slow ypserv problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 1 Feb 1997, Steve wrote: > Ive noted that any program that uses setpwent()/getpwent() to riffle thru > the password file looking for user, brings the uptime over 2.00 - takes > forever - and systat will show ypserv taking up to and over 80% of the > cpu. > > Im not sure who the author/port programmer is - but thought they ought to > know. Bill knows. ypserv was completely re-written for 2.2. Tom From owner-freebsd-hackers Sat Feb 1 10:03:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA02372 for hackers-outgoing; Sat, 1 Feb 1997 10:03:27 -0800 (PST) Received: from Clifford.LiveNet.Net (root@Clifford.LiveNet.Net [206.156.5.13]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02355 for ; Sat, 1 Feb 1997 10:03:22 -0800 (PST) Received: from samantha (Earthquake.Stormer.LiveNet.Net [206.156.5.144]) by Clifford.LiveNet.Net (8.7.6/8.6.9) with ESMTP id NAA09929 for ; Sat, 1 Feb 1997 13:09:42 -0500 (EST) Message-Id: <199702011809.NAA09929@Clifford.LiveNet.Net> From: "Joseph I. Arias" To: Date: Sat, 1 Feb 1997 13:05:43 -0800 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk JA> I have Win95 installed in my computer, but I'm booting the system from the JA> boot disk that I made with rawrite boot4.flp and I also tried boot.flp. JW>The latter is unimportant -- but Win95 certainly is. I assume you're JW>using this dreaded VFAT filesystem then. Sorry to say, but our MSDOS JW>filesystem code is not yet up to this. I Formated my hard drive and only installed dos 6.22 and have removed Windows 95 complety from my system and again I get the same error message. Error mounting /dev/wd1s2 on /dos: invalid argument (22) JW>Good news: FreeBSD 2.2 doesn't use the msdosfs for installation, but a JW>private library instead. This should at least allow installing from a JW>VFAT filesystem, even though you still can't mount it in Unix JW>afterwards (but the mtools package can export or import files there). Should I download FreeBSD 2.2? I'm a beginger to Unix is 2.2 stable enough for me to pratic on? I'm wanting to start up my own ISP using BSD it was a recomendation for the ISP now he runs it and I have gotten use to it. Thanks Joe From owner-freebsd-hackers Sat Feb 1 10:39:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA03892 for hackers-outgoing; Sat, 1 Feb 1997 10:39:23 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA03887 for ; Sat, 1 Feb 1997 10:39:18 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id NAA04106; Sat, 1 Feb 1997 13:39:08 -0500 (EST) From: "John S. Dyson" Message-Id: <199702011839.NAA04106@dyson.iquest.net> Subject: Re: Device driver help... To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Sat, 1 Feb 1997 13:39:08 -0500 (EST) Cc: hackers@freebsd.org, msmith@atrad.adelaide.edu.au In-Reply-To: <199702011634.LAA10659@spoon.beta.com> from "Brian J. McGovern" at Feb 1, 97 11:34:02 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Ok. I'm underway writing my pseudo-device driver, as promised. Unfortuately, > I think I hit my first snag early on in that the book I'm using for > reference was slanted towards SCO. Here's what they recommend: > As an extremely simple driver prototype, try /sys/i386/i386/mem.c as a first example??? John From owner-freebsd-hackers Sat Feb 1 12:50:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA08973 for hackers-outgoing; Sat, 1 Feb 1997 12:50:21 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA08968 for ; Sat, 1 Feb 1997 12:50:17 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA18020; Sat, 1 Feb 1997 21:50:12 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id VAA00388; Sat, 1 Feb 1997 21:30:10 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 21:30:10 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: BigDaddy@LiveNet.Net (Joseph I. Arias) Cc: hackers@FreeBSD.ORG Subject: Re: Installing from DOS partition References: <199702011809.NAA09929@Clifford.LiveNet.Net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702011809.NAA09929@Clifford.LiveNet.Net>; from Joseph I. Arias on Feb 1, 1997 13:05:43 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Joseph I. Arias wrote: > I Formated my hard drive and only installed dos 6.22 and have removed > Windows 95 complety from my system and again I get the same error message. ..because it's probably still a VFAT filesystem, i assume. Install DOS 5. :) > Should I download FreeBSD 2.2? I'm a beginger to Unix is 2.2 stable enough > for me to pratic on? It's probably 20 times more stable than Win 3.1, and 5 times more stable than Win 95. :-) > I'm wanting to start up my own ISP using BSD it was a > recomendation for the ISP now he runs it and I have gotten use to it. Hmm, i think you've got quite some way to go until you will even be able to start your ISP business. Be assured, by the time you've got the knowledge how to handle all this, there will be FreeBSD 2.2.5. :) No offense intended, but i think somebody who's going to be serious about ISP business won't even install a DOS partition at all first. Waste of space. You even didn't learn how to give your mail a subject line yet... how are you going to teach your customers about Internet Netiquette? Sorry for my ramblings. -- 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 Feb 1 13:02:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA09408 for hackers-outgoing; Sat, 1 Feb 1997 13:02:23 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA09396 for ; Sat, 1 Feb 1997 13:01:58 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id NAA04920 for ; Sat, 1 Feb 1997 13:02:43 -0800 (PST) Received: (qmail 10804 invoked by uid 110); 1 Feb 1997 21:00:31 -0000 MBOX-Line: From owner-netdev@roxanne.nuclecu.unam.mx Sat Feb 01 20:27:14 1997 remote from suburbia.net Delivered-To: proff@suburbia.net Received: (qmail 9045 invoked from network); 1 Feb 1997 20:26:51 -0000 Received: from roxanne.nuclecu.unam.mx (132.248.29.2) by suburbia.net with SMTP; 1 Feb 1997 20:26:51 -0000 Received: (from root@localhost) by roxanne.nuclecu.unam.mx (8.6.12/8.6.11) id OAA22043 for netdev-outgoing; Sat, 1 Feb 1997 14:00:30 -0600 Received: from prosun.first.gmd.de (prosun.first.gmd.de [194.95.168.2]) by roxanne.nuclecu.unam.mx (8.6.12/8.6.11) with SMTP id FAA19920 for ; Sat, 1 Feb 1997 05:20:16 -0600 Received: by prosun.first.gmd.de (4.1/SMI-4.1) id AA01923; Sat, 1 Feb 97 12:17:41 +0100 From: leo@prosun.first.gmd.de (Matthias L. Jugel) Message-Id: <9702011117.AA01923@prosun.first.gmd.de> Subject: lockfree datastructures To: netdev@roxanne.nuclecu.unam.mx Date: Sat, 1 Feb 1997 12:17:40 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi folks, a friend of mine forwarded me your interest in lock free data structures. Maybe the following papers will help you: * General Aspects - "Axioms for Concurrent Objects", CMU-CS-86-154 - "Reasoning About Concurrent Objects", CMU-CS-87-176 - "Linearizeability: A Correctness Condition for Concurrent Objects", CMU-CS-88-120 Maurice P. Herlihy, Jeanette M. Wing Dept. of Computer Science, Carnegie-Mellong-Univ. * Methods - "A Methodology for Implementing Highly Concurrent Data Objects", ACM Transactions on Programing Languages and Systems, Vol 15, No 5, Nov 1993 Pages 746-770 - "A Method for Implementing Lock-Free Shared Data Structures", Proceedings of the 14th Annual ACM Symposium on Principles of Distributed Computing, Ottawa, Ont. Canada, pp184-193 G. Barnes, 1995 also: MPI-I-94-120, Apr 1994, Max-Planck-Institut fuer Informatik - "Practical Considerations for nonblocking concurrent objects" Proceedings 13th IEEE International Conference on Distri- buted Systems, IEEE Computer Society Press, pp 264-273 B.N. Bershad, 1993 * Operating Systems - "The Synergy Between Non-Blocking Synchronisation and Operating System Structure", CA 94305-9040 Michael Greenwald, David Cheriton CS Dept, Stanford University - ... There is another paper I have to fetch ... Ok, I hope the papers give you a clue about the problem. From experience and discussion with our own OS builders I get the impression that for most problems a CAS or CAS2 (Compare-And-Swap) is sufficient compared to the proposed methods explained in the papers above. I'd be very interested in any problems and solutions you have in mind, because I am working on the subject in my PhD studies. If someone could give me a more detailled description of the problems you want to solve using non-blocking techniques. Best wishes, Leo. -- Matthias L. Jugel, leo@first.gmd.de GMD - German National Research Centre for Information Technology FIRST - Research Institute for Computer Architecture and Software Technology From owner-freebsd-hackers Sat Feb 1 13:24:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10170 for hackers-outgoing; Sat, 1 Feb 1997 13:24:37 -0800 (PST) Received: from Clifford.LiveNet.Net (root@Clifford.LiveNet.Net [206.156.5.13]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10165 for ; Sat, 1 Feb 1997 13:24:34 -0800 (PST) Received: from samantha (Taupe.Colours.LiveNet.Net [206.156.5.130]) by Clifford.LiveNet.Net (8.7.6/8.6.9) with ESMTP id QAA15986 for ; Sat, 1 Feb 1997 16:31:01 -0500 (EST) Message-Id: <199702012131.QAA15986@Clifford.LiveNet.Net> From: "Joseph I. Arias" To: Subject: Subject: Re: Installing from DOS partition Date: Sat, 1 Feb 1997 16:27:00 -0800 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ..because it's probably still a VFAT filesystem, i assume. > > Install DOS 5. :) So dos 6.22 is a VFAT system? I was told different and that could be the only thing that it is? > > > Should I download FreeBSD 2.2? I'm a beginger to Unix is 2.2 stable enough > > for me to pratic on? > > It's probably 20 times more stable than Win 3.1, and 5 times more > stable than Win 95. :-) > Well Being new to unix I really won't know that. and I was told by the very same people that told me BSD is the way to go not to do a 2.2 install. they just installed 2.1.6 and are having problems booting off of it > > I'm wanting to start up my own ISP using BSD it was a > > recomendation for the ISP now he runs it and I have gotten use to it. > > Hmm, i think you've got quite some way to go until you will even be > able to start your ISP business. Be assured, by the time you've got > the knowledge how to handle all this, there will be FreeBSD 2.2.5. :) > You may be right but all I'm missing in Unix is the command part a ran a very large BBS in Virginia after only owning a computer for 4 months and this was with NO knowlage of any in any type of computers, I'm 36 and live at home retired from work at the age of 29 I must have some kind of smarts :) > No offense intended, but i think somebody who's going to be serious > about ISP business won't even install a DOS partition at all first. > Waste of space. You even didn't learn how to give your mail a subject > line yet... how are you going to teach your customers about Internet > Netiquette? I ran a very profitble BBS in Viginia when all other were FREE and have been told I was one of the most user friendy and also gave my users support as for internet Netiquette? they will have to do like all the rest and learn it by the old rules trial and error... the best way to learn and thing in life. :) As for Dos I have it installed on account my 3 kids have there class work on it and I also like to fiddle in Windows and also like Dos it is the only operating system I know for now..... but it won't be soon! :) Thanks Joe From owner-freebsd-hackers Sat Feb 1 13:53:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10955 for hackers-outgoing; Sat, 1 Feb 1997 13:53:34 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA10950 for ; Sat, 1 Feb 1997 13:53:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA06709; Sat, 1 Feb 1997 14:51:50 -0700 From: Terry Lambert Message-Id: <199702012151.OAA06709@phaeton.artisoft.com> Subject: Re: performance puzzler To: gurney_j@resnet.uoregon.edu Date: Sat, 1 Feb 1997 14:51:50 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org In-Reply-To: from "John-Mark Gurney" at Jan 31, 97 08:53:37 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Your bus on the 120 is 3MHz slower than the bus on the 66. What you > > are doing is not I/O bound, it is CPU bound. > > umm... this usually isn't true... most of the non 33mhz bus speeds (for > 486 based chips) are actually 40 mhz or 50mhz... the amd-486/120dx4 is > actually a 40mhz bus multiplied by 3... it's kinda like the Intel > 486/100dx4... the chip is actually 3x bus speed (33mhz)... Memory bus, or I/O bus? The PCI and EISA standards specify 33MHz as their top end. 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 Feb 1 14:05:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA11455 for hackers-outgoing; Sat, 1 Feb 1997 14:05:46 -0800 (PST) Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA11448 for ; Sat, 1 Feb 1997 14:05:40 -0800 (PST) Received: from bsampley.vip.best.com (bsampley.vip.best.com [206.184.160.196]) by proxy3.ba.best.com (8.8.5/8.8.3) with SMTP id OAA00828; Sat, 1 Feb 1997 14:03:30 -0800 (PST) Message-ID: <32F3BD4B.41C67EA6@best.com> Date: Sat, 01 Feb 1997 14:01:47 -0800 From: Burton Sampley X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-BETA_A i386) MIME-Version: 1.0 To: "Joseph I. Arias" , hackers@FreeBSD.ORG Subject: Re: Subject: Re: Installing from DOS partition References: <199702012131.QAA15986@Clifford.LiveNet.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joseph I. Arias wrote: SNIP [...] SNIP [deleted a lot of stuff]; > as for internet Netiquette? they will have to do like all the rest and > learn it by the old rules trial and error... the best way to learn and > thing in life. :) I don't want to burst your bubble here, but with an attitude like that, you're not going to last very long as an ISP! Customers today are expecting A LOT of their ISP in terms of customer service. If you tell them you're on your own, figure it out yourself, then most will say goodbye I'm taking my business to place where I can get some help. There are just too many ISP's around for a customer to have to deal with that kind of attitude! Right now I have about 100+ ISP's to chose from. If my current ISP told me to go learn it by trial and error, I would close my account and move on to another ISP. -- Burton Sampley Email: bsampley@best.com | home page: http://www.best.com/~bsampley All opinions expresseed above are my own. From owner-freebsd-hackers Sat Feb 1 14:13:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA11773 for hackers-outgoing; Sat, 1 Feb 1997 14:13:49 -0800 (PST) Received: from buffnet4.buffnet.net (root@buffnet4.buffnet.net [205.246.19.13]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA11764; Sat, 1 Feb 1997 14:13:41 -0800 (PST) Received: from buffnet1.buffnet.net (buffnet1.buffnet.net [205.246.19.10]) by buffnet4.buffnet.net (8.6.12/8.6.9) with SMTP id RAA05301; Sat, 1 Feb 1997 17:15:24 -0500 Received: from buffnet11.buffnet.net by buffnet1.buffnet.net id aa03139; 1 Feb 97 17:14 EST Date: Sat, 1 Feb 1997 17:13:56 -0500 (EST) From: Steve To: Tom Samplonius cc: freebsd-questions@freebsd.org, hackers@freebsd.org Subject: Re: slow ypserv problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 1 Feb 1997, Tom Samplonius wrote: > Bill knows. > > ypserv was completely re-written for 2.2. > > Tom > > It it possible to get just that piece for 2.1? or wouldnt it work under 2.1? From owner-freebsd-hackers Sat Feb 1 15:23:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA13743 for hackers-outgoing; Sat, 1 Feb 1997 15:23:37 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA13737 for ; Sat, 1 Feb 1997 15:23:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.4/8.8.4) with SMTP id PAA04271; Sat, 1 Feb 1997 15:22:06 -0800 (PST) Date: Sat, 1 Feb 1997 15:22:06 -0800 (PST) From: John-Mark Gurney Reply-To: John-Mark Gurney To: Terry Lambert cc: hackers@freefall.freebsd.org Subject: Re: performance puzzler In-Reply-To: <199702012151.OAA06709@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 1 Feb 1997, Terry Lambert wrote: > > > Your bus on the 120 is 3MHz slower than the bus on the 66. What you > > > are doing is not I/O bound, it is CPU bound. > > > > umm... this usually isn't true... most of the non 33mhz bus speeds (for > > 486 based chips) are actually 40 mhz or 50mhz... the amd-486/120dx4 is > > actually a 40mhz bus multiplied by 3... it's kinda like the Intel > > 486/100dx4... the chip is actually 3x bus speed (33mhz)... > > Memory bus, or I/O bus? I'm not sure... they usually refere to it as the processor clock.. so I really wouldn't know if they change the speed for both memory or io access... but they don't have to do any speed fiddling if the board is straight isa or a vlb/isa comba... as vlb can be spec'd at 50mhz... > The PCI and EISA standards specify 33MHz as their top end. I didn't know the eisa top end.. but did know the pci limit... most 486/pci boards have a jumper that sets the pci bus to either the bus speed (i.e. 33 or 40mhz) or half that... so you can put a processor clock of 40 or 50mhz on the board (and get a pci bus speed of 20 or 25mhz)... 486based boards are quite different then pentium based boards :)... ttyl... John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Sat Feb 1 15:35:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA14283 for hackers-outgoing; Sat, 1 Feb 1997 15:35:45 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA14278 for ; Sat, 1 Feb 1997 15:35:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA06872; Sat, 1 Feb 1997 16:33:52 -0700 From: Terry Lambert Message-Id: <199702012333.QAA06872@phaeton.artisoft.com> Subject: Re: Mounting CD-ROM when data not on first track To: taob@risc.org (Brian Tao) Date: Sat, 1 Feb 1997 16:33:52 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Brian Tao" at Feb 1, 97 01:47:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On a whim, I bought the "Star Trek: First Contact" soundtrack > today on CD. It has a filesystem on track 14 of the disc with > Quicktime trailers of the movie. Trying to mount this on FreeBSD > 2.2-BETA gives me this error: > > cd0(ncr0:6:0): BLANK CHECK req sz: 16 (decimal) asc:64,0 Illegal mode for this track > cd0(ncr0:6:0): error code 0 > > I presume this is because mount_cd9660 only looks for data on > the first track of the CD? How would I mount the data track from such > a CD? This is the toc dump from cdcontrol: > > Starting track = 1, ending track = 14, TOC size = 122 bytes > track start duration block length type > ------------------------------------------------- > 1 0:02.00 4:21.27 0 19452 audio [ ... ] > 14 53:54.17 18:30.36 242417 83136 data > 170 72:22.53 - 325553 - - I believe this is a perfectly legal thing to do, actually. One wonders why the cd device starts at the raw track one instead of the first data track in any case... | a)Multisession Volume Recognition Sequence | The Volume Recognition Sequence shall begin at the 16th logical sector | of the first track of the last session on the disc. | | This volume recognition sequence supersedes all other volume recognition | sequences on the disc. The interpretation of the Volume Recognition | Sequence is otherwise unchanged. | | For example, consider a disc that contains 3 sessions, where session 1 | starts at 00:00:00, session 2 starts at 10:00:00, and session 3 starts | at 20:00:00. The Volume Recognition Sequence for this disc would start | at Minute:Second:Frame address 20:00:16. | | This technique is compatible with the CD-Bridge multisession technique. Have you determined whether the disc has a PVD or an SVD on it? The PVD is supposed to be overridden by an SVD, if present. This is consistent with the idea that the quicktime data is viewable from Windows95 or NT. Most likely, there exists Unicode extensions on the disk to enable use of "long names". The Microsoft specification for this type of disc is "Joliet". You can determine if this is the case by looking at the contents of the SVD: | Use a SVD with a UCS-2 (UNICODE) Escape Sequence. | The UCS-2 escape sequences used are: (25)(2F)(40), (25)(2F)(43), | or (25)(2F)(45). | The default setting of bit 0 of the SVD "Volume Flags Field" is ZERO. | The Unicode Wide characters shall be recorded in "Big Endian" | (Motorola) format. | Special Directory Identifiers are recorded as single byte names | containing (00) or (01). | SEPARATOR 1 and SEPARATOR 2 are encoded using an equivalent 16-bit | code point. | Sort ordering is unchanged, except that all justification pad bytes | are to be set to (00). There are additional rules for directory hierarchy recognition, depth greater than 8, and 128 character length limits. There are the standard "DOSsy" restrictions on file and directory name characters. Finally, it seems to me that the CDROM device should impose "slices" on its own, and it makes sense to me that 'd' is the whole disk and that 'c' is the first data area. This would have allowed the disk to be mountable as well, even if it is a Joliet disk using an extended volume recognition sequence (since such disks are required to be backward compatible in all cases, according to the Joliet "standard"). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 1 15:36:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA14366 for hackers-outgoing; Sat, 1 Feb 1997 15:36:09 -0800 (PST) Received: from Clifford.LiveNet.Net (root@Clifford.LiveNet.Net [206.156.5.13]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA14361 for ; Sat, 1 Feb 1997 15:36:05 -0800 (PST) Received: from samantha (Manimal@Taupe.Colours.LiveNet.Net [206.156.5.130]) by Clifford.LiveNet.Net (8.7.6/8.6.9) with ESMTP id SAA15881; Sat, 1 Feb 1997 18:42:30 -0500 (EST) Message-Id: <199702012342.SAA15881@Clifford.LiveNet.Net> From: "Joseph I. Arias" To: "Burton Sampley" Cc: Subject: Re: Subject: Re: Installing from DOS partition Date: Sat, 1 Feb 1997 18:38:27 -0800 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > as for internet Netiquette? they will have to do like all the rest and > > learn it by the old rules trial and error... the best way to learn and > > thing in life. :) > > I don't want to burst your bubble here, but with an attitude like > that, you're not going to last very long as an ISP! Customers > today are expecting A LOT of their ISP in terms of customer > service. If you tell them you're on your own, figure it out > yourself, then most will say goodbye I'm taking my business to > place where I can get some help. There are just too many ISP's > around for a customer to have to deal with that kind of attitude! > Right now I have about 100+ ISP's to chose from. If my current > ISP told me to go learn it by trial and error, I would close my > account and move on to another ISP. Thank you for you truly wize input but the problem is I need help with UNIX not how I'm going to run my ISP... if you have any help for me please send it and I will appreciate it very much. The stuff the you Sniped deleted was the information I needed this message you sent me is useless please don't reply to this message. I was only talking to WJ on a comment he had for me but along with his comment he did in fact help me with my problem! Reguards Joe From owner-freebsd-hackers Sat Feb 1 15:37:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA14409 for hackers-outgoing; Sat, 1 Feb 1997 15:37:08 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA14404 for ; Sat, 1 Feb 1997 15:37:04 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id SAA12533 for ; Sat, 1 Feb 1997 18:36:59 -0500 (EST) Message-Id: <199702012336.SAA12533@spoon.beta.com> To: hackers@freebsd.org Subject: Device driver help needed... Date: Sat, 01 Feb 1997 18:36:59 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ok. I'm sure that now I've terribly bastardized the uio structure, but at least the damn thing compiles :) Let see if I can get some comment on my interpretation of the uio stucture: struct uio { struct iovec *uio_iov; /* Pointer to IO Vector (possible array?) */ int uio_iovcnt; /* Number of IO vectors (?) */ off_t uio_offset; /* Offset in to device */ int uio_resid; /* Length of read request (?) */ enum uio_seg uio_segflg; /* I assume a segment of some kind, but I can only find reference to UIO_SYSSPACE */ enum uio_rw uio_rw; /* UIO_READ or UIO_WRITE (type of operation(?)) */ struct proc *uio_procp; /* No idea, but I've seen it set to curproc */ }; Ok, guys. Beat me up, and let me know whats incorrect. With that in mind, I've bent my device driver to look like this: ------ foo.c --------------------------------------- #define KERNEL #include #include #include #include #include #include #include #include #include #include #include #include #ifdef DEVFS #include #endif #include #include #include static char message[] = "The quick brown fox jumps over a lazy dog\n"; #define CDEV_MAJOR 20 static d_read_t fooread; static struct cdevsw foo_cdevsw = { nxopen, nxclose, fooread, nxwrite, nxioctl, nxstop, nxreset, nxdevtotty, nxselect, nxmmap, NULL, "foo", NULL, -1 }; fooinit() { } static int fooread(dev,myuio, flag) dev_t dev; struct uio *myuio; int flag; { unsigned char *buffer_pointer; int toread; if ((myuio->uio_iovcnt != 1) || (MINOR(dev) != 0)) return ENODEV; while(myuio->uio_resid) { buffer_pointer = (message + (myuio->uio_offset % sizeof(message))); toread = ((long unsigned int)(message + sizeof(message)) - (long unsigned int)buffer_pointer); uiomove(buffer_pointer, toread, myuio); myuio->uio_offset + toread; myuio->uio_resid = myuio->uio_resid - toread; } } #define CDEV_MAJOR 20 ------------------------------------------------- Now, I'm sure there are bugs in there. Hell, I didn't know what I was doing half the time :) But, now its time to start debugging, which means I need to get it in to the kernel. Someone mentioned using SYSINIT to get it working as a pseudo-device driver. The file above is located in /usr/src/sys/i386/addons/foo.c. Anyone care to give me a set of steps (and code changes) to get it in the kernel? Thanks. -Brian From owner-freebsd-hackers Sat Feb 1 15:44:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA14786 for hackers-outgoing; Sat, 1 Feb 1997 15:44:51 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA14780; Sat, 1 Feb 1997 15:44:47 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id PAA17259; Sat, 1 Feb 1997 15:35:00 -0800 (PST) Message-ID: <32F3D2BE.15FB7483@whistle.com> Date: Sat, 01 Feb 1997 15:33:18 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Brian Somers CC: Archie Cobbs , brian@utell.co.uk, terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net, joerg_wunsch@uriah.heep.sax.de, phk@freebsd.org Subject: Re: ipdivert & masqd FIXED ! References: <199702011325.NAA01803@awfulhak.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Somers wrote: > > > > > > This wasn't the original intent, but in retrospect it makes more > > sense -- your patch that zeros ip_divert_ignore after calling > > ip_fw_chk() looks good to me... > > I'll commit the changes then - anyone have a problem with them going into > 2.2 too ? please do!! we'll be sing this and 2.2 and if it;s in it it's one less file we'll be patching locally. From owner-freebsd-hackers Sat Feb 1 15:51:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA15462 for hackers-outgoing; Sat, 1 Feb 1997 15:51:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA15446 for ; Sat, 1 Feb 1997 15:51:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA06912; Sat, 1 Feb 1997 16:50:04 -0700 From: Terry Lambert Message-Id: <199702012350.QAA06912@phaeton.artisoft.com> Subject: Re: #include dependencies To: proff@iq.org (Julian Assange) Date: Sat, 1 Feb 1997 16:50:03 -0700 (MST) Cc: bde@zeta.org.au, hackers@freebsd.org In-Reply-To: <199702010815.TAA06303@profane.iq.org> from "Julian Assange" at Feb 1, 97 07:15:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm going to skirt the periphery of this argument. I think the point being debated may very well be "the wrong point", since it seems to assume some things which themselves assume continued bad interface design on the part of kernel engineers... > > Most of the #include changes are wrong. > > > > Most of the headers are only used in the kernel. Kernel sources > > follow the convention of including or > > before any other header. > > I'm aware of this, this is why you see a number of #ifndef KERNEL. > I strongly philosophically disagree with the need for this but > have done so out of what appears to be (foolish imho) tradition. The typical use of the _KERNEL manifest value checks is to allow a single header file to define an interface, AND an implementation. The interface is user space, and the implementation is kernel space. Typically, you will also see this for exposed kernel data structures, such as those incorrectly used in 'ps', 'w', and so on, causing their dependency on things like the proc structure layout, which should be opaque to them. > Personally I believe the only #ifdef KERNEL we should be seeing is > around externs and function definitions, because that is where the > only REAL difference between user-level and kernel-level include code > dependencies should be occurring. Any structure that is used in the kernel and is not "#ifndef _KERNEL" excepted, is defining reading that structure out of /dev/kmem as an accepted interface. I think that exposing the kernel internals this way is a *bad* idea, since it increases the number of programs that will potentially need to be recompiled as a result of a kernel change, and this is a bad thing. Typically, there should be an interface for the data passed across a kernfs and/or procfs, and the data structure for passing this data should remain fixed, regardless of the implementation structure being changed to accomodate ongoing developement. The single failure case for this is running the programs against a kernel core file. This is probably not an issue that should be perpetuated. It is the responsibility of the kernel debugger to provide these utilities. Preferrably, it will do so at some point by the kernel being implemented in ELF, and there being debugging segments which are run by the debugger, but not loaded by the kernel loader, which are loaded into the debugger as modules specific to the kernel file being debugged... after all, you can not debug a kernel core without the kernel file from which the core originated, and you might as well take advantage of this. As an alternative to kernfs/procfs interfaces, which would tend to pollute the kernel with useless-to-the-kernel code and data, the 'ps', 'w', and so on could query for the kernel image file with sysctl if an image file is not provided, and similarly, load these interpretation and iteration modules. The 'ps', 'w', and so on would then be able to continue to take a core and image argument, as now, but the ability to use the information contained in the core would not depend on the recompilation of the utilities. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 1 15:58:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA16047 for hackers-outgoing; Sat, 1 Feb 1997 15:58:54 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA16038 for ; Sat, 1 Feb 1997 15:58:51 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id QAA10150; Sat, 1 Feb 1997 16:58:35 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 01 Feb 1997 16:52:33 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: hackers@freebsd.org, xfmail@Burka.NetVision.net.il, djb-qmail@koobera.math.uic.edu Subject: Very Strange Mail Problem Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Attached are two pieces of email. If I feed either one of them to xfmail 1.0 (or later, did not try older) all is well. If I concatenate them, xfmail dumps core on sig 11. This is only an example. Since I subscribed to cvs-all, I get these crashes almost every time. It is on FreeBSD 2.2-BETA. It seems that Pine is also prone to the same error, although it needs bigger files. I am posting this to these three lists as the mail was processed as folows: qmail 0.95 o ~shimon/Maildir maildir2mbox xfmail I have no clue why this happens, except that the Subject: line appears long. So, if any of you can help, I will appreciate it very much. Thanx! Simon From owner-freebsd-hackers Sat Feb 1 16:01:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16544 for hackers-outgoing; Sat, 1 Feb 1997 16:01:41 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA16528 for ; Sat, 1 Feb 1997 16:01:38 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vqhd3-0004OE-00; Sat, 1 Feb 1997 07:45:21 -0800 Date: Sat, 1 Feb 1997 07:45:21 -0800 (PST) From: Tom Samplonius To: Steve cc: hackers@freebsd.org Subject: Re: slow ypserv problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 1 Feb 1997, Steve wrote: > On Sat, 1 Feb 1997, Tom Samplonius wrote: > > Bill knows. > > > > ypserv was completely re-written for 2.2. > > > > Tom > > > > > It it possible to get just that piece for 2.1? or wouldnt it work under > 2.1? It won't compile without modification on 2.1.x I asked about this along time ago, and Bill said that you'd have to drag over some rcp library stuff too. Tom From owner-freebsd-hackers Sat Feb 1 16:02:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16675 for hackers-outgoing; Sat, 1 Feb 1997 16:02:31 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA16665 for ; Sat, 1 Feb 1997 16:02:28 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA06935; Sat, 1 Feb 1997 17:00:32 -0700 From: Terry Lambert Message-Id: <199702020000.RAA06935@phaeton.artisoft.com> Subject: Re: #include dependencies To: bde@zeta.org.au (Bruce Evans) Date: Sat, 1 Feb 1997 17:00:32 -0700 (MST) Cc: bde@zeta.org.au, proff@iq.org, hackers@freebsd.org In-Reply-To: <199702010949.UAA17084@godzilla.zeta.org.au> from "Bruce Evans" at Feb 1, 97 08:49:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Most of the headers are only used in the kernel. Kernel sources > > >I'm aware of this, this is why you see a number of #ifndef KERNEL. > > #ifndef KERNEL in kernel-only headers is nonsense (unless it is used > to control a #warning or #error). Or to prevent a structure definition plus a kvm grovelling library being misconstrued as an interrface. 8-). > After living for a while in an environment with sloppy headers, > programs depend on things like obtaining declarations related to > ANSI time functions by including . I happen to agree with you on this one... > New interfaces should use sysctl() and be designed better to only > pass the parts of the kernel struct of interest to applications > across the interface. You happen to disagree with you on this one... 8-). Use of the "#ifndef" makes sysctl a better bet. Not using it makes sysctl a rule which programmers will feel free to ignore. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 1 16:04:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16855 for hackers-outgoing; Sat, 1 Feb 1997 16:04:03 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA16841 for ; Sat, 1 Feb 1997 16:03:58 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA06949; Sat, 1 Feb 1997 17:02:38 -0700 From: Terry Lambert Message-Id: <199702020002.RAA06949@phaeton.artisoft.com> Subject: Re: Suggested ehternet chips/cards? To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 1 Feb 1997 17:02:37 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: from "J Wunsch" at Feb 1, 97 01:58:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What about AMD? The `Lance' (Am7990PC) chip has got good reputation, > and has been used in many workstations, i think. I'm not certain > about the quality of their newer products (PCnet?). I thought it was impossible to non-descructively probe for a LANCE chipset because you have to poke it and see if it squirms to tell one is there... if one isn't, you may poke the wrong thing. 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 Feb 1 16:07:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA17309 for hackers-outgoing; Sat, 1 Feb 1997 16:07:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA17296 for ; Sat, 1 Feb 1997 16:07:00 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA06968; Sat, 1 Feb 1997 17:05:42 -0700 From: Terry Lambert Message-Id: <199702020005.RAA06968@phaeton.artisoft.com> Subject: Re: bisdn To: grog@lemis.de Date: Sat, 1 Feb 1997 17:05:42 -0700 (MST) Cc: plm@xs4all.nl, hackers@FreeBSD.ORG In-Reply-To: <199702011556.QAA19237@freebie.lemis.de> from "grog@lemis.de" at Feb 1, 97 04:56:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > At least I don't know of any ISP's that offer other ways for > > TCP/IP connection. > > There aren't too many in the USA. That doesn't mean that there > shouldn't be. I believe most ISDN routers can be set up to run > without PPP. Certainly the ISPs over here, nearly all of who offer > transparent HDLC, use the same routers as are used in the USA. The default hardware in the US doesn't do the HDLC for you. Think about what hardware the phone company provides for an ISDN user over there, but doesn't provide for an ISDN user over here... 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 Feb 1 16:22:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18758 for hackers-outgoing; Sat, 1 Feb 1997 16:22:06 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA18751 for ; Sat, 1 Feb 1997 16:22:00 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA06695 for freebsd-hackers@freebsd.org; Sun, 2 Feb 1997 01:21:58 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id BAA03480; Sun, 2 Feb 1997 01:12:43 +0100 (MET) Message-ID: Date: Sun, 2 Feb 1997 01:12:43 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: Mounting CD-ROM when data not on first track References: <199702012333.QAA06872@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702012333.QAA06872@phaeton.artisoft.com>; from Terry Lambert on Feb 1, 1997 16:33:52 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > I believe this is a perfectly legal thing to do, actually. One wonders At least not in the sense of CD9660 (which i think has a crippled idea in this respect). > why the cd device starts at the raw track one instead of the first data > track in any case... Because it always starts at the beginning, and covers the entire data area. You could look at it as if it were a huge sparse file in this special situation: seek to the right location, and you'll be able to read the data. Btw., this is exactly what the normal ``multi-session'' idea of CD9660 is: you've got the entire drive mapped, and the first track of the most recent session contains the CD9660 directory structure, where the block pointers are allowed to point back on the CD, or to point into this track itself. (Strictly spoken, they are allowed to point into the first track of each successive session only. See above.) That's why they call this entire beast a session then, despite of the matter that a single session might have multiple tracks. They always siltently assume at most the first track of each session being in CD-ROM data format. Our cd9660 filesystem code simply needs to examine the TOC (this can be done from userland, since there's an ioctl for it), and if it succeeds in this operation, it should default to the diretory structure from the first track of the last session. Voila!, this would allow us to read multi-session ISO-9660 CDs. The downside: _creating_ such a filesystem is way harder. mkisofs currently always runs in standalone mode. For ISO-9660 CDs however, it needs to examine the existing tree structure first (which can already be multi-session), and needs to figure out which files are to be replaced. It must then add them up to the new track, along with an entire new directory tree. (Maybe partial new would suffice, if parts of the tree remain untouched.) Things are even worse if audio tracks lie between the data tracks, since mkisofs must retains the holes in the block numbers, even if the data contents is unknown. > Finally, it seems to me that the CDROM device should impose "slices" > on its own, and it makes sense to me that 'd' is the whole disk and > that 'c' is the first data area. It makes no sense, i've already thought about this. There are up to 99 tracks allowed, so we need up to 99 subdevices. Maybe 100, to account for one covering the entire disk (subdevice 0 fits best for this, since it's not a legal track number). -- 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 Feb 1 16:23:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18824 for hackers-outgoing; Sat, 1 Feb 1997 16:23:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA18817 for ; Sat, 1 Feb 1997 16:23:00 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA07020; Sat, 1 Feb 1997 17:21:16 -0700 From: Terry Lambert Message-Id: <199702020021.RAA07020@phaeton.artisoft.com> Subject: Re: Subject: Re: Installing from DOS partition To: BigDaddy@LiveNet.Net (Joseph I. Arias) Date: Sat, 1 Feb 1997 17:21:16 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199702012131.QAA15986@Clifford.LiveNet.Net> from "Joseph I. Arias" at Feb 1, 97 04:27:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > ..because it's probably still a VFAT filesystem, i assume. > > > > Install DOS 5. :) > > So dos 6.22 is a VFAT system? I was told different and that could be the > only thing that it is? There is no difference between a FAT and a VFAT system. They have the same data layout. The difference is in the use of the directory layout. FAT creates directory entries that, uniformly, never have all their attribute bits set. In FAT, a directory entry *is* the on disk inode (this is why DOS can't do hard links). VFAT creates additional directory entries for the "long names" for files. It does this by setting all the attribute bits on the entry, and storing the long name data in the entry itself on the disk. So it tends to use up a lot of directory entries. It turns out that every piece of software Microsoft tested ignores entries with all attribute bits set. Because of the way the DOS findfirst/findnext operates, and the fact that one of the bits is the "volume label" bit, software which uses the INT 21 DOS interfaces never see these entries. Other than reducing the number of real files that you can put in the root directory by their very presence (the root has an existing hard limit on the number of files, which dates back to before DOS knew about directories), these additional entries will have ZERO, NONE, ZILCH, NOTTA, *NO* EFFECT ON WHETHER OR NOT YOU CAN MOUNT THE DISK. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 1 16:26:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA19040 for hackers-outgoing; Sat, 1 Feb 1997 16:26:55 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA19033 for ; Sat, 1 Feb 1997 16:26:50 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id RAA10350; Sat, 1 Feb 1997 17:26:35 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.1-alpha.p0.FreeBSD:970201172608:9953=_" Date: Sat, 01 Feb 1997 17:19:56 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: hackers@freebsd.org, xfmail@Burka.NetVision.net.il, djb-qmail@koobera.math.uic.edu Subject: Re: Strange Mail Problem Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This message is in MIME format --_=XFMail.1.1-alpha.p0.FreeBSD:970201172608:9953=_ Content-Type: text/plain; charset=iso-8859-8 Sorry about the previous posting which went out empty... Basically: FreeBSD 2.2-BETA as a platfrom, Qmail 0.95 as MTA delivering to ~shimon/Maildir /var/qmial/bin/maildir2mbox converting to ~shimon/Mailbox xfmail 1.0 or later reading from ~shimon/Mailbox Xfmail has no problem reading either Mailbox.1 or Mailbox.2, BUT; If you do cat Mailbox.? > MAilbox and run xfmail, you will get a signal 11. It happenswith many mails from cvs-all but I only managed to isolate this pair as a resonably short and very predictable one. --_=XFMail.1.1-alpha.p0.FreeBSD:970201172608:9953=_ Content-Disposition: attachment; filename="Mailbox.2" Content-Transfer-Encoding: base64 Content-Type: application/octet-stream; name=Mailbox.2; SizeOnDisk=7337 RnJvbSBpbmV0LWFjY2Vzcy1ib3VuY2VzQGVhcnRoLmNvbSBTYXQgRmViIDAxIDE1OjI4OjIxIDE5 OTcKUmV0dXJuLVBhdGg6IDxpbmV0LWFjY2Vzcy1ib3VuY2VzQGVhcnRoLmNvbT4KRGVsaXZlcmVk LVRvOiBzaGltb25Ac2VuZGVyby5pLWNvbm5lY3QubmV0ClJlY2VpdmVkOiAocW1haWwgNjEwNCBp bnZva2VkIGZyb20gbmV0d29yayk7IDEgRmViIDE5OTcgMTU6Mjg6MTkgLTAwMDAKUmVjZWl2ZWQ6 IGZyb20gbm9taXMuaS1jb25uZWN0Lm5ldCAocW1haWxyQDIwNi4xOTAuMTQzLjEwKQogIGJ5IHNv ZnRkbnNlcnJvciB3aXRoIFNNVFA7IDEgRmViIDE5OTcgMTU6Mjg6MTkgLTAwMDAKUmVjZWl2ZWQ6 IChxbWFpbCAxNTYxMyBpbnZva2VkIGJ5IHVpZCAxMDApOyAxIEZlYiAxOTk3IDE0OjI2OjMyIC0w MDAwCkRlbGl2ZXJlZC1Ubzogc2hpbW9uQG5vbWlzLmktY29ubmVjdC5uZXQKUmVjZWl2ZWQ6IChx bWFpbCAxNTYxMSBpbnZva2VkIGZyb20gbmV0d29yayk7IDEgRmViIDE5OTcgMTQ6MjY6MzEgLTAw MDAKUmVjZWl2ZWQ6IGZyb20gY2FydHJpZGdlLmktY29ubmVjdC5uZXQgKHFtYWlsckAyMDYuMTkw LjE0My4xMikKICBieSBub21pcy5pLWNvbm5lY3QubmV0IHdpdGggU01UUDsgMSBGZWIgMTk5NyAx NDoyNjozMSAtMDAwMApSZWNlaXZlZDogKHFtYWlsIDI2NzM1IGludm9rZWQgYnkgdWlkIDEwMCk7 IDEgRmViIDE5OTcgMTQ6MjY6MzEgLTAwMDAKRGVsaXZlcmVkLVRvOiBzaGltb25AaS1jb25uZWN0 Lm5ldApSZWNlaXZlZDogKHFtYWlsIDI2NzMyIGludm9rZWQgZnJvbSBuZXR3b3JrKTsgMSBGZWIg MTk5NyAxNDoyNjozMCAtMDAwMApSZWNlaXZlZDogZnJvbSBtYWlsZ2F0ZS5CU0RJLkNPTSAoMjA1 LjIzMC4yMjUuMTgpCiAgYnkgY2FydHJpZGdlLmktY29ubmVjdC5uZXQgd2l0aCBTTVRQOyAxIEZl YiAxOTk3IDE0OjI2OjMwIC0wMDAwClJlY2VpdmVkOiBmcm9tIGF1c3Rpbi5ic2RpLmNvbSAoZGFl bW9ue3h0T1MxZ0RBcGNXdDB2VEZLMVNxZzVRK1RIZ2ljMFpvfUBhdXN0aW4uQlNESS5DT00gWzIw NS4yMzAuMjI0LjQ5XSkgYnkgbWFpbGdhdGUuQlNESS5DT00gKDguOC41LzguOC4yKSB3aXRoIEVT TVRQIGlkIEhBQTA5Mjg5OyBTYXQsIDEgRmViIDE5OTcgMDc6MTg6MzMgLTA3MDAgKE1TVCkKUmVj ZWl2ZWQ6IChmcm9tIGRhZW1vbkBsb2NhbGhvc3QpIGJ5IGF1c3Rpbi5ic2RpLmNvbSAoOC44LjUv OC44LjUpIGlkIEhBQTAyMjY0OyBTYXQsIDEgRmViIDE5OTcgMDc6MjI6NDAgLTA3MDAgKE1TVCkK UmVzZW50LURhdGU6IFNhdCwgMSBGZWIgMTk5NyAwNzoyMjo0MCAtMDcwMCAoTVNUKQpSZXNlbnQt TWVzc2FnZS1JZDogPDE5OTcwMjAxMTQyMi5IQUEwMjI2NEBhdXN0aW4uYnNkaS5jb20+Ckxpc3Qt QWRtaW46IGluZXQtYWNjZXNzLXJlcXVlc3RAZWFydGguY29tIChzdWJzY3JpYmUvdW5zdWJzY3Jp YmUgcmVxdWVzdHMpCkVycm9ycy1UbzogaW5ldC1hY2Nlc3MtYm91bmNlc0BlYXJ0aC5jb20KT3Jp Z2luYXRvcjogaW5ldC1hY2Nlc3NAZWFydGguY29tClByZWNlZGVuY2U6IGJ1bGsKUmVwbHktVG86 IGluZXQtYWNjZXNzQGVhcnRoLmNvbQpSZXNlbnQtRnJvbTogaW5ldC1hY2Nlc3NAZWFydGguY29t ClNlbmRlcjogaW5ldC1hY2Nlc3NAZWFydGguY29tClJlY2VpdmVkOiBmcm9tIG5zLmRlZm5ldC5j b20gKG5zLmRlZm5ldC5jb20gWzIwNy4xOS4xNjcuMl0pIGJ5IGF1c3Rpbi5ic2RpLmNvbSAoOC44 LjUvOC44LjUpIHdpdGggU01UUCBpZCBIQUEwMjI0MSBmb3IgPGluZXQtYWNjZXNzQGVhcnRoLmNv bT47IFNhdCwgMSBGZWIgMTk5NyAwNzoyMjozMCAtMDcwMCAoTVNUKQpSZWNlaXZlZDogZnJvbSBz eXJpbnggKHN5cmlueCBbMjA3LjE5LjE2Ny40XSkgYnkgbnMuZGVmbmV0LmNvbSAoOC42LjEzLzgu Ni4xMikgd2l0aCBTTVRQIGlkIEpBQTI1MTY4IGZvciA8aW5ldC1hY2Nlc3NAZWFydGguY29tPjsg U2F0LCAxIEZlYiAxOTk3IDA5OjI0OjQxIC0wNTAwCk1lc3NhZ2UtSWQ6IDwyLjIuMzIuMTk5NzAy MDExMzIyMjguMDA3NDdiNzBAbWFpbC5kZWZuZXQuY29tPgpYLVNlbmRlcjogbWVya2VsQG1haWwu ZGVmbmV0LmNvbQpYLU1haWxlcjogV2luZG93cyBFdWRvcmEgUHJvIFZlcnNpb24gMi4yICgzMikK TWltZS1WZXJzaW9uOiAxLjAKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1h c2NpaSIKRGF0ZTogU2F0LCAwMSBGZWIgMTk5NyAwOToyMjoyOCAtMDQwMApUbzogaW5ldC1hY2Nl c3NAZWFydGguY29tCkZyb206ICJFcmljIEouIE1lcmtlbCIgPG1lcmtlbEBkZWZuZXQuY29tPgpT dWJqZWN0OiBOZXRzZXJ2ZXIgMTYvUmFkaXVzIFByb2JsZW0/CgpJJ3ZlIGdvdHRlbiBhIHN0cmFu Z2UgcHJvYmxlbSBsYXRlbHkuICBQZW9wbGUgYXJlIGNvbXBsYWluZyB0aGF0IApvY2NhdGlvbmFs eSB0aGV5IGdldCBkaXNjb25uZWN0ZWQgd2hlbiB0cnlpbmcgdG8gZ2V0IGxvZ2dlZCBvbgp0byBv dXIgVVNSIE5ldHNlcnZlciAxNidzLgoKTW9zdCBvZiB0aGUgdGltZSwgcGVvcGxlIGdldCBpbiBy aWdodCBhd2F5LCBidXQgSSd2ZSBub3RpY2VkIAp0aGUgZm9sbG93aW5nIG1lc3NhZ2UgbW9yZSBw cmV2YWxlbnQgaW4gb3VyIC92YXIvbG9nL2F1dGhsb2cKZmlsZSBoZXJlIGxhdGVseS4KCioqCkph biAzMSAyMDowODozNiB0ZXJtc2VydjAyIGRpYWxuZXQ6IHBvcnQgUzggcHZhc29sZCBzdWNjZWVk ZWQgZGVzdCAwLjAuMC4wCkphbiAzMSAyMDowODozOSB0ZXJtc2VydjAyIGRpYWxuZXQ6IHBvcnQg UzggcHBwX3N5bmMgZmFpbGVkIGRlc3QgICAgIAoqKgoKRm9yIHNvbWUgcmVhc29uLCB0aGV5IGFy ZSBnZXR0aW5nIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIDAuMC4wLjAgd2hlbgp0aGV5IHNo b3VsZCBiZSBnZXR0aW5nIGFuIElQIGFkZHJlc3MgZnJvbSB0aGUgYXNzaWduZWQgcG9vbCBvZiBu dW1iZXJzCmZvciB0aGF0IG5ldHNlcnZlci4KClRoZSB1c2VyIGFyZSBib3RoIFdpbmRvd3MgOTUg YW5kIDMuMSB1c2Vycy4gIENvdWxkIHRoaXMgYmUgYSByYWRpdXMgcHJvYmxlbT8KSXMgcG9zc2li bHkgUmFkaXVzIGdldHRpbmcgb3ZlcmxvYWRlZCBhdCBidXN5IHRpbWVzIG9yIGlzIHRoZXJlIGEg cG9zc2libGUKbWlzY29uZmlndXJhdGlvbiBvbiB0aGUgbmV0c2VydmVyPyBOb3RlOiB0aGV5J3Zl IGJlIHJ1bm5pbmcgZmluZSBmb3IgYSBjb3VwbGUKb2YgbW9udGhzLi4uCgpJIGp1c3QgbG9va2lu ZyBmb3Igc29tZSBpZGVhcyBvciBhZHZpY2UuICBUaGFua3MhCgpFcmljCgoKCiAgIAo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQpFcmljIE1lcmtlbCAgICAgICAgICAgICAgICBQaG9uZTogNDE5LTc4Mi0z NDcyICAgICAgaHR0cDovL3d3dy5kZWZuZXQuY29tCk1ldGFMaW5rIFRlY2hub2xvZ2llcyAgICAg ICAgICAgICA0MTktNTkyLTM0NzAgICAgICBodHRwOi8vd3d3LmhlbnJ5LW5ldC5jb20KRU1haWw6 IG1lcmtlbEBkZWZuZXQuY29tICAgICAgICAgIDQxOS0zMzUtMzQ3MCAgICAgIGh0dHA6Ly93d3cu ZnVsdG9uLW5ldC5jb20KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCgo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0gSVNQIE1haWxpbmcgTGlzdCA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KRW1haWwgYGB1bnN1YnNjcmliZScnIHRvIGluZXQtYWNjZXNzLXJlcXVlc3RAZWFydGguY29t IHRvIGJlIHJlbW92ZWQuClJlbW92ZSBoZWFkZXJzIGFuZCBzaWduYXR1cmVzIGZyb20gcXVvdGVk IHRleHQuCgpGcm9tIGRlYmlhbi1kZXZlbC1jaGFuZ2VzLW93bmVyLXNoaW1vbj1pLWNvbm5lY3Qu bmV0QGxpc3RzLmRlYmlhbi5vcmcgU2F0IEZlYiAwMSAxNToyODoyOCAxOTk3ClJldHVybi1QYXRo OiA8ZGViaWFuLWRldmVsLWNoYW5nZXMtb3duZXItc2hpbW9uPWktY29ubmVjdC5uZXRAbGlzdHMu ZGViaWFuLm9yZz4KRGVsaXZlcmVkLVRvOiBzaGltb25Ac2VuZGVyby5pLWNvbm5lY3QubmV0ClJl Y2VpdmVkOiAocW1haWwgNjEwNyBpbnZva2VkIGZyb20gbmV0d29yayk7IDEgRmViIDE5OTcgMTU6 Mjg6MjcgLTAwMDAKUmVjZWl2ZWQ6IGZyb20gbm9taXMuaS1jb25uZWN0Lm5ldCAocW1haWxyQDIw Ni4xOTAuMTQzLjEwKQogIGJ5IHNvZnRkbnNlcnJvciB3aXRoIFNNVFA7IDEgRmViIDE5OTcgMTU6 Mjg6MjcgLTAwMDAKUmVjZWl2ZWQ6IChxbWFpbCAxNTYyMiBpbnZva2VkIGJ5IHVpZCAxMDApOyAx IEZlYiAxOTk3IDE0OjI2OjM5IC0wMDAwCkRlbGl2ZXJlZC1Ubzogc2hpbW9uQG5vbWlzLmktY29u bmVjdC5uZXQKUmVjZWl2ZWQ6IChxbWFpbCAxNTYyMCBpbnZva2VkIGZyb20gbmV0d29yayk7IDEg RmViIDE5OTcgMTQ6MjY6MzkgLTAwMDAKUmVjZWl2ZWQ6IGZyb20gY2FydHJpZGdlLmktY29ubmVj dC5uZXQgKHFtYWlsckAyMDYuMTkwLjE0My4xMikKICBieSBub21pcy5pLWNvbm5lY3QubmV0IHdp dGggU01UUDsgMSBGZWIgMTk5NyAxNDoyNjozOSAtMDAwMApSZWNlaXZlZDogKHFtYWlsIDI2NzQz IGludm9rZWQgYnkgdWlkIDEwMCk7IDEgRmViIDE5OTcgMTQ6MjY6MzggLTAwMDAKRGVsaXZlcmVk LVRvOiBzaGltb25AaS1jb25uZWN0Lm5ldApSZWNlaXZlZDogKHFtYWlsIDI2NzM5IGludm9rZWQg ZnJvbSBuZXR3b3JrKTsgMSBGZWIgMTk5NyAxNDoyNjozNyAtMDAwMApSZWNlaXZlZDogZnJvbSBt b25nby5waXhhci5jb20gKDEzOC43Mi41MC42MCkKICBieSBjYXJ0cmlkZ2UuaS1jb25uZWN0Lm5l dCB3aXRoIFNNVFA7IDEgRmViIDE5OTcgMTQ6MjY6MzcgLTAwMDAKUmVjZWl2ZWQ6IChxbWFpbCAy NTI3MyBpbnZva2VkIGZyb20gbmV0d29yayk7IDEgRmViIDE5OTcgMTQ6MjY6MzQgLTAwMDAKUmVj ZWl2ZWQ6IGZyb20gcHJpbWVyLmktY29ubmVjdC5uZXQgKEhFTE8gbWFzdGVyLmRlYmlhbi5vcmcp IChicnVjZUAyMDYuMTkwLjE0My4xMykKICBieSBtb25nby5waXhhci5jb20gd2l0aCBTTVRQOyAx IEZlYiAxOTk3IDE0OjI2OjM0IC0wMDAwCkRhdGU6IFNhdCwgMSBGZWIgMTk5NyAxNToyOTo1OCAr MDEwMCAoR01UKzAxMDApCkZyb206IFZpbmNlbnQgUmVuYXJkaWFzIDx2aW5jZW50QHdhdy5jb20+ ClRvOiBkZWJpYW4gY2hhbmdlcyA8ZGViaWFuLWRldmVsLWNoYW5nZXNAbGlzdHMuZGViaWFuLm9y Zz4KY2M6IDY5OTEtZG9uZUBidWdzLmRlYmlhbi5vcmcsIDY5OTItZG9uZUBidWdzLmRlYmlhbi5v cmcKU3ViamVjdDogeGdhbGFnYV8xLjZjLTVfaTM4NiBVcGxvYWQKTWVzc2FnZS1JRDogPFBpbmUu TE5YLjMuOTEuOTcwMjAxMTUyODQwLjMwNzUyQy0xMDAwMDBAb2Rpbi53YXcuY29tPgpNSU1FLVZl cnNpb246IDEuMApDb250ZW50LVR5cGU6IFRFWFQvUExBSU47IGNoYXJzZXQ9VVMtQVNDSUkKUmVz ZW50LU1lc3NhZ2UtSUQ6IDwiQUlpbUkyLjAuTUEuOEVyeW8iQG1hc3Rlci5kZWJpYW4ub3JnPgpS ZXNlbnQtRnJvbTogZGViaWFuLWRldmVsLWNoYW5nZXNAbGlzdHMuZGViaWFuLm9yZwpSZXNlbnQt UmVwbHktVG86IGRlYmlhbi1kZXZlbC1jaGFuZ2VzQGxpc3RzLmRlYmlhbi5vcmcKWC1NYWlsaW5n LUxpc3Q6IDxkZWJpYW4tZGV2ZWwtY2hhbmdlc0BsaXN0cy5kZWJpYW4ub3JnPiBhcmNoaXZlL2xh dGVzdC84MDUKWC1Mb29wOiBkZWJpYW4tZGV2ZWwtY2hhbmdlc0BsaXN0cy5kZWJpYW4ub3JnClBy ZWNlZGVuY2U6IGxpc3QKUHJpb3JpdHk6IG5vbi11cmdlbnQKSW1wb3J0YW5jZTogbG93ClJlc2Vu dC1TZW5kZXI6IGRlYmlhbi1kZXZlbC1jaGFuZ2VzLXJlcXVlc3RAbGlzdHMuZGViaWFuLm9yZwoK Ci0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0KCkZvcm1hdDogMS41CkRhdGU6IFNh dCwgMSBGZWIgMTk5NyAxODowMTowNSArMDEwMApTb3VyY2U6IHhnYWxhZ2EKQmluYXJ5OiB4Z2Fs YWdhCkFyY2hpdGVjdHVyZTogc291cmNlIGkzODYKVmVyc2lvbjogMS42Yy01CkRpc3RyaWJ1dGlv bjogbm9uLWZyZWUKVXJnZW5jeTogbG93Ck1haW50YWluZXI6IFZpbmNlbnQgUmVuYXJkaWFzIDx2 aW5jZW50QHdhdy5jb20+CkRlc2NyaXB0aW9uOiAKIHhnYWxhZ2EgICAgLSBNdWNoIGltcHJvdmVk IFZpZGVvIEdhbWUgd2l0aCBTb3VuZCBldGMKQ2hhbmdlczogCiB4Z2FsYWdhICgxLjZjLTUpIG5v bi1mcmVlOyB1cmdlbmN5PWxvdwogLgogICAqIEZpeGVkIHByb2JsZW0gd2l0aCBzb3VuZGZpbGVz IChCdWcgIzY5OTEpLgogICAqIFJlbW92ZWQgZW1wdHkgZGlyZWN0b3J5IC92YXIvbGliL2dhbWVz IChCdWcgIzY5OTIpLgogICAqIENoYW5nZWQgc29tZSBzcmMgY29kZSB0byBnZXQgcmlkIG9mIGNv bXBpbGF0aW9uIHdhcm5pbmdzLgpGaWxlczogCiA2ZDk4NDY2ZjE4MzA3NDY0YWZmMWNjMTY4MDFh MTc0NiA2MDMgZ2FtZXMgb3B0aW9uYWwgeGdhbGFnYV8xLjZjLTUuZHNjCiAyMTU1NzUzZWJjMTI4 MTM3NmFkMzI2ZjA4MmNhNjVhMyA2NzAwIGdhbWVzIG9wdGlvbmFsIHhnYWxhZ2FfMS42Yy01LmRp ZmYuZ3oKIDg1MWVkM2ZjYzFmYTc4OTJkYjY5NDgwNjNhN2E5OGRmIDE4NjM1MiBnYW1lcyBvcHRp b25hbCB4Z2FsYWdhXzEuNmMtNV9pMzg2LmRlYgoKLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0t LS0KVmVyc2lvbjogMi42LjJpCgppUUNWQXdVQk12TjZVZytibzFzSTFtd3BBUUhNdmdRQWw2YW16 UlZ5eUl3NjBMb1dIM0krRFdKY3Y5WFVxL2NiCm1vTG1SK1dsWjE5N1BxUXhNejFuSnZ2NUFHRm8v RFJvMGd1N25CcE9DMFI2NXlOdXVWK2M2K2cvcVdDeUxmZmMKdCtjNHliT1JhYjJtNE1lQU9MNVFL NHo5bGUwNVYxTlpuZDJEMkQ0bGFmVmsrVWhickQzT2hoU05Xb0hkWEJiWgpjZEZZSEZ6QjN4az0K PUR0bEwKLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tCgoKLS0KLSAgICAgKiogTGludXggKiog ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgKiogV0FXICoqICAgICAt Ci0gIHZpbmNlbnRAZGViaWFuLm9yZyAgICAgfCBSRU5BUkRJQVMgVmluY2VudCB8ICAgICAgICAg IHZpbmNlbnRAd2F3LmNvbSAgLQotICBEZWJpYW4vR05VIExpbnV4ICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0tKyAgICAgIGh0dHA6Ly93d3cud2F3LmNvbS8gIC0KLSAgaHR0cDovL3d3dy5kZWJp YW4ub3JnLyAgICAgICAgICAgfCAgICAgICAgICAgIFdBVyAgKDMzKSA0IDkxIDgxIDIxIDQ1ICAt Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBMdW1pbnkgICgz MykgNCA5MSA4MiA4NSAzMiAgLQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCgo= --_=XFMail.1.1-alpha.p0.FreeBSD:970201172608:9953=_ Content-Type: application/octet-stream; name=Mailbox.1; SizeOnDisk=2829 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Mailbox.1" RnJvbSBvd25lci1jdnMtYWxsQGZyZWVmYWxsLmZyZWVic2Qub3JnIFNhdCBGZWIgMDEgMTU6MTc6 MjMgMTk5NwpSZXR1cm4tUGF0aDogPG93bmVyLWN2cy1hbGxAZnJlZWZhbGwuZnJlZWJzZC5vcmc+ CkRlbGl2ZXJlZC1Ubzogc2hpbW9uQHNlbmRlcm8uaS1jb25uZWN0Lm5ldApSZWNlaXZlZDogKHFt YWlsIDYwOTMgaW52b2tlZCBmcm9tIG5ldHdvcmspOyAxIEZlYiAxOTk3IDE1OjE3OjIyIC0wMDAw ClJlY2VpdmVkOiBmcm9tIG5vbWlzLmktY29ubmVjdC5uZXQgKHFtYWlsckAyMDYuMTkwLjE0My4x MCkKICBieSBzb2Z0ZG5zZXJyb3Igd2l0aCBTTVRQOyAxIEZlYiAxOTk3IDE1OjE3OjIyIC0wMDAw ClJlY2VpdmVkOiAocW1haWwgMTU0NTcgaW52b2tlZCBieSB1aWQgMTAwKTsgMSBGZWIgMTk5NyAx NDoxNTozNCAtMDAwMApEZWxpdmVyZWQtVG86IHNoaW1vbkBub21pcy5pLWNvbm5lY3QubmV0ClJl Y2VpdmVkOiAocW1haWwgMTU0NTUgaW52b2tlZCBmcm9tIG5ldHdvcmspOyAxIEZlYiAxOTk3IDE0 OjE1OjMzIC0wMDAwClJlY2VpdmVkOiBmcm9tIG5zMi5oYXJib3Jjb20ubmV0IChyb290QDIwNi4x NTguNC40KQogIGJ5IG5vbWlzLmktY29ubmVjdC5uZXQgd2l0aCBTTVRQOyAxIEZlYiAxOTk3IDE0 OjE1OjMzIC0wMDAwClJlY2VpdmVkOiBmcm9tIGZyZWVmYWxsLmZyZWVic2Qub3JnIChmcmVlZmFs bC5GcmVlQlNELk9SRyBbMjA0LjIxNi4yNy4xOF0pCiAgICAgICAgICBieSBuczIuaGFyYm9yY29t Lm5ldCAoOC44LjUvOC44LjQpIHdpdGggRVNNVFAKCSAgaWQgSkFBMTIxODE7IFNhdCwgMSBGZWIg MTk5NyAwOToxNToyOSAtMDUwMCAoRVNUKQpSZWNlaXZlZDogKGZyb20gcm9vdEBsb2NhbGhvc3Qp CiAgICAgICAgICBieSBmcmVlZmFsbC5mcmVlYnNkLm9yZyAoOC44LjUvOC44LjUpIGlkIEdBQTIz MTg5CiAgICAgICAgICBmb3IgY3ZzLWFsbC1vdXRnb2luZzsgU2F0LCAxIEZlYiAxOTk3IDA2OjE0 OjM4IC0wODAwIChQU1QpClJlY2VpdmVkOiAoZnJvbSBhbmRyZWFzQGxvY2FsaG9zdCkKICAgICAg ICAgIGJ5IGZyZWVmYWxsLmZyZWVic2Qub3JnICg4LjguNS84LjguNSkgaWQgR0FBMjMxNTU7CiAg ICAgICAgICBTYXQsIDEgRmViIDE5OTcgMDY6MTQ6MjggLTA4MDAgKFBTVCkKRGF0ZTogU2F0LCAx IEZlYiAxOTk3IDA2OjE0OjI4IC0wODAwIChQU1QpCkZyb206IEFuZHJlYXMgS2xlbW0gPGFuZHJl YXNAZnJlZWZhbGwuZnJlZWJzZC5vcmc+Ck1lc3NhZ2UtSWQ6IDwxOTk3MDIwMTE0MTQuR0FBMjMx NTVAZnJlZWZhbGwuZnJlZWJzZC5vcmc+ClRvOiBDVlMtY29tbWl0dGVyc0BmcmVlZmFsbC5mcmVl YnNkLm9yZywgY3ZzLWFsbEBmcmVlZmFsbC5mcmVlYnNkLm9yZywKICAgICAgICBjdnMtcG9ydHNA ZnJlZWZhbGwuZnJlZWJzZC5vcmcKU3ViamVjdDogY3ZzIGNvbW1pdDogIHBvcnRzL3gxMS9mdndt OTUgTWFrZWZpbGUgcG9ydHMveDExL2Z2d205NS9wa2cgREVTQ1IgUExJU1QgcG9ydHMveDExL2Z2 d205NS9maWxlcyBzYW1wbGUuZnZ3bTk1cmMgbWQ1IG1haWx0b29sLnhwbSBuZXRzY2FwZS54cG0g eGZtX2ljb24ueHBtIHhybi5nb29kbmV3cy54cG0geHYueHBtIHBvcnRzL3gxMS9mdndtOTUvcGF0 Y2hlcyBwYXRjaC1hYSBwYXRjaC1hYiBwYXRjaC1hYyBwYXRjaC1hZCBwYXRjaC1hZSBwYXRjaC1h ZiBwYXRjaC1hZwpTZW5kZXI6IG93bmVyLWN2cy1hbGxARnJlZUJTRC5PUkcKWC1Mb29wOiBGcmVl QlNELm9yZwpQcmVjZWRlbmNlOiBidWxrCgphbmRyZWFzICAgICA5Ny8wMi8wMSAwNjoxNDoyNgoK ICBNb2RpZmllZDogICAgeDExL2Z2d205NSAgTWFrZWZpbGUKICAgICAgICAgICAgICAgeDExL2Z2 d205NS9maWxlcyAgbWQ1CiAgICAgICAgICAgICAgIHgxMS9mdndtOTUvcGtnICBERVNDUiBQTElT VAogIEFkZGVkOiAgICAgICB4MTEvZnZ3bTk1L2ZpbGVzICBzYW1wbGUuZnZ3bTk1cmMKICAgICAg ICAgICAgICAgeDExL2Z2d205NS9wYXRjaGVzICBwYXRjaC1hYSBwYXRjaC1hYiBwYXRjaC1hYwog IFJlbW92ZWQ6ICAgICB4MTEvZnZ3bTk1L2ZpbGVzICBtYWlsdG9vbC54cG0gbmV0c2NhcGUueHBt IHhmbV9pY29uLnhwbQogICAgICAgICAgICAgICAgICAgICAgICB4cm4uZ29vZG5ld3MueHBtIHh2 LnhwbQogICAgICAgICAgICAgICB4MTEvZnZ3bTk1L3BhdGNoZXMgIHBhdGNoLWFkIHBhdGNoLWFl IHBhdGNoLWFmIHBhdGNoLWFnCiAgTG9nOgogIFVwZ3JhZGVkIGZ2d205NSBwb3J0IHRvIHZlcnNp b24gMi4wLjQzYS4KICBUaGUgZnZ3bTk1IGRldmVsb3BlbWVudCB0ZWFtIG1ha2VzIGdvb2QgcHJv Z3Jlc3MgOy0pKQogIAogIE9uZSB0aGluZyBJIGRvZXNuJ3QgdW5kZXJzdGFuZCB3aGVuIG1ha2lu ZyB0aGUgcG9ydDoKICAKICBXaGVuIGRvaW5nIG1ha2UgcGFja2FnZSwgdGhlbiB0aGUgZmlyc3Qg QGN3ZCBpbiBQTElTVCBpc24ndAogIHVzZWQsIHNvIGZ2d205NiBpcyBwYWNrYWdlZCBhcyAvdXNy L2xvY2FsL2Jpbi9mdndtOTUgaW5zdGVhZAogIG9mIC91c3IvWDExUjYvYmluL2Z2d205NS4KICAK ICBXb3VsZCBzb21lb25lIHBsZWFzZSBiZSBzbyBraW5kIHRvIGxvb2sgYXQgdGhpcy4gSXMgaXQg bWUgb3IKICBpcyBwa2dfYWRkIG1pc2JlaGF2aW5nID8hCiAgCiAgUmV2aXNpb24gIENoYW5nZXMg ICAgUGF0aAogIDEuNyAgICAgICArMTEgLTM2ICAgIHBvcnRzL3gxMS9mdndtOTUvTWFrZWZpbGUK ICAxLjMgICAgICAgKzEgLTEgICAgICBwb3J0cy94MTEvZnZ3bTk1L2ZpbGVzL21kNQogIDEuMiAg ICAgICArMTQgLTE0ICAgIHBvcnRzL3gxMS9mdndtOTUvcGtnL0RFU0NSCiAgMS41ICAgICAgICsy NDMgLTE3OCAgcG9ydHMveDExL2Z2d205NS9wa2cvUExJU1QK --_=XFMail.1.1-alpha.p0.FreeBSD:970201172608:9953=_-- End of MIME message From owner-freebsd-hackers Sat Feb 1 16:45:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA19793 for hackers-outgoing; Sat, 1 Feb 1997 16:45:28 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA19784 for ; Sat, 1 Feb 1997 16:45:24 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA07338; Sun, 2 Feb 1997 01:45:17 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id BAA20831; Sun, 2 Feb 1997 01:42:52 +0100 (MET) Message-ID: Date: Sun, 2 Feb 1997 01:42:50 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: mcgovern@spoon.beta.com (Brian J. McGovern) Cc: hackers@FreeBSD.ORG Subject: Re: Device driver help needed... References: <199702012336.SAA12533@spoon.beta.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702012336.SAA12533@spoon.beta.com>; from Brian J. McGovern on Feb 1, 1997 18:36:59 -0500 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brian J. McGovern wrote: > struct uio > { > int uio_resid; /* Length of read request (?) */ The residual, the amount that's still to transfer. If you leave something here on return, this indicates a short read/write. I think leaving the entire amount of data here indicates EOF on write. > enum uio_seg uio_segflg; /* I assume a segment of some kind, but I > can only find reference to UIO_SYSSPACE */ ...or UIO_USERSPACE. Describes the origin/destination of the data. IIRC, depending on this value, uiomove(9) decides whether it can memcpy() the stuff or needs to copyin()/copyout() it. > struct proc *uio_procp; /* No idea, but I've seen it set to curproc */ Certainly the associated process. Probably useful in an SMP environment, must be setup by the caller. curproc is an ugly thing in an SMP environment, since there are multiple current processes. -- 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 Feb 1 16:46:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA20124 for hackers-outgoing; Sat, 1 Feb 1997 16:46:22 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20097 for ; Sat, 1 Feb 1997 16:46:16 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA15015; Sun, 2 Feb 1997 11:16:08 +1030 (CST) From: Michael Smith Message-Id: <199702020046.LAA15015@genesis.atrad.adelaide.edu.au> Subject: Re: Suggested ehternet chips/cards? In-Reply-To: from J Wunsch at "Feb 1, 97 01:58:24 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 2 Feb 1997 11:16:07 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch stands accused of saying: > What about AMD? The `Lance' (Am7990PC) chip has got good reputation, > and has been used in many workstations, i think. I'm not certain > about the quality of their newer products (PCnet?). The Lance was used because the only alternative was the i82586, and you're welcome to ask Garret about that. I'm not sure if you'd have trouble with two Lance-style chips on one card though; they use busmaster DMA to talk to their memory, which might also be a problem wrt. bandwidth. > cheers, J"org -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sat Feb 1 16:56:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA20971 for hackers-outgoing; Sat, 1 Feb 1997 16:56:47 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA20966 for ; Sat, 1 Feb 1997 16:56:44 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA07106; Sat, 1 Feb 1997 17:55:19 -0700 From: Terry Lambert Message-Id: <199702020055.RAA07106@phaeton.artisoft.com> Subject: Re: Mounting CD-ROM when data not on first track To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 1 Feb 1997 17:55:19 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "J Wunsch" at Feb 2, 97 01:12:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Terry Lambert wrote: > > > I believe this is a perfectly legal thing to do, actually. One wonders > > At least not in the sense of CD9660 (which i think has a crippled > idea in this respect). I'm not sure if I agree with the interpretation of CD9660 meaning "the first track of any session shall be a data track". I think I lean more towards "the first data track of any session is the first track of the session". > > why the cd device starts at the raw track one instead of the first data > > track in any case... > > Because it always starts at the beginning, and covers the entire data > area. You could look at it as if it were a huge sparse file in this > special situation: seek to the right location, and you'll be able to > read the data. But it's not a data area... or rather, it's not a 'data' area. > Btw., this is exactly what the normal ``multi-session'' idea of CD9660 > is: you've got the entire drive mapped, and the first track of the > most recent session contains the CD9660 directory structure, where the > block pointers are allowed to point back on the CD, or to point into > this track itself. (Strictly spoken, they are allowed to point into > the first track of each successive session only. See above.) That's > why they call this entire beast a session then, despite of the matter > that a single session might have multiple tracks. They always > siltently assume at most the first track of each session being in > CD-ROM data format. I looked at the Windows95 CDROM driver in Soft-ICE for a long time, mostly because it doesn't have the bogus "drive recogniton code" of VFAT implemented in the wrong logical layer, like VFAT. It has it's own bogus "media arrival" definition that doesn't use the device manager like it should, but that's neither here nor there. The Windows95 IFS module for the CDROM driver looks for the first data track of the last session on the device, if the last data track of the last session does not show it as a Joliet disc. If it is a Joliet disc (like I think it is), it would work, and if it's a CD9660 disc using the interpretation using my second sentence above, it would still work. Does anyone else have this CD? Do you have a MacOS or SunOS or older Windows box with ASPI or proprietary CDROM driver you can try it in? If the non-Joliet aware OS recognizes it, I'd think that the FreeBSD interpretation is probably wrong. I suspect they *must* have tested it on a Macintosh before they went to press on it... Quicktime is a native Mac format. > Our cd9660 filesystem code simply needs to examine the TOC (this can > be done from userland, since there's an ioctl for it), and if it > succeeds in this operation, it should default to the diretory > structure from the first track of the last session. Voila!, this > would allow us to read multi-session ISO-9660 CDs. > > The downside: _creating_ such a filesystem is way harder. mkisofs > currently always runs in standalone mode. For ISO-9660 CDs however, > it needs to examine the existing tree structure first (which can > already be multi-session), and needs to figure out which files are to > be replaced. It must then add them up to the new track, along with an > entire new directory tree. (Maybe partial new would suffice, if parts > of the tree remain untouched.) Things are even worse if audio tracks > lie between the data tracks, since mkisofs must retains the holes in > the block numbers, even if the data contents is unknown. The software we run on our mastering burners here knows about writing additional sessions. It does partial trees on the new session; I was recently burning through 12 or more sessions on a CDROM we were using to test install code modifications for autorun.inf for running an install chooser when the user inserted the disc. It seems that Microsoft (stupidly) can not force a program image to be entirely resident in memory, and will blue-screen if the image is from a disc that has been removed, and it wants to page from it. You can see this easily by installing the MSVC++ CDROM on a Win95 box where it's not already installed, letting the install screen pop up, removing the CDROM, and then moving the mouse around. The bitmap data for the buttons was not forced in, and it will attempt to page them from the file, and blue-screen. > > Finally, it seems to me that the CDROM device should impose "slices" > > on its own, and it makes sense to me that 'd' is the whole disk and > > that 'c' is the first data area. > > It makes no sense, i've already thought about this. There are up to > 99 tracks allowed, so we need up to 99 subdevices. Maybe 100, to > account for one covering the entire disk (subdevice 0 fits best for > this, since it's not a legal track number). Why would you need 99 sub-devices? Wouldn't you just *always* point the 'c' device at the first data area? Hmmmm... maybe we should wait until someone tries the CD in a non-Win95 box with a "known good" CD9660? Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 1 17:00:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA21287 for hackers-outgoing; Sat, 1 Feb 1997 17:00:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA21277 for ; Sat, 1 Feb 1997 17:00:32 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA07122; Sat, 1 Feb 1997 17:58:35 -0700 From: Terry Lambert Message-Id: <199702020058.RAA07122@phaeton.artisoft.com> Subject: Re: Device driver help needed... To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 1 Feb 1997 17:58:35 -0700 (MST) Cc: mcgovern@spoon.beta.com, hackers@freebsd.org In-Reply-To: from "J Wunsch" at Feb 2, 97 01:42:50 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > curproc is an ugly thing in an SMP environment, since there are > multiple current processes. Generic implementation strategy is to replace CURPROC with a macro. I believe the current SMP code references the curproc out of the processor specific data area, along with the kernel stack. It's really questionable whether this is a good idea, if we ever intend to support kernel multithreading. But as things stand now, you still use "curproc", and you get the right one for the CPU you are running on. 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 Feb 1 17:02:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA21425 for hackers-outgoing; Sat, 1 Feb 1997 17:02:13 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA21416 for ; Sat, 1 Feb 1997 17:02:08 -0800 (PST) Received: (qmail 6592 invoked by uid 5); 2 Feb 1997 01:01:51 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Sun Feb 2 11:58:11 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id LAA17811; Sun, 2 Feb 1997 11:58:11 +1100 (EST) From: John Birrell Message-Id: <199702020058.LAA17811@freebsd1.cimlogic.com.au> Subject: Re: pthread library on FreeBSD To: nw1@cs.wustl.edu (Nanbor Wang) Date: Sun, 2 Feb 1997 11:58:10 +1100 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <199702010346.VAA26518@siesta.cs.wustl.edu> from Nanbor Wang at "Jan 31, 97 09:46:41 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nanbor Wang wrote: > Hi all, > > Thanks for your help I had made some progress on porting ACE to > FreeBSD. However, I encountered another obstacle. There seems to be > some pthread functions unimplemented. After looking to its source > code, here is a list of functions that are missing and will be nice if > ACE can make use of them. > > pthread_mutexattr_destroy: > pthread_condattr_init: > pthread_condattr_destroy: > pthread_attr_setstackaddr: > pthread_attr_setdetachstate: > These are nowhere to be found. > > pthread_cleanup_push: > pthread_cleanup_pop: > Have underlying functions _thread_cleanup_push and > _thread_cleanup_pop but there is no API functions. (Possibly > implemented?) These can (will!) be renamed as pthread_cleanup_push and pthread_cleanup_pop since they comply with 1003.1c. > > Does anyone know this is because that pthread lib (for BSD) itself is > still ongoing or just because the pthread lib source files in Ongoing. > FreeBSD are simply outdated? I am running -current as of 1/26. > > Under either circumstance, is there anyway to get around this? TIA. If you can test these functions, I'll send you diffs against -current. > > Later, > > Nanbor Wang http://www.cs.wustl.edu/~nw1/ > Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au; jb@netbsd.org 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Sat Feb 1 17:11:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA21891 for hackers-outgoing; Sat, 1 Feb 1997 17:11:14 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA21886 for ; Sat, 1 Feb 1997 17:11:10 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA15091; Sun, 2 Feb 1997 11:41:00 +1030 (CST) From: Michael Smith Message-Id: <199702020111.LAA15091@genesis.atrad.adelaide.edu.au> Subject: Re: Device driver help needed... In-Reply-To: <199702012336.SAA12533@spoon.beta.com> from "Brian J. McGovern" at "Feb 1, 97 06:36:59 pm" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Sun, 2 Feb 1997 11:40:59 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern stands accused of saying: > Ok. I'm sure that now I've terribly bastardized the uio structure, but at > least the damn thing compiles :) Let see if I can get some comment > on my interpretation of the uio stucture: "correct" usage of the uio structure means ignoring its contents, with the exception of the uio_resid member, which gives you a count of bytes outstanding. On a read, this is how much of the user buffer is left, on a write this is how much more the user process wants to write. You drag stuff around with uiomove() : u_char mybuf[128]; int hmuch; int result; ... hmuch = min(uio->uio_resid, sizeof(mybuf)); if ((result = uiomove(mybuf, hmuch, uio))) return(result); ... In a read() style routine, this will copy data from mybuf out to the user, in a write() style routine, the data goes the other way. This is handled invisibly by the contents of the uio strcture. > With that in mind, I've bent my device driver to look like this: I'm assuming that this is meant to be a pseudo-device, correct? > static struct cdevsw foo_cdevsw = > { > nxopen, nxclose, fooread, nxwrite, > nxioctl, nxstop, nxreset, nxdevtotty, > nxselect, nxmmap, NULL, "foo", NULL, -1 > }; You probably want nullopen and nullclose there, so that the device can be opened and closed. > fooinit() > { > } If this is a pseudo-device, you're going to want some code here to install you cdevsw and any devfs nodes you plan on advertising. I _strongly_ suggest looking at the logic in vn_drvinit, which does just that (as well as installing a shutdown hook). > static int fooread(dev,myuio, flag) > dev_t dev; > struct uio *myuio; > int flag; > { > unsigned char *buffer_pointer; > int toread; > if ((myuio->uio_iovcnt != 1) || (MINOR(dev) != 0)) > return ENODEV; > while(myuio->uio_resid) > { > buffer_pointer = (message + (myuio->uio_offset % sizeof(message))); > toread = ((long unsigned int)(message + sizeof(message)) - (long unsigned int)buffer_pointer); > uiomove(buffer_pointer, toread, myuio); > myuio->uio_offset + toread; > myuio->uio_resid = myuio->uio_resid - toread; > } > } > #define CDEV_MAJOR 20 Ouch. Leave the innards of the uio structure alone; uiomove takes care of all that for you. If what you want the read function to do is to return as much of the message string as will fit in the requeted read buffer, try : static int fooread(dev_t dev, struct uio *uio, int flag) { int toread; if (MINOR(dev) != 1) return(ENODEV); toread = (min(uio->uio_resid, sizeof(message)); return(uiomove(message, toread, uio)); } > as a pseudo-device driver. The file above is located in > /usr/src/sys/i386/addons/foo.c. Anyone care to give me a set of steps (and > code changes) to get it in the kernel? Thanks. > -Brian Move it to /sys/dev/foo/foo.c, bracket the whole file in #if NFOO > 0 / #endif, add a line to /sys/conf/files that reads '/dev/foo/foo.c optional foo' and stick a line in your kernel config that reads 'pseudo-device foo 1'. Add a SYSINIT macro to your file that looks like : SYSINIT(foodev,SI_SUB_DRIVERS,SI_ORDER_MIDDLE+CDEV_MAJOR,foo_init,NULL); and rework your init function along the lines of the 'vn' one mentioned above. When you're testing your kernels, _don't_ use 'make install' to install them, as it's fairly likely you'll end up with two dead ones in a row 8) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sat Feb 1 17:55:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA23773 for hackers-outgoing; Sat, 1 Feb 1997 17:55:12 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA23766 for ; Sat, 1 Feb 1997 17:55:08 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id RAA18732; Sat, 1 Feb 1997 17:20:47 -0800 (PST) Message-ID: <32F3EB83.41C67EA6@whistle.com> Date: Sat, 01 Feb 1997 17:18:59 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Brian J. McGovern" CC: hackers@freebsd.org Subject: Re: Device driver help needed... References: <199702012336.SAA12533@spoon.beta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern wrote: > > Ok. I'm sure that now I've terribly bastardized the uio structure, but at > least the damn thing compiles :) Let see if I can get some comment > on my interpretation of the uio stucture: > > struct uio > { > struct iovec *uio_iov; /* Pointer to IO Vector (possible array?) */ pointer to ARRAY OF IOVECS (POSSIBLY ONLY 1) (I know that's what you said but....) > int uio_iovcnt; /* Number of IO vectors (?) */ (size of array above) > off_t uio_offset; /* Offset in to device */ > int uio_resid; /* Length of read request (?) */ number of bytes STILL TO BE TRANSFERED > enum uio_seg uio_segflg; /* I assume a segment of some kind, but I > can only find reference to UIO_SYSSPACE */ the addresses in the iovec are to be interpretted as being in: KV space, User space, etc.etc. > enum uio_rw uio_rw; /* UIO_READ or UIO_WRITE (type of operation(?)) */ yes.. TO or FROM the addresses inn the iovec array > struct proc *uio_procp; /* No idea, but I've seen it set to curproc */ pointer of the proc structure associated with the operation needed if using UIO_USERSPACE. > }; > > Ok, guys. Beat me up, and let me know whats incorrect. > > With that in mind, I've bent my device driver to look like this: > > ------ foo.c --------------------------------------- > #define KERNEL > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #ifdef DEVFS > #include > #endif > #include > #include > #include > > static char message[] = "The quick brown fox jumps over a lazy dog\n"; > > #define CDEV_MAJOR 20 are you sure 20 is unused? I guess it's for local use.. that's fine. > > static d_read_t fooread; > > static struct cdevsw foo_cdevsw = > { > nxopen, nxclose, fooread, nxwrite, > nxioctl, nxstop, nxreset, nxdevtotty, > nxselect, nxmmap, NULL, "foo", NULL, -1 > }; > you are going to have trouble openning the device if it returns ENXIO.. (nxopen?) > fooinit() > { > } > > static int fooread(dev,myuio, flag) > dev_t dev; > struct uio *myuio; > int flag; > { > unsigned char *buffer_pointer; > int toread; > if ((myuio->uio_iovcnt != 1) || (MINOR(dev) != 0)) what if it's 2? > return ENODEV; and anyway, wouldn't EINVAL be a better response to no user memory buffer.. > while(myuio->uio_resid) exactly.. keep doing it till we have the required data. > { > buffer_pointer = (message + (myuio->uio_offset % sizeof(message))); what's message? is this a ring buffer? > toread = ((long unsigned int)(message + sizeof(message)) - (long unsigned int)buffer_pointer); I don't follow this very well. > uiomove(buffer_pointer, toread, myuio); yep.. (I haven't chaecked the arguments but that's the basic idea how about checking the return value of uiomove eh? it returns an errno value you can pass straight to the user. (return it, the syscall code will put it into errno.) > myuio->uio_offset + toread; you mean += surely.. > myuio->uio_resid = myuio->uio_resid - toread; using -= would be more readable.. > } > } > #define CDEV_MAJOR 20 > > ------------------------------------------------- > > Now, I'm sure there are bugs in there. Hell, I didn't know what I was doing > half the time :) But, now its time to start debugging, which means I need > to get it in to the kernel. Someone mentioned using SYSINIT to get it working > as a pseudo-device driver. The file above is located in > /usr/src/sys/i386/addons/foo.c. Anyone care to give me a set of steps (and > code changes) to get it in the kernel? Thanks. > -Brian ok cd /sys/i386/conf cp GENERIC MYKERN cat > /sys/i386/conf/files.MYKERN <>MYKERN < Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA24038 for hackers-outgoing; Sat, 1 Feb 1997 18:02:29 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA24033 for ; Sat, 1 Feb 1997 18:02:23 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id RAA18853; Sat, 1 Feb 1997 17:30:31 -0800 (PST) Message-ID: <32F3EDCC.446B9B3D@whistle.com> Date: Sat, 01 Feb 1997 17:28:44 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Michael Smith CC: joerg_wunsch@uriah.heep.sax.de, hackers@freebsd.org Subject: Re: Suggested ehternet chips/cards? References: <199702020046.LAA15015@genesis.atrad.adelaide.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith wrote: > > > The Lance was used because the only alternative was the i82586, and > you're welcome to ask Garret about that. personally I'd rather an 82586.. I've a LOT of experience with those, and I can make them do anything I want. > > I'm not sure if you'd have trouble with two Lance-style chips on one > card though; they use busmaster DMA to talk to their memory, which > might also be a problem wrt. bandwidth. > From owner-freebsd-hackers Sat Feb 1 19:28:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27052 for hackers-outgoing; Sat, 1 Feb 1997 19:28:00 -0800 (PST) Received: from spoon.beta.com (root@[199.165.180.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA27038 for ; Sat, 1 Feb 1997 19:27:55 -0800 (PST) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.4/8.6.9) with ESMTP id WAA00333 for ; Sat, 1 Feb 1997 22:27:52 -0500 (EST) Message-Id: <199702020327.WAA00333@spoon.beta.com> To: hackers@freebsd.org Subject: Device Driver: Almost home(?) Date: Sat, 01 Feb 1997 22:27:51 -0500 From: "Brian J. McGovern" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ok. I've collated a half dozen responses, and merged them in to what I hope is less of a Frankenstein. At this point, I've modified files.i386, and moved foo.c in to /usr/src/sys/dev/foo/foo.c. I've added a "pseudo-device foo 1" line to the config file, and see foo.h being generated with an NFOO #define'ed to 1. I see the make depend and the make compile the chunk, so I'm fairly sure its making it in there. However, I don't think fooinit() is being run properly, and I'm not sure of the call I make to register the device. As before, if someone can sanity check me, and let me take it a step or two further, I'd appreciate it. I think that once I can get it to where I can tinker and debug, I should be set. Also, I'm getting a warning about the SYSINIT macro, stating "warning: initialization from incompatible pointer type". If someone could give me a lead on that as well, I'd appreciate it. Anyhow, here is the contents of foo.c: #include #include #include #include #include #include #include #include #include #include #include #include #ifdef DEVFS #include #endif #include #include #include static char message[] = "The quick brown fox jumps over a lazy dog\n"; #define CDEV_MAJOR 20 static d_read_t fooread; static struct cdevsw foo_cdevsw = { nxopen, nxclose, fooread, nxwrite, nxioctl, nxstop, nxreset, nxdevtotty, nxselect, nxmmap, NULL, "foo", NULL, -1 }; static void fooinit(void) { dev_t dev; printf("Test character driver\n"); cdevsw_add(&dev,&foo_cdevsw,NULL); } static int fooread(dev,myuio, flag) dev_t dev; struct uio *myuio; int flag; { unsigned char *buffer_pointer; int toread; if ((myuio->uio_iovcnt != 1) || (minor(dev) != 0)) return ENODEV; while(myuio->uio_resid) { buffer_pointer = (message + (myuio->uio_offset % sizeof(message))); toread = ((long unsigned int)(message + sizeof(message)) - (long unsigned int)buffer_pointer); uiomove(buffer_pointer, toread, myuio); myuio->uio_offset + toread; myuio->uio_resid = myuio->uio_resid - toread; } return 0; } SYSINIT(foodev, SI_SUB_DRIVERS, SI_ORDER_MIDDLE+CDEV_MAJOR, fooinit, NULL); As always, thanks in advance. -Brian From owner-freebsd-hackers Sat Feb 1 21:37:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA01876 for hackers-outgoing; Sat, 1 Feb 1997 21:37:54 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA01871 for ; Sat, 1 Feb 1997 21:37:51 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id QAA15620; Sun, 2 Feb 1997 16:07:31 +1030 (CST) From: Michael Smith Message-Id: <199702020537.QAA15620@genesis.atrad.adelaide.edu.au> Subject: Re: Device Driver: Almost home(?) In-Reply-To: <199702020327.WAA00333@spoon.beta.com> from "Brian J. McGovern" at "Feb 1, 97 10:27:51 pm" To: mcgovern@spoon.beta.com (Brian J. McGovern) Date: Sun, 2 Feb 1997 16:07:30 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian J. McGovern stands accused of saying: > > Ok. I've collated a half dozen responses, and merged them in to what I hope > is less of a Frankenstein. At this point, I've modified files.i386, and moved > foo.c in to /usr/src/sys/dev/foo/foo.c. I've added a "pseudo-device foo 1" You shouldn't be modifying files.i386 if the file isn't in the i386 tree. You should be modifying /sys/conf/files as I previously mentioned. > its making it in there. However, I don't think fooinit() is being run > properly, and I'm not sure of the call I make to register the device. As > before, if someone can sanity check me, and let me take it a step or two > further, I'd appreciate it. I think that once I can get it to where I can > tinker and debug, I should be set. Do you see your printf at startup? > Also, I'm getting a warning about the SYSINIT macro, stating > "warning: initialization from incompatible pointer type". If someone could > give me a lead on that as well, I'd appreciate it. ... > static void fooinit(void) That should be static void fooinit(void *unused) as per the example I referenced in /sys/dev/vn/vn.c > static int fooread(dev,myuio, flag) > dev_t dev; > struct uio *myuio; > int flag; > { > unsigned char *buffer_pointer; > int toread; > if ((myuio->uio_iovcnt != 1) || (minor(dev) != 0)) > return ENODEV; > while(myuio->uio_resid) > { > buffer_pointer = (message + (myuio->uio_offset % sizeof(message))); > toread = ((long unsigned int)(message + sizeof(message)) - (long unsigned int)buffer_pointer); > uiomove(buffer_pointer, toread, myuio); > myuio->uio_offset + toread; > myuio->uio_resid = myuio->uio_resid - toread; > } > return 0; > } This is still complete rubbish; please see my earlier message. 8) > -Brian -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sat Feb 1 21:45:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA02158 for hackers-outgoing; Sat, 1 Feb 1997 21:45:12 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA02151 for ; Sat, 1 Feb 1997 21:45:07 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id VAA21438; Sat, 1 Feb 1997 21:39:28 -0800 (PST) Message-ID: <32F42817.794BDF32@whistle.com> Date: Sat, 01 Feb 1997 21:37:27 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Michael Smith CC: "Brian J. McGovern" , hackers@freebsd.org Subject: SAMPLE DEVICE DRIVER. References: <199702020111.LAA15091@genesis.atrad.adelaide.edu.au> Content-Type: multipart/mixed; boundary="------------1CFBAE3959E2B60015FB7483" Sender: owner-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 Michael Smith wrote: > > I'm assuming that this is meant to be a pseudo-device, correct? > > > static struct cdevsw foo_cdevsw = > > { > > nxopen, nxclose, fooread, nxwrite, > > nxioctl, nxstop, nxreset, nxdevtotty, > > nxselect, nxmmap, NULL, "foo", NULL, -1 > > }; > > You probably want nullopen and nullclose there, so that the device can > be opened and closed. > > If this is a pseudo-device, you're going to want some code here to > install you cdevsw and any devfs nodes you plan on advertising. I > _strongly_ suggest looking at the logic in vn_drvinit, which does just > that (as well as installing a shutdown hook). Even if it's a REAL device you want that.. here is a shell script that writes andevice driver for you, configures it into the kerenl tree and compiles it for you. Once you have run this once, you should just alternate between editing the .c file it writes, and compiling the kernel.. edit /sys/i386/conf/FOO to set the correct h/w configuration. run it as follows: cp makedriver /tmp cd /tmp sh ./makedriver foo [shell script makes a foo driver..] cd /sys/compile/FOO get kernel, reboot, try.. it makes 4 files /sys/i386/conf/FOO /sys/i386/conf/files.FOO /sys/i386/isa/foo.c /sys/fooio.h this is all you need to link your kernel in.... it is for a REAL device driver (with hardware) it is an ISA driver. I'd like to make similar "builders" for PCI and EISA.. anyone care to adapt it? oh yeah this assumes you can write to your sources.. --------------1CFBAE3959E2B60015FB7483 Content-Type: text/plain; charset=us-ascii; name="makedriver" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="makedriver" #!/bin/sh # This writes a skeleton driver and puts it into the kernel tree for you #arg1 is lowercase "foo" # # Trust me, RUN THIS SCRIPT :) # #-------cut here------------------ cd /sys/i386/conf if [ "${1}X" = "X" ] then echo "Hey , how about some help here.. give me a device name!" exit 1 fi UPPER=`echo ${1} |tr "[:lower:]" "[:upper:]"` cat >files.${UPPER} <${UPPER} <>${UPPER} cat >>${UPPER} <../isa/${1}.c < #include #include /* SYSINIT stuff */ #include /* cdevsw stuff */ #include /* malloc region definitions */ #include /* DELAY() */ #include /* ISA bus port definitions etc. */ #include /* ISA bus configuration structures */ #include /* ${1} IOCTL definitions */ #ifdef DEVFS #include /* DEVFS defintitions */ #endif /* DEVFS */ /* Function prototypes (these should all be static except for ${1}intr()) */ static d_open_t ${1}open; static d_close_t ${1}close; static d_read_t ${1}read; static d_write_t ${1}write; static d_ioctl_t ${1}ioctl; static d_mmap_t ${1}mmap; static d_select_t ${1}select; static int ${1}probe (struct isa_device *); static int ${1}attach (struct isa_device *); /* void ${1}intr(int unit);*//* actually defined in ioconf.h (generated file) */ #define CDEV_MAJOR 20 static struct cdevsw ${1}_cdevsw = { ${1}open, ${1}close, ${1}read, ${1}write, ${1}ioctl, nullstop, nullreset, nodevtotty, ${1}select, ${1}mmap, NULL, "${1}", NULL, -1 }; struct isa_driver ${1}driver = { ${1}probe, ${1}attach, "${1}" }; /* * device specific Misc defines */ #define BUFFERSIZE 1024 #define NUMPORTS 4 #define UNIT(dev) minor(dev) /* assume one minor number per unit */ /* * One of these per allocated device */ struct ${1}_softc { struct isa_device *dev; char buffer[BUFFERSIZE]; #ifdef DEVFS static void *devfs_token; #endif } ; typedef struct ${1}_softc *sc_p; static sc_p sca[N${UPPER}]; /* add your own test to see if it exists */ /* should return the number of ports needed */ static int ${1}probe (struct isa_device *dev) { char val; int unit = dev->id_unit; sc_p scp = sca[unit]; /* * Check the unit makes sense. */ if (unit > N${UPPER}) { printf("bad unit (%d)\n", unit); return (0); } if (scp) { printf("unit $d already attached\n", unit); return (0); } /* * try see if the device is there. */ val = inb (dev->id_iobase); if ( val != 42 ) { return (0); } /* * ok, we got one we think * do some further (this time possibly destructive) tests. */ outb (dev->id_iobase, 0xff); DELAY (10000); /* 10 ms delay */ val = inb (dev->id_iobase) & 0x0f; return ((val & 0x0f) == 0x0f)? NUMPORTS : 0 ; } /* * Called if the probe succeeded. * We can be destructive here as we know we have the device. * we can also trust the unit number. */ static int ${1}attach (struct isa_device *dev) { int unit = dev->id_unit; sc_p scp = sca[unit]; /* * Allocate storage for this instance . */ scp = malloc(sizeof(*scp), M_DEVBUF, M_NOWAIT); if( scp == NULL) { printf("${1}%d failed to allocage driver strorage\n", unit); return (0); } bzero(scp, sizeof(*scp)); sca[unit] = scp; /* * Store whatever seems wise. */ scp->dev = dev; #if DEVFS scp->devfs_token = devfs_add_devswf(&${1}_cdevsw, 0, DV_CHR, UID_ROOT, GID_KMEM, 0640, "${1}%d", unit); #endif return 1; } /* * Macro to check that the unit number is valid * Often this isn't needed as once the open() is performed, * the unit number is pretty much safe.. The exception would be if we * implemented devices that could "go away". in which case all these routines * would be wise to check the number, DIAGNOSTIC or not. */ #define CHECKUNIT(RETVAL) \ do { /* the do-while is a safe way to do this grouping */ \ if (unit > N${UPPER}) { \ printf(__FUNCTION__ ":bad unit $d\n", unit); \ return (RETVAL); \ } \ if (scp == NULL) { \ printf( __FUNCTION__ ": unit $d not attached\n", unit);\ return (RETVAL); \ } \ } while (0) #ifdef DIAGNOSTIC #define CHECKUNIT_DIAG(RETVAL) CHECKUNIT(RETVAL) #else /* DIAGNOSTIC */ #define CHECKUNIT_DIAG(RETVAL) #endif /* DIAGNOSTIC */ void ${1}intr(int unit) { sc_p scp = sca[unit]; /* * well we got an interupt, now what? * Theoretically we don't need to check the unit. */ return; } int ${1}ioctl (dev_t dev, int cmd, caddr_t data, int flag, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); switch (cmd) { case DHIOCRESET: /* whatever resets it */ outb(scp->dev->id_iobase, 0xff); break; default: return ENXIO; } return (0); } /* * You also need read, write, open, close routines. * This should get you started */ static int ${1}open(dev_t dev, int oflags, int devtype, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT(ENXIO); /* * Do processing */ return (0); } static int ${1}close(dev_t dev, int fflag, int devtype, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); /* * Do processing */ return (0); } static int ${1}read(dev_t dev, struct uio *uio, int ioflag) { int unit = UNIT (dev); sc_p scp = sca[unit]; int toread; CHECKUNIT_DIAG(ENXIO); /* * Do processing * read from buffer */ toread = (min(uio->uio_resid, sizeof(scp->buffer))); return(uiomove(scp->buffer, toread, uio)); } static int ${1}write(dev_t dev, struct uio *uio, int ioflag) { int unit = UNIT (dev); sc_p scp = sca[unit]; int towrite; CHECKUNIT_DIAG(ENXIO); /* * Do processing * write to buffer */ towrite = (min(uio->uio_resid, sizeof(scp->buffer))); return(uiomove(scp->buffer, towrite, uio)); } static int ${1}mmap(dev_t dev, int offset, int nprot) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(-1); /* * Do processing */ #if 0 /* if we had a frame buffer or whatever.. do this */ if (offset > FRAMEBUFFERSIZE - PAGE_SIZE) { return (-1); } return i386_btop((FRAMEBASE + offset)); #else return (-1); #endif } static int ${1}select(dev_t dev, int which, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); /* * Do processing */ return (0); /* this is the wrong value I'm sure */ } /* * Now for some driver initialisation. * Occurs ONCE during boot (very early). */ static void ${1}_drvinit(void *unused) { dev_t dev; dev = makedev(CDEV_MAJOR, 0); cdevsw_add(&dev, &${1}_cdevsw, NULL); } SYSINIT(${1}dev, SI_SUB_DRIVERS, SI_ORDER_MIDDLE+CDEV_MAJOR, ${1}_drvinit, NULL) DONE cat >../../sys/${1}io.h < #endif #include /* * define an ioctl here */ #define DHIOCRESET _IO('D', 0) /* reset the ${1} device */ #endif DONE config ${UPPER} cd ../../compile/${UPPER} make depend make ${1}.o make exit #--------------end of script--------------- # #you also need to add an entry into the cdevsw[] #array in conf.c, but it's too hard to do in a script.. # #edit to your taste.. # # --------------1CFBAE3959E2B60015FB7483-- From owner-freebsd-hackers Sat Feb 1 22:04:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA02990 for hackers-outgoing; Sat, 1 Feb 1997 22:04:25 -0800 (PST) Received: from r33h142.res.gatech.edu (r33h142.res.gatech.edu [128.61.33.142]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA02982; Sat, 1 Feb 1997 22:04:13 -0800 (PST) Received: (from jason@localhost) by r33h142.res.gatech.edu (8.8.2/8.7.3) id BAA02654; Sun, 2 Feb 1997 01:04:11 -0500 (EST) Message-ID: <19970202010411.MK61452@r33h142.res.gatech.edu> Date: Sun, 2 Feb 1997 01:04:11 -0500 From: jason@r33h142.res.gatech.edu (Jason Bennett) To: smpatel@freebsd.org Cc: hackers@freebsd.org Subject: PnP info X-Mailer: Mutt 0.59-PL19 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm trying to get pnp.c to work on 3.0-current, but when I go to recomplile the kernel, gcc barfs on pnp.c. It finally says that finction declaration isn't a prototype in line 324 (the last function). jason -- Jason Bennett, jbennett@cc.gatech.edu | Member, Team OS/2! CS Major, Georgia Institute of Technology | Senior TA, CS 1501! Believer in Jesus Christ as Savior and Lord | VP-Comm, BSU! http://bsu.gt.ed.net/~jason/ | finger for PGP key! From owner-freebsd-hackers Sat Feb 1 22:20:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA03596 for hackers-outgoing; Sat, 1 Feb 1997 22:20:10 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA03591 for ; Sat, 1 Feb 1997 22:20:06 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id WAA21854; Sat, 1 Feb 1997 22:15:01 -0800 (PST) Message-ID: <32F4306A.FF6D5DF@whistle.com> Date: Sat, 01 Feb 1997 22:12:58 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Brian J. McGovern" CC: hackers@freebsd.org Subject: Re: Device Driver: Almost home(?) References: <199702020327.WAA00333@spoon.beta.com> Content-Type: multipart/mixed; boundary="------------237C228A31DFF4F5ABD322C" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------237C228A31DFF4F5ABD322C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK, here is a shell script that writes a pseudo device driver and integrates it into your kernel. I also attach a real device driver writing script that does the same thing they both use the GENERIC config as a starting point.. you run them as: sh make_pseudo_driver.sh foo and sh make_device_driver.sh bar comments and suggestions? I think these should go into /usr/share/examples or somewhere (the FAQ?) the make REAL device driver script has a littel bug-fix from the last one) julian --------------237C228A31DFF4F5ABD322C Content-Type: application/x-sh; name="make_device_driver.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="make_device_driver.sh" #!/bin/sh # This writes a skeleton driver and puts it into the kernel tree for you #arg1 is lowercase "foo" # # Trust me, RUN THIS SCRIPT :) # #-------cut here------------------ cd /sys/i386/conf if [ "${1}X" = "X" ] then echo "Hey , how about some help here.. give me a device name!" exit 1 fi UPPER=`echo ${1} |tr "[:lower:]" "[:upper:]"` cat >files.${UPPER} <${UPPER} <>${UPPER} cat >>${UPPER} <../isa/${1}.c < #include #include /* SYSINIT stuff */ #include /* cdevsw stuff */ #include /* malloc region definitions */ #include /* DELAY() */ #include /* ISA bus port definitions etc. */ #include /* ISA bus configuration structures */ #include /* ${1} IOCTL definitions */ #ifdef DEVFS #include /* DEVFS defintitions */ #endif /* DEVFS */ /* Function prototypes (these should all be static except for ${1}intr()) */ static d_open_t ${1}open; static d_close_t ${1}close; static d_read_t ${1}read; static d_write_t ${1}write; static d_ioctl_t ${1}ioctl; static d_mmap_t ${1}mmap; static d_select_t ${1}select; static int ${1}probe (struct isa_device *); static int ${1}attach (struct isa_device *); /* void ${1}intr(int unit);*//* actually defined in ioconf.h (generated file) */ #define CDEV_MAJOR 20 static struct cdevsw ${1}_cdevsw = { ${1}open, ${1}close, ${1}read, ${1}write, ${1}ioctl, nullstop, nullreset, nodevtotty, ${1}select, ${1}mmap, NULL, "${1}", NULL, -1 }; struct isa_driver ${1}driver = { ${1}probe, ${1}attach, "${1}" }; /* * device specific Misc defines */ #define BUFFERSIZE 1024 #define NUMPORTS 4 #define UNIT(dev) minor(dev) /* assume one minor number per unit */ /* * One of these per allocated device */ struct ${1}_softc { struct isa_device *dev; char buffer[BUFFERSIZE]; #ifdef DEVFS static void *devfs_token; #endif } ; typedef struct ${1}_softc *sc_p; static sc_p sca[N${UPPER}]; /* add your own test to see if it exists */ /* should return the number of ports needed */ static int ${1}probe (struct isa_device *dev) { char val; int unit = dev->id_unit; sc_p scp = sca[unit]; /* * Check the unit makes sense. */ if (unit > N${UPPER}) { printf("bad unit (%d)\n", unit); return (0); } if (scp) { printf("unit $d already attached\n", unit); return (0); } /* * try see if the device is there. */ val = inb (dev->id_iobase); if ( val != 42 ) { return (0); } /* * ok, we got one we think * do some further (this time possibly destructive) tests. */ outb (dev->id_iobase, 0xff); DELAY (10000); /* 10 ms delay */ val = inb (dev->id_iobase) & 0x0f; return ((val & 0x0f) == 0x0f)? NUMPORTS : 0 ; } /* * Called if the probe succeeded. * We can be destructive here as we know we have the device. * we can also trust the unit number. */ static int ${1}attach (struct isa_device *dev) { int unit = dev->id_unit; sc_p scp = sca[unit]; /* * Allocate storage for this instance . */ scp = malloc(sizeof(*scp), M_DEVBUF, M_NOWAIT); if( scp == NULL) { printf("${1}%d failed to allocage driver strorage\n", unit); return (0); } bzero(scp, sizeof(*scp)); sca[unit] = scp; /* * Store whatever seems wise. */ scp->dev = dev; #if DEVFS scp->devfs_token = devfs_add_devswf(&${1}_cdevsw, unit, DV_CHR, UID_ROOT, GID_KMEM, 0600, "${1}%d", unit); #endif return 1; } /* * Macro to check that the unit number is valid * Often this isn't needed as once the open() is performed, * the unit number is pretty much safe.. The exception would be if we * implemented devices that could "go away". in which case all these routines * would be wise to check the number, DIAGNOSTIC or not. */ #define CHECKUNIT(RETVAL) \ do { /* the do-while is a safe way to do this grouping */ \ if (unit > N${UPPER}) { \ printf(__FUNCTION__ ":bad unit $d\n", unit); \ return (RETVAL); \ } \ if (scp == NULL) { \ printf( __FUNCTION__ ": unit $d not attached\n", unit);\ return (RETVAL); \ } \ } while (0) #ifdef DIAGNOSTIC #define CHECKUNIT_DIAG(RETVAL) CHECKUNIT(RETVAL) #else /* DIAGNOSTIC */ #define CHECKUNIT_DIAG(RETVAL) #endif /* DIAGNOSTIC */ void ${1}intr(int unit) { sc_p scp = sca[unit]; /* * well we got an interupt, now what? * Theoretically we don't need to check the unit. */ return; } int ${1}ioctl (dev_t dev, int cmd, caddr_t data, int flag, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); switch (cmd) { case DHIOCRESET: /* whatever resets it */ outb(scp->dev->id_iobase, 0xff); break; default: return ENXIO; } return (0); } /* * You also need read, write, open, close routines. * This should get you started */ static int ${1}open(dev_t dev, int oflags, int devtype, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT(ENXIO); /* * Do processing */ return (0); } static int ${1}close(dev_t dev, int fflag, int devtype, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); /* * Do processing */ return (0); } static int ${1}read(dev_t dev, struct uio *uio, int ioflag) { int unit = UNIT (dev); sc_p scp = sca[unit]; int toread; CHECKUNIT_DIAG(ENXIO); /* * Do processing * read from buffer */ toread = (min(uio->uio_resid, sizeof(scp->buffer))); return(uiomove(scp->buffer, toread, uio)); } static int ${1}write(dev_t dev, struct uio *uio, int ioflag) { int unit = UNIT (dev); sc_p scp = sca[unit]; int towrite; CHECKUNIT_DIAG(ENXIO); /* * Do processing * write to buffer */ towrite = (min(uio->uio_resid, sizeof(scp->buffer))); return(uiomove(scp->buffer, towrite, uio)); } static int ${1}mmap(dev_t dev, int offset, int nprot) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(-1); /* * Do processing */ #if 0 /* if we had a frame buffer or whatever.. do this */ if (offset > FRAMEBUFFERSIZE - PAGE_SIZE) { return (-1); } return i386_btop((FRAMEBASE + offset)); #else return (-1); #endif } static int ${1}select(dev_t dev, int which, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); /* * Do processing */ return (0); /* this is the wrong value I'm sure */ } /* * Now for some driver initialisation. * Occurs ONCE during boot (very early). */ static void ${1}_drvinit(void *unused) { dev_t dev; dev = makedev(CDEV_MAJOR, 0); cdevsw_add(&dev, &${1}_cdevsw, NULL); } SYSINIT(${1}dev, SI_SUB_DRIVERS, SI_ORDER_MIDDLE+CDEV_MAJOR, ${1}_drvinit, NULL) DONE cat >../../sys/${1}io.h < #endif #include /* * define an ioctl here */ #define DHIOCRESET _IO('D', 0) /* reset the ${1} device */ #endif DONE config ${UPPER} cd ../../compile/${UPPER} make depend make ${1}.o make exit #--------------end of script--------------- # #you also need to add an entry into the cdevsw[] #array in conf.c, but it's too hard to do in a script.. # #edit to your taste.. # # --------------237C228A31DFF4F5ABD322C Content-Type: application/x-sh; name="make_pseudo_driver.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="make_pseudo_driver.sh" #!/bin/sh # This writes a skeleton driver and puts it into the kernel tree for you #arg1 is lowercase "foo" # # Trust me, RUN THIS SCRIPT :) # #-------cut here------------------ cd /sys/i386/conf if [ "${1}X" = "X" ] then echo "Hey , how about some help here.. give me a device name!" exit 1 fi UPPER=`echo ${1} |tr "[:lower:]" "[:upper:]"` cat >files.${UPPER} <${UPPER} <>${UPPER} cat >>${UPPER} <../../dev/${1}.c < #include #include /* SYSINIT stuff */ #include /* cdevsw stuff */ #include /* malloc region definitions */ #include /* DELAY() */ #include /* ${1} IOCTL definitions */ #ifdef DEVFS #include /* DEVFS defintitions */ #endif /* DEVFS */ /* Function prototypes (these should all be static except for ${1}intr()) */ static d_open_t ${1}open; static d_close_t ${1}close; static d_read_t ${1}read; static d_write_t ${1}write; static d_ioctl_t ${1}ioctl; static d_mmap_t ${1}mmap; static d_select_t ${1}select; #define CDEV_MAJOR 20 static struct cdevsw ${1}_cdevsw = { ${1}open, ${1}close, ${1}read, ${1}write, ${1}ioctl, nullstop, nullreset, nodevtotty, ${1}select, ${1}mmap, NULL, "${1}", NULL, -1 }; /* * device specific Misc defines */ #define BUFFERSIZE 1024 #define UNIT(dev) minor(dev) /* assume one minor number per unit */ /* * One of these per allocated device */ struct ${1}_softc { struct isa_device *dev; char buffer[BUFFERSIZE]; #ifdef DEVFS static void *devfs_token; #endif } ; typedef struct ${1}_softc *sc_p; static sc_p sca[N${UPPER}]; /* * Macro to check that the unit number is valid * Often this isn't needed as once the open() is performed, * the unit number is pretty much safe.. The exception would be if we * implemented devices that could "go away". in which case all these routines * would be wise to check the number, DIAGNOSTIC or not. */ #define CHECKUNIT(RETVAL) \ do { /* the do-while is a safe way to do this grouping */ \ if (unit > N${UPPER}) { \ printf(__FUNCTION__ ":bad unit $d\n", unit); \ return (RETVAL); \ } \ if (scp == NULL) { \ printf( __FUNCTION__ ": unit $d not attached\n", unit);\ return (RETVAL); \ } \ } while (0) #ifdef DIAGNOSTIC #define CHECKUNIT_DIAG(RETVAL) CHECKUNIT(RETVAL) #else /* DIAGNOSTIC */ #define CHECKUNIT_DIAG(RETVAL) #endif /* DIAGNOSTIC */ int ${1}ioctl (dev_t dev, int cmd, caddr_t data, int flag, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); switch (cmd) { case DHIOCRESET: /* whatever resets it */ outb(scp->dev->id_iobase, 0xff); break; default: return ENXIO; } return (0); } /* * You also need read, write, open, close routines. * This should get you started */ static int ${1}open(dev_t dev, int oflags, int devtype, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT(ENXIO); /* * Do processing */ return (0); } static int ${1}close(dev_t dev, int fflag, int devtype, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); /* * Do processing */ return (0); } static int ${1}read(dev_t dev, struct uio *uio, int ioflag) { int unit = UNIT (dev); sc_p scp = sca[unit]; int toread; CHECKUNIT_DIAG(ENXIO); /* * Do processing * read from buffer */ toread = (min(uio->uio_resid, sizeof(scp->buffer))); return(uiomove(scp->buffer, toread, uio)); } static int ${1}write(dev_t dev, struct uio *uio, int ioflag) { int unit = UNIT (dev); sc_p scp = sca[unit]; int towrite; CHECKUNIT_DIAG(ENXIO); /* * Do processing * write to buffer */ towrite = (min(uio->uio_resid, sizeof(scp->buffer))); return(uiomove(scp->buffer, towrite, uio)); } static int ${1}mmap(dev_t dev, int offset, int nprot) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(-1); /* * Do processing */ #if 0 /* if we had a frame buffer or whatever.. do this */ if (offset > FRAMEBUFFERSIZE - PAGE_SIZE) { return (-1); } return i386_btop((FRAMEBASE + offset)); #else return (-1); #endif } static int ${1}select(dev_t dev, int which, struct proc *p) { int unit = UNIT (dev); sc_p scp = sca[unit]; CHECKUNIT_DIAG(ENXIO); /* * Do processing */ return (0); /* this is the wrong value I'm sure */ } /* * Now for some driver initialisation. * Occurs ONCE during boot (very early). */ static void ${1}_drvinit(void *unused) { dev_t dev; int unit; sc_p scp = sca[unit]; dev = makedev(CDEV_MAJOR, 0); cdevsw_add(&dev, &${1}_cdevsw, NULL); for (unit = 0; unit < N${UPPER}; unit++) { /* * Allocate storage for this instance . */ scp = malloc(sizeof(*scp), M_DEVBUF, M_NOWAIT); if( scp == NULL) { printf("${1}%d failed to allocate strorage\n", unit); return ; } bzero(scp, sizeof(*scp)); sca[unit] = scp; #if DEVFS scp->devfs_token = devfs_add_devswf(&${1}_cdevsw, unit, DV_CHR, UID_ROOT, GID_KMEM, 0640, "${1}%d", unit); #endif } } SYSINIT(${1}dev, SI_SUB_DRIVERS, SI_ORDER_MIDDLE+CDEV_MAJOR, ${1}_drvinit, NULL) DONE cat >../../sys/${1}io.h < #endif #include /* * define an ioctl here */ #define DHIOCRESET _IO('D', 0) /* reset the ${1} device */ #endif DONE config ${UPPER} cd ../../compile/${UPPER} make depend make ${1}.o make exit #--------------end of script--------------- # #you also need to add an entry into the cdevsw[] #array in conf.c, but it's too hard to do in a script.. # #edit to your taste.. # # --------------237C228A31DFF4F5ABD322C-- From owner-freebsd-hackers Sat Feb 1 23:07:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA04990 for hackers-outgoing; Sat, 1 Feb 1997 23:07:53 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA04985 for ; Sat, 1 Feb 1997 23:07:46 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id CAA01954; Sun, 2 Feb 1997 02:04:37 -0500 From: Bill Paul Message-Id: <199702020704.CAA01954@skynet.ctr.columbia.edu> Subject: Re: slow ypserv problem To: tom@sdf.com (Tom Samplonius) Date: Sun, 2 Feb 1997 02:04:35 -0500 (EST) Cc: shovey@buffnet.net, hackers@FreeBSD.ORG In-Reply-To: from "Tom Samplonius" at Feb 1, 97 07:45:21 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Tom Samplonius had to walk into mine and say: > > On Sat, 1 Feb 1997, Steve wrote: > > > On Sat, 1 Feb 1997, Tom Samplonius wrote: > > > Bill knows. > > > > > > ypserv was completely re-written for 2.2. Darn straight. > > > Tom > > > > > > > > It it possible to get just that piece for 2.1? or wouldnt it work under > > 2.1? > > It won't compile without modification on 2.1.x I asked about this > along time ago, and Bill said that you'd have to drag over some rcp > library stuff too. > > Tom I think you mean RPC. Actually, the RPC library isn't the problem: the stuff under src/lib/libc/yplib is the problem. It changed quite a lot, and the new ypserv just won't link on 2.1.x unless you take certain steps. Also, I recently added async DNS lookups, which require calling into part of the resolver code in libc, which won't work on 2.1.x unless you supply some support code. Can you do it? Sure: I still run 2.1.0 at home and use it to do most of my development (though I test on a 2.2 machine too). But I've already tried to explain to people how to do it and I get the feeling I just leave them confused. For the record, the main reason why the 2.1.x ypserv is so slow in this case (many repeated calls to getpwent() to enumerate the passwd database) is because it opens/searches/closes the database on each access. The actual Linux version may not have this problem since it uses GDBM, and I think GDBM supports a special 'nextkey' routine which allows for sequential enumerations of a database in an efficient manner. With the Berkeley DB hash method, there's no simple way to say 'here's a key 'foo': find me the record that goes with this key and then return me the record that comes immediately _after_ it.' Unfortunately, this is exactly what you need to do for the yp_next() operation. The 2.1.x ypserv fakes this up by starting at the first record in the database and then searching through the database one record at a time until it find the specified key, then skips ahead one space to retrieve the next record. (The exception is for yp_all(): in this case the server just spews the whole map from start to finish, so no lookups are necessary.) This mess is caused by the fact that when using the hash method, Berkeley DB's 'cursor' can only be positioned by performing fetches with the DB_FIRST or DB_NEXT flags. Simply fetching an arbitrary record without any flags does not move the cursor. There is an RB_CURSOR flag which is supposed to let you shift the cursor to an arbitrary location, but it doesn't work for the hash method. It does work for the btree method, but I couldn't decide which method was faster and decided to just stick with hashing. In 2.2, the server gets around this problem by caching database handles: after you access a database the first time, the server keeps the database open and thus preserves the Berkeley DB 'cursor' location. On the next access, the lookup to open the map checks to see if there's already a handle in the cache that happens to be positioned at the right location, and if so, it uses that handle rather than opening a new one. In the case of the getpwent() loop, this permits the server to open the database just once. If two clients run the same kind of loop, each loop will end up with a separate cached handle. As more clients requests are received, more handles are cached until all slots are filled; once the slot limit is reached, the server starts evicting handles at the bottom of the list to make room for new ones. Note that the client side NIS code in libc has also been changed to support caching handles, though in this case it's RPC client handles rather than Berkeley DB database handles. Previously, the yplib code would call clnt_create(), clnt_call() and clnt_destroy() for every NIS call. This is not necessary; once a client handle has been created with clnt_create(), you can make as many clnt_call()s with it as you like. The code now reuses the same handle as often as it can until it encounters an error: only then will it destroy the binding and try to create a new one. With any luck, both the server and client side changes should make the overall performace much better. It's still not as fast as I'd like it, but I think the remaining performance problems stem from the fact that the transactions involved are very small: the client and server are both transmitting and receiving a large number of very small UDP packets. A 'ypcat passwd' is usually many times faster than a getpwent() loop since yp_all() uses a TCP pipe to send the whole map in one shot. By contrast, yp_first() and yp_next() can only send one record at a time. No batching is possible due to the nature of the NIS protocol, which is too bad as it would probably help a lot. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-hackers Sat Feb 1 23:48:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA07085 for hackers-outgoing; Sat, 1 Feb 1997 23:48:23 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA07080 for ; Sat, 1 Feb 1997 23:48:21 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id XAA12974 for ; Sat, 1 Feb 1997 23:49:44 -0800 (PST) Received: (qmail 4703 invoked by uid 110); 2 Feb 1997 07:48:03 -0000 Message-ID: <19970202074803.4702.qmail@suburbia.net> Subject: Re: slow ypserv problem In-Reply-To: <199702020704.CAA01954@skynet.ctr.columbia.edu> from Bill Paul at "Feb 2, 97 02:04:35 am" To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Sun, 2 Feb 1997 18:48:03 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Of all the gin joints in all the towns in all the world, Tom Samplonius > had to walk into mine and say: > > > > > On Sat, 1 Feb 1997, Steve wrote: > > > > > On Sat, 1 Feb 1997, Tom Samplonius wrote: > > > > Bill knows. > > > > > > > > ypserv was completely re-written for 2.2. > > Darn straight. (etc) What happened to the NIS+ support someone posted to here a few months ago? Cheers, Julian.